Cant get time correctly syncd

jonaskellens · 09-26-2012, 07:14 AM

Hello,

I do the following on my CentOS server :

bash-3.2# rm /etc/localtime

bash-3.2# ln -s /usr/share/zoneinfo/Europe/Brussels /etc/localtime

bash-3.2# /usr/sbin/ntpdate 0.be.pool.ntp.org

I get time :
26 Sep 14:09:52 ntpdate[2074]: step time server 193.104.37.238 offset 133.148363 sec

While time should be :
wo sep 26 14:12:18 CEST 2012
(correct time on my Acer Fedora laptop)

There is more than 2 minutes difference. How come ??

pan64 · 09-26-2012, 07:21 AM

in such cases I would try it several times and also with several ntp servers.

Habitual · 09-26-2012, 10:33 AM

my CentOS bacula host has this cron entry:

Code:

*/15 * * * * ntpdate pool.ntp.org

to correct a TZ "drift".

segmentation_fault · 09-26-2012, 11:16 AM

You could also try ntpd which continuously syncs the time.

michaelk · 09-26-2012, 11:18 AM

Quote:

Originally Posted by Habitual

my CentOS bacula host has this cron entry:

Code:

*/15 * * * * ntpdate pool.ntp.org

to correct a TZ "drift".

Not really the best method. Running ntpdate via cron will just force a clock correction but will not compensate for drift. By running NTP the system clock drift error will be calculated and it can maintain synchronization nominally within one millisecond.

jonaskellens,
The time in the message is not the corrected time. Your offset was 133 seconds which is 2 minutes 13 seconds which if your Fedora laptop was time synched should be reasonable. Run the date command on both computers again or compare the times on the desktop if running a GUI.

jonaskellens · 09-27-2012, 02:28 AM

Date on Fedora laptop :

[Jonas@jonas ~]$ date
do sep 27 09:25:27 CEST 2012

Date on CentOS server before sync :

bash-3.2# date
do sep 27 09:23:20 CEST 2012

Date on CentOS server after sync :

bash-3.2# /usr/sbin/ntpdate pool.ntp.org
27 Sep 09:23:27 ntpdate[17983]: step time server 83.98.201.134 offset 130.359327 sec
bash-3.2# /usr/sbin/ntpdate 0.be.pool.ntp.org
27 Sep 09:23:32 ntpdate[17984]: step time server 91.183.56.68 offset 130.356664 sec
bash-3.2# date
do sep 27 09:23:34 CEST 2012

Date on Fedora on laptop :

[Jonas@jonas ~]$ date
do sep 27 09:25:50 CEST 2012

Still a difference...

pan64 · 09-27-2012, 02:48 AM

Can you try to change the time by hand, and run ntpdate again?

michaelk · 09-27-2012, 07:08 AM

Is the Fedora laptop running ntp or are you using ntpdate?

Post the output using the -d option
ntpdate -d pool.ntp.org

ermoreno · 09-27-2012, 07:58 AM

There is another file I usually modify on my systems.

[root@Blah sysconfig]# cat /etc/sysconfig/clock
ZONE="America/Chicago"
UTC=true
ARC=false

jonaskellens · 09-28-2012, 03:27 AM

bash-3.2# cat /etc/sysconfig/clock
# The ZONE parameter is only evaluated by system-config-date.
# The timezone of the system is defined by the contents of /etc/localtime.
ZONE="Europe/Brussels"
UTC=false
ARC=false

bash-3.2# /usr/sbin/ntpdate -d pool.ntp.org
28 Sep 10:23:36 ntpdate[8283]: ntpdate 4.2.2p1@1.1570-o Fri Nov 18 13:21:21 UTC 2011 (1)
Looking for host pool.ntp.org and service ntp
host found : sip.dicode.nl
transmit(91.148.192.49)
receive(91.148.192.49)
transmit(91.148.192.49)
receive(91.148.192.49)
transmit(91.148.192.49)
receive(91.148.192.49)
transmit(91.148.192.49)
receive(91.148.192.49)
transmit(91.148.192.49)
transmit(83.98.201.134)
receive(83.98.201.134)
transmit(83.98.201.134)
receive(83.98.201.134)
transmit(83.98.201.134)
receive(83.98.201.134)
transmit(83.98.201.134)
receive(83.98.201.134)
transmit(83.98.201.134)
transmit(213.154.229.24)
receive(213.154.229.24)
transmit(213.154.229.24)
receive(213.154.229.24)
transmit(213.154.229.24)
receive(213.154.229.24)
transmit(213.154.229.24)
receive(213.154.229.24)
transmit(213.154.229.24)
transmit(213.136.0.252)
receive(213.136.0.252)
transmit(213.136.0.252)
receive(213.136.0.252)
transmit(213.136.0.252)
receive(213.136.0.252)
transmit(213.136.0.252)
receive(213.136.0.252)
transmit(213.136.0.252)
server 91.148.192.49, port 123
stratum 2, precision -20, leap 00, trust 000
refid [91.148.192.49], delay 0.02696, dispersion 0.00006
transmitted 4, in filter 4
reference time: d40fd680.e5f50090 Fri, Sep 28 2012 9:55:44.898
originate timestamp: d40fdd87.2e4616ce Fri, Sep 28 2012 10:25:43.180
transmit timestamp: d40fdd08.87605ab3 Fri, Sep 28 2012 10:23:36.528
filter delay: 0.02721 0.02707 0.02724 0.02696
0.00000 0.00000 0.00000 0.00000
filter offset: 126.6513 126.6513 126.6514 126.6512
0.000000 0.000000 0.000000 0.000000
delay 0.02696, dispersion 0.00006
offset 126.651255

server 83.98.201.134, port 123
stratum 2, precision -20, leap 01, trust 000
refid [83.98.201.134], delay 0.02678, dispersion 0.00000
transmitted 4, in filter 4
reference time: d40fdd1b.ae14abe2 Fri, Sep 28 2012 10:23:55.680
originate timestamp: d40fdd87.6126b311 Fri, Sep 28 2012 10:25:43.379
transmit timestamp: d40fdd08.ba4b44a1 Fri, Sep 28 2012 10:23:36.727
filter delay: 0.02687 0.02681 0.02678 0.02681
0.00000 0.00000 0.00000 0.00000
filter offset: 126.6512 126.6511 126.6511 126.6511
0.000000 0.000000 0.000000 0.000000
delay 0.02678, dispersion 0.00000
offset 126.651198

server 213.154.229.24, port 123
stratum 2, precision -19, leap 00, trust 000
refid [213.154.229.24], delay 0.02748, dispersion 0.00002
transmitted 4, in filter 4
reference time: d40fdab3.50f91503 Fri, Sep 28 2012 10:13:39.316
originate timestamp: d40fdd87.952c8340 Fri, Sep 28 2012 10:25:43.582
transmit timestamp: d40fdd08.ee3a4b55 Fri, Sep 28 2012 10:23:36.930
filter delay: 0.02765 0.02780 0.02748 0.02763
0.00000 0.00000 0.00000 0.00000
filter offset: 126.6510 126.6511 126.6510 126.6510
0.000000 0.000000 0.000000 0.000000
delay 0.02748, dispersion 0.00002
offset 126.651092

server 213.136.0.252, port 123
stratum 1, precision -19, leap 00, trust 000
refid [PPS], delay 0.02750, dispersion 0.00002
transmitted 4, in filter 4
reference time: d40fdd51.7c5ca387 Fri, Sep 28 2012 10:24:49.485
originate timestamp: d40fdd87.c83685a3 Fri, Sep 28 2012 10:25:43.782
transmit timestamp: d40fdd09.215a3a08 Fri, Sep 28 2012 10:23:37.130
filter delay: 0.02780 0.02753 0.02759 0.02750
0.00000 0.00000 0.00000 0.00000
filter offset: 126.6509 126.6508 126.6508 126.6508
0.000000 0.000000 0.000000 0.000000
delay 0.02750, dispersion 0.00002
offset 126.650831

28 Sep 10:23:37 ntpdate[8283]: step time server 213.136.0.252 offset 126.650831 sec

bash-3.2# date
vr sep 28 10:23:41 CEST 2012

pan64 · 09-28-2012, 04:30 AM

I asked it: can you modify the time by hand? I think ntpdate does not set anything, just displays the offset. Try to set another offset (probably hours) and check it again

michaelk · 09-28-2012, 06:33 AM

ntpdate can be used to set the clock. With older versions of NTP it was necessary to run ntpdate first due to the fact that if the time difference was more then 1024 seconds ntp would quit assuming there was a problem.

You can force the time to be set with the -b option i.e.
ntpdate -b pool.ntp.org

jonaskellens · 09-29-2012, 03:22 AM

Forcing did not help :

Code:

bash-3.2# date
za sep 29 10:18:12 CEST 2012
bash-3.2# /usr/sbin/ntpdate -b pool.ntp.org
29 Sep 10:18:29 ntpdate[32303]: step time server 83.98.201.133 offset 123.112925 sec
bash-3.2# date
za sep 29 10:18:31 CEST 2012

There is still a difference of about 2 minutes...

michaelk · 09-29-2012, 12:12 PM

Is this a real or virtual machine?

jonaskellens · 10-01-2012, 02:43 AM

This is a VM, VMware if I'm not mistaken...

Could this be the problem ? I have never had the problem that time on the VM was dependant on the host.