[arch-general] Systemd and time synchronisation problems
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 -- mike c
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.
On Tue, Sep 11, 2012 at 12:28:26PM +0200, Ralf Mardorf wrote:
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.
I use Arch+systemd native & have never had time issue's but this could be that my router(pfsense-nano-4Gb-2.0.1(cf card)LinITX) provides ntp to the LAN which in turn look to 0-3.za.pool.ntp.org
Am 11.09.2012 12:15, schrieb mike cloaked:
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
Does chrony install a .list file to /usr/lib/systemd/ntp-units.d?
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!)
Your /etc/adjtime probably contains a faulty adjustment value. Delete it, hwclock --systohc, then reboot.
On Tue, Sep 11, 2012 at 11:59 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 11.09.2012 12:15, schrieb mike cloaked:
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
Does chrony install a .list file to /usr/lib/systemd/ntp-units.d?
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!)
Your /etc/adjtime probably contains a faulty adjustment value. Delete it, hwclock --systohc, then reboot.
Thanks Thomas - I will check and report back later..... and try your suggestion too. -- mike c
On Tue, Sep 11, 2012 at 11:59 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Does chrony install a .list file to /usr/lib/systemd/ntp-units.d?
[mike@lapmike3 Documents]$ cat /usr/lib/systemd/ntp-units.d/chrony.list chrony.service So yes this is the single line content of the chrony.list file
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!)
Your /etc/adjtime probably contains a faulty adjustment value. Delete it, hwclock --systohc, then reboot.
I will delete the adjtime file and reboot after running the hwclock command - and report back -- mike c
On Tue, Sep 11, 2012 at 11:59 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Your /etc/adjtime probably contains a faulty adjustment value. Delete it, hwclock --systohc, then reboot.
There is a problem running the hwclock command: [root@lapmike3 etc]# hwclock --systohc 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. Any suggestion as to work around this? -- mike c
On Tue, Sep 11, 2012 at 5:16 PM, mike cloaked <mike.cloaked@gmail.com> wrote:
On Tue, Sep 11, 2012 at 11:59 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Your /etc/adjtime probably contains a faulty adjustment value. Delete it, hwclock --systohc, then reboot.
There is a problem running the hwclock command:
[root@lapmike3 etc]# hwclock --systohc 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.
Any suggestion as to work around this?
I tried: [root@lapmike3 etc]# hwclock --debug hwclock from util-linux 2.21.2 hwclock: Open of /dev/rtc failed: Device or resource busy No usable clock interface found. hwclock: Cannot access the Hardware Clock via any known method. -- mike c
Am 11.09.2012 18:17, schrieb mike cloaked:
On Tue, Sep 11, 2012 at 5:16 PM, mike cloaked <mike.cloaked@gmail.com> wrote:
On Tue, Sep 11, 2012 at 11:59 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Your /etc/adjtime probably contains a faulty adjustment value. Delete it, hwclock --systohc, then reboot.
There is a problem running the hwclock command:
[root@lapmike3 etc]# hwclock --systohc 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.
Any suggestion as to work around this?
I tried:
[root@lapmike3 etc]# hwclock --debug hwclock from util-linux 2.21.2 hwclock: Open of /dev/rtc failed: Device or resource busy No usable clock interface found. hwclock: Cannot access the Hardware Clock via any known method.
I guess you need to stop chrony when playing with hwclock. Maybe it is enough to just delete adjtime without that command. Forgot to tell you (but it's probably too late now) to post the first line of your /etc/adjtime, this would have told us if we are on the right track.
On Tue, Sep 11, 2012 at 5:52 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 11.09.2012 18:17, schrieb mike cloaked:
I guess you need to stop chrony when playing with hwclock. Maybe it is enough to just delete adjtime without that command.
Forgot to tell you (but it's probably too late now) to post the first line of your /etc/adjtime, this would have told us if we are on the right track.
OK I will try with chrony stopped - the first line of adjtime is: 0.000000 0 0.000000 I saved the file as .bak before fiddling! -- mike c
Am 11.09.2012 19:03, schrieb mike cloaked:
On Tue, Sep 11, 2012 at 5:52 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 11.09.2012 18:17, schrieb mike cloaked:
I guess you need to stop chrony when playing with hwclock. Maybe it is enough to just delete adjtime without that command.
Forgot to tell you (but it's probably too late now) to post the first line of your /etc/adjtime, this would have told us if we are on the right track.
OK I will try with chrony stopped - the first line of adjtime is:
0.000000 0 0.000000
I saved the file as .bak before fiddling!
Okay, that means your problem is NOT a broken adjtime. This basically says that your hardware clock does not drift.
On Tue, Sep 11, 2012 at 7:15 PM, Thomas Bächler <thomas@archlinux.org> wrote:
OK I will try with chrony stopped - the first line of adjtime is:
0.000000 0 0.000000
I saved the file as .bak before fiddling!
Okay, that means your problem is NOT a broken adjtime. This basically says that your hardware clock does not drift.
The adjtime file has now changed: 0.000000 1347386033 0.000000 1347386033 UTC -- mike c
On Tue, Sep 11, 2012 at 5:52 PM, Thomas Bächler <thomas@archlinux.org> wrote:
I guess you need to stop chrony when playing with hwclock. Maybe it is enough to just delete adjtime without that command.
Forgot to tell you (but it's probably too late now) to post the first line of your /etc/adjtime, this would have told us if we are on the right track.
You were right - once I had stopped chrony with systemctl stop chrony then the hwclock command works. So I first set the system clock using date +%T -s "18:55:00" Then hwclock --systohc Then checked that both the system clock and hardware clock are saying about the same and then rebooted but left /etc/adjtime in place since rebooting seemed not to recreate this file! Now I will wait and see if "chronyc tracking" shows it has resynced in a while. However a question is where does the hardware clock get re-synchronised if it drifts out of time over a period unless it is occasionally resynchronised? -- mike c
Am 11.09.2012 20:16, schrieb mike cloaked:
However a question is where does the hardware clock get re-synchronised if it drifts out of time over a period unless it is occasionally resynchronised?
Three things: 1) On boot, the hardware clock is copied to the system clock. The adjtime file says how much time has to be added/removed to compensate for drift. 2) When chrony is not running, systemd-timedated runs periodically to adjust the hardware clock for drift (AFAIK, not sure that is the job that timedated does). 3) When chrony is running, chrony adjusts the hardware clock for drift.
On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:
2) When chrony is not running, systemd-timedated runs periodically to adjust the hardware clock for drift (AFAIK, not sure that is the job that timedated does).
No. When chrony isn't running, the hwclock isn't getting adjusted at all. The only thing systemd does on startup is warp the system clock if and only if the RTC is running in localtime. systemd-timedated's job is to provide a DBus interface to change system time and date settings: SetTime, SetTimezone, SetLocalRTC (whether RTC is in localtime), SetNTP (whether NTP is enabled) It's used by gnome-control-center, at least. The SetNTP call uses the ntp-units.d directory to select an implementation.
Am 11.09.2012 20:51, schrieb Jan Steffens:
On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:
2) When chrony is not running, systemd-timedated runs periodically to adjust the hardware clock for drift (AFAIK, not sure that is the job that timedated does).
No. When chrony isn't running, the hwclock isn't getting adjusted at all. The only thing systemd does on startup is warp the system clock if and only if the RTC is running in localtime.
Hm, sad, I had hoped it would take care of this. Seems I misunderstood the purpose of timedated.
On Tue, Sep 11, 2012 at 7:51 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:
2) When chrony is not running, systemd-timedated runs periodically to adjust the hardware clock for drift (AFAIK, not sure that is the job that timedated does).
No. When chrony isn't running, the hwclock isn't getting adjusted at all. The only thing systemd does on startup is warp the system clock if and only if the RTC is running in localtime.
systemd-timedated's job is to provide a DBus interface to change system time and date settings: SetTime, SetTimezone, SetLocalRTC (whether RTC is in localtime), SetNTP (whether NTP is enabled) It's used by gnome-control-center, at least. The SetNTP call uses the ntp-units.d directory to select an implementation.
Thank you for all the information - it seems that the key to this was that the RTC was too far out from correct time at boot - now that I manually set the RTC to correct time it comes up close to correct - and then chrony synchronises a few minutes after startup. At present tracking shows it is about 0.1 microsecs from NTP time: System time : 0.000000106 seconds fast of NTP time What I don't understand is why the hardware clock was not re-written with the correctly synchronised time previously, since chrony has been running every time I booted the system for ages? -- mike c
On Tue, Sep 11, 2012 at 8:06 PM, mike cloaked <mike.cloaked@gmail.com> wrote:
On Tue, Sep 11, 2012 at 7:51 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:
2) When chrony is not running, systemd-timedated runs periodically to adjust the hardware clock for drift (AFAIK, not sure that is the job that timedated does).
No. When chrony isn't running, the hwclock isn't getting adjusted at all. The only thing systemd does on startup is warp the system clock if and only if the RTC is running in localtime.
systemd-timedated's job is to provide a DBus interface to change system time and date settings: SetTime, SetTimezone, SetLocalRTC (whether RTC is in localtime), SetNTP (whether NTP is enabled) It's used by gnome-control-center, at least. The SetNTP call uses the ntp-units.d directory to select an implementation.
Thank you for all the information - it seems that the key to this was that the RTC was too far out from correct time at boot - now that I manually set the RTC to correct time it comes up close to correct - and then chrony synchronises a few minutes after startup. At present tracking shows it is about 0.1 microsecs from NTP time: System time : 0.000000106 seconds fast of NTP time
What I don't understand is why the hardware clock was not re-written with the correctly synchronised time previously, since chrony has been running every time I booted the system for ages?
By the way I also found another way to write the hardware clock from within chrony which does not need the chronyd daemon to be stopped (after spending this evening reading the detailed chrony docs!) that you can run chronyc in a terminal, and then enter "password mypasswordforchrony" (where the argument is the password from the chrony keys file) and then issue the "trimrtc" command once the chrony password has been accepted - this will then write the current system time to the RTC, only sensible if time has been synchronised - though the RTC is only accurate to within a second or so I believe. I guess it would be nice to have more complete information on the archwiki though there is full documentation on the chrony main web page. -- mike c
On 11/09/2012 5:22 PM, mike cloaked wrote:
On Tue, Sep 11, 2012 at 8:06 PM, mike cloaked <mike.cloaked@gmail.com> wrote:
On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:
2) When chrony is not running, systemd-timedated runs periodically to adjust the hardware clock for drift (AFAIK, not sure that is the job that timedated does). No. When chrony isn't running, the hwclock isn't getting adjusted at all. The only thing systemd does on startup is warp the system clock if and only if the RTC is running in localtime.
systemd-timedated's job is to provide a DBus interface to change system time and date settings: SetTime, SetTimezone, SetLocalRTC (whether RTC is in localtime), SetNTP (whether NTP is enabled) It's used by gnome-control-center, at least. The SetNTP call uses the ntp-units.d directory to select an implementation. Thank you for all the information - it seems that the key to this was
On Tue, Sep 11, 2012 at 7:51 PM, Jan Steffens <jan.steffens@gmail.com> wrote: that the RTC was too far out from correct time at boot - now that I manually set the RTC to correct time it comes up close to correct - and then chrony synchronises a few minutes after startup. At present tracking shows it is about 0.1 microsecs from NTP time: System time : 0.000000106 seconds fast of NTP time
What I don't understand is why the hardware clock was not re-written with the correctly synchronised time previously, since chrony has been running every time I booted the system for ages?
By the way I also found another way to write the hardware clock from within chrony which does not need the chronyd daemon to be stopped (after spending this evening reading the detailed chrony docs!) that you can run chronyc in a terminal, and then enter "password mypasswordforchrony" (where the argument is the password from the chrony keys file) and then issue the "trimrtc" command once the chrony password has been accepted - this will then write the current system time to the RTC, only sensible if time has been synchronised - though the RTC is only accurate to within a second or so I believe.
I guess it would be nice to have more complete information on the archwiki though there is full documentation on the chrony main web page.
I think the usual response is, anyone can edit the wiki - please add what you think is needed.
On Wed, Sep 12, 2012 at 1:02 PM, Stephen E. Baker <baker.stephen.e@gmail.com> wrote:
I think the usual response is, anyone can edit the wiki - please add what you think is needed.
Point taken - I will try find some time to do that! -- mike c
On Wed, Sep 12, 2012 at 2:59 PM, mike cloaked <mike.cloaked@gmail.com> wrote:
On Wed, Sep 12, 2012 at 1:02 PM, Stephen E. Baker <baker.stephen.e@gmail.com> wrote:
I think the usual response is, anyone can edit the wiki - please add what you think is needed.
Point taken - I will try find some time to do that!
I edited the wiki - hopefully this will be useful. -- mike c
participants (6)
-
Jan Steffens
-
mike cloaked
-
Ralf Mardorf
-
Stephen E. Baker
-
Thomas Bächler
-
Tom Rand