G T Smith wrote:
I double checked the man pages. I remember at one time there was a
difference between the syntax for various types of crontab files, but
this seems to have changed and this no longer seem to be the case if the
5 crontab man page is to be believed.
This is on 10.0; but I doubt that it is different on later SUSEs.
(Sorry for the line breaks, Seamonkey is too dumb here.)
In the cron man page, 2nd paragraph:
Cron
also searches for /etc/crontab and the files in the /etc/cron.d
direc-
tory, which are in a different format (see crontab(5)).
I.e., there _are_ different formats.
In the crontab man page, roughly on line 50:
The format of a cron command is very much the V7 standard, with
a num-
ber of upward-compatible extensions. Each line has five time
and date
fields, followed by a user name if this is the system crontab
file,
followed by a command.
This spells out the different crontab syntax: the additional user
name as sixth column in system crontab files.
There is an irritation that the man page continues to talk about
the 6th command column later on; where it is really the 6th or 7th,
depending on the type of crontab, as cited above.
/etc/cron.d seems to be rarely
used by anything in SuSE , and seems to be a bit of an anomaly as its
effective role is covered by /etc/crontab and the /etc/cron.<time>
directories. I presume it is still there for standards related reasons.
No, sorry, not at all. /etc/cron.d/ is *very* valuable.
It is needed if one
(a) wants to be able to install and de-install a cron file without
changing /etc/crontab, e.g., by a package,
(b) wants to have precise control when the cron job runs,
and/or
(c) needs other intervals or other times than the one supplied
by /etc/cron.<time>.
In fact, Mohamed supplied a perfectly valid example here: He wants
to execute a cron job every quarter of an hour and another one
every minute. Both are not possible to do with /etc/cron.<time>.
I'm quite sure that his problems have nothing to do with his
crontab format. If his cron service is activated and works for
other jobs, it's probably related to wrong access rights
(executable, group-writable), or the command itself needs
environment variables from /etc/profile that are not availabe in
cron's environment, or other typical cron problems.
There also seems to a lack of clarity in the documentation about the
default shell used, one part suggests that cron automatically selects
/bin/sh but another that it is obtained from the user account
settings...
Yes, the comment in the example section is misleading.
(Interestingly, the crontab(5) man page in Debian has a better
example here.)
if the former is the case then the SHELL=/bin/sh statement
in /etc/crontab is redundant unless this is what the statement means
Yes, it is.
(the question then is do the entries in cron.d inherit the /etc/crontab
settings?).
No, each crontab file needs the settings anew.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: [EMAIL PROTECTED]
Roedermark, Germany
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
