RE: NTP problem for virtual RHEL 4 server on VmWare

Hi,

I had the same problem with my RHEL 4 and 5 servers. I found the KB article from VMWare to be very helpful.

http://kb.vmware.com/kb/1006427

Regards,

--
Andre Dill
Senior Systems Administrator
DataCash

Tel (Direct): +27 (0)21 528 4618

DataCash (PTY) Ltd, No1 Waterview Park, Century City Boulevard,
Century City. 7446. Cape Town, South Africa.

Tel: ; +27 (0)21 528 4500
Fax: +27 (0)21 528 4570

www.datacash.com


-----Original Message-----
From: redhat-list-bounces@xxxxxxxxxx [mailto:redhat-list-
bounces@xxxxxxxxxx] On Behalf Of Kenneth Holter
Sent: 07 November 2008 11:49 AM
To: redhat-list@xxxxxxxxxx
Subject: NTP problem for virtual RHEL 4 server on VmWare

Hei.


One of our RHEL 4 servers running on VmWare has a quite serious NTP
problem.
I know that NTP can be an issue when running red hat boxes on VmWare,
so as
a fix I put this small script in a file in /etc/cron.hourly:


[root@server cron.hourly]# cat ntpdate
#!/bin/sh
/etc/init.d/ntpd stop
ntpdate 1.2.3.4 >> /tmp/time_adjust.log
/etc/init.d/ntp


After investigating the "/tmp/time_adjust.log" file, I was quite
surprised
by the amount of drift found on one particular server. Consider this
extract
from the file:

6 Nov 20:00:01 ntpdate[19373]: step time server 1.2.3.4 offset -
60.504153
sec
6 Nov 20:00:52 ntpdate[19666]: step time server 1.2.3.4 offset -
8.735440
sec
6 Nov 20:01:00 ntpdate[19689]: step time server 1.2.3.4 offset -
1.635632
sec
6 Nov 20:54:06 ntpdate[24198]: step time server 1.2.3.4 offset -
415.894712
sec
6 Nov 21:01:01 ntpdate[24920]: adjust time server 1.2.3.4 offset
0.136833
sec
6 Nov 22:01:02 ntpdate[29943]: adjust time server 1.2.3.4 offset -
0.114253
sec
6 Nov 23:01:01 ntpdate[2519]: adjust time server 1.2.3.4 offset -
0.036345
sec
7 Nov 00:01:00 ntpdate[7577]: step time server 1.2.3.4 offset -
1.064935 sec
7 Nov 01:00:57 ntpdate[12697]: step time server 1.2.3.4 offset -
3.922577
sec
7 Nov 02:00:21 ntpdate[17733]: step time server 1.2.3.4 offset -
40.421825
sec
7 Nov 02:01:00 ntpdate[17777]: step time server 1.2.3.4 offset -
1.123175
sec
7 Nov 02:57:23 ntpdate[22542]: step time server 1.2.3.4 offset -
218.649820
sec
7 Nov 03:00:36 ntpdate[22900]: step time server 1.2.3.4 offset -
25.284528
sec
7 Nov 03:00:58 ntpdate[22940]: step time server 1.2.3.4 offset -
3.104130
sec
7 Nov 03:52:32 ntpdate[27430]: step time server 1.2.3.4 offset -
509.363952
sec
7 Nov 03:59:50 ntpdate[27943]: step time server 1.2.3.4 offset -
71.430354
sec
7 Nov 04:00:52 ntpdate[28236]: step time server 1.2.3.4 offset -
9.344907
sec
7 Nov 04:01:00 ntpdate[28259]: step time server 1.2.3.4 offset -
1.237651
sec
7 Nov 05:01:01 ntpdate[1363]: adjust time server 1.2.3.4 offset
0.390149
sec
7 Nov 06:01:01 ntpdate[6419]: adjust time server 1.2.3.4 offset -
0.185112
sec
7 Nov 07:01:02 ntpdate[11493]: adjust time server 1.2.3.4 offset -
0.228884
sec
7 Nov 08:00:59 ntpdate[16579]: step time server 1.2.3.4 offset -
2.166519
sec
7 Nov 09:00:38 ntpdate[21522]: step time server 1.2.3.4 offset -
23.169420
sec
7 Nov 09:01:02 ntpdate[21558]: adjust time server 1.2.3.4 offset -
0.492106
sec
7 Nov 09:59:26 ntpdate[26329]: step time server 1.2.3.4 offset -
95.154264
sec
7 Nov 10:00:55 ntpdate[26639]: step time server 1.2.3.4 offset -
5.997955
sec
7 Nov 10:01:01 ntpdate[26658]: step time server 1.2.3.4 offset -
0.506367
sec


Does anyone know what may be causing the RHEL box to drift as much as
500
seconds in only one hour?

Regards,
Kenneth Holter
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

DISCLAIMER: This email and any files transmitted with it are confidential to DataCash Group plc and its group companies. It is intended only for the person to whom it is addressed. If you have received this email in error, please forward it to info@xxxxxxxxxxxx with the subject line "Received in Error". If you are not the intended recipient you must not use, disclose, copy, print, distribute or rely on this email or any transmitted files. DataCash Ltd is registered in England and Wales no. 3430157. DataCash Ltd is part of the DataCash Group plc. DataCash Group plc is registered in England and Wales no. 3168091. DataCash Ltd and DataCash Group plc registered address is Descartes House, 8 Gate Street, London, WC2A 3HP, United Kingdom.

Save a tree...Please only print this page if essential


--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

Relevant Pages

  • RE: NTP problem for virtual RHEL 4 server on VmWare
    ... NTP problem for virtual RHEL 4 server on VmWare ... NTP on the guest and just let the physical host update the guest. ... One of our RHEL 4 servers running on VmWare has a quite serious NTP ...
    (RedHat)
  • Re: NTP problem for virtual RHEL 4 server on VmWare
    ... One of our RHEL 4 servers running on VmWare has a quite serious NTP ... has to do with the frequency & adjustment history recorded by NTP. ...
    (RedHat)
  • Debian Squeeze ext4 corruption under VMware
    ... We have several Debian Squeeze servers running in VMs under VMware ESXi 4.1.0 with the latest VMware Tools bundle installed. ... We're using the ext4 filesystem on each of these servers. ... We have had a few crashes of our VMware infrastructure, and each time, the Debian servers have all suffered filesystem corruption. ...
    (Debian-User)
  • Re: Is it true that Debian does not fuck people like Fedora does
    ... So, based on some previous discussions, Debian is much more suitable. ... Fedora is not for production servers, it is by definition a permanently ... RHEL is the dominant enterprise Linux, ...
    (comp.os.linux.misc)
  • Re: Is it true that Debian does not fuck people like Fedora does
    ... So, based on some previous discussions, Debian is much more suitable. ... Fedora is not for production servers, it is by definition a permanently ... RHEL is the dominant enterprise Linux, ...
    (comp.os.linux.misc)