Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
[ I'm not subscribed to -hackers, please keep CC'ing me; thanks! ]
On Mon, Nov 20, 2000 at 19:33 +0100, Gerhard Sittig wrote:
>
> [ ... cron and DST ... ]
>
> But I thought modifying cron(8) itself would be the best way.
> Is someone already working on this or should I try to do it
> myself (within the next few weeks)?
Since I dared to offer my working on cron.c in the above cited
cvs-all message <[EMAIL PROTECTED]> and nobody
stopped me :) I did as sketched here:
$ diff -r -u \
fbsd/src/usr.sbin/cron/cron \
obsd/src/usr.sbin/cron \
> $PATCHFILE
$ $EDITOR $PATCHFILE
$ cd fbsd/src/usr.sbin/cron/cron
$ patch -p4 < $PATCHFILE
$ make all
This took the DST handling code of OpenBSD's cron, leaving the
other diffs / details (capabilities, logging, errno handling, gcc
work arounds, formatting, pipe/env etc stuff) aside.
But what keeps me from feeding the changes back into the FreeBSD
project by means of send-pr(1) is that I don't want to do so
before testing that everything works as it should. That's where
I fail miserably:
# script
# kill `cat /var/run/cron.pid`
# ./cron -x sch &
... watch it for a while ...
# date -v+1H
... further watch it ...
# echo 'date 0300' | at 0200
... further watch it ...
Normal run is not broken. :) Small jumps (the first date
command) work as expected. But the DST emulation (the second
date command, delayed) fails since "something" turns back the
clock some two minutes after the scheduled jump. And I feel it's
adjkerntz(8) run by cron doing so (scheduled for 03:01:00 by
default).
Remembering the fortune "Don't force it. Get a larger hammer!"
and after reading "man 5 tzfile; man 8 zic zdump" I applied the
following patch to simulate another DST change:
Index: /usr/src/share/zoneinfo/europe
===
RCS file: /usr/fcvs/src/share/zoneinfo/europe,v
retrieving revision 1.18.2.2
diff -u -r1.18.2.2 europe
--- /usr/src/share/zoneinfo/europe 2000/10/25 19:44:08 1.18.2.2
+++ /usr/src/share/zoneinfo/europe 2000/12/03 12:36:54
@@ -406,6 +406,10 @@
Rule EU 1981max - Mar lastSun 1:00u 1:00S
Rule EU 1996max - Oct lastSun 1:00u 0 -
+# this is my private modification to test out DST handling code in cron(8).
+Rule EU 2000only- Dec 4 1:00u 1:00S
+Rule EU 2000only- Dec 5 1:00u 0 -
+
# W-Eur differs from EU only in that W-Eur uses standard time.
Rule W-Eur 19771980- Apr Sun>=1 1:00s 1:00S
Rule W-Eur 1977only- Sep lastSun 1:00s 0 -
After "make buildworld; make installworld; mergemaster; cp
/usr/share/zoneinfo/Europe/Berlin /etc/localtime" (you know,
grabbing the _big_ stick ...) I tried to double check:
$ zdump -v /etc/localtime | grep 2000
/etc/localtime Sun Mar 26 00:59:59 2000 UTC = Sun Mar 26 01:59:59 2000 CET isdst=0
gmtoff=3600
/etc/localtime Sun Mar 26 01:00:00 2000 UTC = Sun Mar 26 03:00:00 2000 CEST isdst=1
gmtoff=7200
/etc/localtime Sun Oct 29 00:59:59 2000 UTC = Sun Oct 29 02:59:59 2000 CEST isdst=1
gmtoff=7200
/etc/localtime Sun Oct 29 01:00:00 2000 UTC = Sun Oct 29 02:00:00 2000 CET isdst=0
gmtoff=3600
/etc/localtime Mon Dec 4 00:59:59 2000 UTC = Mon Dec 4 01:59:59 2000 CET isdst=0
gmtoff=3600
/etc/localtime Mon Dec 4 01:00:00 2000 UTC = Mon Dec 4 03:00:00 2000 CEST isdst=1
gmtoff=7200
/etc/localtime Tue Dec 5 00:59:59 2000 UTC = Tue Dec 5 02:59:59 2000 CEST isdst=1
gmtoff=7200
/etc/localtime Tue Dec 5 01:00:00 2000 UTC = Tue Dec 5 02:00:00 2000 CET isdst=0
gmtoff=3600
(Actually this was done in two steps: First I copied the "EU"
and "Germany" sections from the europe file, inserted the
additional DST switch between 01:00 and 04:00 UTC on an earlier
date, compiled and installed with "zic -d . tzfile; cp CronDST
/etc/localtime", tested with the above zdump command and failed
to get the expected DST messages when running cron, too. :< )
Afterwards I started the test again ("script; kill `cat
/var/run/cron.pid`; ./cron -x sch") and failed to see _any_ "DST"
log messages I've seen before. Although local time did change
(jump forward for an hour) for this one day. Hmmm ...
I'm lost. Please advise on how to best test this scenario.
Without local tests I definitely won't publish the patch (don't
feel at all like bothering others with code which doesn't work in
its basic functionality).
Having the logic in cron itself would eliminate the never ending
discussion bubbling up twice a year on why cronjobs didn't run /
ran multiple times and where to move daily cronjobs to (ending up
every time with the result that _no_ time suits _all_ the FreeBSD
users -- there simply are way too many of them ... :).
Thank you for your attention (and patience to read this lengthy
message)!
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true |
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
[ ... reminder after two weeks of silence ... ] On Tue, Dec 05, 2000 at 22:56 +0100, Gerhard Sittig wrote: > > [ I'm not subscribed to -hackers, please keep CC'ing me; thanks! ] > > [ ... ] > > This took the DST handling code of OpenBSD's cron, leaving the > other diffs / details (capabilities, logging, errno handling, gcc > work arounds, formatting, pipe/env etc stuff) aside. > > But what keeps me from feeding the changes back into the FreeBSD > project by means of send-pr(1) is that I don't want to do so > before testing that everything works as it should. That's where > I fail miserably: > > [ ... ] > > I'm lost. Please advise on how to best test this scenario. > Without local tests I definitely won't publish the patch (don't > feel at all like bothering others with code which doesn't work in > its basic functionality). > > Having the logic in cron itself would eliminate the never ending > discussion bubbling up twice a year on why cronjobs didn't run / > ran multiple times and where to move daily cronjobs to (ending up > every time with the result that _no_ time suits _all_ the FreeBSD > users -- there simply are way too many of them ... :). The full story can be found at http://www.freebsd.org/cgi/getmsg.cgi?fetch=211030+217815+/usr/local/www/db/text/2000/freebsd-hackers/20001210.freebsd-hackers virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: > > [ ... reminder after two weeks of silence ... ] Two weeks of silence is generally enough to let you know that no one is interested in this modification. If someone was, they'd generally have said something by now. 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. Just so you wouldn't think you were being ignored, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
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" [EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: > 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 ... I'm opposed to the changes. Those people who live in places that use daylight savings time should be aware of its effect on their lives and should understand that scheduling events to fall during the missed or repeated time at the changeover (whether by cron or by any other mechanism) is going to produce anomalous results. Therefore, the /right/ thing to do is to avoid the times where this problem can occur. IMO, the solution is to put a note at the top of the distributed /etc/crontab file suggesting that people who have DST not put jobs in the transition times, together with similar notes in the relevant man pages and in comments at the top of the files that are generated by crontab. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed, Jan 03, 2001 at 02:38:30PM +1000, Greg Black scribbled: | Gerhard Sittig wrote: | > 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 ... | | I'm opposed to the changes. Those people who live in places | that use daylight savings time should be aware of its effect on You see, "those people" equates to sysadmins living in North/South America, Europe, Australia, and some other places. | their lives and should understand that scheduling events to fall | during the missed or repeated time at the changeover (whether by | cron or by any other mechanism) is going to produce anomalous | results. Therefore, the /right/ thing to do is to avoid the | times where this problem can occur. | | IMO, the solution is to put a note at the top of the distributed | /etc/crontab file suggesting that people who have DST not put | jobs in the transition times, together with similar notes in the | relevant man pages and in comments at the top of the files that | are generated by crontab. Daylight savings time is here to stay. Nobody is going to change this for bunch of unix servers. I do not understand why people resist change in FreeBSD so much. This does not hurt anybody. Mr.Blacks' /etc/crontab comment idea is quite the thing that we try to avoid in the tree. -- Sigh, yet another bikeshed. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
I like these changes. I'm definitely in favor of code that corrects for the DST handling oddities that sysadmins have to deal with. This would be especially valuable for companies which might have deployments in 25 different time zones globally, which for reasons that are out of scope can't be converted to UTC. The argument that the sysadmin should know the results of putting a cronjob at a certain time become much weaker in that scenario. Additionally, the fact of the matter is that most DST crossovers occur during low-usage periods for typical servers. Given a choice of performing resource-intensive daily chores at a time of low usage, or wasting three hours each night, because twice a year there's a clock jump, I'll take the fully utilized server please. The one thing that has me giving some amount of hesitation, though it's trivial, is the fact that this patch is based solely on clock skew. My initial reaction is that I'd like the patch to check if the skew has been caused by a time zone shift, though honestly, I can't think of another scenario where a properly running server's clock would jump. I'll gladly retract my endorsement of this type of change if somebody can note scenarios where this could have negative effects equal to or greater than the negative effects of the current system. -- kevin way <[EMAIL PROTECTED]> worldgate communications software engineer +1 215 354 5287 PGP signature
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
[ 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
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: > > [ 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. You're blowing the significance of this part of your argument WAY out of proportion. After long discussion we've picked times for the periodic jobs that are the best overall choices, and you make my followup point for me below. > 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)? The people to whom this is important already know how to check it, and set it accordingly. This is the last thing a novice admin needs to worry about. > It's not that I want to talk you into something you don't want. But that's exactly what you're trying to do. I will not bother to re-re-restate my points as to why what you're proposing is a bad idea. Do all the testing you want, but make sure you understand that there will be vigorous resistance to incorporating your proposed changes. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Tue, 9 Jan 2001, Doug Barton wrote: > But that's exactly what you're trying to do. I will not bother to > re-re-restate my points as to why what you're proposing is a bad idea. > Do all the testing you want, but make sure you understand that there > will be vigorous resistance to incorporating your proposed changes. Not if there's a cron_dtrt="NO" # Get cron to do the right thing in /etc/defaults/rc.conf -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED] If it's broken really badly - don't fix it either. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Tue 2001-01-09 (02:14), Doug Barton wrote:
> Gerhard Sittig wrote:
> >
> > [ 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.
>
> You're blowing the significance of this part of your argument WAY out
> of proportion. After long discussion we've picked times for the periodic
> jobs that are the best overall choices, and you make my followup point
> for me below.
You yourself, in your commit, say that "Please note that this time was
chosen with input from people in various countries with various methods
and schedules for switching to and from DST. There is no perfect time
to schedule this job that works for everyone, but this time both A)
Works for more people, and B) Causes problems for fewer people. And,
ultimately, you can always change it if you need to."
Now, consider NTP calibrations, possibly automated every few hours (one
suggested way of doing so, and much easier than setting up ntpd from
scratch, since we don't come with a default or example ntp.conf, but
that's another story). Now, say that adjusts the clock back 5 minutes.
Any hourly run (which may specifically need to be run only every hour,
on the hour, say for generating statistics, log rotation, or whatever,
would then be run twice in quick succession. Knock it forward enough,
and you'll skip jobs (note, I'm talking stepping, not slew). That isn't
expected behaviour to the vast majority of people, since I've only ever
heard complaints about the DST handling, and never has anyone suggested
before you that we should just ignore it, and that in fact, people are
ignorant if they expect cron to do this work for them.
Now, the fix itself is to honour DST changes, and that will work for
everyone. An alternative is to add better heuristics to see if the
change in time is "almost exactly" a factor of 30 minutes (do any
countries do anything but exactly 1 hour changes?).
This way, we never repeat jobs, and never lose jobs. Which makes cron
reliable. "Timing" problems with separate cron jobs will always be a
hack job, and undoubtably they'll lose or double jobs by mistake anyway.
> > 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)?
>
> The people to whom this is important already know how to check it, and
> set it accordingly. This is the last thing a novice admin needs to worry
> about.
The novice expects that if you set up a job to run once a day, by
telling it to run at 2am, it will be run at 2am, exactly once. In fact,
that's the behaviour I expect. Without this code, cron is doing
something stupid - running a daily thing more than once a day, or maybe
even not at all.
> > It's not that I want to talk you into something you don't want.
>
> But that's exactly what you're trying to do. I will not bother to
> re-re-restate my points as to why what you're proposing is a bad idea.
> Do all the testing you want, but make sure you understand that there
> will be vigorous resistance to incorporating your proposed changes.
And when you finally realize that everyone else thinks this is a great
idea, you'll stop your sole campaign to vigourously resist the
incorporation of this code? If it helps, we can have an option ('-i')
to ignore DST changes, for "advanced administrators who know what
they're d
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Neil Blakey-Milner wrote:
>
> On Tue 2001-01-09 (02:14), Doug Barton wrote:
> > Gerhard Sittig wrote:
> > You're blowing the significance of this part of your argument WAY out
> > of proportion. After long discussion we've picked times for the periodic
> > jobs that are the best overall choices, and you make my followup point
> > for me below.
>
> You yourself, in your commit, say that
. . .
Yes, I said in my commit that we got, effectively, "the best overall" time
to run the periodic jobs. I have said all along that this part of the
system is not, and cannot be perfect.
> Now, consider NTP calibrations,
. . .
Your example basically says, "Imagine a case where we have an admin with
time-critical jobs who refuses to set up proper time synchronization." I
don't think we should break cron to accomodate cases where admins insist on
loading the gun and pointing it at their foot. I agree that setting up ntp
properly is "one more thing" that you need to be able to do in order to be
a real system admin, but I'm not sure how to lower this bar. Your point
about us not including a sample ntp.conf file is well taken however, I'll
have a go at that as soon as I get my current project off my plate.
> Now, the fix itself is to honour DST changes, and that will work for
> everyone.
The point I'm trying (obviously in vain) to make is having cron do what
amounts to "slewing its internal clock" will not work for everyone, and
violates POLA.
> An alternative is to add better heuristics to see if the
> change in time is "almost exactly" a factor of 30 minutes (do any
> countries do anything but exactly 1 hour changes?).
Yes.
> This way, we never repeat jobs, and never lose jobs. Which makes cron
> reliable.
For your definition of "reliable." Personally, I find cron doing exactly
what it's told and not trying to think for itself "reliable."
> "Timing" problems with separate cron jobs will always be a
> hack job, and undoubtably they'll lose or double jobs by mistake anyway.
You (pl.) keep referring to the "We need to hand-hold users who are too
stupid to figure this stuff out for themselves" argument. While there are a
lot of areas of the system that I try to make simpler and easier to
understand, I don't see how we can possibly make this problem foolproof.
The universe keeps producing better fools.
> > > It's not that I want to talk you into something you don't want.
> >
> > But that's exactly what you're trying to do. I will not bother to
> > re-re-restate my points as to why what you're proposing is a bad idea.
> > Do all the testing you want, but make sure you understand that there
> > will be vigorous resistance to incorporating your proposed changes.
>
> And when you finally realize that everyone else thinks this is a great
> idea,
In fact, I'm quite sure that this is not true. I happen to be the only one
who is currently voicing opposition.
> you'll stop your sole campaign to vigourously resist the
> incorporation of this code? If it helps, we can have an option ('-i')
> to ignore DST changes, for "advanced administrators who know what
> they're doing and expect jobs to be lost or run multiple times depending
> on exactly when they schedule their jobs", and the "clueless newbies who
> ignorantly expect a job scheduled at 2am to not only run, but run only
> once" can be served too, by default.
At minimum, the proposed change would have to be described in detail in
the man page so that people who expect traditional cron behavior will know
what the heck is going on when cron starts to think for itself. I would
prefer that this new behavior be an option that is off by default, however
there would have to be an option to turn it off if ultimately it ends up
being the default.
> (Attitude almost entirely feigned to match Doug's)
Don't give up your day job. :)
Doug
--
"The most difficult thing in the world is to know how to do a thing and
to watch someone else do it wrong without comment."
-- Theodore H. White
Do YOU Yahoo!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Hello again.
On Tue, 9 Jan 2001, Doug Barton wrote:
> Neil Blakey-Milner wrote:
> >
> > On Tue 2001-01-09 (02:14), Doug Barton wrote:
>
> The point I'm trying (obviously in vain) to make is having cron do what
> amounts to "slewing its internal clock" will not work for everyone, and
> violates POLA.
Why won't "slewing it internal close" not work for everyone, I'm not
trying to be a pain, but I just don't know. Also, what is POLA?
> > This way, we never repeat jobs, and never lose jobs. Which makes cron
> > reliable.
>
> For your definition of "reliable." Personally, I find cron doing exactly
> what it's told and not trying to think for itself "reliable."
This is obviously a personal preference that no amount of talk is going to
change.
> > "Timing" problems with separate cron jobs will always be a
> > hack job, and undoubtably they'll lose or double jobs by mistake anyway.
>
> You (pl.) keep referring to the "We need to hand-hold users who are too
> stupid to figure this stuff out for themselves" argument. While there are a
> lot of areas of the system that I try to make simpler and easier to
> understand, I don't see how we can possibly make this problem foolproof.
> The universe keeps producing better fools.
I don't consider myself stupid (maybe other's do =) but when I'm admin'ing
a box, I have a bunch of other things that I'm thinking about and this
usually falls through the cracks. I have a hard time even remembering when
the DST shift is so I can change my alarm clock to make it into work at a
resonable hour.
> > you'll stop your sole campaign to vigourously resist the
> > incorporation of this code? If it helps, we can have an option ('-i')
> > to ignore DST changes, for "advanced administrators who know what
> > they're doing and expect jobs to be lost or run multiple times depending
> > on exactly when they schedule their jobs", and the "clueless newbies who
> > ignorantly expect a job scheduled at 2am to not only run, but run only
> > once" can be served too, by default.
>
> At minimum, the proposed change would have to be described in detail in
> the man page so that people who expect traditional cron behavior will know
> what the heck is going on when cron starts to think for itself. I would
> prefer that this new behavior be an option that is off by default, however
> there would have to be an option to turn it off if ultimately it ends up
> being the default.
I believe that there is already a bit in patch that updates the man page.
That can always be expanded. If this does make it in, it should have an
option to turn it on/off. However, I think that it should default to on.
Doug, you think that this patch is bad. The fact that this thread keeps
coming up twice a year makes me think that *something* should be done
about DST changes. Do you have alternate suggestion for what can/should be
done?
-gordon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Doug Barton wrote: > Neil Blakey-Milner wrote: > > > > On Tue 2001-01-09 (02:14), Doug Barton wrote: > > > Gerhard Sittig wrote: > > > This way, we never repeat jobs, and never lose jobs. Which makes cron > > reliable. > > For your definition of "reliable." Personally, I find cron doing exactly > what it's told and not trying to think for itself "reliable." Indeed. > > And when you finally realize that everyone else thinks this is a great > > idea, > > In fact, I'm quite sure that this is not true. I happen to be the only one > who is currently voicing opposition. No, you're not the only one opposed. I've stated my opposition previously and will re-state it here. If any change to expected cron behaviour is to be introduced, the traditional behaviour must be the default, with a knob documented in the man pages that can be twisted to get the oddball behaviour that is being proposed here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed 2001-01-10 (08:51), Greg Black wrote: > If any change to expected cron behaviour is to be introduced, > the traditional behaviour must be the default, with a knob > documented in the man pages that can be twisted to get the > oddball behaviour that is being proposed here. The oddball behaviour that is what, I imagine, the vast majority of people expect. We could take a vote here, if you like. Are you at all deluded into believing your position would win? I'm sorry, but cron should never miss jobs. And it should preferably not run the same job twice. All the hacks we've had to go through to simply get our daily jobs to run reliably (yes, this "reliable" word again). This oddball behaviour, unlike the numerous hacks tried before, and which still don't solve the intrinsic problem, has been tested, and is default, on OpenBSD, for the past 3 years. My reading of the code seems to indicate it does the right thing in all time update cases - it doesn't repeat wildcard jobs multiple times for the "medium" jump (1 to 3 hours), it doesn't miss jobs for any size jump forward, and it doesn't repeat jobs for negative jumps. It just ignores insanely big jumps (ie, over 3 hours). Since this is the default in OpenBSD, and we want to not randomly diverge from their code, and since they're more likely to accept code to ignore DST changes that a couple of people thinks is the correct thing, and so forth, we should have the behaviour as default. (Not to mention that it'll solve the endless complaints about missed or repeated runs we get twice every year. And no, these aren't clueless administrators as you and Doug believe, but people who expect tools to be reliable and do the obvious thing. Also, the only reason cron is doing the wrong thing now is that it is trying to be clever to let people set jobs in their local time, and we get bit because of silly things like DST. It should, of course, be expressed as UTC.) Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On 9 Jan 2001, at 10:20, Doug Barton wrote: > > And when you finally realize that everyone else thinks this is a great > > idea, I do not like being included in "everyone". I don't think it's a great idea. > > In fact, I'm quite sure that this is not true. I happen to be the only one > who is currently voicing opposition. IMHO, the solution is not to schedule jobs during during the changeover period. However, *if* the mods are adopted, it should default to off. Add a switch to turn them on. See how that runs for a few years. Then, and only then, if the feedback is positive, consider changing it to the default behaviour. Such a radical change to cron cannot be implemented without sufficient field testing. That will take years. It cannot be simulated. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed 2001-01-10 (21:20), Dan Langille wrote:
> > > And when you finally realize that everyone else thinks this is a great
> > > idea,
>
> I do not like being included in "everyone". I don't think it's a great idea.
If you didn't miss the comment, I was (and am now) attempting to emulate
Doug's style. (The "I don't like this change, and since nobody
commented, it must be a terrible thing" style.)
> > In fact, I'm quite sure that this is not true. I happen to be the only one
> > who is currently voicing opposition.
>
> IMHO, the solution is not to schedule jobs during during the changeover
> period. However, *if* the mods are adopted, it should default to off. Add
> a switch to turn them on. See how that runs for a few years. Then, and
> only then, if the feedback is positive, consider changing it to the default
> behaviour. Such a radical change to cron cannot be implemented
> without sufficient field testing. That will take years. It cannot be
> simulated.
These changes have been tested in OpenBSD for 3 years. The "solution"
is _not_ to tell people they're stupid to schedule jobs during the
changeover. It has nothing to do with them. If they want jobs at 2am
in the morning, that's cool. The fact the changeover is a problem is
cron-specific. It shouldn't be trying to be clever and work with local
time when local time does weird things like randomly add and remove time
from existence. However, since it _does_ have this "feature", we should
accomodate people who are negatively affected by it. It _will_ fix the
twice-yearly complaint about extra and missing jobs. It may create
unexpected behaviour for a tiny percentage. Those people should be
reading the release notes ("or they shouldn't be system administrators
or run FreeBSD").
Again, this change is from OpenBSD. We will synchronise with their
changes, and perhaps offer them back a patch to ignore what "ultra leet
sysadmins who rely on broken behaviour because people who don't are
simply stupid and shouldn't be running FreeBSD anyway!" with an option.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On 10 Jan 2001, at 11:24, Neil Blakey-Milner wrote:
> These changes have been tested in OpenBSD for 3 years.
That's a relatively smaller user-base compared to FreeBSD. Do you
consider that sufficient?
> The "solution"
> is _not_ to tell people they're stupid to schedule jobs during the
> changeover. It has nothing to do with them. If they want jobs at 2am
> in the morning, that's cool. The fact the changeover is a problem is
> cron-specific. It shouldn't be trying to be clever and work with local
> time when local time does weird things like randomly add and remove time
> from existence. However, since it _does_ have this "feature", we should
> accomodate people who are negatively affected by it. It _will_ fix the
> twice-yearly complaint about extra and missing jobs. It may create
> unexpected behaviour for a tiny percentage. Those people should be
> reading the release notes ("or they shouldn't be system administrators
> or run FreeBSD").
I don't see how the above relates to my point about sufficient testing. It
seems to be a repeat of what you've said before.
> Again, this change is from OpenBSD. We will synchronise with their
> changes, and perhaps offer them back a patch to ignore what "ultra leet
> sysadmins who rely on broken behaviour because people who don't are
> simply stupid and shouldn't be running FreeBSD anyway!" with an option.
Maybe I'm stupid. I couldn't parse that. But I get the drift.
--
Dan Langille
The FreeBSD Diary - http://freebsddiary.org/
FreshPorts - http://freshports.org/
NZ Broadband - http://unixathome.org/broadband/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed 2001-01-10 (22:35), Dan Langille wrote: > That's a relatively smaller user-base compared to FreeBSD. Do you > consider that sufficient? I would, yes, considering it has been three years. You may feel free to disagree, of course, and I'll get to why next: > I don't see how the above relates to my point about sufficient testing. It > seems to be a repeat of what you've said before. I obviously agree sufficient testing is required. Luckily, we have -CURRENT for "sufficient testing". If it's an incredible concern, this change could be postponed to being in a release until 5.0; by then we'd have had our own testing for at least one DST change, and OpenBSD's testing for at least 7. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Neil Blakey-Milner wrote:
> On Wed 2001-01-10 (21:20), Dan Langille wrote:
> >
> > IMHO, the solution is not to schedule jobs during during the changeover
> > period. However, *if* the mods are adopted, it should default to off. Add
> > a switch to turn them on. See how that runs for a few years. Then, and
> > only then, if the feedback is positive, consider changing it to the default
> > behaviour. Such a radical change to cron cannot be implemented
> > without sufficient field testing. That will take years. It cannot be
> > simulated.
>
> These changes have been tested in OpenBSD for 3 years.
That's not the same as testing under FreeBSD. And it's not just
a matter of testing anyway -- it's a matter of changing well
known and understood behaviour that has been in place for
decades for no other reason than that some people seem to be
unable to understand simple facts, such as the fact that playing
arbitrarily with clocks for DST leads inevitably to certain
anomalies in all kinds of scheduling.
Solutions to this include running the scheduler under a more
sensible time regime, such as UTC or TAI -- always an option for
cron, or avoiding the scheduling of tasks for times that can
either occur twice or not at all -- usually an option for Unix
cron tasks. None of this is rocket science.
Fiddling with cron to work around incompetent sysadmins just
exposes the rest of us to new bugs in cron -- a program that we
depend on for a large range of important tasks.
Of course, those of us who don't want to be bitten by the weird
new behaviour will have the option of retaining the current
(rather unattractive) BSD (aka Vixie) cron or of replacing it
with an entirely new tool and disabling the supplied cron
altogether, in much the same way as many people remove sendmail
in favour of qmail or named in favour of djbdns.
> The "solution"
> is _not_ to tell people they're stupid to schedule jobs during the
> changeover.
It's not a matter of telling people "they're stupid to schedule
jobs during the changeover," it's a matter of expecting them to
understand what it means to do that in those benighted places
that resort to DST.
> However, since it _does_ have this "feature", we should
> accomodate people who are negatively affected by it.
I think we should accommodate them in exactly the same way we
accommodate people who are negatively affected by the lack of
support for Word documents in vi, surely a far more pressing
problem.
> It _will_ fix the
> twice-yearly complaint about extra and missing jobs.
And that will reduce the list traffic of that type by a truly
insignificant amount.
> It may create
> unexpected behaviour for a tiny percentage. Those people should be
> reading the release notes ("or they shouldn't be system administrators
> or run FreeBSD").
Those people do read the release notes, just as they read the
stuff that gets on this list -- and at least some of them have
expressed strong reservations about the proposed changes. It
seems clear that the loudest noise comes from the proponents, so
I guess I'll have to dust off the sources to my old personal
cron implementation in readiness for the day when this thing
gets into the distribution.
> Again, this change is from OpenBSD. We will synchronise with their
> changes, and perhaps offer them back a patch to ignore what "ultra leet
> sysadmins who rely on broken behaviour because people who don't are
> simply stupid and shouldn't be running FreeBSD anyway!" with an option.
I cannot parse the final sentence above and don't think it adds
much to the case that is being made here. Since it seems that
heat rather than light is the base of much of the discussion, I
think I'll drop it now -- apart from a final plea that the new
behaviour be made to default to off if it gets up enough support
to be incorporated into FreeBSD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed 2001-01-10 (21:35), Greg Black wrote:
> > These changes have been tested in OpenBSD for 3 years.
>
> That's not the same as testing under FreeBSD.
Of course not, but it's a reasonably similar population type.
> And it's not just a matter of testing anyway -- it's a matter of
> changing well known and understood behaviour that has been in place
> for decades for no other reason than that some people seem to be
> unable to understand simple facts, such as the fact that playing
> arbitrarily with clocks for DST leads inevitably to certain
> anomalies in all kinds of scheduling.
To summarise: It is broken, we have the fix, but some people don't need
it, because they've given up on cron, beacsuse it's broken, and avoid
using the broken bits.
Not only that, but people who don't understand that it is broken are
unable to understand simple facts. In addition, it took the FreeBSD
project about 7 years to finally get their daily runs to run exactly
once, once every day.
> Solutions to this include running the scheduler under a more
> sensible time regime, such as UTC or TAI -- always an option for
> cron, or avoiding the scheduling of tasks for times that can
> either occur twice or not at all -- usually an option for Unix
> cron tasks. None of this is rocket science.
You left out "detecting DST changes, and acting accordingly".
> Fiddling with cron to work around incompetent sysadmins just
> exposes the rest of us to new bugs in cron -- a program that we
> depend on for a large range of important tasks.
Here you are doing it again. You're calling people who expect a tool to
work in a reliable and obvious way "incompetent", and the few people who
know the arcane arts to be some sort of elite. If you hadn't noticed
(despite my indication of the fact), I was attempting to emulate the
style of the detraction; that's why you seem to believe I'm getting
worked up over this. Trust me, I'm not.
If these people who know the arcane system administrator's art upgrade
their systems, don't read the release notes, and don't use the options
I'm suggesting we attempt to give them, then we've done all we can to
provide an alternative reliable and obvious scheduler (without "don't
schedule tasks in the morning! Beware!" notices).
> Of course, those of us who don't want to be bitten by the weird
> new behaviour will have the option of retaining the current
> (rather unattractive) BSD (aka Vixie) cron or of replacing it
> with an entirely new tool and disabling the supplied cron
> altogether, in much the same way as many people remove sendmail
> in favour of qmail or named in favour of djbdns.
Or using the supplied option.
> > The "solution"
> > is _not_ to tell people they're stupid to schedule jobs during the
> > changeover.
>
> It's not a matter of telling people "they're stupid to schedule
> jobs during the changeover," it's a matter of expecting them to
> understand what it means to do that in those benighted places
> that resort to DST.
Or of providing them with the option to not have to worry about all that
stuff? Or does that make FreeBSD too easy for plebs to use? (:
> > However, since it _does_ have this "feature", we should
> > accomodate people who are negatively affected by it.
>
> I think we should accommodate them in exactly the same way we
> accommodate people who are negatively affected by the lack of
> support for Word documents in vi, surely a far more pressing
> problem.
You seem to believe this is a feature. This is a bugfix for a feature
that already exists.
> > It may create
> > unexpected behaviour for a tiny percentage. Those people should be
> > reading the release notes ("or they shouldn't be system administrators
> > or run FreeBSD").
>
> Those people do read the release notes, just as they read the
> stuff that gets on this list -- and at least some of them have
> expressed strong reservations about the proposed changes. It
> seems clear that the loudest noise comes from the proponents, so
> I guess I'll have to dust off the sources to my old personal
> cron implementation in readiness for the day when this thing
> gets into the distribution.
Or just do the least-work thing and use the option provided to act in
the old way?
In summary: I do not see a valid argument for not having the bugfix at
all, available as an option. I do see the argument for not changing the
default. I also see that everyone who opposes seems to believe that it
is only people without major skills that get confused by all this, since
people with major skills know not to rely on any behaviour over DST
changes. 66% of them agree (33% haven't expressed an opinion) without
provocation that those people with major skills will read the release
notes. Common sense indicates that they are able to use a command line
option that disable the new reliable behaviour. There has been
expressed a need for testing. That is dealt with by three years in
OpenBSD, and a period of time in the development bra
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
> In summary: I do not see a valid argument for not having the bugfix at > all, available as an option. I do see the argument for not changing the > default. I also see that everyone who opposes seems to believe that it > is only people without major skills that get confused by all this, since > people with major skills know not to rely on any behaviour over DST > changes. 66% of them agree (33% haven't expressed an opinion) without > provocation that those people with major skills will read the release > notes. Common sense indicates that they are able to use a command line > option that disable the new reliable behaviour. There has been > expressed a need for testing. That is dealt with by three years in > OpenBSD, and a period of time in the development branch, as per most > development. > If this is turning into a vote: I'm for the new colour of the bikeshed. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Well, we've obviously hit a hot button issue for you here Neil, for reasons that I don't pretend to understand. Please try to reduce the amount of emotion that's going into your argument It's just a computer thing after all. :) On Wed, 10 Jan 2001, Neil Blakey-Milner wrote: > On Wed 2001-01-10 (21:20), Dan Langille wrote: > > > > And when you finally realize that everyone else thinks this is a great > > > > idea, > > > > I do not like being included in "everyone". I don't think it's a great idea. > > If you didn't miss the comment, I was (and am now) attempting to emulate > Doug's style. As I said previously, don't give up your day job. > (The "I don't like this change, and since nobody > commented, it must be a terrible thing" style.) Actually, that's not my postition at all. I have stated clearly and on several occasions that I oppose this change on its merits. When I was doing consulting work as a business I got hired to research this exact issue. I can't tell you who the customer was, unfortunately. The problem is that while the existing behavior of cron is somewhat confusing for certain edge cases (like DST, or poorly configured system timekeeping) it is the only behavior that makes sense for the vast majority of cases. In addition, while the problems are somewhat confusing to novice admins, the solutions are well known, and what's more, well documented, particularly in sources outside the freebsd project. Therefore, changing existing behavior, especially to something as dramatic as the proposed change is ill advised. > These changes have been tested in OpenBSD for 3 years. With all due respect to our friends in the openbsd project, I don't consider this a significant factor. Others have expressed reasons why this may or may not be the case in other threads, I'll leave it to that. > The "solution" is _not_ to tell people they're stupid to schedule jobs > during the changeover. Woah who said anything about people being stupid? What I said was that novice system admins, all the way down to desktop freebsd users don't really care about this issue (other than the occasional "how come my periodic thingy ran twice?" e-mails). More experienced admins, and/or people who have really time critical jobs will take the appropriate steps to make sure things happen the way they want. Our current cron is working exactly as it is (or should be) expected. Therefore, like so many other parts of the system, the "fix" is user education, rather than violating POLA in a major way by changing many years of established behavior. > It has nothing to do with them. If they want jobs at 2am > in the morning, that's cool. What if there is no 2am on a given day? You have defined a fairly limited problem set wherein your proposed changes are the solution. What I'm trying to tell you is that the problem set is much larger then what you're seeing. > The fact the changeover is a problem is > cron-specific. It shouldn't be trying to be clever and work with local > time when local time does weird things like randomly add and remove time > from existence. Once again, the current implementation of cron isn't trying to be clever. It's just doing what it's told, namely running jobs when the system clock tells it what time it is. > Again, this change is from OpenBSD. We will synchronise with their > changes, and perhaps offer them back a patch to ignore what "ultra leet > sysadmins who rely on broken behaviour because people who don't are > simply stupid and shouldn't be running FreeBSD anyway!" with an option. Well, this paragraph is obviously an attempted dig at me, but you're dramatically misrepresenting my position, as explained above. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Tue, 9 Jan 2001, Gordon Tetlow wrote: > Hello again. > > On Tue, 9 Jan 2001, Doug Barton wrote: > > > Neil Blakey-Milner wrote: > > > > > > On Tue 2001-01-09 (02:14), Doug Barton wrote: > > > > The point I'm trying (obviously in vain) to make is having cron do what > > amounts to "slewing its internal clock" will not work for everyone, and > > violates POLA. > > Why won't "slewing it internal close" not work for everyone, I'm not > trying to be a pain, but I just don't know. Also, what is POLA? I've commented in detail in previous messages as to why cron not sticking to what the system clock tells it is a bad idea. POLA stands for "The Principle Of Least Astonishment," which means that when you introduce changes into an established system you should do so in a way that does the least damage to continuity from one system to another. The FreeBSD project introducing a variety of cron that departs dramatically from many years of established behavior would be a POLA violation. > > You (pl.) keep referring to the "We need to hand-hold users who are too > > stupid to figure this stuff out for themselves" argument. While there are a > > lot of areas of the system that I try to make simpler and easier to > > understand, I don't see how we can possibly make this problem foolproof. > > The universe keeps producing better fools. > > I don't consider myself stupid (maybe other's do =) but when I'm admin'ing > a box, I have a bunch of other things that I'm thinking about and this > usually falls through the cracks. I have a hard time even remembering when > the DST shift is so I can change my alarm clock to make it into work at a > resonable hour. With all due respect, we can't change the laws of physics to help you with this one. :) Time is one of those things that system administrators have to manage, in more ways than one. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed, 10 Jan 2001, Neil Blakey-Milner wrote: > To summarise: It is broken, According to your definition of broken, which we have not necessarily reached a consensus on. > Not only that, but people who don't understand that it is broken are > unable to understand simple facts. Or perhaps we understand the simple facts, but there are more complex facts that make this change a bad idea. > In addition, it took the FreeBSD > project about 7 years to finally get their daily runs to run exactly > once, once every day. This is overstating the case. It was never really considered a huge issue by most, and at various times in the past the "correct" change for the majority of our userbase got mired down in socio-political arguments that had nothing to do with the technical merits. > What we haven't seen is any technical opposition to the algorithm used, > which has been explained. What you are seeing is opposition to the idea itself. I'm not going to waste time analyzing the implementation of what I think is a bad idea. :) Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Neil Blakey-Milner wrote: > On Wed 2001-01-10 (21:35), Greg Black wrote: > > To summarise: It is broken, we have the fix, No. You believe it is broken; you believe you have a fix. Not everybody agrees that it is broken or that any fix is required. > > Fiddling with cron to work around incompetent sysadmins just > > exposes the rest of us to new bugs in cron -- a program that we > > depend on for a large range of important tasks. > > Here you are doing it again. You're calling people who expect a tool to > work in a reliable and obvious way "incompetent", No, I'm calling people who can't be bothered finding out how things work incompetent. > If you hadn't noticed > (despite my indication of the fact), I was attempting to emulate the > style of the detraction; that's why you seem to believe I'm getting > worked up over this. Trust me, I'm not. You appear to be worked up, and denials don't reduce that appearance. > What we haven't seen is any technical opposition to the algorithm used, > which has been explained. If there is a problem with it, then that > should be determined. My review of it indicates the OpenBSD cron > behaviour is very specific, reliable, and obvious. People who don't believe in the justification for the change are not going to waste their time reviewing the implementation. If that's going to be done, it will have to be done by somebody who thinks the idea makes sense. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Tue, Jan 09, 2001 at 02:14 -0800, Doug Barton wrote: > Gerhard Sittig wrote: > > > > It's not that I want to talk you into something you don't > > want. > > But that's exactly what you're trying to do. Honestly -- no! :) OK, I've been unclear there. I did reply to your message, but writing to lists I usually do so for a broader audience -- for everything else I could use PM instead. So my continued proposal and discussion is mainly meant for those who do have interest in making cron work the way many users expect it to. Maybe more silent readers may find reasons against the proposal I fail to see, so far? I have no doubt that there is positive - while silent - agreement. Although I recognize you've dealt with the subject in much detail, know it's anything but trivial, and are aware that FreeBSD currently has no real solution, I realize you like telling all the concerned admins to shift their jobs around instead of accepting code changes meaning to make things work OOTB. It's nothing I can change. And it's nothing I would want to change after some amount of effort. We both (as well as others) have stated our impressions and that they're quite fixed and won't move. Let's end it here. > I will not bother to re-re-restate my points as to why what > you're proposing is a bad idea. Do all the testing you want, > but make sure you understand that there will be vigorous > resistance to incorporating your proposed changes. 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) - 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 ... :) - 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 Looking at the echo returning so far I see _much_ more "yes" than "nope" answers. There's consent that *something* has to be done. And I read the answers ranging from "yes, please do it!" (some six) via "I don't care -- as long as there's no impact on me ..." (one or two) to the few "I don't like it, I don't have this problem / I don't see this as a problem" (two, and the "explanation" is my guess -- but it's the only reason I could see for this position). Although I'm aware that statistics won't work for these small numbers - ten people took part in the thread so far - there's a trend visible to me. :> When in doubt, one could dig up in the archives how many threads took place in the past that "cron does strange things", which would enormously put weight on the "please do change something" section ... BTW: There's good news for those with a dislike regarding the change: While testing I'm stuck again, so there will be some more delay. It looks like I have to setup another OpenBSD machine to look into it a little deeper. Those who are interested in the status reached so far may contact me off list. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
[ note to nbm: would you like getting cc'ed, too? I'm used to keep receiver lists as short as possible, but feel free to state your wishes :) ] On Tue, Jan 09, 2001 at 10:20 -0800, Doug Barton wrote: > Neil Blakey-Milner wrote: > > > > Now, consider NTP calibrations, > > . . . > > Your example basically says, "Imagine a case where we have an > admin with time-critical jobs who refuses to set up proper time > synchronization." No, I read the example somewhat different: The admin told its system to run a job - every day - once a day - when 2:00 (or what the time was) is reached -- we already agree that this is more of a *hint* to the UNIX system than a strict regime, experience tells us the job won't get run before 2:00 but might start a while after "2:00 sharp" took place In the above example I wouldn't even dare to refer to the job as "time-critical" in the meaning that it is meant to run at an exact time. What's much more important to the usual backup / indexing / statistics / cleanup / whatever jobs is that they _do_ happen, and do so with the specified frequency. The reason why the discussion about "cron(8) is broken" comes up twice a year: Saying "'once a day' may be 'at least once' or 'maybe not at all'" is somewhat counter intuitive. There might be reasons why a given implementation shows some effect. But this doesn't necessarily mean that the mechanism is supposed to act this way (we don't blame UNIX to be broken just because the FreeBSD implementation has some bugs, do we?) ... That's the whole point where I see cron(8) to deviate from human expectation: Imagine you have a daily job - in your Real Life(TM) - to fetch your mail from the physical box, usually scheduled for 6:00 since you get up at 5:30. Would you skip it once you wake up late at 6:05 or would you try to catch up by walking through your todo list in the form it has accumulated in? I thought the latter would be what dispatching jobs and scheduling them in the possible way is meant to be like ... It's your dammit job on the list and it's the next tick after going to bed having done the previous day's jobs. Let's start the new day with its first job and do everything that's been scheduled. > > Now, the fix itself is to honour DST changes, and that will > > work for everyone. > > The point I'm trying (obviously in vain) to make is having cron > do what amounts to "slewing its internal clock" will not work > for everyone, and violates POLA. Whether there's a "violation" obviously depends on the expectation one has. That's why there will be a switch for what policy is the one the user wants to follow. This should satisfy those who believe cron to be correct in its current shape as well as those thinking that cron should behave differently. Do we have to discuss what DST changes mean? The different opinions what's expected behaviour seem to stem from the points of view "the skipped hour doesn't happen" vs. "the hour is squeezed into the one second" as well as "the hour willingly happens twice" vs. "there's a gap to be filled, we only count something to _have_ a datetime without really meaning it's this time, again (we already had it)". Or is it more of "in all the DST period it's not really that late"? As much as I like Neil's idea of using UTC for specifying execution times and thereby eliminating any ambiguity, I'm afraid this will make FreeBSD do something nobody else does this way -- I'm not clear as to how much this would confuse admins. What do other sibling projects do in this situation? Admittedly I haven't looked at NetBSD's and BSD/OS' documentation regarding this topic, but it seems I will have to in the very near future. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
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) We'd need some guarantees that the attempt to maintain current behaviour was done correctly -- i.e., without introducing bugs that broke things. > - 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 ... :) One of the things that would need to be documented is what will happen to the new algorithm in the situation where cron is stopped and re-started during one of the time periods that gets repeated. > - 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 In the beginning, something like CRON_DST_HACK="NO" in rc.conf with a comment pointing to the explanation should cover both these items. If more is needed later, then it can be added. > BTW: There's good news for those with a dislike regarding the > change: While testing I'm stuck again, so there will be some > more delay. Previously we were told that this stuff had already been tested for years under another OS and was therefore robust and reliable. Now we learn that these claims are not correct. And you wonder why people are reluctant to even consider these changes ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On 11 Jan 2001, at 16:33, Greg Black wrote: > We'd need some guarantees that the attempt to maintain current > behaviour was done correctly -- i.e., without introducing bugs > that broke things. What sort of guarantees are acceptable? > In the beginning, something like CRON_DST_HACK="NO" in rc.conf > with a comment pointing to the explanation should cover both > these items. If more is needed later, then it can be added. Do you mean /etc/defaults/rc.conf? -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
"Dan Langille" wrote: > On 11 Jan 2001, at 16:33, Greg Black wrote: > > > We'd need some guarantees that the attempt to maintain current > > behaviour was done correctly -- i.e., without introducing bugs > > that broke things. > > What sort of guarantees are acceptable? It would need to be tested against a set of "suitable" test crontab files across both ends of DST transitions using real timezone files -- either by running it for several months in -current or by dedicating a test machine that was rebooted several times for date changes a few days before and after the DST transitions. Faking timezone files leads to suspicions about bugs in them. Changing the date on a running system without rebooting leads to uncertainty about side-effects of large date changes. If I was doing this, I'd be looking for input with test data for the crontab files and I'd be looking hard (in advance) at the kinds of outcomes that would serve to validate the behaviour. Having once written and then maintained a cron implementation (more than 10 years ago), I do know that covering all bases is non-trivial. And, as I said previously, I'd want to know how the new code coped with cron being stopped and restarted during one of the DST transition times, as well as seeing assurances that the legacy version would do the same thing then as it does now. > > In the beginning, something like CRON_DST_HACK="NO" in rc.conf > > with a comment pointing to the explanation should cover both > > these items. If more is needed later, then it can be added. > > Do you mean /etc/defaults/rc.conf? One of the ways we break the POLA is the habit of changing the names and locations of those files. But yes -- if that's still its name when/if this thing happens. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed 2001-01-10 (12:52), Doug Barton wrote: > > To summarise: It is broken, > > According to your definition of broken, which we have not > necessarily reached a consensus on. I agree - there is no consensus, and there never will be. Some people want cron to be reliable, and not skip jobs or run jobs multiple times, and other people want cron to be reliable, and to skip jobs and run jobs multiple times. I believe the reliable behaviour is to never skip jobs. People schedule fixed-time jobs (the _only_ type affected by this change) with the intention that they will be run. I also believe people schedule fixed-time jobs (tagain, the only type affected by this change), with the anticipation that it will be run only once. Time doesn't really go backwards or forwards merely due to timezone changes or corrective time changing. Wildcard jobs are not affected by this change. Your hourly jobs will run every hour still. _Every_ hour. If there are two two-o'clocks in a row, it will be run twice, because in reality, there has been an hour passing. Every five minutes will run every five minutes, even if you correct the time backwards 18 minutes - it'll run at 10:30, 10:15, 10:20, 10:25, and 10:30 again (just like the current cron behaviour). One side says POLA means never changing a programs, and others say POLA means that a program shouldn't act in an astonishing way. They both have merit. > > Not only that, but people who don't understand that it is broken are > > unable to understand simple facts. > > Or perhaps we understand the simple facts, but there are more > complex facts that make this change a bad idea. Note, I was quoting a detractor, not saying this myself to anyone. I don't attack people when I don't agree with their argument. > > In addition, it took the FreeBSD > > project about 7 years to finally get their daily runs to run exactly > > once, once every day. > > This is overstating the case. It was never really considered a > huge issue by most, and at various times in the past the "correct" change > for the majority of our userbase got mired down in socio-political > arguments that had nothing to do with the technical merits. Of course it's hyperbole - what I'm saying is that every 6 months people get confused (and astonished) that jobs get skipped or doubled, and still nobody could agree on a simple way to fix this. My personal concern isn't DST changes (since I'm not influenced by them), but other corrective time measures that cron really should act reliably around. > > What we haven't seen is any technical opposition to the algorithm used, > > which has been explained. > > What you are seeing is opposition to the idea itself. I'm not > going to waste time analyzing the implementation of what I think is a bad > idea. :) The opposition I've summarised already: "People who don't know that cron is not reliable are unable to understand basic facts" (rough paraphrase). The arguments have often been against the idea in it's entirety, saying that this behaviour should never occur, even as an option, since it's a stupid idea. That is policy, and should be ignored - we don't enforce policy on our users. The only argument people can have is against the implementation of the change, and whether it should be default or an option. The implementation is good, unless someone cares to review it. I think it should be default, as the only people who will be inconvenienced by the new behaviour will be people who already consider cron to not be reliable around time changes. If they rely on it being unreliable, they can always use an option supplied to get the old behaviour, since they already spend a lot of time thinking of how to avoid the problems inherent in the old behaviour, and remembering a command line option (or looking it up in the man page) shouldn't be an issue for them. Yes, this is a POLA issue - it is astonishing to people that cron behaves this way, when they first see it. It will be "astonishing" to very fewer people if the default changes to the new behaviour, and we accomodate these people by placing it in the release notes, having an option for the old behaviour, and possibly delaying the use of the new system in the -STABLE branch until 5.0, if that is deemed necessary. Now, if anyone has a reasoned argument about the new algorithm (like, how it handles certain kinds of events in a surprising way), I'd like to hear it, or we can proceed to make it an option. If anyone has some clear cases why this is a truly astonishing change for people that can't adequately be handled in the accomodations listed above, we can hear your concerns too. If there is no clear winner, we can have it as just an option. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: > > On Tue, Jan 09, 2001 at 02:14 -0800, Doug Barton wrote: > > Gerhard Sittig wrote: > > > > > > It's not that I want to talk you into something you don't > > > want. > > > > But that's exactly what you're trying to do. > > Honestly -- no! :) Alright, I give up. Your post just before this one shows me that you are unwilling, or unable to accept the reality of the situation you're discussing, or even the proper definitions of the terms involved, so my efforts here are futile. > 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) > - 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 ... :) > - 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 I'd say these are the minimal acceptable design parameters for the project. The options you describe need to be command line options, not environment variables as someone else described. > Looking at the echo returning so far Which represents a very small percentage of the people who need to look at the change. A significant percentage (probably a majority) of the people who are freebsd developers abandoned -hackers long ago. When you have a working set of patches you should post a message to -arch with details and download instructions. > BTW: There's good news for those with a dislike regarding the > change: You and your associates keep trying to cast this in personal terms. It is not that I dislike your idea. I think your idea is dangerous, and wrong for the project. There is a big difference. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On 11 Jan 2001, at 17:06, Greg Black wrote: > And, as I said previously, I'd want to know how the new code > coped with cron being stopped and restarted during one of the > DST transition times, as well as seeing assurances that the > legacy version would do the same thing then as it does now. If the changes are modular, and I sure hope they are, it would almost be a matter of: if newcode then call new stutt end if But I'm guessing it's going to be a *bit* more complicated than that. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Hi, > And, as I said previously, I'd want to know how the new code > coped with cron being stopped and restarted during one of the > DST transition times, as well as seeing assurances that the > legacy version would do the same thing then as it does now. The legacy version only checks for jobs that fire in the exact current minute. If it was stopped, it wouldn't run jobs for the missed time. The new behaviour is to run the fixed-time jobs that are between the last known time, and the current time, if the stop time is less than 3 hours (if it is more, assume that the change is not a standard DST thing or normal corrective time change). If the time change is less than 5 minutes, then cron should try run all jobs for each minute that passed between the last known time and the current time. If over 5 minutes, then cron will check for all wildcard jobs that would have fired, and run it only once, even if it would have run multiple times). If time goes backwards, fixed-time jobs are assumed to have already run, and if we happen to match a wildcard job for the current minute, run it. If there is a fixed job at 2:40, and we pass 2:40, run the job, and then at 3, time goes backwards, don't run it. If cron gets killed at 2:50, and started at 2:55, and time goes backwards to 2:00, the 2:40 job isn't run either, since the virtual time is still at 3:00. If cron is running at 2:40, the job is run, cron is killed, and restarted just after the change back to 2:00, it will run the 2:40 job, as it wasn't around to experience the DST change. Similarly, if cron isn't around to experience a forward jump, it won't magically know to run the jobs missed. All of which makes me ponder putting cron_tz option in rc.conf and suggesting people set it to UTC or some other non-DST-afflicted place, but that isn't the only use of these changes. However, the new behaviour does do the expected things for common changes - if it's a relatively small forward jump, run whatever jobs would have run. If it's a medium-sized jump, run all the fixed-time jobs, and one of each wildcard job that would have occured. If it's a massive jump, assume something unusual is up, and don't run any jobs. If it's a small backwards jump, assume fixed-time jobs shouldn't be run again until we reach the time we jumped back. And if it's a big backwards jump, assume something unusual is up, and just start functioning as if the time hadn't changed. The previous behaviour says not to care what changes occur in time whatsoever, and only compare this exact current minute of the waking up to the crontab list, and run those jobs. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Dan Langille wrote: > > On 11 Jan 2001, at 16:33, Greg Black wrote: > > > We'd need some guarantees that the attempt to maintain current > > behaviour was done correctly -- i.e., without introducing bugs > > that broke things. > > What sort of guarantees are acceptable? > > > In the beginning, something like CRON_DST_HACK="NO" in rc.conf > > with a comment pointing to the explanation should cover both > > these items. If more is needed later, then it can be added. > > Do you mean /etc/defaults/rc.conf? > Howabout having a setting: TZ=GMT0BST or TZ=Europe/London in the crontab file, analogous to the MAILTO= or USER= settings that already exist. That would mean individual user crontabs could run on different timezones --- or would that just be too complicated? I suppose the default (with no TZ= setting) should be to work just as cron does now, using the system standard timezone, without DST hacks, or you could choose a timezone setting without DST changes: TZ=UTC and probably TZ=localtime to use the system default time zone, with DST hacks. Matthew PS. If anyone is counting, put me down as one who thinks the DST hack is a good idea. -- Certe, Toto, sentio nos in Kansate non iam adesse. Dr. Matthew Seaman, Inpharmatica Ltd, 60 Charlotte St, London, W1T 2NU Tel: +44 20 7631 4644 x229 Fax: +44 20 7631 4844 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
I know I'm going to regret this, but since silence is being taken to be consent here, I'd better speak up. My opinion, for those keeping count: Changing cron to internally compensate for changing timezones seems to open more doors for bugs and misfeatures than it closes. FreeBSD is in use worldwide, and compensating for all the various timezone shifts has the potential to cause serious code bloat. If you don't catch all the possible shifts, it's hard to claim the solution is complete. I oppose such changes. If someone wants to change cron's behavior to make DST (and other timezone shenanigans) behave intuitively, add a flag to make cron work exclusively in UTC as someone else suggested. It's simple to explain which means less user confusion, and covers all the cases (even crossing the International Date line with a mobile laptop) which reduces code bloat. Finally it's conceptually simpler and more elegant. I think that's worth something. I don't think that changing cron's behavior for DST is a pressing issue. However, if a change is made, I support the change to using UTC (as a user configurable option, default off), not detecting and correcting for all possible local time mods. PGP signature
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed, 10 Jan 2001, Gerhard Sittig wrote: > Looking at the echo returning so far I see _much_ more "yes" than > "nope" answers. There's consent that *something* has to be done. Heh, if its votes you are looking for then you can add another to your "nope" column for what its worth. The current behavior is the expected behavior and should remain. I'd suggest moving the man 5 conrtab BUGS section content (really doesn't belong there, its not really what I would call a bug) up to the section discussing field contents so admins/users are hit with it each time they look. Or perhaps adding a note to the default crontab comments. I'd see this as being more helpful. Darren Henderson [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
FWIW, I'm against changing cron. Ted Faber said it best: > If someone wants to change cron's behavior to make DST (and > other timezone shenanigans) behave intuitively, add a flag to > make cron work exclusively in UTC as someone else suggested. > It's simple to explain which means less user confusion, and > covers all the cases (even crossing the International Date > line with a mobile laptop) which reduces code bloat. Finally > it's conceptually simpler and more elegant. I think that's ^^ > worth something. -- Tim Jackson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Thu, Jan 11, 2001 at 01:05 -0800, Doug Barton wrote: > Gerhard Sittig wrote: > > > > Looking at the echo returning so far > > Which represents a very small percentage of the people who need > to look at the change. A significant percentage (probably a > majority) of the people who are freebsd developers abandoned > -hackers long ago. How am I supposed to know? Especially after asking "how to? where to go?" without getting this kind of redirection? That's been part of what rises frustration when you don't know whether you're plain wrong or just unheard. But we had the OT discussion already and don't need to replay it here ... > > BTW: There's good news for those with a dislike regarding > > the change: > > You and your associates keep trying to cast this in personal > terms. Not to leave a false impression: I don't have any "associates" here. It just happened that there was no unisono rejection and some readers thought (like I did) teaching cron about DST would be a good idea. The always bubbling up threads and PRs may have led there. > It is not that I dislike your idea. I think your idea is > dangerous, and wrong for the project. There is a big > difference. OK, in the meantime I did what I didn't want to bother you with: setup another OpenBSD machine and have it run some test. It's just that toying with DST without artificially jumping the clock (and thus falsifying the test, see my other message) takes a few days for a single cycle. And we all have our day jobs. As well as other spare time projects. Some of us even have a real life. I hope to have come back to reasonable and technically based discussion with the summary I just sent out in the other reply. That's the kind of "redirection towards what will be a real solution" I hoped to get together with the refusal in case my first approach was wrong. It obviously took some laps to get there ... :) virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Thu, Jan 11, 2001 at 13:19 -0500, Darren Henderson wrote: > > On Wed, 10 Jan 2001, Gerhard Sittig wrote: > > > Looking at the echo returning so far I see _much_ more "yes" > > than "nope" answers. There's consent that *something* has to > > be done. > > Heh, if its votes you are looking for then you can add another > to your "nope" column for what its worth. The current behavior > is the expected behavior and should remain. If those votes help in estimating what the community opinion is: Yes, I want to get them! Wouldn't you like to know, too, how much of acceptance is there for the results of work you do in your spare time? We only have limited resources, and we aren't paid for contributing. Well, most of us. So there should at least be the motivation of "yes, it makes sense what I do here and it brings us some advantage". > I'd suggest moving the man 5 conrtab BUGS section content > (really doesn't belong there, its not really what I would call > a bug) up to the section discussing field contents so > admins/users are hit with it each time they look. Or perhaps > adding a note to the default crontab comments. I'd see this as > being more helpful. The above crontab(5) BUGS section BTW is the result of another "DST breaks cron / is broken by cron" PR back in April 1999. This PR conf/10947 has a rather lengthy discussion on wether it is a bug or an implementation detail and wheter it should be documented in the NOTES section. The problem with DST and cron doesn't seem to be so much that it isn't documented. But more that it doesn't spring to mind immediately to those admins affected. Especially when they didn't schedule the daily job themselves but merely drop in their own scripts to the collection alredy installed and having its execution time. Maybe the actual problem is the lack of an afterboot(7) manpage which could make admins really check the thousand things in a fresh installation they might even not be aware of. PR bin/3314 as of April 1997 BTW has a patch in it from Mark Thompson which basically looks like what OpenBSD incorporated in December 1997. It was then rejected. And it is what doesn't solve the DST issue as I stated in the summary message since its only criterion for the time passed by is the time(3) syscall. So we couldn't use it even when we were willing to teach cron about DST. These PRs is what I found after searching for closed PRs, too. But I couldn't imagine that such an eternal problem is not open. Next time I will know better. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
[ for the impatient there's a summary at the bottom ("/summarize") ]
On Thu, Jan 11, 2001 at 16:33 +1000, Greg Black wrote:
> 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)
>
> We'd need some guarantees that the attempt to maintain current
> behaviour was done correctly -- i.e., without introducing bugs
> that broke things.
The only way I could think of to make sure there won't be new
bugs would be peer review. The reason why we're not yet at this
stage is my personal failure to make any (visible) progress.
There seems to be a catch22: I don't want to bother you with
untested code, but I fail to successfully test what I have here
as long as I'm alone fighting it. But that's OK with me as it
"only" slows things down a bit. Compared to the time this topic
has been discussed in over the last few years some more weeks
don't count that much ...
> > - 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 ... :)
>
> One of the things that would need to be documented is what will
> happen to the new algorithm in the situation where cron is
> stopped and re-started during one of the time periods that gets
> repeated.
Oh, you bring up an absolutely new datapoint it seems! Since all
the information vixie cron (in its original form as well as the
OpenBSD variant) keeps its state in is held in memory (the time
it went to sleep, the time it expects to wake up again, the time
it is collecting jobs for -- usually somewhere between the time
it went to sleep and the time it woke up at, catching up towards
the current time) it wouldn't know that it does repeat an hour it
just has passed few minutes ago in case there's been a restart in
between.
This lack of persistency is some (mis)behaviour the OpenBSD
version has, too. And it isn't documented there, either. It
looks like this point should be fed back to their project, too
(to be solved by extending the documentation).
A solution to make this state persistent would be to
- have cron.c:set_time() read state from a file which
- cron.c:cron_sleep() will write to before going to sleep.
The file probably should live somewhere next to the crontab spool
directory. But permanently writing state to disc to keep this
kind of persistency is what we have learnt to be wrong from the
latest /etc/rc and Yarrow thread on cvs-all ...
And yes, now that you brought this up, I can see the (IMO first
technical and valid) point against the proposed change.
It turns out that specifying cronjobs' timings in UTC is the only
real solution. Should any existing will to *somehow* solve the
current situation better be spent on writing a frontend to _this_
approach (some vicron(8) command being a vipw(8) workalike,
translating users' specifications in local time to a unified
coordinate system; or a cron(8) command line option to interpret
the crontab time specification in UTC) instead of shooting down
the effort I'm trying to do now? It's not that I would insist in
following a dead end's path. But I would like to learn _how_ to
solve the problem and how to contribute if my current proposal
turns out to just not work at all in forseable future or for some
obvious(?) reason.
This is BTW the reason why I asked some seven weeks back in
cvs-all message <[EMAIL PROTECTED]> *if* the
OpenBSD approach would be a solution for us, if somebody is
already to handle the DST topic, and if I should lend a hand /
jump in on existing works. Just to find myself welcomed with a
warm and heartly "Go away and do something more useful instead!"
which might one of the reasons for this discussion being not
wholly technical ... :>
> > - 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
>
> In the beginning, something like CRON_DST_HACK="NO" in rc.conf
> with a comment pointing to the explanation should cover both
> these items. If more is needed later, then it can be added.
I would have done some cron_flags setting in rc.conf(5) since
this is already kind of missing in case you want to activate some
-x command line parameters. :) Of course this would have its
comment in /etc/defaults/rc.conf and its section in the
rc.conf(5) manpage pointing to the fullblown discussion in the
cron(8) manpage.
> > BTW: There's good news for those with a dislike regarding
> > the change: While testing I'm stuck again, so there will be
> > some more delay.
>
> Previously we were told that this stuff had already been tested
> for years under another OS and was therefore robust and
> reliable. Now
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
> > One of the things that would need to be documented is what will > > happen to the new algorithm in the situation where cron is > > stopped and re-started during one of the time periods that gets > > repeated. > > Oh, you bring up an absolutely new datapoint it seems! Since all > the information vixie cron (in its original form as well as the > OpenBSD variant) keeps its state in is held in memory (the time > it went to sleep, the time it expects to wake up again, the time > it is collecting jobs for -- usually somewhere between the time > it went to sleep and the time it woke up at, catching up towards > the current time) it wouldn't know that it does repeat an hour it > just has passed few minutes ago in case there's been a restart in > between. > Oh no. If this "clock-slewing" was implemented, I'd expect killing and restarting cron be a way to forget everything which had happened. I.e. if I wanted to test a schedule, I might want to stop cron, reset time and start cron again. Cron usually doesn't die by itself. If it gets killed, it is usually for a reason. Don't complicate this proposed change with also having to add persistance over a kill and restart. Does anacron handle this DST issue better? Could it be added to ports if so, and a knob NO_CRON in make.conf? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Could you guys remove my name from the Cc: list on this thread please? I've already made my position quite clear. Thanks, Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Ok, this has gone on long enough that my normal inhibitions about driving down the signal-to-noise ratio of a technical list have long subsided. Folks, cron is a *LOW LEVEL SERVICE* much in the same vein as UDP. Neither one makes strong guarantees about ordering, duplication, or dropped events. Those are for higher layer services, iff they are needed. *BSD may very well have a need for a temporal equivalent to TCP where stronger guarantees are made, but it is not and should not be cron. That said, I can't help dinking with the design :-) What would happen if the definitions of the hour and minute fields were subtly changed to mean "elapsed wall-clock time since local midnight"? Then, the DST conversion is no longer ambiguous. "Two hours since local midnight" only happens once regardless. On days where the clocks change, most scripts would wind up running an hour ahead or behind their usual time, but hey, so are many of the people :-). There would also have to be an entry in the BUGS section noting that some days have 23 or 25 hours, which is accurate. -JohnG To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: > On Thu, Jan 11, 2001 at 16:33 +1000, Greg Black wrote: > > > BTW: There's good news for those with a dislike regarding > > > the change: While testing I'm stuck again, so there will be > > > some more delay. > > > > Previously we were told that this stuff had already been tested > > for years under another OS and was therefore robust and > > reliable. Now we learn that these claims are not correct. And > > you wonder why people are reluctant to even consider these > > changes ... > > "We were told UNIX had been around for some thirty years, is said > to be functional / reliable / flexible / add whatever you use and > love UNIX for. And now we learn it doesn't even work easily for > those simple tasks as networking / printing / gaming / etc are?" > > Excuse me, please? Could it be that you got more from my > messages than what I actually said? Please read more carefully. I said: "we were told that this stuff had already been tested for years [...]". I did not say who made this claim, although I assumed that those few people who are following this thread would have remembered who it was. The claim /was/ made. I suggested that it was invalid. I still think that. As for the implementation issues that you covered in detail, I have no comment as I'm not interested in reviewing the code for a change that I see no case for. > I understand that having the clock jump is a Bad Idea(TM). > Especially when it is jumping backward since this violates the > model we have of time (*always* monotonously increasing [...] It may be monotonous, but it's supposed to be monotonically increasing. > And I realize that the DST topic is anything but trivial, cannot > be handled by my ported patch and actions can easily do harm when > done incorrectly. The only solutions turn out to be > - education [...] Not such a bad method. We use it for all the "How do I remove a file named -x?" questions -- we don't "fix" rm or the way the shells parse commands. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
John Gregor wrote: > > What would happen if the definitions of the hour and minute fields > were subtly changed to mean "elapsed wall-clock time since local > midnight"? Then, the DST conversion is no longer ambiguous. "Two > hours since local midnight" only happens once regardless. On days > where the clocks change, most scripts would wind up running an hour > ahead or behind their usual time, but hey, so are many of the people > :-). There would also have to be an entry in the BUGS section noting > that some days have 23 or 25 hours, which is accurate. I believe that the handling of DST change in cron must be fixed. Practically every commercial Unix (except the very retarded ones) does that and that's something the sysadmins normally expect. I'll probably look if I can fix it. The logic I plan to implement is (this is a quote from somewhere else but it describes my intentions): Now the jobs run as intuitively expected. If a job falls into time interval that disappears during switch from standard time (ST) to daylight saving time (DST) or is duplicated during the reverse switch, then it's handled in one of 2 ways. The jobs that run every hour work as before, they skip the skipped hour or run in the added hour as usual. But the jobs that run less frequently are executed exactly once, they are not skipped nor executed twice (unless cron is restarted or the user's crontab is changed during such a time interval). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
If someone wants to tackle this, a few words to the wise. * testing for daylight savings times changes. You test this by comparing the differential between two time_t's (dtime1) against the differential between two time_t's after converting them to localtime and then back to time_t's as if the localtime structure were in GMT (dtime2). If dtime1 has a large differential the clock was stepped and all daylight savings specific state must be ignored and/or reset. If dtime1 is reasonable and (dtime2 - dtime1) shows a large differential (e.g. 20 minutes or greater), you hit a daylight savings switch and can use this to drive your state logic. Make sure your code is robust enough to ignore leap seconds and other minor corrections that cron already deals with. Encapsulate the state machine for handling daylight savings shifts into a single procedure if you can. Do not spread special cases all over the codebase. Don't worry about making lots of calls to the libc time conversion routines if it makes your job easier. * cron is a critical system resource. Don't blow it. For example, for many many years Vixie cron had horrendous bugs in it that would for example cause it to try to 'catch up' on time steps, resulting in systems suddenly running hundreds of cron jobs simultaniously. (this and other bugs were what prompted me to write dcron for Linux a number of years ago). Whatever you do, don't ressurect old bugs! All of that said, if someone wants to tackle this issue in cron, I think it would be great. Having written a cron program before I would be happy to review the patchsets. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On 1 Jan, Doug Barton wrote: > Gerhard Sittig wrote: >> >> [ ... reminder after two weeks of silence ... ] > > Two weeks of silence is generally enough to let you know that no one is > interested in this modification. If someone was, they'd generally have > said something by now. > > 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. > > Just so you wouldn't think you were being ignored, > I didn't see this can you email me about it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed, Jan 10, 2001 at 08:51 +1000, Greg Black wrote:
>
> If any change to expected cron behaviour is to be introduced,
> the traditional behaviour must be the default, with a knob
> documented in the man pages that can be twisted to get the
> oddball behaviour that is being proposed here.
In http://www.freebsd.org/cgi/query-pr.cgi?pr=24358 ("/etc/rc
variables for cron(8)") I suggest how to provide knobs to pass
parameters to cron as well as to switch to a different cron
executable, while of course leaving current behaviour as the
default.
This is meant for those who feel a change to be necessary or
highly desirable. No matter how soon "DST solutions" will be
available and what they will look like.
This opens the opportunity to use a cron daemon from ports as
well as settling another - maybe repo copied - cron variant in
the FreeBSD tree (although I fail to estimate how probable this
is to happen). For highly involved developers this opens the
opportunity to plug in an own cron version or to pass options to
locally modified sources.
But I recognize that there are strong concerns about touching the
current src/usr.sbin/cron tree -- it is expected to be broken by
being touched. For whatever the definition of "broken" might be:
deviation from expected behaviour or introduction of real bugs.
I feel that the proposed extension will contribute to everybody's
satisfaction ...
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote:
> On Wed, Jan 10, 2001 at 08:51 +1000, Greg Black wrote:
> >
> > If any change to expected cron behaviour is to be introduced,
> > the traditional behaviour must be the default, with a knob
> > documented in the man pages that can be twisted to get the
> > oddball behaviour that is being proposed here.
>
> In http://www.freebsd.org/cgi/query-pr.cgi?pr=24358 ("/etc/rc
> variables for cron(8)") I suggest how to provide knobs to pass
> parameters to cron as well as to switch to a different cron
> executable, while of course leaving current behaviour as the
> default.
This looks fine to me, as far as it goes. I'm assuming here
that the proposed new behaviour for cron will only be enabled if
a specific flag is provided?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed, Jan 17, 2001 at 06:43 +1000, Greg Black wrote:
> Gerhard Sittig wrote:
> >
> > In http://www.freebsd.org/cgi/query-pr.cgi?pr=24358 ("/etc/rc
> > variables for cron(8)") I suggest how to provide knobs to
> > pass parameters to cron as well as to switch to a different
> > cron executable, while of course leaving current behaviour as
> > the default.
>
> This looks fine to me, as far as it goes. I'm assuming here
> that the proposed new behaviour for cron will only be enabled
> if a specific flag is provided?
Exactly. Since nobody wants to ram any changes down anybody
else's throat, as I get it from the thread. It all is about
providing "corrected" behaviour for those who want it. And those
obviously will have to act to get it.
I'm just editing the PR with the cron patches to "catch up" with
OpenBSD in this respect (stating that it doesn't handle DST, but
has benefits whenever one's clock is jumping or cron waking up
too late and _could_ be extended to handle DST). Therein I
suggest to
- not touch current cron at all but switch to a different
executable by means of the newly introduced rc.conf variables
or to
- modify cron but make the new code optional while defaulting to
off
(in this order). Although I cannot say which variant will happen
driven by those with enough priviledges to decide and commit. As
well as I cannot even tell you if something will be done at all
in the near future regarding the fact that there's no DST
solution available yet -- which was the actual reason for the
wish to change something.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On 17 Jan 2001, at 18:48, Gerhard Sittig wrote: > I'm just editing the PR with the cron patches to "catch up" with > OpenBSD in this respect (stating that it doesn't handle DST, but > has benefits whenever one's clock is jumping or cron waking up > too late and _could_ be extended to handle DST). Therein I > suggest to > - not touch current cron at all but switch to a different > executable by means of the newly introduced rc.conf variables > or to This is the safest route IMHO. No risk for that that choose not to use it. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: > I'm just editing the PR with the cron patches to "catch up" with > OpenBSD in this respect (stating that it doesn't handle DST, but > has benefits whenever one's clock is jumping or cron waking up > too late and _could_ be extended to handle DST). Therein I > suggest to > - not touch current cron at all but switch to a different > executable by means of the newly introduced rc.conf variables > or to > - modify cron but make the new code optional while defaulting to > off I prefer option 1. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
:I'm just editing the PR with the cron patches to "catch up" with :OpenBSD in this respect (stating that it doesn't handle DST, but :has benefits whenever one's clock is jumping or cron waking up :too late and _could_ be extended to handle DST). Therein I :suggest to :- not touch current cron at all but switch to a different : executable by means of the newly introduced rc.conf variables : or to :- modify cron but make the new code optional while defaulting to : off :(in this order). Although I cannot say which variant will happen :driven by those with enough priviledges to decide and commit. As :well as I cannot even tell you if something will be done at all :in the near future regarding the fact that there's no DST :solution available yet -- which was the actual reason for the :wish to change something. : :virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 :Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] In the second suggestion, I presume turned off by default but can be turned on with a command-line option? (Verses a make.conf compile-time variable). I like the idea of a command-line option to turn on the 'new' code. That provides a consistent, straightforward way of allowing developers to test the code, making it available in releases with a simple rc.conf twitch, and eventually (years later judging by the flame war:-)) turning it on in /etc/defaults/rc.conf. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Fri 2001-01-19 (12:44), Matt Dillon wrote:
> :I'm just editing the PR with the cron patches to "catch up" with
> :OpenBSD in this respect (stating that it doesn't handle DST, but
> :has benefits whenever one's clock is jumping or cron waking up
> :too late and _could_ be extended to handle DST). Therein I
> :suggest to
> :- not touch current cron at all but switch to a different
> : executable by means of the newly introduced rc.conf variables
> : or to
> :- modify cron but make the new code optional while defaulting to
> : off
> :(in this order). Although I cannot say which variant will happen
> :driven by those with enough priviledges to decide and commit. As
> :well as I cannot even tell you if something will be done at all
> :in the near future regarding the fact that there's no DST
> :solution available yet -- which was the actual reason for the
> :wish to change something.
> :
> :virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
> :Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
>
> In the second suggestion, I presume turned off by default
> but can be turned on with a command-line option? (Verses
> a make.conf compile-time variable). I like the idea of
> a command-line option to turn on the 'new' code. That provides
> a consistent, straightforward way of allowing developers to test
> the code, making it available in releases with a simple rc.conf
> twitch, and eventually (years later judging by the flame war:-))
> turning it on in /etc/defaults/rc.conf.
There seems not to be a real argument against the algorithm, plenty of
support for having it available as an option, and only an argument
against it being default. I'm quite happy for it not to be default, as
I'm sure Gerhard is.
Thus, there's no reason not to add the ability (at least OpenBSD, Debian
and HP-UX have similar behaviour), so we should proceed. All we need do
is add the option to getopt, and turn the "optimisation check for the
default 1 minute case" to check if the "new behaviour flag" is not
checked. Ie:
if (!bflag || (timeDiff == 1)) {
virtualTime = timeRunning;
find_jobs(virtualTime, &database, TRUE, TRUE);
} else {
wakeupKind = -1;
if (timeDiff > -(3*MINUTE_COUNT))
wakeupKind = 0;
...
It should work exactly like the old cron behaviour, unless the '-b' flag
is given.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
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" [EMAIL PROTECTED]
--
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
All, I've committed these changes for cron to support DST change to -current (see PR bin/24494 for description of my tests). Everyone is welcome to test them out. Please let me know if you encounter any problems caused by them (and better do that before these changes would be MFCed to -stable in a few weeks). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > All, > > I've committed these changes for cron to support DST change > to -current (see PR bin/24494 for description of my tests). > Everyone is welcome to test them out. > Please let me know if you encounter any problems caused by them > (and better do that before these changes would be MFCed to -stable > in a few weeks). I do believe this is premature. There really should at least be an option for the old behaviour, and there is a good argument for making the new behaviour optional dependent on a variable with the old behaviour default. _Especially_ if you intend to MFC this, since changing this behaviour in a minor release, without a way to have the old behaviour, is almost certainly wrong. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Neil Blakey-Milner wrote: > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > All, > > > > I've committed these changes for cron to support DST change > > to -current (see PR bin/24494 for description of my tests). > > Everyone is welcome to test them out. > > Please let me know if you encounter any problems caused by them > > (and better do that before these changes would be MFCed to -stable > > in a few weeks). > > I do believe this is premature. There really should at least be an > option for the old behaviour, and there is a good argument for making > the new behaviour optional dependent on a variable with the old Let me ask a simple question: Why ? What are the benefits of preserving the old behavior ? As far as I've watched this thread nobody had explained it. So could you please elaborate ? On the other hand I clearly see the benefits of avoiding loss or duplication of once-a-day (or even more rare) cron jobs. If some job is scheduled once a day (or even once a week or once a month) then it's probably a rather heavy job. So running two of them at once is not a good thing even if they would not mess up each other but just slow down the machine. Skipping such a job seems to me as an almost equally bad thing. (Yes, I'm speaking from my personal experience as sysadmin as well). > behaviour default. _Especially_ if you intend to MFC this, since > changing this behaviour in a minor release, without a way to have the > old behaviour, is almost certainly wrong. That's why I asked for comments. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Sergey Babkin wrote: > Neil Blakey-Milner wrote: > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > All, > > > > > > I've committed these changes for cron to support DST change > > > to -current (see PR bin/24494 for description of my tests). > > > Everyone is welcome to test them out. > > > Please let me know if you encounter any problems caused by them > > > (and better do that before these changes would be MFCed to -stable > > > in a few weeks). > > > > I do believe this is premature. There really should at least be an > > option for the old behaviour, and there is a good argument for making > > the new behaviour optional dependent on a variable with the old > > Let me ask a simple question: Why ? What are the benefits of > preserving the old behavior ? As far as I've watched this thread > nobody had explained it. So could you please elaborate ? You have not been paying attention. Please go back and /read/ the archives on this topic which has been thrashed out in great detail here. We did not reach agreement about the desired behaviour because the nature of this issue is that different people desire different behaviour. What was agreed by those who contributed was clearly that the old behaviour was to be preserved by default and that new behaviour was to be enabled by a command-line option, which could be set in rc.conf. You have shown no reason not to go with the solution that was agreed, so please don't just jump in with your big boots on insisting that you know best. Nobody knows best about this. > > behaviour default. _Especially_ if you intend to MFC this, since > > changing this behaviour in a minor release, without a way to have the > > old behaviour, is almost certainly wrong. > > That's why I asked for comments. You should have read the thread more carefully. But you have been given comments now. Take heed of them and don't push ahead with this plan. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Sergey Babkin wrote: > > Neil Blakey-Milner wrote: > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > All, > > > > > > I've committed these changes for cron to support DST change > > > to -current (see PR bin/24494 for description of my tests). > > > Everyone is welcome to test them out. > > > Please let me know if you encounter any problems caused by them > > > (and better do that before these changes would be MFCed to -stable > > > in a few weeks). > > > > I do believe this is premature. There really should at least be an > > option for the old behaviour, and there is a good argument for making > > the new behaviour optional dependent on a variable with the old > > Let me ask a simple question: Why ? What are the benefits of > preserving the old behavior ? As far as I've watched this thread > nobody had explained it. So could you please elaborate ? The fact that you do not understand, or do not accept the many salient points that have been made in opposition to this change does not mean that they do not exist. > On the other hand I clearly see the benefits of avoiding loss > or duplication of once-a-day (or even more rare) cron jobs. > If some job is scheduled once a day (or even once a week or > once a month) then it's probably a rather heavy job. So running > two of them at once is not a good thing even if they would not > mess up each other but just slow down the machine. Skipping > such a job seems to me as an almost equally bad thing. > (Yes, I'm speaking from my personal experience as sysadmin as well). > > > behaviour default. _Especially_ if you intend to MFC this, since > > changing this behaviour in a minor release, without a way to have the > > old behaviour, is almost certainly wrong. > > That's why I asked for comments. With changes of this magnitude we do not shoot first and ask questions later. Both the proponents and opponents of this change agreed that AT MINIMUM there should be a command line option to enable the new behavior. I was planning to commit Gerhard's rc patches to allow for specifying flags to cron during startup today (and still may get to it later) to make testing the change easier. Personally, I had a lot of sympathy with the idea of the proponents making a port of the new cron, but I could live with the idea of a command line option, defaulting to the old behavior. In either case, you need to back that commit out. Your actions were premature and indefensable. Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On 21 Jan 2001, at 14:50, Sergey Babkin wrote: > Neil Blakey-Milner wrote: > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > All, > > > > > > I've committed these changes for cron to support DST change > > > to -current (see PR bin/24494 for description of my tests). > > > Everyone is welcome to test them out. > > > Please let me know if you encounter any problems caused by them > > > (and better do that before these changes would be MFCed to -stable > > > in a few weeks). > > > > I do believe this is premature. There really should at least be an > > option for the old behaviour, and there is a good argument for making > > the new behaviour optional dependent on a variable with the old > > Let me ask a simple question: Why ? What are the benefits of > preserving the old behavior ? First, it's not "old" behaviour. It is existing behaviour. There is a difference. Because that's what was discussed and agreed to. On this list. > As far as I've watched this thread > nobody had explained it. So could you please elaborate ? Nobody explained it to your satisfaction but you still committed it? > On the other hand I clearly see the benefits of avoiding loss > or duplication of once-a-day (or even more rare) cron jobs. > If some job is scheduled once a day (or even once a week or > once a month) then it's probably a rather heavy job. So running > two of them at once is not a good thing even if they would not > mess up each other but just slow down the machine. Skipping > such a job seems to me as an almost equally bad thing. > (Yes, I'm speaking from my personal experience as sysadmin as well). People have asked for the existing behaviour because they want it. POLA has already been explained. Other reasons have been explained. I'm assuming you read what I read. > > behaviour default. _Especially_ if you intend to MFC this, since > > changing this behaviour in a minor release, without a way to have the > > old behaviour, is almost certainly wrong. > > That's why I asked for comments. You have pointed out the PR (24494). Does any documentation exist which describes how this change will affect existing systems? Details of the options for invoking the proposed new behaviour? Such things were marked as important during the discussions. It would be helpful to be able to read these things now that it has been commited. [before anyone suggestions, no, I'm not going to read the code to find out] -- Dan Langille pgpkey - finger [EMAIL PROTECTED] | http://unixathome.org/finger.php To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Quoting Sergey Babkin <[EMAIL PROTECTED]>: > All, > > I've committed these changes for cron to support DST change > to -current (see PR bin/24494 for description of my tests). > Everyone is welcome to test them out. > Please let me know if you encounter any problems caused by them > (and better do that before these changes would be MFCed to -stable > in a few weeks). > I thought the consensus was to make it a command line feature and have the old behavior by default? Myself I get a little nervous when something as important as cron is changed without intensive testing and no way to go back to the older proven method. I'd feel alot more comfortable if these changes were made a command-line option as was discussed. I for one cannot afford cron to break on any production servers as this could literally cost my comapny thousands of dollars if scheduled tasks fail because of this change. Just my 2 cents.. --Larry > -SB > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Lawrence Sica - Systems Administrator - Interactivate, Inc. [EMAIL PROTECTED] http://www.interactivate.com -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Greg Black wrote: > > Sergey Babkin wrote: > > > Neil Blakey-Milner wrote: > > > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > > All, > > > > > > > > I've committed these changes for cron to support DST change > > > > to -current (see PR bin/24494 for description of my tests). > > > > Everyone is welcome to test them out. > > > > Please let me know if you encounter any problems caused by them > > > > (and better do that before these changes would be MFCed to -stable > > > > in a few weeks). > > > > > > I do believe this is premature. There really should at least be an > > > option for the old behaviour, and there is a good argument for making > > > the new behaviour optional dependent on a variable with the old > > > > Let me ask a simple question: Why ? What are the benefits of > > preserving the old behavior ? As far as I've watched this thread > > nobody had explained it. So could you please elaborate ? > > You have not been paying attention. Please go back and /read/ > the archives on this topic which has been thrashed out in great > detail here. We did not reach agreement about the desired > behaviour because the nature of this issue is that different > people desire different behaviour. Actually, yes, I was paying not quite a close attention. But I went to the -hackers archive and re-read all the thread now. The end result is that I've seen exactly zero technical arguments on why changing the current behavior is bad. As well as zero real-life examples and only one imaginary example. That was one example of a job running at 2:30 and another job which depends on it running at 3:45. However with the current behavior if 2:30 disappears, the first job won't run anyway and thus the second job would not be able to work correctly as well. So this does not look like a quite compelling example. > What was agreed by those who contributed was clearly that the > old behaviour was to be preserved by default and that new > behaviour was to be enabled by a command-line option, which > could be set in rc.conf. You have shown no reason not to go > with the solution that was agreed, so please don't just jump in I did and if you re-read the thread you could see my e-mail on this. In short it is that a) this is what people normally expect (I agree, an arguable statement) b) practically all the commercial Unix implemenattions do support the DST changes in cron I'll comment more in answers to other e-mails. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
The problem here has nothing to do with whether changing the behavior
is good or bad, and everything to do with the fact that cron is an
absolutely critical core piece of software that runs on these machines
and there is no guarentee that you haven't introduced one or many bugs
with your rather large diff set. For better or for worse, people
already know about the daylight savings shift problem. Thousands
of people depend on cron to work, which means that when you
make a major change like this it must be tested by a wider audience
for a longer time before becoming the default. It needs to have some
real-life operational experience behind it.
So I have to say here that I agree with the calls to back it out...
it needs to backed out, and then put back in as a command line option.
Or you need to commit the command line option code ASAP and make the
old behavior the default. Judging by the diffs, it should not be
difficult for you to do this.
Also, I've already found a problem with the code:
+ /* check for the daylight saving time change
+* we support only change by +-1 hour happening at :00 minutes,
+* those living in more strange timezones are out of luck
+*/
+ if (last_time != 0 && tm->tm_isdst != lasttm.tm_isdst
+ && TargetTime > last_time /* exclude stepping back */) {
This is broken. If you want to check for a DLS change there is only
one right way to do it, and that is to compare the wall clock
differential verses the GMT differential, and to not put in any silly
restrictions like the change having to occur at the top of the hour
or be a +-1 hour increment. I would rather see the code ripped completely
out then to have a semi-broken DLS test.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Doug Barton wrote: > > Sergey Babkin wrote: > > > > Neil Blakey-Milner wrote: > > > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > > All, > > > > > > > > I've committed these changes for cron to support DST change > > > > to -current (see PR bin/24494 for description of my tests). > > > > Everyone is welcome to test them out. > > > > Please let me know if you encounter any problems caused by them > > > > (and better do that before these changes would be MFCed to -stable > > > > in a few weeks). > > > > > > I do believe this is premature. There really should at least be an > > > option for the old behaviour, and there is a good argument for making > > > the new behaviour optional dependent on a variable with the old > > > > Let me ask a simple question: Why ? What are the benefits of > > preserving the old behavior ? As far as I've watched this thread > > nobody had explained it. So could you please elaborate ? > > The fact that you do not understand, or do not accept the many salient > points that have been made in opposition to this change does not mean that > they do not exist. I'm sorry but the fact is not that I don't understand or don't accept some points, but that no technical points were ever mentioned. The discussion was very much on the emotional level, discussing the stupidity of people who schedule their cron jobs at 2am. Please do not misunderstand me: I do like conservatism and I do like the compatibility with previous releases. But sometimes these decisions mean incompatibility with the other Unix systems, so there is some sort of tradeoff. I think that I've found a reasonable solution that can let us have both sorts of compatibility at a quite good level. > > > behaviour default. _Especially_ if you intend to MFC this, since > > > changing this behaviour in a minor release, without a way to have the > > > old behaviour, is almost certainly wrong. > > > > That's why I asked for comments. > > With changes of this magnitude we do not shoot first and ask questions I'm sorry to ask this again and again but did you look at the changes ? > later. Both the proponents and opponents of this change agreed that AT > MINIMUM there should be a command line option to enable the new behavior. I I've proposed a solution which would implement the new option without significantly disturbing the old behavior. I had it discussed in -hackers and got only positive replies. > was planning to commit Gerhard's rc patches to allow for specifying flags My patches are different from Gerhard's. And Gerhard's test have shown that these patches do not quite solve the problem with DST support. > to cron during startup today (and still may get to it later) to make > testing the change easier. Personally, I had a lot of sympathy with the > idea of the proponents making a port of the new cron, but I could live with I do not have any sympathy to this idea. It brings linuxisation with scores of similar packages with subtle differences between them, making it difficult to predict the behavior of the typical installation and to get exactly the right package needed for a particular solution. Worse yet, making these packages coexist on one machine if too often quite a bit of trouble. > the idea of a command line option, defaulting to the old behavior. I agree with an idea of a command line option (again, nobody mentioned any technical argument why breaking minor compatibility aspect with the old behavior is unacceptable, but if people want this by a however irrational reason) but I think that making the changed behavior default is better. Simply because it hurts much less people. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Lawrence Sica wrote: > > Quoting Sergey Babkin <[EMAIL PROTECTED]>: > > > All, > > > > I've committed these changes for cron to support DST change > > to -current (see PR bin/24494 for description of my tests). > > Everyone is welcome to test them out. > > Please let me know if you encounter any problems caused by them > > (and better do that before these changes would be MFCed to -stable > > in a few weeks). > > > > I thought the consensus was to make it a command line feature and have the old > behavior by default? Myself I get a little nervous when something as important > as cron is changed without intensive testing and no way to go back to the older > proven method. Do you feel comfortable with the VM subsystem or SCSI subsystem changed with about the same amount of testing ? Yet these subsystems (as any core part of the kernel) are much more important than cron and much more complicated. I'd actually say that any part of the kernel used in a particular user's configuration is much more important than cron just because it can bring much bigger disaster. > I'd feel alot more comfortable if these changes were made a command-line option > as was discussed. I for one cannot afford cron to break on any production > servers as this could literally cost my comapny thousands of dollars if > scheduled tasks fail because of this change. You probably do not run -current on your production servers, do you ? The whole purpose of -current is to test the changes before they get into the production systems. And, speaking of production systems, you probably do not have any daily jobs scheduled between 1:00 and 2:59 AM ? Otherwise you'd already have problems by now. And my changes do not touch the other jobs. That's not to say that I'm against the option idea, just to show that this is not really a life-or-death issue. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Matt Dillon wrote:
> The problem here has nothing to do with whether changing the behavior
> is good or bad, and everything to do with the fact that cron is an
> absolutely critical core piece of software that runs on these machines
> and there is no guarentee that you haven't introduced one or many bugs
> with your rather large diff set. For better or for worse, people
> already know about the daylight savings shift problem. Thousands
> of people depend on cron to work, which means that when you
> make a major change like this it must be tested by a wider audience
> for a longer time before becoming the default. It needs to have some
> real-life operational experience behind it.
This can be applied to whole FreeBSD just as well. And IMHO
cron is less critical than any part of the kernel, yet changes
to the kernel don't usually bring such a strong reaction.
> So I have to say here that I agree with the calls to back it out...
> it needs to backed out, and then put back in as a command line option.
> Or you need to commit the command line option code ASAP and make the
> old behavior the default. Judging by the diffs, it should not be
> difficult for you to do this.
OK, I'll change it to a command line option.
> Also, I've already found a problem with the code:
>
> + /* check for the daylight saving time change
> +* we support only change by +-1 hour happening at :00 minutes,
> +* those living in more strange timezones are out of luck
> +*/
> + if (last_time != 0 && tm->tm_isdst != lasttm.tm_isdst
> + && TargetTime > last_time /* exclude stepping back */) {
>
> This is broken. If you want to check for a DLS change there is only
> one right way to do it, and that is to compare the wall clock
> differential verses the GMT differential, and to not put in any silly
I disagree. Checking the difference from GMT creates a danger
of misrecognition of a time zone change (for example, when
a machine was physically moved) for a DST switch. So comparing
is_dst is the only reliable way to tell if there actually was
such a switch.
> restrictions like the change having to occur at the top of the hour
> or be a +-1 hour increment. I would rather see the code ripped completely
> out then to have a semi-broken DLS test.
This limitation stems from the way the Vixie cron works. Supporting
other sorts of DST timing is either non-obvious or would require
a complete rewrite of cron to make it work like in SVR4, by
precalculating the time_t time of next run for each job in advance.
Such a rewrite would nicely fix the problem of missed minutes under
high load as well but will require significant effort to do
and lots of testing.
Anyway, the present limitation covers most of the globe nowadays except
for Kirgizia and a few islands in Australasia (judging from the
zoneinfo files). If the fix in its present form would be accepted
then I guess adding more code around it for half-an-hour and arbitrary
DST timing would be the next step.
-SB
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
:> with your rather large diff set. For better or for worse, people :> already know about the daylight savings shift problem. Thousands :> of people depend on cron to work, which means that when you :> make a major change like this it must be tested by a wider audience :> for a longer time before becoming the default. It needs to have some :> real-life operational experience behind it. : :This can be applied to whole FreeBSD just as well. And IMHO :cron is less critical than any part of the kernel, yet changes :to the kernel don't usually bring such a strong reaction. I think you have a valid argument in regards to cron vs the kernel. But keep in mind that even though you are fixing a 'bug', it's a well known 'bug' so you are in fact creating an operational change to the code rather then just a bug fix or minor performance enhancement, etc... When I do major kernel work, it's usually tested by third parties for a week or two. The last three major commits I've done had been under test for three weeks (don't let the 2-5 day MFC fool you, I have to do all my work on -stable first, then forward port to -current, then MFC back to -stable). :> So I have to say here that I agree with the calls to back it out... :> it needs to backed out, and then put back in as a command line option. :> Or you need to commit the command line option code ASAP and make the :> old behavior the default. Judging by the diffs, it should not be :> difficult for you to do this. : :OK, I'll change it to a command line option. I sure would appreciate it. Thanks! :> This is broken. If you want to check for a DLS change there is only :> one right way to do it, and that is to compare the wall clock :> differential verses the GMT differential, and to not put in any silly : :I disagree. Checking the difference from GMT creates a danger :of misrecognition of a time zone change (for example, when :a machine was physically moved) for a DST switch. So comparing :is_dst is the only reliable way to tell if there actually was :such a switch. I don't consider someone changing the machine's /etc/localtime zone to be an issue, since it rarely if ever happens. And if a machine is moved, it's likely to be powered down anyway cron is not going to nor is it supposed to 'catch up' after downtime. Additionally, cron cannot detect a timezone change without being restarted, so the point is moot anyhow. -Matt :This limitation stems from the way the Vixie cron works. Supporting :other sorts of DST timing is either non-obvious or would require :a complete rewrite of cron to make it work like in SVR4, by :precalculating the time_t time of next run for each job in advance. :Such a rewrite would nicely fix the problem of missed minutes under :high load as well but will require significant effort to do :and lots of testing. : :Anyway, the present limitation covers most of the globe nowadays except :for Kirgizia and a few islands in Australasia (judging from the :zoneinfo files). If the fix in its present form would be accepted :then I guess adding more code around it for half-an-hour and arbitrary :DST timing would be the next step. : :-SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Matt Dillon wrote: > > :> with your rather large diff set. For better or for worse, people > :> already know about the daylight savings shift problem. Thousands > :> of people depend on cron to work, which means that when you > :> make a major change like this it must be tested by a wider audience > :> for a longer time before becoming the default. It needs to have some > :> real-life operational experience behind it. > : > :This can be applied to whole FreeBSD just as well. And IMHO > :cron is less critical than any part of the kernel, yet changes > :to the kernel don't usually bring such a strong reaction. > > I think you have a valid argument in regards to cron vs the kernel. > But keep in mind that even though you are fixing a 'bug', it's a well > known 'bug' so you are in fact creating an operational change to the > code rather then just a bug fix or minor performance enhancement, etc... Yes, I understand that and I tried to make the change maximally compatible with the existing behavior. Even with all this I agree that making this change optional is a yet safer approach and by now I feel quite sorry that I did not take it from the start. > When I do major kernel work, it's usually tested by third parties for > a week or two. The last three major commits I've done had been under > test for three weeks (don't let the 2-5 day MFC fool you, I have to > do all my work on -stable first, then forward port to -current, then > MFC back to -stable). I never intended to MFC it immediately, that's why I said "in a few weeks" thus implying something like a month or so, possibly more. Also this change is not quite a major one. > :> This is broken. If you want to check for a DLS change there is only > :> one right way to do it, and that is to compare the wall clock > :> differential verses the GMT differential, and to not put in any silly > : > :I disagree. Checking the difference from GMT creates a danger > :of misrecognition of a time zone change (for example, when > :a machine was physically moved) for a DST switch. So comparing > :is_dst is the only reliable way to tell if there actually was > :such a switch. > > I don't consider someone changing the machine's /etc/localtime zone > to be an issue, since it rarely if ever happens. And if a machine is > moved, it's likely to be powered down anyway cron is not going to > nor is it supposed to 'catch up' after downtime. Additionally, cron > cannot detect a timezone change without being restarted, so the point > is moot anyhow. Agreed, this did not occur to me at once. Actually, after some thinking I see a reason why the difference from GMT may change without changing the DST state: if the country adopts different offset for its time zones, then the zoneinfo file would be updated in advance and cron would discover it on time. So comparing the difference really is the right way. And I think I see a simple way to do that and handling of arbitrary offsets as well. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
