0

I'm using apcupsd to respond to events on an APC UPS. The daemon effects responses by chaining BASH scripts. First it calls apccontrol (appending 4 arguments) which in turn calls a script specific to the event such as "onbattery". Users can only edit these 3rd level scripts.

I have edited my "onbattery" script to build up modular messages for emailing and broadcasting and all works well when I call the "onbattery" script directly & when it's called from the 2nd level apccontrol. However when the chain starts from the top level daemon all commands such as cat, echo and the redirects / appends seem to be ignored in the final "onbattery" script.

I understand from reading that redirection in spawned shells / scripts is an issue but not how to get around it. Can anyone help please.

the onbattery script is as follows

#!/bin/bash
echo -e "From: Admin@somewhere \nSubject: Server on battery $(date +%D_%T) \n\n" > email.txt
cat OnBattWarn.txt >> email.txt
cat email.txt | ssmtp remoteadmin@somewherelse
wall | email.txt
exit99
3
  • Change wall | email.txt to wall <email.txt, and remove the line with exit99. – ott-- Apr 10 '16 at 21:57
  • Apart from ott 's suggestions the script should be able to redirect its own command outputs. Are there permissions errors or any other indicators? Add a ‘set -x` on line 2 for more info. – Jeff Schaller Apr 11 '16 at 0:25
  • Thanks ott but wall wasn't really the problem and the exit 99 is required by apcupsd and thanks to Jeff your instincts were right as below – JAH1 Apr 11 '16 at 15:22
0

Thanks for your consideration. A good night's sleep has revealed the answer. The script worked fine as root but failed as apcupsd - pointing to a permissions issue (as Jeff suggests) but in fact the problem was apcupsd creating the email.txt file in / and not within the originating /apcupsd directory. Without the file the redirects & appends etc failed. The simple solution was to use absolute paths - dumb me! I might have found the answer sooner if I hadn't used versions of the script successfully elsewhere, hence my misconceived analysis.

I had tried debugging with set -x but of course bash wasn't failing per se so no errors - just no result. Anyway all fixed now so thanks for your time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.