[9fans] cron and timesync

[andrey mirtchovski]

There is a race between the cron daemon and timesync that hit me pretty
badly for the past two days.

The problem comes from the fact that timesync does not set the system's
real-time clock. On one of the machines here the RTC was behind a few hours,
so when it went through /rc/bin/cpurc the following happened:

... # time set by rtc (1am)
aux/timesync -n ntp.ucalgary.ca # time still 1am
...
auth/cron # time still 1am
...
... # after a few (micro)seconds the time
# is reset to the current time (say
# 10am) as reported by the ntp server

cron gets initialized with 'last' time being 1am and the next time it wakes
up it tries to run all cron jobs in between 1am and 10am, effectively
crashing my machine.

i have modified timesync.c and added a -w option to write to /dev/rtc, but
then decided it'd be simple to run 'date -n > /dev/rtc' once daily from
cron.

in the example below cron started some 2000 jobs:

% date; date -n
Thu Jul 17 12:36:55 MDT 2003
1058467015
% echo 1057467015 > /dev/rtc
% aux/timesync -r
% date
Sat Jul 5 22:50:24 MDT 2003
% auth/cron
% ps | grep cron
bootes 648 0:00 0:00 172K Sleep cron
% aux/timesync -n ntp.cpsc.ucalgary.ca
% date
Thu Jul 17 12:38:11 MDT 2003
%
% date -n > /dev/rtc # otherwise it'll happen again on reboot
% # wait a minute or so ...

andrey

[r...@vitanuova.com]

> ... # time set by rtc (1am)
> aux/timesync -n ntp.ucalgary.ca # time still 1am
> ...
> auth/cron # time still 1am

i came across this problem in for another reason, and my assessment
was not that /dev/rtc wasn't being set (after all, everything reads
/dev/time, not /dev/rtc), but that aux/timesync returns immediately
without having synced the time.

it wouldn't be hard to do: it just requires a little synchronisation
between the forked process and its parent. i'm afraid i didn't get
around to it (story of my life!).

[Dan Cross]

> i have modified timesync.c and added a -w option to write to /dev/rtc, but
> then decided it'd be simple to run 'date -n > /dev/rtc' once daily from
> cron.

It is easier, except that the RTC may be up to a second off. If you
don't care about one second, it's not a big deal. If you do, writing a
little C program that updates the RTC when it hits the leading edge of
a second isn't hard.

- Dan C.

[Geoff Collyer]

I invoke this function early in cpurc:

fn timesync {
aux/timesync -nl -d /sys/log/timesync.d -a 100000 $*
# the alpha port currently has no #r
if (test -e '#r/rtc') @ {
sleep 600 # let ntp do its thing
awk '{print $1}' /dev/time >'#r/rtc' # fix the hardware clock
} &
}

I don't start cron until I've started venti and fossil, and that takes
long enough that timesync should have reset /dev/time by then.

[David Presotto]

I changed timesync to not background until it's tried at least once
to sync up. That means you'll be within 10 seconds of real time
when it returns if it managed to find a time source; timesync just
sets the time if off by more than 10 seconds and tries to sneak
up on the correct time otherwise.

I could wait for time to get within the accuracy limit, but that
could take a while. 10 seconds should be good enough for the
reported problem.