once at startup. ntpd delays daemonizing until it has done the intial
time setting (or ran into the timeout) in this mode to make sure stuff started
later in rc is not subject to time jumps.
this eleminates the need to run rdate -n beforehands.
with some input from & ok ryan and bob, march music from mickey
-kill the _pid flavors of imsg_create and imsg_compose, and just add pid as
argument to those
-use imsg_create in imsg_compose instead of duplicating code
-check for datalen overflow
asking the privileged one to do it. sends back an imsg with the
resulting addresses in a bunch of struct sockaddr_storage in the data
part.
this should fix all remaining issues with dns (non-)availability at
ntpd startup, be it due to named on localhost or something else.
tested by marco@ and Chris Paul <chris.paul@sentinare.com>
looping over the addresses returned by the dns lookup, as each address
is one new peer.
however, if the lookup fails with a temporary error, we will try to lookup
later again. for that, we obviously need to insert one peer with the
hostname in addr_head... change one for() loop into a do { } while() one
to resolve the hostname every 60 seconds
fixes ntpd invocations before e. g. a dialup link is established and such.
as we want ntpd to be a "fire and forget" background daemon it should
cope with such situations.
tested by many
which, besides the head pointer for the list of course, stores the original
address as specified (i. e. as hostname instead of resolved IPs) and flags
and such.
1) base the interval calculation on the offset from the last reply, not
from the last peer update.
Allows us to send more queries again faster when the local clock
diverges too much
2) every time we form a peer update (for which we need 8 replies)
check wether we have a ready peer update for all peers that are
currently trusted, and if so, calculate the total offset and call
adjtime().
that means that adjtime is no longer called in fixed intervals
but whenever we have enough data to reliably calculate the local
clock offset.
In practice, that means we call adjtime() less often, but with
probably better data.
3) invalidate peer updates after beeing used. no point in re-using them
- this resulted in calling adjtime() multiple times with the same
offset, which doesn't make sense
tested by many
a close-to-reality stratum, a real reference time, and a leap indicator
that will indicate if the local clock isn't synchronized.
This also means that until the server feels it's synchronized, it will
tell the clients it isn't. This is normal, and correct.
ok henning@
henning