Tuesday, March 16, 2010

What are cron and crontab and how to use them.

In Unix (POSIX.1-2008) or *nix systems cron is a deamon that, has its name suggests, has to do with time. More precisely it takes care of scheduling operations which must be carried out by the system at certain periods.

crontab is a text file containing a list of tasks to be executed at proper times. Both the commands and the times are specified inside the crontab file.

Each user has its own crontab files and there’s also a system crontab which takes care of scheduling system tasks as, for example, the log rotation we spoke in an previous article.

To use crontab the user name should normally be included in the crontab.allow file or, if such file doesn’t exist, then the user name must not be included in the crontab.deny file. If this file exist and it’s empty then usage of crontab is allowed to everybody without restrictions. cronttab.allow and crontab.deny files contain a list of user name and each name must occupy a line. Such policies and standard implementations can vary depending on the *nix system your using. For what concerns Ubuntu and Debian, these files are located in /etc/ directory.

Under the /etc/ directory there are commonly subdirectories and, among these, you should see also /etc/cron.hourly/  /etc/cron.daily/ /etc/cron.weekly/ and so on. If you have a script you want to run with a constant defined periodicity you can just copy it inside one of these directories and you will have it run respectively each hour, each day and each week. This is an approach that is related to an implementation of cron called anacron

However crontab allows much more flexibility for what concerns scheduling and to do so it necessary to edit (or even creating from scratch) the crontab file.

To write a crontab file just open it with your favorite text editor or type crontab –e to open it with the default editor (specified in the environment variable “EDITOR” – see the env command in bash).

When you open the file you will face something like this:

















Note: Don't necessarly expect to find a crontab already filled with commands. It could very possibly be (and it's the case with Ubuntu) that your crontab it's blank and infact you'll be creating it from new as soon as you launch the crontab -e command from the terminal.

Each entry consists of a line with six items separated blank spaces. The first five field must be filled by integers that specify the schedule. The sixth field is a string to be executed by the shell.

Here below you can see a diagram of a crontab line

As you can see by selecting the proper values you can compose any type of schedule you need.
There are also special character that can be used instead of or together with the integers.

[*] Asterisk – The asterisk is for every value. Therefore to put an * in the hour field would mean that the command should be scheduled to run every hour.

[,] Comma – The comma character is used to run a command more than one time within a specific range of time. By writing 1, 15 in the hour field it means that the command will run at 1 A.M. and 3 P.M.

[-] Dash – The dash character specifies an inclusive range and it’s used to run a command continuously with a certain period of time. Specify 1-32 in the minute field to run a command continuously for 32 minutes.

Please note that a certain date can be specified either with Day of the Month field and Day of the Week field. Just pay attention to this situation in order to avoid weird behavior to occur. For example if you want to run a command the 5th day of each month, mark the DoW field with an asterisk so that the command can run at the specific day disregarding which day of the week it is.

We said before that every entry correspond to one line. However blank lines and lines that begins with # are ignored.

There are a bunch of environment variables that can affect the behavior of cron. The most common are EDITOR, LANG, LC_ALL, LC_TYPE, LC_MESSAGE, NLSPATH, LC_MESSAGES. These concern mostly advanced configuration so the default values should be ok unless you want to change the default editor with your favorite one.

A particular mention is to the variable DISPLAY which defines the default display. This information can be used to use cron to run graphical applications by specifying which display must show the application. This can be made by writing something like the following:

* 20 * * * env DISPLAY=:0 /usr/bin/evolution

By doing this you will tell cron to run Evolution mail client every day at 8 pm on the default display.

Note: if you’re a Ubuntu user, there’s a workaround to be applied in order to make this working in Karmic Koala. Please refer to the Ubuntu official documentation.

Before finishing the article let’s have a look at the most common errors you can encounter while hacking with crontab. Please note that modifications to crontab and the command excuted from its schedule, are logged in /var/log/syslog. If you spot a malfunctioning in your schedule try to check this log to acquire precious information.

- Every crontab file must end with a newline. If you create add an entry to an existing crontab file (or you create a new one) and you forget the newline, your job will never be run.

- As a corollary of the above, note that the % character in the sixth field will be considered a newline. Any character preceded by a \ will be escaped and therefore treated literelly.

- Lines that begins with # or blank lines are ignored

- If you add a user to your crontab.allow list you must also somehow re-edit the crontab files because otherwise the user will not be allowed to execute jobs.

- In order to avoid weird behaviors or fails to execute jobs for certain users, take the precaution to specify the full path of the command to be executed.

- if you try to run a command that needs super user privileges with your user's crontab you will fail. To run something like chkrootkit, as in the example above, you must add the command to the system crontab. To do so type sudo crontab -e in a terminal and prompt the superuser password when prompted to do so.

Note that it’s not really a good idea to edit the system crontab in /etc/crontab not only because you could create possible damages but also because during the system updates you could find your jobs erased. Unless you have particular needs and you know what you’re doing and why you’re doing it, it’s much safer to edit the user crontab with crontab –e.

This is almost all the basic information about cron and crontab. I invite you to refer to the man pages for information.

Live long and prosper

No comments:

Post a Comment