Core System Services - CRITICAL SKILL 9.4 Learn How to Use the cron Program (Page 5 of 5 )
The cron program allows any user in the system to schedule a program to run on any date, at any time, or on a particular day of week, down to the minute. Using cron is an extremely efficient way to automate your system, generate reports on a regular basis, and perform other periodic chores. (Not-so-honest uses of cron include having it invoke a system to have you paged when you want to get out of a meeting!)
Like the other services we’ve discussed in this module, cron is started by the boot scripts and is most likely already configured for you. A quick check of the process listing should show it quietly running in the background:
[root@ford /root]# ps auxw | grep cron | grep -v grep
root 341 0.0 0.0 1284 112 ? S Jun21 0:00 crond
[root@ford /root]#
The cron service works by waking up once a minute and checking each user’s crontab file. This file contains the user’s list of events that they want executed at a particular date and time. Any events that match the current date and time are executed.
The crond command itself requires no command-line parameters or special signals to indicate a change in status.
The crontab File The tool that allows you to edit entries to be executed by crond is crontab. Essentially, all it does is verify your permission to modify your cron settings and then invoke a text editor so you can make your changes. Once you’re done, crontab places the file in the right location and brings you back to a prompt.
Whether or not you have appropriate permission is determined by crontab by checking the /etc/cron.allow and /etc/cron.deny files. If either of these files exists, you must be explicitly listed there for your actions to be effected. For example, if the /etc/cron.allow file exists, your username must be listed in that file in order for you to be able to edit your cron entries. On the other hand, if the only file that exists is /etc/cron.deny, unless your username is listed there, you are implicitly allowed to edit your cron settings.
The file listing your cron jobs (often referred to as the crontab file) is formatted as follows. All values must be listed as integers.
Minute Hour Day Month DayOfWeek Command
If you want to have multiple entries for a particular column (for instance, you want a program to run at 4:00 A.M., 12:00 P.M., and 5:00 P.M.), then you need to have each of these time values in a comma-separated list. Be sure not to type any spaces in the list. For the program running at 4:00 A.M., 12:00 P.M., and 5:00 P.M., the Hour values list would read 4, 12, 17. Newer versions of cron allow you to use a shorter notation for supplying fields. For example if you want to run a process every two minutes, you just need to put /2 as the first entry. Notice that cron uses military time format.
For the DayOfWeek entry, 0 represents Sunday, 1 represents Monday, and so on, all the way to 6 representing Saturday.
Any entry that has a single asterisk (*) wildcard will match any minute, hour, day, month, or day of week when used in the corresponding column.
When the dates and times in the file match the current date and time, the command is run as the user who set the crontab. Any output generated is e-mailed back to the user. Obviously, this can result in a mailbox full of messages, so it is important to be thrifty with your reporting. A good way to keep a handle on volume is to output only error conditions and have any unavoidable output sent to /dev/null.
Let’s look at some examples. The following entry runs the program /usr/bin/ping -c 5 zaphod every four hours:
0 0,4,8,12,16,20 * * * /usr/bin/ping -c 5 zaphod
or using the shorthand method:
0 */4 * * * /usr/bin/ping -c 5 zaphod
Here is an entry that runs the program
/usr/local/scripts/backup_level_0 at 10:00 P.M.every Friday night:
0 22 * * 5 /usr/local/scripts/backup_level_0
And finally, here’s a script to send out an e-mail at 4:01 A.M. on April 1 (whatever day that may be):
1 4 1 4 * /bin/mail dad@domain.com < /home/sshah/joke
NOTE
When crond executes commands, it does so with the sh shell. Thus, any environment variables that you might be used to may not work within cron.
Edit the crontab File
Now that you know the format of the crontab configuration file you need to edit the file. You don’t do this by editing the file directly; you use the crontab command to edit your crontab:
[root@ford /root]# crontab -e
To list what is in your current crontab file just give crontab the -l argument to concatenate the file to your terminal.
- What process has the process ID of 1?
- What is the /etc/inittab file used for?
- What line would you change to make the system boot into runlevel 3 by default?
- What two commands could you issue to reboot the system?
- Why is it a bad idea to kill the init process?
- How would you let the xinetd server know you have changed the configuration file?
- Why would you not want to use inetd/xinetd for high-volume servers?
- What does the cron program do?
- How would you schedule the script /root/scripts/foo.sh to run every five minutes every day of the month using cron?
- How would a user modify his or her crontab file?
- What file is used by cron for the system-wide crontab?
- What is syslog?
- Where is the configuration file for syslogd located?
- Why would you want to send syslog messages to another syslog server?
- Is syslog a reliable logging mechanism?
The telinit program allows you to switch runlevels and display which run level you are currently at.
The /etc/inittab file tells init what to do at each run level.
init is the master process. It is the first process spawned after the kernel is booted, and it is responsible for getting the system up and running.
xinetd is used to call upon network services only when needed.
TCP and UDP network services such as Telnet and Finger.
/ 10 
