Subject: Re: Implementing periodic.d
To: Andrew Brown <firstname.lastname@example.org>
From: mouss <email@example.com>
Date: 04/20/2004 00:44:07
Andrew Brown wrote:
> one other thing to remember is that the wrapper script, which we now
> call daily or security or weekly or monthly (why don't we have a
> yearly?) does other things *around* the "jobs" it runs, like creating
> a secure temporary work directory, making sure it gets cleaned up,
> mailing the report in total to a specified address, etc.
> 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".
As a result, if it can't be proved that periodic.d/foo.sh will finish
soon, it should be run in the bg. but this implies all scripts will run
in bg (unless we choose to have a variable that says whether a script is
fast or not, which isn't very fancy nor rigourous). then we got the log
problem. a solution would be to have a "log" script (that is "send the
logs to someone/somewhere") at the end of a "group" of cron tasks (such
Anyway, doing it with small scripts has the advantage of solving "today"
problems. it's simple and there will be ways to solve whatever problem
is found. I'd say go for periodic[.d]/[daily|weekly|monthly]. Other dirs
would be just over-engineering (unless someone explains why we would