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 <srivasta@...> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Manoj Srivastava <srivasta@...> 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 (rra@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve Langasek]

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/
slangasek@...                                     vorlon@...

[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. <ballombe@...>

Imagine a large red swirl here.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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/
slangasek@...                                     vorlon@...

[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. <ballombe@...>

Imagine a large red swirl here.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

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 <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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/
slangasek@...                                     vorlon@...

[Gerrit Pape]

On Wed, Sep 16, 2009 at 10:32:04PM -0700, Steve Langasek wrote:
> 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.)

Hi, the bcron-run package provides /etc/crontab, which includes

24 4 * * *  root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

Regards, Gerrit.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve Langasek]

On Thu, Sep 17, 2009 at 09:03:22AM +0000, Gerrit Pape wrote:
> On Wed, Sep 16, 2009 at 10:32:04PM -0700, Steve Langasek wrote:
> > 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.)

> Hi, the bcron-run package provides /etc/crontab, which includes

> 24 4 * * *  root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

Ok, then the bcron-run package (but not the bcron package) would meet that
requirement.

--
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/
slangasek@...                                     vorlon@...

[Manoj Srivastava]

On Fri, Sep 18 2009, Steve Langasek wrote:

>>>>        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}

> On Thu, Sep 17, 2009 at 09:03:22AM +0000, Gerrit Pape wrote:
>> On Wed, Sep 16, 2009 at 10:32:04PM -0700, Steve Langasek wrote:
>> > 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.)
>
>> Hi, the bcron-run package provides /etc/crontab, which includes
>
>> 24 4 * * *  root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
>
> Ok, then the bcron-run package (but not the bcron package) would meet that
> requirement.

        So. We have a criteria that would allow for anyone needing to
 set up a periodic cron job, and at least two packages that provide such
 functionality: cron, and bcron-run.

        Is this sufficient to add a virtual package?

        manoj
--
The little pieces of my life I give to you, with love, to make a quilt
to keep away the cold.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve Langasek]

On Tue, Sep 29, 2009 at 01:43:39PM -0500, Manoj Srivastava wrote:
> >> Hi, the bcron-run package provides /etc/crontab, which includes

> >> 24 4 * * *  root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

> > Ok, then the bcron-run package (but not the bcron package) would meet that
> > requirement.

>         So. We have a criteria that would allow for anyone needing to
>  set up a periodic cron job, and at least two packages that provide such
>  functionality: cron, and bcron-run.

>         Is this sufficient to add a virtual package?

Given that there's demand for it, seems fine to me.

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/
slangasek@...                                     vorlon@...

[Manoj Srivastava]

On Thu, Oct 01 2009, Steve Langasek wrote:

> On Tue, Sep 29, 2009 at 01:43:39PM -0500, Manoj Srivastava wrote:
>> >> Hi, the bcron-run package provides /etc/crontab, which includes
>
>> >> 24 4 * * *  root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
>
>> > Ok, then the bcron-run package (but not the bcron package) would meet that
>> > requirement.
>
>>         So. We have a criteria that would allow for anyone needing to
>>  set up a periodic cron job, and at least two packages that provide such
>>  functionality: cron, and bcron-run.
>
>>         Is this sufficient to add a virtual package?
>
> Given that there's demand for it, seems fine to me.

        Do I hear another second? Russ, do you still want policy
 changed, given that the requirements are so pared down now?

        manoj
--
What makes the universe so hard to comprehend is that there's nothing to
compare it with.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bill Allombert-3]

On Mon, Oct 05, 2009 at 10:40:02AM -0500, Manoj Srivastava wrote:

> On Thu, Oct 01 2009, Steve Langasek wrote:
>
> > On Tue, Sep 29, 2009 at 01:43:39PM -0500, Manoj Srivastava wrote:
> >> >> Hi, the bcron-run package provides /etc/crontab, which includes
> >
> >> >> 24 4 * * *  root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
> >
> >> > Ok, then the bcron-run package (but not the bcron package) would meet that
> >> > requirement.
> >
> >>         So. We have a criteria that would allow for anyone needing to
> >>  set up a periodic cron job, and at least two packages that provide such
> >>  functionality: cron, and bcron-run.
> >
> >>         Is this sufficient to add a virtual package?
> >
> > Given that there's demand for it, seems fine to me.
>
>         Do I hear another second? Russ, do you still want policy
>  changed, given that the requirements are so pared down now?

What I like to know is the use case for such virtual package. I know about
popularity-contest cron.daily job, but waht about the other ?

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Mon, Oct 05 2009, Bill Allombert wrote:

> On Mon, Oct 05, 2009 at 10:40:02AM -0500, Manoj Srivastava wrote:
>> On Thu, Oct 01 2009, Steve Langasek wrote:
>>
>> > On Tue, Sep 29, 2009 at 01:43:39PM -0500, Manoj Srivastava wrote:
>> >> >> Hi, the bcron-run package provides /etc/crontab, which includes
>> >
>> >> >> 24 4 * * *  root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
>> >
>> >> > Ok, then the bcron-run package (but not the bcron package) would meet that
>> >> > requirement.
>> >
>> >>         So. We have a criteria that would allow for anyone needing to
>> >>  set up a periodic cron job, and at least two packages that provide such
>> >>  functionality: cron, and bcron-run.
>> >
>> >>         Is this sufficient to add a virtual package?
>> >
>> > Given that there's demand for it, seems fine to me.
>>
>>         Do I hear another second? Russ, do you still want policy
>>  changed, given that the requirements are so pared down now?
>
> What I like to know is the use case for such virtual package. I know about
> popularity-contest cron.daily job, but waht about the other ?

        The original use case was for logfile rotation; but really, thi
 can be for package that needs periodic tasks to be done (devotee would
 like to recommend this, for the processing done during a vote -- while
 devotee does not set up a periodic task on install, the voting
 mechanism would be crippled without a periodic job execution
 mechanism).

        So, the generic use case is any periodic task execution.

        manoj
--
"Confound these ancestors.... They've stolen our best ideas!" Ben Jonson
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Manoj Srivastava <srivasta@...> writes:
> On Thu, Oct 01 2009, Steve Langasek wrote:
>> On Tue, Sep 29, 2009 at 01:43:39PM -0500, Manoj Srivastava wrote:

>>>>> Hi, the bcron-run package provides /etc/crontab, which includes
>>
>>>>> 24 4 * * *  root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

>>>> Ok, then the bcron-run package (but not the bcron package) would meet that
>>>> requirement.

>>>         So. We have a criteria that would allow for anyone needing to
>>>  set up a periodic cron job, and at least two packages that provide such
>>>  functionality: cron, and bcron-run.

>>>         Is this sufficient to add a virtual package?

>> Given that there's demand for it, seems fine to me.

>         Do I hear another second?

Sure, I'll second it.

>  Russ, do you still want policy changed, given that the requirements are
>  so pared down now?

I just want to be sure that we write down the criteria that we came up
with in this thread somewhere so that people know when they can provide
the virtual package.

Separately, I'll note that Policy 9.5 strongly implies that
/etc/cron.d/<file> will work, using "the same syntax as /etc/crontab"
without specifying what that syntax is.  If the Debian project is going to
support alternative cron daemons than the default, we really need to
document what that syntax is so that packages know what to expect and what
they can safely use.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Sun, Oct 11 2009, Russ Allbery wrote:

>>>>        Requirements:
>>>> 1) Be able to run a batch job periodically, as defined in the POSIX
>>>>    standards document.
>>>> 2) Correct execution of /etc/cron.{hourly,daily,weekly,monthly}, as
>>>>    long as the files are conforming to POSIX standards.

>>  Russ, do you still want policy changed, given that the requirements are
>>  so pared down now?
>
> I just want to be sure that we write down the criteria that we came up
> with in this thread somewhere so that people know when they can
> provide the virtual package.
>
> Separately, I'll note that Policy 9.5 strongly implies that
> /etc/cron.d/<file> will work, using "the same syntax as /etc/crontab"
> without specifying what that syntax is.  If the Debian project is going to
> support alternative cron daemons than the default, we really need to
> document what that syntax is so that packages know what to expect and what
> they can safely use.

        I suggest, then, that we follow POSIX (please note that @reboot
 and @daily and other such convenient contractions are not mentioned in
 the standard, though cron(1) supports them):

   http://www.opengroup.org/onlinepubs/009695399/utilities/crontab.html

        The important bits are extracted below.  Should policy add
 support requirements for @reboot et al?

--8<---------------cut here---------------start------------->8--- Upon
execution of a command from a crontab entry, the implementation shall
supply a default environment, defining at least the following
environment variables:

HOME    A pathname of the user's home directory.
LOGNAME The user's login name.
PATH    A string representing a search path guaranteed to find all of
        the standard utilities.
SHELL   A pathname of the command interpreter. When crontab is invoked
        as specified by this volume of IEEE Std 1003.1-2001, the value
        shall be a pathname for sh.

The values of these variables when crontab is invoked as specified by
this volume of IEEE Std 1003.1-2001 shall not affect the default values
provided when the scheduled command is run.

If standard output and standard error are not redirected by commands
executed from the crontab entry, any generated output or errors shall be
mailed, via an implementation-defined method, to the user.

In the POSIX locale, the user or application shall ensure that a crontab
entry is a text file consisting of lines of six fields each. The fields
shall be separated by <blank>s. The first five fields shall be integer
patterns that specify the following:

   1. Minute [0,59]
   2. Hour [0,23]
   3. Day of the month [1,31]
   4. Month of the year [1,12]
   5. Day of the week ([0,6] with 0=Sunday)

Each of these patterns can be either an asterisk (meaning all valid
values), an element, or a list of elements separated by commas. An
element shall be either a number or two numbers separated by a hyphen
(meaning an inclusive range). The specification of days can be made by
two fields (day of the month and day of the week). If month, day of
month, and day of week are all asterisks, every day shall be matched. If
either the month or day of month is specified as an element or list, but
the day of week is an asterisk, the month and day of month fields shall
specify the days that match. If both month and day of month are
specified as an asterisk, but day of week is an element or list, then
only the specified days of the week match. Finally, if either the month
or day of month is specified as an element or list, and the day of week
is also specified as an element or list, then any day matching either
the month and day of month, or the day of week, shall be matched.

The sixth field of a line in a crontab entry is a string that shall be
executed by sh at the specified times. A percent sign character in this
field shall be translated to a <newline>. Any character preceded by a
backslash (including the '%' ) shall cause that character to be treated
literally. Only the first line (up to a '%' or end-of-line) of the
command field shall be executed by the command interpreter. The other
lines shall be made available to the command as standard input.

Blank lines and those whose first non- <blank> is '#' shall be ignored.
--8<---------------cut here---------------end--------------->8---

        Given that, should this be duplicated in a normative section of
 policy? Or can we just vaguely hand wave the reader over to POSIX? Or
 add this as an informative footnote?

        manoj
--
Use what talents you possess: the woods would be very silent if no birds
sang there except those that sang best.  -- Henry Van Dyke
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Manoj Srivastava <srivasta@...> writes:

>         I suggest, then, that we follow POSIX (please note that @reboot
>  and @daily and other such convenient contractions are not mentioned in
>  the standard, though cron(1) supports them):

>    http://www.opengroup.org/onlinepubs/009695399/utilities/crontab.html

>         The important bits are extracted below.  Should policy add
>  support requirements for @reboot et al?

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?)

>         Given that, should this be duplicated in a normative section of
>  policy? Or can we just vaguely hand wave the reader over to POSIX? Or
>  add this as an informative footnote?

I would prefer to point people to POSIX but document the above exceptions,
similar to how we do for /bin/sh.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Gerrit Pape]

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

Regards, Gerrit.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Gerrit Pape <pape@...> 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 (rra@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...