Date: Tue, 2 Jan 2001 13:32:39 +0100 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010102133239.V253@speedy.gsinet> In-Reply-To: <3A513799.75EAB470@FreeBSD.org>; from DougB@FreeBSD.org on Mon, Jan 01, 2001 at 06:06:17PM -0800 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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" 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?20010102133239.V253>