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.