Posted: Fri Mar 16, 2012 10:33 pm Post subject: You normally don't need to do this if you run a ntp daemon.

/etc/conf.d/hwclock says that you don't need to set clock_systohc="YES" if you are running an ntp daemon. I'm not sure that this comment is accurate. All of my systems run ntp daemons. When I set clock_systohc="no" my systems say that filesystems were mounted in the future on boot because the hardware clock is wrong. When my systems are unable to contact an ntp server at boot time, their clocks are off.

Perhaps ntpd used to set the hardware clock, but no longer does? This comment in /etc/conf.d/hwclock does not seem to be accurate.

Is the hardware clock ever going to be set if clock_systohc="NO"? It doesn't matter if the drift is significant or not. If there is any drift at all the hardware clock will become wrong given enough time. It seems to me that running ntpd is completely unrelated to syncing the hardware clock.

My experience is that the hardware clock is not set under those circumstances. Also logic tells me the same thing.

Quote:

It seems to me that running ntpd is completely unrelated to syncing the hardware clock

This is my experience too, although with the caveat that I use netdate rather than ntpd.

To keep things in sync I do one of the following

(1) Set clock_systohc="YES" in /etc/conf.d/hwclock

or

(2) run netdate in my own local script which is

Code:

netdate utcnist.colorado.edu ;hwclock --systohc

You are right; something has to set the hardware clock
I think that the coments in /etc/conf.d/hwclock are misleading, but if you ignore them everything does work as one would expect from the defns of
clock_systohc and clock_hctosys.

I think the default is "don't touch the hardware" due to historically buggy RTC chips and not wanting to break those computers. I agree though, it's not a very useful default._________________Quantity is not quality.
overlay | runit-scripts

Generally I don't want errors in the software (system) clock to be automatically passed
to the hardware clock at shutdown, since I don't run an NTP daemon. If it's left alone
a hardware clock has predictable drift, which can be allowed for in setting the system
clock on startup.

(From time to time I set the hardware clock by hand, immediately after setting the
system clock with ntpd -q).