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 <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
