Getting "com.apple.launchd[1] (0x1109b0.cron[87714])" every 5 minutes

I've removed all jobs from my crontab. No other users even have a cron/tab/ file yet I still get the message. I personally suspect it's the crond (launchd?) application itself or the message is misleading and it isn't actually cron at all.

Let me retract that. If I remove my user's cron/tabs file, the messages stop. But that's really obviously not a solution.

The worse part is that I just noticed now I'm getting two a minute instead of one.

Ok, I think I get it. The message is coming from the cron (launchd?) application for every job that executes. I have two that run every minute which is why I'm getting two messages every minute.

This is almost certainly a bug in launchd in which it is mishandling or improperly allocating port 9. If that means, tcp port 9, that is effectively /dev/null. It could be that the application is attempting to discard the jobs output. Or, it's attempting to capture the output for logging. I suspect the latter and since I've yet to see any of my jobs' output in any log, anywhere, this message could be an indication of the bug.

criquet wrote:
Ok, I think I get it. The message is coming from the cron (launchd?) application for every job that executes. I have two that run every minute which is why I'm getting two messages every minute.

Hmm, I thought someone already mentioned that, but I can't seem to find it. Yes, the error occurs for each and every cron job that runs.

This is almost certainly a bug in launchd in which it is mishandling or improperly allocating port 9. If that means, tcp port 9, that is effectively /dev/null. It could be that the application is attempting to discard the jobs output. Or, it's attempting to capture the output for logging. I suspect the latter and since I've yet to see any of my jobs' output in any log, anywhere, this message could be an indication of the bug.

The port in question is a "Task Special Port". It's a kernel thing; completely unrelated to TCP ports.

The output of the cron job should be mailed to the user related to the crontab file. By default, root's email is redirected to /dev/null. Check /var/root/.forward and/or /etc/postfix/aliases to see or change where root's email goes. If you're not getting cronjob output for other users, verify the job generates output and that the user can get mail via something like "echo test | mail user"

If you're feeling up to it, you might be able to convert the job to run from launchd directly instead of through cron. See http://developer.apple.com/macosx/launchd.html

Generally, I try to stay away from cron jobs that run every minute. It doesn't take much to get multiple jobs running (if one or more takes longer than a minute, gets blocked, etc.) Unless the job checks for the existence of other duplicate jobs already running, you can also get into situations where files get clobbered, corrupted etc. For things that really have to run every minute or so, it's often better to make a script with a forever loop and a sleep 60 -- at least this way there's only ever one job running.

Hope this helps...

Thanks for the input. Agreed about the multiple jobs. All scripts that can be invoked periodically should protect themselves from multiple instances. A fairly simple technique I use (in bash) is:

\[ -e ~/.${SELF].pid ] && exit 1
trap 'rm -f ~/.${SELF}.pid' 0 1 2 3 9
echo $$ > ~/.${SELF}.pid

The point of cron is that it is far simpler to set up jobs than launchd. Additionally, cron is already the forever-loop. Even implementing your own forever-loop script, you still have to protect against multiple instances so why not just take advantage of cron's forever-loop.

When launchd is as easy to use as cron, I'll switch. Otherwise, when the job simply calls for simple periodic execution, I prefer cron.

Message was edited by: criquet

Whoa! That's weird. I didn't realize this editor did substitutions. It initiall converted the \[ -e ~/.${SELF}.pid ] into an http link. Maybe the editor should check for properly formatted URLs prior to making that change.

another way to deal with that in bash anyway, how I do it here

if ps -ww | grep "$0" | grep -v grep | grep -v $$ > /dev/null ; then
# there is another copy of us running NOW. bail out.
terminate "DUPLICATE RUNNING"
fi

Where terminate logs the event, notifies me of a hung process, and exit's. I may get brave later and have it log its PID when it spawns, so if it hangs, the next one that piles in can kill it. I've found it's best to set a "tolerance" level on things like that, so you don't have it kill the hung one unless it's been discovered several times. Five seems to be a good limit, if it hasn't unstuck by then it's fair game for kill -9.