Re: [PROPOSAL] Cron jobs
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.
Reply to: