Re: PROPOSAL to serialize cron.{daily,weekly,monthly}
begin Steve Greenland <steveg@moregruel.net> dedi ki:
> On 04-Sep-04, 20:45 (CDT), Abdullah Ramazanoglu <ar018@yahoo.com> wrote:
>
>> Current Situation:
>> cron.daily, cron.weekly, and cron.monthly gets triggered off at specific
>> times (everyday at 6:25, Sunday at 6:47 and 1st of the month at 6:52,
>> respectively) regardless of whether previous batch of maintenance scripts
>> has finished or not. This may result in parallel execution of scripts from
>> several batches, although each batch in itself is serialized. This, in
>> turn, can cause consequences ranging from wrong output to fatal script
>> clash. For instance a script from cron.daily might be scanning the volumes
>> for viruses, while a script from cron.weekly kicks in, force-unmounts
>> several volumes (killing the processes using those volumes BTW) and starts
>> backing up them. Examples are endless.
>
> Yes, one can always put together a system to screw one's self. Don't do
> that.
>
> Your complicated solution doesn't account for other crontabs (in
> /etc/cron.d, or root's user crontab). So it doesn't solve the problem.
I have managed it to look more complicated than what it actually is: It is
just about disabling weekly and monthly entries in crontab and anacrontab,
and putting a two-liner (zzz-daily) to be executed last, into cron.daily.
What I don't like most with this setup is, it depends on the execution
sequence of cron.daily jobs (hence zzz-daily). It is a hack. Should some
demented admin put a script named zzzzzt into cron.daily, the setup gets
whacked :)
If we merge the two scripts, namely "/etc/cron.daily/zz1-weekly" and
"/etc/cron.daily/zz2-monthly" into one "/etc/cron.daily/zzz-daily" then it
should look like:
/etc/cron.daily/zzz-daily ::
#!/bin/sh
#
# Only run on Sundays and on the 1st of the month, respectively.
[ `date +%u` -eq 7 ] && run-parts --report /etc/cron.weekly
[ `date +%d` -eq 01 ] && run-parts --report /etc/cron.monthly
> In your solution, if a script at the daily level hangs, the ones at
> higher levels will never run.
If it wasn't for cron.xxxly, if we were talking about regular cron usage,
I couldn't agree more. But the basic idea with cron.xxxly is that it is a
drop-in place for things to be taken care of, without further strings
attached. Otherwise why should I be using cron.xxxly in the first place?
There's nothing wrong with regular cron, and I could just as well be using
it.
Also, it is paradoxical that each cron.xxxly batch is serial in
themselves, but the batches are not serial. It's true that any script
hanging in the chain, would stall the whole chain. But it is equally true
that the situation is already so within each batch. If cron.daily hangs
halfway, then there is a serious problem needing my attention anyway. My
system would not be ready for the next day, regardless of whether
cron.weekly has been run or not, if cron.daily is stalled.
Leaving the in-house written maintenance scripts aside, it has also a
negative effect on package maintainers, and generally on the robustness of
Debian: Each package maintainer should cross check other packages'
cron.xxxly scripts to make sure that nobody would step on others' toes
inadvertantly. I guess this should make package maintenance a bit harder,
and it is an invitation for an occasional slip off.
Furthermore, I have never had a server with any serious task without a
need for some lengthy EOD/EOW/EOM maintenances. Almost always, they had to
be serialized. If I can't just drop my daily, weekly and monthly jobs into
relevant cron.xxxly and forget about the rest, then what is the point of
having this feature in the first place?
> On a side note, running the jobs under 'nice' has been discussed, and
> determined to be a bad idea for many systems, as it causes jobs that
> scan disks to run a *lot* longer.
It was a slip off from my cut & pasted crontab. I didn't mean it to be
included in the proposal.
==============================================================
Another point:
I have made the error of mixing two separate issues into one thread. There
is a bug, currently, in anacrontab that causes cron.monthly to be executed
twice, once on 31st of the month, and once again on the 1st of the next
month. The period regarding cron.monthly should be increased from 30 to 31
in /etc/anacrontab.
Anybody feels that I should start another thread on this subject? Or is
this bug taken note of?
--
Abdullah | aramazan@ |
Ramazanoglu | myrealbox |
________________| D.0.T cöm |__
Reply to: