Re: cron jobs more often than daily
schwarz@monet.m.isar.de (Christian Schwarz) wrote on 05.01.98 in <[🔎] Pine.LNX.3.96.980105145618.16504D-100000@monet>:
> On Tue, 6 Jan 1998, Hamish Moffatt wrote:
>
> > On Mon, Jan 05, 1998 at 11:58:12PM +1100, Hamish Moffatt wrote:
> > > Urgh, I hate it already. Can somebody post a rationale for
> > > the section of policy quoted above? I notice that mgetty
> > > has added faxrunq to my /etc/crontab on my bo system.
>
> The idea behind the policy is explained in `3.3.7 Configuration files'. As
> /etc/crontab is a configuration file of the "cron" package, no other
> package may touch it. That's because in the past, we had packages that
> messed around with other packages configuration files.
>
> The solution presented in 3.3.7 is that the "owner" of the conffile (cron
> in that case) provides a utility (like install-info, for example) through
> which other packages can register and remove cron jobs.
Umm. There's a good reason for not automatically modifying conffiles,
ever: "... was modified by you or by a script ..."
The general rule, AFAIR, is for a file to _either_ be a conffile, or
_completely_ handled by scripts, and never the twain shall meet.
And yes, we still have a number of (sometimes important) packages getting
this wrong.
In this case, it's probably best if /etc/crontab goes the "script only"
route, with a section clearly reserved for the sysadmin, and other
sections handled automatically. The "update-crontab" script would have to
handle "ancient" /etc/crontab files that were done by
conffile+sysadmin+scripts before; probably impossible without manual
intervention. Also, make sure that old *rm scripts won't junk the new,
improved crontab! This is not going to be fun.
MfG Kai
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: