mouss wrote:

> Andrew Brown wrote:

> > yes, you could make all that happen from cron, but (a) cron does not
> > do all those little things, and (b) cron should *not* do all those
> > little things.

> as long as cron is what it is, this is unbeatable. it's already not easy 
> to solve cron problems (cron leaves to you to handle dst, to choose a 
> date/time to run something when you don't care what hour but only want 
> it to run once, ...). Adding more "intelligence" into cron would 
> certainly break something (unless of course if cron is redesigned from 
> semi-scratch... but we're not there, are we?).
> 
> I once realized that I didn't get any daily mail since 4 days, and since 
>   daily means everyday, that wasn't fair. checking the system, I found 
> that my silly-quick-and-dirty script to parse ipf logs took too long 
> (many days cos I was logging too much). Of course, the approach wasn't 
> correct. however, whatever the specs of cron are (where are they?), 
> nothing I know of ever said "beware the long running scripts".

Perhaps what we need is some sort of job queuing system.  I worked
at a place once where they wrote a "filter" for lpd that ran a
shell script, rather than send a file to a printer.  It was rather
scary, just because lpq would list things that you knew were never
headed for a printer, and didn't even look like they should be
printed.  This was mostly because they were making an existing
system do double duty without much (any) warning or documentation
except general "group knowledge".

However, despite those faults, it was very good at getting loaded
up with lots of things to do, and doing them one at a time until
it ran out, no matter how long each individual job took.

Jon