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, ).
> > If there was heavy use of /
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 favou
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
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.
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 < /etc/crontab.tmp
> > # DO NOT EDIT THIS FILE. It will be overwritten by the up
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
Remco Blaakmeer <[EMAIL PROTECTED]> wrote:
> The update-cron script could be very simple, like:
>
> #!/bin/sh
> cat < /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 .
> #
> E
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 w
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 exact
> 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 cronta
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, th
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
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 w
"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
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", aft
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 ab
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.of
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 rul
[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
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-
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
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. wi
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 touche
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
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,
> tha
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 unders
| 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 pac
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
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 /et
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]
>
> Th
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 mrt
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 shoul
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
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 som
[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
[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 abo
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 ?
> [...]
> >
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 no
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
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 ?
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 examp
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 ot
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-mai
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 "un
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 mac
> "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 ca
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.mainte
elopers 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
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.
:
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
mod
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 ide
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 /e
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/cront
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 th
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 li
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 o
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 summarie
57 matches
Mail list logo
