SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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:
Code:
cat /etc/ntp.conf | grep -E -v '^$|^#' cat /etc/ntp.conf | grep -E -v '^$|^#'
server in.pool.ntp.org
server asia.pool.ntp.org
server 127.127.1.0
fudge 127.127.1.0 stratum 10
driftfile /etc/ntp/drift
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?
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
Code:
# Start ntpd:
ntpd_start() {
# Clear the log file
>/tmp/ntp.log # this wipes out the old log
CMDLINE="/usr/sbin/ntpd -g"
echo -n "Starting NTP daemon: $CMDLINE"
$CMDLINE -p /var/run/ntpd.pid -l /tmp/ntp.log # this generates the log entries
echo
}
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.
Last edited by catkin; 06-28-2010 at 10:28 PM.
Reason: Insert mssing coma
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?
Last edited by catkin; 06-28-2010 at 10:27 PM.
Reason: Removed quote
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.
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?
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.
Code:
cat /tmp/ntp.log
29 Jun 07:33:21 ntpd[20709]: logging to file /tmp/ntp.log
29 Jun 07:33:21 ntpd[20709]: precision = 1.000 usec
29 Jun 07:33:21 ntpd[20709]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
29 Jun 07:33:21 ntpd[20709]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
29 Jun 07:33:21 ntpd[20709]: Listening on interface #1 wildcard, ::#123 Disabled
29 Jun 07:33:21 ntpd[20709]: Listening on interface #2 lo, ::1#123 Enabled
29 Jun 07:33:21 ntpd[20709]: Listening on interface #3 lo, 127.0.0.1#123 Enabled
29 Jun 07:33:21 ntpd[20709]: Listening on interface #4 ppp0, 75.232.185.247#123 Enabled
29 Jun 07:33:21 ntpd[20709]: kernel time sync status 0040
29 Jun 07:33:26 ntpd[20709]: frequency initialized 0.000 PPM from /etc/ntp/drift
29 Jun 07:36:37 ntpd[20709]: synchronized to LOCAL(0), stratum 10
29 Jun 07:36:37 ntpd[20709]: kernel time sync status change 0001
29 Jun 07:38:48 ntpd[20709]: synchronized to 216.93.242.10, stratum 2
And then it'll just sit there mumbling to itself with occasional kernel time sync status change and synchronized to messages.
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.
Quote:
Originally Posted by acid_kewpie
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.
That is not correct; dig returns three addresses. I do not know if ntpd uses more than one, though.
Quote:
Originally Posted by acid_kewpie
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.
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).
Quote:
Originally Posted by acid_kewpie
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.
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
Code:
server 2.in.pool.ntp.org
server 1.asia.pool.ntp.org
server 2.asia.pool.ntp.org
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
Thanks Chris
That is not correct; dig returns three addresses. I do not know if ntpd uses more than one, though.
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.conf
Quote:
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).
The 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.
Quote:
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
Code:
server 2.in.pool.ntp.org
server 1.asia.pool.ntp.org
server 2.asia.pool.ntp.org
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.
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.
The pool scheme is configured using one or more pool commands with DNS names indicating the pool from which to draw. The pool command can be used more than once; duplicate servers are detected and discarded. In principle, it is possible to use a configuration file containing a single line pool pool.ntp.org. The NTP Pool Project offers instructions on using the pool with the server command, which is suboptimal but works with older versions of ntpd predating the pool command. With recent ntpd, consider replacing the multiple server commands in their example with a single 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.
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).
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.
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.
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).
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:
Code:
root@CW9:/usr/share/doc/ntp-4.2.6p1# ls --classify
COPYRIGHT NEWS README README.hackers README.refclocks TODO clockstuff/ html/ readme.y2kfixes scripts/
ChangeLog NOTES.y2kfixes README.bk README.patches README.versions WHERE-TO-START conf/ ntpdate/ results.y2kfixes util/
root@CW9:/usr/share/doc/ntp-4.2.6p1# grep --ignore-case pool * conf/*
conf/grundoon.conf:statsdir /var/spool/ntpstats/ # directory for statistics files
conf/pogo.conf:statsdir /var/spool/ntpstats/ # directory for statistics files
But it works for me, too. After replacing the server lines in ntp.conf with
Code:
pool in.pool.ntp.org
pool asia.pool.ntp.or
and 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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
