Date: Sat, 20 Jan 2001 19:43:25 +0100 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010120194325.N253@speedy.gsinet> In-Reply-To: <20010117184854.G253@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Wed, Jan 17, 2001 at 06:48:54PM %2B0100 References: <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010109124044.A16276@mithrandr.moria.org> <3A5B5656.E2AAF0B5@FreeBSD.org> <nospam-3a5b95e412011c9@maxim.gbch.net> <20010116192601.B253@speedy.gsinet> <nospam-3a64b2731814449@maxim.gbch.net> <20010117184854.G253@speedy.gsinet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 17, 2001 at 18:48 +0100, Gerhard Sittig wrote: > > I'm just editing the PR with the cron patches [ ... ] So it finally happened. It's filed as "bin/24485: [PATCH] to make cron(8) handle clock jumps" and got archived at http://www.freebsd.org/cgi/query-pr.cgi?pr=24485 I don't see it as a ready solution but more as a basis for further discussion if needed or considered useful. Up to now there was only the reference to "cvs diff -r1.3 -r1.4 $OPENBSDTREE/cron.c". Now there's an isolated DST part of what's different between OpenBSD and FreeBSD. And the code turned out to not handle DST, but time(3) differences. In the course of this thread I got uncertain if this is the way to follow when talking about the DST issue. The PR's subject tries to demonstrate that I see the patch to serve a different purpose from what its manpage diff promises. As a consequence I try to discuss in the PR the enhancements the diff could be in need of as well as what other mechanisms could solve (or lower) the DST "problem". There's nothing new for those who followed the thread. But it might be pleasant to have them bundled and archived. (Sorry if I forgot something or didn't read it. It's no bad intent, I'm just not subscribed to -hackers and the web frontend has some four days of delay. And I don't browse from where I do the mail, so something could get dropped "in transit". Feel free to followup to the PR in case there's something missing or wrong. But you surely do without me inviting you:) Combine this one with the "conf/24358: [PATCH] etc/rc variables for cron(8)" PR and everybody has the choice to - do nothing and live unaffected - create / get a port and switch over to it ('cd /usr/ports; make search key=cron' is empty at the moment) - repo copy cron and fiddle in any way with the new instance - locally patch the cron tree and leave others unaffected - revive private implementations (? I heard mention of these) There should be no suspicion any longer of getting harmed for no other reason than lazy / unexperienced / misguided admins' wanting their computer to do things the way humans expect. :) I wouldn't think about make.conf switches, but rather handle it the rc.conf way. Have the one "stable" cron that's been there for good, leave it untouched and experiment in one of the above sketched ways. This should give the maximum in deterministic and expected behaviour for those wanting consistency with the current implementation as well as maximum flexibility for those who feel a change to be necessary for their own environments. The lesson I have learnt from the discussion is that there is no single cron that would be able to satisfy everyone. And since cron is an essential component of a UNIX machine concerns cannot be taken easily. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. 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?20010120194325.N253>