Classic crontab syntax mistakes

January 27, 2008

The crontab file format is unfortunately prone to mistakes, since it requires you to carefully count words and, for bonus fun, requires a different number of words in different contexts. There are three classic crontab syntax mistakes that I have seen (and sometimes committed):

  • adding a username when it's not necessary

    This generally results in mail from cron complaining that it cannot run 'username'.

  • failing to specify a username when it's necessary

    This results in mail about 'no such user program', assuming that you gave the program arguments. (A good version of cron will complain about it even if you didn't give the program arguments, because then it is a crontab line without a program to run.)

  • putting too many *'s in.

    If you are lucky, this produces mysterious email about cron not being able to execute the first file in your home directory. If you are not lucky, the first file in your home directory is executable, and it will get run with the rest of the files in your home directory as arguments.

    Alternately, if this is in a situation that needs a username, you get email about being unable to find the username '*'.

System crontab entries need usernames; on Linux systems this is /etc/crontab and the /etc/cron.d/* files. Per-user crontab entries, including root's, do not need or accept usernames.

(By 'per-user crontab entry' I mean what you get when you use 'crontab -e' and its kin.)

Personally I strongly suggest that you do not give root a per-user crontab on a machine with system crontabs, because doing so is a great way to confuse people. In fact, if you have system crontabs I don't think that any system account should have a per-user crontab; just put everything into the system crontabs with the right usernames specified.

Comments on this page:

From at 2008-02-03 13:09:59:

Heh, the confusion caused by creeping vendorisms like /etc/cron.d/* and /etc/crontab files even existing is one of the things that keeps me from running linux. Annoyances like that add up, but the cron breakage is one of the big ones for me.

Putting periodic tasks into so many different but not mutually exclusive places, with similar but not exactly the same syntax required, adds to the nightmare of trying to figure out what the machine has been told to do. Worse, in many cases it is a recipe for disaster.

By cks at 2008-02-03 22:06:54:

I think that Vixie cron has the right approach, for the same reason that /etc/init.d is the right approach; it's much easier to manage separate things than a single monolithic mass. This is especially so for crontab files, where if you manage them through crontab you can't use things like in-place version control and so on.

Written on 27 January 2008.
« The funding capture problem
One reason I like Python »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jan 27 23:59:44 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.