cron and crontab: some classics are timeless

• cron and crontab: some classics are timeless

Quite often we, as computer users, need to schedule applications or jobs to take place at a given time. Backups typically happen at night, virus scans might happen after dinner, system updates might take place first thing in the morning. It's often useful to have routine tasks performed automatically and at a time when we're not sitting in front of the machine. This week we're going to cover the cron daemon and demonstrate how it can be used to quickly set up periodic tasks.

What does cron do? Well, once a minute the cron daemon checks the file /etc/crontab to see if any tasks are scheduled and, if it finds an applicable task, it runs a given program. The /etc/crontab file is a text file which we can open and examine in any text editor. Let's break down the information fields we will find in that file.

Typically a crontab file will contain two or more lines setting variables. Usually we will see a line setting the path to a shell and another listing the paths where cron can find executable files. These may look like the following:

   SHELL=/bin/sh
   PATH=/sbin:/bin:/usr/sbin:/usr/bin

Following these variables we will find lines specifying times and tasks to be run at those times. Let's look at an example of one of these scheduled tasks:

    15 * * * * root logrotate

The first five fields of the line are made up of numbers or stars. These fields represent a given point (or points) in time to let us know when the task will be run. From left to right the fields indicate the minute, hour, day of the month, month and day of the week when a task is to be run. Stars effectively mean "any" or "every". The sixth column indicates which user account will be used to run the task and the final field is the command to be run. In the above example we will run the logrotate command as the root user. This will happen 15 minutes into every hour of every day of every month, on every day of the week. In the following example we will run a backup script as the root user at noon on every Sunday:

   0 12 * * * 0 root my-backup-script

As you can see, we've set the minute field to zero, the hour to twelve (noon) and the day of the week to zero (Sunday). Cron associates Sunday with zero, Monday with one... through to Saturday which is six. Here is another example where we perform a clean-up of the /tmp directory at 6:30pm every evening from Monday through Friday. The dash character allows us to specify a range:

  30 18 * * 1-5 root rm -rf /tmp/*

On most Linux systems it's not just the root user who can schedule tasks, regular user accounts can create their own cron jobs. These user-scheduled tasks are kept separate from the /etc/crontab jobs and can be accessed by running the command:

    crontab -e

The crontab command will open a text editor and allow us to create tasks specific to our account. The main difference between the user-specific schedules and the /etc/crontab file is that the user-specific schedules do not include a username. For example, the following entry in my crontab file will perform a backup of my Documents directory at 5:00am on the first day of each month:

    0 5 1 * * tar czf ~/mybackup.tar.gz ~/Documents

Should we wish to see all of the jobs we have scheduled in our cron file we can run

   crontab -l

to get a complete list. Lastly, we can remove all of our user's scheduled tasks by running:

   crontab -r

The cron program is a very flexible and powerful tool which can be used to automate processes and is particularly good for scheduling backups and system clean-ups. It's a very handy utility to know.

Article first publiced at https://distrowatch.com/weekly.php?issue=20120416&mode=68#qa

Comments

[Thomas H Jones II]

Even better are /etc/cron.d files. Much better for environments using centralized configuration-management. With per-task crontab-files, you don't have to worry about multiple things needing to modify the monolithic/centralized crontab file.

[Dimitris Tzemos]

I agree. I use /etc/cron.hourly /etc/cron.daily to set up automate processes for my slackware system. I found this article useful in distrowatch.com. This article explain what is crontab, for educational purposes.

[Thomas H Jones II]

Heh... I'm too much of a control-freak to like using files in /etc/cron.<time-span>/. Using /etc/cron.hourly is fine, but as you move on to /etc/cron.<daily|weekly|monthly> the scheduling-control just feels to indefinite. I mean, I'm not even super fond of the Jenkins-scheduler's H option.

That said, for some tasks that I dump into /etc/cron.d/<service>, those scripts have backoff-randomizers to help avoid concurrency-related load-spikes that having a bunch of systems on the same schedule can cause. Doesn't feel great, but, sometimes you have to make concessions to resource-limitations.

[Rakesh Jain]

Any thoughts on using redirection operators at the end of any crontab entry to ignore the errors and ouputs in case of running the backup scripts on NFS shares as part of crontab ..