Date: Thu, 11 Jan 2001 13:43:06 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Greg Black <gjb@gbch.net> Cc: dan@langille.org, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010111134306.A78413@mithrandr.moria.org> In-Reply-To: <nospam-3a5d5b66040447e@maxim.gbch.net>; from gjb@gbch.net on Thu, Jan 11, 2001 at 05:06:14PM %2B1000 References: <20010110233907.L253@speedy.gsinet> <200101110647.TAA32661@ducky.nz.freebsd.org> <nospam-3a5d5b66040447e@maxim.gbch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010111134306.A78413>