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

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
  • Change wall | email.txt to wall <email.txt, and remove the line with exit99.
    – ott--
    Apr 10, 2016 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, 2016 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, 2016 at 15:22

1 Answer 1


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .