The Tuesday 2005-02-15 at 21:50 +0100, I wrote: ...
The sequence of events is this:
* Boot. Run /etc/init.d/boot.clock Check for existence of '/etc/adjtime', create if not. Get time and date from the CMOS clock, adjusting for drift, with command: /sbin/hwclock --adjust $HWCLOCK Continue with boot, enter runlevel 2, 3 or 5 If service xntpd is enabled (1), run /etc/init.d/boot.clock/xntpd (after $remote_fs $syslog $named are running) Using the network, get correct time and set the clock, right now. Start the xntpd daemon to keep the clock in time. Continue boot.
* System running. One of two things may happen: If enabled, the xntpd daemon keeps the system clock on its toes. If not, then ntpdate or 'rcxntpd ntptimeset' can be called as soon as network goes up to update the time. This is done from '/etc/ppp/poll.tcpip' without user intervention. (2)
* System stopping. ... The xntpd daemon stops. ... Copy system time to cmos clock, calculate drift (3).
Notes:
(1) Running xntp only makes sense if you have a permanent network connection.
(2) The pppd daemon calls '/etc/ppp/ip-up' if present. This script, wrote by SuSE, calls 'poll.tcpip' and 'ip-up.local', if present. This behaviour can be disabled by setting 'RUN_POLL_TCPIP = no' - theoretically in '/etc/sysconfig/network/ifcfg-ppp0' (because it appears to break '/sbin/conf.d/SuSEconfig.hostname')
(3) If at this point the time is incorrect, the CMOS clock will be set incorrectly; and worse, the '/etc/adjtime' file will store the wrong drift. Perhaps it would make sense to disable it.
Further adjustments for those without a permanent internet connection: tuning the hwclock (cmos). When the connection goes up, /etc/ppp/poll.tcpip does this: while true ; do set -- $(/sbin/runlevel) test -e /etc/init.d/rc${2}.d/S*xntpd && break test -x /usr/sbin/ntpdate || break checkproc /usr/sbin/xntpd &> /dev/null && break /usr/sbin/rcxntpd ntptimeset break done Later, when the system stops, the hardware clock is updated in "/etc/init.d/boot.clock": stop) if [ "$HOSTTYPE" != "s390" -a "$HOSTTYPE" != "s390x" ] ; then echo -n "Set Hardware Clock to the current System Time" /sbin/hwclock --systohc $HWCLOCK rc_status -v -r fi ;; I mentioned previously that, if xntpd was not running, the system clock may be off at that instant, and thus, the hardware clock will be set incorrectly, and also '/etc/adjtime' will contain the wrong adjustment. Therefore, I commented out the '/sbin/hwclock' line above. Instead, I use the following script in '/etc/ppp/ip-up.local' (I have 'poll.tcpip' disabled): . /etc/sysconfig/clock /usr/sbin/rcxntpd ntptimeset &> $FLAG_BOOTED_PPP /sbin/hwclock --systohc $HWCLOCK However, I noticed that the adjustment did not became better over the days: Feb 14 19:56:47 nimrodel ntpdate[7151]: adjust time server x.y.z.w offset -0.208596 sec Feb 15 11:52:53 nimrodel ntpdate[7200]: step time server x.y.z.w offset -0.592240 sec Feb 15 19:46:38 nimrodel ntpdate[7218]: step time server x.y.z.w offset -0.523598 sec Feb 16 14:35:21 nimrodel ntpdate[7783]: step time server x.y.z.w offset -0.954435 sec Feb 17 11:18:22 nimrodel ntpdate[7247]: step time server x.y.z.w offset -0.725295 sec Feb 18 13:08:47 nimrodel ntpdate[7238]: step time server x.y.z.w offset -0.657556 sec Feb 18 20:55:15 nimrodel ntpdate[8900]: adjust time server x.y.z.w offset 0.197868 sec Feb 19 21:45:32 nimrodel ntpdate[7189]: adjust time server x.y.z.w offset 0.311187 sec Feb 20 11:40:32 nimrodel ntpdate[9744]: adjust time server x.y.z.w offset -0.121958 sec Feb 20 14:24:58 nimrodel ntpdate[7839]: step time server x.y.z.w offset -0.704849 sec Feb 20 20:38:18 nimrodel ntpdate[7761]: step time server x.y.z.w offset -0.732385 sec Feb 21 13:27:32 nimrodel ntpdate[7804]: adjust time server x.y.z.w offset -0.328831 sec Feb 22 11:49:48 nimrodel ntpdate[7149]: adjust time server x.y.z.w offset -0.467263 sec Then, it occurred to me that when ntpdate "adjusts" instead of "steps", the clock is not immediately correct, because the system clock is slowly adjusted: it can be adjusted at most .5 seconds over a period of 10 minutes - see how it slowly gets in sync: Feb 22 11:50:38 nimrodel ntpdate[7252]: adjust time server x.y.z.w offset -0.426417 sec Feb 22 11:51:53 nimrodel ntpdate[7556]: adjust time server x.y.z.w offset -0.350410 sec Feb 22 11:56:06 nimrodel ntpdate[7599]: adjust time server x.y.z.w offset -0.096976 sec Feb 22 11:57:22 nimrodel ntpdate[7619]: adjust time server x.y.z.w offset -0.025964 sec Feb 22 11:57:49 nimrodel ntpdate[7639]: adjust time server x.y.z.w offset 0.007841 sec Feb 22 11:59:55 nimrodel ntpdate[7740]: adjust time server x.y.z.w offset 0.002169 sec Thus, the call to /sbin/hwclock should be delayed 10 minutes. My setup is, at this moment, is like this: * During boot, I remove a flag file. * On the first internet connection, I sync time (and only once), and before fetching mail (ie, before the modem becomes "busy"). ** /etc/init.d/boot.local: FLAG_BOOTED_PPP=/etc/ppp/SYSTEM_WAS_SYNCRONIZED if test -f $FLAG_BOOTED_PPP ; then rm $FLAG_BOOTED_PPP fi ** /etc/ppp/ip-up.local SERVICE_NAME=ip-up.local FLAG_BOOTED_PPP=/etc/ppp/SYSTEM_WAS_SYNCRONIZED if ! test -f $FLAG_BOOTED_PPP ; then /bin/logger -t $SERVICE_NAME -p user.info " --> Synchronizing time" /usr/bin/play $VOLUMEN /usr/share/sounds/wav/clock.wav &> /dev/null & /usr/sbin/rcxntpd ntptimeset &> $FLAG_BOOTED_PPP # Time can be "adjusted" or "stepped" by xntpd. In the first case, the # system time is not correct till some time later; assuming that it # only "adjusts" for at most .5S, the clock will be correct before 10 # minutes. Therefore, I delay setting the hardware clock: /usr/bin/at -f /etc/ppp/hwclock now + 10 minutes /bin/logger -t $SERVICE_NAME -p user.info -f $FLAG_BOOTED_PPP fi ** /etc/ppp/hwclock #!/bin/bash # Serves to be called from "at", called from ip-up.local.doit . /etc/sysconfig/clock /sbin/hwclock --systohc $HWCLOCK I'll see what happens over several days. Of course, there is room for further improvement: I could sync time not only once after booting, but say, once ever four hours. Also, the system clock could be disciplined, as some poster mentioned here time ago. P.S: Remember, all this is for people not having a permanent network connection, and not running xntpd. -- Cheers, Carlos Robinson