4

How can I determine any problems with the /etc/crontab not running cron commands? I have scripts that send emails, I can run them manually via command line and they work great, but never get processed by cron....

What can I do to debug why cron isn't running?

I have a feeling this is part of the problem...

$ sudo /etc/init.d/crond start
sudo: /etc/init.d/crond: command not found
1
  • 1
    It's /etc/init.d/cron not crond on Ubuntu
    – brent
    Dec 7, 2010 at 16:22

4 Answers 4

3

You've got a few options, not in any particular order.

  • Run the command that you have in crontab on the command line. This can be deceptive since oftentimes this will work for you, and the reason it's not running in cron is a missing environment variable, or something along those lines.

  • Add an output option to your crontab line, for example:

    5 */2 * * * /usr/local/bin/do-stuff.sh >> /tmp/results.log;

  • Make sure cron is actually running.

  • Check your cron log files for any particular errors. 

10
  • Don't forget: set MAILTO at the top of your crontab to point to some e-mail address that you actually check. (The default is to go to the local system account under which the cron job ran -- for /etc/crontab, probably root.
    – mattdm
    Dec 7, 2010 at 15:09
  • MAILTO is indeed actually set
    – Ben
    Dec 7, 2010 at 15:13
  • How do I make sure that cron is actually running? I can't find any cron log files or documentation on them, and nothing gets outputted or emailed given the output of these scripts. I have verified that these scripts will run when I push them manually
    – Ben
    Dec 7, 2010 at 15:20
  • The lazy way to check if cron is running is to simply run "/etc/init.d/cron restart" -- the output should indicate if it was running or not, and when you're done it should be running either way. Alternatively, something along the lines of "ps ax | grep cron" should list cron, if it's running.
    – muffinista
    Dec 7, 2010 at 15:59
  • 1
    Got it, I enabled logging and that led me to the error, thanks!
    – Ben
    Dec 8, 2010 at 16:38
1

In addition to @muffinista and @brent's answers, there are more esoteric problems you can run into on Ubuntu

  • You need a blank line at the end of your crontab.
  • The user must be in|not-in /etc/cron.allow|cron.deny (or have these files absent)
    • user does not need to be a member of group crontab
  • cron may ignore filenames it doesn't like in /etc/cron.d/ and similar directories.
    • add cron's '-l' option (impact explained more in 'man run-parts')
  • cron sends the crontab entries through /bin/sh (by default), so things as simple-looking as this will fail, but work when pasted into your /bin/bash terminal

    0 * * * * echo hi >& /dev/null

    so change SHELL or your redirection syntax! 

My version of Ubuntu ignores settings in /etc/defaults/cron, so to bump up the log level you might need to run the cron daemon by hand (cron -f -L 2).

0

In some recent cases, this has been due to people editing things in /etc/crontab without sending crond signal 1 (SIGHUP) to let it know that it should reread the /etc/crontab file.

Try

kill -1 $PID-OF-CROND

and see if that helps. Determining the pid of crond is left as an exercise for you ;-) - not least because if you can't find it, it may mean that crond isn't running, and then you'll have found your problem!

0

If you're using shellscript, people often forget that commands they use in their script may not be in cron's PATH (e.g., something in /opt). Setup your PATH properly at the beginning of your script as needed. For sh/bash, it would be:

PATH=$PATH:/opt/something-1.0/bin

for example

1
  • I've verified that the path is correct
    – Ben
    Dec 7, 2010 at 17:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .