Objections and comments noted inline. On Thu, Mar 11, 1999 at 06:56:48PM -0800, Daniel Quinlan wrote: > A specification proposal for LSB-compliant package cron jobs. > > This is basically straight out of the Debian policy handbook, with > several suggested modifications following the proposal. > > ------- start of proposal -------------- > Cron jobs > > Packages may not touch the configuration file /etc/crontab, nor may > they modify the files in /var/spool/cron/crontabs. > > If a package wants to install a job that has to be executed via cron, > it should place a file with the name if the package in one of the > following directories: > > /etc/cron.daily > /etc/cron.weekly > /etc/cron.monthly > > As these directory names say, the files within them are executed on a > daily, weekly, or monthly basis, respectively. > > If a certain job has to be executed more frequently than `daily,' the > package should install a file /etc/cron.d/<package-name> tagged as > configuration file. This file uses the same syntax as /etc/crontab and > is processed by cron automatically. (Note, that scripts in the > /etc/cron.d directory are not handled by anacron. Thus, you should > only use this directory for jobs which may be skipped if the system is > not running.)
Why not just put the /etc/cron.daily|weekly|monthly tables into /etc/cron.d, too? What does this buy the spec? Or the user, for that matter? Drop it all into cron.d and you look one place and one place only. It seems simpler. > All files installed in any of these directories have to be scripts > (shell scripts, Perl scripts, etc.) so that they can easily be > modified by the local system administrator. In addition, they have to > be registered as configuration file. > > The scripts in these directories have to check, if all necessary > programs are installed before they try to execute them. Otherwise, > problems will arise when a package was removed (but not purged), since > the configuration files are kept on the system in this situation. > ------- end ---------------------------- > > Suggested modifications: > > - replace should with shall (makes sense for all cases) > - all scripts must be XPG3 Shell compliant scripts, using a > standard location for XPG3 Shell to be determined > > Open questions: > > - do we require anacron in the standard base system? No. What is the rationale? Vixie cron works just fine, except, perhaps that it assumes a box is up 24x7. If a box isn't up 24x7, why is it so critical to specify anacron? > - if anacron, should there be a configuration option (for any package > cron job to disable/enable anacron operation)? > - if anacron, should scripts in /etc/cron.d be handled by anacron? > - do we use the above system or an "install-cron" program wrapper? I like the spec for /etc/cron.d. I don't see, at first blush, any added value of specifying, in addition to /etc/cron.d, /etc/cron.daily|weekly|etc. Or vice versa. "We've always done it that way!" won't fly either. > I think this is the right way to go. The software patches for > /etc/cron.d already exist. /etc/cron.daily and friends have emerged > as de-facto Linux standards. With /etc/cron.d in play, there is more > than enough flexibility for a long time into the future. Leading with my chin, I ask "Have emerged as de-facto Linux standards"? for whom? News to me. > Also, using this approach does not prevent further innovation and > non-cron-like schedulers that could replace/supplement cron in the > event someone decided to do that. Noted and agreed. Is there any value in stating that non-cron-type schedulers should leave /etc/cron.d alone? -- Kurt The likelihood of a software project's success is inversely proportional to the number of managers involved in it.
