LUX 263 - Linux System Administration III

Lesson 3: Chapter 15, cron and anacron, pages 607 to 611

Objectives:

This lesson discusses scheduled events in Linux. Objectives important to this lesson:

1. What's cron?
2. crond daemon
   
3. crontab files
   
4. anacron and anacrontab files
   

Concepts:

Chapter 15, cron and anacron stuff

For those of you who are curious, we can presume that "cron" is a typical Linux/UNIX shortening of "chron-" as in chronometer (clock, watch) or Chronos (Greek mythology character representing time). In the word "crontab", we can believe this source that tells us "tab" stands for "table". So, crontab really means "time table". That may help a bit.

As you may know from trying it out in another class, the cron-related files, directories, and daemons have to do with scheduled events. It makes sense that we would want there to be a way to run commands and scripts on a schedule, since the point of a script is to automate a process and to make it reliably repeatable.

The text introduces the crond daemon on page 607. The d in its name is a common naming convention for daemons, which are processes that typically start on boot, but do not put much burden on your processor until they are called upon by a process, a command, or a script. So, if they are running in the background, not doing anything, why run them at all until we need them? One argument might be faster response, but in the case of crond, it keeps track of time, especially the passage of time, so it functions better if it is always running, like a good clock. If it is not running when the time for a scheduled event comes and goes, it will miss triggering that event. If we know that a server will be down from time to time (e.g. every night) the text recommends that we consider using anacron, a utility that looks for missed events that should be run as soon as possible.

If we are running crond, the daemon looks for system crontab (time table) files in the two locations listed at the bottom of page 607: /etc/cron.d (that's a directory name) and /etc/crontab, (that's a filename). It also looks for user crontab files in /var/spool/cron (that's also a directory). The text pauses at the top of page 608 to warn us that the word "crontab" has three meanings:

• it is the name of a list of scheduling rules, each of which specifies a task to run on a specific schedule
• it is the file that the list above is stored in
• it is the utility used to view, remove, or edit crontab files; you issue the command followed by -v, -r, or -e, respectively

(You may want to take a moment to imagine grabbing the geek who signed off on that and slapping him silly, as if he weren't already silly enough. Take a deep breath, count to ten, and we will continue.)

The text tells us that we have to format crontab commands so they match the graphic on the right, if they are going into a system crontab file. User crontab files do not have a specfied username field, because their commands are always run as the user the file belongs to. To understand the syntax, you need to know that each of the five numeric fields (indicated by their positions and by different colors in the graphic) represents a unit of time. You put values in as many of the fields as are needed to specify the rule you want to apply. Fields you do not need to use will have asterisks in them instead of values, so the computer ignores them. Numeric fields will accept ranges of values or single integers.

• The first two fields, reading from left to right, represent the minute and hour (respectively) when you want the event to occur. Note that the value for hour can be from 0 to 23, so it represents a time in 24 hour format. The 0 hour starts at midnight, and the 23rd hour starts at 11 PM.
• The third field is a day of the month. Make sure to specify a day that exists. For example, there is never a 31 in April or June. (Now, recite the poem. Pick a version that is actually correct.)
• The fourth field represents a month as a number from 1 to 12. Common numbering is used.
• The fifth field represents a day of the week. Note that Sunday can be represented as 0 or as 7. Days can also be represented by their three letter abbreviations (in English, anyway).
• In a user crontab file, the sixth field holds the command or script to run. In a system crontab, this field holds the name of the user who would be running the command or script, and the seventh field holds the command or script to run. A user crontab has no seventh field.

The text provides several examples to illustrate possible rules.

• In the middle of page 608, the first example has 20 in the first field, and 1 in the second field. There are asterisks in the other numeric fields. This means to run the command at the end of the line daily, at 1:20 AM, local time. It also specifies that the command should be run as root (in the sixth field). This is true for all the examples in this section.
  20 1 * * * root /usr/local/bin/checkit
  
  
• In the second example, the line reads like this:
  25 9 17 * * root /usr/local/bin/monthly.check
  This means to run at 9:25 AM, on the 17th of each month.
  
  
• The third example is shaped like the first one, but there is a difference:
  40 23 * * 7 root /usr/local/bin/sunday.check
  This means to run the sunday.check script as root, at 11:40 PM, every Sunday. The name of the file that is run does not control the day of the week. The 7 in the fifth numeric field does.
  
  
• The last example on page 608 shows a different notation:
  10/* * * * * root/ /usr/local/bin/tenmin.check
  The 10/* in the first field means to run every ten minutes. If this notation had been used in another field, it would have been about that field's time interval instead of minutes. The number 10 may be called a step value, meaning "do it every 10" in this case.
  This can also be accomplished by two more memorable notations, using */10 in the first field ("divisible by 10?"), or using a comma delimited list like this: 0,10,20,30,40,50
  
  
• In the first example on page 609, only the first numeric field is set, and its value is 01, meaning "run at the end of the first minute of every hour". The asterisks mean to do this every hour, day. month, and day of the week.
  01 * * * * root run-parts /etc/cron.hourly
  Technically, the first minute is 0, so this is the start of the second minute. The fields that follow the numeric fields in this example state that the user to run the command as would be root again, the command is a utility called run-parts, and the command is given a path to a directory as an argument.
  

You will find other examples on this blog page at thegeekstuff.com. That page also has links to other articles about cron and anacron. I recommend that you also read this article on tuxradar.com, for its insights into cron and anacron.

In case you aren't getting the lesson from this material, the embedded video below goes over some practical examples of setting up crontab commands.

The text changes topics to discuss the anacron utility. The example at the bottom of page 609 shows the contents of a 0anacron script, which is meant to be run to test two conditions before running anacron.

• The first major condition is tested in two steps. First, if the file /var/spool/anacron/cron.daily exists and is readable, this script reads it and assigns the contents to variable called day. (anacron writes the current date to this file every time it runs the cron.daily job, so if the file isn't there, there is no need to run the next test.) If we just put a date value in day, the script checks to see if it matches today's date. If it does, the script stops running.
• The second major condition tests whether the system is running on AC power. If it is not, the script stops running.

The text makes a good point about these tests: anacron will not run if it has already run on the current date, and it will not run unless the system is running on AC power (battery power is not acceptable).

Your text does not go into it, but the tuxradar article linked above and the geekstuff.com article at this web site explain the syntax for an anacrontab command. anacrontab syntax is different from crontab commands but it is similar enough to be confusing. anacrontab rules have four fields, based on the idea that this device has just been booted up:

• The first field is the period, expressed as a number of days. If you want a job run weekly, make the period 7. Daily would have a period of 1.
• The second field is the delay field, expressed as a number of minutes. Assuming we are going to run a job based on the value in the period field, the delay field specifies how many minutes to wait after this computer was turned on.
• The third field is the timestamp/job identifier, which is the timestamp file specific to this job, which was written the last time this job was run. It must be checked against the current date and the period in the first field.
• The fourth field is the command field, which holds either a command, the path to a script, or both.