Cron is a powerful job scheduler for GNU/Linux and many other operating systems. It automates recurring tasks by executing commands at a given time. It has a wide range of potential applications; most simple recurring tasks, from backups to e-mail retrieval, can be automated using cron, saving users time and headaches.
There are multiple cron implementations available from which users may choose. Template:Package Official is available in [core] and is installed as part of the base group, you can check it is correctly installed with:
# pacman -S --needed cronie
Until May 2011, the default cron implementation for Arch Linux was Template:Package Official (Dillon's Cron), which anyway is still supported and available in [extra]:
# pacman -S dcron
Alternatively, users may wish to install Template:Package Official from [community] or Template:Package AUR or Template:Package AUR from the AUR; all offer a wider range of features and configuration options.
The Gentoo Linux Cron Guide offers a comparison between these implementations.
Users & autostart
Cron should work "out-of-the-box" for most Arch Linux users. In order to use crontab, users must be members of a designated group, but in Arch Linux, that group is users, of which all users should already be members. If for whatever reason some users are not members of this group, they can be added to it with the command:
# gpasswd -a username users
and they should then be able to edit their own crontabs.
Handling errors of jobs
Errors can occur during execution of jobs. When this happens cron register stderr output of job as e-mail and try to send it by default via sendmail command. To log this message you can use -M option of crontd and write you own script or install rudimentary SMTP subsystem (esmtp in this example):
# pacman -S esmtp procmail
After installation create file Template:Filename with this content:
identity email@example.com hostname mail.myisp.com:25 username "myself" password "secret" starttls enabled default mda "/usr/bin/procmail -d %T"
Procmail needs root privileges to work in delivery mode but it is not an issue if you are running the cronjobs as root.
To test that everything works correctly, create a file Template:Filename with "test message" in it.
From the directory containing Template:Filename run:
$ sendmail user_name < message.txt
$ cat /var/spool/mail/user_name
You should see in the terminal, the "test message", the time and date it was sent.
Thats all, all error output of jobs now will be redirected to Template:Filename.
Due to the privileged issue, it is hard to create and send the email to root. So you could ask esmtp to forward all root's email to some ordinary users. Add the following lines in esmtprc
Run the following command to make sure it has the correct 710 permission:
$ chmod 710 ~/.esmtprc
Now just repeat the test with Template:Filename exactly as before.
The basic format for a crontab is:
<minute> <hour> <day_of_month> <month> <day_of_week> <command>
- minute values can be from 0 to 59.
- hour values can be from 0 to 23.
- day_of_month values can be from 1 to 31.
- month values can be from 1 to 12.
- day_of_week values can be from 0 to 6, with 0 denoting Sunday.
Multiple times may be specified with a comma, a range can be given with a hyphen, and the asterisk symbol is a wildcard character. Spaces are used to separate fields. For example, the line:
*0,*5 9-16 * 1-5,9-12 1-5 /home/user/bin/i_love_cron.sh
Will execute the script Template:Codeline at five minute intervals from 9 AM to 4:55 PM every weekday of the month except during the summer months (June, July, and August). More examples and advanced configuration techniques can be found below.
Crontabs should never be edited directly; instead, users should use the crontab program to work with their crontabs. To be granted access to this command, user must be a member of the users group (see gpasswd command).
To view their crontabs, users should issue the command:
$ crontab -l
To edit their crontabs, they may use:
$ crontab -e
To remove their crontabs, they should use:
$ crontab -d
If a user has a saved crontab and would like to completely overwrite their old crontab, he or she should use:
$ crontab saved_crontab_filename
To overwrite a crontab from the command line (Wikipedia:stdin), use
$ crontab -
To edit somebody else's crontab, issue the following command as root:
# crontab -u username -e
This same format (appending "-u username" to a command) works for listing and deleting crontabs as well.
To use nano rather than vi as crontab editor, add the following lines to /etc/bash.bashrc:
And restart terminal/s
01 * * * * /bin/echo Hello, world!
runs the command Template:Codeline on the first minute of every hour of every day of every month (i.e. at 12:01, 1:01, 2:01, etc.)
*/5 * * jan mon-fri /bin/echo Hello, world!
runs the same job every five minutes on weekdays during the month of January (i.e. at 12:00, 12:05, 12:10, etc.)
As noted in the Crontab Format section, the line:
*0,*5 9-16 * 1-5,9-12 1-5 /home/user/bin/i_love_cron.sh
Will execute the script Template:Codeline at five minute intervals from 9 AM to 5 PM (excluding 5 PM itself) every weekday (Mon-Fri) of every month except during the summer (June, July, and August).
The cron daemon parses a configuration file known as crontab. Each user on the system can maintain a separate crontab file to schedule commands individually. The root user's crontab is used to schedule system-wide tasks (though users may opt to use Template:Filename or the Template:Filename directory, depending on which cron implementation they choose).
There are slight differences between the crontab formats of the different cron daemons. The default root crontab for dcron looks like this:
These lines exemplify one of the formats that crontab entries can have, namely whitespace-separated fields specifying:
- ID=jobname (this tag is specific to dcron)
The other standard format for crontab entries is:
- day of week
See the crontab man page for further information and configuration examples, dcron's manpages are available hereTemplate:Linkrot and this (note: yacron removed from repos?) forum post has lots of info.
cronie use run-parts to carry out script in cron.daily/cron.week.y/cron.montly. Be carefull that the script name in these folders should not have any '.', like backup.sh. Since run-parts without options will ignore them. Detail information see man run-parts.
Running X apps
If you find that you cannot run X apps from cron jobs then put this before the command:
export DISPLAY=:0.0 ;
That sets the DISPLAY variable to the first display; which is usually right unless you like to run multiple xservers on your machine.
If it still does not work then you need to use xhost to give your user control over X11:
# xhost +si:localuser:$(whoami)
I put it in my gnome `Startup Applications' like this:
bash -c "xhost +si:localuser:$(whoami)"
Asynchronous job processing
If you regularly turn off your computer but do not want to miss jobs, there are some solutions available (easiest to hardest):
- Vanilla dcron (the default cron daemon in Arch) now supports asynchronous job processing. Just put it with @hourly, @daily, @weekly or @monthy with a jobname, like this:
@hourly ID=greatest_ever_job echo This job is very useful.