Сервер Ubuntu время от времени теряет ровно 5 минут
Я заметил, что мой сервер, сервер Ubuntu 12.04, теряет время. Я полагал, что аппаратные часы были выключены или, возможно, умирают из-за неисправной батареи CMOS. Я установил NTP, чтобы гарантировать исправление дрейфа, но безрезультатно. В течение дня он потерял бы около 20 минут.
Для отладки я создал небольшое задание cron для проверки времени удаленных серверов, которое, как я знал, было правильным. Скрипт рассчитывает разницу в секундах между местным и удаленным временем. Служба NTP не работала во время этих тестов.
Результат был интересным. Кажется, он теряет ровно 5 минут несколько раз в течение дня. Посмотрите на этот журнал (отличие от удаленного сервера отмечено в секундах):
Tue Oct 23 03:30:02 CEST 2012: 284
Tue Oct 23 03:35:02 CEST 2012: 284
Tue Oct 23 03:40:01 CEST 2012: 285
Tue Oct 23 03:45:02 CEST 2012: 285
Tue Oct 23 03:50:02 CEST 2012: 285
Tue Oct 23 03:55:02 CEST 2012: 284
Tue Oct 23 04:00:02 CEST 2012: 284
Tue Oct 23 04:05:01 CEST 2012: 285
Tue Oct 23 04:10:01 CEST 2012: 285
Tue Oct 23 04:15:02 CEST 2012: 585
Tue Oct 23 04:20:02 CEST 2012: 584
Tue Oct 23 04:25:02 CEST 2012: 584
Tue Oct 23 04:30:02 CEST 2012: 584
Tue Oct 23 04:35:01 CEST 2012: 585
Tue Oct 23 04:40:01 CEST 2012: 585
Tue Oct 23 04:45:02 CEST 2012: 585
Tue Oct 23 04:50:02 CEST 2012: 584
Tue Oct 23 04:55:02 CEST 2012: 584
Tue Oct 23 05:00:02 CEST 2012: 584
Tue Oct 23 05:05:01 CEST 2012: 585
Tue Oct 23 05:10:01 CEST 2012: 585
Tue Oct 23 05:15:02 CEST 2012: 585
Tue Oct 23 05:20:02 CEST 2012: 584
Tue Oct 23 05:25:02 CEST 2012: 584
Tue Oct 23 05:30:02 CEST 2012: 584
Tue Oct 23 05:35:01 CEST 2012: 585
Tue Oct 23 05:40:01 CEST 2012: 585
Tue Oct 23 05:45:02 CEST 2012: 584
Tue Oct 23 05:50:02 CEST 2012: 584
Tue Oct 23 05:55:02 CEST 2012: 584
Tue Oct 23 06:00:02 CEST 2012: 584
Tue Oct 23 06:05:03 CEST 2012: 584
Tue Oct 23 06:10:02 CEST 2012: 584
Tue Oct 23 06:15:01 CEST 2012: 585
Tue Oct 23 06:20:02 CEST 2012: 584
Tue Oct 23 06:25:02 CEST 2012: 584
Tue Oct 23 06:30:02 CEST 2012: 584
Tue Oct 23 06:35:02 CEST 2012: 584
Tue Oct 23 06:40:02 CEST 2012: 584
Tue Oct 23 06:45:01 CEST 2012: 585
Tue Oct 23 06:50:02 CEST 2012: 584
Tue Oct 23 06:55:01 CEST 2012: 585
Tue Oct 23 07:00:02 CEST 2012: 584
Tue Oct 23 07:05:02 CEST 2012: 584
Tue Oct 23 07:10:02 CEST 2012: 584
Tue Oct 23 07:15:02 CEST 2012: 584
Tue Oct 23 07:20:02 CEST 2012: 584
Tue Oct 23 07:25:02 CEST 2012: 584
Tue Oct 23 07:30:01 CEST 2012: 585
Tue Oct 23 07:35:02 CEST 2012: 584
Tue Oct 23 07:40:02 CEST 2012: 584
Tue Oct 23 07:45:02 CEST 2012: 584
Tue Oct 23 07:50:02 CEST 2012: 584
Tue Oct 23 07:55:02 CEST 2012: 584
Tue Oct 23 08:00:01 CEST 2012: 585
Tue Oct 23 08:05:02 CEST 2012: 584
Tue Oct 23 08:10:02 CEST 2012: 584
Tue Oct 23 08:15:02 CEST 2012: 584
Tue Oct 23 08:20:02 CEST 2012: 584
Tue Oct 23 08:25:02 CEST 2012: 584
Tue Oct 23 08:30:01 CEST 2012: 585
Tue Oct 23 08:35:02 CEST 2012: 584
Tue Oct 23 08:40:02 CEST 2012: 584
Tue Oct 23 08:45:02 CEST 2012: 584
Tue Oct 23 08:50:02 CEST 2012: 584
Tue Oct 23 08:55:02 CEST 2012: 584
Tue Oct 23 09:00:02 CEST 2012: 584
Tue Oct 23 09:05:03 CEST 2012: 584
Tue Oct 23 09:10:02 CEST 2012: 584
Tue Oct 23 09:15:02 CEST 2012: 584
Tue Oct 23 09:20:02 CEST 2012: 584
Tue Oct 23 09:25:02 CEST 2012: 584
Tue Oct 23 09:30:01 CEST 2012: 584
Tue Oct 23 09:35:02 CEST 2012: 584
Tue Oct 23 09:40:02 CEST 2012: 584
Tue Oct 23 09:45:02 CEST 2012: 584
Tue Oct 23 09:50:02 CEST 2012: 584
Tue Oct 23 09:55:02 CEST 2012: 584
Tue Oct 23 10:00:01 CEST 2012: 584
Tue Oct 23 10:05:02 CEST 2012: 584
Tue Oct 23 10:10:07 CEST 2012: 584
Tue Oct 23 10:15:02 CEST 2012: 584
Tue Oct 23 10:20:02 CEST 2012: 884
Tue Oct 23 10:25:02 CEST 2012: 884
Tue Oct 23 10:30:02 CEST 2012: 883
Tue Oct 23 10:35:01 CEST 2012: 884
Tue Oct 23 10:40:02 CEST 2012: 884
Tue Oct 23 10:45:02 CEST 2012: 884
Tue Oct 23 10:50:02 CEST 2012: 884
Tue Oct 23 10:55:02 CEST 2012: 1184
Tue Oct 23 11:00:02 CEST 2012: 1183
Tue Oct 23 11:05:01 CEST 2012: 1184
Tue Oct 23 11:10:02 CEST 2012: 1184
Tue Oct 23 11:15:02 CEST 2012: 1184
Tue Oct 23 11:20:02 CEST 2012: 1184
На мой взгляд, это не является неисправной батареей CMOS. Но что вы думаете?
РЕДАКТИРОВАТЬ:
Когда я включаю NTP, это вывод ntpq -p:
remote refid st t when poll reach delay offset jitter
==============================================================================
dns02.wsrs.net .INIT. 16 u - 64 0 0.000 0.000 0.000
brick.steinhoff 71.40.128.157 3 u 1 64 1 144.031 1499785 0.002
chime6.surfnet. .PPS. 1 u - 64 1 22.663 1499789 0.002
ntp0.mediamatic .INIT. 16 u - 64 0 0.000 0.000 0.002
europium.canoni .INIT. 16 u - 64 0 0.000 0.000 0.002
РЕДАКТИРОВАТЬ 2:
После ntpdate ntp.ubuntu.com
remote refid st t when poll reach delay offset jitter
==============================================================================
kvm01.roethof.n 213.154.236.182 3 u 10 64 1 34.918 -1.980 0.002
ntp0.bbactive.e 193.79.237.14 2 u 9 64 1 58.378 6.956 0.002
16-164-ftth.ons 193.79.237.14 2 u 8 64 1 30.202 5.697 0.002
kameli.miuku.ne 62.237.86.238 2 u 7 64 1 106.975 -9.806 0.002
europium.canoni 193.79.237.14 2 u 6 64 1 42.010 6.381 0.002
1 ответ
Я полагал, что аппаратные часы были выключены или, возможно, умирают из-за неисправной батареи CMOS.
Часы CMOS считываются только при загрузке операционной системы.
Я установил NTP, чтобы гарантировать исправление дрейфа, но безрезультатно.
NTP не предназначен для исправления огромного смещения. Вы можете сделать это исправление, используя ntpdate, затем запустите ntpd и через несколько часов проверьте ntpq -p и убедитесь, что вы понимаете, что он говорит вам. Тогда посмотрите в системном журнале жалобы NTP.
NTP работает, и все же иногда он теряет 300 секунд в любом случае
Если это так, я ожидаю увидеть комментарий NTP по этому поводу в системном журнале - он точно скажет вам, когда возникнет проблема. Возможно, это совпадает с работой cron или каким-то внешним событием. Я бы следил за такими подсказками. Я предполагаю, что вы заметите, если аппаратный сбой замораживает систему на 5 минут за раз.
Устранение неполадок NTP
Я прочитал Устранение неполадок NTP, особенно раздел "Известные проблемы".
Время мониторинга
У Гарольда уже есть сценарий, для других вот пара идей:
На badserver включите протокол времени RFC868
vi /etc/xinetd.d/time-stream
# change `disable=yes` to `disable=no`
kill -HUP $(cat /var/run/xinetd.pid)
На goodserver используйте cron для планирования раз в минуту
date -u; TZ=utc rdate badserver > /tmp/badserver-time.log
Или лучше написать сценарий, который регистрирует только неудачные ответы или большие изменения в смещении между goodserver и badserver.