Lesson 3: Chapter 15, cron and anacron, pages 607 to 611
This lesson discusses scheduled events in Linux. Objectives important
to this lesson:
anacron and anacrontab files
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
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 cronddaemon 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
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.)
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,
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. 201 * * * root /usr/local/bin/checkit
In the second example, the line reads like this: 25917 * * 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: 4023 * * 7root /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
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
The first major condition is tested in two steps. First, if
the file /var/spool/anacron/cron.dailyexists 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.
As an example, an anacrontab line might look like this:
10 30 test.tenday tenday.report
This rule would check the date stored in the test.tenday file. If it has been 10 days since that date, the tenday.report script would be run when 30 minutes have passed since this computer was turned on.
Week 3 Assignments:
Assignment 1, Exercises from chapter 15:
Write a crontab rule that would run at 5:30 PM, on a day near
the end of each month. It should run as root, and should run a
script called cron.monthly, stored in the root of the etc folder.
Write a crontab rule that would run every five minutes on Tuesdays
in April. It should run a script called waste.of.time in the etc
folder. It should run the script with your Baker ID.
Write a different crontab rule that uses at least three fields.
Submit the rule and explain what it does.
In the link above to the poem, there are 91 versions
of the days of the months poem. Several are whimsical, and most
are close to the truth. On a quick scan, I found one and
only one that is actually correct. Which is it? Provide
a link to a site that documents the truth of your answer.
Assignment 2, Lab for cron
Write a crontab file for your server. Make it call a script
that you anticipate running at a certain time each day. (This
may be an empty file for now, but it should actually exist on
Submit copies of the two files mentioned above, and a description
of what the crontab file does, as well as a description of what
you anticipate having in the daily file.