|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Vadim Guchenko 2:5020/400 28 Aug 2005 14:55:49
To : Vadim Guchenko
Subject : Re: Проблема с синхронизацией времени
--------------------------------------------------------------------------------
Hello, Vadim!
You wrote to All on Mon, 15 Aug 2005 15:36:53 +0000 (UTC):
Я до сих пор пытаюсь нормально настроить синхронизацию времени. Полностью
отказался от openntpd и перешел обратно на стандартный ntpd. Сделал внутри
сети два раздающих NTP-сервера, которые синхронизируют свое время с
несколькими стратум 1 серверами в Интернете. В свою очередь эти серверы
раздают остальным серверам внутри сети время броадкастами, плюс отвечают на
юникаст-запросы клиентов. Все замечательно, никаких рассинхронизаций или
убеганий времени. Hо есть одно HО. При перезагрузке любого сервера в логах
ntpd видим:
Aug 28 17:13:34 control ntpd[411]: synchronized to 87.236.40.61, stratum=2
Aug 28 17:13:30 control ntpd[411]: time reset -3.274122 s
Т.е. время, которое было в аппаратных часах и при загрузке сервера
скопировалось в системные часы, отличалось от точного времени на величину
3.274 с. Причем чем больше был аптайм сервера, тем больше величина
расхождения. Такое можно объяснить только тем, что до шатдауна сервера
точное системное время не было записано в аппаратные часы. Потому что за 5
минут ребута аппаратные часы не могут дать такую ошибку. Зато такая ошибка
вполне нормальна для времени работы сервера до шатдауна. Такое наблюдается
на всех (порядка 15) серверах с разным железом и не зависит от
включенного/выключенного поллинга. Везде 5.4 RELEASE.
Когда ntpd после старта системы первый раз синхронизирует время с
NTP-сервером, он исправляет расхождение step'ом. Понятно, что такой скачок
времени некорректен, пусть он даже будет один раз. Причем первая
синхронизация происходит не сразу, а спустя какое-то время, пока не будут
опрошены все NTP-сервера. К этому моменту все другие службы сервера
загрузятся и начнут работать. Если есть софт, который болезненно реагирует
на такой скачок, ему хватит и одного раза. Кроме того, одно дело когда
расхождение в пределах одной секунды, а другое - когда сервер проработал до
шатдауна полгода и аппаратные часы ушли вперед или назад на несколько минут.
Если ntpd и справится при следующей загрузке с таким расхождением, то очень
странно будет видеть во всех логах внезапный откат времени на несколько
минут назад.
Предложение синхронизировать время при загрузке системы однократным вызовом
ntpdate из rc.conf считаю ненадежным, т.к. не во всех случаях это сработает.
Даже если в своей сети маршрут до NTP-серверов прописан статиками, то сами
NTP-сервера могут быть просто недоступны из-за проблем на аплинке или еще по
каким-то причинам (не успели загрузиться). Единственно правильным считаю
периодическую запись (раз в час и при шатдауне) системного времени в
аппаратные часы. Чтобы при последующей загрузке сервера (если прошло
несколько минут), время не успело уйти больше, чем порог срабатывания step'а
в ntpd (125 мс). Тогда после первой синхронизации c NTP-серверами ntpd
сделает slew и скачка не будет. Hесмотря на то, что тут писали про
adjkerntz, указанную функцию эта утилита у меня не выполняет, хотя и висит
все время в памяти. Поиск в гугле ничего не дал. Поэтому есть два вопроса:
1. У всех при загрузке любого сервера, который проработал хотя бы сутки, и
первой синхронизации времени ntpd делает step (reset time), даже если до
шатдауна время было синхронизировано? Или так только у меня?
2. Если у всех, то чем можно периодически и при шатдауне записывать
системное время в аппаратные часы? Есть функция resettodr(9), но я не нашел
для нее оболочки, чтобы вызывать из шелла.
With best regards, Vadim Guchenko. E-mail: s0lver@kraslan.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
