Почему 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 7В ntpq вывода указано, что вы позволяете пЪрд работать только около 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 секунд. Бинго! Моя первая подсказка была о сбоях Kerberos, замеченных в журналах. Kerberos и многие 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, синхронизируется ли время?

с наилучшими пожеланиями