Hi,
I have upgraded my Dell C151 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now as I type this out. If anyone else has any links or ideas that I should check out It would be greatly appreciated.
Just a quick note about my setup. I do not use any gui. As mentioned I have not had any issues with this machine and it's time until I upgrade.
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram.
TIA.
Brian.
On 4/13/2011 7:35 AM, Mailing List wrote:
Hi,
I have upgraded my Dell C151 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now as I type this out. If anyone else has any links or ideas that I should check out It would be greatly appreciated.
Just a quick note about my setup. I do not use any gui. Asmentioned I have not had any issues with this machine and it's time until I upgrade.
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram.
TIA.
Brian.
Just to follow up, I had switched to the old kernel before the 5.6 upgrade, and at this time my clock is working flawlessly.
kernel v. 2.6.18-194.32.1.el5 Works as it should... kernel v. 2.6.18-238.5.1.el5 I cannot get my clock accurate.
If there is anything I can do to help solve this IE: information or test. please let me know.At this point I will just make the old kernel default boot until there is a kernel update where which I will try again.
Brian.
Mailing List wrote:
On 4/13/2011 7:35 AM, Mailing List wrote:
Hi,
I have upgraded my Dell C151 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now as I type this out. If anyone else has any links or ideas that I should check out It would be greatly appreciated.
Just a quick note about my setup. I do not use any gui. Asmentioned I have not had any issues with this machine and it's time until I upgrade.
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram.
TIA.
Brian.
Just to follow up, I had switched to the old kernel before the 5.6 upgrade, and at this time my clock is working flawlessly.
kernel v. 2.6.18-194.32.1.el5 Works as it should... kernel v. 2.6.18-238.5.1.el5 I cannot get my clock accurate.
there are two other 238 kernels - do they show the same behavior?
If there is anything I can do to help solve this IE: information or test. please let me know.At this point I will just make the old kernel default boot until there is a kernel update where which I will try again.
Brian.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, 2011-04-13 at 14:42 -0400, Mailing List wrote:
On 4/13/2011 1:08 PM, Rob Kampen wrote:
there are two other 238 kernels - do they show the same behavior?
I will install kernel-2.6.18-238.5.1.el5.centos.plus and let the list know how it goes. I totally forgot that there was a Plus repo. I actually had it disabled.
Brian.
That's probably not what you want. See this first:
http://wiki.centos.org/AdditionalResources/Repositories/CentOSPlus?highlight...
On Wed, 2011-04-13 at 13:08 -0400, Rob Kampen wrote:
Mailing List wrote:
On 4/13/2011 7:35 AM, Mailing List wrote:
Hi,
I have upgraded my Dell C151 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now as I type this out. If anyone else has any links or ideas that I should check out It would be greatly appreciated.
Just a quick note about my setup. I do not use any gui. Asmentioned I have not had any issues with this machine and it's time until I upgrade.
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram.
TIA.
Brian.
Just to follow up, I had switched to the old kernel before the 5.6 upgrade, and at this time my clock is working flawlessly.
kernel v. 2.6.18-194.32.1.el5 Works as it should... kernel v. 2.6.18-238.5.1.el5 I cannot get my clock accurate.
there are two other 238 kernels - do they show the same behavior?
If there is anything I can do to help solve this IE: information or test. please let me know.At this point I will just make the old kernel default boot until there is a kernel update where which I will try again.
Brian.
You don't say what version of ntp you are using or whether the system in question can access the Internet.
Should be: ntp-4.2.2p1-9.el5.centos.2.1.i386
[Refs]
http://www.ntp.org/ http://support.ntp.org/bin/view/Support/WebHome http://www.eecis.udel.edu/~mills/ntp/html/index.html http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment... /usr/share/doc/ntp-<version>/ntpd.htm
[Main config files]
/etc/ntp.conf /var/lib/ntp/drift /etc/ntp/step-tickers
[Time Sources]
Three time sources you can use for your ntpd:
1. Public or corporate NTP servers
If you have an Internet connection using a public ntp pool is the simplest.
http://www.pool.ntp.org/en/use.html
2. An accurate external reference clock
http://doc.ntp.org/4.2.0/refclock.html
Use if you need microsecond or better accuracy and you've got time and money to setup.
3. Undisciplined local clock on a local computer
http://doc.ntp.org/4.2.0/drivers/driver1.html
This is what I use. You can use this if a few seconds off every few months is less important than all clients being in sync. If it drifts at least all clients will drift with it. You can compensate easily for minor drift too.
As long as all clocks are synced to the same source you should be able to tolerate being off by even a few minutes from the "real" time. Some networked services such as Kerberos cannot tolerate differences in time stamps between client and server. You'll get lots of seemingly arbitrary faults and errors with AD Windows Domains and Linux-based directory authentication and such if all participants are not time-synced.
Sounds like you're using your system clock.
Here's how my isolated networks are configured:
[Primary server]
Machine with most stable system clock - uses system clock, compensating for calculated drift in /var/lib/ntp/drift.
[Secondary servers]
One main RHEL/CentOS server in each of 3 buildings uses primary ntp server as master and sister servers as peers.
[Clients]
CentOS, Windoze DC, Windows stand-alone, and Unix configured to sync with secondary ntp servers using the closest first.
[Using undisciplined system clock]
Best way to determine most stable clock is to:
1. turn ntpd off 2. Sync time with accurate server I use http://wwp.greenwichmeantime.com/time-zone/usa/eastern-time/ 3. Wait days or weeks to check system time against same source 4. Calculate and set drift 5. Start ntpd 6. Check against same time source periodically... every few weeks at first until it's as close as you can get it. 7. Adjust frequency offset and drift values for local (system) clock 8. Start ntpd and use this as "server" in secondary servers.
Sync secondary servers or just clients off this primary.
There are many ways to configure and implement ntp. You should study the references and determine which options are best for your specific needs.
If you wish I can provide sample ntp.conf files, and details of my calibration process. I'm kind of busy right now but I'll throw something together as time permits and forward if you want.
./Cal
On 4/13/2011 2:50 PM, Cal Webster wrote:
You don't say what version of ntp you are using or whether the system in question can access the Internet.
Should be: ntp-4.2.2p1-9.el5.centos.2.1.i386
[Refs]
http://www.ntp.org/ http://support.ntp.org/bin/view/Support/WebHome http://www.eecis.udel.edu/~mills/ntp/html/index.html http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment... /usr/share/doc/ntp-<version>/ntpd.htm
[Main config files]
/etc/ntp.conf /var/lib/ntp/drift /etc/ntp/step-tickers
[Time Sources]
Three time sources you can use for your ntpd:
- Public or corporate NTP servers
If you have an Internet connection using a public ntp pool is the simplest.
http://www.pool.ntp.org/en/use.html
- An accurate external reference clock
http://doc.ntp.org/4.2.0/refclock.html
Use if you need microsecond or better accuracy and you've got time and money to setup.
- Undisciplined local clock on a local computer
http://doc.ntp.org/4.2.0/drivers/driver1.html
This is what I use. You can use this if a few seconds off every few months is less important than all clients being in sync. If it drifts at least all clients will drift with it. You can compensate easily for minor drift too.
As long as all clocks are synced to the same source you should be able to tolerate being off by even a few minutes from the "real" time. Some networked services such as Kerberos cannot tolerate differences in time stamps between client and server. You'll get lots of seemingly arbitrary faults and errors with AD Windows Domains and Linux-based directory authentication and such if all participants are not time-synced.
Sounds like you're using your system clock.
Here's how my isolated networks are configured:
[Primary server]
Machine with most stable system clock - uses system clock, compensating for calculated drift in /var/lib/ntp/drift.
[Secondary servers]
One main RHEL/CentOS server in each of 3 buildings uses primary ntp server as master and sister servers as peers.
[Clients]
CentOS, Windoze DC, Windows stand-alone, and Unix configured to sync with secondary ntp servers using the closest first.
[Using undisciplined system clock]
Best way to determine most stable clock is to:
- turn ntpd off
- Sync time with accurate server I use http://wwp.greenwichmeantime.com/time-zone/usa/eastern-time/
- Wait days or weeks to check system time against same source
- Calculate and set drift
- Start ntpd
- Check against same time source periodically... every few weeks at
first until it's as close as you can get it. 7. Adjust frequency offset and drift values for local (system) clock 8. Start ntpd and use this as "server" in secondary servers.
Sync secondary servers or just clients off this primary.
There are many ways to configure and implement ntp. You should study the references and determine which options are best for your specific needs.
If you wish I can provide sample ntp.conf files, and details of my calibration process. I'm kind of busy right now but I'll throw something together as time permits and forward if you want.
./Cal
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
The ntp server does connect to the internet fine. the version of ntp is as follows.
ntp-4.2.2p1-9.el5.centos.2.1
The time is not off by a matter of minutes or I would not crab so much. It gets to the point of being more then an hour off after setting it. And also Dovecot dies after setting the tuime so much.
As I had posted before, I never had any issue with the sync till I updated to 5.6. And whe I rolled it back to the old kernel time and sync went along flawlessly.
Brian.
On Wed, 2011-04-13 at 15:10 -0400, Mailing List wrote:
On 4/13/2011 2:50 PM, Cal Webster wrote:
[snip]
The ntp server does connect to the internet fine. the version ofntp is as follows.
ntp-4.2.2p1-9.el5.centos.2.1
The time is not off by a matter of minutes or I would not crab so much. It gets to the point of being more then an hour off after setting it. And also Dovecot dies after setting the tuime so much.
As I had posted before, I never had any issue with the sync till I updated to 5.6. And whe I rolled it back to the old kernel time and sync went along flawlessly.
Brian.
I'm running the same kernel and ntp versions and I'm having no problems at all on ntp servers or clients.
If my previous suggestions didn't help maybe you could share contents of the following files and output of some commands so the list can see what you've got.
/etc/ntp.conf /etc/ntp/ntpservers /etc/ntp/step-tickers /var/lib/ntp/drift
grep ntpd /var/log/messages* (please remove repeated messages for clarity)
Most recent entries in /var/log/ntpd.log
SELinux could also be playing a role.
Are you running SELinux enabled, permissive, or disabled? What mode was it running before it stopped working? Are there any possibly related "avc" messages in /var/log/messages or /var/audit/audit.log?
./Cal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/13/2011 03:35 PM, Cal Webster wrote:
On Wed, 2011-04-13 at 15:10 -0400, Mailing List wrote:
On 4/13/2011 2:50 PM, Cal Webster wrote:
[snip]
The ntp server does connect to the internet fine. the version ofntp is as follows.
ntp-4.2.2p1-9.el5.centos.2.1
The time is not off by a matter of minutes or I would not crab so much. It gets to the point of being more then an hour off after setting it. And also Dovecot dies after setting the tuime so much.
As I had posted before, I never had any issue with the sync till I updated to 5.6. And whe I rolled it back to the old kernel time and sync went along flawlessly.
Brian.
I'm running the same kernel and ntp versions and I'm having no problems at all on ntp servers or clients.
If my previous suggestions didn't help maybe you could share contents of the following files and output of some commands so the list can see what you've got.
/etc/ntp.conf /etc/ntp/ntpservers /etc/ntp/step-tickers /var/lib/ntp/drift
grep ntpd /var/log/messages* (please remove repeated messages for clarity)
Most recent entries in /var/log/ntpd.log
SELinux could also be playing a role.
Are you running SELinux enabled, permissive, or disabled? What mode was it running before it stopped working? Are there any possibly related "avc" messages in /var/log/messages or /var/audit/audit.log?
./Cal
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
The avc messages are in /var/log/audit/audit.log
ausearch -m avc -ts recent
Will also show you recent AVC messages.
audit2allow -la
will search for any avc message in /var/log/audit/audit.log or /var/log/messages since the last policy load.
On Wed, 2011-04-13 at 16:00 -0400, Daniel J Walsh wrote: [snip]
The avc messages are in /var/log/audit/audit.log
ausearch -m avc -ts recent
Will also show you recent AVC messages.
audit2allow -la
will search for any avc message in /var/log/audit/audit.log or /var/log/messages since the last policy load.
Thanks for correcting me and providing the additional tools for the OP to use. I sometimes mis-type when in a hurry.
I'd use caution with audit2allow, though, as this tool only shows you what to do to get rid of the avc denial message(s). It makes no judgement whether the resulting policy will be appropriate or safe.
./Cal
On 4/13/2011 3:35 PM, Cal Webster wrote:
I'm running the same kernel and ntp versions and I'm having no problems at all on ntp servers or clients.
If my previous suggestions didn't help maybe you could share contents of the following files and output of some commands so the list can see what you've got.
/etc/ntp.conf /etc/ntp/ntpservers /etc/ntp/step-tickers /var/lib/ntp/drift
grep ntpd /var/log/messages* (please remove repeated messages for clarity)
Most recent entries in /var/log/ntpd.log
SELinux could also be playing a role.
Are you running SELinux enabled, permissive, or disabled? What mode was it running before it stopped working? Are there any possibly related "avc" messages in /var/log/messages or /var/audit/audit.log?
./Cal
/etc/ntp;
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server 0.centos.pool.ntp.org server 1.centos.pool.ntp.org server 2.centos.pool.ntp.org server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift keys /etc/ntp/keys
There is no /etc/ntp/ntpservers
/etc/ntp/step-tickers is an empty file.
/var/lib/ntp/drift; -65.219
I have no /var/log/ntpd.log
/varlog/messages; This is the log using stock updated kernel.
Apr 12 03:32:35 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 03:33:36 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 15:51:56 Server ntpd[2797]: time reset +43208.248852 s Apr 12 15:51:56 Server ntpd[2797]: kernel time sync enabled 0001 Apr 12 15:56:03 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 15:56:26 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:00:22 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:16:59 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 2 Apr 12 16:16:57 Server ntpd[2797]: time reset -1.830305 s Apr 12 16:20:27 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:22:35 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 2 Apr 12 16:28:01 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:32:29 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:36:36 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:40:05 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:41:57 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:42:09 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:47:28 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:48:28 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:51:44 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:53:52 Server ntpd[2797]: synchronized to 173.193.227.67, stratum 4 Apr 12 16:58:06 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 17:00:18 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 17:04:31 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 17:06:44 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 19:54:46 Server ntpd[2797]: ntpd exiting on signal 15 Apr 13 03:01:24 Server ntpd[2409]: ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:56:13 UTC 2009 (1) Apr 13 03:01:24 Server ntpd[2410]: precision = 1.000 usec Apr 13 03:01:24 Server ntpd[2410]: Listening on interface wildcard, 0.0.0.0#123 Disabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface wildcard, ::#123 Disabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface lo, ::1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface eth0, fe80::218:8bff:fe80:67db#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface lo, 127.0.0.1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface eth0, 192.168.2.1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: kernel time sync status 0040 Apr 13 03:01:30 Server ntpd[2410]: frequency initialized 0.000 PPM from /var/lib/ntp/drift Apr 13 07:04:44 Server ntpd[2410]: synchronized to LOCAL(0), stratum 10 Apr 13 07:04:44 Server ntpd[2410]: kernel time sync enabled 0001 Apr 13 07:11:09 Server ntpd[2410]: synchronized to 208.75.88.4, stratum 2 Apr 13 07:17:34 Server ntpd[2410]: synchronized to 64.6.144.6, stratum 2 Apr 13 07:42:59 Server ntpd[2410]: time reset -27.586767 s Apr 13 07:46:35 Server ntpd[2410]: synchronized to LOCAL(0), stratum 10 Apr 13 07:47:38 Server ntpd[2410]: synchronized to 199.249.224.123, stratum 2 Apr 13 07:51:53 Server ntpd[2410]: synchronized to 64.6.144.6, stratum 2 Apr 13 09:27:19 Server ntpd[2410]: ntpd exiting on signal 15 Apr 13 09:27:19 Server ntpd[6743]: ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:56:13 UTC 2009 (1)
Selinux is disabled, and just a note also. This is a stock install of of ntp. I never had to do any fudging with it cause it just worked up until the update.
I also have no /var/log/audit/audit.log.
tia.
Brian
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Mailing List Sent: Wednesday, April 13, 2011 16:23 To: CentOS mailing list Subject: Re: [CentOS] CentOs 5.6 and Time Sync
/etc/ntp;
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server 0.centos.pool.ntp.org server 1.centos.pool.ntp.org server 2.centos.pool.ntp.org server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift keys /etc/ntp/keys
There is no /etc/ntp/ntpservers
/etc/ntp/step-tickers is an empty file.
/var/lib/ntp/drift; -65.219
I have no /var/log/ntpd.log
/varlog/messages; This is the log using stock updated kernel.
Apr 12 03:32:35 Server ntpd[2797]: synchronized to LOCAL(0), stratum
10
Apr 12 03:33:36 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 15:51:56 Server ntpd[2797]: time reset +43208.248852 s
Wow! That is a big jump.
Apr 12 15:51:56 Server ntpd[2797]: kernel time sync enabled 0001 Apr 12 15:56:03 Server ntpd[2797]: synchronized to LOCAL(0), stratum
10
Apr 12 15:56:26 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:00:22 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:16:59 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 2 Apr 12 16:16:57 Server ntpd[2797]: time reset -1.830305 s Apr 12 16:20:27 Server ntpd[2797]: synchronized to LOCAL(0), stratum
10
<SNIP log of ntpd jumping from server to server (fairly often) including LOCAL host>
It seems that the connections to the external ntp servers are not good enough to keep you off LOCAL, and once on local you will drift at the rate the system last had, and that drift rate can be quite large when the system is first trying to come into sync. (and often quite a bit larger than the steady state drift rate once synced)
Selinux is disabled, and just a note also. This is a stock install of of ntp. I never had to do any fudging with it cause it just worked up until the update.
I also have no /var/log/audit/audit.log.
tia.
Brian
We still don't know why the machine is losing time, but it might help to have some more data to compare with IIRC you indicated you had two other servers in your environment that were still keeping time good... I would suggest adding something like: echo "server myotherserver" >> /etc/ntp.conf echo "restrict myotherserver mask 255.255.255.255 notrap" >> /etc/ntp.conf
you may also have to add restrict a line on "myotherserver" such that your "timeloosingserver" can get info, i.e. on myotherserver echo "restrict timeloosingserver mask 255.255.255.255 nomodify notrap"
/etc/ntp.conf
[please evaluate the above restrict lines to verify they are good enough security for your environment, I am doing them from memory]
so that you have a local host which is not bouncing all over the place, with respect to connectivity, to check against.
On Wed, 2011-04-13 at 16:22 -0400, Mailing List wrote:
On 4/13/2011 3:35 PM, Cal Webster wrote:
I'm running the same kernel and ntp versions and I'm having no problems at all on ntp servers or clients.
If my previous suggestions didn't help maybe you could share contents of the following files and output of some commands so the list can see what you've got.
/etc/ntp.conf /etc/ntp/ntpservers /etc/ntp/step-tickers /var/lib/ntp/drift
grep ntpd /var/log/messages* (please remove repeated messages for clarity)
Most recent entries in /var/log/ntpd.log
SELinux could also be playing a role.
Are you running SELinux enabled, permissive, or disabled? What mode was it running before it stopped working? Are there any possibly related "avc" messages in /var/log/messages or /var/audit/audit.log?
./Cal
/etc/ntp;
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server 0.centos.pool.ntp.org server 1.centos.pool.ntp.org server 2.centos.pool.ntp.org server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift keys /etc/ntp/keys
There is no /etc/ntp/ntpservers
/etc/ntp/step-tickers is an empty file.
/var/lib/ntp/drift; -65.219
I have no /var/log/ntpd.log
/varlog/messages; This is the log using stock updated kernel.
Apr 12 03:32:35 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 03:33:36 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 15:51:56 Server ntpd[2797]: time reset +43208.248852 s Apr 12 15:51:56 Server ntpd[2797]: kernel time sync enabled 0001 Apr 12 15:56:03 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 15:56:26 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:00:22 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:16:59 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 2 Apr 12 16:16:57 Server ntpd[2797]: time reset -1.830305 s Apr 12 16:20:27 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:22:35 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 2 Apr 12 16:28:01 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:32:29 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:36:36 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:40:05 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:41:57 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:42:09 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:47:28 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:48:28 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:51:44 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:53:52 Server ntpd[2797]: synchronized to 173.193.227.67, stratum 4 Apr 12 16:58:06 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 17:00:18 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 17:04:31 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 17:06:44 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 19:54:46 Server ntpd[2797]: ntpd exiting on signal 15 Apr 13 03:01:24 Server ntpd[2409]: ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:56:13 UTC 2009 (1) Apr 13 03:01:24 Server ntpd[2410]: precision = 1.000 usec Apr 13 03:01:24 Server ntpd[2410]: Listening on interface wildcard, 0.0.0.0#123 Disabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface wildcard, ::#123 Disabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface lo, ::1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface eth0, fe80::218:8bff:fe80:67db#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface lo, 127.0.0.1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface eth0, 192.168.2.1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: kernel time sync status 0040 Apr 13 03:01:30 Server ntpd[2410]: frequency initialized 0.000 PPM from /var/lib/ntp/drift Apr 13 07:04:44 Server ntpd[2410]: synchronized to LOCAL(0), stratum 10 Apr 13 07:04:44 Server ntpd[2410]: kernel time sync enabled 0001 Apr 13 07:11:09 Server ntpd[2410]: synchronized to 208.75.88.4, stratum 2 Apr 13 07:17:34 Server ntpd[2410]: synchronized to 64.6.144.6, stratum 2 Apr 13 07:42:59 Server ntpd[2410]: time reset -27.586767 s Apr 13 07:46:35 Server ntpd[2410]: synchronized to LOCAL(0), stratum 10 Apr 13 07:47:38 Server ntpd[2410]: synchronized to 199.249.224.123, stratum 2 Apr 13 07:51:53 Server ntpd[2410]: synchronized to 64.6.144.6, stratum 2 Apr 13 09:27:19 Server ntpd[2410]: ntpd exiting on signal 15 Apr 13 09:27:19 Server ntpd[6743]: ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:56:13 UTC 2009 (1)
Selinux is disabled, and just a note also. This is a stock install of of ntp. I never had to do any fudging with it cause it just worked up until the update.
I also have no /var/log/audit/audit.log.
I don't have any CentOS machines with direct Internet connections but I compared your config and logs to my internal machines and an external FC12 box.
Your time resets are wildly fulctuating between +720 min (12 hours) and -2 seconds over the course of only one hour, according to the log. I have no way of knowing how much actual time had elapsed but the ntp daemon decided the step threshold had been exceeded and reset the time according to its time source.
If you are indeed getting good time from the ntp pool, then either your local system clock is malfunctioning or the kernel driver is getting bad clock readings. Even network outages would not produce such a large range of resets in such a short period.
I'd be interested to see the output of:
ntpq -c pe -c as
You might try commenting out the local clock entries in /etc/ntp.conf and see if that changes your symptoms.
#server 127.127.1.0 # local clock #fudge 127.127.1.0 stratum 10
./Cal
On 4/13/2011 5:24 PM, Cal Webster wrote:
ntpq -c pe -c as
root > ~# ntpq -c pe -c as remote refid st t when poll reach delay offset jitter ============================================================================== bindcat.fhsu.ed 132.163.4.101 2 u 1015 1024 377 49.987 -15082. 6919.88 216.45.57.38 108.71.253.18 2 u 998 1024 377 83.112 -15139. 6900.14 javanese.kjsl.c 69.36.224.15 2 u 1 1024 377 109.083 -29233. 7285.83 *LOCAL(0) .LOCL. 10 l 13 64 377 0.000 0.000 0.001
ind assID status conf reach auth condition last_event cnt =========================================================== 1 26525 9044 yes yes none reject reachable 4 2 26526 9044 yes yes none reject reachable 4 3 26527 9044 yes yes none reject reachable 4 4 26528 9644 yes yes none sys.peer reachable 4 root > ~#
Right now everything is running as it should. I did indeed switch to the CentOSplus kernel. And it is working as it should. I would need to go back to the stiock updated kernel from the 5.5 - 5.6 upgrade..
Brian.
On Wed, 2011-04-13 at 17:42 -0400, Mailing List wrote:
On 4/13/2011 5:24 PM, Cal Webster wrote:
ntpq -c pe -c as
root > ~# ntpq -c pe -c as remote refid st t when poll reach delay offset jitter ============================================================================== bindcat.fhsu.ed 132.163.4.101 2 u 1015 1024 377 49.987 -15082. 6919.88 216.45.57.38 108.71.253.18 2 u 998 1024 377 83.112 -15139. 6900.14 javanese.kjsl.c 69.36.224.15 2 u 1 1024 377 109.083 -29233. 7285.83 *LOCAL(0) .LOCL. 10 l 13 64 377 0.000 0.000 0.001
ind assID status conf reach auth condition last_event cnt
1 26525 9044 yes yes none reject reachable 4 2 26526 9044 yes yes none reject reachable 4 3 26527 9044 yes yes none reject reachable 4 4 26528 9644 yes yes none sys.peer reachable 4 root > ~#
Right now everything is running as it should. I did indeed switch to the CentOSplus kernel. And it is working as it should. I would need to go back to the stiock updated kernel from the 5.5 - 5.6 upgrade..
Brian.
Your ntpq output tells me that all the ntp.org servers have been rejected in favor of your (undisciplined) local clock. You should disable it as a time source in ntp.conf as suggested previously. You gain nothing by keeping it configured under your circumstances.
./Cal
On 4/13/2011 6:01 PM, Cal Webster wrote:
Your ntpq output tells me that all the ntp.org servers have been rejected in favor of your (undisciplined) local clock. You should disable it as a time source in ntp.conf as suggested previously. You gain nothing by keeping it configured under your circumstances.
./Cal
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I have removed the call to the local source as you suggested. I have noticed now that the clock is moving ahead now that I am on the CentOSPlus kernel. I'm going to leave it go over night and see how far it will go ahead.. Thank you all for your help.
Brian.
On 14/04/11 7:42 AM, Mailing List wrote:
remote refid st t when poll reach delay offsetjitter
bindcat.fhsu.ed 132.163.4.101 2 u 1015 1024 377 49.987 -15082. 6919.88 216.45.57.38 108.71.253.18 2 u 998 1024 377 83.112 -15139. 6900.14 javanese.kjsl.c 69.36.224.15 2 u 1 1024 377 109.083 -29233. 7285.83 *LOCAL(0) .LOCL. 10 l 13 64 377 0.000 0.000 0.001
<snip>
Glad you've got a fix but you should keep an eye on it.
If you look at the output for ntpq you have three stratum 2 servers which differ by ~15s from both you and each other. Stratum 2 servers should be a lot closer than 15s given that they are only one link removed from some form of atomic clock.
Cheers -pete
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Peter Brady Sent: Wednesday, April 13, 2011 18:39 To: CentOS mailing list Subject: Re: [CentOS] CentOs 5.6 and Time Sync
On 14/04/11 7:42 AM, Mailing List wrote:
remote refid st t when poll reach delayoffset
jitter
=======================================================================
=======
bindcat.fhsu.ed 132.163.4.101 2 u 1015 1024 377 49.987 -
6919.88 216.45.57.38 108.71.253.18 2 u 998 1024 377 83.112 -
6900.14 javanese.kjsl.c 69.36.224.15 2 u 1 1024 377 109.083 -
7285.83 *LOCAL(0) .LOCL. 10 l 13 64 377 0.000
0.000
0.001
<snip>
Glad you've got a fix but you should keep an eye on it.
If you look at the output for ntpq you have three stratum 2 servers which differ by ~15s from both you and each other. Stratum 2 servers should be a lot closer than 15s given that they are only one link removed from some form of atomic clock.
I think you may be comparing a couple of rotting apples to one that is just now ripening. when offset 1015 15082 998 15139 1 29233
i.e., the samples that are 17 seconds apart in the taking are .057S apart in value, and trending longer.
On 14/04/11 9:16 AM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane wrote:
I think you may be comparing a couple of rotting apples to one that is just now ripening. when offset 1015 15082 998 15139 1 29233
i.e., the samples that are 17 seconds apart in the taking are .057S apart in value, and trending longer.
Ah, fair enough.
-pete
Mailing List wrote:
On 4/13/2011 3:35 PM, Cal Webster wrote:
I'm running the same kernel and ntp versions and I'm having no problems at all on ntp servers or clients.
If my previous suggestions didn't help maybe you could share contents of the following files and output of some commands so the list can see what you've got.
/etc/ntp.conf /etc/ntp/ntpservers /etc/ntp/step-tickers /var/lib/ntp/drift
grep ntpd /var/log/messages* (please remove repeated messages for clarity)
Most recent entries in /var/log/ntpd.log
SELinux could also be playing a role.
Are you running SELinux enabled, permissive, or disabled? What mode was it running before it stopped working? Are there any possibly related "avc" messages in /var/log/messages or /var/audit/audit.log?
./Cal
/etc/ntp;
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server 0.centos.pool.ntp.org server 1.centos.pool.ntp.org server 2.centos.pool.ntp.org server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift keys /etc/ntp/keys
There is no /etc/ntp/ntpservers
/etc/ntp/step-tickers is an empty file.
/var/lib/ntp/drift; -65.219
I have no /var/log/ntpd.log
/varlog/messages; This is the log using stock updated kernel.
Apr 12 03:32:35 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 03:33:36 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 15:51:56 Server ntpd[2797]: time reset +43208.248852 s Apr 12 15:51:56 Server ntpd[2797]: kernel time sync enabled 0001 Apr 12 15:56:03 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 15:56:26 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:00:22 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:16:59 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 2 Apr 12 16:16:57 Server ntpd[2797]: time reset -1.830305 s Apr 12 16:20:27 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:22:35 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 2 Apr 12 16:28:01 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:32:29 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:36:36 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:40:05 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:41:57 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:42:09 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:47:28 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:48:28 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:51:44 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:53:52 Server ntpd[2797]: synchronized to 173.193.227.67, stratum 4 Apr 12 16:58:06 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 17:00:18 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 17:04:31 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 17:06:44 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 19:54:46 Server ntpd[2797]: ntpd exiting on signal 15 Apr 13 03:01:24 Server ntpd[2409]: ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:56:13 UTC 2009 (1) Apr 13 03:01:24 Server ntpd[2410]: precision = 1.000 usec Apr 13 03:01:24 Server ntpd[2410]: Listening on interface wildcard, 0.0.0.0#123 Disabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface wildcard, ::#123 Disabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface lo, ::1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface eth0, fe80::218:8bff:fe80:67db#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface lo, 127.0.0.1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface eth0, 192.168.2.1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: kernel time sync status 0040 Apr 13 03:01:30 Server ntpd[2410]: frequency initialized 0.000 PPM from /var/lib/ntp/drift Apr 13 07:04:44 Server ntpd[2410]: synchronized to LOCAL(0), stratum 10 Apr 13 07:04:44 Server ntpd[2410]: kernel time sync enabled 0001 Apr 13 07:11:09 Server ntpd[2410]: synchronized to 208.75.88.4, stratum 2 Apr 13 07:17:34 Server ntpd[2410]: synchronized to 64.6.144.6, stratum 2 Apr 13 07:42:59 Server ntpd[2410]: time reset -27.586767 s Apr 13 07:46:35 Server ntpd[2410]: synchronized to LOCAL(0), stratum 10 Apr 13 07:47:38 Server ntpd[2410]: synchronized to 199.249.224.123, stratum 2 Apr 13 07:51:53 Server ntpd[2410]: synchronized to 64.6.144.6, stratum 2 Apr 13 09:27:19 Server ntpd[2410]: ntpd exiting on signal 15 Apr 13 09:27:19 Server ntpd[6743]: ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:56:13 UTC 2009 (1)
Selinux is disabled, and just a note also. This is a stock install of of ntp. I never had to do any fudging with it cause it just worked up until the update.
I also have no /var/log/audit/audit.log.
tia.
Brian
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
43208 seconds is 8 seconds from 12 hours. Could this be an AM/PM issue? or a tz issue? what timezone have you set? ntp uses UTC time. Is your machine hw clock set for UTC?
Just a few thoughts.
Peace, Allan
On 04/13/2011 10:31 AM, Mailing List wrote:
On 4/13/2011 7:35 AM, Mailing List wrote:
Hi,
I have upgraded my Dell C151 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now as I type this out. If anyone else has any links or ideas that I should check out It would be greatly appreciated.
Just a quick note about my setup. I do not use any gui. Asmentioned I have not had any issues with this machine and it's time until I upgrade.
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram.
TIA.
Brian.
Just to follow up, I had switched to the old kernel before the 5.6 upgrade, and at this time my clock is working flawlessly.
kernel v. 2.6.18-194.32.1.el5 Works as it should... kernel v. 2.6.18-238.5.1.el5 I cannot get my clock accurate.
If there is anything I can do to help solve this IE: information or test. please let me know.At this point I will just make the old kernel default boot until there is a kernel update where which I will try again.
Is it really true that the time is working perfectly with one of the other kernels (the older ones)?
On 4/14/2011 6:47 AM, Johnny Hughes wrote:
Is it really true that the time is working perfectly with one of the other kernels (the older ones)?
Johnny,
Yes, As long as I run the older 5.5 kernel my time is perfect. All clients can get from this machine with no issues. As soon as I run new kernel, or Plus kernel for that matter. The time goes downhill. "Uphill actually"
To answer the previous question I do have the HW clock set to utc, Everything is stock from initial install of the package.
Brian.
On 4/14/2011 6:47 AM, Johnny Hughes wrote:
Is it really true that the time is working perfectly with one of the other kernels (the older ones)?
Johnny, Yes, As long as I run the older 5.5 kernel my time is perfect.All clients can get from this machine with no issues. As soon as I run new kernel, or Plus kernel for that matter. The time goes downhill. "Uphill actually"
To answer the previous question I do have the HW clock set to utc,Everything is stock from initial install of the package.
Did you check dmesg which timer is being used (I think it can also be seen somewhere in /proc but I don't remember). If it's hpet, you could try to disable it. That was for i686: 'hpet=disable' and for x86_64: 'nohpet', don't know how it is with current kernels.
Simon
On Thu, 2011-04-14 at 13:28 +0200, Simon Matter wrote:
On 4/14/2011 6:47 AM, Johnny Hughes wrote:
Is it really true that the time is working perfectly with one of the other kernels (the older ones)?
Johnny, Yes, As long as I run the older 5.5 kernel my time is perfect.All clients can get from this machine with no issues. As soon as I run new kernel, or Plus kernel for that matter. The time goes downhill. "Uphill actually"
To answer the previous question I do have the HW clock set to utc,Everything is stock from initial install of the package.
Did you check dmesg which timer is being used (I think it can also be seen somewhere in /proc but I don't remember). If it's hpet, you could try to disable it. That was for i686: 'hpet=disable' and for x86_64: 'nohpet', don't know how it is with current kernels.
Simon
Forgive me if I've missed a later post but it looked like this thread was stagnant...
You may have something here Simon. I was thinking about your suggestion that it could be a timer issue. I'm wondering if the default clocksource or some related timer kernel parameter has been changed between 2.6.18-194.17.4.el5 (5.5) and 2.6.18-238.5.1.el5 (5.6).
Timer related issues could very well account for this large, inconsistent NTP drift as well as Florin Andrei's "bizarre" tar, scp, and NTP issues in the "[CentOS] bizarre system slowness" thread. System interrupts are based on the clocksource chosen by (or configured in) the kernel. Any service or facility that uses these interrupts could be experiencing problems.
Can anyone on the list confirm whether or not timer related kernel parameters have changed in 5.6? I don't have source handy and I'm going out the door in minutes.
Reading up on kernel timer options, I came across these articles.
# Discusses mis-detected timer frequency 9.2.4.2.7. Kernel 2.6 Mis-Detecting CPU TSC Frequency http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.7.
# Describes ntpd instability from some time sources # Includes data and graphs from detailed study http://www.ep.ph.bham.ac.uk/general/support/adjtimex.html
I checked clock sources on a few systems under my control to see what came up. None are experiencing this problem. The CentOS and FC12 machines are isolated from the Internet while the FC14 laptop connects. My sample CentOS 5.5 & 5.6 systems are different hardware platforms. The 5.6 box doesn't have the hpet timer available so it may just not be susceptible to this problem. I'll be updating the 5.5 sample to 5.6 tomorrow which does have hpet available so I should know something more then.
# Used these to get available and current clocksource: cat /sys/devices/system/clocksource/clocksource0/available_clocksource cat /sys/devices/system/clocksource/clocksource0/current_clocksource
# CentOS 5.5: Available: acpi_pm jiffies hpet tsc pit Current: tsc
# CentOS 5.6: Available: acpi_pm jiffies tsc pit Current: tsc
# Fedora 12: Available: tsc hpet acpi_pm Current: tsc
# Fedora 14: Using hpet Available: hpet acpi_pm Current: hpet
On 04/14/2011 06:23 AM, Mailing List wrote:
On 4/14/2011 6:47 AM, Johnny Hughes wrote:
Is it really true that the time is working perfectly with one of the other kernels (the older ones)?
Johnny,
Yes, As long as I run the older 5.5 kernel my time is perfect. Allclients can get from this machine with no issues. As soon as I run new kernel, or Plus kernel for that matter. The time goes downhill. "Uphill actually"
To answer the previous question I do have the HW clock set to utc,Everything is stock from initial install of the package.
Brian.
I do not see anything from Dell that is a model C151.
I also do not see anything in the RH bugzilla that is problematic for older AMD processors and the clock, unless running KVM type virtual machines.
Is this a VM or regular install?
If this a real machine, do you have the latest BIOS from Dell?
Do you have any special kernel options in grub?
On 04/15/2011 04:08 AM, Johnny Hughes wrote:
On 04/14/2011 06:23 AM, Mailing List wrote:
On 4/14/2011 6:47 AM, Johnny Hughes wrote:
Is it really true that the time is working perfectly with one of the other kernels (the older ones)?
Johnny,
Yes, As long as I run the older 5.5 kernel my time is perfect. Allclients can get from this machine with no issues. As soon as I run new kernel, or Plus kernel for that matter. The time goes downhill. "Uphill actually"
To answer the previous question I do have the HW clock set to utc,Everything is stock from initial install of the package.
Brian.
I do not see anything from Dell that is a model C151.
I also do not see anything in the RH bugzilla that is problematic for older AMD processors and the clock, unless running KVM type virtual machines.
Is this a VM or regular install?
If this a real machine, do you have the latest BIOS from Dell?
Do you have any special kernel options in grub?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
It also occured to me to ask if this was running in a VM, but it sounded like it was running on actual hardware. I once had a vmware VM in which I had similar misbehavior of the clock. Eventually I discovered that the following simple program when run inside the VM would return immediately instead of delaying for 10 seconds as it should.
#include <stdio.h> /* #include <sys/select.h> */ #include <sys/time.h> #include <sys/types.h> #include <unistd.h>
int main() { fd_set set; struct timeval timeout; int filedes = STDIN_FILENO;
FD_ZERO (&set); FD_SET (filedes, &set);
timeout.tv_sec = 10; timeout.tv_usec = 0;
select(FD_SETSIZE, &set, NULL, NULL, &timeout);
}
I then found out that the ISP had set the host OS for my VM to Ubuntu when I was running CentOS 5 in the VM. The cause was that VMware assumed a tickless kernel for Ubuntu, but not for CentOS 5 and there were optimizations in the VM emulation that counted on VMware knowing what timekeeping options where set in the kernel.
Nataraj
On 4/15/2011 7:08 AM, Johnny Hughes wrote:
I do not see anything from Dell that is a model C151.
I also do not see anything in the RH bugzilla that is problematic for older AMD processors and the clock, unless running KVM type virtual machines.
Is this a VM or regular install?
If this a real machine, do you have the latest BIOS from Dell?
Do you have any special kernel options in grub?
Johnny,
Sorry about the wrong system id number here is what it is.
Dell Inspiron C521 Bios Version 1.1.11 (08/07/2007)
It is not a VM, it is a regular install. I have not made any changes to the kernel options. It has been fine with a stock install so I never had any need to tweek it.
Thank you. Brian
On 4/15/2011 4:58 PM, Mailing List wrote:
Johnny,
Sorry about the wrong system id number here is what it is.Dell Inspiron C521 Bios Version 1.1.11 (08/07/2007)
It is not a VM, it is a regular install. I have not made anychanges to the kernel options. It has been fine with a stock install so I never had any need to tweek it.
Thank you. Brian
I would have answered sooner but my ISP ended up in the trash can due to the list's spam filters.
I tried the latest kernel that was just rolled out. kernel-2.6.18-238.9.1.el5 and it was a mess also.
Brian.
On 4/13/2011 7:35 AM, Mailing List wrote:
Hi,
I have upgraded my Dell C151 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now as I type this out. If anyone else has any links or ideas that I should check out It would be greatly appreciated.
Just a quick note about my setup. I do not use any gui. Asmentioned I have not had any issues with this machine and it's time until I upgrade.
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram.
TIA.
Brian.
Something I wanted to add, Cal here on the list gave me a command to run.. Here is the results on a working 5.5 kernel.
root > ~# ntpq -c pe -c as remote refid st t when poll reach delay offset jitter ============================================================================== *slackadelic.com 204.9.54.119 2 u 746 1024 377 57.333 -1.560 1.054 +ntp2.Rescomp.Be 128.32.206.55 2 u 351 1024 377 107.342 11.677 0.197 +w1-wdc.ipv4.got 10.0.77.54 3 u 708 1024 377 25.122 8.503 1.698 LOCAL(0) .LOCL. 10 l 33 64 377 0.000 0.000 0.001
ind assID status conf reach auth condition last_event cnt =========================================================== 1 18756 9614 yes yes none sys.peer reachable 1 2 18757 9414 yes yes none candidat reachable 1 3 18758 9414 yes yes none candidat reachable 1 4 18759 9014 yes yes none reject reachable 1
Now here is the results on the 5.6 kernels.
root > ~# ntpq -c pe -c as
remote refid st t when poll reach delay offset jitter ==============================================================================
bindcat.fhsu.ed 132.163.4.101 2 u 1015 1024 377 49.987 -15082. 6919.88 216.45.57.38 108.71.253.18 2 u 998 1024 377 83.112 -15139. 6900.14 javanese.kjsl.c 69.36.224.15 2 u 1 1024 377 109.083 -29233. 7285.83 *LOCAL(0) .LOCL. 10 l 13 64 377 0.000 0.000 0.001
ind assID status conf reach auth condition last_event cnt =========================================================== 1 26525 9044 yes yes none reject reachable 4 2 26526 9044 yes yes none reject reachable 4 3 26527 9044 yes yes none reject reachable 4 4 26528 9644 yes yes none sys.peer reachable 4
And as for the clock source.
# CentOS 5.5 Kernel 2.6.18-194.32.1.el5.. Time runs as it should. cat /sys/devices/system/clocksource/clocksource0/available_clocksource=jiffies
cat /sys/devices/system/clocksource/clocksource0/current_clocksource=jiffies
# CentOS 5.6 kernel 2.6.18-238.5.1.el5 Time goes to the dogs. cat /sys/devices/system/clocksource/clocksource0/available_clocksource=jiffies
cat /sys/devices/system/clocksource/clocksource0/current_clocksource=jiffies TIA Brian
On 4/13/2011 7:35 AM, Mailing List wrote:
Hi,
I have upgraded my Dell C151 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now as I type this out. If anyone else has any links or ideas that I should check out It would be greatly appreciated.
Just a quick note about my setup. I do not use any gui. Asmentioned I have not had any issues with this machine and it's time until I upgrade.
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram.
TIA.
Brian.
I hope I'm not the only one having this issue with ntp and the new 5.6 kernels..
I am still stuck on the old 5.5 kernel, anything from the 5.6 era and I start seeing time issues.
Brian.
On 4/13/2011 7:35 AM, Mailing List wrote:
Hi,
I have upgraded my Dell C151 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now as I type this out. If anyone else has any links or ideas that I should check out It would be greatly appreciated.
Just a quick note about my setup. I do not use any gui. Asmentioned I have not had any issues with this machine and it's time until I upgrade.
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram.
TIA.
Brian.
Have you tried installing the adjtimex package? If your system clock is running reliably fast under the 5.6 kernel, maybe adjtimex can turn that reliability into reliable time sync for you?
Rick
On 4/20/2011 5:45 PM, Rick Thomas wrote:
Have you tried installing the adjtimex package? If your system clock is running reliably fast under the 5.6 kernel, maybe adjtimex can turn that reliability into reliable time sync for you?
Rick
No I haven't, I will look into it. Thank you for the thought,
Brian
On 4/13/2011 7:35 AM, Mailing List wrote:
Hi,
I have upgraded my Dell C521 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now as I type this out. If anyone else has any links or ideas that I should check out It would be greatly appreciated.
Just a quick note about my setup. I do not use any gui. Asmentioned I have not had any issues with this machine and it's time until I upgrade.
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram.
TIA.
Brian.
List,
I was not able to resolve my issue with the time on this machine. I went ahead and rolled the update back to 5.5 and disabled the update to 5.6.
What I would like to know is if CentOS 6 might be ok when it rolls out, or am I just going to have to keep with 5.5 till EOL?
Thanks to all with there help.
Brian.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Mailing List Sent: Monday, April 25, 2011 13:57 To: CentOS mailing list Subject: Re: [CentOS] CentOs 5.6 and Time Sync
On 4/13/2011 7:35 AM, Mailing List wrote:
Hi,
I have upgraded my Dell C521 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram.
TIA.
Brian.
List, I was not able to resolve my issue with the time on this machine.I went ahead and rolled the update back to 5.5 and disabled the update
to
5.6.
What I would like to know is if CentOS 6 might be ok when it rollsout, or am I just going to have to keep with 5.5 till EOL?
Thanks to all with there help.
1) I hope you are only talking about having rolled back to the last working for you kernel from 5.5, not the whole distribution.
2) If I was in your position and had time, my method would be[1] a) get the srpm for the last known working kernel (2.6.18-194.32 ???) b) get the srpm for the first known not working kernel (2.6.18-238 ???) c) expand each of the above srpms into their own rpm build tree i.e., rpmdev-setuptree;rpm -i kern1; mv rpmbuild rpmbuild.kern1; rpmdev-setuptree;rpm -i kern2; mv rpmbuild rpmbuild.kern2 d) start looking at the differences in the patches applied in kern1 vs. those in kern2, i.e., read/diff the kernel.spec files see if there were any new ones that seemed likely to be causing the problem... RTFS if necessary to make better guesses. Rebuild kernel 2 with patches taken out/modified based on my investigations and test them and see if I guessed right. If no luck, think about opening an TUV bug with lots of the info you have sent here, they may be interested even if you don't have a subscription.
[1] Been there, done that: http://www.gossamer-threads.com/lists/drbd/users/9616
On Mon, Apr 25, 2011 at 12:47 PM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane todd.denniston@navy.mil wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Mailing List Sent: Monday, April 25, 2011 13:57 To: CentOS mailing list Subject: Re: [CentOS] CentOs 5.6 and Time Sync
List, I was not able to resolve my issue with the time on this machine.I went ahead and rolled the update back to 5.5 and disabled the update
to
5.6.
What I would like to know is if CentOS 6 might be ok when it rollsout, or am I just going to have to keep with 5.5 till EOL?
Thanks to all with there help.
- I hope you are only talking about having rolled back to the last
working for you kernel from 5.5, not the whole distribution.
- If I was in your position and had time, my method would be[1]
a) get the srpm for the last known working kernel (2.6.18-194.32 ???) b) get the srpm for the first known not working kernel (2.6.18-238 ???) c) expand each of the above srpms into their own rpm build tree i.e., rpmdev-setuptree;rpm -i kern1; mv rpmbuild rpmbuild.kern1; rpmdev-setuptree;rpm -i kern2; mv rpmbuild rpmbuild.kern2 d) start looking at the differences in the patches applied in kern1 vs. those in kern2, i.e., read/diff the kernel.spec files see if there were any new ones that seemed likely to be causing the problem... RTFS if necessary to make better guesses. Rebuild kernel 2 with patches taken out/modified based on my investigations and test them and see if I guessed right. If no luck, think about opening an TUV bug with lots of the info you have sent here, they may be interested even if you don't have a subscription.
[1] Been there, done that: http://www.gossamer-threads.com/lists/drbd/users/9616
At first I figured this was misconfigured NTP but I actually see this happening on one of my machines as well. Nothing interesting about it in particular but I verified that rolling back to the previous kernel (2.6.18-194.32.1.el5) solves the problem entirely. This happens when NTP is enabled or disabled. I get the following error messages in dmesg which are possibly related.
time.c: can't update CMOS clock from 59 to 0 time.c: can't update CMOS clock from 59 to 0 time.c: can't update CMOS clock from 59 to 0 time.c: can't update CMOS clock from 59 to 0
The time drift is significantly higher than would be expected as normal. Because rolling back the kernel completely solves this issue, this must be a bug.
[root@nexus4 ~]# date; ntpdate -u pool.ntp.org Mon May 9 16:51:03 PDT 2011 9 May 16:50:21 ntpdate[22117]: step time server 207.182.243.123 offset -42.418572 sec
[root@nexus4 ~]# date; ntpdate -u pool.ntp.org Mon May 9 16:50:33 PDT 2011 9 May 16:50:35 ntpdate[22127]: step time server 207.182.243.123 offset -0.692146 sec
Brandon
On 05/09/2011 06:53 PM, Brandon Ooi wrote:
On Mon, Apr 25, 2011 at 12:47 PM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane <todd.denniston@navy.mil mailto:todd.denniston@navy.mil> wrote:
> -----Original Message----- > From: centos-bounces@centos.org <mailto:centos-bounces@centos.org> [mailto:centos-bounces@centos.org <mailto:centos-bounces@centos.org>] On > Behalf Of Mailing List > Sent: Monday, April 25, 2011 13:57 > To: CentOS mailing list > Subject: Re: [CentOS] CentOs 5.6 and Time Sync > > > > List, > > I was not able to resolve my issue with the time on this machine. > I > went ahead and rolled the update back to 5.5 and disabled the update to > 5.6. > > What I would like to know is if CentOS 6 might be ok when it rolls > out, or am I just going to have to keep with 5.5 till EOL? > > Thanks to all with there help. > 1) I hope you are only talking about having rolled back to the last working for you kernel from 5.5, not the whole distribution. 2) If I was in your position and had time, my method would be[1] a) get the srpm for the last known working kernel (2.6.18-194.32 ???) b) get the srpm for the first known not working kernel (2.6.18-238 ???) c) expand each of the above srpms into their own rpm build tree i.e., rpmdev-setuptree;rpm -i kern1; mv rpmbuild rpmbuild.kern1; rpmdev-setuptree;rpm -i kern2; mv rpmbuild rpmbuild.kern2 d) start looking at the differences in the patches applied in kern1 vs. those in kern2, i.e., read/diff the kernel.spec files see if there were any new ones that seemed likely to be causing the problem... RTFS if necessary to make better guesses. Rebuild kernel 2 with patches taken out/modified based on my investigations and test them and see if I guessed right. If no luck, think about opening an TUV bug with lots of the info you have sent here, they may be interested even if you don't have a subscription. [1] Been there, done that: http://www.gossamer-threads.com/lists/drbd/users/9616At first I figured this was misconfigured NTP but I actually see this happening on one of my machines as well. Nothing interesting about it in particular but I verified that rolling back to the previous kernel (2.6.18-194.32.1.el5) solves the problem entirely. This happens when NTP is enabled or disabled. I get the following error messages in dmesg which are possibly related.
time.c: can't update CMOS clock from 59 to 0 time.c: can't update CMOS clock from 59 to 0 time.c: can't update CMOS clock from 59 to 0 time.c: can't update CMOS clock from 59 to 0
The time drift is significantly higher than would be expected as normal. Because rolling back the kernel completely solves this issue, this must be a bug.
[root@nexus4 ~]# date; ntpdate -u pool.ntp.org http://pool.ntp.org Mon May 9 16:51:03 PDT 2011 9 May 16:50:21 ntpdate[22117]: step time server 207.182.243.123 offset -42.418572 sec
[root@nexus4 ~]# date; ntpdate -u pool.ntp.org http://pool.ntp.org Mon May 9 16:50:33 PDT 2011 9 May 16:50:35 ntpdate[22127]: step time server 207.182.243.123 offset -0.692146 sec
Yes, this is obviously a problem with the kernel interacting with the clock on some machines. IF we can figure out which ones and why, we can get upstream to fix it.
On 05/09/2011 06:53 PM, Brandon Ooi wrote:
On Mon, Apr 25, 2011 at 12:47 PM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane <todd.denniston@navy.mil mailto:todd.denniston@navy.mil> wrote:
> -----Original Message----- > From: centos-bounces@centos.org <mailto:centos-bounces@centos.org> [mailto:centos-bounces@centos.orgmailto:centos-bounces@centos.org] On > Behalf Of Mailing List > Sent: Monday, April 25, 2011 13:57 > To: CentOS mailing list > Subject: Re: [CentOS] CentOs 5.6 and Time Sync > > > > List, > > I was not able to resolve my issue with the time on this machine. > I > went ahead and rolled the update back to 5.5 and disabled the update to > 5.6. > > What I would like to know is if CentOS 6 might be ok when it rolls > out, or am I just going to have to keep with 5.5 till EOL? > > Thanks to all with there help. >
1) I hope you are only talking about having rolled back to the last working for you kernel from 5.5, not the whole distribution. 2) If I was in your position and had time, my method would be[1] a) get the srpm for the last known working kernel (2.6.18-194.32???) b) get the srpm for the first known not working kernel (2.6.18-238 ???) c) expand each of the above srpms into their own rpm build tree i.e., rpmdev-setuptree;rpm -i kern1; mv rpmbuild rpmbuild.kern1; rpmdev-setuptree;rpm -i kern2; mv rpmbuild rpmbuild.kern2 d) start looking at the differences in the patches applied in kern1 vs. those in kern2, i.e., read/diff the kernel.spec files see if there were any new ones that seemed likely to be causing the problem... RTFS if necessary to make better guesses. Rebuild kernel 2 with patches taken out/modified based on my investigations and test them and see if I guessed right. If no luck, think about opening an TUV bug with lots of the info you have sent here, they may be interested even if you don't have a subscription.
[1] Been there, done that: http://www.gossamer-threads.com/lists/drbd/users/9616At first I figured this was misconfigured NTP but I actually see this happening on one of my machines as well. Nothing interesting about it in particular but I verified that rolling back to the previous kernel (2.6.18-194.32.1.el5) solves the problem entirely. This happens when NTP is enabled or disabled. I get the following error messages in dmesg which are possibly related.
time.c: can't update CMOS clock from 59 to 0 time.c: can't update CMOS clock from 59 to 0 time.c: can't update CMOS clock from 59 to 0 time.c: can't update CMOS clock from 59 to 0
The time drift is significantly higher than would be expected as normal. Because rolling back the kernel completely solves this issue, this must be a bug.
[root@nexus4 ~]# date; ntpdate -u pool.ntp.org http://pool.ntp.org Mon May 9 16:51:03 PDT 2011 9 May 16:50:21 ntpdate[22117]: step time server 207.182.243.123 offset -42.418572 sec
[root@nexus4 ~]# date; ntpdate -u pool.ntp.org http://pool.ntp.org Mon May 9 16:50:33 PDT 2011 9 May 16:50:35 ntpdate[22127]: step time server 207.182.243.123 offset -0.692146 sec
Yes, this is obviously a problem with the kernel interacting with the clock on some machines. IF we can figure out which ones and why, we can get upstream to fix it.
May I ask to try upstreams current kernel first http://people.redhat.com/jwilson/el5/ to make sure it's not already fixed there?
BTW: Those kernels have been very useful for me in the past and as this example shows may also be useful for others. The sad part is that the same doesn't apply for EL6 anymore because they don't make their dev kernels available anymore.
Simon
-
allan -
Brandon Ooi -
Brian -
Cal Webster -
Daniel J Walsh -
Denniston, Todd A CIV NAVSURFWARCENDIV Crane -
Johnny Hughes -
Mailing List -
Nataraj -
Peter Brady -
Rick Thomas -
Rob Kampen -
Simon Matter