3

I have the option CONFIG_RTC_SYSTOHC enabled in my kernel:

Device Drivers  --->
    [*] Real Time Clock  --->
        [*]   Set the RTC time based on NTP synchronization

The help says:

CONFIG_RTC_SYSTOHC:

If you say yes here, the system time (wall clock) will be stored in the RTC
specified by RTC_HCTOSYS_DEVICE approximately every 11 minutes if userspace
reports synchronized NTP status.

However, my hardware clock is not being synced. I have RTC_HCTOSYS_DEVICE set correctly:

CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

The above cited help says, the sync works if "if userspace reports synchronized NTP status". What does that mean? I am using ntpdate to sync my time regularly (every 4 hours) using cron.

How can I tell my system that I am ntp synchronized and that I want my hardware clock to be synced ?

|improve this question
3

Since you have already cron'ed the ntp time updates via ntpupdate why not also just add the hardware sync to that cron (or make a second one)? I have used this same method on some of my company's really really old RHEL 3 & 4 boxes to keep their clocks in sync.

0 */4 * * * ntpdate mytimeserver.com && ( hwclock --adjust; hwclock -w )

This cron will update the hardware clock to the system's time if ntpdate was successful. More information about the hwclock commands.

Added note:

mytimeserver.com for me is an internal vip with a few time servers in it for redundancy. If you don't have access to the same thing, you should change the ntp server to be different ntp pools so that every system isn't reliant on one and only one ntp server.

Server 1:

0 */4 * * * ntpdate 0.pool.ntp.org  && ( hwclock --adjust; hwclock -w )

Server 2:

0 */4 * * * ntpdate 1.pool.ntp.org  && ( hwclock --adjust; hwclock -w )
|improve this answer
  • thanks, that would work. But why is there the option in the kernel then, when you can do the same with a simple cronjob? Is there any advantage doing it with CONFIG_RTC_SYSTOHC ? – Michael Boies Feb 24 '15 at 19:13
  • @MichaelBoies I honestly don't know. It might be to make things 'easier' by allowing the option in the kernel level rather than managing it via cron, but I prefer cron for these kind of jobs, since I can easily log in to a server and view my cronlist (crontab -l) and see everything running, rather than spending the time to figure out why CONFIG_RTC_SYSTOHC doesn't work. – devnull Feb 24 '15 at 21:26
  • This is the correct solution. Don't use SYSTOHC if you are using ntpdate. The SYSTOHC/HCTOSYS mess is there to try to synchronise the RTC on a second boundary but this has never really worked properly because of the 500ms delay introduced for the PC RTC. See that discussion: lists.infradead.org/pipermail/linux-arm-kernel/2017-September/… – Alexandre Belloni Oct 27 '17 at 8:46
2

Running ntpdate from a cronjob will adjust the system time every time it runs, but this doesn't mean that your system is "NTP synchronized" (the clock can drift between the periodic syncs) and the kernel will not automatically sync the RTC.

Is there any particular reason you're running ntpdate from a cronjob rather than running ntpd? ntpd will keep much more accurate time, has more error-checking (so that an erroneous time server won't cause chaos for you), and disciplines the system's clock frequency to compensate for oscillator drift.

Additionally, it will report the "NTP syncronized status" to the kernel, which will then periodically set the hwclock.

From the ntpdate man page:

ntpdate can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time. This is useful in some cases to set the clock initially before starting the NTP daemon ntpd. It is also possible to run ntpdate from a cron script. However, is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited.

In general, it's better to use ntpd to keep your clock in sync unless you have a particular reason not to (e.g. a remote or isolated system where transferring data is very expensive).

|improve this answer
1

ntpdate doesn't clear STA_UNSYNC flag when it adjust system time. Thus kernel thinks that system time invalid and don't update RTC. It doesn't clear STA_UNSYNC because it use adjtime() to set system time instead of adjtimex().

In order to use CONFIG_RTC_SYSTOHC feature, you have to use tool what clears STA_UNSYNC flag, i.e. ntpd.

May be the issue should be reported to ntpdate developers.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.