2

RHEL 5 workstation. Has been running smoothly for years. I did a 'pup' recently and followed with a nice, cleansing reboot. Afterwards the system had some startup issues: namely MySQL refused to start. It just went "...." for 5-10 minutes before I did another boot and skipped that step (using 'interactive'). This was the only service that didn't wan't to start normally.

So now that the system is booted I've found that it doesn't want to stay in sync with the NTP master and after 48 hours is refusing any SSH other than root.

NTPD: this service starts normally and gets a lock on 4 servers. Almost immediately it starts to lose ground and now (after 3 days) is almost 40 hours behind. If I stop/start the service it gets the lock, resets the system clock and starts losing ground again. The 'hwclock' is set properly and maintains its time.

Login: when I (re)start the ntp server I am able to login normally. I assume this problem is due to losing sync with LDAP. This appears to be verified by LDAP errors in /var/log/messages.

Suggestions on where to look?

ADDENDA: Tried deleting the 'drift' file. After a bit it gets recreated with 0.000.

from /var/log/messages:

Jan 17 06:54:01 aeolus ntpdate[5084]: step time server 129.95.96.10 offset 30.139216 sec
Jan 17 06:54:01 aeolus ntpd[5086]: ntpd 4.2.2p1@1.1570-o Tue Oct 25 12:54:17 UTC 2011 (1)
Jan 17 06:54:01 aeolus ntpd[5087]: precision = 1.000 usec
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface wildcard, 0.0.0.0#123 Disabled
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface wildcard, ::#123 Disabled
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface lo, ::1#123 Enabled
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface eth0, fe80::213:72ff:fe20:4080#123 Enabled
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface lo, 127.0.0.1#123 Enabled
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface eth0, 10.127.24.81#123 Enabled
Jan 17 06:54:01 aeolus ntpd[5087]: kernel time sync status 0040
Jan 17 06:54:02 aeolus ntpd[5087]: frequency initialized 0.000 PPM from /var/lib/ntp/drift
Jan 17 06:54:02 aeolus ntpd[5087]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)

You can see the 30 second offset. This was after about one minute of operation.

Improve this question
2
  • 1
    Howdy, few details that I need. When the clock is not synced, ntpdate -d <time-server>, ntpq -pn, ntpdc -c kerninfo, ntpdc -c loopinfo. Run ntpq in root prompt and then run associations and rv on association-id. Pastebin the entire output, don't forget to put /etc/ntp.conf and /etc/sysconfig/ntpd. Lots of asking but I have seen that nothing about ntp code is eye-soothing.
    – Soham Chakraborty
    Aug 18, 2013 at 15:58
  • Check that ntpd.conf has a valid server entry. Make sure the server is contactable and you're allowed to use it. Then follow the suggested answers people have provided.
    – hookenz
    Mar 10, 2014 at 9:25

2 Answers 2

Reset to default
2

I would recomend to delete the drift file, stop the NTP daemon and then execute an ntpdate prior to starting the service. What I understand is that your hardware clock has a problem.

Improve this answer
1

As you may know, ntpd tries to measure the drift of the internal hardware clock and adjust the system's clocks accordingly (in case the server cannot be contacted, and to prevent excessive synchronizations). The value of the drift is stored in a file; usually /etc/ntp/drift (depends on your distro). It sounds like somehow a wrong value is noted in there; or some other changed parameters (power consumption etc.) have influenced the hardware characteristics in such a way that this stored drift value is no longer correct.

Stop the daemon, rename/remove the file (or just empty it), and start the daemon again. It will measure drift from scratch over the next few days and act accordingly.

LDAP and SSH (among other login services), rely on having the involved systems not having too much discrepancy of their system clocks, so if you're off by 40 hours, its completely natural they get all upset. :)

Improve this answer
3
  • Would I see a fix to 'date' immediately or does this need a few days to correct as well? I emptied /var/log/drift, bounced the service and am seeing the system clock lag behind almost immediately.
    – ethrbunny
    Jan 16, 2012 at 17:05
  • 1
    This depends on your configuration. But usually ntpd, having no drift file, should work in a special mode for at least 15 minutes, after that, time&frequency should have stabilized. But this requires the drift not to be too large. Do you see anything strange in the logs? If so, please update your question with those messages.
    – Roman
    Jan 17, 2012 at 13:05
  • Edits in original entry.
    – ethrbunny
    Jan 17, 2012 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.