Предположим, на машине есть файл ntp.conf, который выглядит следующим образом:
дрифтфайл <path-to-drift-file>
сервер <NTP-server-1>
сервер <NTP-server-2>
сервер <NTP-server-2>
По какой-то причине допустим, что сервер NTP не запускается при первом запросе ко всем серверам. Можем ли мы заставить ntpd повторно запрашивать эти источники (т.е. снова обращаться к серверу 1 с сервером 3 в цикле)? Как мы это делаем?
Изменить: есть ли способ количественно определить, какой сервер вызвал фактическую синхронизацию времени из списка серверов, указанного в ntp.conf на машине?
Все определенные серверы в /etc/ntp.conf используются для синхронизации времени. Нет необходимости в том, чтобы он «перебирал» серверы, поскольку алгоритм уже обрабатывает несколько источников.
Программа ntpd работает путем обмена сообщениями с одним или несколькими сконфигурированными серверами через определенные интервалы опроса.
Из: человек ntpd
Вы можете увидеть это, выполнив ntpq -p в командной строке, чтобы показать коллег и их статус.
Вы можете увидеть результат, как показано здесь:
remote refid st when poll reach delay offset disp
========================================================================
+128.4.2.6 132.249.16.1 2 131 256 373 9.89 16.28 23.25
*128.4.1.20 .WWVB. 1 137 256 377 280.62 21.74 20.23
-128.8.2.88 128.8.10.1 2 49 128 376 294.14 5.94 17.47
+128.4.2.17 .WWVB. 1 173 256 377 279.95 20.56 16.40
Вывод также поясняется на страницах руководства. Но со временем я собрал несколько заметок:
удаленный: узлы, указанные в файле ntp.conf
* = текущий источник времени
# = источник выбран, расстояние превышает максимальное значение
o = выбран источник, используется частота импульсов в секунду (PPS)
+ = источник выбран, включен в окончательный набор
x = исходный ложный тикер
. = источник выбран из конца списка кандидатов
- = источник отброшен кластерным алгоритмом
blank = источник отброшен высокий уровень, рассудокисправлять: источник синхронизации удаленного источника
слой: stratum level источника
т: доступные типы
l = местный (например, GPS, WWVB)
u = одноадресная (наиболее распространенная)
m = многоадресная передача
b = трансляция
- = netaddrкогда: количество секунд, прошедших с момента последнего ответа
голосование: интервал опроса в секундах для источника
достичь: указывает на успех / неудачу в достижении источника, 377 все попытки успешны
задержка: указывает время приема-передачи в миллисекундах туда и обратно.
смещение: указывает разницу во времени в миллисекундах между клиентским сервером и источником.
дисп / джиттер: указывает разницу в миллисекундах между двумя выборками.
Наконец, чтобы ответить на последний вопрос;
Есть ли способ количественно определить, какой сервер вызвал фактическую синхронизацию времени из списка серверов, указанного в ntp.conf на машине?
Хост, обозначенный (*), является вашим текущим выбранным источником времени. Это может измениться во время опроса.
При запуске Ntpd опрашивает все настроенные серверы и выбирает тот, у которого самый низкий уровень. Если тот не сработает, он автоматически перейдет к следующему серверу. Так зачем вам это менять?
Википедия: Протокол сетевого времени - страты часов
Изменить: после проверки я нашел некоторую информацию о iburst параметр, который на самом деле предназначен для ускорения синхронизации часов. Разница здесь в том, что он заставит ntpd-сервер завершиться, когда он не сможет связаться ни с одним из серверов. Вы можете злоупотребить этим способом, чтобы убедиться, что экземпляр ntpd работает постоянно, например, используя сторожевой таймер или простой скрипт, время от времени запускаемый cron.
К сожалению, я не мог понять, как работает ntpd по умолчанию, когда сервер недоступен; хотя я нашел много ссылок о том, как он будет вести себя, когда серверы не разрешаются в DNS (например, эта ошибка) или когда интерфейс выходит из строя.