Questions tagged [crontab]

Crontab files are stored where the lists of jobs and other instructions to the cron daemon are kept.
Users can have their own individual crontab files and often there is a system-wide crontab file (usually in /etc or a subdirectory of /etc) which only system administrators can edit.

Each line of a crontab file represents a job and is composed of a CRON expression, followed by a shell command to execute.

Basic format

 +---------------- minute (0 - 59)
 |  +------------- hour (0 - 23)
 |  |  +---------- day of month (1 - 31)
 |  |  |  +------- month (1 - 12)
 |  |  |  |  +---- day of week (0 - 6) (Sunday=0 or 7)
 |  |  |  |  |
 *  *  *  *  *  command to be executed 

Popular questions

• Why percent signs (%) do not work in crontab?
• cronjob does not execute a script that works fine standalone

Some implementations of cron, such as that in the popular 4th BSD edition written by Paul Vixie and included in many Linux distributions, add a sixth field to the format: an account username that the specified job will be run by (subject to user existence and permissions).

This is only allowed in the system crontabs, not in others which are each assigned to a single user to configure.
The sixth field is also sometimes used for year instead of an account username, the nncron daemon for Windows does this.

However Vixie cron does not use the sixth column as a year and if used will treat the year as the command to run and fail.

For "day of the week" (field 5), both 0 and 7 are considered Sunday, though some versions of Unix such as AIX do not list "7" as acceptable in the man page.

While normally the job is executed when the time/date specification fields all match the current time and date, there is one exception: if both "day of month" and "day of week" are restricted (not *), then either the "day of month" field (3) or the "day of week" field (5) must match the current day.

Vixie cron supports an extended time expression syntax where you can say e.g. 5,35 to run jobs at five past the hour and five past half; and */5 to run a job every five minutes/hours/days/months. This is not compatible with traditional / POSIX cron.

Debugging crontab

There are several reasons for why a cron job wouldn't run as expected:

1. Using percent signs, as in date +%F
2. Incorrect timespec
3. Adding or omitting username, depending
4. Cron isn't running
5. Problems with syntax or permissions
6. Making assumptions about the environment

These are all described below.

Percent signs

In crontab, percent signs are replaced by line feeds. This is an exceedingly common problem in backup jobs that try to archive with timestamp, e.g.

14 3 0 0 0 tar cfz /backup/file-$(date +%F).tar.gz /home

The % can be escaped by a backslash, but the backslash is not removed. This can cause additional confusion since escaping works for date +\%F, but not for wget "http://host/My\%20File.jpg".

Instead, put the command in a script file and run the script from crontab.

Incorrect timespec

People frequently put 1 * * * * mycommand in crontab, wait a few minutes, and wonder why their job didn't run. In this case, it's because the timespec means one minute past every hour, rather than every minute. Try a tool like crontab.guru to sanity check your timespec.

To test your cron job, use * * * * * if you want to run it frequently (every minute) while testing.

Adding or omitting username

On some systems, there's an /etc/crontab. In this file, a username is expected after the timespec, e.g.

57 1 * * * root rkhunter -c -sk

In regular crontabs as seen with crontab -l, for both normal users and root, no username is permitted.

A job will fail to run if a username is added in crontab -e or omitted in /etc/crontab.

Make sure you know which kind of crontab you're editing.

Cron might not be running

Not all systems have cron installed and running by default, and use e.g. anacron instead for periodic scheduling.

ps aux | grep [c]ron will list the cron daemon if it's running.

If it appears to be running, add an entry * * * * * touch /tmp/my_cronjob_ran and check whether the file is created after a minute. You can also check syslog to see a list of recently executed cron jobs.

Problems with syntax or permissions

It's quite common to try to avoid any shell and symbol issues by putting a command in a file, but forgetting to chmod +x before adding the crontab entry.

Ensure the command works in an interactive shell before adding it to crontab.

Do not discard a problematic command's output! If you have a problem with * * * * * command >/dev/null 2>&1 then remove the redirections and examine the output before asking us for help.

(If your command is not writing output to a file, the cron daemon will attempt to deliver any output by mail. Of course, this requires that you have mail set up and properly configured.)

Making assumptions about the environment

Graphical programs (X11 apps), Java programs, ssh and sudo are notoriously problematic to run as cron jobs. This is because they rely on things from interactive environments that may not be present in cron's environment.

To more closely model cron's environment interactively, run

env -i sh -c 'yourcommand'

This will clear all environment variables and run sh which may be more meager in features than your current shell.

Common problems uncovered this way:

• foo: Command not found or just foo: not found.

  Most likely $PATH is set in your .bashrc or similar interactive init file. Try specifying all commands by full path (or put source ~/.bashrc at the start of the script you're trying to run).

• Inexplicable shell syntax errors

  If your interactive shell is bash, it's easy to write a script which uses Bash features, and which appears to work from the command line. But cron does not run bash, it runs sh, which has a different set of features (even when /bin/sh is a symlink to /bin/bash)!

  If your script file has a proper shebang line #!/bin/bash then it will be run by the requested interpreter instead of sh.

• unable to open display

  You are trying to run a graphical program, but don't specify where (Unix never shows anything on "the screen", it only shows things on "a screen"). Put export DISPLAY=:0 at the start of your script if you want to try to open the program on the first display. This will fail if nobody is logged in at the time, and might bring up oddities on a colleague's display if somebody is logged in on the first display, but it's not you.

  A common architectural workaround is to split your service into a server running as a headless daemon and a userland component. Have the userland client listen to the server's events via some IPC mechanism (log file, socket, shared memory, shared bus, what have you) and then any or every user can follow what the server is doing, with fairly minimal runtime requirements for the server; and if they are running a graphical display, the client will run in a correctly configured session which trivially has access to the user's display, as well as window manager preferences, individualized client configuration settings, etc. (and if they want to, they can run a simpler command-line client instead, or as well, or neither when they don't want to be distracted, etc. etc. etc.).

• Any kind of password prompt

  If ssh or sudo asks for a password, it will fail in cron since the jobs run in the background with no user to interact with them. Make sure these are set up for automatic, non-interactive operations.

  For ssh, this means setting up a key pair, and doing so without a pass phrase (since ssh-agent isn't there to unlock keys). Trying to echo the password to ssh does not work.

  For sudo, this means adding entries to sudoers to allow running a command without password, and without requiring a tty. The Unix & Linux Stack Exchange has some posts on how.

It still doesn't work!

So you can run simple commands like touch /tmp/my_cronjob_ran just fine?

And your desired command contains no %s and runs fine with env -i sh -c 'yourcommand'?

Does it still run fine with env -i sh -c 'nohup yourcommand' or env -i sh -c 'yourcommand </dev/null'? If not then it has a problem when it doesn't have standard input and/or a controlling terminal.

Yet it still fails from cron?

Add logging to your command with * * * * * yourcommand >> /tmp/mylog 2>&1 then examine /tmp/mylog which will log output and errors to /tmp/mylog. Don't forget that because you are using >> (append redirection), the newest entries will be at the end of the file. You may have errors at the top, and only discover later that half the way down you corrected the problem. If you only look at the top of the file, you'll miss the changes happening at the bottom.

If after reading /tmp/mylog you still don't know what's wrong, it's time to post a question. Make sure to include relevant output from this file in your post.