[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PROPOSAL] Cron jobs



On Fri, Mar 12, 1999 at 03:04:33AM -0500, Cristian Gafton wrote:
> On Fri, 12 Mar 1999, Kurt Wall wrote:
> > Why not just put the /etc/cron.daily|weekly|monthly tables into
> > /etc/cron.d, too?  What does this buy the spec?  Or the user, for that
> > matter?  Drop it all into cron.d and you look one place and one place
> > only.  It seems simpler.

Well, that was a stupid thing to say.  Mixing files from two different
cron-ish implementations isn't very smart.  Posting at at 1:00 a.m. ...

> No, it is not simpler. It is one thing to drop a 10k shell script in
> /etc/cron.daily just as a shell script and not worry about crontab format,
> and is another thing to make that shell script fit under /etc/crontab
> syntax. And any sort of hack it is just plain ugly. The /etc/cron.d is
> intended for simple one line commands, while /etc/cron.daily can possibly
> include shell scripts that are configurable by the user.

The argument that a 10K shell/perl/python/whatever script is simpler than 
writing a one-line wrapper around the same script and executing it from 
/etc/cron.d/ begs the question.  But, I agree that the one-line wrapper is 
an ugly hack.  I agree that anacron provides greater flexibility for both
user and administrator and provides the added benefit of making sure that 
jobs do get run on a box that isn't 24x7.

> > 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?
> 
> Yeah, right. tell that to a laptop user and see what kind of feedback you
> get from him. Anacron is so much nicer and requires virtually no effort
> for integration, while providing many advantages.

This objection is to specifying a particular product, not to the idea.  If
we specify anacron, and a better mousetrap comes along next year, vendors
either support an inferior product, break the standard in order to switch
to the new product, or ship both, adding to their workload (not that
managing 77k is so bad, but you get the idea).

Is specifying the behavior we want worse than specifying a particular
implentation?
 
-- 
Kurt
The likelihood of a software project's success is inversely proportional
to the number of managers involved in it.


Reply to: