topic Re: ntpd not working, ntpdate -u works fine in Operating System - Linux

ntpd not working, ntpdate -u works fine

YairZaretski — Sun, 09 May 2010 14:23:39 GMT

Hi all,

I have a strange situation with ntp.
I have set up a standard ntp.conf configuration (listed below) on an rhel5 server, yet ntpd is unable to synchronize time with my time source. it synchronizes with the local clock instead.
When I run ntpdate -u ntp_server, it's able to synchronize the clock.

I have tried synchronizing with other time sources and linux servers in my organization but with the same result.

I have also tried adding to grub.conf the following with no success:
clock=pit nosmp noapic nolapic

This is my /etc/ntp.conf coniguration on the ntp client:
****Start of /etc/ntp.conf******
restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server 127.127.1.0
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
keys /etc/ntp/keys
server server1
restrict server1 mask 255.255.255.255 nomodify notrap noquery
server server2
restrict server2 mask 255.255.255.255 nomodify notrap noquery
****End of /etc/ntp.conf*****

this is my /etc/ntp.conf coniguration on server1:
****Start of /etc/ntp.conf******
restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server 127.127.1.0
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
keys /etc/ntp/keys
server 0.rhel.pool.ntp.org
server 1.rhel.pool.ntp.org
server 2.rhel.pool.ntp.org
restrict 192.168.100.0 mask 255.255.255.0 nomodify notrap
****End of /etc/ntp.conf*****
where 12.168.100.0 is the subnet of th servers

This what I get in ntpq -p on the ntp clients:
[root@ntpclient ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 10 l 52 64 377 0.000 0.000 0.001
server1 .LOCL. 1 u 913 1024 377 0.289 -61.588 15.260
server2 .INIT. 16 u - 1024 0 0.000 0.000 0.000
[root@ntpclient ~]#

This is the output of ntpdate -u:
[root@ntpclient ~]# ntpdate -u server1
9 May 18:20:14 ntpdate[27625]: adjust time server 192.168.100.20 offset -0.088901 sec
[root@ntpclient ~]#

Does anyone have any idea?

Re: ntpd not working, ntpdate -u works fine

Matti_Kurkela — Sun, 09 May 2010 17:30:23 GMT

This tells me the client has not been able to reach server2 at all:

*LOCAL(0) .LOCL. 10 l 52 64 377 0.000 0.000 0.001
server1 .LOCL. 1 u 913 1024 377 0.289 -61.588 15.260
server2 .INIT. 16 u - 1024 0 0.000 0.000 0.000

So the client has two possible sources of time information. One agrees 100% with the client's local clock (because it *is* the local clock), has no measurable communication delay and insignificant delay jitter. The other is slow by about 61.6 ms, has some delay and quite a bit of jitter. So, by the numbers, the first one looks very reliable indeed.

If there were two timesources that would be in a reasonable agreement with each other and disagree with the local clock, ntpd would pick one of them instead of the local clock. But there are only two active timesources, so this sanity check is not possible. The result is that ntpd dumbly picks the local clock as its reference of choice.

My recommendation is simple: comment out the local clock lines ("server 127.127.1.0" and "fudge 127.127.1.0 stratum 10") from your NTP client configuration.

You don't really need it to fall back to the local clock if the contact to all the configured NTP servers is lost: your OS will do that automatically whenever ntpd is not running or cannot provide time synchronization.

The local clock configuration has any value in your NTP server hosts only. When a NTP server is not synchronized with any timesource, it will not provide time information to its clients: its answer will be the NTP protocol equivalent of "I'm not sure."

If this happens to your server1 and server2, then all your clients will fall back to their own internal clocks, and each system will drift on its own.

But if one of the servers has a local clock configured, that server will use it as a last-resort timesource, and can keep serving the clients. In this situation, your group of clients may drift out of sync with the rest of the world - but they all will at least stay in sync with the server, and thus with each other, which is usually the main goal of time synchronization.

My second recommendation would be: your NTP client obviously has some sort of problem in communicating with server2. Find out why, and fix it.

MK

Re: ntpd not working, ntpdate -u works fine

YairZaretski — Mon, 10 May 2010 09:31:57 GMT

Thanks!
I actually combined both recommendations and it solved part of the problem.
I removed the local clock and added another NTP server instead of the non-functional one.
Now, it synchronizes with the new NTP server I listed, which is stratum 11, and not with the first NTP server, which is stratum 1.
I'm not sure why it can't work with the stratum 1 NTP server, though.
Do you have any idea whelse can I check?

At least now, I'm able to synchronize with something in the network

Re: ntpd not working, ntpdate -u works fine

Randy Jones_3 — Mon, 10 May 2010 20:26:13 GMT

If your system is synchronizing to another that shows stratum 11, then that other system is using it's local clock instead of some better authoritative source.

It is likely that your systems are simply too far away from the accurate time on the stratum 1 server. ntpd will not make a correction if it exceeds about two minutes. Use ntpdate to step your system to match time on the stratum 1 server, then start up ntpd to maintain that accurate time. NTP will prefer to use the lower strata over the higher ones if they are within range. The local clock is fudged to 10 or higher so that it is the least preferred.

I would not remove the local clock definition from the configuration since it allows systems to at least agree with each other if a failure occurs that puts your cluster out of touch with more authoritative clocks.