[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



begin  "Artur R. Czechowski" <arturcz@hell.pl> dedi ki:
> On Wed, Sep 08, 2004 at 01:33:55AM +0300, Abdullah Ramazanoglu wrote:
>
>> 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.
>
> Right. It is critical to you to run cron.weekly on Sunday and
> cron.monthly at 1st day of month?
> I can imagine a situation when it is important, but it is rather rare
> case. It requires that unix box is under heavy load 24h during working
> days and lower load during Sat/Sun. In any other case I see no reasons
> to run weekly/monthy jobs on Sunday/at 1st.
> 
> Well, if it is your case it really requires a special configuration. But
> for most people default settings in Debian should work.

Yes, it's my case. But I thought it's also needed by other admins as well.
BTW this NG might be populated by people way more sophisticated than an
average sysadmin. So I would like to point out that there may be some gap
between what an average person here sees as a "need" and what an average
Debian user would actually need. I guess this point should also be taken
into consideration while designing certain features of Debian.

There are other considerations regarding your comments, which I already
expressed in my reply to Steve.
 
>> 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.
>
> I would like to propose another solution. Let's left jobs' definition as
> they are, giving to administrator an option to choose (anacron or
> crontab). Let crontab do nothing about serialisation. Instead run-parts
> could respect additional, optional parameter: --lock <lockname>. Some
> run-parts calls could use the same <lockname> - in this case only one
> run-parts could run. Another one could proceed only after the running
> one finishes.

It would also work, AFAICS.

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



Reply to: