[ 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
