[arch-general] hwclock and openntpd
A recent announcement said: * The adjustment of the hwclock for drift is moved into a daemon that should not be used in most scenarios as it can lead to subtle bugs (especially if using dual-boot or ntp). If you know what you are doing and want to adjust the hardware clock for drift, add `"hwclock"` to your `DAEMONS` array. I use openntpd, and with hwclock disabled - DAEMONS=(!hwclock ...) - I've been getting these errors every reboot: "Superblock last mount time is in the future (by less than a day, probably due to the hardware clock being incorrectly set) - fixed" Perhaps openntpd does not set the hwclock. Therefore, should openntpd be used in conjuction with the hwclock daemon?
On Sat, 2011-06-04 at 03:06 -0400, Yclept Nemo wrote:
Perhaps openntpd does not set the hwclock. Therefore, should openntpd be used in conjuction with the hwclock daemon?
That's true, and that's also the reason why Openntpd doesn't play well with Xen where all guest VMs will take over the clock from the host VM. With the normal ntp distribution that works, but with Openntpd you need something to push the changes to the hwclock.
Jan de Groot :
On Sat, 2011-06-04 at 03:06 -0400, Yclept Nemo wrote:
Perhaps openntpd does not set the hwclock. Therefore, should openntpd be used in conjuction with the hwclock daemon?
That's true, and that's also the reason why Openntpd doesn't play well with Xen where all guest VMs will take over the clock from the host VM. With the normal ntp distribution that works, but with Openntpd you need something to push the changes to the hwclock.
I've put the following in my /etc/rc.local: (sleep 180 && ntpd -qg && hwclock --adjust && hwclock --systohc) &
On Saturday 04 June 2011 08:44:34 Jan de Groot wrote:
On Sat, 2011-06-04 at 03:06 -0400, Yclept Nemo wrote:
Perhaps openntpd does not set the hwclock. Therefore, should openntpd be used in conjuction with the hwclock daemon?
That's true, and that's also the reason why Openntpd doesn't play well with Xen where all guest VMs will take over the clock from the host VM. With the normal ntp distribution that works, but with Openntpd you need something to push the changes to the hwclock.
I've found this gnawing at me since I read it. I originally started using OpenNTPD because it was smaller, lighter, and easier to configure. However, it's disappointing that it doesn't deal better with the hardware clock. Searching around for more information, I discovered that OpenNTPD is not currently well supported for Linux, and the "portable" version that our package is based on is lagging significantly behind the mainline. I've heard a few people mention Chrony as a good alternative, and I like the sound of it. There's an AUR package, but no Wiki entry. Has anyone given Chrony a shot, or have any strong opinions about it? Paul
Paul, On Fri, Jun 10, 2011 at 1:05 PM, Paul Gideon Dann <pdgiddie@gmail.com> wrote:
I've found this gnawing at me since I read it. I originally started using OpenNTPD because it was smaller, lighter, and easier to configure. However, it's disappointing that it doesn't deal better with the hardware clock.
Searching around for more information, I discovered that OpenNTPD is not currently well supported for Linux, and the "portable" version that our package is based on is lagging significantly behind the mainline.
I've heard a few people mention Chrony as a good alternative, and I like the sound of it. There's an AUR package, but no Wiki entry. Has anyone given Chrony a shot, or have any strong opinions about it?
I don't know about Chrony, but I was in the same situation as yourself when I found out about the status of OpenNTP. I tried installing the regular ntpd, and it was actully very simple to set up, and not particularly huge, so I'm using that. PS A solution for OpenNTP is to call "hwclock --systohc" when it stops. -t
participants (5)
-
F.Gr.
-
Jan de Groot
-
Paul Gideon Dann
-
Tom Gundersen
-
Yclept Nemo