Date: Sun, 7 Jan 2001 17:08:40 +0100 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-hackers@FreeBSD.org Cc: Doug Barton <DougB@gorean.org> Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010107170840.G253@speedy.gsinet> In-Reply-To: <20010102133239.V253@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Tue, Jan 02, 2001 at 01:32:39PM %2B0100 References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet>
next in thread | previous in thread | raw e-mail | index | archive | help
[ citing from Doug's message in the "OT: silence ..." subthread
to keep the technical discussion in the "how to test" subthread ]
On Tue, Jan 05, 2001 at 14:45 -0800, Doug Barton wrote:
>
> You stated in another post that you wished I had elaborated
> more. I was in a hurry when I wrote that post, so here are more
> details. While this is, as you say, "an eternal problem," it is
> not a problem entirely without remedy. The proper solution is
> simply to avoid scheduling mission/time critical events during
> the DST change period for your time zone. Without improperly
> revealing sources, I can say that I did a lot of research on
> this topic in a past life, and it is by no means clear that
> your proposed solution is the best one.
Well, the "don't schedule jobs for these times" is the problem
here: The fact that all FreeBSD users are potentially struck is
caused by the jobs execution time to be delivered with the
distribution. It's not a wanton act of some administrators to
schedule their jobs this way, but it's the status after
installing FreeBSD on a machine. Plus the fact that this machine
(by chance? but it's an increasing chance as has been stated in
an other message) is located in a region with DST changes.
Of course everybody knows there's a need to check, correct and
add quite a few things an installer is not capable to handle in
all the variety of arrangements humans come up with. And some
things aren't just the job of an installer. But how many of us
are aware of checking scheduled jobs' timings and how they could
collide in the near future (in the next year after setting up the
machine) or in the general future (when you somehow "forgot" the
machine because it just works flawlessly)? What if some
government later decides to introduce DST, too? What if these
jumps are shifted to a different week? It may be rare, but it
definitely would be tedious to keep up with these details for
machines you don't need to spend too much attention for or
regions you don't live in or care too much about. Even if the
user gets it right after the installation, there's a chance that
a commit to the timezone database will cause new trouble.
Strictly speaking you wouldn't even have to check crontab(5)
against the Real World (TM), but against the zdump(8) output.
Since the /etc/localtime description is what makes the clock jump
on the computer.
It boils down to: Do we want to keep putting tedious (and mostly
nonintuitive) work on FreeBSD users? Or do we want to free some
of their resources for more important tasks (maybe even the
actual tasks they install FreeBSD as a tool / vehicle for:)?
Imagine you would be yourself in the situation to handle a few
wide spread machines in different regions of the earth. Add your
experience with the nontrivial nature of DST handling and job
scheduling. Actually I would expect you to welcome when cron(8)
would be intelligent enough to save you from thinking about these
low level details. :) There already are much more (and more
important) things to care about when setting up a server ...
It's not that I want to talk you into something you don't want.
Currently I'm about to setup a spare machine for the tests (the
one I had last year is not available for toying any longer).
Since this machine lacks any kind of connectivity, I have to
fallback to 4.1-R from the Lehmann's CD set. With the CVS repo
from CD#2 I checked there's no diff between the -STABLE and
-CURRENT usr.sbin/cron tree. And I would expect mdocification to
be the only change made to cron since then. While I write this
"make world" is running and will take some seven hours. I
scheduled DST changes for Jan 8th, 9th, 10th, and 11th (to, from,
to, and from DST, respectively). If things go well, I can
send-pr the code and the testing environment next weekend (Sergey
Babkin was so kind to help me with setting it up).
> Consider the following. We are in the spring and DST is
> "springing forward" at 2am. We have a job scheduled at 2:15
> that takes one hour to run. There is another job scheduled at
> 3:20 that ABSOLUTELY POSITIVELY cannot run unless the first job
> finishes. Aside from the fact that this is bad design, how
> should cron handle this situation? You can (and probably
> should) respond that this is not cron's responsibility, and
> come up with all kinds of ways to ameliorate this situation. My
> response will then be that if you can "fix" this situation
> without "fixing" cron, then cron doesn't really need to be
> "fixed."
Well, the only valid "fix" for this situation would be to fix the
jobs' arrangement / interaction / synchronisation. This can be
done with coordinating interdependent jobs by means of locks or
making them one job with several stages or something".
Do you agree that the proposed cron extension merely reveals the
brokenness of the above asumption that a job has a given length
and unforced synchronisation always will work? Talking about a
UNIX environment there's no way of reliably operating based on
computation time, anyway. You may have an expectation, you may
even have an estimate, but you never have determined execution
lengths. But all of this is basically what you state yourself.
In the current situation (and in future, too, of course) cron
wouldn't even force these jobs to really start at the given time.
They're just dispatched, queued, or whatever term is the best.
Availability of resources is what influences scheduling more than
users' wishes. :) This means the above example is defective
without touching cron, already.
But without the proposed fix to cron the 2:15 job wouldn't even
get run and and thus possibly damage(?) the prerequisites the
3:20 job wants to run under. No matter how defective the above
example may be, it's hard to decide which "brokenness" is worse
in the above scenario: not to run needed jobs or to have them
run interleaved while they should be sequenced. But in any
normal scenario it surely is a bug when scheduled jobs aren't run
at all or multiple times.
Out of curiousity: can cron(8) already handle situations where
it is woken up after some minutes have passed since the last
"tick"? Or is this absolutely out of imagination that a
machine's workload is this bad?
> With very little imagination you could easily come up with
> other situations where your proposed changes will cause more
> harm than good.
You might be shocked, but sorry I *cannot* come up with _any_
situation that's to get broken by a cron which keeps up with its
job list. :)
Isn't it exactly the user's expectation that cronjobs are run
(for nitpicking: queued immediately and waited for resources to
become available for running them) as soon as the scheduled time
is reached _or_ _passed_? And making sure that cron "gets bored"
about "hey, I know this job. I just ran it. Just because
somebody turned back the clock doesn't mean I *want* to do it all
again" would IMO better match users' expectations, too. To make
things clear: This doesn't touch the "every five minutes" and
"hourly" jobs, only those scheduled for one given daytime and at
least daily.
Anyway. The reminder I sent seems to prove there *is* interest
among FreeBSD users. And not everyone is keen on having the
discussion in late March once more, and in October again. :) So
I will do my part and contribute what I can. :> May others with
more knowledge jump in and join or prove me wrong ... For the
record I will cite the manpage again, which is meant to clarify
the motivation for the change. It seems my presentation of what
I try to achieve was wrong. And I expect the PR with code to
change this.
-----------------------------------------------------------------
--- /usr/src/usr.sbin/cron/cron/cron.8 1999/08/28 01:15:49 1.7
+++ /usr/src/usr.sbin/cron/cron/cron.8 2000/12/03 12:44:53
@@ -68,6 +68,25 @@
.Xr crontab 1
command updates the modtime of the spool directory whenever it changes a
crontab.
+.Pp
+Special considerations exist when the clock is changed by less than 3
+hours; for example, at the beginning and end of Daylight Saving
+Time.
+If the time has moved forward, those jobs which would have
+run in the time that was skipped will be run soon after the change.
+Conversely, if the time has moved backward by less than 3 hours,
+those jobs that fall into the repeated time will not be run.
+.Pp
+Only jobs that run at a particular time (not specified as @hourly, nor with
+.Ql *
+in the hour or minute specifier)
+are
+affected.
+Jobs which are specified with wildcards are run based on the
+new time immediately.
+.Pp
+Clock changes of more than 3 hours are considered to be corrections to
+the clock, and the new time is used immediately.
.Sh SEE ALSO
.Xr crontab 1 ,
.Xr crontab 5
-----------------------------------------------------------------
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010107170840.G253>