Re: cron jobs more often than daily
Kai is absolutely correct in his justification of the policy:
> 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.
To reiterate: if a file is listed as a conffile by dpkg, then *any*
modification is going to cause dpkg to notify you when the distributed
version of the file changes. It doesn't matter if the mod was done by a
script provided by the package.
I agree that there seems to be a need for general solution. There are
two general approaches:
1. Extend the current model of providing directories and using
run-parts. This is the most straightforward, but leads to
questions about how fine a granularity to provide (I'm thinking
5m,10m,15m,20m,30m,1h,2h,6h,12h) and is kind of ugly in terms having
a pile of directories around. I could easily convince myself to put
them all under cron.scripts/<time>, although it leaves cron.{daily,
weekly, monthly} hanging out in the breeze. I'd probably softlink
cron.scripts/daily -> cron.daily, and so on.
Advantages: Easy to do, consistent with current policy and practice.
Only packages that have to be modified are cron and packages that are
currently in violation of policy.
Disadvantages: Limited control by packages over granularity, offset, and
user. (I'm not convinced that this is a real showstopper: if the package
*really* requires that fine of control, it probably needs a custom user
anyway.)
2. /etc/crontab is no longer a dpkg conffile, but is built by calls to
a script (for debian packages) or editing (for sysadmins). Probably
it's marked into two sections: one for sysadmin customization, one for
update-crontab's playground. I have a lot misgivings about what could go
wrong if the sysadmin messes with the playground.
Advantages: packages have complete control over cron scheduling.
Everything is actually in /etc/crontab, which is probably what most
(debian) newcomers expect. Packages could add comments, arguments to
scripts.
Disadvantages: Every package that currently uses cron.{daily,...} has to
be modified (not immediately, perhaps, but eventually: you don't want
both schemes). What about packages that don't rely on cron, but can
use it: if cron is installed after that package, it's too late, they
won't be in the crontab. Upgrade from the current situation is tricky,
although not so bad if we say that packages that currently violate
policy by modifying /etc/crontab are screwed.
Also, how does all of this affect anacron? (now that they're finally
playing well together, it would be a shame to screw them up...)
As cron maintainer, right now I'm leaning towards 1), mostly because
it's the least disturbance to a working system. If we were starting from
scratch, I'd probably prefer 2), but I also believe the update-crontab
script is going to require more thought than most people think....
steve
--
Steve Greenland
--
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: