I've written a simple bash script to check whether a program (supplied as its only argument) is running and send an email to a set address in the script if it's not. The script works if run on the command line, but I cannot for the life of me get it to work under launchd as a user agent (~/Library/LaunchAgents) where I try to set it to run every minute. The latest incarnation of the relevant .plist file is (monitoring Dropbox):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>greencollar.Dropbox.checkRun</string>
        <key>StartInterval</key>
        <integer>60</integer>
        <key>Program</key>
        <string>/Users/greencollar/Documents/code/proc_check.sh</string>
        <key>ProgramArguments</key>
        <array>
            <string>proc_check.sh</string>
            <string>Dropbox</string>
        </array>
    </dict>
</plist>

Yes - the bash script is executable and no there are no entries in Console indicating any problems with the .plist file. I have tried making /bin/bash the program, but that doesn't seem to make any difference and reading execvp(3) seems to hint that it wouldn't. I've also tried having everything under <ProgramArguments> without any luck as well. Any help would be greatly appreciated as this seems to me pretty basic and it's very frustrating that I can't get it to work!

----------------------------- 1st Edit ---------------------------

Here is the pared-down basics of the shell script:

#!/bin/bash
PROC=$1
if ! /usr/bin/pgrep $PROC > /dev/null
then
    /bin/echo "$PROC is not running!" | /usr/bin/mail -s "$PROC down" email@mydomain
fi

Not much to go wrong there...

  • Have you run with the full path as the first argument in ProgramArguments - also what are the permissions on the script? (the easy way is to use LaunchControl or other programs to edit the script) – Mark May 7 '16 at 14:03
  • 1
    Also when you say does not run - how would you know if it runs? – Mark May 7 '16 at 14:07
  • 3
    Without omitting anything, other then to put a suitable placeholder for something that's sensitive, e.g. the actual email address and password, etc., edit you question to include the contents of the proc_check.sh shell script. Because without it, there cannot be a complete troubleshooting process that's done easily or by trying to replicate as exact as possible, where the issue is. – user3439894 May 7 '16 at 19:16
  • @Mark, Thanks for the comment on my now deleted previous answer. It made me test the .plist in the question, which I admit I hadn't because I thought I saw a problem with it, and it did trigger (on my system anyway). So, I do not believe that's where the issue is. My new answer I believe may be spot on for where the issue could be. Obviously without seeing the contents of the script I can't say for sure, however this is most likely where the issue may be. – user3439894 May 7 '16 at 20:06
  • 1
    I've tested both the .plist and the proc_check.sh, using my $HOME and rest of your path of course, and this works when called by launchd for me in testing with "Caculator" and say $PROC is not running. I didn't test sending email as my system is not setup to do that. So you might want to test like I did to see if that works and then if it does the troubleshooting will need to be done on how mail might be being handled when triggered by launchd. BTW I'm running OS X 10.8.5, what version are you running? – user3439894 May 9 '16 at 2:06

I'm posting this as an answer because it's to much for a comment and I believe I know what the issue may be, even without seeing the contents of the proc_check.sh shell script.

I realized after reading again your question and ensuing comments, after deleting my first answer, the hint was the script worked from the command line but not when called by launchd.

When your User Agent .plist file is triggered, the $PATH it receives may not contain the paths to some commands/utilities that are being called within the script. The $PATH passed to the proc_check.sh shell script is only:

/usr/bin:/bin:/usr/sbin:/sbin

So, any program that is called in the script that is not in the above $PATH or includes it's fully qualified pathname is not running when called by launchd.

To fix this, either use the fully qualified pathname for all executables called within the script, that are not in the above $PATH, or add a PATH=... statement after the shebang, where ... is the actual output of, echo $PATH in Terminal, e.g.:

#!/bin/bash
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin

Note: The $PATH above is what's outputted by echo $PATH on my system and may well be different on yours.

  • Thanks for the comments so far. I modified my script down to the barest essentials and put the full paths to all executables but it still doesn't work. Here is the script: #!/bin/bash PROC=$1 if ! /usr/bin/pgrep $PROC > /dev/null then /bin/echo "$PROC is not running!" | /usr/bin/mail -s "$PROC down" email@mydomain fi It is definitely the script as an improper edit resulted in console messages every minute. But I can't see what's wrong with it. – GAM May 9 '16 at 1:14
  • @GAM, Please add your script to your question in a properly formatted structure, not in a comment. – user3439894 May 9 '16 at 1:16
up vote 2 down vote accepted

After getting this far, it had to be some issue with mail being invoked by launchd, so I searched on that and I found this which referenced this. It was the .plist file in that it did not include the AbandonProcessGroup key which would allow the mail process to live long enough to work. Adding

<key>AbandonProcessGroup</key>
<true/>

made it work.

I was setting myself up for this in that I was using a .plist generated by a 3rd party app to "save time". Such apps are not always complete or accurate in the .plist files they produce, apparently.

Thanks to @user3439894 & @Mark for their help.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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