13.0/13.1 ntpd differences
 

Hello :)

I'd like to get the 13.0 "synchronized to <time server>, stratum <stratum>" messages back on 13.1.

On 13.0, running ntpd 4.2.4p8, reassuring messages appeared in /var/log/messages like "synchronized to 211.233.84.186, stratum 2".

On 13.1, running ntpd 4.2.6p1, there are no messages in /var/log/messages to confirm that time is being synchronised.

rc.ntpd on both starts ntpd with the same options. /etc/ntp.conf is identical on both, a "get it working and then make it secure" version:
According to Linux Home Networking, synchronisation can be checked using ntpq -p. This shows synchronisation is working.

I would prefer to see that confirmation in /var/log/messages without having to run a command manually to check it. Can anyone advise how to get the old messages back?

Best

Charles

well those messages shouldn't be as reassuring as you take them to be. Each time you get that message it means that it's gained trust in that ntp service, and so if it's the same address, it's also lost it's trust beforehand. You shouldn't see lots of them in the slightest. The way I recommend seeing ntp status is to run "ntpq -pn" and it'll print out the table of what it's doing nice and clearly. Things filling up logs files telling you not to worry is a crappy state of affairs. The best log is an empty log.

Your ntp.conf is pretty poor though, and needs changing. you have two servers listed there, that will only be resolved once on startup. what if one of them is wrong? How do you know which one of the two is wrong, it's just A vs B with no other informatin to do on. You want at least 3, preferably many more so you can really have confidence in your time sources.

Well, it may not be in /var/log/messages but the way I do it is create a log in /tmp (that gets wiped out every time NTPD is started -- so the log doesn't get huge).

In /etc/rc.d/rc.ntpd you can make the "Start ntpd" section look like
and you'll get a log.

Hope this helps some.

Thanks Chris :)

Useful to learn those messages indicate gaining a trust. Regards "so if it's the same address, it's also lost it's trust beforehand" it probably is a new address for reasons which relate to having only two server entries in the config file. Those entries are not to single servers but to server pools. As it says on ntp.org's NTP pool project page, "The pool.ntp.org project is a big virtual cluster of timeservers". As it says on their How do I use pool.ntp.org? page for best results only a single country pool should be used. In the case of India, the country pool is not adequate and it is necessary to extend to the continent.

With that type of pool system, messages indicating that new trusts have been created are good -- they show that the pool is functioning as a pool and the local system is cycling around the pool members as intended.

Regards "The best log is an empty log" there are pros and cons. Personally I prefer assurance/success messages having been bitten too many times by daemons etc. that were both not functional and not generating error messages.

Thanks tronayne :) that's a neat idea but according to my understanding of the man page it would be the same messages as currently go to "the system log" -- presumably /var/log/messages -- so the gain would be in log management rather than in log content. Does your ntpd generate a lot of output?

Yes thanks, I know what an ntp pool is. The point is though that it is a collection of individual servers. you resolve that address you'll still only get one IP back, one server to check. If you think that you'd be getting a different server each time you polled, then clearly ntp would stand no chance at all, as the drift and delay would constantly change and ntp would never work. just use 0.in.pool.ntp.org, 1.in.pool.ntp.org, 2.in.pool.ntp.org etc... to pick 3 random servers instead of just one.

Nope, not a lot (even though it's been running for months). Mostly about one or more pool servers dropping off (I specify three) and another coming on. I've just done it this way for... oh, wow, about 15 years now (lordy, time do fly when you're having fun).

Thing is, there just isn't anything in the system logs about NTPD and having this separate log (that's just NTPD) is handy if there's a problem -- and I haven't had any problems with it for a long, long time. Thing "just works."

I've just stopped and restarted NTPD (network connection via wireless USB) and the entries look like this.
And then it'll just sit there mumbling to itself with occasional kernel time sync status change and synchronized to messages.

Hope this helps some.

Thanks Chris :)

Now I have a new problem because I respect your knowledge but my understanding of what you wrote is different from my understanding of the information on ntp.org's "How do I use pool.ntp.org?" page.

That is not correct; dig returns three addresses. I do not know if ntpd uses more than one, though.
Which is presumably why ntp.org say that the sever names "point to a random set of servers that will change every hour". Presumably an hour is long enough to establish drift and delay (although the first period would, on average, be only 30 minutes).
ntp.org describe that technique first but then say "As pool.ntp.org will assign you timeservers from all over the world, time quality will not be ideal. You get a bit better result if you use the continental zones (For example europe, north-america, oceania or asia.pool.ntp.org), and even better time if you use the country zone (like ch.pool.ntp.org in Switzerland)".

I understand that to be saying that best is to configure the country pool (as long as it is adequate), next best the continent pool and, as a last resort, the global pool.

According to ntp.org, the appropriate configuration for users in India is
This nicely follows your advice to use at least 3 server lines while also putting country first. India has only 6 servers which is presumably why there is a single country line and two continent lines. Presumably the "2" in 2.in.pool.ntp.org could equally well have been 0 or 1.

LQ is great! Ask one question and get useful/necessary advice on another. A service model that few organisations attain :)

It is correct as ntp is only requesting a single a record. one server entry = one ip address. The A record itself on their DNS server does return lots of different IP's, that's the point of it, but you wil only use one per server definition in your ntpd.confThe longer you use an ntp server the better, if you track a servers drift properly you can drop down to obscenely low rates of checking without any real fear that you won't know what time it's going to tell you. Unless you control the settings deliberately, ntp could go as long as 36.5 hours between checking if it's very very happy with a specific server.
It can be, I don't know how many you could go up to, it might also be able to be "eggs" or "aluminium". Their DNS server will probably just blindly redirect any unknown cname to the pool address within their server, but the point is that it's a different DNS name. you could put 0 in there three times, and IF you directly query their end name servers then you'd get 3 different IP addresses. However your internal name stack, and other name servers online will cache these answers, so by making them different names, they should really faithfully be different IP addresses too.

http://www.eecis.udel.edu/~mills/ntp...yopt.html#pool describes pool command:

Thanks again Chris. This is turning out to be very educational :)

If I've understood correctly, the ideal scenario is where ntpd is configured to connect with at least 3 time servers and then maintains that connection (more properly "trust"?) with them long term. The randomising and hourly changing aspects of the ntp.org pools is simply to spread the load; it is not intended that an individual client should change. That is why the messages that I took as reassuring actually indicated that this ideal scenario had broken down; ntpd had lost contact with one of its ideally long-term time servers so had found another.

Thanks Petri :) Do you happen to know what "recent ntpd" means? The page is dated 12apr10 so it could be very recent. On Slackware 13.1, ntpd is 4.2.6p1 and the man page does not contain the word "pool" and there is no man page for ntp.conf.

Yes, "pool" works in Slackware 13.1 but Slackware 13.0 is too old. I just tried it and a single line 'pool fi.pool.ntp.org' generated three associations, as seen by 'ntpq -np'. (I am in Finland).

Yes. Unless something has changed recently, ntpd never asks DNS again after it has resolved the IP addresses and generated the associations with them. For example, if a remote ntp server changes its ip address, the local ntpd never hears about it unless it's restarted.

If 'ntpq -np' shows '*' (system peer) or '+' (candidate) in the first column, they are associations included in the algorithm. But '-' (outlyer), 'x' (falsetick), or ' ' (reject) means that they are discarded. The messages 'synchronized to...' refer to the system peer ('*') which changes every now and then. But '+' associations are also included in determining time.

Seems that "pool" is at the "undocumented feature" stage. As stated above it is not in the man pages. It is also not in the distributed Changelog or in the sample *.conf files:But it works for me, too. After replacing the server lines in ntp.conf withand restarting ntpd, ntpq -np listed six servers: one peer, two candidates and three outlyers.

Unnecessarily the peer was a stratum 1 server (if that's what the st column indicates). I understand it is bad NTP etiquette to peer with stratum 1 servers unless there is a real need for best accuracy.

I tried adding tos floor 2 to ntp.conf (strange that the default value is 1 ?) but this resulted in only two time servers one of which was a tier 1 and disabled -- leaving ntpd with a single time server, a tier 4!

Changing to tos floor 2 minclock 4 resulted in a tier 2 peer and 3 candidates. OK

Changing to tos floor 2 minclock 3 to avoid loading the time server network unnecessarily, resulted in only two servers. The default minclock value is 3 (as documented on http://www.eecis.udel.edu/~mills/ntp...scopt.html#tos) so this last change was simply making the default explicit.

Reverted to tos floor 2 minclock 4