ntpd -g не синхронизирует часы
Из ntpd справочной страницы
Если время больше 1000 с от времени сервера, ntpd предполагает, что что-то ужасно неправильно, и единственное надежное действие - чтобы оператор мог вмешаться и вручную установить часы. Это заставляет ntpd выйти с сообщением о панике в системный журнал. Параметр -g отменяет эту проверку, и часы будут установлены на время сервера независимо от времени чипа .
Я провел небольшой эксперимент, чтобы проверить параметр -g с ntpd. Сначала я изменил время системных часов на какое-то старое с помощью команды date.
date -s 2021.06.15-19: 10: 21
После этого я создал небольшой /etc/ntp.conf файл с информацией ниже
driftfile /etc/ntp.drift
logconfig =syncstatus
server time.google.com minpoll 3 maxpoll 4
После этого я запустил ntpd с помощью следующей команды
ntpd -g -n -4 -c /etc/ntp.conf &
Обратите внимание, что мой файл ntp.drift был пуст.
Я не вижу изменений в системном времени, фактически статус ntp показывает, что часы не синхронизированы.
GW:/# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
time2.google.co .GOOG. 1 u - 64 1 0.000 +0.000 0.000
Clock is not synchronized, stratum 16, reference is INIT
frequency is +0.000 Hz, precision is -19
reference time is (no time),
clock offset is +0.000000 msec, root delay is 0.000 msec
root dispersion is N/A
Кто-нибудь, пожалуйста, помогите мне. Я пропустил какую-то конфигурацию или какие-то другие данные.
Помимо этого, у меня есть один небольшой вопрос.
Нужно ли синхронизировать часы ntp для аутентификации по протоколу ntp? Если часы ntp не синхронизированы, тогда аутентификация сервера ntp будет пройдена.
Редактировать:
Ниже приведены журналы, которые появляются, когда я запускаю ntpd
GW:~/var/log# cat ntpd.log
15 Jun 19:21:03 ntpd[14560]: Listen and drop on 0 v4wildcard 0.0.0.0:123
15 Jun 19:21:03 ntpd[14560]: Listen normally on 1 lo 127.0.0.1:123
15 Jun 19:21:03 ntpd[14560]: Listen normally on 2 srcr2 192.168.0.2:123
15 Jun 19:21:03 ntpd[14560]: Listen normally on 3 log0 1.0.0.1:123
15 Jun 19:21:03 ntpd[14560]: Listening on routing socket on fd #20 for interface updates
15 Jun 19:21:03 ntpd[14560]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
15 Jun 19:21:03 ntpd[14560]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
Обновление :
@John Я сделал все, что вы предлагали, но все же вижу ту же проблему
GW:~/var/log# systemctl status ntpd
ntpd.service - NTPD daemon
Loaded: loaded (/etc/systemd/system/ntpd.service; disabled; vendor preset: enabled)
Active: active (running) since Fri 2021-07-09 08:17:46 UTC; 6min ago
Process: 21151 ExecStart=/bin/sh -c /sbin/ntpd -g >> /var/log /ntpd.log 2>&1 (code=exited, status=0/SUCCESS)
Main PID: 21153 (ntpd)
CGroup: /system.slice/ntpd.service
└─21153 /sbin/ntpd -g
cat /etc/ntp.conf
# use a random selection of 4 public stratum 2 servers
# see http://twiki.ntp.org/bin/view/Servers/NTPPoolServers
#restrict default nomodify notrap noquery
#restrict default noquery
logfile /var/log/ntpd.log
driftfile /etc/ntp.drift
logconfig =syncstatus
server time1.google.com iburst
server time2.google.com iburst
server time3.google.com iburst
server time4.google.com iburst
#tried pool time.google.com also
GW:~/var/log# ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 8426 9014 yes yes none reject reachable 1
2 8427 9014 yes yes none reject reachable 1
3 8428 9014 yes yes none reject reachable 1
4 8429 9014 yes yes none reject reachable 1
GW:~/var/log# ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
time1.google.co .GOOG. 1 u - 64 377 0.000 +0.000 0.000
time2.google.co .GOOG. 1 u - 64 377 0.000 +0.000 0.000
time3.google.co .GOOG. 1 u - 64 377 0.000 +0.000 0.000
time4.google.co .GOOG. 1 u - 64 377 0.000 +0.000 0.000
GW:~/var/log# cat ntpd.log
9 Jul 08:17:46 ntpd[21153]: Listen and drop on 0 v6wildcard [::]:123
9 Jul 08:17:46 ntpd[21153]: Listen and drop on 1 v4wildcard 0.0.0.0:123
9 Jul 08:17:46 ntpd[21153]: Listen normally on 2 lo 127.0.0.1:123
9 Jul 08:17:46 ntpd[21153]: Listen normally on 3 srcr2 192.168.0.2:123
9 Jul 08:17:46 ntpd[21153]: Listen normally on 4 log0 1.0.0.1:123
9 Jul 08:17:46 ntpd[21153]: Listening on routing socket on fd #21 for interface updates
9 Jul 08:17:46 ntpd[21153]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
9 Jul 08:17:46 ntpd[21153]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
GW: ~ / var / log #
Не могли бы вы проверить еще раз. Я что-то пропустил?
Обновление
Pasting ntpd association output
GW:/# ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 47211 9014 yes yes none reject reachable 1
2 47212 9014 yes yes none reject reachable 1
3 47213 9014 yes yes none reject reachable 1
4 47214 9014 yes yes none reject reachable 1
GW: / # GW: / #
GW:/# ntpq -c "rv 47211"
associd=47211 status=9014 conf, reach, sel_reject, 1 event, reachable,
srcadr=time1.google.com, srcport=123, dstadr=192.168.0.2, dstport=123,
leap=00, stratum=1, precision=-20, rootdelay=0.000, rootdisp=0.107,
refid=GOOG, reftime=e4a0073d.cba4777a Mon, Jul 19 2021 14:14:21.795,
rec=e4a0073d.cba4777b Mon, Jul 19 2021 14:14:21.795, reach=017,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=347,
flash=400 peer_dist, keyid=0, offset=+0.000, delay=0.000,
dispersion=15937.500, jitter=0.000, xleave=0.033,
filtdelay= 2833222 2833222 2833222 2833222 2833222 2833222 2833222 2833222,
filtoffset= +141661 +141661 +141661 +141661 +141661 +141661 +141661 +141661,
filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
Обычно после разрешения NTP через любой брандмауэр обрабатываются первые несколько пакетов (увеличивающаяся досягаемость), выбирается одноранговый узел системы, и на начальном этапе фиксируется время. У этой системы есть доступные одноранговые узлы, но они все отвергнуты, что странно.
После просмотра вывода readvar, rootdelay = 0,000 не имеет смысла. Удаленный через Интернет, не может быть нулевым. Возможно, почему вы получили мгновенное сообщение о превышении порогового значения расстояния.
Теория из IRC состоит в том, что пакеты NTP искажаются каким-то промежуточным ящиком. Что, если правда, было бы плохо, поскольку это, по-видимому, нарушило NTP. ntpd применяет dscp к своим пакетам, а ntpdate - нет. Попробуйте dscp 0 в ntp.conf Спросите, есть ли на пути блоки поддержки дифференцированных служб. Возьмите захват пакета (tcpdump) пакетов NTP и посмотрите его в Wireshark. Посмотрите, сможет ли он проанализировать оба поля DSCP, заключив пакеты NTP с отметками времени NTP.
Также изучите ntpd в совершенно другой сети, чтобы сравнить, как он выглядит во время работы. ntpd может работать на чем угодно, возможно, на виртуальной машине на вашей рабочей станции.
Мой первоначальный ответ с критикой конфигурации следует ниже.
Ваш зарегистрированный охват составляет всего 1. Подождите 3 минуты после запуска ntpd. Требуется некоторое время, чтобы вернуть первую пару пакетов.
Относительно вашей конфигурации:
server time.google.com minpoll 3 maxpoll 4
Рассмотрите возможность добавления iburst в строки вашего сервера и пула. Первоначальная пачка при запуске нескольких пакетов с небольшой задержкой.
Я не уверен, что настройка minpool и maxpool - хорошая идея, ни Red Hat . Слишком часто в течение длительного периода, и общедоступные службы NTP могут заблокировать вас. ntpd уже хорошо умеет динамически выбирать интервал пула.
Требуется больше серверов NTP, в идеале 4 для обнаружения фальшивомонетчиков с избыточностью n + 1. Общедоступный NTP Google имеет 4 внешних интерфейса, которые можно использовать либо с директивой pool , либо с несколькими строками сервера. Не стесняйтесь добавлять другие службы NTP в качестве второго мнения, например 2.pool.ntp.org . (Однако, если ваши серверы NTP не согласятся с этим, вы получите беспорядочную дополнительную ошибку .)
Нет, общедоступные службы NTP не требуют аутентификации NTP. Аутентификация - это не ваша проблема, она позволяет выполнять большие шаги и настраивать частоту опроса.
Мое предлагаемое изменение для строки сервера больше похоже на это:
pool time.google.com iburst
Что касается того, как вы запускаете ntpd:
ntpd -g -n -4 -c /etc/ntp.conf &
-g параметр необходим для исправления такого большого смещения в несколько часов, оставьте его . Позволяет бесконечный шаг один раз при запуске. Обычно большое смещение вызывает панику ntpd. Используйте -g в любом скрипте, который запускает ntpd, поэтому время будет фиксировано при загрузке.
Я не вижу смысла в использовании фона без вилки и оболочки. Для запуска в фоновом режиме я использую системный диспетчер служб или сценарий инициализации. Например, модуль ntpd.service для Linux с systemd.
Удалить -4 . Google поддерживает IPv6.
Если вы хотите установить время один раз и выйти, полезна опция -q .Для интерактивного использования при устранении неполадок при нормальной работе ntpd остается запущенным. Не используйте устаревшую версию ntpdate.
ntpd -g -q