Classic crontab syntax mistakes
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
croncomplaining that it cannot run '
- 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
cronwill 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
If you are lucky, this produces mysterious email about
cronnot 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:Written on 27 January 2008.