Date: Mon, 22 Jan 2001 21:16:43 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Doug Barton <DougB@gorean.org> Cc: cvs-committers@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h Message-ID: <3A6CE98B.4EA9EB9B@bellatlantic.net> References: <Pine.BSF.4.31.0101211916030.66595-100000@dt051n37.san.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
To mention it from the start, I've backed out my changes. (Yes, the pre-backed-out version was the one with the old behavior enabled by default and changed behavior enabled by an option). Doug Barton wrote: > > On Sun, 21 Jan 2001, Sergey Babkin wrote: > > > Doug Barton wrote: > > > > > > This needs to be backed out immediately. This isn't even close to what was > > > discussed in -hackers. After LONG, often pointless discussion, the > > > following points were agreed to there. > > > > Could you please look at the changes first ? The changes I > > committed are _not_ those from NetBSD. > > So instead of following what was agreed to on -hackers you went > off on your own and committed something totally different? This is worse > than I thought. Gerhard Sittig did test the changes from NetBSD and found that they do not quite solve the DST problem. That means that some other way of handling the DST changes should be used. I proposed such a way. > > My changes do not try > > to cover all the cases of skipped minutes but are specifically > > for the change of DST and actually take many precautions to avoid > > messing with the other cases. > > ... which makes the POLA violation worse instead of better. When > we tell people that our cron handles DST changes, the people who live in > areas where the change is not exactly one hour happening at <hour>:00 will > not hear the disclaimer that they are, "out of luck," as you put it. Yes, I agree that this is not good. Though considering that practically all the world except Kirgizia and two smaller islands near Australia falls into the lucky category, this is not that bad. I think I see a reasonably easy way to fix it now. > > On the points: > > > > > Gerhard Sittig wrote: > > > > I take notice of your (and Greg Black's) reservation / being > > > > opposed, respect it and conclude that the change will have to > > > > - default to the current behaviour (something quite usual for > > > > expanding changes) > > > > The behavior is quite close to the current one, differing for > > only the jobs running less frequently than every hour when of course they hit the DST change frame, and different in a rather safe way. > > For a definition of "safe" that is entirely inadequate. In the traditional way strange things happen to the jobs scheduled between 1am and 3am (for Europe/US, time may differ for other time zones) at the DST changes. In the changed way other things happen which are somewhat less strange. That sounds very much like "safe". > > > > - yet be enabled easily for those interested in the change to > > > > work for them and free up some of their resources for more > > > > important tasks > > > > - maybe provide knobs (besides the on-off-switch) to customize > > > > behaviour in a more fine grained way > > > > All the discussion in the thread was about that sysadmins must > > not schedule jobs at 2:00-2:59 AM time (and actually 1:00-1:59 > > as well to avoid duplication though somehow nobody mentioned it). > > If no jobs are scheduled at this interval, then the behavior > > of the cron with my changes is absolutely identical to the > > old one. > > That is certainly NOT the only discussion. I made the point > several times that someone who schedules a time critical job during the > DST change period will have a huge problem if their job is unexpectedly > run without sufficient time to finish, or There are other things which may not allow a job to finish in a predefined time slot. For example, other operations going on and consuming CPU, disk or network bandwidth. So presuming that a job would finish by some time is inherently unsafe. The safe way is to put both jobs sequentially into one script and run this one script from cron. And of course there is a very good chance that the problem would be exactly the same or worse if the job does not run at all, what happens with the traditional implementation. > what is frequently worse their > job is run twice. That's what happens now at switch from 1am DST to 1am ST - all the jobs in the interval 1:00-1:59 run the second time. And that's a part of what my change prevents. > The proponents of the change responded by saying that > you shouldn't schedule time critical jobs during this period, to which I > replied that if you can solve the problem other ways then there is no need > to modify cron. Time critical jobs should be avoided at all, by including all the dependent jobs into one script and running only this script from cron. There is no reason why the DST-dependent period is worse for this purpose than any other one. > What I object to about making this the default is that you are > effectively programming to the lowest common denominator, assuming from > the start that people are too stupid to schedule their jobs properly, > therefore we must fix them in ways that potentially break cron for people > who expect the well established behavior. I'm trying to say that I do not exactly see how changing this denominator would make life worse for "not too stupid people". However I see how it can make life better for the "too stupid people". Also many of the "not too stupid people" just have never met this behavior before because purely by occasion they've never scheduled the jobs at the troubled intervals. So for them the current behavior is not something to cling to and I believe they would prefer to never discover it. I can give you one example from my past experience: a nightly cold backup of a database which takes a long time, must be started after all the day's work would be complete, and finish by 7:30AM the next morning. The time of backup depends on the amount of change logs generated during the day, so to be safe it should be started as early as possible. Well, eventually we got the day's close processing to complete by 12:50 and scheduled the job there. But the fact that two hours of time are unusable for starting any jobs is not a particularly exciting one nor fun to discover. > > > I made the additional point that the options should be command line > > > options, instead of environment variables as someone else suggested. > > > > And I made the additional point that practically all the commercial > > Unixes do support intelligent handling of DST. Being different > > from them makes no good and is a lot of inconvenience. > > If you want to offer the option of making cron think for the user > instead of following traditional behavior then it should be offered as a > command line option, defaulting to off. Period. "We're not like everyone > else" is not a compelling argument here. This sort of arguments is largely responsible for why Unix had branched in so many incompatible ways. The NIH syndrome is not the most productive approach. > > I also have a feeling that these agreed points were agreed only by > > the proponents of keeping the traditional behavior, practically > > ignoring anyone with a different opinion. > > You are in fact 100% wrong. I was careful to quote the summary of > agreed points from Gerhard Sittig's e-mail, who is the original proponent > of the change in the first place. He asked for discussion on the change > and agreed readily after several people spoke up saying that the new > behavior should be an option. It's only partially so. The discussion was rather one-way, with much vocality from the opponents of the change and not much technical arguments. Also the discussion was about different kind of changes, which not only change the behavior of once-a-day jobs in the DST switch timeframe but also affect the jobs running at hourly and sub-hourly intervals enclosing this timeframe and all the jobs get affected by the time changes, and this discussed kind of change is a more dangerous one than I did. I agree that an option is a resonable solution and although I believe that making the changed behavior default is technically better, I do not really mind making the traditional behavior the default. > You need to back out your changes and let the people who are > proposing a more complete solution which has been widely discussed and > agreed to have time to finish their work and send it to -arch for more a) as far as I can see, no more complete solution is proposed b) I don't see any implementations of these proposals either c) the next DST time change would be in about two months from now and it would be really good to do something with this issue before then > discussion. Your drive-by commit out of the blue of something that doesn't Once again, I've described this change in -hackers before implementing it. If you ignored that description, that does not mean that the change comes out of the blue. > come close to what even the people who want the time-skewing behavior are > proposing is wrong on many levels. I agree with the critique of the time zone switch time limitation but on the main meaning of changes you still did not give much technical arguments nor any example showing where the behavior of my changes would be worse than the traditional one. I'd like to see this critique. -SB 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?3A6CE98B.4EA9EB9B>