5

In OSX 10.6 I'm running logcheck.sh via. launchd using this plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key><string>org.logcheck</string>
<key>Program</key><string>/opt/local/bin/logcheck.sh</string>
<key>StartInterval</key><integer>600</integer>
</dict>
</plist>

logcheck runs at the specified interval but it won't send me mail using the command below:

cat $TMPDIR/checkreport.$$ | $MAIL -s "$HOSTNAME $DATE system check" $SYSADMIN

where

$TMPDIR=/opt/local/var/tmp
$MAIL=/usr/bin/mail
$SYSADMIN=myuser

however, if I hack it, and change the command to:

cat $TMPDIR/checkreport.$$ > /Users/myuser/report
cat /Users/myuser/report | $MAIL -s "$HOSTNAME $DATE system check" $SYSADMIN

then I receive the mail.

Checking permission on tmp with $ls -l /opt/local/var I get

drwx------  20 root  admin  680 Jul 12 13:29 tmp/

If I run sudo /opt/local/bin/logcheck.sh the first command works.

If I use /opt/local/bin/logcheck.sh in root's crontab the first command works.

If I throw in the script echo "$(whoami)" > /Users/myuser/launchduser I see that it is indeed being run by root.

Why am I not getting mail with the first command in launchd? Is it a permissions issue with the pipe to mail?

bias
  • 225
  • 3
  • 13
  • 1
    What do your logs say? – Dennis Williamson Jul 12 '10 at 20:11
  • Sorry, forgot to mention them. Actually, nothing unusual (i.e. concerning launchd, logcheck, etc.) even when I enable in the launchd plist. Literally, only my sudo usage and my vpn were logged to syslog when this was occuring. – bias Jul 12 '10 at 23:00
  • 1
    What do you get when you run `set` in the script? Make sure all of your environment variables are getting defined properly in the context that launchd is running your app in. – peelman Jul 21 '10 at 21:52

3 Answers3

1

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.

Andy Simmons
  • 41
  • 2
1

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.

drAlberT
  • 10,871
  • 7
  • 38
  • 52
  • The second hack creates a file with the username *root* in it. And, root does indeed have permissions on /opt/local/var – bias Nov 26 '12 at 19:19
1

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.

kenorb
  • 5,943
  • 1
  • 44
  • 53
Roy Miller
  • 26
  • 1