Bug#391836: debian-policy: New virtual package: cron-daemon

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Manoj Srivastava-3
Hi,

        Are there any seconds to the proposal to create a virtual
 package cron-daemon? The rationale is for packages like logratate,
 which otherwise would need to depend on cron | anacron | fcron | bcron |
 etc.

        The requirements for providing cron-daemon are:
 [ POSIX ]
 - Has to provide /usr/bin/crontab and support crontab entries
 [ Implemented in most Linux / BSD distributions, including Debian, but not
   in Solaris, HP-UX or AIX's cron ]
 - Correct execution of /etc/cron.d
 - Correct support of /etc/crontab
 - Correct support of /etc/cron.{allow,deny}
 - Has to support 'crontab -u'
 - Support of crontab entries with extended features (i.e. those in Vixie
   Cron need to be supported), these include names for days and months,
   ranges, step values and the 'special strings' (@reboot, @yearly..)
 [ Debian-specific feature ]
 - Correct execution of /etc/cron.{hourly,daily,weekly,monthly}


        Do I hear seconds for this package?

        manoj
--
Elevators smell different to midgets.
Manoj Srivastava <[hidden email]> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Russ Allbery-2
Manoj Srivastava <[hidden email]> writes:

>         Are there any seconds to the proposal to create a virtual
>  package cron-daemon? The rationale is for packages like logratate,
>  which otherwise would need to depend on cron | anacron | fcron | bcron |
>  etc.

>         The requirements for providing cron-daemon are:
>  [ POSIX ]
>  - Has to provide /usr/bin/crontab and support crontab entries
>  [ Implemented in most Linux / BSD distributions, including Debian, but not
>    in Solaris, HP-UX or AIX's cron ]
>  - Correct execution of /etc/cron.d
>  - Correct support of /etc/crontab
>  - Correct support of /etc/cron.{allow,deny}
>  - Has to support 'crontab -u'
>  - Support of crontab entries with extended features (i.e. those in Vixie
>    Cron need to be supported), these include names for days and months,
>    ranges, step values and the 'special strings' (@reboot, @yearly..)
>  [ Debian-specific feature ]
>  - Correct execution of /etc/cron.{hourly,daily,weekly,monthly}

I second the idea provided that we put all of the above into Policy so
that we clearly specify what a Debian cron system should provide.  I'd
like to see us do more of that.  If there's a virtual package, I suspect
that we frequently should be documenting in Policy what a package that
provides that virtual package should be doing.  And in the case of cron,
we already have section 9.5, so adding the additional bits about what we
expect from cron daemons isn't hard.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Steve Langasek
In reply to this post by Manoj Srivastava-3
On Fri, Sep 11, 2009 at 12:54:10AM -0500, Manoj Srivastava wrote:

>         Are there any seconds to the proposal to create a virtual
>  package cron-daemon? The rationale is for packages like logratate,
>  which otherwise would need to depend on cron | anacron | fcron | bcron |
>  etc.

Given how anacron works, I think it fails almost all of the requirements
below, so should not be eligible to declare this virtual package.  fcron's
Conflicts / description suggest it may have a similar problem.  Is this
virtual package still useful in that case?

>         The requirements for providing cron-daemon are:
>  [ POSIX ]
>  - Has to provide /usr/bin/crontab and support crontab entries
>  [ Implemented in most Linux / BSD distributions, including Debian, but not
>    in Solaris, HP-UX or AIX's cron ]
>  - Correct execution of /etc/cron.d
>  - Correct support of /etc/crontab
>  - Correct support of /etc/cron.{allow,deny}
>  - Has to support 'crontab -u'
>  - Support of crontab entries with extended features (i.e. those in Vixie
>    Cron need to be supported), these include names for days and months,
>    ranges, step values and the 'special strings' (@reboot, @yearly..)
>  [ Debian-specific feature ]
>  - Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
This last feature is the only one anacron supports, but a) it doesn't
support cron.hourly, and b) anacron relies on cron for launching via
/etc/cron.d...

Also, cron's handling of /etc/cron.{hourly,daily,weekly,monthly} is simply
done through ordinary /etc/crontab entries... and /etc/crontab is a
conffile.  Should each cron-daemon package provide that conffile?

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Bill Allombert-3
On Fri, Sep 11, 2009 at 02:36:26PM -0700, Steve Langasek wrote:

> On Fri, Sep 11, 2009 at 12:54:10AM -0500, Manoj Srivastava wrote:
>
> >         Are there any seconds to the proposal to create a virtual
> >  package cron-daemon? The rationale is for packages like logratate,
> >  which otherwise would need to depend on cron | anacron | fcron | bcron |
> >  etc.
>
> Given how anacron works, I think it fails almost all of the requirements
> below, so should not be eligible to declare this virtual package.  fcron's
> Conflicts / description suggest it may have a similar problem.  Is this
> virtual package still useful in that case?

Maybe I am confused but anacron depends on cron, so a system with anacron
installed should provide all the feature of cron, right ?

A point of reference: as far as popularity-contest is concerned (one of that
package having a dependency on cron) the only feature required is support for
/etc/cron.daily. So a case could be made for a cron-daemon virtual package
with a much smaller interface.

Cheers,
--
Bill. <[hidden email]>

Imagine a large red swirl here.



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Steve Langasek
On Mon, Sep 14, 2009 at 03:15:41PM +0200, Bill Allombert wrote:
> On Fri, Sep 11, 2009 at 02:36:26PM -0700, Steve Langasek wrote:
> > On Fri, Sep 11, 2009 at 12:54:10AM -0500, Manoj Srivastava wrote:

> > >         Are there any seconds to the proposal to create a virtual
> > >  package cron-daemon? The rationale is for packages like logratate,
> > >  which otherwise would need to depend on cron | anacron | fcron | bcron |
> > >  etc.

> > Given how anacron works, I think it fails almost all of the requirements
> > below, so should not be eligible to declare this virtual package.  fcron's
> > Conflicts / description suggest it may have a similar problem.  Is this
> > virtual package still useful in that case?

> Maybe I am confused but anacron depends on cron, so a system with anacron
> installed should provide all the feature of cron, right ?

Nope, anacron Recommends: cron.

> A point of reference: as far as popularity-contest is concerned (one of that
> package having a dependency on cron) the only feature required is support for
> /etc/cron.daily. So a case could be made for a cron-daemon virtual package
> with a much smaller interface.

Well, I don't think I would call that virtual package "cron-daemon" then.
"cron-daily"?

Cheers,
--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Bill Allombert-3
On Mon, Sep 14, 2009 at 09:32:25AM -0700, Steve Langasek wrote:

> On Mon, Sep 14, 2009 at 03:15:41PM +0200, Bill Allombert wrote:
> > On Fri, Sep 11, 2009 at 02:36:26PM -0700, Steve Langasek wrote:
> > > On Fri, Sep 11, 2009 at 12:54:10AM -0500, Manoj Srivastava wrote:
>
> > > >         Are there any seconds to the proposal to create a virtual
> > > >  package cron-daemon? The rationale is for packages like logratate,
> > > >  which otherwise would need to depend on cron | anacron | fcron | bcron |
> > > >  etc.
>
> > > Given how anacron works, I think it fails almost all of the requirements
> > > below, so should not be eligible to declare this virtual package.  fcron's
> > > Conflicts / description suggest it may have a similar problem.  Is this
> > > virtual package still useful in that case?
>
> > Maybe I am confused but anacron depends on cron, so a system with anacron
> > installed should provide all the feature of cron, right ?
>
> Nope, anacron Recommends: cron.

Ah right...

> > A point of reference: as far as popularity-contest is concerned (one of that
> > package having a dependency on cron) the only feature required is support for
> > /etc/cron.daily. So a case could be made for a cron-daemon virtual package
> > with a much smaller interface.
>
> Well, I don't think I would call that virtual package "cron-daemon" then.
> "cron-daily"?

I agree. A survey of package depending on cron is in order.

Cheers,
--
Bill. <[hidden email]>

Imagine a large red swirl here.



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Manoj Srivastava
In reply to this post by Steve Langasek
On Fri, Sep 11 2009, Steve Langasek wrote:

> On Fri, Sep 11, 2009 at 12:54:10AM -0500, Manoj Srivastava wrote:
>
>>         Are there any seconds to the proposal to create a virtual
>>  package cron-daemon? The rationale is for packages like logratate,
>>  which otherwise would need to depend on cron | anacron | fcron | bcron |
>>  etc.
>
> Given how anacron works, I think it fails almost all of the
> requirements below, so should not be eligible to declare this virtual
> package.  fcron's Conflicts / description suggest it may have a
> similar problem.  Is this virtual package still useful in that case?

        Hmm. You do have a point. However, the  original use case was
 for a package to be able to have it's log files rotated periodically,
 and by that criteria cron, anacron, fcron, and bcron do fit the bill.

        I think perhaps we need to pare down the requirements (and
 perhaps change the name of the virtual package), so that packages that
 just want a periodic job scheduler don't have to specify a list of
 matching providers.

        Requirements:
 1) Be able to run a batch job periodically.
 2) Correct execution of /etc/cron.{hourly,daily,weekly,monthly}

        These schedulers claim to be drop in replacements of Vixie cron:
 cron, bcron

        fcron says that is implements most of what Vixie cron does; but
 does not claim to be a drop in replacement.

        Anacron does not seem to make any claims about vixie cron
 compatibility at all.

        However, all of them should meet the bill, as far as the
 original use case goes.

        manoj
--
Hope that the day after you die is a nice day.
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Steve Langasek
On Tue, Sep 15, 2009 at 04:45:26PM -0500, Manoj Srivastava wrote:
> >>         Are there any seconds to the proposal to create a virtual
> >>  package cron-daemon? The rationale is for packages like logratate,
> >>  which otherwise would need to depend on cron | anacron | fcron | bcron |
> >>  etc.

> > Given how anacron works, I think it fails almost all of the
> > requirements below, so should not be eligible to declare this virtual
> > package.  fcron's Conflicts / description suggest it may have a
> > similar problem.  Is this virtual package still useful in that case?

>         Hmm. You do have a point. However, the  original use case was
>  for a package to be able to have it's log files rotated periodically,
>  and by that criteria cron, anacron, fcron, and bcron do fit the bill.

fcron doesn't appear to run cron.daily by default, and neither does bcron.
*Only* the cron package ships a crontab that runs /etc/cron.daily by
default; anacron also supports running cron.daily, but relies on cron itself
to trigger it on a daily basis.  (Without cron installed, anacron will only
rotate logs when you reboot.)

I don't think we should relax the requirements when that still only leaves
us one package that satisfies them.  Instead, we ought to make sure that we
have a set of requirements that make sense for what the reverse-dependencies
need, and withhold use of a virtual package until there's more than one
package actually meeting those requirements.

>         I think perhaps we need to pare down the requirements (and
>  perhaps change the name of the virtual package), so that packages that
>  just want a periodic job scheduler don't have to specify a list of
>  matching providers.

>         Requirements:
>  1) Be able to run a batch job periodically.
>  2) Correct execution of /etc/cron.{hourly,daily,weekly,monthly}

[...]

Anacron will always fail the /etc/cron.hourly requirement, too...

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Russ Allbery-2
Gerrit Pape <[hidden email]> writes:
> On Tue, Oct 13, 2009 at 01:43:57PM -0700, Russ Allbery wrote:

>> I suspect that we need to document that packages may rely on @reboot,
>> @yearly, @monthly, @weekly, @daily, and @hourly, and also on the */2
>> syntax.  We also need to document that, contrary POSIX, files in
>> /etc/cron.d have seven fields instead of six, with the sixth field
>> naming the local user as which the cron job runs.  That's a common
>> error when writing cron.d files.
>>
>> Do both of our proposed cron daemons support that same syntax?  (Does
>> anyone here use bcron to comment on that?)

> bcron supports the */n syntax, but not @reboot and the other @*.  See
> http://manpages.debian.net/cgi-bin/man.cgi?query=bcrontab&sektion=5

Hm.  I wonder how many packages that ship cron.d files expect the @* stuff
to work.  If none, then maybe we should document that packages shouldn't
rely on it.

Everything other than @reboot is trivial to replace.  @reboot is a lot
trickier, although I suspect most packages use an init script.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Raphael Hertzog-3
On Wed, 14 Oct 2009, Russ Allbery wrote:

> >> Do both of our proposed cron daemons support that same syntax?  (Does
> >> anyone here use bcron to comment on that?)
>
> > bcron supports the */n syntax, but not @reboot and the other @*.  See
> > http://manpages.debian.net/cgi-bin/man.cgi?query=bcrontab&sektion=5
>
> Hm.  I wonder how many packages that ship cron.d files expect the @* stuff
> to work.  If none, then maybe we should document that packages shouldn't
> rely on it.
>
> Everything other than @reboot is trivial to replace.  @reboot is a lot
> trickier, although I suspect most packages use an init script.

As a user, I got used to rely on @reboot to start services (like an irc
proxy).

And I have used it in packages (outside of Debian though) as well because
init scripts are a pain nowadays compared to this simple solution (need to
write meta-information to order the boot, etc).

It would be nice if we could mandate its support.

Cheers,
--
Raphaƫl Hertzog



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Giacomo Catenazzi
Raphael Hertzog wrote:

> On Wed, 14 Oct 2009, Russ Allbery wrote:
>>>> Do both of our proposed cron daemons support that same syntax?  (Does
>>>> anyone here use bcron to comment on that?)
>>> bcron supports the */n syntax, but not @reboot and the other @*.  See
>>> http://manpages.debian.net/cgi-bin/man.cgi?query=bcrontab&sektion=5
>> Hm.  I wonder how many packages that ship cron.d files expect the @* stuff
>> to work.  If none, then maybe we should document that packages shouldn't
>> rely on it.
>>
>> Everything other than @reboot is trivial to replace.  @reboot is a lot
>> trickier, although I suspect most packages use an init script.
>
> As a user, I got used to rely on @reboot to start services (like an irc
> proxy).
>
> And I have used it in packages (outside of Debian though) as well because
> init scripts are a pain nowadays compared to this simple solution (need to
> write meta-information to order the boot, etc).
>
> It would be nice if we could mandate its support.

But OTOH @reboot has a "feature" which could confuse users:
@reboot (on std cron) is called sometime earlier as expected in the
init.d sequence.
And I think the new dependency based init it could make it worse.

IMO I really think that packages should use the init.d script instead of
rely @reboot, allowing @reboot only for sysadmin: better to have a unique
method for "init.d"-like scripts, and to use the full features of new
booting system.
But in this case we doesn't need @reboot in the policy.

In the other case, I think we need to specify in policy when @reboot is
called, and which services should be available.

ciao
        cate

PS: priority of cron: S89 (old style) and "$remote_fs $syslog $time"
new style.



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Bill Allombert-3
On Thu, Oct 15, 2009 at 09:18:45AM +0200, Giacomo A. Catenazzi wrote:

> Raphael Hertzog wrote:
>> On Wed, 14 Oct 2009, Russ Allbery wrote:
>>>>> Do both of our proposed cron daemons support that same syntax?  (Does
>>>>> anyone here use bcron to comment on that?)
>>>> bcron supports the */n syntax, but not @reboot and the other @*.  See
>>>> http://manpages.debian.net/cgi-bin/man.cgi?query=bcrontab&sektion=5
>>> Hm.  I wonder how many packages that ship cron.d files expect the @* stuff
>>> to work.  If none, then maybe we should document that packages shouldn't
>>> rely on it.
>>>
>>> Everything other than @reboot is trivial to replace.  @reboot is a lot
>>> trickier, although I suspect most packages use an init script.
>>
>> As a user, I got used to rely on @reboot to start services (like an irc
>> proxy).
>>
>> And I have used it in packages (outside of Debian though) as well because
>> init scripts are a pain nowadays compared to this simple solution (need to
>> write meta-information to order the boot, etc).
>>
>> It would be nice if we could mandate its support.
>
> But OTOH @reboot has a "feature" which could confuse users:
> @reboot (on std cron) is called sometime earlier as expected in the
> init.d sequence.
> And I think the new dependency based init it could make it worse.

non-root users do not have much alternatives.

> IMO I really think that packages should use the init.d script instead of
> rely @reboot, allowing @reboot only for sysadmin: better to have a unique
> method for "init.d"-like scripts, and to use the full features of new
> booting system.
> But in this case we doesn't need @reboot in the policy.

I agree that packages should not use @reboot, and that therefore there is
little point in mentionning it in policy.

Cheers,
--
Bill. <[hidden email]>

Imagine a large red swirl here.



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#391836: debian-policy: New virtual package: cron-daemon

Russ Allbery-2
Bill Allombert <[hidden email]> writes:
> On Thu, Oct 15, 2009 at 09:18:45AM +0200, Giacomo A. Catenazzi wrote:

>> IMO I really think that packages should use the init.d script instead
>> of rely @reboot, allowing @reboot only for sysadmin: better to have a
>> unique method for "init.d"-like scripts, and to use the full features
>> of new booting system.  But in this case we doesn't need @reboot in the
>> policy.

> I agree that packages should not use @reboot, and that therefore there is
> little point in mentionning it in policy.

Well, I think Raphael was also arguing that it would be nice for any
package that provides the virtual package to also provide that feature.
Although given that the one package that wants to provide that virtual
package in addition to the normal cron daemon doesn't support it, that
does seem like too strong of a requirement at the moment if we're going
forward with defining a virtual package.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]