Чому ntpd не оновлює час на моєму сервері?

У мене на сервері працює ntpd. Це всі налаштування за замовчуванням, за винятком того, що я прокоментував його здатність бути сервером для інших машин:

# restrict -4 default kod notrap nomodify nopeer noquery                                                                    
# restrict -6 default kod notrap nomodify nopeer noquery   
restrict default ignore

Якщо я біжу ntpdate -q ntp.ubuntu.com, мені кажуть, що годинник моєї машини вимкнений на 7 секунд.

Що відбувається? Як я можу діагностувати те, що відбувається, чи є журнал, який я можу включити?

більше інформації №1

# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.189.94.4     193.79.237.14    2 u   30   64    7  108.518   -0.136   0.361

більше інформації №2

Ось як це виглядало, коли я задавав питання:

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec

І ось, як це виглядає зараз, після перезавантаження ntpd кілька разів (я припускаю, що це виправлено):

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec

більше інформації №3

Я видалив ntp і встановив openntpd і побіг /usr/sbin/ntpd -d, і я бачу такий вихід:

reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s

Що для мене досить чітко вказує на те, що я не в змозі встановити час на своєму сервері (хоча, за допомогою регулярного ntp, він, здається, іноді оновлюється ...).

більше інформації №4

Мій постачальник послуг VPS каже:

Останні ядра не повинні фіксувати вашу систему до годинника нашого dom0, щоб бути на безпечній стороні, ви можете встановити xen.independent_wallclock = 1 у своєму sysctl.conf.

Я вважаю, що все ще не вирішується питання про те, що VPS потребує наявного центрального процесора для правильних розрахунків часу.

Ви можете увімкнути вхід у ntpd, додавши це до ntp.conf:

logfile /var/log/ntpd.log

Джерело: посібник з ntp

Якщо ви вимкнете ntpd, можете оновити годинник за допомогою командного рядка? Якщо ви запускаєте команду ntpdate і отримуєте помилку на зразок:

# ntpdate ntp.ubuntu.com
10 Jan 23:47:57 ntpdate[26284]: Can't adjust the time of day: Operation not permitted

Це означає, що ви, мабуть, перебуваєте на VPS, і в такому випадку ви не можете змінювати системний годинник - це можна зробити лише на хост-машині.

Добре люди, за час, коли я задав це запитання, я перевстановив ntp із конфігурацією постачальника за замовчуванням (Ubuntu 10.0.4) і дав йому працювати кілька днів. Станом на це написання, ntpdate -q ntp.ubuntu.comвидно, що мій час точно в межах 0,000216 секунд. Отже, проблеми, які у мене виникли, були з моїм налаштованим конфігурацією (де я намагався унеможливити зовнішні хости запитів мого сервера, що я вже роблю зі своїм брандмауером, тому я не надто переживаю) Ось Ubuntu 10.0.4 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 ntp.ubuntu.com

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1
restrict ::1

Я вітаю відгуки про те, як цю конфігурацію можна вдосконалити.

Я також зробив квиток у свого постачальника послуг VPS, попросивши детальну рекомендацію щодо найкращого. Я вказав на цей потік та деяку іншу документацію, яка вказує на те, що, можливо, розподіл процесора спричинить проблему з тимчасовим терміном. Ось що вони сказали:

Останні ядра не повинні фіксувати вашу систему до годинника нашого dom0, щоб бути на безпечній стороні, ви можете встановити xen.independent_wallclock = 1 у своєму sysctl.conf. Це дозволить переконатися, що екземпляр сервера не слідкує за годинником на хост-сервері.

і:

Я думаю, що ви можете неправильно розуміти точну ступінь, в якій ця проблема впливає на клієнтів NTP у віртуалізованому середовищі. З мого досвіду роботи з віртуалізованою системою на хості Xen (як, наприклад, наша установка в Rackspace Cloud), неточність, успадкована тим, що немає спеціального системного годинника для обробки переривань, становить частки секунди, навіть у сильно завантажених системах. Ця незначна неточність легко управляється NTP, навіть якщо вона встановлена ​​лише для оновлення часу серверів один раз на день (або навіть рідше, ніж це).

В одному з ваших коментарів йдеться про те, що ви біжите на пристріті. У цьому випадку ви, мабуть, не матимете великого успіху, оскільки відчуття часу вашого vhost буде залежати як від реального господаря, на якому він працює, так і від того, наскільки зайнятий vhost загалом.

Залежно від використовуваної віртуалізації, vhost може не отримувати стійкої частки перерв у певному періоді часу. Це зробить годинник швидшим або повільнішим, ніж це відбувається насправді. Оскільки ntp намагається виміряти зміни за припущенням, що ваш годинник є фіксованою швидкістю швидше або повільніше, ніж у всьому світі, це прискорення та уповільнення призведе до придатків ntp і, можливо, з часом він просто здасться, результат що ntp -npпоказує сервери часу, які ntp визнав непридатними.

Ваша найкраща ставка, якщо це так, мабуть, жорстока сила rdate -s $serverкожні так часто (як кожні шість годин) смикати годинник за ніс, щоб він не сильно вийшов із синхронізації. Але дрібнозерниста точність, ймовірно, недосяжна.

Речі, які я знаходив у минулому, коли я використовував ntpd замість openntpd:

1. Вам потрібно дозволити доступ до localhost, щоб ntpd запустився належним чином і фактично займався роботою

   restrict 127.0.0.1
   restrict ::1
   

2. Хоча ви можете використовувати імена хостів для правил сервера, відкривати резервні копії дірок для спілкування з тими серверами означає, restrictщо для цього потрібні IP-адреси, тож я все-таки повинен був використовувати IP-адреси для всього, що завгодно.

3. Ви не згадуєте використання restrictдля відкриття резервного доступу до своїх серверів. Це питання. Спробуйте такі блоки, як:

   # ntp.xs4all.nl
   server          194.109.22.18
   restrict        194.109.22.18
   

4. Для ntpd потрібно декілька однолітків або серверів, оскільки він намагається використовувати голосування за більшістю правил для боротьби з поганим актором. Отже мінімум 4, щоб все-таки мати можливість більшості, коли ви втратите один, бажано 5.

5. Для блокування доступу за замовчуванням я можу використовувати:

   restrict default notrust nomodify
   

   щоб все-таки мати можливість запиту, але я закінчив використовувати, restrict default ignoreяк і ви, коли ntpd 4.2 змінив значення notrust. зітхати

6. Якщо ви не надаєте службі часу обслуговування іншим, то, ймовірно, вам не потрібна вся потужність звичайного ntpd, і вам слід подумати про це openntpd. Написаний екіпажем OpenBSD, це набагато мінімальна реалізація, використовуючи розділення привілеїв та набагато простіший конфігураційний файл. Він нібито не забезпечить дуже точний час, який буде ntpd, але це легко досить добре для звичайного сервера або робочої станції.

• Якщо ntpd не зможе з'єднатися з віддаленим сервером, ви не побачите зміщення цього сервера.
• Якщо ntpq буде заблоковано ntpd, ви побачите чітке повідомлення про помилку від ntpq.
• Якщо якась інша служба встановила б також час (наприклад, інструменти vmware), ви побачите стрибкове зміщення для сервера (запускайте ntpq -p кожні 70 секунд).

Вихід reach 7ntpq вказував, що ви дозволяєте ntpd працювати лише протягом приблизно 4 хвилин. 7 - 111 двійкових, що означає, що сервер був досягнутий уже 3 рази. ntp виходить кожні 64 секунди ( pollзначення) і чекає вже 30 секунд ( whenзначення) з моменту останнього контакту.

offset -0.136Вказується, що система вже синхронізована. Тільки ntpd ще не позначив сервер як джерело. Просто дайте йому більше часу, і з’явиться маленька зірка.

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

PS: Я знаю, що питання дуже старе. Але питання є позачасовим. А всі інші відповіді - це просто оману ІМХО. ntpd навіть рекомендується VMWare, щоб тримати час у синхронізації.

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

В /etc/sysconfig/ntpd:

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no

Я встановив це yes. Звичайно спочатку переконайтеся, що у вас надійний NTP-сервер, і ваш системний годинник надійний.

Я знав, що це було - мій перекіс - 47 секунд, а годинник HW - також 47 секунд. Бінго! Першою моєю підказкою були провали Кербероса, помічені в журналах. Керберос та багато NAS просто не працюватимуть, якщо перекос годинника буде занадто великим.

Гарного дня!

якщо ви запускаєте vhost на vmware, перевірте наступну статтю. Це допоможе вам http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

Хай ..

Перегляньте це посилання, щоб дізнатися, чи може це допомогти у вирішенні проблеми:

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_: Ch24 : _The_NTP_Server

ви можете опублікувати вміст файлу ntpd.conf, вихід команд налагодження, таких як ntpq -p

І перевірити свою дату / час?

І переконайтесь також у цьому, запускайте ntpdate та запускайте ntpd, чи синхронізується час?

з найкращими побажаннями