Re: PROPOSAL to serialize cron.{daily,weekly,monthly}

[Abdullah Ramazanoglu <ar018@yahoo.com>]

begin  Steve Greenland <steveg@moregruel.net> dedi ki:
> On 07-Sep-04, 17:33 (CDT), Abdullah Ramazanoglu <ar018@yahoo.com> wrote:
>
>> The only plausible answer I can
>> find is, since cron doesn't serialize the jobs, and since anacron does
>> have such an option, and since these jobs got to be serialized, then the
>> responsibility to drive cron.xxxly jobs has been taken from cron (which
>> has the ability to trigger at exact times) and given to anacron (which
>> has the ability to trigger at intervals).
> 
> Your obsession with serialization is leading you astray. I think you need
> to read the description of anacron, and think about the *real* reason
> anacron is running those jobs. It's got nothing to do with serialization,
> and everything to do with machines that are not running 24x7.
> 
>> because cron.xxxly jobs, by definition, has got to be run at exact
>> precise times
> 
> Why? The term "weekly" is not an precise time description. There is no
> need for weekly jobs and monthly jobs to be in some sort of sync. If there
> were, then the fact that 3 times out of 4 (or 4 out of 5) the monthly job
> doesn't run after the weekly job would be some sort of issue. But it
> isn't.

This is rather an interesting debate, which I am reluctant to delve into,
for it could lead the thread somewhere far from its original starting
point. OTOH my proposal becomes irrelevant if this issue is not addressed.
I will present my own standing point. But I will (have to :) accept it if
the general consensus favors out of sync weekly and monthly runs.

I don't know how other sysadmins do their automated maintenances, but for
me, it is almost vital that weekly jobs start on weekend, and monthly jobs
on 1st of the month.

For a busy intranet server, which is busy all the week, I have only the
weekend for certain "day long" maintenances. Such as force fsck'ing a 1 TB
raid array, detailed/multiple virus scanning etc., which takes nearly all
the day, and (gulp!) rebooting...

This is one heavy example, but most of the time other servers also need
weekly jobs to be run on a specific time too. Day, week and month are some
divisible quantities, and in accordance with this peculiarity, there are
often some special procedures which must be performed at division points
(e.g. week-ends). Such as automated weekly backup, which should reflect
the actual weekly boundary. Or some End-Of-Week business accounting
procedures, which must be done at week boundaries and off business hours.
Or, simply rebooting (OK I know, but for an intranet server months of
uptime is no big deal). There are many more examples which need to be run
precisely on weekends or 1st of month.

Simply put, I have always found myself in need of running certain
procedures at such precise times. I don't know how others manage.

Put another way, I can't imagine an unsuspecting or unsophisticated
sysadmin would guess that his weekly script might run on Wednesday, or
monthly script on 15th of the month.

As a side note, there is one issue left regarding the audience of
cron.xxxly jobs. I have seen some mentions of Debian itself having no
problems with the current scheme. If there is a general concensus that
cron.xxxly is solely for Debian-internal maintenance, and sysadmins should
not use this mechanism, then I withdraw my proposal. But if sysadmins are
allowed to use this mechanism for their own private maintenance needs,
then I would like to point out that it is not relevant whether Debian, in
itself, works successfully with this scheme or not.

>> Anacron is meant to be a fallback mechanism, it is a fallback mechanism,
>> and it should be used as such. Using it as a primary means for any
>> scheduling is a misuse, and invites unforeseen slip offs, IMHO.
> 
> Perhaps there are reasons for the current setup. Perhaps the cron and
> anacron maintainers aren't idiots. (Well, at least the anacron
> maintainer.)

Uh, sorry if I offended anyone. I really didn't mean it. Perhaps I was a
bit too excited or my general approach was a bit rough, but I didn't mean
to be ranting.

> Cron and anacron have to be able to work together. The current setup is
> designed to keep them from stepping on each other, and running jobs
> multiple times.  We've *thought* about this.

Doesn't my proposal address this issue as well? Anacron and cron doesn't
step on each other, cron manages precise timings with serialized batches,
while anacron stands-by as the fallback. And its behavior is the same,
independent of whether anacron is installed or not. I use it for more than
a year and I'm happy with it so far.

Now, I don't want to be in a position of pushing my own proposal. Kind of
embarrassing to me. I just proposed and if it's found useful as-is or
after correction, then I'm happy that I've actually been able to
contribute something. If it's rejected, well, at least I've done my bit. I
really don't want to push it anymore.

>> So, I would like to improve on my original proposition, and I now
>> propose that anacron should only be used as a fallback mechanism, and
>> cron.xxxly should be given under cron's sole control, and a means (other
>> than anacron) should be employed to serialize cron.xxxly jobs.
> 
> No. You've invented a requirement that doesn't exist. If you want to do
> something useful, go work on fcron so that it is a drop-in replacement for
> cron, and can we can use it instead of the anacron-cron combo.

I would be glad to. But I'm more a sysadmin than a programmer, and I
couldn't find enough free time even for my own package: It's stalled for
more than a year.

-- 
Abdullah        | aramazan@ |
Ramazanoglu     | myrealbox |
________________| D.0.T cöm |__