3

Я заметил, что мой сервер, сервер 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 ответ1

2

Я подумал, что аппаратные часы были выключены или, возможно, умирают из-за неисправной батареи 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.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .