Wonky NTP startup and the incremental-configuration problem
hmurray at megapathdsl.net
Mon Jun 27 05:08:19 UTC 2016
An alternative option would be to implement rereading ntp.conf.
For each line in ntp.conf, there are 3 possibilities. It's new or the value
has changed, nothing has changed, or the item was dropped. The latter is the
The idea is to save a parsed copy of the old ntp.conf. As the new file is read in, kick out the old items (if any) as they get replaced. (Actually, move them to what will be the new saved info.) Anything left on the old saved-list needs to be set back to the default.
That works for simple things like setting a parameter. It gets more complicated for things like server/pool/refclock.
It feels like something that's reasonably clean with the appropriate table.
We would need a way to test things. I wonder if we could do that from a script driving the debugger?
These are my opinions. I hate spam.
More information about the devel