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

[Abdullah Ramazanoglu <ar018@yahoo.com>]

begin  Abdullah Ramazanoglu <ar018@yahoo.com> dedi ki:
> begin  "Artur R. Czechowski" <arturcz@hell.pl> dedi ki:
>> On Tue, Sep 07, 2004 at 06:31:35PM +0300, Abdullah Ramazanoglu wrote:
>>
>>> Here is the problem: Anacron works as a fall back mechanism where cron
>>> fails, due to various reasons, to do its job. In a normal 7/24 system
>>> anacron never kicks in cron.xxxly batches, as cron does its job
>>> successfully. Note that /etc/cron.d/anacron starts anacron at 7:30,
>>> whereas cron starts cron.{daily,weekly,monthly} at 6:25, 6:47 and 6:52
>>> respectively.
>>
>> Are you sure? Let's look into /etc/crontab:
>> 25 6 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
>> then, for legibility, let's separate a command:
>> test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
>> and analyze them.
>> test -x /usr/sbin/anacron means "/usr/sbin/anacron is runnable for me"
>> so, the whole command:
>> /usr/sbin/anacron is runnable for me OR execute run-parts.
>> 
>> If you have installed anacron the first part is true and run-parts wont be
>> executed. The same for weekly/monthy at 6:47 and 6:52. Then at 7:30 anacron
>> shall be run.
> 
> Hmm, you're right. Sorry for the confusion. It's been a bit of time to
> remember but I guess I must have first installed just cron, and later on
> crontab when my serialization fix was already in place for some time,
> which bypasses anacron check. Then I've overlooked the fact that anacron
> doesn't kick in because of my own changes to crontab.

Ooops! A minute please. I just remembered why I disabled anacron checks
now. (It's been more than a year...)

Well, there was a really inconvenient behavior, bordering a bug, with
using anacron for cron.xxxly : It was breaking the timing sync of
cron.weekly to week-ends and cron.monthly to start of months.

Because anacron does not work based on exact time to trigger, but it does
work based on equally paced strides. I.e. it doesn't run weekly jobs on
Sunday, but it runs them in 7 day periods. Now consider that your system
was off for Saturday to Tuesday. If you boot the system on Wednesday noon,
anacron would fire off the overdue weekly job, and stamp it with Wednesday
noon. From then on, your cron.weekly would be run, by anacron, on the
midst of Wednesdays! The solution was, if you sync your weekly jobs once,
and never stop your system for more than a day, then anacron would not
deviate from Sundays. But this is a very awkward thing to do.

OTOH, for monthly jobs even syncing anacron to 1st of month and then never
stopping 7/24 operation wouldn't do any good. Because anacron runs monthly
jobs not at 1st day of a month, but in 30 (or 31) days period. This will
slowly but surely drift the day of month on which cron.monthly runs.

In woody this is the situation. I don't know if it is fixed in Sarge.
According to Travis and Pascal's posts anacron now uses "@monthly" instead
of "30" as the monthly period. This hints that the problem might have been
solved in Sarge.

But once again, if we take a couple of steps back and look at the whole
setup again, there is something awkward (at least to me) in leaving
cron.xxxly jobs to anacron's management. 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). Thus, just because cron couldn't
serialize the jobs, a whole new range of problems have been introduced
into cron.xxxly handling.

Whether anacron has fixed this interval based behavior or not, I feel that
the responsibility should be taken from anacron and given back to cron,
because cron.xxxly jobs, by definition, has got to be run at exact precise
times, and this is cron's job. 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.

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.

> Well, this defeats 3 legs of my previous case, I guess. Still a leg
> remains, however. Namely, syncing the behavior of cron with anacron, so it
> would be a more consistent system, regardless of whether anacron is
> installed or not.
> 
> Thank you for clearing up the issue.

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