Ted Beatie wrote:
If ntpd finds an offset of more than 1000 seconds, it will
terminate itself unless "-g" is present on the ntpd command
line. In that case, it will make one such adjustment and will
terminate itself if a second such adjustment is required.
I'm confused then;
server-04:~# ps aux|grep ntpd
root 389 0.0 0.1 2328 2320 ? SL Jun13 0:05 /usr/sbin/ntpd -g
This instance of ntpd has been running since Jun13. Shouldn't it have
terminated by now? (not that I want it to terminate.. what I want is
for it to say, "ok upstream server, I think you're on crack, but I'm
going to believe you anyway.")
The offsets shown by ntpq are in milliseconds. Does that answer the
question? Otherwise, I don't really know what the status of "server-04"
is, so I can't evaluate whether anything is amiss or not.
Also make sure that each ntpd instance has at least 4
reliable, consistent, and _working_ lower-stratum servers
configured before you even start ntpd for the first time.
What if we can't guarantee that? The docs certainly seem to say that
the more the better, but that only one is actually required. Some of
our deployments have public internet access, in which case, we can
populate the ntp.conf file on the gateway machines with as many servers
as we'd like. But a fair number of our deployments don't have outbound
internet access, and have only one internal NTP server, if even that.
And yet, we still want at a minimum, for all of our machines to be in sync.
If you can't guarantee that, you'll have to settle for poor and unreliable
timekeeping, not to put too fine a point on it. Obviously, you have to
have at least one working server. What if you only have one configured
and it is down? What if it is malfunctioning and reporting the wrong
time? With multiple servers, NTP can cull out the bad boys. 4 is the
minimum you need to provide a valid statistical sample and n+1
redundancy.
In any case, you should make no judgments about whether
ntpd is working properly or not until it has been running
for several hours, sometimes 2 days or more on a previously
unitialized system.
This is also a problem. Given our situation, the gateways and servers
all get powered on at roughly the same time. Ideally, what we would
like is for the servers to sync up to the gateways, no matter what they
think of the accuracy of them, just so that they are all in sync. Then,
if the gateways themselves get more reliable information, from internal
or external upstream servers, that the whole system asjusts accordingly.
Nothing will synch to the gateways until the gateways are themselves
synched. You have to start with them. Make sure they step to the
right time on boot (with ntpdate -b ....], synch to their servers
as quickly as possible (add iburst to the end of each server line),
and hope that the gateways' clients can be happy with a clock
skew for a while after they boot. If there is a possibility that
the gateways will not be able to reach any servers at the time they
boot, you would have to configure the local undisciplined clock at
a high stratum as a server on at least one of those to allow the
clients to be able to synchronize to something, or you will just
have to live with letting all of the systems float with their own
time until the real servers become accessible.
There is some other discussion in here that suggests that you may
be using Windows systems running W32time as time servers. That won't
work. Don't even try. If that's what you've got, sort that out first.
-Tom
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
