A shell script is deployed to synchronize time, the script is invoked hourly by crontab, and its content is as follows: #!/bin/bash service ntpd stop ntpdate 192.168.0.191 #it's a valid ntpd server in LAN service ntpd start chkconfig ntpd on
Inspected the Linux log(Centos6.4 /var/log/messages), found the following fragment: Jan 7 14:00:01 host1 ntpd[32101]: ntpd exiting on signal 15 Jan 7 13:59:59 host1 ntpd[44764]: ntpd 4.2.4p8@1.1612-o Fri Feb 22 11:23:27 UTC 2013 (1) Jan 7 13:59:59 host1 ntpd[44765]: precision = 0.143 usec Jan 7 13:59:59 host1 ntpd[44765]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Jan 7 13:59:59 host1 ntpd[44765]: Listening on interface #1 wildcard, ::#123 Disabled Jan 7 13:59:59 host1 ntpd[44765]: Listening on interface #2 lo, ::1#123 Enabled Jan 7 13:59:59 host1 ntpd[44765]: Listening on interface #3 em2, fe80::ca1f:66ff:fee1:eed#123 Enabled Jan 7 13:59:59 host1 ntpd[44765]: Listening on interface #4 lo, 127.0.0.1#123 Enabled Jan 7 13:59:59 host1 ntpd[44765]: Listening on interface #5 em2, 192.168.1.151#123 Enabled Jan 7 13:59:59 host1 ntpd[44765]: Listening on routing socket on fd #22 for interface updates Jan 7 13:59:59 host1 ntpd[44765]: kernel time sync status 2040 Jan 7 13:59:59 host1 ntpd[44765]: frequency initialized 499.399 PPM from /var/lib/ntp/drift Jan 7 14:00:01 host1 ntpd_initres[32103]: parent died before we finished, exiting Jan 7 14:04:17 host1 ntpd[44765]: synchronized to 192.168.0.191, stratum 2 Jan 7 14:04:17 host1 ntpd[44765]: kernel time sync status change 2001
The script should be executed at 14:00, the first line of the fragment also should indicate that the command 'service ntpd stop' have executed successfully, but why the second line timestamp(13:59:59) is less than the first line's(14:00:01)? Inspected the Linux log, the problem has happened three times, the time point was Jan 7 14:00:00, Jan 14 14:00:00 and Feb 4 14:00:00 respectively.
On 2/11/2015 5:53 PM, David chen wrote:
A shell script is deployed to synchronize time, the script is invoked hourly by crontab, and its content is as follows: #!/bin/bash service ntpd stop ntpdate 192.168.0.191 #it's a valid ntpd server in LAN service ntpd start chkconfig ntpd on
huh? ntpd synchronizes time continuously with the given reference servers. why in heck would you stop it to set the clock then restart it ?!?
$ uptime 6:37pm up 422 days, 19:38, 1 user, load average: 0.00, 0.04, 0.06 $ ntptrace localhost: stratum 3, offset 0.000015, synch distance 0.05679 enigma.wiredgoats.com: stratum 2, offset 0.000249, synch distance 0.04080 lantime.sonic.net: stratum 1, offset -0.000116, synch distance 0.00044, refid 'PPS'
ntpd hasn't been stopped or restarted since that server last booted over a year ago... my time is within 0.000116 seconds, thats 116 microseconds, of the reference server. ntpd works by incrementally fine tuning the speed the system clock runs at, using phase lock loop techniques, so the clock remains monotonic (always increasing) and stable. running a hard time set program can cause the clock to go BACKWARDS if its running fast.
if ntpd isn't working for you properly, you should investigate what ntp servers you're using in /etc/ntp.conf
On Feb 11, 2015, at 8:53 PM, David chen c77_cn@163.com wrote:
The script should be executed at 14:00, the first line of the fragment also should indicate that the command 'service ntpd stop' have executed successfully, but why the second line timestamp(13:59:59) is less than the first line's(14:00:01)?
Because at 14:00, ntpd was stopped, then ntpdate was run which caused the clock to jump back in time, and ntpd started, and logged that it starts with the new time. Syslog doesn't know the clock has changed, it's just logging what it thinks the current time is. This is why you use ntpd instead of ntpdate out of cron -- ntpd is *supposed* to gradually change the clock until the OS clock matches the upstream NTPd server times.
I think you might want to check your ntpd configuration, because clearly its not keeping your clock in time. Either that, or it's set up to talk to different clocks than what you're telling ntpdate to use.
-- Jonathan Billings billings@negate.org
On 12/02/15 12:53, David chen wrote:
but why the second line timestamp(13:59:59) is less than the first line's(14:00:01)?
Total guess here, but I suspect what's happening is that the ntp server on your LAN that this client is getting the time from in the hardcoded 'ntpdate' command is about ~1 second out from the servers the client is using from /etc/ntp.conf
Further complicating matters is the output from the hardcoded 'ntpdate' command doesn't appear in /var/log/messages until it's completed thus giving the output of 'ntpdate' all at once.
Add these two together, and you get a TARDIS :D
Cheers,
Pete.
Hi guys, Thanks for your reply. I originally used the following command to synchronize time: ntpdate 192.168.0.191 but got the error: ntpdate[16715]: the NTP socket is in use, exiting So i used the way of stopping ntpd service. Now I have known that using command "ntpdate -u 192.168.0.191" can solve the above error, and also know using ntpdate command is an improper way, i.e. should use ntpd service instead of ntpdate command. But i have still a problem that why ntpdate command can cause backward clock? 192.168.0.191 is a valid ntpd server, its clock should not go backward, why the clock gotten by its client can go backwards?
On 2/11/2015 11:12 PM, David chen wrote:
Hi guys, Thanks for your reply. I originally used the following command to synchronize time: ntpdate 192.168.0.191 but got the error: ntpdate[16715]: the NTP socket is in use, exiting So i used the way of stopping ntpd service. Now I have known that using command "ntpdate -u 192.168.0.191" can solve the above error, and also know using ntpdate command is an improper way, i.e. should use ntpd service instead of ntpdate command. But i have still a problem that why ntpdate command can cause backward clock? 192.168.0.191 is a valid ntpd server, its clock should not go backward, why the clock gotten by its client can go backwards?
what ntp server is your ntpd synchronized to, and what is its time reference?
if that 192.168.0.191 is your internal name server, you should edit /etc/ntp.conf and replace all teh server statements with one, 'server 192.168.0.191', then restart ntpd and get rid of your cron job. wait about an hour, and try `ntpstat`
I've seen situations where people have put ntpdate in a cronjob to get around issues with big time jumps at boot or dodgy clocks under virtualization. There are much better solutions to this problem, so let us know if this is the case for you.
K
On 2/11/2015 11:47 PM, Kahlil Hodgson wrote:
I've seen situations where people have put ntpdate in a cronjob to get around issues with big time jumps at boot or dodgy clocks under virtualization. There are much better solutions to this problem, so let us know if this is the case for you.
NOT compatible with running ntpd!!!
I've seen situations where people have put ntpdate in a cronjob to get around issues with big time jumps at boot or dodgy clocks under virtualization. There are much better solutions to this problem, so let us know if this is the case for you.
put "tinker panic 0" in your ntp.conf.
This stops ntpd from throwing a wobbly if it sees large jumps in time and will keep clocks in virtualised environments ticking along.
Hi guys, I don't use virtual machine. The 192.168.0.191 is an internal ntpd server configured by administrator, so i can not see what ntp server it synchronizes to or what is its time reference. But i have added a new line "server 192.168.0.191" into file "/etc/ntp.conf" on ntpd client machines, and the output to execute command ntpstat is as follows: synchronised to NTP server (192.168.0.191) at stratum 3 time correct to within 80 ms polling server every 128 s
Is it an proper way to synchronize clock?
On 2/12/2015 12:27 AM, David chen wrote:
i have added a new line "server 192.168.0.191" into file "/etc/ntp.conf" on ntpd client machines, and the output to execute command ntpstat is as follows: synchronised to NTP server (192.168.0.191) at stratum 3 time correct to within 80 ms polling server every 128 s
Is it an proper way to synchronize clock?
yup, its working great. over the next week or so, it will probably get even more accurate, and start polling at longer intervals.
-
Andrew Holway -
David chen -
John R Pierce -
Jonathan Billings -
Kahlil Hodgson -
Peter Lawler