On Sat, Jan 31, 2026 at 07:23:12PM +0100, Joachim Tingvold wrote: > My interpretation of how the -x flag worked, was that it basically ignored > the system time, and only used the virtual software clock (“NTP clock”) to > serve NTP clients with. Based on the two aforementioned discussions, that > doesn’t seem to be the case (i.e. it still relies on the system clock, even > if the server doesn’t attempt to set it).
The description of the -x option in the man page says it's still tracking the system clock and assuming it's running free, not that it's ignoring it. The ability to run independently from the system clock is possible in theory, and it's a planned feature for the next chrony version, but nothing concrete yet. > I also noticed that the 4.7 changelog mentions “Detect clock interference > from other processes”. Is this something that would solve these feedback > loops in the scenario I’m describing? No, that only detects (and logs a warning message) when two chronyd instances (or chronyd and some other NTP/PTP client) are trying to control the system clock at the same time. In your case there is only one instance touching the clock. > If not, what should the chrony-config look like on the client (hosts) and > server (ntp1+2)? Would it be possible to have equal config on all hosts > (regardless if ntp1+2 is running as LXC container on said host or not), to > ease config-deployment of chrony on the hosts? Preferably a setup where only > ntp1+2 has access to the external NTP-servers (i.e. hosts will not). My suggestion would be to run the server together with the client on the host. If that's not possible, run the server in a virtual machine, which has its own clock. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
