Extended Cron System by Geoff Kuenning Interrupt Technology Corporation This software is Copyright 1987, Interrupt Technology Corporation, Manhattan Beach, CA. Permission is granted to copy this software for private use, provided that this notice and all other copyright notices are preserved intact. All other rights reserved. This file is an extended README file, explaining why I wrote the extended cron system, what its features are, and why you might want to run it. For simple installation instructions without the advertising, see the README file. For instructions on how to use the daemon, see the man pages. RATIONALE The extended cron project began because I ran UNIX on a small desktop workstation which was sometimes shut off at night. The frequent 'off' periods meant that any overnight entries in crontab were unreliable. Because of the unpredictability of the 'off' times, I could not simply reschedule the 'overnight' stuff for daytime hours. So I set about writing a new cron daemon that knew what it had missed and could catch up on it. While at my task, I learned of the System V.2 concept of user crontabs, and decided that sounded pretty handy. I also learned that System V.2 cron also includes 'at' and 'batch'. I put in 'at', but batch was more of a problem. I have philosophical objections to putting such a thing in cron; just because cron is a queue manager is no excuse to hang unrelated queues off of it in a kludgey fashion. I put out a request on the net for batch daemons, and got back a very slick one, written by Ian Allen and Jim Barby at the University of Waterloo. I ported it to System V, and I have integrated it into cron's Configure script and Makefile so that it is even more painless to use than it was. Finally, somewhere along the way I got sick of trying to remember the order of cron's input fields and which were zero-indexed, and rewrote the table parser to accept a rational input format. WHY YOU WANT IT There are many reasons why you might want this software. Some of them are: - Your computer is not up all the time, and you want reliable cron operation. - You want user crontabs. - You want a version of 'at' that works reliably with minute resolution. - You want a good (or better) batch daemon. - You want a more readable crontab and a more reliable cron. FEATURES - "Catchup" mode that allows recovery of missed 'cron' tasks from while the machine was down (regardless of why it was down). - New human-readable crontab format. (Plus a script to convert your old crontab for you). - All System V.2 cron features, including user crontabs, at and batch, allow/deny files, and security. - Numerous improvements compared to System V.2 cron, including significantly improved error messages and the '-u' switch to crontab. - Tellcron program to allow the superuser to control and communicate with cron. - 'Userlimits' file to provide control over the loads various users can place on cron. - 'Rn'-style automated configuration/conversion/installation. - Lower CPU load on system (but it takes more memory, alas). INCOMPATIBILITIES - Upwardly compatible (using conversion aids) with V7 and BSD crons. - The V.2 queue control file (/usr/lib/cron/queuedefs) is not supported. It has been superseded by the 'userlimits' file for at and cron, and by the profile files for batch. There is no queue-specific control for at and cron; it is user-specific instead. There also are no conversion aids (sorry, it was a bit too tricky). You will have to create the 'userlimits' file by hand. The 'makeq' script will help you create the profile files for the batch queues. - The cron log file output format has been changed. If you have scripts that process the cron logs, you will have to edit them. The new log file format is similar to the old one, and was designed with scripts in mind, so you should find the conversion easy. - The /usr/lib/cron/.proto file is ignored. If you want to change the at-job prototype, you must change the source (see runcmd.c). I'd be interested to hear if anybody uses this feature. - System V at forces /bin/sh on all users. This offends me, plus it's incompatible with BSD's implementation of at. I did it the BSD way. I intend to add a configuration option to control this for sites that like the System V way, but I haven't yet. SOME EXTENDED INSTALLATION NOTES If you want to take full advantage of the new cron daemon's features, you will have to do some hand editing of some things. The new daemon has several capabilities that the old ones didn't have, and they can be used to improve your system administration world. V7 and BSD people, you are going to have to get used to "submitting" your crontabs with the 'crontab' command after you edit them. If your edits didn't seem to take, maybe you forgot to type 'crontab'. Cron keeps its files in /usr/spool/cron/crontabs. You will find your root crontab there, and you can create new crontabs for other administrative users (such as uucp) in that directory by using a command like "crontab -e -u uucp". If you don't live in the United States, you will have to change the daylight-savings table in "timesubs.c". Someday I'll use Arthur Olson's stuff, but I haven't integrated it yet. New capabilities and how to use them: - Set-uid flags in crontab lines. Because so many crontab lines seem to start with "su" or "exec su", the new cron has a feature to allow uid and gid specification in crontab lines. ID's may be either symbolic or numeric. To use this feature, add the characters 'ug' to the flags field on the line (if the flags field is '-', delete the dash), and add the uid and gid just before the command. Thus, for example, the line - Sun 08:00 exec su uucp -c "exec /usr/lib/uucp/uudemon.wk" becomes ug Sun 08:00 uucp uucp exec /usr/lib/uucp/uudemon.wk However, note that user crontabs are a better way to achieve this. - User crontabs. Instead of using the set-uid capability, you can split up the root crontab into several crontabs, by user. Each administrative user's crontab will be run under that user's id. When you have finished editing, submit each crontab using the "-u" switch. For example, to submit a crontab named 'uucp' on behalf of the uucp administrative user, type crontab -u uucp uucp You can also 'su' to uucp and then simply type 'crontab uucp'. - Catchup mode. If you ever go down unpredictably, you may want cron to catch up when you come back up. You will have to do a line-by-line analysis of your crontab and decide which lines warrant catching up, and what catchup mode should be used. In general, catchup is not appropriate for lines that are executed more than once per hour, because they will soon be executed anyway. Most catchup lines should be 's' mode (run sequentially in background); a few will need to be 'w' mode. The other catchup modes are for exceptional situations. - Permission files and userlimits file. If you don't want a wide-open system, you will want to edit these. You can deny access to user crontabs by creating a zero-length cron.allow file, and to at by creating a null at.allow file. Finer control can be had by putting user names into allow/deny files, and by controlling resources using the userlimits file. - Batch queues. The batch daemon supports multiple named queues with extensive control parameters. The 'makeq' command can be used to make new queues. The original authors suggested names such as "now", "later", "never" (really "much-later") and "troff". However, there is no restriction on names. Good luck, and have fun. Please send bugs/comments to geoff@itcorp.com (...!{hplabs,trwrb}!desint!geoff).