I have used these 2 references to insert a new crontab entry.



I have created a new bash file and moved it to /usr/bin. That sh file has execute permissions for the root user and the admin group. The bash file just echos a line to a log file and then calls a java program. I have tested the sh file as root, manually. It runs fine. My crontab entry looks like this...

 @hourly      /usr/bin/foo.blah.sh

It's supposed to run at the top of every hour. The echo statement is not getting printed to the log file so I don't think crond is calling it at all. Also, when I visually monitor processes in "top", the job never appears. I have run "service crond status" to verify the cron daemon is running. The documentation says that restarting the daemon is not necessary. What else could I be doing wrong?

  • 1
    What's the output when you list your crontab file: crontab -l
    – John
    May 19, 2016 at 20:32
  • "no crontab for root" What does that mean?
    – bwfrieds
    May 19, 2016 at 21:02
  • @bwfrieds It means that there is no user-specific crontab file for the user named root. Crontabs can be user-specific or system-wide; I think you have made a system-wide one. See my answer for more details.
    – user
    May 19, 2016 at 21:36

2 Answers 2


You don't actually say where the crontab entry is, but based on your comment that crontab -l outputs no crontab for root, I would hazard a guess that you have added a file under one of the /etc/cron.* directories, which contains files corresponding to various cron jobs. This answer assumes that that is the case.

Those files have a format that is slightly different from the user-specific crontab that you edit through crontab -e. Specifically, they include a username field just before the command, which is not included in the user-specific crontab (which at least on my system are stored under /var/spool/cron/crontabs, but please don't abuse that information; the exact location is an implementation detail of the cron daemon you happen to be running, and you should use the documented interfaces for managing those files).

As a result, you should change

@hourly      /usr/bin/foo.blah.sh


@hourly user /usr/bin/foo.blah.sh

where user is the name of the user account to run the script as. It should then run fine.

I really encourage you to not run cron jobs as root unless you must; doing anything as the superuser is always a security risk. If possible, give the script its own account with restricted access. (This is the principle of least privilege; least, that is, that is required for it to do its job.) As a general rule, you should place system-local files into /usr/local to avoid clashes with the system package manager; additionally, to avoid confusion, don't place things in any bin directory that need root privileges to work, use sbin instead.

  • +1 for separate user account for automated tasks
    – John
    May 19, 2016 at 21:41

In the past, when adding scripts to cron, I always led the line with sh, like so:

@hourly    sh /usr/bin/foo.blah.sh

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.