OS X: How to track down and kill a cron job. Or something.

November 14, 2009 3:09 PM

OS X Unix filter: Please help me find and delete an obsolete cron job on an iMac running Leopard.

I'm doing tech support for a small office. A previous provider setup a cron job or something to create an rsync backup to a MacMini server every day at the same time. The backup configuration has changed, but this one job keeps trying to run. I can't find the script to delete it and am getting a bit frustrated.

I've tried

crontab -e - which shows an empty crontab.

I've looked in StartupItems, looked in /usr/bin/, usr/sbin/ for a compiled script, looked in the logs to see if I could see the source of the job, but it doesn't log to system.log or console.log. I did find the log that was set up for the backup, but it doesn't say the path of the original script. I know it's running because it was set up to also send an email to the office administrator. She gets a failure message daily.

I'm pretty sure it's not a LaunchDaemon, as the job was set up by someone who was using old-style tools, and all of the LaunchDaemons I could find were stock OS X.

Any idea how I can track this thing down and kill it for good?

Thanks!

posted by al_fresco to computers & internet (13 comments total)

I don't know anything about OS X, but I know a couple things about Linux. So maybe this'll work - in Ubuntu, there's a user crontab for each user, but there's also a root crontab for the root user, which is often more convenient for system-level processes since it has root access. In Ubuntu, you can access it with

sudo crontab -e

which by virtue of executing as the superuser will bring up the root crontab. Good luck.
posted by Salvor Hardin at 3:13 PM on November 14, 2009

Check in /usr/lib/cron/tabs or /etc/crontab ... if there's a file in there, do not just delete it, because it may screw up your cron daemon (not sure if this applies to OSX, but it certainly does to other unices). Run crontab -u [username] -r for the user that the crontab file is named after. That will delete it. That command might be backwards, it may be crontab -r -u [username], so give that a try if the previous one doesn't work.
posted by synaesthetichaze at 3:14 PM on November 14, 2009

I'm assuming you're root already, by the way. If not, Salvor Hardin's answer may be more relevant than mine.
posted by synaesthetichaze at 3:17 PM on November 14, 2009

Oh yeah, I forgot that it's possible to log in as the root user in other UNIX systems. That capability is disabled in Ubuntu by default.
posted by Salvor Hardin at 3:20 PM on November 14, 2009

Dump your crontab to a file, edit that file, then crontabbify it back again. That's:

1) $ crontab -l > mycrontab
2) $ pico mycrontab
3) (edit file the way you like, remove lines as you like)
4) $ crontab mycrontab

(You can use pico, or vi, or bbedit, or whatever editor you like in step 2.)

If it's a root crontab file, do an su - before step 1.
posted by rokusan at 3:43 PM on November 14, 2009

It's dsabled in OSX by default as well, but you can sudo.

Places to look: /var/cron/tabs for various users' crontabs, and /etc/crontab for the old-fashioned non-user-specific crontabs (both are empty on my system); /etc/periodic for some scripts run as daily/weekly/monthly housekeeping that the previous guy might have hooked into; /etc/daily.local for one common place to put such things.

I'd do an ls -lAtr in /etc to list files by order of modification date, and see if any of them have suggestive names / modification dates.

You can use sudo launchctl list to list launchd-managed jobs— many of these are jobs that invoke more traditional mechanisms (eg, cron jobs are run via launchd, as are the periodic scripts.)
posted by hattifattener at 3:43 PM on November 14, 2009

And just plain crontab -l (for "list") as any user will show you what's there now.
posted by rokusan at 3:43 PM on November 14, 2009

Is it possible the task is running from the Mini, by connecting to and pulling the files, rather than from the computer you're working on?
posted by rokusan at 3:45 PM on November 14, 2009

Thanks, folks for the tips! Keep them coming, as some of these I've tried but some I haven't.

@rokusan: It is possible that it's running from the mini, but I ran many of the same tests on the mini and wan't able to find it.

I didn't mention that I was able to locate and delete the job from the 5 other computers in the office using

sudo crontab -e

Sorry, but when I wrote before I forgot to include the sudo in my example command.
posted by al_fresco at 3:57 PM on November 14, 2009

If you know when the job is running, you can look at the process tree to see the name of the command executing the job, and the name of the process running that command etc.

'ps axjf' should give an illustration of the tree of spawned processes, which you can then examine to find your culprit.
posted by idiopath at 5:08 PM on November 14, 2009

Also: if you know the command that is being run, you can make a shell script that calls the real command and logs some forensic info to help you track down when and why it is being run, and temporarily replace the command with the shell script.

ie. something like (simplified for the sake of example)

echo 'date >> /root/wtf.log; ps axjf >> /root/wtf.log; /usr/bin/rsync.real $*' > rsync.fake
mv /usr/bin/rsync /usr/bin/rsync.real
cp rsync.fake /usr/bin/rsync

posted by idiopath at 5:16 PM on November 14, 2009 [1 favorite]

If I understand you correctly, the backup logfile is accessible and known, right? Lsof may be useful for monitoring the logfile and tracing back to the actual script. There are many ways to set up periodicity in scripts so I wouldn't assume it must be a cronjob. You could also change permissions on the log so that the next time the script runs it will bomb out and the system will log the access failure.
posted by benzenedream at 5:36 PM on November 14, 2009

Lots of great suggestions. I'll get my hands on this machine again on Monday, and I'll let you know if and how I track it down.

Thanks again!
posted by al_fresco at 10:38 PM on November 14, 2009