Heal Your Church WebSite

Teaching, rebuking, correcting & training in righteous web design.

How to stop a run-away cron job

Earlier this morning, I got a panicky email from a friend whose hosting provider made a boo-boo, launching a CRON job to perform an automated backup every minute instead of once a day. OOPS! While sorta funny, the situation was potentially sorta serious. Here’s the advice I suggested to ‘bash’ the run-away job(s) dead as a doornail:

Step 1 – stop the cron daemon

Linux has the ability to start and stop background services on the fly. Known as daemons in *nix parlance, the cron service runs once a minute. So step number one is to stop the cron daemon:

$ /etc/init.d/crond stop


$ /sbin/service crond stop

Which version you’ll employ depends on which version of Linux you’re running, but for clarity, I’ll continue on with the ‘/etc/’ flavor for the rest of this post.

You can check to see the status of the daemon with the ‘status’ command:

$ /etc/init.d/crond status

Step 2 – Remove the errant crontab entry

First understand that merely removing the errant crontab entry will not kill any run-away jobs currently in process. It will however prevent future jobs run running again. Some might suggest crontab -r … but that’s the sort of nuclear option I’d rather not resort to unless all else fails.

We’ve discussed modifying contab before, which for most of you is a task that has been somewhat ‘de-geeked’ by means of various command consoles such as cPanel and Plesk.

However, when dealing with run-away process – it might not hurt to know how to modify crontab from via the shell/command line as HTTP services (e.g. your web-based admin screens) might be unavailable.

Step 3 – Identify the run-away process

So far, we’ve been working in the realm of ‘relatively safe.‘ But killing a process, that’s one sure way to shoot one’s foot clean off – so proceed with caution.

If this is beginning to become all too much for you, it is at this point you can reboot the server and let it do the rest of the dirty work.

For the brave, caution means enumerating all the active/running processes with as much information possible. On a SUN, that would be ps -ef, on Linux ps aux.

Of course these commands can potentially list dozens, if not hundreds of processes, so the trick is to limit the results, piping them through grep to filter only those jobs you want/need to see.

The results should include the process id (PID) of the offending process – and if you’re good with your grep – any related (parent) processes. With that PID, you then use the kill command to wack the runaway process good’n’dead. Here’s an example:
bash-2.05a$ ps aux | grep “mywebsite”
mywebsite 11666 0.0 0.2 2444 1344 pts/2 S 23:43 0:00 -bash
mywebsite 12451 0.0 0.1 1700 604 pts/2 R 23:50 20:00 mybackup
mywebsite 13074 0.0 0.1 2660 760 pts/2 R 23:50 0:00 ps -aux
mywebsite 13075 0.0 0.1 1700 604 pts/2 R 23:50 0:00 grep mywebsite
bash-2.05a$ kill 12451

BTW, kill -9 can be used to forgo the graceful exit and just kill the process
now (e.g. do not stop at go, do not collect $200, just drop dead).

4 – Restart the crontab daemon

$ /etc/init.d/crond restart


While the above steps worked fine for said friend (no, I’m not ‘said friend’), please note that with any such online advice, such advice, your command-line syntax, results and mileage may vary. Meaning, I disclaim any responsibility of you entirely submarine your system.

Still, I wanted to document this … just in case …

… yeah, isn’t that reassuring?-)