NTP працює, системний годинник все ще не вчасно - що дає?

Запущений сервер Debian (5.0.3) ntpdта підключений до Інтернету. Тим не менш, системний годинник не так близько 5 хвилин.

$ /etc/init.d/ntp status
NTP server is running..

Відповідні частини (я думаю) про /etc/ntp.conf:

driftfile /var/lib/ntp/ntp.drift

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org

Я знаю, що NTP не обов'язково приносить годинник вчасно. Тим не менше, скільки годин або днів потрібно чекати, щоб обгрунтовано очікувати, що NTP зробив свою роботу і синхронізував годинник?

Я пропускаю якийсь інший конфігураційний файл чи параметр, або я щось щось неправильно роблю? Чи правильним інструментом для цього є ntp (замість, наприклад, ntpdate )? Чи є швидкий спосіб перевірити правильність конфігурації та повернути вибрані сервери NTP правильний час?

Редагувати : вихід ntpq -p:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ns1.nexellent.n .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-madrid .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 sinister.wzw.tu .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-frankf .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Edit 2 : Вимикає ntpdate -u 0.europe.pool.ntp.orgкоманду ( запропоновану brent )

17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found

... навіть якщо на інших машинах команда працює чудово. Тож ми розглянемо параметри мережі / брандмауера для цього конкретного сервера (який знаходиться в іншій мережі, доступ до якої здійснюється через VPN).

Розв’язання . Винувателем був не локальний брандмауер на нашому сервері, а налаштування брандмауера десь у навколишній мережі. Тож ми попросили постачальника хостингових серверів дозволити NTP для наших машин, і тепер він працює добре. Наприклад, ntpq -pтепер повертає:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ns1.eunet.fi    192.36.144.23    2 u   10   64    1    1.043    0.258   0.001
 ns2.eunet.fi    62.142.10.44     2 u    9   64    1    0.671    0.135   0.001
 ns3.eunet.fi    62.142.10.44     2 u    8   64    1    0.750    0.277   0.001

(Ми також перейшли на сервери eunet.fi, відновлені хостинговою компанією, але це поруч із цим.) Команди у відповіді brent були корисними, оскільки вони змусили мене зрозуміти, що проблема полягає в доступі до мережі до серверів NTP, а не в конфігурації NTP себе. Дякую всім!

Зупинити ntpd, запустити ntpdate -u 0.europe.pool.ntp.org3 рази, запустити ntpd, перевірити ntpq -p, затримка, зміщення та тремтіння повинно бути не нульовим.

Якби мені довелося здогадатися, чому і якщо припустити, що ти маєш мережеве підключення і можеш без проблем бачити свій хост NTP, то, можливо, ти перейшов до великого значення. Якщо різниця у часі більша за X (Вибачте, я не пам’ятаю, що X є вільним), буде надруковано попередження і час не синхронізується. Ви можете перевірити свої систематичні повідомлення на випадки цього.

Якщо це так, зупиніть NTP, запустіть хост ntpdate та перезапустіть NTPD, це змусить синхронізувати час, тоді почніть тримати його синхронізацію вперед, якщо ви продовжуєте дрейфувати стільки, що у вас може виникнути проблема з обладнанням.

Стовпці "досяжності", що дорівнює 0, говорять про те, що він не зміг поговорити з серверами, і він поступово отримує біти зміщені, щоб показати, як пройшли останні 8 спроб (тому 377 добре, 0 - погано).