FAQ
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6022 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.centos.org/pipermail/centos/attachments/20110413/d4e63cdf/attachment.bin

Search Discussions

  • Mailing List at Apr 13, 2011 at 11:31 am

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

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110413/0df8710a/attachment.bin
  • Rob Kampen at Apr 13, 2011 at 1:08 pm

    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. 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.
    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: rkampen.vcf
    Type: text/x-vcard
    Size: 322 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20110413/15f9548f/attachment.vcf
  • Mailing List at Apr 13, 2011 at 2:42 pm

    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.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110413/6fe6e2a7/attachment.bin
  • Cal Webster at Apr 13, 2011 at 2:50 pm

    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. 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.
    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_Guide/s1-dateconfig-ntp.html
    /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
  • Cal Webster at Apr 13, 2011 at 2:55 pm

    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=%28centosplus%29
  • Mailing List at Apr 13, 2011 at 3:10 pm

    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_Guide/s1-dateconfig-ntp.html
    /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






    _______________________________________________
    CentOS mailing list
    CentOS at 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.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110413/ad53fa59/attachment.bin
  • Cal Webster at Apr 13, 2011 at 3:35 pm

    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 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.
    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
  • Daniel J Walsh at Apr 13, 2011 at 4:00 pm

    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 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.
    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 at 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.
  • Cal Webster at Apr 13, 2011 at 4:12 pm
    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
  • Mailing List at Apr 13, 2011 at 4:22 pm

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

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110413/8c10fca8/attachment.bin
  • Denniston, Todd A CIV NAVSURFWARCENDIV Crane at Apr 13, 2011 at 5:07 pm

    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at 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.
  • Cal Webster at Apr 13, 2011 at 5:24 pm

    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 at 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 at 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
  • Mailing List at Apr 13, 2011 at 5:42 pm

    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.


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110413/b365674b/attachment.bin
  • Cal Webster at Apr 13, 2011 at 6:01 pm

    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
  • Mailing List at Apr 13, 2011 at 6:27 pm

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

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110413/5163f04e/attachment.bin
  • Peter Brady at Apr 13, 2011 at 6:39 pm

    On 14/04/11 7:42 AM, Mailing List wrote:
    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
    <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
  • Denniston, Todd A CIV NAVSURFWARCENDIV Crane at Apr 13, 2011 at 7:16 pm

    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at 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 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
    <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.
  • Peter Brady at Apr 13, 2011 at 7:45 pm

    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
  • Allan at Apr 14, 2011 at 3:27 am

    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 at 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 at 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 at 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
  • Johnny Hughes at Apr 14, 2011 at 6:47 am

    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. 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.
    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)?

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110414/e4fd0291/attachment.bin
  • Mailing List at Apr 14, 2011 at 7:23 am

    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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110414/fa1ffb1e/attachment.html
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110414/fa1ffb1e/attachment.bin
  • Simon Matter at Apr 14, 2011 at 7:28 am

    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
  • Cal Webster at Apr 14, 2011 at 8:34 pm

    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
  • Johnny Hughes at Apr 15, 2011 at 7:08 am

    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. 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.
    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?

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110415/ae732da8/attachment.bin
  • Nataraj at Apr 15, 2011 at 11:42 am

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

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110415/7c0bf8c7/attachment.html
  • Mailing List at Apr 15, 2011 at 4:58 pm

    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



    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110415/87c7177c/attachment.bin
  • Mailing List at Apr 15, 2011 at 5:14 pm

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

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110415/0cc15ca0/attachment.bin
  • Brian at Apr 16, 2011 at 10:18 am

    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. 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.
    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
  • Mailing List at Apr 20, 2011 at 10:23 am

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

    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.


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110420/c381ff33/attachment.bin
  • Rick Thomas at Apr 20, 2011 at 5:45 pm

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

    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
  • Mailing List at Apr 20, 2011 at 6:06 pm

    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

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110420/92cf0abf/attachment.bin
  • Mailing List at Apr 25, 2011 at 1:56 pm

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

    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.




    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 6022 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110425/1a670681/attachment.bin
  • Denniston, Todd A CIV NAVSURFWARCENDIV Crane at Apr 25, 2011 at 3:47 pm

    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at 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 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/9616
  • Brandon Ooi at May 9, 2011 at 7:53 pm

    On Mon, Apr 25, 2011 at 12:47 PM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane wrote:


    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at 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/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 at 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 at 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110509/97d99d52/attachment.html
  • Johnny Hughes at May 12, 2011 at 10:09 am

    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 at navy.mil wrote:


    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org <mailto:centos-bounces at 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/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 at 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 at 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.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110512/e35d6c05/attachment.bin
  • Simon Matter at May 12, 2011 at 1:06 pm

    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 at navy.mil wrote:


    -----Original Message-----
    From: centos-bounces at centos.org <mailto:centos-bounces at centos.org>
    [mailto:centos-bounces at centos.org
    <mailto:centos-bounces at 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/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 at 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 at 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedApr 13, '11 at 7:35a
activeMay 12, '11 at 1:06p
posts37
users13
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase