From owner-freebsd-hackers Tue Jan 9 10:20:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 803AE37B6A5 for ; Tue, 9 Jan 2001 10:20:23 -0800 (PST) Received: from FreeBSD.org (Studded@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id KAA79516; Tue, 9 Jan 2001 10:20:07 -0800 (PST) (envelope-from DougB@FreeBSD.org) Message-ID: <3A5B5656.E2AAF0B5@FreeBSD.org> Date: Tue, 09 Jan 2001 10:20:06 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Neil Blakey-Milner Cc: Gerhard Sittig , freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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