Re: cron jobs more often than daily
FWIW, just so you don't think you're by yourself, I think your proposal is superior. What we're talking about here is a simple cron database, and that's something the filesyastem's quite good at -- no scripts needed. Those arguing in favor of making /etc/crontab automatically generated are the same people who think that people won't understand /etc/cron.d, and that /etc/cron.d is too unix-incompatible. 1) Making /etc/crontab auto-generated is at least as incompatible as /etc/cron.d, and it puts more of a burden on the user. Debian users already know about /etc/crontab, and expect to be able to modify it. If we go with /etc/cron.d, as far as the user's concerned, nothing changes -- principle of least surprise. 2) If you make /etc/crontab automatically generated, people new to Debian *will* still modify it, and then we'll have to field questions on debian-user. 3) With /etc/cron.d we can make the files in there conffiles (like /etc/init.d), and then when a user modifies them, they'll get immediate results, without having to remember to call some script (and many won't remember, they'll ask on debian-user why their changes didn't take effect). -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Rob Browning [EMAIL PROTECTED] wrote: FWIW, just so you don't think you're by yourself, I think your proposal is superior. What we're talking about here is a simple cron database, and that's something the filesyastem's quite good at -- no scripts needed. Seconded. I was only in favour of the script generated /etc/crontab while I was labouring under the illusion that /etc/cron.d processing would be a pain to implement. Having cron process the /etc/cron.d/* files directly is much more elegant. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Fri, Jan 09, 1998 at 11:24:42AM -0600, Steve Greenland wrote: On 09-Jan-1998 13:03:45, Martin Schulze [EMAIL PROTECTED] wrote: . 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 ipac needs to collect IP accounting statistics every few minutes if 1. any decent resolution is to work when reviewing the results; the summarizer supports any time resolution you want; 2. IP accounting statistics are not to be lost in the event of a crash. I do not think Martin's solution of writing a daemon is acceptable. cron is perfect for this. There is no need to reinvent the wheel. hamish (ipac maintainer) -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On 07-Jan-1998 11:35:45, Christian Schwarz [EMAIL PROTECTED] wrote: On 6 Jan 1998, Kai Henningsen wrote: [EMAIL PROTECTED] (Christian Schwarz) wrote: (b) We set up a certain directory (say /usr/lib/cronjobs) where each package can install its own crontab file (/usr/lib/cronjobs/foo). Use /etc/cron.often (or similar name). It will contain crontabs, not executable scripts. All of them will be conffiles, so the sysadmin can change them without fear of updates. This seems to be the consensus, and it's my favorite too, and looks to be easy to implement (especially given the nice way that cron reads/parses crontabs). Here's the proposal: In addition to reading /etc/crontab, the cron daemon will also read each file in /etc/cron.d (chosen for similarity to init.d). Each of the files in cron.d is considered a crontab fragment, and should be formatted exactly as /etc/crontab (i.e. with the username specified). The end result will be just as if cron read the result of cat /etc/crontab /etc/cron.d/* Packages requiring faster than daily intervals, or irregular intervals, should place the appropriate crontab fragment in /etc/cron.d/packagename. This file should be marked as conf file, so that the sysadmin may change it. The files in /etc/cron.d will be checked for changes (via stat()) every minute, just as /etc/crontab is; therefore there is no need for action in the postinst. I should be able to get this out this weekend. steve -- Steve Greenland -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Thu, Jan 08, 1998 at 11:07:52PM -0600, Steve Greenland wrote: This seems to be the consensus, and it's my favorite too, and looks to be easy to implement (especially given the nice way that cron reads/parses crontabs). Here's the proposal: In addition to reading /etc/crontab, the cron daemon will also read each file in /etc/cron.d (chosen for similarity to init.d). Each of the files in cron.d is considered a crontab fragment, and should be formatted exactly as /etc/crontab (i.e. with the username specified). The end result will be just as if cron read the result of cat /etc/crontab /etc/cron.d/* Packages requiring faster than daily intervals, or irregular intervals, should place the appropriate crontab fragment in /etc/cron.d/packagename. This file should be marked as conf file, so that the sysadmin may change it. The files in /etc/cron.d will be checked for changes (via stat()) every minute, just as /etc/crontab is; therefore there is no need for action in the postinst. 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. . /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. . 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. . /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. . Our policy contains a clear statement on what to do: 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. Sorry that I only speak up now, but I was too busy before (and I still am) Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / Whenever you meet yourself you're in a time loop / / http://home.pages.de/~joey/ or in front of a mirror / pgpsNm3ofaZOE.pgp Description: PGP signature
Re: cron jobs more often than daily
On 07-Jan-1998 11:35:45, Christian Schwarz [EMAIL PROTECTED] wrote: On 6 Jan 1998, Kai Henningsen wrote: [EMAIL PROTECTED] (Christian Schwarz) wrote: (b) We set up a certain directory (say /usr/lib/cronjobs) where each package can install its own crontab file (/usr/lib/cronjobs/foo). Use /etc/cron.often (or similar name). It will contain crontabs, not executable scripts. All of them will be conffiles, so the sysadmin can change them without fear of updates. This seems to be the consensus, and it's my favorite too, and looks to be easy to implement (especially given the nice way that cron reads/parses crontabs). Here's the proposal: In addition to reading /etc/crontab, the cron daemon will also read each file in /etc/cron.d (chosen for similarity to init.d). Each of the files in cron.d is considered a crontab fragment, and should be formatted exactly as /etc/crontab (i.e. with the username specified). The end result will be just as if cron read the result of cat /etc/crontab /etc/cron.d/* How about also moving /etc/crontab to /etc/cron.d/cron, so the behavior is simply equivalent to the result of: cat /etc/cron.d/* You could either get rid of /etc/crontab, have it as a symbolic link to /etc/cron.d/cron, or have it contain a note directing the user to edit the new file. This way even cron abides by the /etc/cron.d/package-name standard. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Thu, 8 Jan 1998, Steve Greenland wrote: Here's the proposal: In addition to reading /etc/crontab, the cron daemon will also read each file in /etc/cron.d (chosen for similarity to init.d). Each of the files in cron.d is considered a crontab fragment, and should be formatted exactly as /etc/crontab (i.e. with the username specified). The end result will be just as if cron read the result of cat /etc/crontab /etc/cron.d/* Isn't it easier to have all packages that place something in /etc/cron.d (or whatever is's called) call an update-cron script which conctenates all files in /etc/cron.d/ into /etc/crontab? The /etc/crontab we have currently would also have to me moved into /etc/cron.d/ . Perhaps /etc/crontab could also contain some comment lines that say something like don't edit this file, instead edit the appropriate file in /etc/cron.d/. The update-cron script could be very simple, like: #!/bin/sh cat EOF /etc/crontab.tmp # DO NOT EDIT THIS FILE. It will be overwritten by the update-cron script. # Instead, edit the appropriate file in /etc/cron.d and re-run update-cron . # EOF cat /etc/cron.d/* /etc/crontab.tmp mv /etc/crontab.tmp /etc/crontab Advantage: cron doesn't need to be modified Packages requiring faster than daily intervals, or irregular intervals, should place the appropriate crontab fragment in /etc/cron.d/packagename. This file should be marked as conf file, so that the sysadmin may change it. The files in /etc/cron.d will be checked for changes (via stat()) every minute, just as /etc/crontab is; therefore there is no need for action in the postinst. Disadvantage (perhaps) of my proposal: each package has to call update-crom in both postinst and postrm. I think there should be no modifications to cron that make Debian incompatible with other unixes, if they can be avoided. Remco -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Fri, Jan 09, 1998 at 04:30:43PM +0100, Remco Blaakmeer wrote: Isn't it easier to have all packages that place something in /etc/cron.d (or whatever is's called) call an update-cron script which conctenates all files in /etc/cron.d/ into /etc/crontab? The /etc/crontab we have currently would also have to me moved into /etc/cron.d/ . Perhaps /etc/crontab could also contain some comment lines that say something like don't edit this file, instead edit the appropriate file in /etc/cron.d/. The update-cron script could be very simple, like: #!/bin/sh cat EOF /etc/crontab.tmp # DO NOT EDIT THIS FILE. It will be overwritten by the update-cron script. # Instead, edit the appropriate file in /etc/cron.d and re-run update-cron . # EOF cat /etc/cron.d/* /etc/crontab.tmp mv /etc/crontab.tmp /etc/crontab That's far too easy. :) Yes, of course, that's great. Advantage: cron doesn't need to be modified Disadvantage: Users adding cronjobs might see their jobs removed. But as there is a note at the beginning this should be acceptable. Disadvantage (perhaps) of my proposal: each package has to call update-crom in both postinst and postrm. Same for /etc/services, update-alternatives, menu and things. I don't see a disadvantage here. I think there should be no modifications to cron that make Debian incompatible with other unixes, if they can be avoided. Seconded. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / Whenever you meet yourself you're in a time loop / / http://home.pages.de/~joey/ or in front of a mirror / pgpepkfIX4XGB.pgp Description: PGP signature
Re: cron jobs more often than daily
Remco Blaakmeer [EMAIL PROTECTED] wrote: The update-cron script could be very simple, like: #!/bin/sh cat EOF /etc/crontab.tmp # DO NOT EDIT THIS FILE. It will be overwritten by the update-cron script. # Instead, edit the appropriate file in /etc/cron.d and re-run update-cron . # EOF cat /etc/cron.d/* /etc/crontab.tmp mv /etc/crontab.tmp /etc/crontab Brilliant. I think that sorts that problem out rather nicely. BTW you could make the script even simpler (well shorter anyway ;-), and slighlty safer: #!/bin/sh cat - /etc/cron.d/* EOF /etc/crontab.tmp mv /etc/crontab.tmp /etc/crontab # DO NOT EDIT THIS FILE. It will be overwritten by the update-cron script. # Instead, edit the appropriate file in /etc/cron.d and re-run update-cron . # EOF Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On 09-Jan-1998 13:03:45, Martin Schulze [EMAIL PROTECTED] 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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On 09-Jan-1998 17:00:04, Martin Schulze [EMAIL PROTECTED] wrote: On Fri, Jan 09, 1998 at 04:30:43PM +0100, Remco Blaakmeer wrote: The update-cron script could be very simple, like: #!/bin/sh cat EOF /etc/crontab.tmp # DO NOT EDIT THIS FILE. It will be overwritten by the update-cron script. # Instead, edit the appropriate file in /etc/cron.d and re-run update-cron . # EOF cat /etc/cron.d/* /etc/crontab.tmp mv /etc/crontab.tmp /etc/crontab That's far too easy. :) Yes, that's far too easy, not to mention guaranteed to break existing systems. Advantage: cron doesn't need to be modified Disadvantage: Users adding cronjobs might see their jobs removed. But as there is a note at the beginning this should be acceptable. Totally unacceptable. I think there should be no modifications to cron that make Debian incompatible with other unixes, if they can be avoided. Seconded. Why is it bad to have cron read files directly from cron.d, and acceptable to have it read a crontab that's built from files in cron.d. In the first case, if I mod crontab, it doesn't get overwritten, and I have to go to cron.d to modify some things. In the second, if I mod crontab, it *does* get overwritten, and I have to cron.d to modify things. What's the difference, except that I'm more likely to screw stuff up in the second case? steve -- Steve Greenland -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Fri, 9 Jan 1998, Steve Greenland wrote: [snip] 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). This is not only a problem with /etc/crontab, but with even more important files like /etc/passwd! Does someone know how COAS interferes with this discussion? Thanks, Chris -- Christian Schwarz Do you know [EMAIL PROTECTED], [EMAIL PROTECTED], Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Christian Schwarz [EMAIL PROTECTED] writes: On 6 Jan 1998, Kai Henningsen wrote: Disadvantage: needs a patch for cron, to scan this directory as well as the usual user crontab directory, and to execute those cronjobs as root, not as a user. It's a small disadvantage, after all. I like this option too. A more general patch to cron would be an include mechanism: include path/to/file - include a file include path/to/directory - include every file in a directory We'd use the second form here. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Meskes, Michael [EMAIL PROTECTED] writes: Couldn't we find a common way for packages to adjust other packages conffiles? The service registration mechanism I proposed earlier takes care of this easily. Netbase does this in the postinst: provide-service --install-hook services netbase /usr/lib/installservice And has /usr/lib/installservice: #!/bin/sh if [ $1 = --install ] ; then p=$2 shift 2 echo $@ # $p /etc/services elsif [ $1 = --remove ] ; then p=$2 t=$(tempfile) sed -e '/# $p/d' /etc/services $t mv t /etc/services done A quake-server package would do this for example: register-service --install quake-server quake 26000/udp And in prerm: register-service --remove quake-server I should go implement it. It solves lots of configuration issues. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Wed, Jan 07, 1998 at 11:30:42PM -0800, Guy Maor wrote: Disadvantage: needs a patch for cron, to scan this directory as well as the usual user crontab directory, and to execute those cronjobs as root, not as a user. I like this option too. A more general patch to cron would be an include mechanism: include path/to/file - include a file include path/to/directory - include every file in a directory For my feeling this would complicate things alot more than needed. Both the user and the cron program have to take care of alot of more stuff. I don't see the need for this compicated mechanism as there are only very few packages that contain scripts/programs that need to be run more often than daily. It doesn't make sense to split very small configuration files into more files and directories. This is useful for configuration files that contain a lot of entries and where many packages use to install services. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / Whenever you meet yourself you're in a time loop / / http://home.pages.de/~joey/ or in front of a mirror / pgpmS6rk7lnQs.pgp Description: PGP signature
Re: cron jobs more often than daily
On 6 Jan 1998, Kai Henningsen wrote: [EMAIL PROTECTED] (Christian Schwarz) wrote on 06.01.98 in [EMAIL PROTECTED]: (b) We set up a certain directory (say /usr/lib/cronjobs) where each package can install its own crontab file (/usr/lib/cronjobs/foo). Use /etc/cron.often (or similar name). It will contain crontabs, not executable scripts. All of them will be conffiles, so the sysadmin can change them without fear of updates. I like this option, too. Disadvantage: needs a patch for cron, to scan this directory as well as the usual user crontab directory, and to execute those cronjobs as root, not as a user. It's a small disadvantage, after all. Policy would be to only use this for cron jobs that absolutely cannot be handled by any of the other /etc/cron.period directories. Yes, that's very important to point out: Anacron will only run scripts in the /etc/cron.period directories. Therefore, only jobs which can safely be ignored if the system is powered down can be placed into /etc/cron.often. (What about /etc/cron.generic ?) Other opinions? Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Christian Schwarz wrote: Yes, that's very important to point out: Anacron will only run scripts in the /etc/cron.period directories. Therefore, only jobs which can safely be ignored if the system is powered down can be placed into /etc/cron.often. (What about /etc/cron.generic ?) How about /etc/cron.frequent? -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
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
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Mon, 5 Jan 1998, Christian Schwarz wrote: Fact is, that the cron package, the local sysadmin, and possibly other packages modify the /etc/crontab file. However, dpkg only controls modification between the sysadmin and _one_ package (cron here). I really think the cron package should provide a script where other packages can register cron jobs. I'll file a bug report. Could the crontab file be made to source another file which could contain all the changes? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lindsay Allen [EMAIL PROTECTED] Perth, Western Australia voice +61 8 9316 248632.0125S 115.8445Evk6lj Debian Unix =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 09:12:23AM -0600, Nathan E Norman wrote: On Mon, 5 Jan 1998, Hamish Moffatt wrote: : Packages may not touch the configuration file `/etc/crontab', nor may : they modify the files in `/var/spool/cron/crontabs'. : : Doesn't this rule this out? The mrtg package in hamm adds an entry to /etc/crontab; it also places comments around the entry to aid future removal, I suppose. This may violate policy (I don't know), but it does show that other packages are doing this. Actually, you're not allowed to modify other configuration files at all, Christian points out. So mrtg can't edit /etc/crontab, mgetty-fax shouldn't edit it either, mgetty shouldn't edit /etc/inittab, etc. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 09:45:39PM +0100, Torsten Landschoff wrote: What about a kind of tag-oriented style of appending to /etc/crontab after asking the admin: ipac-install suggest to append an entry to /etc/crontab, which starts ipac every 15 minutes: [line to be inserted] The lines will be enclosed by # -*- install: ipac -*-. This way a remove script will be able to remove the lines which were inserted by install. That is the best way to do it (and the way debstd does it automatically), but the problem is that it is illegal under policy however you do it. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Steve Greenland [EMAIL PROTECTED] writes: I agree that there seems to be a need for general solution. There are two general approaches: This might be completely off base, but what about a (hopefully small) hack to cron for debian systems that makes it concatenate /etc/cron.debian/* with /etc/crontab everytime it would have just loaded /etc/crontab. Then packages would just have to put crontab snippets into /etc/crontab.debian/. If stat-ing all these files is too much work for cron every minute, then just have update-crontab concatenate them into one file, say /etc/crontab.debian/cron. Then there are only two files to stat. Something like if [ -x /usr/bin/update-crontab ] ; then update-crontab ; fi would be used in each package's postinst to make sure things are OK if cron's not installed. An alternate idea, which I thought of first, but probably won't work, was to create a user called debcron or something, then have files like menu's /usr/lib/menu files which are used to build debcron's crontab. The problem with that would be that I can't see any easy way to make the tasks run as the appropriate user. This latter approach is just another case of the more general mechanism that Guy outlined eariler. -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Steve Greenland wrote: 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.) Another disadvantage is that this would lead to run-parts running evey 5 minutes and wasting some cpu time, even if there were no 5 minute granularity cron jobs installed on the system. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re[2]: cron jobs more often than daily
| On Tuesday, 6 January 98, at 2:28:26 AM | Joey wrote about cron jobs more often than daily Steve Greenland wrote: 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.) Another disadvantage is that this would lead to run-parts running evey 5 minutes and wasting some cpu time, even if there were no 5 minute granularity cron jobs installed on the system. Or: Have a directory, /etc/debian.crontab/, that holds a file for every package that wants to be run by cron. Modify /etc/cron.tab(in the master version), to have a line that runs /etc/init.d/debian.cron. Have a script, update-debian-crontab, that when called to add a new /etc/debian.crontab/package, updates /etc/init.d/debian.cron to run the package that would next need to be. Everytime that /etc/init.d/debian.cron is run, it checks to see when the next package is to be run, and updates itself, and /etc/cron.tab. Does anyone understand what I am trying to accomplish here? Each time /etc/init.d/debian.cron runs, it modifies /etc/cron.tab, changing the time that it will next be run at. This might be better handled with some type of alarm program, that will exec another program at a specific time, instead of every so often. Why do keyboards get replaced? Because people run Windows, and they can't hit Bill! Adam Heath of Borg-Linux [EMAIL PROTECTED] Join the H.323 effort. Email http://www.debian.org - Get Your Own Linux! [EMAIL PROTECTED] with http://wwp.mirabilis.com/3375265 - Page Me the word subscribe in the body. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re[2]: cron jobs more often than daily
On Tue, Jan 06, 1998 at 02:51:52AM -0500, Adam Heath wrote: /etc/init.d/debian.cron to run the package that would next need to be. Everytime that /etc/init.d/debian.cron is run, it checks to see when the next package is to be run, and updates itself, and /etc/cron.tab. Does anyone understand what I am trying to accomplish here? Each time /etc/init.d/debian.cron runs, it modifies /etc/cron.tab, changing the time that it will next be run at. This might be better handled with some type of alarm program, that will exec another program at a specific time, instead of every so often. Sounds like `at' to me. So I could schedule my thing to run every 15 minutes with at, but I think that the sysadmin probably assumes that standard system tasks will not be run through at, but by cron. at has an atd, probably because it wasn't allowed to add atrun to crontab :-) hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re[2]: cron jobs more often than daily
On Tue 06 Jan 1998, Adam Heath wrote: Have a directory, /etc/debian.crontab/, that holds a file for every package that wants to be run by cron. Modify /etc/cron.tab(in the master version), to have a line that runs /etc/init.d/debian.cron. Have a script, update-debian-crontab, that when called to add a new /etc/debian.crontab/package, updates /etc/init.d/debian.cron to run the package that would next need to be. Everytime that /etc/init.d/debian.cron is run, it checks to see when the next package is to be run, and updates itself, and /etc/cron.tab. Why not require packages that need this level of control over cron jobs to register a user, so that a user-specific crontab (in /var/spool/cron/crontabs) can be installed, e.g. with crontab -u package file ? Paul Slootman -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re[2]: cron jobs more often than daily
On Tue, Jan 06, 1998 at 10:57:48AM +0100, Paul Slootman wrote: Why not require packages that need this level of control over cron jobs to register a user, so that a user-specific crontab (in /var/spool/cron/crontabs) can be installed, e.g. with crontab -u package file ? Because sometimes the jobs need to run as root. Quite often I suspect. My package ipac (which started this) needs to run ipfwadm to configure and reset the IP accounting rules, which requires root. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
I currently see three practical solutions out of the dilemma (that /etc/crontab is edited by the sysadmin and scripts): (a) We set up another crontab (say /etc/crontab.deb) which is maintained by install-cronjob only. The current /etc/crontab will stay a conffile and only be touched by the sysadmin. Disadvantage: The sysadmin might want to remove (or change) an entry of /etc/crontab.deb too, so we didn't solve any problems. (b) We set up a certain directory (say /usr/lib/cronjobs) where each package can install its own crontab file (/usr/lib/cronjobs/foo). Disadvantage: See above. (c) We split /etc/crontab into two areas. The install-cronjob script will only touch one area, while the sysadmin can touch both. For example: # /etc/crontab # Sysadmin's private area: Do whatever you like to do here. # Nothing will be changed automatically... * * * * * root rm -rf / # (I hope noone installs this crontab :) # -- # automatic area: You can do changes to this area, but packages # might add or remove new entries via install-cronjob # ---entry from package foo1--- * * * * * root something # ---entry from package foo2--- This keep all cronjobs in a single file which makes life easier for the sysadmin, I think. Note, that the install-cronjob script should be smart enough to handle commented-out cron entries correctly (they should stay commented-out during package upgrades). Comments? Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Debian has a logo![EMAIL PROTECTED], [EMAIL PROTECTED] Check out the logo PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA pages at http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re[2]: cron jobs more often than daily
On Tue 06 Jan 1998, Hamish Moffatt wrote: On Tue, Jan 06, 1998 at 10:57:48AM +0100, Paul Slootman wrote: Why not require packages that need this level of control over cron jobs to register a user, so that a user-specific crontab (in /var/spool/cron/crontabs) can be installed, e.g. with crontab -u package file ? Because sometimes the jobs need to run as root. Quite often I suspect. My package ipac (which started this) needs to run ipfwadm to configure and reset the IP accounting rules, which requires root. Ah, that's quite a good reason. The mechanism involved in scanning for users' crontabs could be used to implement what Christian has proposed: using something like /usr/lib/cronjobs which would contain package-specific crontabs. In that scheme, is the user id under which the jobs are to be run configurable in any way? I'd says that not all such jobs would need to be run as root, and minimizing the number of root jobs helps to prevent security trouble. Paul Slootman -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Tue, Jan 06, 1998 at 11:49:30AM +0100, Christian Schwarz wrote: I currently see three practical solutions out of the dilemma (that /etc/crontab is edited by the sysadmin and scripts): (b) We set up a certain directory (say /usr/lib/cronjobs) where each package can install its own crontab file (/usr/lib/cronjobs/foo). Disadvantage: See above. I like this solution the best. Isn't it acceptable that the admin may modify these files just as they may modify the files in /etc/init.d and /etc/cron.daily? Then package-supplied crontab files would be conffiles too. So it would be much like /etc/cron.daily etc, but each package can specify its own interval. We should still encourage /etc/cron.daily perhaps because it allows a central point for changing the system maintenance time (in /etc/crontab), makes it easy to use anacron instead, etc. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
[EMAIL PROTECTED] (Christian Schwarz) wrote on 06.01.98 in [EMAIL PROTECTED]: (b) We set up a certain directory (say /usr/lib/cronjobs) where each package can install its own crontab file (/usr/lib/cronjobs/foo). Use /etc/cron.often (or similar name). It will contain crontabs, not executable scripts. All of them will be conffiles, so the sysadmin can change them without fear of updates. Disadvantage: needs a patch for cron, to scan this directory as well as the usual user crontab directory, and to execute those cronjobs as root, not as a user. Policy would be to only use this for cron jobs that absolutely cannot be handled by any of the other /etc/cron.period directories. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re[2]: cron jobs more often than daily
On Tue, Jan 06, 1998 at 04:27:53PM +0100, Turbo Fredriksson wrote: On Tue, 6 Jan 1998, Hamish Moffatt wrote: Because sometimes the jobs need to run as root. Quite often I suspect. My package ipac (which started this) needs to run ipfwadm to configure and reset the IP accounting rules, which requires root. Why not use a daemon? In peal, that would be a ten-liner... That's certainly possible, but it's a bit of a shame to be implementing custom versions of cron, when cron can do exactly this already but we don't have any way to configure it so. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
cron jobs more often than daily
I'm working on a package of ipac, some scripts to set up
and summarise IP accounting info from the kernel. The author
suggests running part of it every 15 minutes. The advantage
to this is that there is less data lost in case of a system crash
(the author's point), and it also lets you get summaries
between a particular times, so obviously we get more resolution
if we run it more often.
However, policy indicates that you can only get your job
to run daily, weekly, or monthly, by putting entries in
/etc/cron.{daily,weekly,monthly}. Anything that runs more often
has a user assigned to it who gets the cronjob (eg smail
runs runq from mail's crontab, inewsinn installs crontabs for
news).
However, there's no suitable user for this and it needs
to run as root anyway to reset the accounting stats.
Am I stuck with daily?
Hamish
--
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 09:48:42PM +1100, Hamish Moffatt wrote:
I'm working on a package of ipac, some scripts to set up
and summarise IP accounting info from the kernel. The author
suggests running part of it every 15 minutes. The advantage
to this is that there is less data lost in case of a system crash
(the author's point), and it also lets you get summaries
between a particular times, so obviously we get more resolution
if we run it more often.
However, policy indicates that you can only get your job
to run daily, weekly, or monthly, by putting entries in
/etc/cron.{daily,weekly,monthly}. Anything that runs more often
has a user assigned to it who gets the cronjob (eg smail
runs runq from mail's crontab, inewsinn installs crontabs for
news).
However, there's no suitable user for this and it needs
to run as root anyway to reset the accounting stats.
Am I stuck with daily?
Why not add a job like:
*/15 * * * * root/usr/sbin/ipac-cron
to /etc/crontab? The predecessor of at has done this, too.
Regards
Joey
--
/ Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg /
/Erfahrung ist eine nützliche Sache /
/ Leider macht man sie immer erst kurz nachdem man sie brauchte /
pgpmaorVfVWMH.pgp
Description: PGP signature
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 01:26:56PM +0100, Martin Schulze wrote: On Mon, Jan 05, 1998 at 09:48:42PM +1100, Hamish Moffatt wrote: However, there's no suitable user for this and it needs to run as root anyway to reset the accounting stats. Am I stuck with daily? Why not add a job like: */15 ** * * root/usr/sbin/ipac-cron to /etc/crontab? The predecessor of at has done this, too. Policy 2.3.0.1 says 3.5. Cron jobs -- Packages may not touch the configuration file `/etc/crontab', nor may they modify the files in `/var/spool/cron/crontabs'. Doesn't this rule this out? thanks, Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgpVKIqkKADfH.pgp Description: PGP signature
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 11:31:09PM +1100, Hamish Moffatt wrote: On Mon, Jan 05, 1998 at 01:26:56PM +0100, Martin Schulze wrote: On Mon, Jan 05, 1998 at 09:48:42PM +1100, Hamish Moffatt wrote: However, there's no suitable user for this and it needs to run as root anyway to reset the accounting stats. Am I stuck with daily? Why not add a job like: */15 * * * * root/usr/sbin/ipac-cron to /etc/crontab? The predecessor of at has done this, too. Policy 2.3.0.1 says 3.5. Cron jobs -- Packages may not touch the configuration file `/etc/crontab', nor may they modify the files in `/var/spool/cron/crontabs'. Doesn't this rule this out? Oups. Well, rules exist for breaking them... An old idiom... Then your only chance is to write an ipacd that forks, lets the daughter call the ipcac-cron script , waits 15 mins and forks again. Started via /etc/init.d/ipac. Well, I know which version I would prefer but maybe the second one is better as you can control that you start your script only if the most recent child has terminated. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / /Erfahrung ist eine nützliche Sache / / Leider macht man sie immer erst kurz nachdem man sie brauchte / pgps4zx7Nvu5a.pgp Description: PGP signature
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 01:35:08PM +0100, Martin Schulze wrote: On Mon, Jan 05, 1998 at 11:31:09PM +1100, Hamish Moffatt wrote: On Mon, Jan 05, 1998 at 01:26:56PM +0100, Martin Schulze wrote: Why not add a job like: */15 ** * * root/usr/sbin/ipac-cron to /etc/crontab? The predecessor of at has done this, too. Policy 2.3.0.1 says Packages may not touch the configuration file `/etc/crontab', nor may they modify the files in `/var/spool/cron/crontabs'. Doesn't this rule this out? Oups. Well, rules exist for breaking them... An old idiom... Then your only chance is to write an ipacd that forks, lets the daughter call the ipcac-cron script , waits 15 mins and forks again. Started via /etc/init.d/ipac. 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. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgpGLKBPLdOEM.pgp Description: PGP signature
Re: cron jobs more often than daily
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. In fact, mgetty-fax's postinst said the modification of /etc/crontab was done automatically by debstd! Perhaps my mistake was using debhelper; if I use debstd, I can reassign any bugs filed against my package for modifying /etc/crontab to debstd :-) Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgp0eXYAhtjy3.pgp Description: PGP signature
Re: cron jobs more often than daily
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. I suggest you file a wish-list bug report against cron. You can refer to me, if you want. In fact, mgetty-fax's postinst said the modification of /etc/crontab was done automatically by debstd! Yeah, this is one of the biggest lies: debstd. Please let me say this very loud again: debstd does _NOT_ stand for DEBIAN STANDARD, it stands for CL's interpretation of the DEBIAN STANDARD, which often differs from the policy Thus, the use of debstd is depreciated. Note, that I've removed debstd from all of my packages lately and would like to see others doing the same thing. As soon as we have the macro-utility (was it called automake?) set up, we should consider removing debstd. Perhaps my mistake was using debhelper; if I use debstd, I can reassign any bugs filed against my package for modifying /etc/crontab to debstd :-) Yes, please file bug reports against debstd. Note, that I don't know if debhelper is any better regarding the cron policy--I hope so. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Hamish Moffatt wrote: [modifying /etc/crontab] 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. One rationale can be found in policy section 3.3.7: A package may not modify a configuration file of another package. /etc/crontab is a conffile of package cron. Perhaps this could be solved by having cron provide an update-crontab command, just like update-inetd, et cetera. (And it does look like we need a generic framework for things like this, like Guy Maor described.) Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Mon, 5 Jan 1998, Hamish Moffatt wrote: : On Mon, Jan 05, 1998 at 01:26:56PM +0100, Martin Schulze wrote: : On Mon, Jan 05, 1998 at 09:48:42PM +1100, Hamish Moffatt wrote: : However, there's no suitable user for this and it needs : to run as root anyway to reset the accounting stats. : Am I stuck with daily? : : Why not add a job like: : : */15 * * * * root/usr/sbin/ipac-cron : : to /etc/crontab? The predecessor of at has done this, too. : : Policy 2.3.0.1 says : : 3.5. Cron jobs : -- : : Packages may not touch the configuration file `/etc/crontab', nor may : they modify the files in `/var/spool/cron/crontabs'. : : Doesn't this rule this out? The mrtg package in hamm adds an entry to /etc/crontab; it also places comments around the entry to aid future removal, I suppose. This may violate policy (I don't know), but it does show that other packages are doing this. : : thanks, : Hamish : -- : Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] : Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 : CCs of replies from mailing lists are welcome. http://hamish.home.ml.org : -- Nathan Norman MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD 57104 phone: (605) 334-4454 fax: (605) 335-1173 mailto://[EMAIL PROTECTED] http://www.midco.net PGP Key ID: 0xA33B86E9 - Public key available at keyservers PGP Key fingerprint: CE03 10AF 3281 1858 9D32 C2AB 936D C472 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: cron jobs more often than daily
Yes, it does. Worse than that are the packages that update /etc/services like transproxy. Everytime Peter adds a service I have to manually change the /etc/services file. Argh! Couldn't we find a common way for packages to adjust other packages conffiles? I don't like the idea of and update-crontab, update-services etc. in my filesystem. Eventually we need a special update-bin directory. :-) Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -Original Message- From: Nathan E Norman [SMTP:[EMAIL PROTECTED] Sent: Monday, January 05, 1998 4:12 PM To: Debian Developers List Subject: Re: cron jobs more often than daily On Mon, 5 Jan 1998, Hamish Moffatt wrote: : On Mon, Jan 05, 1998 at 01:26:56PM +0100, Martin Schulze wrote: : On Mon, Jan 05, 1998 at 09:48:42PM +1100, Hamish Moffatt wrote: : However, there's no suitable user for this and it needs : to run as root anyway to reset the accounting stats. : Am I stuck with daily? : : Why not add a job like: : : */15 ** * * root/usr/sbin/ipac-cron : : to /etc/crontab? The predecessor of at has done this, too. : : Policy 2.3.0.1 says : : 3.5. Cron jobs : -- : : Packages may not touch the configuration file `/etc/crontab', nor may : they modify the files in `/var/spool/cron/crontabs'. : : Doesn't this rule this out? The mrtg package in hamm adds an entry to /etc/crontab; it also places comments around the entry to aid future removal, I suppose. This may violate policy (I don't know), but it does show that other packages are doing this. : : thanks, : Hamish : -- : Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] : Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 : CCs of replies from mailing lists are welcome. http://hamish.home.ml.org : -- Nathan Norman MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD 57104 phone: (605) 334-4454 fax: (605) 335-1173 mailto://[EMAIL PROTECTED] http://www.midco.net PGP Key ID: 0xA33B86E9 - Public key available at keyservers PGP Key fingerprint: CE03 10AF 3281 1858 9D32 C2AB 936D C472 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
This section is in my /etc/crontab... I see no problem with it. Perhaps there ought to be a thing like the script that updates inetd.conf for the crontab. I would also like an /etc/cron.scripts directory. #-- postgresql begin 0 4 * * * postgres/usr/lib/postgresql/bin/do.maintenance #-- postgresql end -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Christian == Christian Schwarz [EMAIL PROTECTED] writes: Christian The solution presented in 3.3.7 is that the owner of Christian the conffile (cron in that case) provides a utility Christian (like install-info, for example) through which other Christian packages can register and remove cron jobs. Perhaps the /etc/crontab shouldn't be a conffile; but created by the installation scripts? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
autmake debian? (was: Re: cron jobs more often than daily)
On Mon, Jan 05, 1998 at 03:02:38PM +0100, Christian Schwarz wrote: On Tue, 6 Jan 1998, Hamish Moffatt wrote: Thus, the use of debstd is depreciated. Note, that I've removed debstd from all of my packages lately and would like to see others doing the same thing. As soon as we have the macro-utility (was it called automake?) set up, we should consider removing debstd. Isn't automake the GNU program for using with autoconf ? automake creates Makefile.in's out of Makefile.am's. The Makefile.in's will be processed by configure (which itself is created by autoconf out of configure.in) to Makefiles. Automake does support the GNU standard, a less restrict one, and (perhaps) the gnits standard (the new GNU standard). Will there be automake support for Debian packages ? Thank you, Marcus -- Rhubarb is no Egyptian god. Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Christian Schwarz wrote: Note, that I don't know if debhelper is any better regarding the cron policy--I hope so. Debhelper doesn't have any provision for modifying /etc/crontab, since that is prohibited by policy. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Topi Miettinen wrote:
We have cron.{month,week,dai}ly, why not add directories hourly, bihourly
(every 30min), and quarterly (every 15min). That would give enough
resolution for most daemons.
Mrtg needs to run every 5 minutes.
--
see shy jo
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake debian? (was: Re: cron jobs more often than daily)
On Mon, 5 Jan 1998, Marcus Brinkmann wrote: On Mon, Jan 05, 1998 at 03:02:38PM +0100, Christian Schwarz wrote: On Tue, 6 Jan 1998, Hamish Moffatt wrote: Thus, the use of debstd is depreciated. Note, that I've removed debstd from all of my packages lately and would like to see others doing the same thing. As soon as we have the macro-utility (was it called automake?) set up, we should consider removing debstd. Isn't automake the GNU program for using with autoconf ? automake creates Makefile.in's out of Makefile.am's. The Makefile.in's will be processed by configure (which itself is created by autoconf out of configure.in) to Makefiles. Automake does support the GNU standard, a less restrict one, and (perhaps) the gnits standard (the new GNU standard). Will there be automake support for Debian packages ? (BTW, the discussion about this was in mid Oct 97.) The idea is to create the debian/rules file by a macro processor. (Since automake is used to create Makefiles and debian/rules is a Makefile, someone suggested to use it. However, doubts have been presented that it does not fit exactly to our purposes. Someone would have to do some experiments on this. If it doesn't fit, we can use or write another macro generator.) This would have the advantage that every action would be included explicitely in the debian/rules file instead of hidden into some utilities. Furthermore, since debian/rules would be generated by the maintainer only, everyone else can recompile the package and get the same results. (With debstd this is one problem. You need exactly the same debstd version than the maintainer had to get the same package.) It would be nice if we could find one (or more) volunteers to do some experiments on that issue. Thanks, Chris -- Christian Schwarz Do you know [EMAIL PROTECTED], [EMAIL PROTECTED], Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On 5 Jan 1998, Karl M. Hegbloom wrote: Christian == Christian Schwarz [EMAIL PROTECTED] writes: Christian The solution presented in 3.3.7 is that the owner of Christian the conffile (cron in that case) provides a utility Christian (like install-info, for example) through which other Christian packages can register and remove cron jobs. Perhaps the /etc/crontab shouldn't be a conffile; but created by the installation scripts? Since /etc/crontab is actually a conffile (no matter if you tag it as such or not) this would be a dirty hack around our policy. Fact is, that the cron package, the local sysadmin, and possibly other packages modify the /etc/crontab file. However, dpkg only controls modification between the sysadmin and _one_ package (cron here). I really think the cron package should provide a script where other packages can register cron jobs. I'll file a bug report. Thanks, Chris -- Christian Schwarz Do you know [EMAIL PROTECTED], [EMAIL PROTECTED], Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake debian? (was: Re: cron jobs more often than daily)
On Mon, Jan 05, 1998 at 08:08:51PM +0100, Christian Schwarz wrote:
On Mon, 5 Jan 1998, Marcus Brinkmann wrote:
Automake does support the GNU standard, a less restrict one, and (perhaps)
the gnits standard (the new GNU standard). Will there be automake support
for Debian packages ?
(BTW, the discussion about this was in mid Oct 97.)
(Ok, perhaps I will look in the archive. I certainly wasn't ready for this
technical topic at that time ;)
The idea is to create the debian/rules file by a macro processor. (Since
automake is used to create Makefiles and debian/rules is a Makefile,
someone suggested to use it. However, doubts have been presented that it
does not fit exactly to our purposes. Someone would have to do some
experiments on this. If it doesn't fit, we can use or write another macro
generator.)
Although I'm not able to judge auto{conf,make}'s capabilities, I had the
impression that they are strong tools. It would be nice to have some
general approach like this become standard for debian packages (I imagine
that auto compiling and porting would be easier then).
[...]
Furthermore, since debian/rules would be generated by the maintainer only,
everyone else can recompile the package and get the same results. (With
debstd this is one problem. You need exactly the same debstd version than
the maintainer had to get the same package.)
I see.
It would be nice if we could find one (or more) volunteers to do some
experiments on that issue.
Yes, I think it would be a Good Thing.
Thank you,
Marcus
--
Rhubarb is no Egyptian god. Debian GNU/Linux
Marcus Brinkmann http://www.debian.org
[EMAIL PROTECTED]
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Hi all!
This is my first message on this mailing list, I am sorry if I am not
allowed to talk.
On Mon, 5 Jan 1998, Topi Miettinen wrote:
Hamish Moffatt writes:
Maybe because if the admin changes the /etc/crontab, it might be difficult
to merge in the modifications.
We have cron.{month,week,dai}ly, why not add directories hourly, bihourly
(every 30min), and quarterly (every 15min). That would give enough
resolution for most daemons.
I'd rather use cron for timing than daemon's built-in functionality:
- less swapped-out daemons
- more flexible configuration
-Topi
What about a kind of tag-oriented style of appending to /etc/crontab after
asking the admin:
ipac-install suggest to append an entry to /etc/crontab, which starts ipac
every 15 minutes:
[line to be inserted]
The lines will be enclosed by # -*- install: ipac -*-.
This way a remove script will be able to remove the lines which were
inserted by install.
cu
Torsten
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake debian? (was: Re: cron jobs more often than daily)
On Mon, Jan 5 1998 20:08 +0100 Christian Schwarz writes: Automake does support the GNU standard, a less restrict one, and (perhaps) the gnits standard (the new GNU standard). Will there be automake support for Debian packages ? [...] However, doubts have been presented that it does not fit exactly to our purposes. Someone would have to do some experiments on this. If it doesn't fit, we can use or write another macro generator.) I played over the christmas holidays with autoconf and automake (for use in my rpncalc package). My conclusions: - the generated Makefiles and configure.in's are too strict: e.g. a) they require that the COPYING (GPL) file is present, b) they test whether the cc is gcc (which we already know it is), c) they test whether the libc-headers are ANSI-compliant (which we already know they are) d) they test whether the signal returning type is void (which it is and should be) etc. ad nausaum. Shortly put, most of the test are appropriate for SunOS 4 but not for Debian (GNU libc2, gcc, POSIX.1 and nearly X/OPEN compliant) and are a waste of time. Of course, some m4 guru could put together an Debianized set of autoconf macros... David -- David Frey (51F35923114FC864 7D05FF173C61EFDE) Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake debian? (was: Re: cron jobs more often than daily)
On Mon, 5 Jan 1998, David Frey wrote: On Mon, Jan 5 1998 20:08 +0100 Christian Schwarz writes: Automake does support the GNU standard, a less restrict one, and (perhaps) the gnits standard (the new GNU standard). Will there be automake support for Debian packages ? [...] However, doubts have been presented that it does not fit exactly to our purposes. Someone would have to do some experiments on this. If it doesn't fit, we can use or write another macro generator.) I played over the christmas holidays with autoconf and automake (for use in my rpncalc package). My conclusions: - the generated Makefiles and configure.in's are too strict: e.g. a) they require that the COPYING (GPL) file is present, b) they test whether the cc is gcc (which we already know it is), c) they test whether the libc-headers are ANSI-compliant (which we already know they are) d) they test whether the signal returning type is void (which it is and should be) etc. ad nausaum. Shortly put, most of the test are appropriate for SunOS 4 but not for Debian (GNU libc2, gcc, POSIX.1 and nearly X/OPEN compliant) and are a waste of time. Of course, some m4 guru could put together an Debianized set of autoconf macros... Automake is much less strict if invoked with the --foreign option. As for all the various autoconf tests, so what if it tests for stuff we know is true? It is what makes everything more portable to whatever you want it to compile on. -- Scott K. Ellis [EMAIL PROTECTED] http://www.gate.net/~storm/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
[EMAIL PROTECTED] (Christian Schwarz) wrote on 05.01.98 in [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
[EMAIL PROTECTED] (Christian Schwarz) wrote on 05.01.98 in [EMAIL PROTECTED]: On 5 Jan 1998, Karl M. Hegbloom wrote: Perhaps the /etc/crontab shouldn't be a conffile; but created by the installation scripts? Since /etc/crontab is actually a conffile (no matter if you tag it as such or not) this would be a dirty hack around our policy. Nope, that would be the correct solution. Conffiles modified by scripts are the dirty hacks, because dpkg's conffile mechanism isn't set up to cope with them. The packages those files and scripts belong to don't have anything to do with it. If the policy manual says otherwise, that's a bug. Fact is, that the cron package, the local sysadmin, and possibly other packages modify the /etc/crontab file. However, dpkg only controls modification between the sysadmin and _one_ package (cron here). I Wrong. Dpkg only controls modification between sysadmin and package maintainer; _no_ additional script changes work right. really think the cron package should provide a script where other packages can register cron jobs. _And_ not keep the file as a conffile, _and_ not keep it in the .deb. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake debian? (was: Re: cron jobs more often than daily)
David Frey [EMAIL PROTECTED] writes: Shortly put, most of the test are appropriate for SunOS 4 but not for Debian (GNU libc2, gcc, POSIX.1 and nearly X/OPEN compliant) and are a waste of time. Of course, some m4 guru could put together an Debianized set of autoconf macros... If I get some free time tonight or tomorrow night, I will (got to be some benefits to hotel rooms :/). -- Stephen --- Normality is a statistical illusion. -- me -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
