Date: Sun, 21 Jan 2001 19:33:43 -0800 (PST) From: Doug Barton <DougB@gorean.org> To: Sergey Babkin <babkin@bellatlantic.net> 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: <Pine.BSF.4.31.0101211916030.66595-100000@dt051n37.san.rr.com> In-Reply-To: <3A6B7148.C5446ECF@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. > 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. > It DOES NOT modify in any way the behavior of cron on an abrupt time > change by date(1) or anything similar. > > > - be well documented (something absolutely clear to all of us, > > > strictly speaking it's way out of imagination for us how > > > somebody could contribute undocumented stuff ... :) > > They are. See cron(8) for description and the PR text for > examples and test cases. I did read cron(8). Your changes are well described, this point is not at issue. > > > - 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 what is frequently worse their job is run twice. 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. 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 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. > 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. 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 discussion. Your drive-by commit out of the blue of something that doesn't come close to what even the people who want the time-skewing behavior are proposing is wrong on many levels. Doug 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?Pine.BSF.4.31.0101211916030.66595-100000>