[ntp:hackers] waiting for ntpd "first fix" with orphan mode

Dave Hart davehart at gmail.com
Fri Apr 9 18:20:06 UTC 2010


Suppose you want to wait to start a database until after ntpd first
synchronizes the clock, to minimize the likelihood of the clock
stepping after the database starts.  Today, the best way to do that is
with scripts/ntp-wait from the distribution, with ntpd -gq or ntpdate
run before starting the daemon ntpd as other options.

That preferred approach breaks down with machines configured to use
orphan mode as a backup, when orphan mode is not being used.  A ntpd
configured with "tos orphan" behaves differently than without at
startup -- orphan participants immediately come up as orphan parents,
self-synchronized and showing leap=00, before any sources become
reachable.  Using ntp-wait with such a configuration will never wait
substantially.

If no external sources are available to any of the orphan
participants, they self-organize and a single ntpd becomes the orphan
parent, self-synched, while the other participants sync to it.  Even
in that case, with more than two hosts the odds are against any given
ntpd that starts up as an orphan mode parent remaining so once it has
reachability to the other orphan mode ntpds.

Perhaps the cleanest solution would be to prohibit orphan parent
operation for some brief startup delay (in seconds or poll intervals).
 That may be undesirable in an intentionally orphan-only configuration
(where orphan mode is not simply a backup mechanism), but could be
minimized or disabled in that case with an appropriate knob (tos
orphandelay?  tos orphanparentdelay?), which presumably would default
to an interval long enough that ntpd configured with orphan mode
backup would behave like one without orphan mode -- come up leap=11
unsynchronized until enough sources become usable, then transition to
leap != 11.  In other words, so that one could have more confidence
that after ntp-wait is satisifed, the clock will not shortly
thereafter be stepped.

I've been discussing this in the context of the ntp-wait script.  In
fact, my interest in resolving the question involves an alternative
meant to solve the same problem as ntp-wait with a slightly different
interface, a new ntpd option "--wait-sync 300" that would fork off a
daemon child process, and then wait for either 300 seconds or until
ntpd's first synch, and exit with failure (nonzero) if the 300 seconds
timed out.  In either case, the daemon continues on.

Your thoughts?

Dave Hart


More information about the hackers mailing list