On Tue, 2012-09-11 at 11:15 +0100, mike cloaked wrote: > Recently I changed permanently to systemd - however I have noticed > that the system clock is out by some minutes just after I have booted > up and see for example: > > [mike@lapmike3 ~]$ chronyc tracking > Reference ID : 178.32.55.58 (gateway.omega.org.uk) > Stratum : 3 > Ref time (UTC) : Tue Sep 11 10:03:20 2012 > System time : 158.888610840 seconds fast of NTP time > Frequency : 5.454 ppm fast > Residual freq : -1.577 ppm > Skew : 13.260 ppm > Root delay : 0.062475 seconds > Root dispersion : 0.029119 seconds > > I would not mind a second or two out - but 158 seconds is not > acceptable - and if I reboot then the clock is immediately out by the > same amount until it eventually re-syncs after quite a long time (10s > of minutes!) > > I thought I would check the hardware clock but : > > [root@lapmike3 ~]# hwclock -r > hwclock: Cannot access the Hardware Clock via any known method. > hwclock: Use the --debug option to see the details of our search for > an access method. > > I had originally set up chrony which does eventually after some time > get the system clock back in sync - I do have dumponexit in my > /etc/chrony.conf but presume somewhere along the way in the transition > from iniscripts there is a configuration error? > > I have in my /etc/adjtime: > > 0.000000 0 0.000000 > 0 > UTC > > > I am running KDE - and until the system clock is re-synced it is quite > a bit off - this presumable also means that mail time stamps will be > wrong until the clock resets properly - > > I have looked at the chrony and systemd arch wiki entries but I can't > find a way to get this sorted out - can anyone help out? > > Thanks Just for the record. I'm not using systemd, but with Arch Linux I experience that the clock most of the times goes wrong around 1.5 sec after startup. I always run ntpdate manually after startup and I noticed that, when rebooting between different distros or simply rebooting Arch. 1.5 sec isn't a serious issue, this will happen when not using the computer too, but it's unusual that a currently synced clock goes wrong, caused by a reboot. I guess there's something fishy, that might not related to systemd. FWIW I'm using the regular kernel most of the times.
