RHEL 5工作站。 多年来一直顺利运行。 我最近做了一个“小狗”，然后进行了一个很好的清洁重新启动。 之后系统有一些启动问题：即MySQL拒绝启动。 它只是“…”5-10分钟，然后我再次启动，并跳过这一步（使用“互动”）。 这是唯一不会不正常启动的服务。
所以现在系统已经启动了，我发现它不想和NTP主服务器保持同步，并且在48小时之后拒绝除root以外的任何SSH。
NTPD：这项服务正常启动并获得4台服务器的locking。 几乎立即开始失地，现在（3天后）已经落后了将近40个小时。 如果我停止/启动服务，它将获得locking，重置系统时钟并重新开始丢失地面。 “hclock”设置正确并保持其时间。
login：当我（重新）启动ntp服务器，我可以正常login。 我认为这个问题是由于与LDAP失去同步。 这似乎是由/ var / log / messages中的LDAP错误validation的。
build议在哪里看？
附加信息：试图删除“漂移”文件。 有一点后，它被0.000重新创build。
从/ 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 [email protected] 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) 你可以看到30秒的偏移量。 这是大约一分钟的操作之后。
我build议删除漂移文件，停止NTP守护进程，然后在启动服务之前执行ntpdate。 我的理解是你的硬件时钟有问题。
您可能知道，ntpd会尝试测量内部硬件时钟的漂移，并相应地调整系统时钟（以防服务器无法联系，并防止过度同步）。 漂移的值存储在一个文件中; 通常是/etc/ntp/drift （取决于你的发行版）。 这听起来似乎有一个错误的价值， 或者一些其他改变的参数（功耗等）已经影响了硬件特性，使得这个存储的漂移值不再是正确的。
停止守护进程，重命名/删除文件（或只是清空它），并再次启动守护进程。 它将在接下来的几天内从头测量漂移，并采取相应的行动。
LDAP和SSH（以及其他login服务）都依赖于所涉及的系统没有太多的系统时钟差异，所以如果你closures了40个小时，那么完全自然就会让所有人感到不安。 🙂