Disable NTP configuration over DHCP

How can I disable NTP configuration over DHCP with NetworkManager? It keeps adding my router as an NTP server and this causes the time to update incorrectly.

Online search suggests setting PEERNTP=“no” in /etc/sysconfig and /etc/dhcp/dhclient.d/chrony.sh checks that variable. But looks like NetworkManager is not using sysconfig settings, according to the file comments, so I’m not sure where to set it.

See:

You should be able to use YaST to configure a Configuration Source.

NetworkManager knows nothing about chrony. It calls /usr/lib/NetworkManager/dispatcher.d/20-chrony-dhcp (which comes from chrony) which dumps received NTP servers into /run/chrony-dhcp/per-interface-file. If you do not want to use it, comment out the line

sourcedir /run/chrony-dhcp

in /etc/chrony.conf.

Well, instead of creating workarounds why do not you fix your DHCP server to not provide incorrect information?
Besides, this is just one additional time source. If it is completely wrong, chrony should ignore it as falseticker as long as you have other reliable sources. So it should not cause any issue.

I tried that already, changing the configuration source to static. Something keeps changing it to dynamic, I am not sure what, certainly without my intervention. If I could fix it back to static, that would help.

Re: changing the router, I didn’t exactly configure the NTP time source, either - that seems to have been an automatic change courtesy of my provider. I have dug through the settings there and the time on the router itself is correct, so I really am not sure why it comes out with the wrong one as an NTP server.

Chrony unfortunately is not discarding the bad source, either - every few hours my time jumps forward wildly over an hour as it picks the router to sync with instead of other sources I configured.

For now commented out the sourcedir in chrony.conf, will see if that fixes it.

After disabling DHCP configuration for Chrony, I realised that that was a red herring. I am experiencing the same sync problems even though my router is no longer a NTP source and I’m not seeing errors about connecting to it.

Now that there are fewer distractions I am looking at another possibility - it seems that the time goes wrong every time after my machine wakes up to sleep. Manual synchronization resolves it. I’m also seeing errors in journalctl of “chronyd[32319]: Can’t synchronise: no selectable sources” that correlate with times when my machine wakes up. Manual chronyd invocation syncs just fine, so it’s not a config problem, but maybe there’s something wrong with sleep on this machine.

Good debug. Can you check the log if when this error is given the network interface is not up yet?

You should also be able to enable debug mode for the chronyd service.

After a few more rounds of debugging, here’s what I arrived at

  • When my system goes to sleep and then wakes up, time goes wrong by an hour (I still don’t know why, I checked obvious settings such as CMOS clock, and it’s a new laptop)
  • To fix that, chrony needs to make a step because of the size of the error. Running chronyc -a makestep manually fixes the problem, so it’s not a sources issue.
  • However, chronyd limits the number of steps it allows, with default configuration of makestep 1.0 3, so it is only configured to allow at most 3 steps as startup and that’s not reset after sleep. So if my laptop goes to sleep multiple times (typical in my day), it hits a maximum number of steps and then doesn’t get synced.

I could set the last parameter of makestep config to -1, allowing chronyd to make steps any time, but that’s a potential security risk. I haven’t figured out how to adjust the config differently.

Instead I used advice from this post to write a service that restarts chronyd after each suspend: linux - How to restart a systemd service upon resume - Super User

This is not a perfect workaround - my time ends up being wrong for a couple of minutes after waking up from sleep at times, until chronyd catches up. But it at least self-corrects eventually.

If it is exactly an hour, the most likely reason is a time zone problem, for example the CMOS clock being on GMT and some other pieces of software that for example are on GMT+1 are not interpreting things correctly.

In the Yast Clock and Time Zone settings you can set or unset “Hardware Clock Set to UTC”, you could experiment with that. Alternatively you could temporary set the time zone to one with a different offset and see if that makes the error follow the offset.