Re: cron jobs more often than daily
On 09-Jan-1998 13:03:45, Martin Schulze <joey@kuolema.Infodrom.North.DE> wrote:
> I object to this proposal. I'd rather have only _one_ systemwide crontab
> called /etc/crontab than introducing a new directory for these reasons:
>
> . /etc/cron.d is fully incompatible to any other flavour of Linux
> or Unix. As far as I know Paul Vixie I don't think that he's
> going to include this patch to the cron package. So it would
> be a special Debian incompatibility.
Difference, not incompatability -- Debian cron will continue to run
quite happily without the presence of /etc/cron.d. And since Paul hasn't
issued a patch to cron for several *years*, I agree that it is unlikely
that he'll add this patch. There are already several "#ifdef DEBIAN"
places in the code.
> . /etc/cron.d would make the system more difficult to maintain
> because they have to check yet another directory where crontabs
> get stored. At the moment many people are already confused that
> there is /etc/crontab and not only /var/spool/cron/crontabs/root.
Many unix systems I've had a /etc/crontab (quite a few, and quite a
variety), which is quite distinct and serves a totally different purpose
than root's crontab.
> . I don't see the need for introducing another directory just
> for three packages that might need it (ipac, cron, <forgot the name>).
> If there was heavy use of /etc/crontab, perhaps in conjunction with
> problems breaking crontab &c, but there aren't. In the past there
> were problems with at/atrun, but that's superceeded by atd as
> standalone program.
cron *doesn't* need it. This all came up because of a claim that many
programs *do* need it. If that claim is incorrect, then we
> . /etc/cron.d would make cron itself much more complicated. It
> has to watch the directory to change, it has to watch each file
> in it to change, more timestamps need to be remembered.
It already does this for /etc/crontab and all the user crontabs. Adding
another directory is *not* a big deal; trust me, I looked at the
code before agreeing. It is, for example, much easier that writing
a *correct* update-crontab script.
> 3.3.7. Configuration files
> --------------------------
>
> [..]
>
> If two or more packages use the same configuration file, one of these
> packages has to be defined as *owner* of the configuration file, i.e.
> it has to list the file as `conffile' and has to provide a program
> that modifies the configuration file.
>
> The other packages have to depend on the *owner* package and use that
> program to update the configuration file.
The problem with this is that once the package-provided program has
modified the file, the file is (quite properly) considered "changed"
by dpkg, which will then whine about the next time distributed version
changes (and thereafter, I think).
There are *so* many issues in writing an update-crontab (think about
upgrades from the existing system; user changes to individual lines vs.
package changes, etc.). Letting each package have it's own conffile
in /etc/cron.d solves most of those. I agree that the difference is
somewhat awkward, but I think it's better (simpler, more reliable) than
the alternatives.
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: