Topic: smeserver.pool.ntp.org missing from DNS?

[allsorts]

After a reboot yesterday my servers time was 10 mins slow last night and 15 minutes slow this morning.

The server is set up to use NTP and the default smeserver.pool.ntp.org time source. ntpq was showing several servers but all with huge offsets (not surprisingly) and way outside the adjustment range.

Investigation found that smeserver.pool.ntp.org seems to have disappeared from the DNS, ie I don't get a block of four results returned for a "dig  smeserver.pool.ntp.org" like I do for "dig uk.pool.ntp.org" or "dig pool.ntp.org".

What is more worrying is that I didn't get any warning email that ntpd was not syncing the time or otherwise having trouble.

Anyone else seeing the same?

[mmccarn]

I, too, get errors looking for 'smeserver.pool.ntp.org'

However, if NTPServer (config getprop ntpd NTPServer) is set to any value  containing 'pool.ntp.org' it is expanded by default to "0.<NTPServer>", "1.<NTPServer>", "2.<NTPServer"> and "3.<NTPServer>".

Here is the content of /etc/ntp.conf on my SME 8 server:

Code: [Select]

#------------------------------------------------------------
#        !!DO NOT MODIFY THIS FILE!!
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at http://www.contribs.org/development/
#
# Copyright (C) 1999-2006 Mitel Networks Corporation
#------------------------------------------------------------
server 0.smeserver.pool.ntp.org
server 1.smeserver.pool.ntp.org
server 2.smeserver.pool.ntp.org
server 3.smeserver.pool.ntp.org

server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10

driftfile /etc/ntp/drift
All of the above "0...", "1...", "2..." and "3..." servers work for me as verified using:

Code: [Select]

ntpdate -d 0.smeserver.pool.ntp.org
ntpdate -d 1.smeserver.pool.ntp.org
ntpdate -d 2.smeserver.pool.ntp.org
ntpdate -d 3.smeserver.pool.ntp.org

(Any one of which will also correct your clock...)

FWIW, I think one of my virtualized SME servers runs ntpdate at bootup to reset the clock.

[allsorts]

Hum, OK maybe the not getting results back for smeserver.pool.ntp.org is fine, I've switched to uk.pool.ntp.org but there is still something wrong with my server as my clock is still losing time at a rather alarming rate, like  20 odd seconds an hour...

I've stopped ntpd (sv d /service/ntpd), set the time (ntpdate pool.ntp.org), set the hardware clock (hwclock -w) and restarted ntpd (sv u /service.ntpd). The log shows a suitably small  ntpdate step time server  value and the daemon starts. I've left it over an hour and the driftfile hasn't been updated, the clock is losing time and all the servers listed  by the as command in ntpq are down as reject apart from the local one. The pe command shows rapidly increasing offsets, around 22 seconds in 17 mins just now across all servers ... that's around 21,000 PPM!

How long does ntpd take to sort itself out, work out the drift value and choose a server to sync to rather than itself? I thought it was fairly quick, 15 mins or so.

[janet]

allsorts

Is this a virtual server? There are known time sync issues. If so, search.

[allsorts]

Not it's a real physical machine,  a month old HP Microserver.

Restarted ntpd at 1452 (with all the clocks manually set). It's now 2016 and the offsets from ntpq > pe are over 200 seconds and ntps > as has all the servers still marked as reject. The drift file hasn't been updated. either  B-(

Something weird is going on. I *think* it's ntpd causing the slow clock. I'll stop ntpd again in a while and let the machine "free run" as see if it still loses times.

[allsorts]

Well I don't know what all that was about. Stopped ntpd, software clock kept losing time but the hardware clock didn't and stayed with real time. Rebooted the server and all is well. Yesterdays reboot that started all this off was to install a couple of updates via Server Manager (libxml2.i386 and libxml2-python.i386). Can't imagine that is particularly relevant I just mention it for completeness.

[holck]

It sounds a lot like the problem I experienced:
http://forums.contribs.org/index.php?topic=49956.0

[CharlieBrady]

What is more worrying is that I didn't get any warning email that ntpd was not syncing the time or otherwise having trouble.

That's never been a feature of SME server software. If you care to develop the code, you'd correct that deficiency, and many people would thank you for it.

Anyone else seeing the same?

As a member of docteam you know that you should be reporting a bug, rather than asking this question here. If something needs to be fixed, the only way that will happen is via the bug tracker.

[123].smeserver.pool.ntp.org resolve in DNS for me.

[allsorts]

That's never been a feature of SME server software. If you care to develop the code, you'd correct that deficiency, and many people would thank you for it.

If I knew where to start I would... Any hints? I don't think ntpd itself gets upset by the situation so maybe a perl cron job to parse the output of ntpq -p? The hard part may well be getting a server with a system clock having a >500ppm drift to get ntpd into the "I'm not going to sync with anything" state to test any such perl script. My errant server is now quite happy after a reboot.

As a member of docteam you know that you should be reporting a bug, rather than asking this question here. If something needs to be fixed, the only way that will happen is via the bug tracker.

I would have done if I'd found that there was something broken in SME. I was busy trying to work out what was going on and "dig smeserver.pool.ntp.org" not returning what I expected was confusing me, particulary as uk.pool.ntp.org does return what I expected...

[mmccarn]

If I knew where to start I would...

Here's a start...but I suspect that if my mail server clock starts drifting badly the alert email is likely to 'sort' off the screen in my email client...

Code: [Select]

ntpstat > /dev/null || echo -e "Subject: NTP is driftin'\nEnd of Message" | sendmail admin@<my.smeserver.local>


[CharlieBrady]

Here's a start...

That would be better if the output of ntpstat formed (part of) the body of the email message. Nice start though.

[purvis]

FWIW

We are on Chicago time.
I checked the time on my servers. All servers showed the correct current time to the second.
2 servers running in virtual mode on proxmox had the proper time also.
I used the date program in a linux console to get the date and time of day.
I did not go any further  than just using the date program.

All servers where updated Sunday and rebooted after the updates.
The time was checked now on Wednesday after 5pm.

[allsorts]

That would be better if the output of ntpstat formed (part of) the body of the email message. Nice start though.

*IF* ntpstat does return 1 when ntpd is not syncing to external sources when the drift is >500 ppm. Looking at the logs when my system was playing up it looks like ntpd was "synchronized" but to the wayward system clock.

4 Aug 14:49:02 ntpd[32313]: kernel time sync status 0040
4 Aug 14:49:03 ntpd[32313]: frequency initialized 10.000 PPM from /etc/ntp/drift
4 Aug 14:52:20 ntpd[32313]: synchronized to LOCAL(0), stratum 10
4 Aug 14:52:20 ntpd[32313]: kernel time sync enabled 0001
4 Aug 21:46:59 ntpd[32313]: ntpd exiting on signal 15
5 Aug 00:29:27 ntpdate[3257]: step time server 82.113.154.206 offset 96.09872
5 Aug 00:29:28 ntpd[3184]: logging to file /dev/stdout
5 Aug 00:29:29 ntpd[3184]: precision = 1.000 usec
5 Aug 00:29:29 ntpd[3184]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
5 Aug 00:29:29 ntpd[3184]: Listening on interface wildcard, 0.0.0.0#123 Disabled
5 Aug 00:29:29 ntpd[3184]: Listening on interface lo, 127.0.0.1#123 Enabled
5 Aug 00:29:29 ntpd[3184]: Listening on interface eth0, 192.168.1.1#123 Enabled
5 Aug 00:29:29 ntpd[3184]: Listening on interface eth1, 172.16.21.2#123 Enabled
5 Aug 00:29:29 ntpd[3184]: kernel time sync status 0040
5 Aug 00:29:29 ntpd[3184]: frequency initialized 10.000 PPM from /etc/ntp/dri
5 Aug 00:32:48 ntpd[3184]: synchronized to LOCAL(0), stratum 10
5 Aug 00:32:48 ntpd[3184]: kernel time sync enabled 0001
5 Aug 00:33:53 ntpd[3184]: synchronized to 178.79.160.57, stratum 2
5 Aug 00:41:20 ntpd[3184]: synchronized to 130.159.196.118, stratum 2

At 14:52:20 it reports the same as it does when it will sync to an external source, there would then be an entry for each occasion it switches reference. But as the drift was >500 ppm it stayed with LOCAL.

At 21:46.59 I stopped ntpd and let the system free run. The system clock still lost time but the hardware one didn't and the two drifted apart. When ntpd was running both the system and hardware clcoks drifted together.

00:29:27 is the machine coming back up after a reboot. Note the identical series of log entries from "... status 0040". The machine has been happy since.

There appears to be a very rare problem during boot related to setting up the system clock. Just very occasionally it appears to get the frequency wrong and the drift is >500 ppm. which ntpd can't handle.  Some one with a spare server needs to figure out how to consistently get a >500 ppm drift on the system clock, have ntpd not syncing to remote servers, then see what ntpstat reports. I'm busy for the next week, yes really...  B-)

[CharlieBrady]

At 21:46.59 I stopped ntpd and let the system free run. The system clock still lost time but the hardware one didn't and the two drifted apart. When ntpd was running both the system and hardware clcoks drifted together.

That's because when ntp is running, the kernel periodically (every 11 minutes) updates the hardware clock from the system time.

http://serverfault.com/questions/337930/what-is-the-largest-hardware-clock-update-the-linux-kernel-11-minute-mode-can

I don't think there is any way to disable this behaviour.

When ntp is using the hardware clock as a reference, it becomes a useless "reference" if it keeps changing. So this is stupid behaviour. As far as I can tell, there's never been any or much debate about this lunacy amongst the kernel developers.