Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)

[Leif Neland]

> > One of the things that would need to be documented is what will
> > happen to the new algorithm in the situation where cron is
> > stopped and re-started during one of the time periods that gets
> > repeated.
> 
> Oh, you bring up an absolutely new datapoint it seems!  Since all
> the information vixie cron (in its original form as well as the
> OpenBSD variant) keeps its state in is held in memory (the time
> it went to sleep, the time it expects to wake up again, the time
> it is collecting jobs for -- usually somewhere between the time
> it went to sleep and the time it woke up at, catching up towards
> the current time) it wouldn't know that it does repeat an hour it
> just has passed few minutes ago in case there's been a restart in
> between.
> 
Oh no. If this "clock-slewing" was implemented, I'd expect killing and
restarting cron be a way to forget everything which had happened.

I.e. if I wanted to test a schedule, I might want to stop cron, reset time
and start cron again.

Cron usually doesn't die by itself. If it gets killed, it is usually for a
reason. Don't complicate this proposed change with also having to add
persistance over a kill and restart.

Does anacron handle this DST issue better? 

Could it be added to ports if so, and a knob NO_CRON in make.conf?

Leif




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message