Date: Tue, 09 Jan 2001 10:20:06 -0800 From: Doug Barton <DougB@FreeBSD.org> To: Neil Blakey-Milner <nbm@mithrandr.moria.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: <3A5B5656.E2AAF0B5@FreeBSD.org> 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> <20010109124044.A16276@mithrandr.moria.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Neil Blakey-Milner wrote:
>
> On Tue 2001-01-09 (02:14), Doug Barton wrote:
> > Gerhard Sittig wrote:
> > 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
. . .
Yes, I said in my commit that we got, effectively, "the best overall" time
to run the periodic jobs. I have said all along that this part of the
system is not, and cannot be perfect.
> Now, consider NTP calibrations,
. . .
Your example basically says, "Imagine a case where we have an admin with
time-critical jobs who refuses to set up proper time synchronization." I
don't think we should break cron to accomodate cases where admins insist on
loading the gun and pointing it at their foot. I agree that setting up ntp
properly is "one more thing" that you need to be able to do in order to be
a real system admin, but I'm not sure how to lower this bar. Your point
about us not including a sample ntp.conf file is well taken however, I'll
have a go at that as soon as I get my current project off my plate.
> Now, the fix itself is to honour DST changes, and that will work for
> everyone.
The point I'm trying (obviously in vain) to make is having cron do what
amounts to "slewing its internal clock" will not work for everyone, and
violates POLA.
> 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?).
Yes.
> This way, we never repeat jobs, and never lose jobs. Which makes cron
> reliable.
For your definition of "reliable." Personally, I find cron doing exactly
what it's told and not trying to think for itself "reliable."
> "Timing" problems with separate cron jobs will always be a
> hack job, and undoubtably they'll lose or double jobs by mistake anyway.
You (pl.) keep referring to the "We need to hand-hold users who are too
stupid to figure this stuff out for themselves" argument. While there are a
lot of areas of the system that I try to make simpler and easier to
understand, I don't see how we can possibly make this problem foolproof.
The universe keeps producing better fools.
> > > 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,
In fact, I'm quite sure that this is not true. I happen to be the only one
who is currently voicing opposition.
> 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.
At minimum, the proposed change would have to be described in detail in
the man page so that people who expect traditional cron behavior will know
what the heck is going on when cron starts to think for itself. I would
prefer that this new behavior be an option that is off by default, however
there would have to be an option to turn it off if ultimately it ends up
being the default.
> (Attitude almost entirely feigned to match Doug's)
Don't give up your day job. :)
Doug
--
"The most difficult thing in the world is to know how to do a thing and
to watch someone else do it wrong without comment."
-- Theodore H. White
Do YOU Yahoo!?
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?3A5B5656.E2AAF0B5>