107.2 Lesson 1

In Linux, cron is a daemon that runs continuously and wakes up every minute to check a set of tables to find tasks to execute. These tables are known as crontabs and contain the so-called cron jobs. Cron is suitable for servers and systems that are constantly powered on, because each cron job is executed only if the system is running at the scheduled time. It can be used by ordinary users, each of whom has their own crontab, as well as the root user who manages the system crontabs.

User crontabs are text files that manage the sheduling of user-defined cron jobs. They are always named after the user account that created them, but the location of these files depends on the distribution used (generally a subdirectory of /var/spool/cron).

Each line in a user crontab contains six fields separated by a space:

For the month of the year and the day of the week you can use the first three letters of the name instead of the corresponding number.

The first five fields indicate when to execute the command that is specified in the sixth field, and they can contain one or more values. In particular, you can specify multiple values using:

Many distributions include the /etc/crontab file which can be used as a reference for the layout of a cron file. Here is an example /etc/crontab file from a Debian installation:

System crontabs are text files that manage the scheduling of system cron jobs and can only be edited by the root user. /etc/crontab and all files in the /etc/cron.d directory are system crontabs.

Most distributions also include the /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly direcrories that contain scripts to be run with the appropriate frequency. For example, if you want to run a script daily you can place it in /etc/cron.daily.

The syntax of system crontabs is similar to that of user crontabs, however it also requires an additional mandatory field that specifies which user will run the cron job. Therefore, each line in a system crontab contains seven fields separated by a space:

As for user crontabs, you can specify multiple values for the time fields using the *, , , - and / operators. You may also indicate the month of the year and the day of the week with the first three letters of the name instead of the corresponding number.

When editing crontab files, you can also use special shortcuts in the first five columns instead of the time specifications:

Within a crontab file, there are sometimes variable assignments defined before the scheduled tasks are declared. The environment variables commonly set are:

The crontab command is used to maintain crontab files for individual users. In particular, you can run the crontab -e command to edit your own crontab file or to create one if it doesn’t already exist.

By default, the crontab command opens the editor specified by the VISUAL or EDITOR environment variables so you can start editing your crontab file with the preferred editor. Some distributions, as shown in the example above, allow you to choose the editor from a list when crontab is run for the first time.

If you want to run the foo.sh script located in your home directory every day at 10:00 am, you can add the following line to your crontab file:

Consider the following sample crontab entries:

In the first line the bar.sh script is executed every Tuesday at 08:00 am, at 08:15 am, at 08:30 am and at 08:45 am. On the second line the foobar.sh script is executed at 08:30 pm from Monday to Friday for the first fifteen days of January and June.

In addition to the -e option mentioned above, the crontab command has other useful options:

Unlike user crontabs, system crontabs are updated using an editor: therefore, you do not need to run the crontab command to edit /etc/crontab and the files in /etc/cron.d. Remember that when editing system crontabs, you must specify the account that will be used to run the cron job (usually the root user).

For example, if you want to run the barfoo.sh script located in the /root directory every day at 01:30 am, you can open /etc/crontab with your preferred editor and add the following line:

In the above example, output of the job is appended to /root/output.log, while errors are appended to /root/error.log.

In Linux the /etc/cron.allow and /etc/cron.deny files are used to set crontab restrictions. In particular, they are used to allow or disallow the scheduling of cron jobs for different users. If /etc/cron.allow exists, only non-root users listed within it can schedule cron jobs using the crontab command. If /etc/cron.allow does not exist but /etc/cron.deny exists, only non-root users listed within this file cannot schedule cron jobs using the crontab command (in this case an empty /etc/cron.deny means that each user is allowed to schedule cron jobs with crontab). If neither of these files exist, the user’s access to cron job scheduling depends on the distribution used.

Using systemd as the system and service manager, you can set timers as an alternative to cron to schedule your tasks. Timers are systemd unit files identified by the .timer suffix, and for each of these there must be a corresponding unit file which describes the unit to be activated when the timer elapses. By default, a timer activates a service with the same name, except for the suffix.

A timer includes a [Timer] section that specifies when scheduled jobs should run. Specifically, you can use the OnCalendar= option to define real-time timers which work in the same way as cron jobs (they are based on calendar event expressions). The OnCalendar= option requires the following syntax:

with DayOfWeek being optional. The *, / and , operators have the same meaning as those used for cron jobs, while you can use .. between two values to indicate a contiguous range. For DayOfWeek specification, you can use the first three letters of the name or the full name.

For example, if you want to run the service named /etc/systemd/system/foobar.service at 05:30 on the first Monday of each month, you can add the following lines in the corresponding /etc/systemd/system/foobar.timer unit file.

Once you have created the new timer, you can enable it and start it by running the following commands as root:

You can change the frequency of your scheduled job, modifying the OnCalendar value and then typing the systemctl daemon-reload command.

Finally, if you want to view the list of active timers sorted by the time they elapse next, you can use the systemctl list-timers command. You can add the --all option to see the inactive timer units as well.

Instead of the longer normalized form mentioned above, you can use some special expressions which describe particular frequencies for job execution:

You can see the manual pages for the full list of time and date specifications at systemd.timer(5).