Wonky NTP startup and the incremental-configuration problem

Achim Gratz Stromeko at nexgo.de
Fri Jun 10 18:05:30 UTC 2016

Eric S. Raymond writes:
> ntpq has dangerous operations that tweak parameters of the time-sync
> algorithms on the fly - operations that can be triggered remotely. Or so I
> gather from things Hal Murray has said; my outside view is weak here,
> I've never explored those operations.

In the standard configuration you can only tweak those locally (via
loopback) and then you still need to set up a password.

> It would be better for code verifiability and security if the
> only source of configuration information for the daemon were the
> ntp.conf file.  (We can't quite get there due to the requirement
> to store drift state, but closer would be better.)

If you do that, you need some way to change the configuration without a
wholesale restart of ntpd or at least determining and tweaking fudge
factors gets a lot harder than it already is.

Come to think of it, ntpd should gracefully react on a few signals
rather than just exit: HUP for close/reopen of any files (logrotate…),
USR1 for re-read of config and maybe USR2 for re-read of an alternate
config file (so you can go back pre ante by just sending USR1 if you
messed up).

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:

More information about the devel mailing list