4

I have installed a very simple NTP server on a Red Hat server I own, the configuration is pretty basic:

driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap 
restrict -6 default kod nomodify notrap 
restrict 127.0.0.1 
restrict -6 ::1
restrict 192.168.200.0 mask 255.255.255.0 nomodify notrap
server 0.rhel.pool.ntp.org
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys

If I try to test this from localhost, it seems to work properly:

ntpq -p localhost
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 gw-ge.esaote.co 62.48.53.90      3 u   56   64  173   81.474  -163823 67736.2

If I try to query it from a remote machine, same result:

ntpq -p 192.168.200.151
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 gw-ge.esaote.co 62.48.53.90      3 u    -   64  367   75.500  -163838 61828.5

But, if I invoke ntpdate, doesn't work:

ntpdate 192.168.200.151
12 Mar 10:35:51 ntpdate[2688]: no server suitable for synchronization found
Improve this question
1
  • 1
    Your ntp server should use more servers, at least three. – Martin Schröder Mar 13 '14 at 9:41
5

Your NTP server is too far out of sync from the pool servers. You'll note that the leftmost character before the hostname in the ntpq -p output is a space. If NTP was synchronised to the remote server, this would be a *. Also note the very large offset value, which tells you that the time set on your server is way off.

Stop NTP, do a ntpdate pool.ntp.org, and restart it. After a few minutes it should settle down and synchronise, and your client should then be able to query it.

Improve this answer
3
  • 1
    Don't use ntpdate. – Martin Schröder Mar 13 '14 at 9:40
  • Ooh, thanks for that. 'After a suitable period of mourning, the ntpdate program may be retired'. I am so old school ;-( – Flup Mar 13 '14 at 9:43
  • What I discovered is that, regardless the error I posted above, the npt client synced slowly to the server. I can't simply why I had that error in first place. – ludiegu Mar 13 '14 at 9:57
1

There are lots of ntp questions and they all have the same mistake: people using SERVER on an ntp pool and POOL on an ntp server:

server 0.rhel.pool.ntp.org

As the URL says, it's a POOL. Try

pool 0.rhel.pool.ntp.org

instead or actually use a server, not a pool ...

Furthermore, most people have a timesource in their network, most often Windows Domain Controllers. If this is true for you, why messing with external ntp servers when you could use internal NTP of Windows DC ...

Don't keep ntpdate on your server if you use ntpd!

Considering for any reasons whatsoever why your system is drifting in time, whatcha gonna do 'bout it?

When you face time issues on Linux, firstly check any virtualization system - if you use VMware/Hyper-V/Xen/KVM/Whatever - think about what really is your "hardware clock" here!?! Sometimes your "BIOS" clock is misbehaving but it is as virtual as your network card(!) so if you use VMs talk to your colleagues in charge.

Considerring the differenciation of ntpd and ntpd put in a nutshell: ntpd is "cheating" your system by slighty adding fractions of time to system time (date) until local system time is synced with whatever your time source says, whereas ntpdate sets your local time to "network time" promptly.

System time is what the command date will tell you on Linux. But there is also hwclock (needs sudo) which is indeed your hardware a.k.a BIOS clock.

For once - literally speaking - you may need to do

sudo hwclock ---systohc

to set your BIOS/hardware/virtual clock to system date - what ntpd says. If you need to do this more often, there is a problem.

I know for sure, this applies to Ubuntu, so I assume it also applies to Debian. Reason is that the system may call ntpdate in time (cron.weekly?) but when you have ntpd running, it would ususally complain! You simply can't run ntpdate when ntpd is running.

Usually, you install ntpd because it owns a drift file that enables ntpd to adjust your time smoothly but "over time" - it may add here a fraction of a second and there but not forcing to reset the time to let's say 30 seconds in the future - or even worse the past - because you can assume e.g. most databases do not like time travels at all!

And that's what ntpd is for. ntpdate - in opposite - will promptly correct any time drifts what may cause time critical application issues - ntpd on the other hand will add some milliseconds to every past second so things will get the right time "in time", not surprising any application that is deeply relying on timestaps with BIG jumps in time for- or backwards. Serious databases with serious content do rely on timestamps (e.g. mysql/postgres/mariadb).

So you see they both have different approches and can't be used together.

Improve this answer
4
  • Errm, you're aware the pool directive is relatively recent? Older versions of ntpd didn't have it, and had to use server instead. And also, the difference is just that the pool directive will replace failed servers? – derobert Apr 10 '17 at 17:57
  • Obviously, I am not but the problem with ntpd and ntpdate and its implications remain. In the end his/her system seems misconfigured so to stay solution centered, let's focus on that 0:) – user226277 Apr 10 '17 at 18:47
  • I'm pretty sure the problem is the clock being way off (the absurdly high offset). But anyway, the point of the comment is to suggest improvements, so e.g., noting which versions of ntpd support the pool directive would make it better. – derobert Apr 10 '17 at 18:53
  • yes, but that would cost him/her time for research ;-) – user226277 Apr 10 '17 at 18:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.