Page MenuHomeFreeBSD

rc.d/ntpd: Restart ntpd when resuming from sleep.
ClosedPublic

Authored by jhb on Jun 14 2022, 3:10 PM.

Details

Summary

ntpd does not always gracefully handle clock steps during resume.
This is probably most useful in conjunction with
ntpd_sync_on_start=YES which will work around any clock skew while
suspended.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jhb requested review of this revision.Jun 14 2022, 3:10 PM

Maybe check if sync_on_start is set and only restart ntpd then ?
I fear some bug reports that ntpd restart on resume for no reason ...

In D35479#804612, @manu wrote:

Maybe check if sync_on_start is set and only restart ntpd then ?
I fear some bug reports that ntpd restart on resume for no reason ...

I thought about that, but I don't really expect harm in restarting in general? ntpd is designed to restart across reboots and preserve state about long-term clock drift, etc.

In D35479#804709, @jhb wrote:
In D35479#804612, @manu wrote:

Maybe check if sync_on_start is set and only restart ntpd then ?
I fear some bug reports that ntpd restart on resume for no reason ...

I thought about that, but I don't really expect harm in restarting in general? ntpd is designed to restart across reboots and preserve state about long-term clock drift, etc.

True, this is fine for me then.

This revision is now accepted and ready to land.Jun 14 2022, 5:39 PM
In D35479#804709, @jhb wrote:
In D35479#804612, @manu wrote:

Maybe check if sync_on_start is set and only restart ntpd then ?
I fear some bug reports that ntpd restart on resume for no reason ...

I thought about that, but I don't really expect harm in restarting in general? ntpd is designed to restart across reboots and preserve state about long-term clock drift, etc.

It is designed for that, yes. If we shut it down properly, saving the drift (aka frequency error) file, it might not be terrible. In the absence of data, it's unclear if resuming from a suspend would have a frequency error more like the drift file, or if we'd be better off starting from scratch. The drift file works well in continuous situations (which includes reboot since the system generally has the same systemic errors and reboot doesn't change the environmental conditions that affect time all that much, and experience has shown that this remains true enough across a shutdown and power up though it works less well since it copes with the systemic errors in the timing hardware, but not the environmental ones). For a laptop, the environmental stuff will vary quite a bit more than a server in a server room, or even a desktop in an unregulated office. Since we have no specific data, we likely should just treat it like we would a reboot, and accept that we may have a slightly higher frequency error as a result that will be steered out. While we might have worse frequency performance doing this, I think the benefits of better phase stepping would outweigh this theoretical benefit.

Having said that, there's not really a need to check in the general case....