Cron and crontab

The cron system is managed by the cron daemon. It gets information about which programs and when they should run from the system's and users' crontab entries. Only the root user has access to the system crontabs, while each user should only have access to his own crontabs. On some systems (some) users may not have access to the cron facility.

At system startup the cron daemon searches /var/spool/cron/ for crontab entries which are named after accounts in /etc/passwd, it searches /etc/cron.d/ and it searches /etc/crontab, then uses this information every minute to check if there is something to be done. It executes commands as the user who owns the crontab file and mails any output of commands to the owner.

On systems using Vixie cron, jobs that occur hourly, daily, weekly and monthly are kept in separate

directories in /etc to keep an overview, as opposed to the standard UNIX cron function, where all tasks are entered into one big file.

Example of a Vixie crontab file:

[root@blob /etc]# more crontab SHELL=/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root

HOME=/

# run-parts

# commands to execute every hour

01 * * * * root run-parts /etc/cron.hourly

# commands to execute every day

02 4 * * * root run-parts /etc/cron.daily

# commands to execute every week

22 4 * * 0 root run-parts /etc/cron.weekly commands to execute every month

42 4 1 * * root run-parts /etc/cron.monthly

Alternative

You could also use the crontab -l command to display crontabs.

Some variables are set, and after that there's the actual scheduling, one line per job, starting with 5 time and date fields. The first field contains the minutes (from 0 to 59), the second defines the hour of execution (0-23), the third is day of the month (1-31), then the number of the month (1-12), the last is day of the week (0-7, both 0 and 7 are Sunday). An asterisk in these fields represents the total acceptable range for the field. Lists are allowed; to execute a job from Monday to Friday enter 1-5 in the last field, to execute a job on Monday, Wednesday and Friday enter 1,3,5.

Then comes the user who should run the processes which are listed in the last column. The example above is from a Vixie cron configuration where root runs the program run-parts on regular intervals, with the

appropriate directories as options. In these directories, the actual jobs to be executed at the scheduled time are stored as shell scripts, like this little script that is run daily to update the database used by the locate

command:

billy@ahost cron.daily]$ cat slocate.cron

#!/bin/sh

renice +19 -p $$ >/dev/null 2>&1

/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e \

"/tmp,/var/tmp, /usr/tmp,/afs,/net"

Users are supposed to edit their crontabs in a safe way using the crontab -e command. This will prevent a user from accidentally opening more than one copy of his/her crontab file. The default editor is vi (see Chapter 6, but you can use any text editor, such as gvim or gedit if you feel more comfortable with a GUI editor.

When you quit, the system will tell you that a new crontab is installed.

This crontab entry reminds billy to go to his sports club every Thursday night:

billy:~> crontab -l

# DO NOT EDIT THIS FILE - edit the master and reinstall.

# (/tmp/crontab.20264 installed on Sun Jul 20 22:35:14 2003)

# (Cron version -- $Id: chap4.xml,v 1.28 2007/09/19 12:22:26 tille Exp $) 38 16 * * 3 mail -s "sports evening" billy

After adding a new scheduled task, the system will tell you that a new crontab is installed. You do not need to restart the cron daemon for the changes to take effect. In the example, billy added a new line pointing to a backup script:

billy:~> crontab -e

45 15 * * 3 mail -s "sports evening" billy 4 4 * * 4,7 /home/billy/bin/backup.sh

<--write and quit-->

crontab: installing new crontab billy:~>

The backup.sh script is executed every Thursday and Sunday. See Section 7.2.5 for an introduction to shell scripting. Keep in mind that output of commands, if any, is mailed to the owner of the crontab file. If no mail service is configured, you might find the output of your commands in your local mailbox,

/var/spool/mail/<your_username>, a plain text file.

Who runs my commands?

You don't have to specify the user who should run the commands. They are executed with the user's own permissions by default.

4.5. Summary

Linux is a multi-user, multi-tasking operating system that has a UNIX-like way of handling processes.

Execution speed of commands can depend on a thousand tiny things. Among others, we learned a lot of new commands to visualize and handle processes. Here's a list:

Table 4-3. New commands in chapter 4: Processes

Command Meaning

at Queue jobs for later execution.

atq Lists the user's pending jobs.

atrm Deletes jobs, determined by their job number.

batch Executes commands when system load level permits.

crontab Maintain crontab files for individual users.

halt Stop the system.

init run level Process control initialization.

jobs Lists currently executing jobs.

kill Terminate a process.

mesg Control write access to your terminal.

netstat Display network connections, routing tables, interface statistics, masquerade connections and multicast memberships.

nice Run a program with modified scheduling priority.

pgrep Display processes.

ps Report process status.

pstree Display a tree of processes.

reboot Stop the system.

renice Alter priority of running processes.

shutdown Bring the system down.

sleep Delay for a specified time.

time Time a command or report resource usage.

top Display top CPU processes.

uptime Show how long the system has been running.

vmstat Report virtual memory statistics.

w Show who is logged on and what they are doing.

wall Send a message to everybody's terminals.

who Show who is logged on.

write Send a message to another user.

4.6. Exercises

These are some exercises that will help you get the feel for processes running on your system.