The UNIX cron Daemon

In UNIX the need for periodic program execution is a real demand. Primarily, it is a good idea to try to automate many administrative tasks, enabling their automatic periodic executions. A typical example is an unattended backup, which usually occurs at night, outside of normal business hours. Automation offers many advantages over performing the same tasks manually from the command line, such as: Greater reliability — Tasks are performed the same way every time. Correct and complete performance is guaranteed by the fact that the very same program has already been run a number of times without any problems. • Guaranteed regularity — Tasks can be performed according to whatever schedule seems appropriate and need not depend on anyones availability presence. • Enhanced system efficiency — Time−consuming or resource−intensive tasks can be performed during off−hours. • In UNIX, automation is accomplished via shell scripts and by the cron daemon.

13.2.1 The UNIX cron Daemon

Periodic program execution is provided by the UNIX cron facility, serviced by the cron daemon also known as the clock daemon. The cron daemon actually handles all jobs scheduled for time−specific, periodic executions. Periodic program executions are specified by crontab entries, which are stored in the systems cron schedule files. Programs scheduled to be executed at a specific time, or simply at any convenient time, are identified by the spooled jobs in the cron spooling directory. The cron daemon checks for time−scheduled jobs and acts accordingly. A typical rc sequence to start the cron daemon during the system startup is: Checking for already running cron daemon pid= usrbinps −e | usrbingrep cron | usrbinsed −e s −e s . case 1 in start if [ {pid} = ] then usrbinrm −f etccron.dFIFO if [ −x usrsbincron ] then usrsbincron fi fi ;; and so on ... If the cron daemon is not already running, it will be started by a preventive housekeeping facility. The only condition is that the corresponding executable program usrsbincron exists, which it always does. The cron daemon must be configured; appropriate configuration is actually required only for jobs scheduled for periodic execution. For jobs scheduled for a single execution, there is no need for any administration; they should simply be submitted into corresponding queues for execution. 307 On System V platforms but also on SunOS, any user may add her own entries to the cron schedule. The entries known as crontab entries are stored in separate files for each of the users, in the directory usrspoolcroncrontabs or varspoolcroncrontabs; users crontab files are named by the user login names including roots. For example, on SunOS 4.3.1: ls −C varspoolcroncrontabs baldwin levi pam root On Solaris 2.6: ls −C usrspoolcroncrontabs espinosa informix lp oracle root sybase On HP−UX 10.20: ls −C usrspoolcroncrontabs informix opgarpac root rscala These examples show how easy it is to recognize users personal crontab files. On System V, the configuration variable CRONLOG should be set to YES in the etcdefaultcron file to keep a log of the cron activity. From the SVR4 release on, the common location for the log file is usrsbincron.dlog in the past it was the file usrlibcronlog. Logging is automatic in BSD, and there is no CRONLOG variable. A frequent way to use the cron facility for regular administrative tasks is through a series of scripts designed to run periodically: every night, once a week, orand once a month. For example, one scenario for daily, weekly, and monthly scripts could be: Daily: Remove junk files, more than three days old, from the tmp directory ♦ Run accounting summary commands if accounting is enabled on the system ♦ Run calendar ♦ Rotate log files cycled daily ♦ Take a snapshot of the system with the df and ps commands ♦ Perform a daily security monitoring ♦ • Weekly: Remove old junk files ♦ Rotate log files cycled weekly ♦ Rebuild the manual page database ♦ Run fsck −n to list any disk problems ♦ • Monthly: • 308 Produce monthly accounting reports if accounting is enabled on the system ♦ Rotate log files cycled monthly ♦ Additional site−dependent activities may be taken into consideration on any particular system. The cron facility can also be used for periodic time−limited tasks. Once the desired period expires, the crontabs entry can be disabled or removed; the cron daemon must be reconfigured for a new job schedule. Unfortunately, this must be done manually, because crontabs entries are inclusive multiple specified conditions work like an OR function, not an AND function. The use of the cron facility can be restricted on a per−user basis. Two administrative files in the directory usrlibcron on some platforms, such as Solaris 2.x, the directory is etccron.d named cron.allow and cron.deny are available to explicitly define users who can or cannot schedule cron−jobs. These files function in the same way as other time−related jobs, and a detailed description can be found in the following text.

13.2.2 The crontab Files