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?
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?
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:
in order to have the file available to the user.
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: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:
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 mylogcheck.sh
script, which reduced, but has not eliminated, these messages. I could lengthen the time of the sleep command inlogcheck.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.