What is preventing me from piping from a '600' file into mail within launchd?

I've recently been working on this myself, and have found entries in the system log (/var/log/system.log) that show errors related to this issue, such as:

Nov  1 08:52:14 my-computer com.apple.launchd[1] (org.postfix.master[22591]): Stray process with PGID equal to this dead job: PID 22592 PPID 1 pickup
Nov  1 08:52:14 my-computer com.apple.launchd[1] (org.postfix.master[22591]): Stray process with PGID equal to this dead job: PID 22594 PPID 1 cleanup

I found that my logcheck script and the expected email worked perfectly when executed from the command line, and that the logcheck script was performing its functions well when launched using launchd via a LaunchDaemon script.

However, the mail never arrived when using launchd. The errors above, and many others, involving postfix and sendmail, indicate that the child sendmail processes were being terminated by launchd (as part of its garbage collection routines?) before they had time to complete.

I added the following key to my plist:

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

and the mail started flowing when using launchd. Unfortunately, I still get the stray process/dead job messages in my system.log, which I'm currently working on eliminating. I've added a sleep 120 line to my logcheck.sh script, which reduced, but has not eliminated, these messages. I could lengthen the time of the sleep command in logcheck.sh, so that the script persists longer, but I don't like this particular 'hack' and want to find a more elegant solution. I believe launchd does not begin its garbage collection until after the logcheck.sh process completes....

I'm going to try explicitly lengthening the TimeOut key in the controlling plist, and see if that works better.

Out of curiosity, when your script successfully sends the reports, are the bodies empty?

I just ask because your workaround will always generate an email if /Users/myuser/report is writable, even if you can't read $TMPDIR/checkreport.$$. The body will be empty, but you'll get the email with the appropriate subject line.

What happens when you run something like this?

if [ -r $TMPDIR/checkreport.$$ ]; then
    <$TMPDIR/checkreport.$$ $MAIL -s "$HOSTNAME $DATE system check" $SYSADMIN
else
    echo "Unable to read file: $TMPDIR/checkreport.$$" | $MAIL -s "ERROR: $HOSTNAME $DATE system check" $SYSADMIN
fi

This will only attempt to send the report email if $TMPDIR/checkreport.$$ exists and is readable, otherwise you should get an email telling you the explicit filename that it could not read, and you can investigate from there.

As a side note, I just removed the cat command because it spins up an unnecessary process. End result will be the same, but it's a little cleaner to just redirect the file contents straight to your mail command, rather than piping cat's output to it.

Your ls output clearly shows that your user can not enter neither read the $TMPDIR, so he can't read the file even if it would be readable to him.

As already pointed out, your second hack simply creates an empty file even if it can't enter the temp dir ... so the mail arrives, but empty.

You should:

• add your user to the admin group
• make the $TMPDIR g+rXs

in order to have the file available to the user.