From owner-freebsd-hackers Mon Jan 8 23:33:49 2001 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 70FB337B404 for ; Mon, 8 Jan 2001 23:33:24 -0800 (PST) Received: (qmail 9448 invoked by uid 0); 8 Jan 2001 17:31:21 -0000 Received: from pd9508811.dip.t-dialin.net (HELO speedy.gsinet) (217.80.136.17) by mail.gmx.net (mail06) with SMTP; 8 Jan 2001 17:31:21 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id RAA23882; Sun, 7 Jan 2001 17:08:41 +0100 Date: Sun, 7 Jan 2001 17:08:40 +0100 From: Gerhard Sittig To: freebsd-hackers@FreeBSD.org Cc: Doug Barton Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010107170840.G253@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> <20010102133239.V253@speedy.gsinet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010102133239.V253@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Tue, Jan 02, 2001 at 01:32:39PM +0100 Organization: System Defenestrators Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ 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. 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)? What if some government later decides to introduce DST, too? What if these jumps are shifted to a different week? It may be rare, but it definitely would be tedious to keep up with these details for machines you don't need to spend too much attention for or regions you don't live in or care too much about. Even if the user gets it right after the installation, there's a chance that a commit to the timezone database will cause new trouble. Strictly speaking you wouldn't even have to check crontab(5) against the Real World (TM), but against the zdump(8) output. Since the /etc/localtime description is what makes the clock jump on the computer. It boils down to: Do we want to keep putting tedious (and mostly nonintuitive) work on FreeBSD users? Or do we want to free some of their resources for more important tasks (maybe even the actual tasks they install FreeBSD as a tool / vehicle for:)? Imagine you would be yourself in the situation to handle a few wide spread machines in different regions of the earth. Add your experience with the nontrivial nature of DST handling and job scheduling. Actually I would expect you to welcome when cron(8) would be intelligent enough to save you from thinking about these low level details. :) There already are much more (and more important) things to care about when setting up a server ... It's not that I want to talk you into something you don't want. Currently I'm about to setup a spare machine for the tests (the one I had last year is not available for toying any longer). Since this machine lacks any kind of connectivity, I have to fallback to 4.1-R from the Lehmann's CD set. With the CVS repo from CD#2 I checked there's no diff between the -STABLE and -CURRENT usr.sbin/cron tree. And I would expect mdocification to be the only change made to cron since then. While I write this "make world" is running and will take some seven hours. I scheduled DST changes for Jan 8th, 9th, 10th, and 11th (to, from, to, and from DST, respectively). If things go well, I can send-pr the code and the testing environment next weekend (Sergey Babkin was so kind to help me with setting it up). > Consider the following. We are in the spring and DST is > "springing forward" at 2am. We have a job scheduled at 2:15 > that takes one hour to run. There is another job scheduled at > 3:20 that ABSOLUTELY POSITIVELY cannot run unless the first job > finishes. Aside from the fact that this is bad design, how > should cron handle this situation? You can (and probably > should) respond that this is not cron's responsibility, and > come up with all kinds of ways to ameliorate this situation. My > response will then be that if you can "fix" this situation > without "fixing" cron, then cron doesn't really need to be > "fixed." Well, the only valid "fix" for this situation would be to fix the jobs' arrangement / interaction / synchronisation. This can be done with coordinating interdependent jobs by means of locks or making them one job with several stages or something". Do you agree that the proposed cron extension merely reveals the brokenness of the above asumption that a job has a given length and unforced synchronisation always will work? Talking about a UNIX environment there's no way of reliably operating based on computation time, anyway. You may have an expectation, you may even have an estimate, but you never have determined execution lengths. But all of this is basically what you state yourself. In the current situation (and in future, too, of course) cron wouldn't even force these jobs to really start at the given time. They're just dispatched, queued, or whatever term is the best. Availability of resources is what influences scheduling more than users' wishes. :) This means the above example is defective without touching cron, already. But without the proposed fix to cron the 2:15 job wouldn't even get run and and thus possibly damage(?) the prerequisites the 3:20 job wants to run under. No matter how defective the above example may be, it's hard to decide which "brokenness" is worse in the above scenario: not to run needed jobs or to have them run interleaved while they should be sequenced. But in any normal scenario it surely is a bug when scheduled jobs aren't run at all or multiple times. Out of curiousity: can cron(8) already handle situations where it is woken up after some minutes have passed since the last "tick"? Or is this absolutely out of imagination that a machine's workload is this bad? > With very little imagination you could easily come up with > other situations where your proposed changes will cause more > harm than good. You might be shocked, but sorry I *cannot* come up with _any_ situation that's to get broken by a cron which keeps up with its job list. :) Isn't it exactly the user's expectation that cronjobs are run (for nitpicking: queued immediately and waited for resources to become available for running them) as soon as the scheduled time is reached _or_ _passed_? And making sure that cron "gets bored" about "hey, I know this job. I just ran it. Just because somebody turned back the clock doesn't mean I *want* to do it all again" would IMO better match users' expectations, too. To make things clear: This doesn't touch the "every five minutes" and "hourly" jobs, only those scheduled for one given daytime and at least daily. Anyway. The reminder I sent seems to prove there *is* interest among FreeBSD users. And not everyone is keen on having the discussion in late March once more, and in October again. :) So I will do my part and contribute what I can. :> May others with more knowledge jump in and join or prove me wrong ... For the record I will cite the manpage again, which is meant to clarify the motivation for the change. It seems my presentation of what I try to achieve was wrong. And I expect the PR with code to change this. ----------------------------------------------------------------- --- /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 ----------------------------------------------------------------- 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