CentOS - Jan 2016 - NTP Service Running on Local Host does not Sync System Time

Hi List

I have  ntp running as a service on a PC, with the expectation that it
would keep time in synch to my ntp server.

However, while  I can manually update the time using "ntpdate -u ...",
I find that if I manually force the wrong time, the ntpd service does
not automatically re-synch the system time with the ntp server:

- Current time:

[admin at lol ~]# date
Wed Jan 27 10:54:21 AST 2016


- Force wrong time:

[admin at lol ~]# date -s 09:29
Wed Jan 27 09:29:00 AST 2016

- Restart ntp service:

[admin at lol ~]# service ntpd restart
Shutting down ntpd:                                        [  OK  ]
Starting ntpd:                                             [  OK  ]


- Time not synched (even after about 10 minutes)

[admin at lol ~]# date
Wed Jan 27 09:35:52 AST 2016

- use ntpdate -u to force synch:

[admin at lol ~]# ntpdate -u time.lol.com
27 Jan 11:02:28 ntpdate[18570]: step time server 172.16.100.13 offset
5154.859809        sec
[osadmin at test-till ~]#

[admin at lol ~]# date
Wed Jan 27 11:03:09 AST 2016


I'm not sure if this is a configuration issue with ntp (ntp.conf looks
fine, as well as /etc/sysconfig/ntpd.conf (pasted below).

/etc/ntp.conf:

restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1
server time.lol.com
driftfile /var/lib/ntp/drift


/etc/sysconfig/ntpd"

# Drop root to id 'ntp:ntp' by default.
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"
# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=yes
# Additional options for ntpdate
NTPDATE_OPTIONS=""
---

Here are some diagnostic queries with ntpq:

---
[admin at lol ~]#  ntpq -pcrv

     remote           refid      st t when poll reach   delay   offset  jitter
=============================================================================
10.1.0.111   xxx.xx.xx.x      2 u   26   64    1    3.618  6018473   0.001
associd=0 status=c012 leap_alarm, sync_unspec, 1 event, freq_set,
version="ntpd 4.2.6p5 at 1.2349-o Sat Nov 23 18:20:11 UTC 2013 (1)",
processor="i686", system="Linux/2.6.32-504.1.3.el6.i686",
leap=11,
stratum=16, precision=-20, rootdelay=0.000, rootdisp=0.405, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  9:28:16.000,
clock=da52e461.90fabbc4  Wed, Jan 27 2016  9:38:25.566, peer=0, tc=3,
mintc=3, offset=0.000, frequency=356.208, sys_jitter=0.000,
clk_jitter=0.001, clk_wander=0.000
----

What could be the issue? Any help would be appreciated.


Here is the output from running the ntpd service in debug mode:

---
[admin at lol ~]# ntpd -d
ntpd 4.2.6p5 at 1.2349-o Sat Nov 23 18:20:11 UTC 2013 (1)
27 Jan 09:29:58 ntpd[18652]: proto: precision = 0.931 usec
27 Jan 09:29:58 ntpd[18652]: 0.0.0.0 c01d 0d kern kernel time sync enabled
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
Finished Parsing!!
27 Jan 09:29:58 ntpd[18652]: ntp_io: estimated max descriptors: 1024,
initial socket boundary: 16
27 Jan 09:29:58 ntpd[18652]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
27 Jan 09:29:58 ntpd[18652]: Listen and drop on 1 v6wildcard :: UDP 123
27 Jan 09:29:58 ntpd[18652]: Listen normally on 2 lo 127.0.0.1 UDP 123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000
flags 00000001
27 Jan 09:29:58 ntpd[18652]: Listen normally on 3 eth 172.16.0.213 UDP 123
restrict: op 1 addr 172.16.0.213 mask 255.255.255.255 mflags 00003000
flags 00000001
27 Jan 09:29:58 ntpd[18652]: Listen normally on 4 lo ::1 UDP 123
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
mflags 00003000 flags 00000001
27 Jan 09:29:58 ntpd[18652]: Listen normally on 5 eth
fe80::3640:b5ff:fe90:104e UDP 123
restrict: op 1 addr fe80::3640:b5ff:fe90:104e mask
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
27 Jan 09:29:58 ntpd[18652]: peers refreshed
27 Jan 09:29:58 ntpd[18652]: Listening on routing socket on fd #22 for
interface updates
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000001d0
restrict: op 1 addr :: mask 0.0.0.0 mflags 00000000 flags 000001d0
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000
flags 00000000
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
mflags 00000000 flags 00000000
key_expire: at 0 associd 17148
peer_clear: at 0 next 1 associd 17148 refid INIT
event at 0 10.1.0.111 8011 81 mobilize assoc 17148
newpeer: 172.16.0.213->10.1.0.111 mode 3 vers 4 poll 6 10 flags 0x1
0x1 ttl 0 key 00000000
27 Jan 09:29:58 ntpd[18652]: 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c016 06 restart
27 Jan 09:29:58 ntpd[18652]: 0.0.0.0 c012 02 freq_set kernel 356.208 PPM
event at 0 0.0.0.0 c012 02 freq_set kernel 356.208 PPM
transmit: at 1 172.16.0.213->10.1.0.111 mode 3 len 48
auth_agekeys: at 1 keys 1 expired 0
receive: at 1 172.16.0.213<-10.1.0.111 mode 4 len 48
event at 1 10.1.0.111 8024 84 reachable
clock_filter: n 1 off 6018.651057      del 0.003849 dsp 7.945313 jit 0.000001
.
.

---

I'm tempted to stick an "ntpdate -u ..." in the crontab to force
time-synch, but I don't see why that's needed if ntpd service should
already be fulfilling that purpose.

Many thanks in advance,
Traiano

On 1/27/2016 12:25 AM, Traiano Welcome wrote:
> I'm tempted to stick an "ntpdate -u ..." in the crontab to
force
> time-synch, but I don't see why that's needed if ntpd service
should
> already be fulfilling that purpose.

ntpd won't make drastic changes in the time, if its too far off. its 
designed to stabilize the clock by making small changes in speeding it 
up or slowing it down, and not 'staircase' setting it absolutely.

IMHO, ntpdate -u should be run before starting ntpd so the clock is 
close to spot on up front, I have sometimes added this to the 
/etc/init.d/ntp scripts.   with systemd, this woudl be trickier to 
implement, maybe a seperate 'service' thats runs the ntpddate -u and 
exits, which the ntpd service depends on being run first?  I dunno, I 
haven't really spent the time to grok systemd thoroughly yet.


-- 
john r pierce, recycling bits in santa cruz

On 27 January 2016 at 08:36, John R Pierce <pierce at hogranch.com>
wrote:
> On 1/27/2016 12:25 AM, Traiano Welcome wrote:
>>
>> I'm tempted to stick an "ntpdate -u ..." in the crontab
to force
>> time-synch, but I don't see why that's needed if ntpd service
should
>> already be fulfilling that purpose.
>
>
>
> ntpd won't make drastic changes in the time, if its too far off. its
> designed to stabilize the clock by making small changes in speeding it up
or
> slowing it down, and not 'staircase' setting it absolutely.
>
> IMHO, ntpdate -u should be run before starting ntpd so the clock is close
to
> spot on up front, I have sometimes added this to the /etc/init.d/ntp
> scripts.   with systemd, this woudl be trickier to implement, maybe a
> seperate 'service' thats runs the ntpddate -u and exits, which the
ntpd
> service depends on being run first?  I dunno, I haven't really spent
the
> time to grok systemd thoroughly yet.

Or of course reading the man page for ntpd it can be seen that the
simplest answer is to use the -g option

http://linux.die.net/man/8/ntpd

This can be added in /etc/sysconfig/ntpd - the appropriate config file
for such a thing.

Hacking the init scripts is a terribly fragile thing that will break
on the next NTP package update as they are explicitly not marked as
config files and will be 'fixed'.

On 2016-01-27 09:36, John R Pierce wrote:

Hi!
> ntpd won't make drastic changes in the time, if its too far off. its
> designed to stabilize the clock by making small changes in speeding it
> up or slowing it down, and not 'staircase' setting it absolutely.
http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ALGO-BASIC-STEP-SLEW

Apart from that, the ntp-implementation (or chrony nowadays) "wants"
to
have more than one time source.

http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#Q-NTP-ALGO

Cheers

Dirk

-- 
https://d5e.org/

In article <56A88188.6070808 at hogranch.com>,
John R Pierce <pierce at hogranch.com> wrote:
> On 1/27/2016 12:25 AM, Traiano Welcome wrote:
> > I'm tempted to stick an "ntpdate -u ..." in the crontab
to force
> > time-synch, but I don't see why that's needed if ntpd service
should
> > already be fulfilling that purpose.
> 
> 
> ntpd won't make drastic changes in the time, if its too far off. its 
> designed to stabilize the clock by making small changes in speeding it 
> up or slowing it down, and not 'staircase' setting it absolutely.
> 
> IMHO, ntpdate -u should be run before starting ntpd so the clock is 
> close to spot on up front, I have sometimes added this to the 
> /etc/init.d/ntp scripts.
You don't need to do that. If you have one or more ntp servers listed
in /etc/ntp/step-tickers, the startup scripts will do it for you
automatically. In C5 the ntpd script does it. In C6 you have to
do "chkconfig ntpdate on" too, as it is separate from the ntpd script.
In C7 i have no idea :-)

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org