Linux with Operating System Concepts

filename
.
The atd daemon is responsible for determining when a scheduled event should execute. 
For a command scheduled with at, it executes at the time specified. For a command sched-
uled with batch, it executes when the system load drops below 80%. If you are working on 
a stand-alone workstation, chances are the load will usually be below 80%; so, batch could 
potentially run the scheduled event within the next minute.
The at command makes a note of the current shell. This is the value stored in the envi-
ronment variable 
SHELL
of the user submitting the command. This shell’s interpreter is 
utilized to execute the line(s) in the scheduled event. For instance, if you switch from bash 
to csh, issue an at command and then exit back to bash, the scheduled command when 
executed is executed using the csh interpreter rather than the bash interpreter.
The at command may or may not be set up to be used by normal users. You may find in 
your system that it can only be executed by root. Alternatively, the system administrator 
has access to two files to control who can use at: /
etc/at.allow
and /
etc/at.deny
. If 
you are defaulting to only allowing root to execute at commands, you can add individual 
users to the /etc/at.allow file to permit specific users to access at. Alternatively, if at can 
be used by every user, you can exclude specific users from using at by listing them in /
etc/at.deny.
14.3.2 The crontab Program
While at and batch are easy to use and very useful, they only permit one-time scheduling 
of events. The cron program is more useful because it schedules recurring events. But to 
use cron, the approach is significantly different from that of at/batch. The program that 
executes scheduled events is called 
crond
. The service is stored in /usr/sbin while the 
script to control the service is in /etc/init.d. To issue a scheduling command, you use the 
command 
crontab
.
Crontab requires that you specify a file that contains a list of events to schedule. Each 
listed event is in a row of the file by itself. The row indicates the times and dates that the 
event is to be executed and the event itself. The file can contain multiple times/events, one 
per row. The actual command will look like 
crontab 
filename
where 
filename
con-
tains the scheduling information.
Since each line must be self-contained, the event(s) scheduled will need to be limited 
in size to fit in one line. To avoid this restriction, you might want to place the individual 
commands in a script and then place the script name as the event to execute. In this way, 

---

582
◾
Linux with Operating System Concepts
you are free to express a much more detailed series of instructions that are not limited to 
one line in the text file.
For instance, if you wish to unmount a partition, backup that partition and then 
remount the partition, you would specify at least three commands. This would most likely 
not be appropriate for one line in the crontab file. You would move the operations to a shell 
script and then specify the script from the crontab file.
The crontab file must specify the recurrence for scheduling the event. This is where 
crontab becomes complicated. There are five specifiers for the time and date. These are 
indicated through the first five columns of the row. The format looks like this:
1 2 3 4 5 command
The values 1–5 specify, in order:
1. Minute of the hour (0–59)
2. Hour of the day (0–23, military time)
3. Day of the month (1–31 but make sure that the day matches the month if you use 29–31)
4. Month of the year (1–12)
5. Day of the week (0–7 where 0 means Sunday, 1–6 means Monday through Saturday, 
and 7 means Sunday again)
For any one of these five entries, you can use the wildcard * to indicate “every time.”
For instance,
30 12 15 * *
would define 12:30 p.m. on the 15th with month and day being “every.” This indicates 12:30 
p.m. on the 15th of every month.
You would usually not specify a date and month if you specify a particular day of the 
week. The entry
30 12 * * 0
represents every Sunday at 12:30 pm. If you instead use
30 12 15 * 0
you would be specifying every Sunday, the 15th, at 12:30 p.m. This latter pattern may only 
match a couple of days out of the year.
You can specify multiple occurrences within any of these five values by separating the 
values with commas. The list 
0,30
for the minute schedules the event for both on the hour 
and half past the hour. If you have specified 0 for the hour, the event would take place at 

---

Maintaining and Troubleshooting Linux
◾
583
both 12:00 a.m. and 12:30 a.m. Alternatively, if the event is to recur more often and you do 
not want to enumerate all of the times, you can use the notation /
x
to indicate the amount 
of time to elapse before the next recurrence.
Consider the following:
*/10 
0,12 
* 
* 
*
This indicates that the event would recur at 12:00 a.m., 12:10 a.m., 12:20 a.m., 12:30 a.m., 
12:40 a.m. and 12:50 a.m. and again at 12:00 p.m., 12:10 p.m., 12:20 p.m., 12:30 p.m., 12:40 
p.m., and 12:50 p.m.
Each user is able to submit a single crontab job. Any new submission will replace any 
earlier scheduled job for the user. To submit multiple events, you must therefore add them 
to the crontab file. Each line will be a separate event with its own scheduled time and 
recurrence.
What follows is an example of a crontab file that root might submit.
0 0 * * * ./backup 
/home
*/5 
* * * * ./intruder_alert
30 
0 15 
* * ./usage_report 
>>
disk_data.dat
15 
3 1 1 * ./end_of_year_statistics
Here, we see four different scheduled events, each event calling a fictional script. First, 
every night at midnight, the script 
backup
is executed, using /home as a parameter. Second, 
every 5 min of every day, the intruder_alert script is executed. Third, every 15th of the 
month at 12:30 a.m., the usage_report script executes, appending the output to the file 
disk_data.dat. Finally, at 3:15 a.m. on every January 1st, the script end_of_year_statistics 
is run.
If you would like to add more scheduled events, you could modify the submitted file 
and resubmit the file using crontab. Crontab would replace the old scheduled events with 
the ones in the new version of the file. To view the scheduled crontab event(s), the com-
mand is 
crontab –l
. This lists whatever you, as a user have scheduled.
To view what other users have scheduled, add 
–u