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@lol ~]# date Wed Jan 27 10:54:21 AST 2016
- Force wrong time:
[admin@lol ~]# date -s 09:29 Wed Jan 27 09:29:00 AST 2016
- Restart ntp service:
[admin@lol ~]# service ntpd restart Shutting down ntpd: [ OK ] Starting ntpd: [ OK ]
- Time not synched (even after about 10 minutes)
[admin@lol ~]# date Wed Jan 27 09:35:52 AST 2016
- use ntpdate -u to force synch:
[admin@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@test-till ~]#
[admin@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@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@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@lol ~]# ntpd -d ntpd 4.2.6p5@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.
On 27 January 2016 at 08:36, John R Pierce pierce@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
On 27 January 2016 at 08:53, Dirk Deimeke dirk@deimeke.net wrote:
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.
It's best practice to have a reasonable pool of sources (3, 5 or 7 depending on how many false tickers you want to be able to cope with) but it can run against a single source, with the understanding that it has to trust it as real time since there's nothing to compare it to.
In article 56A88188.6070808@hogranch.com, John R Pierce pierce@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
-
Dirk Deimeke -
Gordon Messmer -
James Hogarth -
John R Pierce -
tony＠softins.co.uk -
Traiano Welcome