Hi,
> And, as I said previously, I'd want to know how the new code
> coped with cron being stopped and restarted during one of the
> DST transition times, as well as seeing assurances that the
> legacy version would do the same thing then as it does now.
The legacy version only checks for jobs that fire in the exact current
minute. If it was stopped, it wouldn't run jobs for the missed time.
The new behaviour is to run the fixed-time jobs that are between the
last known time, and the current time, if the stop time is less than 3
hours (if it is more, assume that the change is not a standard DST thing
or normal corrective time change).
If the time change is less than 5 minutes, then cron should try run all
jobs for each minute that passed between the last known time and the
current time. If over 5 minutes, then cron will check for all wildcard
jobs that would have fired, and run it only once, even if it would have
run multiple times).
If time goes backwards, fixed-time jobs are assumed to have already run,
and if we happen to match a wildcard job for the current minute, run it.
If there is a fixed job at 2:40, and we pass 2:40, run the job, and then
at 3, time goes backwards, don't run it. If cron gets killed at 2:50,
and started at 2:55, and time goes backwards to 2:00, the 2:40 job isn't
run either, since the virtual time is still at 3:00. If cron is running
at 2:40, the job is run, cron is killed, and restarted just after the
change back to 2:00, it will run the 2:40 job, as it wasn't around to
experience the DST change. Similarly, if cron isn't around to
experience a forward jump, it won't magically know to run the jobs
missed.
All of which makes me ponder putting cron_tz option in rc.conf and
suggesting people set it to UTC or some other non-DST-afflicted place,
but that isn't the only use of these changes.
However, the new behaviour does do the expected things for common
changes - if it's a relatively small forward jump, run whatever jobs
would have run. If it's a medium-sized jump, run all the fixed-time
jobs, and one of each wildcard job that would have occured. If it's a
massive jump, assume something unusual is up, and don't run any jobs.
If it's a small backwards jump, assume fixed-time jobs shouldn't be run
again until we reach the time we jumped back. And if it's a big
backwards jump, assume something unusual is up, and just start
functioning as if the time hadn't changed.
The previous behaviour says not to care what changes occur in time
whatsoever, and only compare this exact current minute of the waking up
to the crontab list, and run those jobs.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
