CentOS - Feb 2015 - Why the command 'service ntpd stop' cause the time reversed?

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 at 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



-- 
john r pierce                                      37N 122W
somewhere on the middle of the left coast

> On Feb 11, 2015, at 8:53 PM, David chen <c77_cn at 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 at 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?