FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 08-12-2010, 11:36 AM
"Simon Billis"
 
Default Date drift and ntpd

Jason Pyeron sent a missive on*2010-08-12:

> We have a local time server and all of our machines are pointed at it
> for the time.
>
> How can the clock drift by a day and a half?
>
> [root@devserver21 ~]# date
> Fri Aug 13 14:43:29 EDT 2010
> [root@devserver21 ~]# rdate -s 192.168.1.67
> [root@devserver21 ~]# date
> Thu Aug 12 07:02:39 EDT 2010
> [root@devserver21 ~]# cat /etc/ntp.conf | grep -v ^# | grep -v ^$
> restrict default nomodify notrap noquery restrict 127.0.0.1 server
> 192.168.1.67 server 192.168.1.66 server 192.168.1.65
> server 127.127.1.0 # local clock
> fudge 127.127.1.0 stratum 10
> driftfile /var/lib/ntp/drift
> broadcastdelay 0.008
> keys /etc/ntp/keys
>
>

Hi,

It is unlikely that the machine in question drifted forward in time if ntpd
was running. Have a look at the logs /var/log/messages it should contain the
ntpd log messages which will help you determine what happened to the time.
Also check that ntpd is running with:

"service ntpd status" and also "chkconfig ntpd --list" will show the startup
position of ntpd


HTH

Simon.





_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-12-2010, 12:01 PM
"Jason Pyeron"
 
Default Date drift and ntpd

> -----Original Message-----
> From: centos-bounces@centos.org
> [mailto:centos-bounces@centos.org] On Behalf Of Simon Billis
> Sent: Thursday, August 12, 2010 7:36
> To: 'CentOS mailing list'
> Subject: Re: [CentOS] Date drift and ntpd
>
> Jason Pyeron sent a missive on*2010-08-12:
>
> > We have a local time server and all of our machines are
> pointed at it
> > for the time.
> >
> > How can the clock drift by a day and a half?
> >
> > [root@devserver21 ~]# date
> > Fri Aug 13 14:43:29 EDT 2010
> > [root@devserver21 ~]# rdate -s 192.168.1.67
> > [root@devserver21 ~]# date
> > Thu Aug 12 07:02:39 EDT 2010
> > [root@devserver21 ~]# cat /etc/ntp.conf | grep -v ^# | grep -v ^$
> > restrict default nomodify notrap noquery restrict 127.0.0.1 server
> > 192.168.1.67 server 192.168.1.66 server 192.168.1.65
> > server 127.127.1.0 # local clock
> > fudge 127.127.1.0 stratum 10
> > driftfile /var/lib/ntp/drift
> > broadcastdelay 0.008
> > keys /etc/ntp/keys
> >
> >
>
> Hi,
>
> It is unlikely that the machine in question drifted forward
> in time if ntpd was running. Have a look at the logs
> /var/log/messages it should contain the ntpd log messages

[root@devserver21 ~]# grep ntpd /var/log/messages
</snip>
Jul 28 20:34:41 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 28 21:08:00 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 28 21:08:00 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:08:11 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 28 21:24:58 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 28 21:41:26 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 28 21:42:16 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 28 21:42:16 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:42:34 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:43:37 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:44:41 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:45:44 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:46:45 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:47:50 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:48:55 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:49:57 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:50:59 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:52:03 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:53:05 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:54:06 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:55:10 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:56:13 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:57:16 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:58:20 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 21:59:23 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:00:28 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:01:32 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:02:35 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:03:38 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:04:41 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:05:44 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:06:49 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:07:53 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:08:57 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:10:00 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:11:03 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:12:07 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:13:13 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:14:17 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:15:11 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 28 22:31:41 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 28 22:31:41 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 22:31:59 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 28 23:05:10 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 28 23:05:10 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
tolerance 500 PPM
Jul 28 23:06:05 devserver21 ntpd[3475]: time reset +0.554019 s
Jul 28 23:10:14 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 28 23:17:36 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 28 23:20:46 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 28 23:22:52 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 28 23:33:28 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 28 23:34:37 devserver21 ntpd[3475]: time reset -0.866445 s
Jul 28 23:38:49 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 28 23:43:01 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 28 23:44:03 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 00:00:57 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 00:25:53 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 00:41:48 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 00:42:45 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 00:42:44 devserver21 ntpd[3475]: time reset -0.922073 s
Jul 29 00:46:58 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 00:57:27 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 01:07:55 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 01:57:05 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 02:13:48 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 02:13:52 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 02:30:31 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 03:03:59 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 03:04:00 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 03:04:00 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 03:37:21 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 04:10:46 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 04:44:06 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 05:00:48 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 05:00:52 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 05:17:30 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 05:34:13 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 06:24:16 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 06:40:59 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 07:30:59 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 07:47:42 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 07:47:53 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 08:04:23 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 08:37:47 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 08:37:58 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 09:11:03 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 09:27:43 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 09:27:44 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 09:28:00 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 10:17:40 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 10:50:57 devserver21 ntpd[3475]: time reset -1.638135 s
Jul 29 10:55:08 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 10:58:17 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 10:59:16 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 11:07:41 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 11:11:57 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 11:13:58 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 11:19:00 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 11:21:19 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 11:29:46 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 11:39:57 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 11:41:56 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 11:44:23 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 12:03:03 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 12:05:19 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 12:23:28 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 12:27:48 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 13:34:13 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 13:51:08 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 14:03:08 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 14:07:42 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 14:23:56 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 14:40:29 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 14:57:07 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 14:57:27 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 15:13:40 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 15:14:01 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 15:26:05 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 15:59:17 devserver21 ntpd[3475]: time reset -1.599691 s
Jul 29 16:03:31 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 16:05:38 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 16:08:46 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 16:11:55 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 16:12:59 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 16:15:00 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 16:28:32 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 16:41:10 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 16:57:35 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
Jul 29 17:23:57 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
Jul 29 17:24:59 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Jul 29 17:30:46 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
Jul 29 17:47:24 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
Aug 12 22:48:29 devserver21 ntpd[3475]: sendto(192.168.1.66): Operation not
permitted
[root@devserver21 ~]# uptime
08:10:19 up 164 days, 9:56, 2 users, load average: 0.20, 0.54, 0.81
[root@devserver21 ~]#

> which will help you determine what happened to the time.
> Also check that ntpd is running with:
>
> "service ntpd status" and also "chkconfig ntpd --list" will
> show the startup position of ntpd
>

It is/was up.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-12-2010, 12:14 PM
"Simon Billis"
 
Default Date drift and ntpd

Hi,

> > Jason Pyeron sent a missive on*2010-08-12:
> >
> > > We have a local time server and all of our machines are
> > pointed at it
> > > for the time.
> > >
> > > How can the clock drift by a day and a half?
> > >
> > > [root@devserver21 ~]# date
> > > Fri Aug 13 14:43:29 EDT 2010
> > > [root@devserver21 ~]# rdate -s 192.168.1.67
> > > [root@devserver21 ~]# date
> > > Thu Aug 12 07:02:39 EDT 2010
> > > [root@devserver21 ~]# cat /etc/ntp.conf | grep -v ^# | grep -v ^$
> > > restrict default nomodify notrap noquery restrict 127.0.0.1 server
> > > 192.168.1.67 server 192.168.1.66 server 192.168.1.65
> > > server 127.127.1.0 # local clock
> > > fudge 127.127.1.0 stratum 10
> > > driftfile /var/lib/ntp/drift
> > > broadcastdelay 0.008
> > > keys /etc/ntp/keys
> > >
> > >
> >
> > Hi,
> >
> > It is unlikely that the machine in question drifted forward
> > in time if ntpd was running. Have a look at the logs
> > /var/log/messages it should contain the ntpd log messages
>
> [root@devserver21 ~]# grep ntpd /var/log/messages
> </snip>
/SNIP
> Jul 29 17:47:24 devserver21 ntpd[3475]: synchronized to LOCAL(0),
> stratum 10
> Aug 12 22:48:29 devserver21 ntpd[3475]: sendto(192.168.1.66): Operation
> not
> permitted
> [root@devserver21 ~]# uptime
> 08:10:19 up 164 days, 9:56, 2 users, load average: 0.20, 0.54, 0.81
> [root@devserver21 ~]#

What happened between July 29 and now? Is there nothing in the logs for that
period?

Rgds

S.





_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-12-2010, 12:24 PM
"Simon Billis"
 
Default Date drift and ntpd

Hi,

> > Jason Pyeron sent a missive on*2010-08-12:
> >
> > > We have a local time server and all of our machines are
> > pointed at it
> > > for the time.
> > >
> > > How can the clock drift by a day and a half?
> >
/SNIP
> > It is unlikely that the machine in question drifted forward
> > in time if ntpd was running. Have a look at the logs
> > /var/log/messages it should contain the ntpd log messages
>
> [root@devserver21 ~]# grep ntpd /var/log/messages
> </snip>
> Jul 28 20:34:41 devserver21 ntpd[3475]: synchronized to 192.168.1.65,
> stratum 3
> Jul 28 21:08:00 devserver21 ntpd[3475]: synchronized to LOCAL(0),
> stratum 10
> Jul 28 21:08:00 devserver21 ntpd[3475]: frequency error -512 PPM
> exceeds
> tolerance 500 PPM

This indicates the hardware clock frequency error exceeds the rate the
kernel can correct. This could be a hardware or a kernel problem.

/SNIP
> Jul 28 23:06:05 devserver21 ntpd[3475]: time reset +0.554019 s
> Jul 28 23:10:14 devserver21 ntpd[3475]: synchronized to LOCAL(0),
> stratum 10
> Jul 28 23:17:36 devserver21 ntpd[3475]: synchronized to 192.168.1.67,
> stratum 3
> Jul 28 23:20:46 devserver21 ntpd[3475]: synchronized to 192.168.1.66,
> stratum 3
> Jul 28 23:22:52 devserver21 ntpd[3475]: synchronized to 192.168.1.65,
> stratum 3
> Jul 28 23:33:28 devserver21 ntpd[3475]: synchronized to 192.168.1.65,
> stratum 3
> Jul 28 23:34:37 devserver21 ntpd[3475]: time reset -0.866445 s
/SNIP
> Jul 29 00:42:44 devserver21 ntpd[3475]: time reset -0.922073 s
/SNIP
> Jul 29 10:50:57 devserver21 ntpd[3475]: time reset -1.638135 s
/SNIP
> Jul 29 15:59:17 devserver21 ntpd[3475]: time reset -1.599691 s
/SNIP

The above lines show that the time on the server was gaining slightly - but
this could be caused by the stratum 3 server losing time slightly due to
loading issues perhaps or by a hardware fault locally


> Aug 12 22:48:29 devserver21 ntpd[3475]: sendto(192.168.1.66): Operation
> not
> permitted

I suspect that you have a firewall in place that is blocking the outgoing
connections from this point.

Rgds

S.




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-12-2010, 12:25 PM
"Jason Pyeron"
 
Default Date drift and ntpd

> -----Original Message-----
> From: centos-bounces@centos.org
> [mailto:centos-bounces@centos.org] On Behalf Of Simon Billis
> Sent: Thursday, August 12, 2010 8:14
> To: 'CentOS mailing list'
> Subject: Re: [CentOS] Date drift and ntpd
>
> Hi,
>
> > > Jason Pyeron sent a missive on*2010-08-12:
> > >
> > > > We have a local time server and all of our machines are
> > > pointed at it
> > > > for the time.
> > > >
> > > > How can the clock drift by a day and a half?
> > > >
> > > > [root@devserver21 ~]# date
> > > > Fri Aug 13 14:43:29 EDT 2010
> > > > [root@devserver21 ~]# rdate -s 192.168.1.67
> > > > [root@devserver21 ~]# date
> > > > Thu Aug 12 07:02:39 EDT 2010
> > > > [root@devserver21 ~]# cat /etc/ntp.conf | grep -v ^# |
> grep -v ^$
> > > > restrict default nomodify notrap noquery restrict
> 127.0.0.1 server
> > > > 192.168.1.67 server 192.168.1.66 server 192.168.1.65
> > > > server 127.127.1.0 # local clock
> > > > fudge 127.127.1.0 stratum 10
> > > > driftfile /var/lib/ntp/drift
> > > > broadcastdelay 0.008
> > > > keys /etc/ntp/keys
> > > >
> > > >
> > >
> > > Hi,
> > >
> > > It is unlikely that the machine in question drifted
> forward in time
> > > if ntpd was running. Have a look at the logs /var/log/messages it
> > > should contain the ntpd log messages
> >
> > [root@devserver21 ~]# grep ntpd /var/log/messages </snip>
> /SNIP
> > Jul 29 17:47:24 devserver21 ntpd[3475]: synchronized to LOCAL(0),
> > stratum 10 Aug 12 22:48:29 devserver21 ntpd[3475]:
> > sendto(192.168.1.66): Operation not permitted
> > [root@devserver21 ~]# uptime
> > 08:10:19 up 164 days, 9:56, 2 users, load average: 0.20, 0.54,
> > 0.81
> > [root@devserver21 ~]#
>
> What happened between July 29 and now? Is there nothing in
> the logs for that period?
>

Nothing of note, I do have full logs from those days...
[root@devserver21 ~]# grep ' 00:00:.. devserver21 arpwatch: bogon 192.168.1.67
0:30:67:0:cf:fd' /var/log/messages
Jul 26 00:00:37 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Jul 27 00:00:47 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Jul 28 00:00:44 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Jul 29 00:00:41 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Jul 30 00:00:08 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Jul 31 00:00:08 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 1 00:00:14 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 2 00:00:22 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 3 00:00:11 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 4 00:00:58 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 5 00:00:06 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 6 00:00:06 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 7 00:00:03 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 8 00:00:43 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 9 00:00:16 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 10 00:00:08 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 11 00:00:34 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 12 00:00:19 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
Aug 13 00:00:20 devserver21 arpwatch: bogon 192.168.1.67 0:30:67:0:cf:fd
[root@devserver21 ~]#

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-12-2010, 01:06 PM
Todd Denniston
 
Default Date drift and ntpd

Jason Pyeron wrote, On 08/12/2010 08:01 AM:
>
>
>> -----Original Message-----
>> From: centos-bounces@centos.org
>> [mailto:centos-bounces@centos.org] On Behalf Of Simon Billis
>> Sent: Thursday, August 12, 2010 7:36
>> To: 'CentOS mailing list'
>> Subject: Re: [CentOS] Date drift and ntpd
>>
>> Jason Pyeron sent a missive on 2010-08-12:
>>
>>> We have a local time server and all of our machines are
>> pointed at it
>>> for the time.
>>>
>>> How can the clock drift by a day and a half?
>>>
>>> [root@devserver21 ~]# date
>>> Fri Aug 13 14:43:29 EDT 2010
>>> [root@devserver21 ~]# rdate -s 192.168.1.67
>>> [root@devserver21 ~]# date
>>> Thu Aug 12 07:02:39 EDT 2010
>>> [root@devserver21 ~]# cat /etc/ntp.conf | grep -v ^# | grep -v ^$
>>> restrict default nomodify notrap noquery restrict 127.0.0.1 server
>>> 192.168.1.67 server 192.168.1.66 server 192.168.1.65
>>> server 127.127.1.0 # local clock
>>> fudge 127.127.1.0 stratum 10
>>> driftfile /var/lib/ntp/drift
>>> broadcastdelay 0.008
>>> keys /etc/ntp/keys
>>>
>>>
>> Hi,
>>
>> It is unlikely that the machine in question drifted forward
>> in time if ntpd was running. Have a look at the logs
>> /var/log/messages it should contain the ntpd log messages
>
> [root@devserver21 ~]# grep ntpd /var/log/messages
> </snip>
> Jul 28 20:34:41 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
> Jul 28 21:08:00 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
> Jul 28 21:08:00 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
> tolerance 500 PPM
> Jul 28 21:08:11 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
> Jul 28 21:24:58 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
> Jul 28 21:41:26 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
> Jul 28 21:42:16 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
> Jul 28 21:42:16 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
> tolerance 500 PPM
> Jul 28 21:42:34 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
> tolerance 500 PPM
> Jul 28 21:43:37 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
> tolerance 500 PPM

> tolerance 500 PPM
> Jul 28 22:12:07 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
> tolerance 500 PPM
> Jul 28 22:13:13 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
> tolerance 500 PPM
> Jul 28 22:14:17 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
> tolerance 500 PPM
> Jul 28 22:15:11 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
> Jul 28 22:31:41 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
> Jul 28 22:31:41 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
> tolerance 500 PPM

> Jul 29 15:14:01 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
> Jul 29 15:26:05 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
> Jul 29 15:59:17 devserver21 ntpd[3475]: time reset -1.599691 s
> Jul 29 16:03:31 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
> Jul 29 16:05:38 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
> Jul 29 16:08:46 devserver21 ntpd[3475]: synchronized to 192.168.1.66, stratum 3
> Jul 29 16:11:55 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3

> Jul 29 17:23:57 devserver21 ntpd[3475]: synchronized to 192.168.1.67, stratum 3
> Jul 29 17:24:59 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
> Jul 29 17:30:46 devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
> Jul 29 17:47:24 devserver21 ntpd[3475]: synchronized to LOCAL(0), stratum 10
> Aug 12 22:48:29 devserver21 ntpd[3475]: sendto(192.168.1.66): Operation not
> permitted
> [root@devserver21 ~]# uptime
> 08:10:19 up 164 days, 9:56, 2 users, load average: 0.20, 0.54, 0.81
> [root@devserver21 ~]#

Assumption: this is not from any kind of virtual machine.
Assumption: Your local time server is NOT a GPS with an ovenized crystal or even a cell phone time
source, i.e. NOT very stable.
Assumption: the time servers that you are following (192.168.1.6[57]) are:
a) each following the same timeserver(s), or at least have one in common.
b) peering with one another
c) following time servers that are reasonably stable.
Assumption: the time farm is on real, non busy (an old cisco router serving as the internet
connection to 1000+ computers does not qualify as non busy), hardware and is configured to archive
maxpoll 10 or higher.

one problem that you have is that your timeserver farm (192.168.1.6[57]) is occasionally loosing its
servers, i.e. we see "synchronized to LOCAL(0)" occasionally, which should not happen with a well
configured time farm for hours to days, not minutes.

the second problem is that a machine which is not intended to be a time server is configured with a
local clock with a stratum better than 15.

suggestion 1: 65 should have local clock at stratum 13, 66 and 67 should have local clock at stratum
14 or 15, all other machines should not have a local clock or should not have one with a stratum
better than 15. Yes I, after reading the ntp documentation, disagree with RedHat's default.
net result should be that you don't get any local clock loops in the setup because you have a
defined leader, but if even the defined leader is lost the other machines should do a stable drift.

suggestion 2: 65, 66 & 67 should ALL peer with one another for added stability in the time farm.

suggestion 3: client machines should 'prefer' one of your servers over the others.

suggestion 4: see if someone has been messing with the kernel ticks on the machine...
run `tickadj` file:///usr/share/doc/ntp-4.2.2p1/tickadj.html
I had one computer where I needed to tweak the default value up or down one (I don't remember) to
have it be real stable, this should be a last resort.


--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-12-2010, 01:27 PM
"Jason Pyeron"
 
Default Date drift and ntpd

> -----Original Message-----
> From: Todd Denniston
> Sent: Thursday, August 12, 2010 9:07
> Jason Pyeron wrote, On 08/12/2010 08:01 AM:
> >> -----Original Message-----
> >> From: Simon Billis
> >> Sent: Thursday, August 12, 2010 7:36
> >>
> >> Jason Pyeron sent a missive on 2010-08-12:
> >>
> >>> We have a local time server and all of our machines are
> >> pointed at it
> >>> for the time.
> >>>
> >>> How can the clock drift by a day and a half?
> >>>
> >>> [root@devserver21 ~]# date
> >>> Fri Aug 13 14:43:29 EDT 2010
> >>> [root@devserver21 ~]# rdate -s 192.168.1.67
> >>> [root@devserver21 ~]# date
> >>> Thu Aug 12 07:02:39 EDT 2010
> >>> [root@devserver21 ~]# cat /etc/ntp.conf | grep -v ^# | grep -v ^$
> >>> restrict default nomodify notrap noquery restrict 127.0.0.1 server
> >>> 192.168.1.67 server 192.168.1.66 server 192.168.1.65
> >>> server 127.127.1.0 # local clock
> >>> fudge 127.127.1.0 stratum 10
> >>> driftfile /var/lib/ntp/drift
> >>> broadcastdelay 0.008
> >>> keys /etc/ntp/keys
> >>>
> >>>
> >> Hi,
> >>
> >> It is unlikely that the machine in question drifted
> forward in time
> >> if ntpd was running. Have a look at the logs /var/log/messages it
> >> should contain the ntpd log messages
> >
> > [root@devserver21 ~]# grep ntpd /var/log/messages </snip> Jul 28
> > 20:34:41 devserver21 ntpd[3475]: synchronized to
> 192.168.1.65, stratum
> > 3 Jul 28 21:08:00 devserver21 ntpd[3475]: synchronized to LOCAL(0),
> > stratum 10 Jul 28 21:08:00 devserver21 ntpd[3475]: frequency error
> > -512 PPM exceeds tolerance 500 PPM Jul 28 21:08:11 devserver21
> > ntpd[3475]: synchronized to 192.168.1.66, stratum 3 Jul 28 21:24:58
> > devserver21 ntpd[3475]: synchronized to 192.168.1.65,
> stratum 3 Jul 28
> > 21:41:26 devserver21 ntpd[3475]: synchronized to
> 192.168.1.67, stratum
> > 3 Jul 28 21:42:16 devserver21 ntpd[3475]: synchronized to LOCAL(0),
> > stratum 10 Jul 28 21:42:16 devserver21 ntpd[3475]: frequency error
> > -512 PPM exceeds tolerance 500 PPM Jul 28 21:42:34 devserver21
> > ntpd[3475]: frequency error -512 PPM exceeds tolerance 500
> PPM Jul 28
> > 21:43:37 devserver21 ntpd[3475]: frequency error -512 PPM exceeds
> > tolerance 500 PPM
>
> > tolerance 500 PPM
> > Jul 28 22:12:07 devserver21 ntpd[3475]: frequency error -512 PPM
> > exceeds tolerance 500 PPM Jul 28 22:13:13 devserver21 ntpd[3475]:
> > frequency error -512 PPM exceeds tolerance 500 PPM Jul 28 22:14:17
> > devserver21 ntpd[3475]: frequency error -512 PPM exceeds
> tolerance 500
> > PPM Jul 28 22:15:11 devserver21 ntpd[3475]: synchronized to
> > 192.168.1.66, stratum 3 Jul 28 22:31:41 devserver21 ntpd[3475]:
> > synchronized to LOCAL(0), stratum 10 Jul 28 22:31:41 devserver21
> > ntpd[3475]: frequency error -512 PPM exceeds tolerance 500 PPM
>
> > Jul 29 15:14:01 devserver21 ntpd[3475]: synchronized to LOCAL(0),
> > stratum 10 Jul 29 15:26:05 devserver21 ntpd[3475]: synchronized to
> > 192.168.1.65, stratum 3 Jul 29 15:59:17 devserver21
> ntpd[3475]: time
> > reset -1.599691 s Jul 29 16:03:31 devserver21 ntpd[3475]:
> synchronized
> > to LOCAL(0), stratum 10 Jul 29 16:05:38 devserver21 ntpd[3475]:
> > synchronized to 192.168.1.67, stratum 3 Jul 29 16:08:46 devserver21
> > ntpd[3475]: synchronized to 192.168.1.66, stratum 3 Jul 29 16:11:55
> > devserver21 ntpd[3475]: synchronized to 192.168.1.65, stratum 3
>
> > Jul 29 17:23:57 devserver21 ntpd[3475]: synchronized to
> 192.168.1.67,
> > stratum 3 Jul 29 17:24:59 devserver21 ntpd[3475]: synchronized to
> > LOCAL(0), stratum 10 Jul 29 17:30:46 devserver21 ntpd[3475]:
> > synchronized to 192.168.1.65, stratum 3 Jul 29 17:47:24 devserver21
> > ntpd[3475]: synchronized to LOCAL(0), stratum 10 Aug 12 22:48:29
> > devserver21 ntpd[3475]: sendto(192.168.1.66): Operation not
> permitted
> > [root@devserver21 ~]# uptime
> > 08:10:19 up 164 days, 9:56, 2 users, load average: 0.20, 0.54,
> > 0.81
> > [root@devserver21 ~]#
>
> Assumption: this is not from any kind of virtual machine.

Correct.

> Assumption: Your local time server is NOT a GPS with an
> ovenized crystal or even a cell phone time source, i.e. NOT
> very stable.

Correct.

> Assumption: the time servers that you are following
> (192.168.1.6[57]) are:
> a) each following the same timeserver(s), or at least
> have one in common.

192.168.1.6[567] are one machine. Time on that one is/has been good. Other
machines in the enterprise follow it accurately.

> b) peering with one another

n/a

> c) following time servers that are reasonably stable.

Appears to be so.

> Assumption: the time farm is on real, non busy (an old cisco
> router serving as the internet connection to 1000+ computers
> does not qualify as non busy), hardware and is configured to
> archive maxpoll 10 or higher.

Unknown, assuming the latency is neglibile. The important detail here is that
all the machines in the lan have the same time. There is no unusual latency
there.

>
> one problem that you have is that your timeserver farm
> (192.168.1.6[57]) is occasionally loosing its servers, i.e.
> we see "synchronized to LOCAL(0)" occasionally, which should

That was on a ntp client, not the ntp server. Am I misunderstanting you?

> not happen with a well configured time farm for hours to
> days, not minutes.

Agreed, see above.

>
> the second problem is that a machine which is not intended to
> be a time server is configured with a local clock with a
> stratum better than 15.
>

I don't understand, I will have to read up more.

> suggestion 1: 65 should have local clock at stratum 13, 66
> and 67 should have local clock at stratum

They are presently one machine.

> 14 or 15, all other machines should not have a local clock or
> should not have one with a stratum better than 15. Yes I,
> after reading the ntp documentation, disagree with RedHat's default.

Ok.

> net result should be that you don't get any local clock loops
> in the setup because you have a defined leader, but if even
> the defined leader is lost the other machines should do a
> stable drift.
>
> suggestion 2: 65, 66 & 67 should ALL peer with one another
> for added stability in the time farm.
>
> suggestion 3: client machines should 'prefer' one of your
> servers over the others.
>
> suggestion 4: see if someone has been messing with the kernel
> ticks on the machine...
> run `tickadj` file:///usr/share/doc/ntp-4.2.2p1/tickadj.html

[root@devserver21 ~]# tickadj
tick = 10000

> I had one computer where I needed to tweak the default value
> up or down one (I don't remember) to have it be real stable,
> this should be a last resort.
>
>
> --
> Todd Denniston
> Crane Division, Naval Surface Warfare Center (NSWC Crane)
> Harnessing the Power of Technology for the Warfighter
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>



--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-12-2010, 09:41 PM
Warren Young
 
Default Date drift and ntpd

On 8/12/2010 5:07 AM, Jason Pyeron wrote:
>
> [root@devserver21 ~]# cat /etc/ntp.conf | grep -v ^# | grep -v ^$
> restrict default nomodify notrap noquery
> restrict 127.0.0.1
> server 192.168.1.67
> server 192.168.1.66
> server 192.168.1.65

Some HOWTOs tell you that more time servers is better, on a standard
knee-jerk redundancy theory, but they're ignoring two things.

First, you already have a fallback: the system's built-in clock. It's
perfectly fine to run on that while you ride out your time server's
downtime.

Second, ntpd, internally, is built on a phase-locked loop, which is
supposed to stabilize its time corrections in the face of jitter and
other bad things out in the real world. Like anything based on a
negative feedback loop, however, it can be destablized with certain
inputs. Giving ntpd two or more servers is a pretty good way to
destabilize its PLL in the real, non-ideal world we find on the modern
Internet.

To anyone considering flaming me, please read this first:

http://queue.acm.org/detail.cfm?id=1773943

At minimum, read the section "One server is enough". The bit on PLLs
about halfway down is also directly relevant.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-12-2010, 09:43 PM
"Jason Pyeron"
 
Default Date drift and ntpd

> -----Original Message-----
> From: centos-bounces@centos.org
> [mailto:centos-bounces@centos.org] On Behalf Of Warren Young
> Sent: Thursday, August 12, 2010 17:41
> To: CentOS mailing list
> Subject: Re: [CentOS] Date drift and ntpd
>
> On 8/12/2010 5:07 AM, Jason Pyeron wrote:
> >
> > [root@devserver21 ~]# cat /etc/ntp.conf | grep -v ^# | grep -v ^$
> > restrict default nomodify notrap noquery restrict 127.0.0.1 server
> > 192.168.1.67 server 192.168.1.66 server 192.168.1.65
>
> Some HOWTOs tell you that more time servers is better, on a
> standard knee-jerk redundancy theory, but they're ignoring two things.
>
> First, you already have a fallback: the system's built-in
> clock. It's perfectly fine to run on that while you ride out
> your time server's downtime.
>
> Second, ntpd, internally, is built on a phase-locked loop,
> which is supposed to stabilize its time corrections in the
> face of jitter and other bad things out in the real world.
> Like anything based on a negative feedback loop, however, it
> can be destablized with certain inputs. Giving ntpd two or
> more servers is a pretty good way to destabilize its PLL in
> the real, non-ideal world we find on the modern Internet.
>
> To anyone considering flaming me, please read this first:
>
> http://queue.acm.org/detail.cfm?id=1773943
>
> At minimum, read the section "One server is enough". The bit
> on PLLs about halfway down is also directly relevant.

Okay, I only have one timeserver, but the ntp clients cowardly refuse to use
less than 3. Back to the man page...



--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-12-2010, 09:51 PM
Warren Young
 
Default Date drift and ntpd

On 8/12/2010 3:43 PM, Jason Pyeron wrote:
>
> Okay, I only have one timeserver,

I meant that your on-site time server should be relying on only one
other outside time server, one stratum up.

> but the ntp clients cowardly refuse to use
> less than 3.

Only one server on a given LAN should be running ntpd. It's overkill
for every machine to keep themselves synced with such a complex and
fussy server. All the others should just call ntpdate or msntp every
hour or so as a cron job to keep their own time close to that of the LAN
time server's.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 08:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org