NTP synchronized clock alongside the system clock

Question

Does NTP daemon(ntpd) provide some sort of virtual clock that it disciplines and serves, but not touch the system clock?

Goal:

On a realtime Linux OS, have a NTP synchronized clock alongside of the system clock, so that ntp time changes won't cause issues on the system, but I can use NTP time for debuging purposes, say for sysloging.

Problem:

We are adding NTP to an already existing system, previously no worries about the system time, but now we are adding NTP to enable better debugging

Setup:

• Some of the applications on the system rely on REALTIME instead of MONOTONIC time
• I have local clock as one of the NTP servers
• By default no external NTP server set
• On boot, ntpd is set to instant sync the system clock to first available non local clock and exit, then start another instance of ntpd normally
• When no external NTP server set, system would just run with ntpd with local clock

Scenario:

• Lets say on boot time no NTP server set, and one decides to not set any NTP server
• Applications are starts running against REALTIME, no problem
• Someone decides to set an NTP server, but not to reboot the system
• Assume the newly added NTP server is good time source better than local clock, but there is an offset(could be a minute, day or even a month)
• If ntpd on the boot is set to allow huge offset stepping, it would do so without problem, but applications on the system could panic(timeout, etc)
• If ntpd on the boot is set to allow only slew, but no stepping, because of the huge offset the system could take forever to sync to the actual NTP server time

Answer 1

It seems to me that you are asking how to have Linux have a split-brain clock: one that never step-changes but can be wrong, for the kernel, and one that is right but may step-change, for everything else. Sadly, Linux doesn't support this idea, and it would take a lot of work to make it do so.

In your situation, things I think you can do to improve matters include:

1. Don't run ntpd with local clock configured as a source unless the local clock is highly-accurate (which in your case it is not, or the problem wouldn't have arisen).

2. Don't let people reconfigure and/or start ntpd under a running system unless they know what they're doing.

3. Ensure the system runs hwclock --systohc on shutdown so that the system time is written to the hardware clock. At some point, the system is likely to acquire a good time signal, and this will help preserve it. After that point, the system will have a pretty good clock from boot onwards, and post-boot acquisition of a decent ntp server will be within the corrective capacity of clock slew.