From owner-freebsd-hackers Tue Jan 2 6:17:38 2001 From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 06:17:33 2001 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 7AF8337B404 for ; Tue, 2 Jan 2001 06:17:27 -0800 (PST) Received: (qmail 25140 invoked by uid 0); 2 Jan 2001 14:17:21 -0000 Received: from p3ee2162b.dip.t-dialin.net (HELO speedy.gsinet) (62.226.22.43) by mail.gmx.net (mail08) with SMTP; 2 Jan 2001 14:17:21 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id NAA12722 for freebsd-hackers@FreeBSD.org; Tue, 2 Jan 2001 13:32:39 +0100 Date: Tue, 2 Jan 2001 13:32:39 +0100 From: Gerhard Sittig To: freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010102133239.V253@speedy.gsinet> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A513799.75EAB470@FreeBSD.org>; from DougB@FreeBSD.org on Mon, Jan 01, 2001 at 06:06:17PM -0800 Organization: System Defenestrators Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 01, 2001 at 18:06 -0800, Doug Barton wrote: > > Speaking only for myself, I don't think your proposed changes > are a good idea, which is why I refrained from offering any > suggestions on how you can test them. Your refusal(id?) has been the only response so far and it didn't sound very clear / determined / explained (sorry, I lack better words) to me. :) So I guess the wording I used "DST handling in cron" was not done luckily. Let me cite from the doc diff: ----------------------------------------------------------------- --- /usr/src/usr.sbin/cron/cron/cron.8 1999/08/28 01:15:49 1.7 +++ /usr/src/usr.sbin/cron/cron/cron.8 2000/12/03 12:44:53 @@ -68,6 +68,25 @@ .Xr crontab 1 command updates the modtime of the spool directory whenever it changes a crontab. +.Pp +Special considerations exist when the clock is changed by less than 3 +hours; for example, at the beginning and end of Daylight Saving +Time. +If the time has moved forward, those jobs which would have +run in the time that was skipped will be run soon after the change. +Conversely, if the time has moved backward by less than 3 hours, +those jobs that fall into the repeated time will not be run. +.Pp +Only jobs that run at a particular time (not specified as @hourly, nor with +.Ql * +in the hour or minute specifier) +are +affected. +Jobs which are specified with wildcards are run based on the +new time immediately. +.Pp +Clock changes of more than 3 hours are considered to be corrections to +the clock, and the new time is used immediately. .Sh SEE ALSO .Xr crontab 1 , .Xr crontab 5 ----------------------------------------------------------------- This modification (obtained from OpenBSD) handles any situation where system time will jump just a little (assuming you're willing to refer to three hours as "just a little" while talking about computers:). Think of administrators' intervention by means of date(8) or netdate(1) for manual correction. Or maybe DST changes, which are just a special case thereof. And yes, it sounds a little like the anacron method of keeping up with scheduled jobs while the machine hasn't been available continuously. But admittedly DST changes are the cause of permanently upcoming discussions twice a year that cron(8) is broken or crontab(5) needs correction -- with (always the same) result that touching the crontab database cannot solve the problem. And the latest commits to crontab that still didn't satisfy every region FreeBSD users live in were what triggered my wish to stuff the "intelligence" into cron(8) and live in peace for good (at least in this respect). Of course we could wait another few months to have the discussion come up once more (and to know for sure it will again and again). But I'd rather have some feedback whether the problem could be solved before the effect strikes again and whether it's worth to spend any more time on providing fixes people actually don't want to get in the end. Is there anyone out there who feels like rejecting the proposal for a *reason*? Or to accept the idea, but to redirect the effort to a "real solution"? I somehow doubt you'd rather explain again and again that cron(8) isn't broken but that users should shuffle around the daily job's execution time ... 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