Итак, я пытаюсь отладить свою текущую настройку NTP и обнаружил, что его смещение от моего единственного настроенного сервера составляет более 3 секунд и не регулируется. Звездочка на LOCAL (0) в выводе ntpq, кажется, указывает на то, что система успешно синхронизируется сама с собой, а не с сервером 10.130.33.201 (который является еще одним Linux-сервером в нашей системе, с которым мы хотим, чтобы все синхронизировалось).
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.130.33.201 LOCAL(0) 9 u 49 64 377 0.242 -3742.2 1.049
*LOCAL(0) .LOCL. 10 l 2 64 377 0.000 0.000 0.001
А это мой файл ntp.conf. Написано кем-то другим, поэтому я не уверен на 100%, что все правильно.
server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift
restrict -4 default nomodify nopeer notrap
restrict -6 default ignore
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
Я читал о burst, iburst и minpoll / maxpoll, поэтому я понимаю, что они могут не понадобиться, но я не думаю, что это имеет какое-либо отношение к моей текущей проблеме.
Кроме того, из-за того, как он развернут, для изменения этого файла конфигурации потребуется много работы, поэтому я надеюсь, что в действительности нет ничего, что нужно было бы менять. Я надеюсь, что это случай, когда я не понимаю, как работает NTP.
РЕДАКТИРОВАТЬ -
Итак, похоже, это дубликат Этот вопрос, но я не думаю, что этот плакат получил достаточный ответ, поэтому я все же хотел бы знать Зачем местное время предпочтительнее серверного. Кроме того, согласно одному из ответов ниже, я попытался использовать prefer
ключевое слово в строке конфигурации сервера и перезапустите, но, похоже, это не повлияло.
Если я удалю все «локальные» строки в конфигурации, как подсказывает ответ на другой вопрос, что произойдет, если сервер будет недоступен? NTP умирает или просто пытается?
ВАЖНОЕ РЕДАКТИРОВАНИЕ -
Хорошо, обычно 10.130.33.201 («сервер») не имеет доступа к Интернету и не имеет источника времени GPS для использования. Важная часть заключается в том, что все устройства в системе имеют то же время, что и сервер, независимо от того, насколько правильным оно является на самом деле.
Итак, чтобы посмотреть, что произойдет, я добавил один из серверов пула NTP в конфигурационный файл сервера, чтобы он получал время оттуда, а не от локального. Теперь он правильно получает время от сервера времени NTP.
После того, как я это сделал, клиенты теперь синхронизируются с сервером, а не предпочитают LOCAL (0)
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.130.33.201 38.229.71.1 3 u 58 64 377 0.216 715621. 1.001
LOCAL(0) .LOCL. 10 l 18 64 377 0.000 0.000 0.001
НОВЫЙ ВОПРОС - Когда мой сервер использует локальный (исходный пример, который был приведен), кажется, что клиенты говорят: «О, 10.130.33.201 использует ЛОКАЛЬНЫЙ (0). Хм, у меня также есть ЛОКАЛЬНЫЙ (0) сервер - - Я просто воспользуюсь этим напрямую, вместо того, чтобы получать ту же информацию через 10.130.33.201 ".
Так ли это? Пытаются ли они перейти «напрямую к источнику», который неверно является ЛОКАЛЬНЫМ (0)? Мне нужен мой сервер, чтобы получать время от ЛОКАЛЬНОГО (0), и мне нужно, чтобы клиенты получали время от сервера. На данный момент удаление «локального» сервера из файлов конфигурации клиента - единственный вариант, но я хотел бы понять, почему это происходит, и, если это вообще возможно, избегать изменения их конфигураций (изменение конфигурации потребует больших усилий из-за наше окружение...).
Также, этот выглядит как еще один дубликат без хорошего ответа.
Если настроен только один сервер NTP, алгоритм не совсем уверен, кому доверять. Несмотря на то, что уровень ниже для удаленного хоста, я уверен, что алгоритм считает, что местное время более надежно.
Попробуйте использовать prefer
ключевое слово с вашим server
заявление, чтобы установить это как предпочтительный источник времени.
РЕДАКТИРОВАТЬ -
Итак, похоже, что это дубликат этого вопроса, но я не думаю, что этот плакат получил достаточный ответ, поэтому мне все равно хотелось бы знать, почему местное время предпочтительнее, чем серверное.
Чтобы получить действительно достаточный ответ, вы будете копаться в недрах очень сложного алгоритма. В документации даже нет слишком конкретный, но я уверен, что там есть официальный документ или спецификация.
Если я удалю все «локальные» строки в конфигурации, как подсказывает ответ на другой вопрос, что произойдет, если сервер будет недоступен? NTP умирает или просто пытается?
Демон NTP не умирает и не останавливается, но он прекращает синхронизацию времени после того, как не может связаться с удаленным сервером. Вот почему лучшие практики предполагают наличие минимум трех удаленных серверов и не использовать LCL, если вы не отключены от сети. Предлагается три сервера, потому что, когда их всего два, и они не согласны, какой сервер выберет? Третий сервер должен помочь алгоритму устранить фиктивный сервер.
Наконец, я только что заметил, что вы не определяете driftfile
. Это может помочь?
Мне кажется, что интервал смещения (разница между вашим системным временем и временем хоста NTP) слишком сильно отличается для NTP, чтобы правильно его установить.
Мое предложение,
1. Stop the NTP service
2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
3. Start the NTP service
После этого у вас не должно возникнуть проблем.
Уровень 10.130.33.201 в качестве ЛОКАЛЬНОГО сервера равен 9, что заставляет локальный слой, рассчитанный из этого (9 + 1 = 10), конкурировать с локальным ЛОКАЛЬНЫМ сервером на уровне 10. Поскольку локальный ЛОКАЛЬНЫЙ слой не имеет сетевых задержек или дрожания, он может выглядеть немного лучше для ntpd, чем для удаленного.
Если вы хотите, чтобы эта конфигурация работала, установите «главный» ЛОКАЛЬНЫЙ сервер на уровень ниже 9. Не слишком низкий, если вы хотите, чтобы время, отслеживаемое до сервера уровня 1, было предпочтительным.
Я знаю, что это устарело, но думаю, вы правы. Никто не показывает способа отладки проблем с ntpd. Оказывается, это выполнимо.
Я думаю, вы были на правильном пути, когда заподозрили, что использование LOCAL (0) локально и на вышестоящем сервере может быть проблемой.
Это определенно было на острове времени из 4 серверов, с которыми у меня была аналогичная проблема. Все они были настроены как равные друг другу, так что, возможно, это другая проблема, чем ваша.
Во-первых, есть лучший способ работы с островками времени, называемый сиротским режимом, который поддерживается версиями ntpd последних нескольких лет:
Сиротский режим на doc.ntp.org
Первоначально все 4 сервера имели один и тот же слой из 10 и предпочитали свои локальные часы. Я исправил это, но они все равно предпочли свои местные часы (хотя страта кажется важной).
Я использовал команду ntpq pe (peer), as, rv, чтобы понять, что происходит. Вам нужно использовать rv (readvar) в номере ассоциации для сервера, чтобы вывести информацию. pe и as, похоже, отсортированы по одному индексу, поэтому таким образом можно получить число as. as имеет поле с именем condition, в котором может отображаться значение reject, если сервер ему не нравится.
На выходе rv есть поле, называемое flash. Если все хорошо, это будет ноль. Если нет, это битовая маска (отображается в шестнадцатеричном формате) проблем. Их можно посмотреть здесь:
У меня была проблема с 0800 peer_loop. Оказалось, что доработка часов важна. Увидев LOCAL (0) как на локальных часах, так и с удаленного сервера, ntpd подумал, что есть петля. Дэвид Миллс подтверждает, что в сообщениях на comp.protocols.time «Как избежать петель в NTP» (я достиг своего лимита в 2 ссылки, извините!)
Использование аргумента refid для fudge для установки уникального refid не сработало - он по-прежнему отображается как LOCAL (0) у получателя.
Что действительно работало, так это использование уникальных номеров экземпляров для локального драйвера. 127.127.1. [0-3]. Используйте один и тот же идентификатор как на сервере, так и на линии выдумки. Когда я это делал, серверы обычно синхронизировались с сервером нижнего уровня, который обычно использовал свои локальные часы. Однако иногда он пытался использовать один из других серверов, которые использовали его в качестве источника. Однако времена совпали и, похоже, так и остаются.
Возможно, уже слишком поздно, чтобы помочь, но я предлагаю это, чтобы показать, что NTP поддается логике и устранению неполадок. Мне потребовались часы, чтобы найти ответ методом проб и ошибок, а потом я нашел документы позже.
Используйте iburst, чтобы заставить сервер отправить запрос NTP на желаемый NTS, даже если один запрос не выполняется.