Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Often, crontab scripts are not executed on schedule or as expected. There are numerous reasons for that:

  1. wrong crontab notation
  2. permissions problem
  3. environment variables

This community wiki aims to aggregate the top reasons for crontab scripts not being executed as expected. Write each reason in a separate answer.

Please include one reason per answer - details about why it's not executed - and fix(es) for that one reason.

Please write only cron-specific issues, e.g. commands that execute as expected from the shell but execute erroneously by cron.

share|improve this question
You must close crontab -e for the cron to take affect. For instance using vim I edit the file and use :w to write it but the job is not added to cron until I quit also. So I will not see the job until after I :q also. – DutGRIFF Jun 24 '14 at 14:58
I think best way to debug cron is to check syslog and find the problems. – Suneel Omrey Jun 23 at 7:49

40 Answers 40

=== Docker alert ===

If you're using docker,

I think it is proper to add that I couldn't manage to make cron to run in the background.

To run a cron job inside the container, I used supervisor and ran cron -f, together with the other process.

Edit: Another issue - I also didn't manage to get it work when running the container with HOST networking. See this issue here also:

share|improve this answer

Logging Permissions

A very simple crontab, won't execute because /var/log/ is not writable by luser account!

* * * * * /usr/local/bin/teamviewer_check >> /var/log/teamviewer.log 2>&1

SOLUTION: create the file as root and chmod to 777

Thanks to the previous suggestion of enabling cron logging in /etc/rsyslog.d/50-default.conf, leads to syslog entry (No MTA installed, discarding output), then thanks to "(CRON) info (No MTA installed, discarding output)" error in the syslog installing postfix in local mode, tail /var/mail/luser, /bin/sh: 1: cannot create /var/log/teamviewer.log: Permission denied

share|improve this answer

If you have a command like this:

* * * * * /path/to/script >> /tmp/output

and it doesn't work and you can't see any output, it may not necessarily mean cron isn't working. The script could be broken and the output going to stderr which doesn't get passed to /tmp/output. Check this isn't the case, by capturing this output as well:

* * * * * /path/to/script >> /tmp/output 2>&1

to see if this helps you catch your issue.


share|improve this answer

My crontab only worked when I was logged in as user.

I found my solution here:

What was the problem is that the scrips were in my home directory which was encrypted. So it will be unmounted and unavailable when I was logged of. You can use the cmd mount to see if your home directory is mounted for encryption. I fixed the problem by putting my scripts in the /usr/local/bin folder.

share|improve this answer

In 16.04, if you have this error in syslog

(CRON) error (can't fork)


systemctl status cron.service

In the result:

Tasks: num_task (limit: 512)

If num_task is close to the limit use:

systemctl set-property cron.service TasksMax=new_max

Replace new_max with a suitable value.

share|improve this answer

I once was working on a shared server with lots of restrictions.

All the answers here (PATH, SHELL, bash -c,...) could not get my script to work in the crontab.

It did work perfectly when I put the command in a little script file with the PATH, SHELL, and shebang rather than in the crontab itself. I did have to change the permissions to 700.

share|improve this answer

Another Gotcha:

When you type crontab -e and save inside the editor, it won't have any effect. You have to exit the editor for it to add or update according to your changes (e.g. use :x in Vim).

(crontab -e effectively runs "edit cron file; update from cron file" so it's blocking on the editor until you close it.)

share|improve this answer

If running scripts within /etc/cron.* directories, make sure your scripts:

  • are executable,
  • match the Ubuntu/Debian cron script namespace (^[a-zA-Z0-9_-]+$).

So for example if you've script with extension (such as .sh) won't work.

To print the names of the scripts which would be run on hourly basis, try:

sudo run-parts --report --test /etc/cron.hourly
share|improve this answer

I had some issues with using sudo in a cron.

Basically I wanted to run a command as a specific user and I tested first, at the command line, su, which returned the error This account is not available. Using sudo, the command ran without errors.

However, when running from cron, the sudo command returned the following error: sudo: sorry, you must have a tty to run sudo.

I later found that using runuser and specifing a shell for the command to run, works.

share|improve this answer

Sometimes cron is working just fine but the script or command you want it to run just fails silently, causing you to bark up the wrong tree.

In such cases I find it useful to wrap the target within another short script, which outputs some visible debugging code (including output of date) and use redirection to ensure I get some evidence to inspect. If the target is a script, wrapping around a sh -x can help further.

The crontab entry (always edit with crontab -e) could look like this:

00 14 * * * (sh -x /tmp/my_wrapper_script) >> /tmp/debug.log 2>&1

Inspect /tmp/debug.log and its timestamp. If it's empty, non-existent or the timesamp isn't shortly after 14:00 (in this example) you may have a cron issue, otherwise you need to debug the actual target action and cron is working just fine!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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