Date: Sun, 21 Jan 2001 19:46:45 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Matt Dillon <dillon@earth.backplane.com> 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: <3A6B82F5.43CA6A65@bellatlantic.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote:
> The problem here has nothing to do with whether changing the behavior
> is good or bad, and everything to do with the fact that cron is an
> absolutely critical core piece of software that runs on these machines
> and there is no guarentee that you haven't introduced one or many bugs
> 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.
> 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.
> Also, I've already found a problem with the code:
>
> + /* check for the daylight saving time change
> + * we support only change by +-1 hour happening at :00 minutes,
> + * those living in more strange timezones are out of luck
> + */
> + if (last_time != 0 && tm->tm_isdst != lasttm.tm_isdst
> + && TargetTime > last_time /* exclude stepping back */) {
>
> 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.
> restrictions like the change having to occur at the top of the hour
> or be a +-1 hour increment. I would rather see the code ripped completely
> out then to have a semi-broken DLS test.
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?3A6B82F5.43CA6A65>