Рабочая станция RHEL 5. Работает без сбоев в течение многих лет. Недавно я сделал «щенок», после чего сделал приятную очищающую перезагрузку. После этого у системы возникли проблемы с запуском: именно MySQL отказывался запускаться. Он просто "...." в течение 5-10 минут, прежде чем я сделал еще одну загрузку и пропустил этот шаг (используя "интерактивный"). Это была единственная служба, которая нормально не запускалась.
Итак, теперь, когда система загружена, я обнаружил, что она не хочет оставаться в синхронизации с мастером NTP и через 48 часов отказывается от любого SSH, кроме root.
NTPD: эта служба запускается нормально и блокируется на 4 серверах. Практически сразу начинает сдавать позиции и теперь (через 3 дня) отстает почти на 40 часов. Если я останавливаю / запускаю службу, она блокируется, сбрасывает системные часы и снова начинает терять позиции. «Hwclock» настроен правильно и поддерживает свое время.
Вход: когда я (повторно) запускаю ntp-сервер, я могу войти в систему как обычно. Я предполагаю, что эта проблема связана с потерей синхронизации с LDAP. Это подтверждается ошибками LDAP в / var / log / messages.
Предложения, где искать?
ДОБАВЛЕНИЕ: Пытался удалить файл "дрейф". Через некоторое время он воссоздается с 0,000.
из / 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)
Вы можете увидеть 30-секундное смещение. Это произошло примерно через минуту работы.
Я бы рекомендовал удалить дрейфовый файл, остановить демон NTP, а затем выполнить ntpdate перед запуском службы. Я понимаю, что у ваших аппаратных часов проблема.
Как вы, возможно, знаете, ntpd пытается измерить дрейф внутренних аппаратных часов и соответствующим образом настроить системные часы (в случае, если с сервером невозможно связаться, и для предотвращения чрезмерной синхронизации). Значение смещения сохраняется в файле; обычно /etc/ntp/drift (зависит от вашего дистрибутива). Похоже, что там указано неправильное значение; или некоторые другие измененные параметры (потребляемая мощность и т. д.) повлияли на характеристики оборудования таким образом, что это сохраненное значение дрейфа больше не является правильным.
Остановите демон, переименуйте / удалите файл (или просто очистите его) и снова запустите демон. Он будет измерять дрейф с нуля в течение следующих нескольких дней и действовать соответствующим образом.
LDAP и SSH (среди других служб входа в систему) полагаются на то, что задействованные системы не имеют слишком больших расхождений с их системными часами, поэтому, если вы отключитесь на 40 часов, совершенно естественно, что они все расстроятся. :)