Automating tasks: the system never sleeps
 

 
The cron daemon is a system service that runs scripts or single commands at a given interval. It is available to root and every user on the system. In addition to user-specified tasks, system tasks can be scheduled by running cron.
 
Pay attention to the man behind the curtain: Each user sets up a crontab file that specifies which jobs should be executed at a designated time. A crontab file contains instructions to the cron daemon in this format: run-this-command-at-this-time-on-this-date. Commands in any given crontab will be executed as the user who owns the crontab.
 

In the crontab, blank lines, leading spaces, and tabs are ignored. Lines whose first nonspace character is a hash mark (#) are read as comments and are ignored. Note that comments are not allowed on the same line as the cron command because they will be taken as part of the command. Similarly, comments are not allowed on the same line as environment variable settings.
 
An active line in a crontab will be either an environment setting or a cron command. An environment setting follows this format:
 

name = value 

# use /bin/sh to run commands, no matter what the login shell is 
SHELL=/bin/sh 

 

# run five minutes after midnight every day and ignore the output 
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1 

 

# Don't forget about the Bay Area Linux User Group meeting 
# every second thursday of the month 
0 10 8-14 * tue mail -s "BALUG meeting" $LOGNAME%BALUG meeting tonight at 7pm 

User crontabs are stored in /var/cron/tabs/ and are named after the user's login name. However, you should never edit these files directly. The command to edit, install, list, or delete a crontab is crontab. The crontabs can be edited by users, but only root is allowed to edit crontabs for other users. The command crontab follows the arguments shown in Table 8-2 .
 
 

In addition to individual user's crontabs, there is a central crontab for system administration. This crontab is stored in the file /etc/crontab. The syntax is almost the same as that for altering user crontabs. The only exception is that there is an additional column that allows root to specify with which user's permissions a job request will be issued. The name of the user belongs between the time/date fields and the command:
 

minute hour day-of-month month day-of-week user command 

As we've said,cronis a perfect tool to ease administrative tasks that need to be taken care of on a regular basis. SuSE has done a good job of providing a set of scripts for the most important tasks. All of these scripts are scheduled by the system crontab in /etc/crontab. SuSE also implemented an add-on mechanism that makes adding or removing jobs even easier.
 
This works with a subdirectory within /etc that sets scripts to be executed every hour, day, week, or month, as shown in Table 8-3 . Every script within these directories will be executed once in the specified time frame.
 
 

The file /etc/logfiles contains a list of various log files and their maximum size, permission levels, and ownership information. Each of these files will be reviewed. If a file's size is greater than the allowed maximum size, the file will be compressed and moved to a backup copy named filename-date.gz. If the permissions or the ownership is different than specified, this will be reconciled. A notice is sent to root if a backup copy has been made or if ownership or permission information has been revised.
 
You can add files to the list. Edit the file /etc/logfiles and add one line per file to be checked:

Filename maximum-size permissions owner.group 

If the value of MAX_DAYS_IN_TMP (also set in /etc/rc.config like all other variables mentioned in this section) is not zero, all files in the directories specified in TMP_DIRS_TO_CLEAR will be removed when they are older than the number of days specified. Files owned by users listed in OWNER_TO_KEEP_IN_TMP won't be removed.
 
This feature is disabled by default; (MAX_DAYS_IN_TMP is set to 0).
 
Old YaST log files will be removed after MAX_DAYS_FOR_LOG_FILES days has been reached.
 
Preformatted versions of man pages will be removed after the default period -- 7 days -- if DELETE_OLD_CATMAN is set to yes. The length of time that you can keep man pages can be modified simply by setting CATMAN_ATIME to the number of days you want to retain these files.
 

Some databases need to be updated on a regular basis. The database for the command locate andthe man page index are regenerated each day. This will be done only if RUN_UPDATEDB is yes. The locate database will contain information only about files in directories not listed in UPDATEDB_PRUNEPATHS. It will run as the user given in RUN_UPDATEDB_AS. By default, no NFS mounted directories will be included. However, if you like to have information about these directories, you can list them in UPDATEDB_NETPATHS.
 
The search will be done with the permissions of the user whose ID is listed in UPDATEDB_NETUSER.
 
All these variables are used to increase security. Because locate can be used by anyone on the system, you want to make sure that sensitive information is excluded from its database.
 
If the RPM database has changed since the last run, a backup will be created. If the original database is corrupted, this will allow you to recover data.
 

Core files are usually created when an application crashes. They can be used to debug the application because they represent a memory dump of the application at the moment of the crash.
 
But if you are not in the process of debugging the application, core files are almost useless. This is why all users receive a notice about core files they own. All core files older than MAX_DAYS_FOR_CORE are reported to the user. They will automatically be deleted when172 DELETE_OLD_CORE is set to yes.
 

If possible, the system checks the life of the battery that keeps the CMOS fresh when the system is turned off. A warning will be sent to root if a problem has been detected.

 
If the file /root/bin/cron.daily.local exists, it will be executed right after aaa_base is done. You can add your own cleanup or maintenance routines here.
 
This script is executed daily, usually at night. If you turn your machine off overnight, it'll be run shortly after you reboot.
 

If you have some system-wide task you need to set to run every hour, day, week, or month, simply write a script to perform the task and put it in the appropriate directory, as shown in Table 8-3.
 
For user-specific tasks, implement user crontabs such as those described previously.
 

After cron, next in importance is at, another service that schedules jobs at a given time. The difference is that cron executes jobs repeatedly, whereas at executes them once and at a specified time.
 
The at service allows fairly complex time specifications. It accepts times formatted as HH:MM (two-digit hour specification, followed by a colon and a two-digit minute specification) to run a job at a specific time of day. (If that time is already past, it is assumed that the job is to be run the following day.) You may also specify midnight, noon, or tea time (4 p.m.), and you can have a time-of-day suffixed with AM or PM for running in the morning or the evening. You can also state what day the job will be run by giving a date in the form month-name day with an optional year, or giving the date in the form MMDDYY, or MM/DD/YY, or DD.MM.YY. When specifying the date, you must follow by specifying the time-of-day. You can also give times such as now +count time-units, where the time-units can be minutes, hours, days, or weeks. You can tell at to run the job today by suffixing the time with today and run the job tomorrow by suffixing the time with tomorrow.
 
For example, to run a job at 4 p.m. three days from now, you would enter:
 

at 4pm + 3 days 

at 10am Jul 31 

at 1am tomorrow 

at 6am tomorrow 
at> echo "Hi, you want coffee?" | mail -s "Coffee?" boss@work.com