Re: [PROPOSAL] Cron jobs
On Fri, Mar 12, 1999 at 12:13:57AM -0800, Daniel Quinlan wrote:
> Actually, it's the other way around. /etc/cron.d requires you to
> understand the crontab format. /etc/cron.<period> just requires you
> to plop a shell script into a directory.
crontab's format is not that complicated. The argument has also been
made that anacron enables users/administrators to configure shell
scripts - if you take this position, my response is that shell script
syntax is far more complex than the crontab format.
> > No. What is the rationale? Vixie cron works just fine, except,
> > perhaps that it assumes a box is up 24x7. If a box isn't up 24x7,
> > why is it so critical to specify anacron?
>
> The box may not be up 24x7. We may want to provide a way for cron
> jobs to work on boxes that aren't up 24 hours a day.
Agreed. I was looking at it from the point of view of a server, which
is up 24x7, and thinking that a user box is not as critical - I'm sure
the user would think otherwise. :-)
> > Leading with my chin, I ask "Have emerged as de-facto Linux standards"?
> > for whom? News to me.
>
> I meant /etc/cron.(daily|weekly|monthly) was a standard, not cron.d.
And that's what I was questioning. A quick look at the Linux systems I
use and to which I have access don't have anacron or it's directories.
The argument about following current usage or specifying something
different has been raised before, though, and I don't want to start it
up again.
> > Noted and agreed. Is there any value in stating that non-cron-type
> > schedulers should leave /etc/cron.d alone?
>
> Well, then they would be violating the LSB specification, wouldn't
> they? (We can specify that the cron software must handle things as
> specified by the cron manuals.)
Mis-read that paragraph.
--
Kurt
Informix on Linux FAQ => http://www.xmission.com/~kwall
Reply to: