crontab command, found in Unix and Unix-like operating systems, is used to schedule commands to be executed periodically.
crontab uses a daemon,
crond, which runs constantly in the background and checks once a minute to see if any of the scheduled jobs need to be executed. These jobs are generally referred to as cron jobs. Cron jobs run as the user who creates them, as though that user typed the command into their shell.
Only shell users can create cron jobs. For help setting up a shell user, see the Enabling Shell Access article.
Crontab file contents on the server
Due to the complex nature of translating user supplied content from the panel to the server, what you enter in to the panel is not what you see in the crontab file. The following example is a more complex cron job using a
The crontab file on the server then appears as follows:
###--- BEGIN DREAMHOST BLOCK ###--- Changes made to this part of the file WILL be destroyed! # Cron Process
MAILTO="firstname.lastname@example.org" */10 * * * * /usr/local/bin/setlock -n /tmp/cronlock.3788261262.173085 sh -c $'wget -q -O dev/null http\072//example.com/cron.php' ###--- You can make changes below the next line and they will be preserved! ###--- END DREAMHOST BLOCK
There are a couple of things worth noting:
- “http://” has been translated as “http\072//”. The “:” (colon) character is one of several special characters that need to be altered in to some other Unix-readable format in order to be successfully added to the crontab file. This is using octal notation (“\072” is the octal representation for “:”).
- When the 'Use locking' option is selected, the command(s) you want executed are filtered through a unique invocation of the setlock command.
View the setlock man page for further information. The use of setlock results in error messages if your cron job is invoked before the last iteration of the job releases your unique lockfile. This can happen if your script takes more time to run than the time between job executions.
- When testing your new cron job, set the 'When to run' time frame to run every 10 minutes. Also, make sure to set an email address for reporting the results. This gives you important information about what may be going wrong if the command line is not running the cron job as desired. When everything is running properly you can then adjust the 'When to run' value to anything you like.
- If you're planning to use external software with a cron job, make sure you have set 'write' and other permissions for the files in your remote folders. If you get an error message about "permission denied" it means your permissions are not set properly. Also specifying the full path of the file you’re writing to can prevent issues with the cron environment running from a different directory.
Dedicated server troubleshooting
It's rare that the cron service on a server may stop running. If you’re using a Dedicated server, you can verify that cron is running by running this shell command:
[server]$ ps aux | grep cron
You can also check the system log for entries labeled 'CRON'.
[server]$ sudo grep CRON /var/log/syslog
There is usually at least one CRON line per minute in the /var/log/syslog file. If you don’t see any recent entries then you may want to restart the cron service. To restart cron run this command under your Dedicated server's admin user:
[server]$ sudo service cron restart
- SSH overview
- Advanced technical details of a crontab
- Execution environment of a cron job
- How do I create a cron job?
- Ubuntu's cron man page
- Ubuntu's crontab(1) page
- Ubuntu's crontab(5) mange page
- Cron entry on Wikipedia
- Unix crontab - Full Reference at Freebsd.org
- Configuring cron jobs on DreamHost - Helpful article for people using Drupal CMS
- Crontab Command Examples in Unix
- Cron and Crontab usage and examples
- ArchLinux Wiki's Cron Entry