Date: Sun, 21 Jan 2001 22:35:37 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Sergey Babkin <babkin@bellatlantic.net> Cc: Greg Black <gjb@gbch.net>, Neil Blakey-Milner <nbm@mithrandr.moria.org>, John Gregor <johng@vieo.com>, Gerhard.Sittig@gmx.net, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <200101220635.f0M6ZbJ17648@earth.backplane.com> References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> <3A6B3D85.9773C9ED@bellatlantic.net> <nospam-3a6b44dfe00a3f3@maxim.gbch.net> <3A6B68E9.278A6BBB@bellatlantic.net> <200101212332.f0LNWun16287@earth.backplane.com> <3A6B82F5.43CA6A65@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:> with your rather large diff set. For better or for worse, people
:> already know about the daylight savings shift problem. Thousands
:> of people depend on cron to work, which means that when you
:> make a major change like this it must be tested by a wider audience
:> for a longer time before becoming the default. It needs to have some
:> real-life operational experience behind it.
:
:This can be applied to whole FreeBSD just as well. And IMHO
:cron is less critical than any part of the kernel, yet changes
:to the kernel don't usually bring such a strong reaction.
I think you have a valid argument in regards to cron vs the kernel.
But keep in mind that even though you are fixing a 'bug', it's a well
known 'bug' so you are in fact creating an operational change to the
code rather then just a bug fix or minor performance enhancement, etc...
When I do major kernel work, it's usually tested by third parties for
a week or two. The last three major commits I've done had been under
test for three weeks (don't let the 2-5 day MFC fool you, I have to
do all my work on -stable first, then forward port to -current, then
MFC back to -stable).
:> So I have to say here that I agree with the calls to back it out...
:> it needs to backed out, and then put back in as a command line option.
:> Or you need to commit the command line option code ASAP and make the
:> old behavior the default. Judging by the diffs, it should not be
:> difficult for you to do this.
:
:OK, I'll change it to a command line option.
I sure would appreciate it. Thanks!
:> This is broken. If you want to check for a DLS change there is only
:> one right way to do it, and that is to compare the wall clock
:> differential verses the GMT differential, and to not put in any silly
:
:I disagree. Checking the difference from GMT creates a danger
:of misrecognition of a time zone change (for example, when
:a machine was physically moved) for a DST switch. So comparing
:is_dst is the only reliable way to tell if there actually was
:such a switch.
I don't consider someone changing the machine's /etc/localtime zone
to be an issue, since it rarely if ever happens. And if a machine is
moved, it's likely to be powered down anyway.... cron is not going to
nor is it supposed to 'catch up' after downtime. Additionally, cron
cannot detect a timezone change without being restarted, so the point
is moot anyhow.
-Matt
:This limitation stems from the way the Vixie cron works. Supporting
:other sorts of DST timing is either non-obvious or would require
:a complete rewrite of cron to make it work like in SVR4, by
:precalculating the time_t time of next run for each job in advance.
:Such a rewrite would nicely fix the problem of missed minutes under
:high load as well but will require significant effort to do
:and lots of testing.
:
:Anyway, the present limitation covers most of the globe nowadays except
:for Kirgizia and a few islands in Australasia (judging from the
:zoneinfo files). If the fix in its present form would be accepted
:then I guess adding more code around it for half-an-hour and arbitrary
:DST timing would be the next step.
:
:-SB
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?200101220635.f0M6ZbJ17648>