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
[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, 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
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
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
49 matches
Mail list logo
