Cron is a time-based job scheduler running as a daemon process in Unix-like computer operating systems. Questions about configuring cron for systems or administration are OFF TOPIC.
The name "cron" comes from the word "chronos", Greek for "time". Cron enables users to schedule jobs (cronjobs, commands or shell scripts) to run periodically at certain times or dates.
It is commonly used to automate system maintenance or administration, though its general-purpose nature means that it can be used for other purposes, such as connecting to the internet and downloading emails.
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
Basic commands
crontab -eEdit crontab.crontab -lShow crontab current information.
What can cron do?
Cron can run any command that can normally stand for itself in the command line. For example, you could program cron to run a java program at a certain interval (java main.java && java main).
Popular questions
- Why percent signs (%) do not work in crontab?
- cronjob does not execute a script that works fine standalone
- Variation for GUI applications: Cron job: how to run a script that requires to open display?
- CronJob not running
- Many common
cronproblems and general troubleshooting guidance
- Many common
- Why is my crontab not working, and how can I troubleshoot it? (canonical Q&A on serverfault.com)
Troubleshooting
There are several reasons for why a cron job wouldn't run as expected:
Using percent signs, as in
date +%FIncorrect timespec
Adding or omitting username, depending
Cron isn't running
Problems with syntax or permissions
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.
Percent signs may be useful to pass constant data to your command. A simple example:
59 23 * * * cat >$HOME/cron.out%foo%bar%baz
will create ~/cron.out with the 3 lines "foo", "bar", "baz".
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.)
See also the section about user names above; the syntax for the crontab owned by root is different from the syntax of the crontab of regular users.
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 foundor justfoo: 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.
