Date: Tue, 9 Jan 2001 12:40:44 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Doug Barton <DougB@gorean.org> Cc: Gerhard Sittig <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: <20010109124044.A16276@mithrandr.moria.org> In-Reply-To: <3A5AE490.D251F590@gorean.org>; from DougB@gorean.org on Tue, Jan 09, 2001 at 02:14:40AM -0800 References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue 2001-01-09 (02:14), Doug Barton wrote:
> Gerhard Sittig wrote:
> >
> > [ citing from Doug's message in the "OT: silence ..." subthread
> > to keep the technical discussion in the "how to test" subthread ]
> >
> > On Tue, Jan 05, 2001 at 14:45 -0800, Doug Barton wrote:
> > >
> > > You stated in another post that you wished I had elaborated
> > > more. I was in a hurry when I wrote that post, so here are more
> > > details. While this is, as you say, "an eternal problem," it is
> > > not a problem entirely without remedy. The proper solution is
> > > simply to avoid scheduling mission/time critical events during
> > > the DST change period for your time zone. Without improperly
> > > revealing sources, I can say that I did a lot of research on
> > > this topic in a past life, and it is by no means clear that
> > > your proposed solution is the best one.
> >
> > Well, the "don't schedule jobs for these times" is the problem
> > here: The fact that all FreeBSD users are potentially struck is
> > caused by the jobs execution time to be delivered with the
> > distribution. It's not a wanton act of some administrators to
> > schedule their jobs this way, but it's the status after
> > installing FreeBSD on a machine. Plus the fact that this machine
> > (by chance? but it's an increasing chance as has been stated in
> > an other message) is located in a region with DST changes.
>
> You're blowing the significance of this part of your argument WAY out
> of proportion. After long discussion we've picked times for the periodic
> jobs that are the best overall choices, and you make my followup point
> for me below.
You yourself, in your commit, say that "Please note that this time was
chosen with input from people in various countries with various methods
and schedules for switching to and from DST. There is no perfect time
to schedule this job that works for everyone, but this time both A)
Works for more people, and B) Causes problems for fewer people. And,
ultimately, you can always change it if you need to."
Now, consider NTP calibrations, possibly automated every few hours (one
suggested way of doing so, and much easier than setting up ntpd from
scratch, since we don't come with a default or example ntp.conf, but
that's another story). Now, say that adjusts the clock back 5 minutes.
Any hourly run (which may specifically need to be run only every hour,
on the hour, say for generating statistics, log rotation, or whatever,
would then be run twice in quick succession. Knock it forward enough,
and you'll skip jobs (note, I'm talking stepping, not slew). That isn't
expected behaviour to the vast majority of people, since I've only ever
heard complaints about the DST handling, and never has anyone suggested
before you that we should just ignore it, and that in fact, people are
ignorant if they expect cron to do this work for them.
Now, the fix itself is to honour DST changes, and that will work for
everyone. An alternative is to add better heuristics to see if the
change in time is "almost exactly" a factor of 30 minutes (do any
countries do anything but exactly 1 hour changes?).
This way, we never repeat jobs, and never lose jobs. Which makes cron
reliable. "Timing" problems with separate cron jobs will always be a
hack job, and undoubtably they'll lose or double jobs by mistake anyway.
> > Of course everybody knows there's a need to check, correct and
> > add quite a few things an installer is not capable to handle in
> > all the variety of arrangements humans come up with. And some
> > things aren't just the job of an installer. But how many of us
> > are aware of checking scheduled jobs' timings and how they could
> > collide in the near future (in the next year after setting up the
> > machine) or in the general future (when you somehow "forgot" the
> > machine because it just works flawlessly)?
>
> The people to whom this is important already know how to check it, and
> set it accordingly. This is the last thing a novice admin needs to worry
> about.
The novice expects that if you set up a job to run once a day, by
telling it to run at 2am, it will be run at 2am, exactly once. In fact,
that's the behaviour I expect. Without this code, cron is doing
something stupid - running a daily thing more than once a day, or maybe
even not at all.
> > It's not that I want to talk you into something you don't want.
>
> But that's exactly what you're trying to do. I will not bother to
> re-re-restate my points as to why what you're proposing is a bad idea.
> Do all the testing you want, but make sure you understand that there
> will be vigorous resistance to incorporating your proposed changes.
And when you finally realize that everyone else thinks this is a great
idea, you'll stop your sole campaign to vigourously resist the
incorporation of this code? If it helps, we can have an option ('-i')
to ignore DST changes, for "advanced administrators who know what
they're doing and expect jobs to be lost or run multiple times depending
on exactly when they schedule their jobs", and the "clueless newbies who
ignorantly expect a job scheduled at 2am to not only run, but run only
once" can be served too, by default.
(Attitude almost entirely feigned to match Doug's)
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?20010109124044.A16276>