Проблема с синхронизацией времени
Vadim Guchenko
Для синхронизации времени использую openntpd. Раньше использовал ntpd, но с
ним возникали проблемы с убеганием времени на сильно нагруженных машинах.
Вдобавок не нравится, что в ntpd нельзя указать на каких интерфейсах ему
слушать и слушать ли вообще. openntpd нормально справляется с синхронизацией
системного времени, однако насколько я понял из сообщений в англоязычных
группах и из собственных наблюдений, openntpd никогда не синхронизирует
аппаратные часы (RTC). Поэтому если аптайм сервера составляет несколько
месяцев и все это время openntpd успешно синхронизирует время с
NTP-серверами, то аппаратные часы могут убежать на много минут назад или
вперед. И после очередной перезагрузки это вылезет боком:
Jul 28 13:44:37 control ntpd[504]: adjusting local clock by 0.017923s
Jul 28 14:04:37 control ntpd[504]: adjusting local clock by 0.025283s
Jul 28 14:43:37 control ntpd[504]: adjusting local clock by -0.062466s
Jul 28 15:06:02 control ntpd[504]: adjusting local clock by 0.102997s
Jul 28 15:33:51 control ntpd[505]: ntp engine exiting
Jul 28 15:33:51 control ntpd[504]: Terminating
Jul 28 15:42:36 control ntpd[562]: ntp engine ready
Jul 28 15:42:51 control ntpd[562]: peer 80.253.235.192 now valid
Jul 28 15:43:36 control ntpd[561]: adjusting local clock by -446.510181s
Jul 28 15:44:36 control ntpd[561]: adjusting local clock by -446.219918s
Jul 28 15:48:36 control ntpd[561]: adjusting local clock by -445.325664s
Такое расхождение openntpd выравнивал почти сутки. Я пробовал при загрузке
запускать ntpdate из rc.conf, однако на серверах используется динамическая
маршрутизация (OSPF) и к моменту запуска ntpdate таблица маршрутизации еще
пуста, поэтому сервер времени недоступен. Что можно сделать?
With best regards, Vadim Guchenko. E-mail: s0l...@kraslan.ru
Eugene Grosbein
VG> Такое расхождение openntpd выравнивал почти сутки. Я пробовал при загрузке
VG>
VG> запускать ntpdate из rc.conf, однако на серверах используется динамическая
VG>
VG> маршрутизация (OSPF) и к моменту запуска ntpdate таблица маршрутизации еще
VG>
VG> пуста, поэтому сервер времени недоступен. Что можно сделать?
Использовать статики с низкой administrative distance, например.
Eugene
--
За то, что сердце в человеке
Hе вечно будет трепетать
Vadim Guchenko
You wrote to Vadim Guchenko on Mon, 15 Aug 2005 23:21:06 +0400:
VG>> Такое расхождение openntpd выравнивал почти сутки. Я пробовал при
VG>> загрузке
VG>> запускать ntpdate из rc.conf, однако на серверах используется
VG>> динамическая
VG>> маршрутизация (OSPF) и к моменту запуска ntpdate таблица
VG>> маршрутизации еще
VG>> пуста, поэтому сервер времени недоступен. Что можно сделать?
EG> Использовать статики с низкой administrative distance, например.
А есть какая-нибудь утилита, которая периодически записывает системное время
в RTC? Кстати, стандартный ntpd обновляет RTC? Насколько часто?
Valentin Davydov
> Date: Mon, 15 Aug 2005 16:41:24 +0000 (UTC)
>
>А есть какая-нибудь утилита, которая периодически записывает системное время
>в RTC?
adjkerntz(8), например.
>Кстати, стандартный ntpd обновляет RTC?
Вряд ли. Впрочем, посмоти в документации.
Вал. Дав.
Vadim Guchenko
You wrote to Vadim Guchenko on Mon, 15 Aug 2005 23:21:06 +0400:
VG>> Такое расхождение openntpd выравнивал почти сутки. Я пробовал при
VG>> загрузке
VG>> запускать ntpdate из rc.conf, однако на серверах используется
VG>> динамическая
VG>> маршрутизация (OSPF) и к моменту запуска ntpdate таблица
VG>> маршрутизации еще
VG>> пуста, поэтому сервер времени недоступен. Что можно сделать?
EG> Использовать статики с низкой administrative distance, например.
Предположим я это сделаю на всех серверах. Но ntpdate при загрузке серверов
сработает только в том случае, если компьютер внутри сети, на котором поднят
NTP-сервер, не перезагружался. Если же произошло отключение питания и упс
выключил сразу все сервера, включая NTP-сервер, то при их одновременной
загрузке после включения питания к моменту, когда другие сервера начнут
синхронизацию времени по ntpdate, NTP-сервер скорее всего еще не загрузится
до конца и не будет способен ответить. Более того, сам NTP-сервер при
загрузке должен синхронизировать свое время с удаленным NTP-сервером. А для
этого ему нужен доступ в инет. Даже если не брать во внимание динамический
роутинг (BGP) и прописать маршрут к удаленному NTP-серверу статиком, то не
факт, что после одновременного включения питания на всех серверах
маршрутизатор загрузится раньше, чем локальный NTP-сервер, и позволит ему
выйти в инет.
Так что на мой взгляд ntpdate при старте вообще ничего не гарантирует.
Поэтому нужно иметь возможность периодически записывать системное время в
hardware clock, чтобы при перезагрузке сервера оно не сильно расходилось с
реальным.
Vadim Guchenko
You wrote to Vadim Guchenko on Tue, 16 Aug 2005 04:36:36 +0000 (UTC):
>> А есть какая-нибудь утилита, которая периодически записывает
>> системное время в RTC?
VD> adjkerntz(8), например.
Судя по всему, оно записывает время в RTC раз в полгода. Когда сменяется TZ
при переходе на летнее или зимнее время.
>> Кстати, стандартный ntpd обновляет RTC?
VD> Вряд ли. Впрочем, посмоти в документации.
Там написано:
Most operating systems and hardware of today incorporate a time-of-year
(TOY) chip to maintain the time during periods when the power is off.
When the machine is booted, the chip is used to initialize the operating
system time. After the machine has synchronized to a NTP server, the
operating system corrects the chip from time to time.
Конкретного времени не указано.
Valentin Davydov
> Date: Wed, 17 Aug 2005 03:08:13 +0000 (UTC)
>
> >> А есть какая-нибудь утилита, которая периодически записывает
> >> системное время в RTC?
> VD> adjkerntz(8), например.
>
>Судя по всему, оно записывает время в RTC раз в полгода. Когда сменяется TZ
>при переходе на летнее или зимнее время.
А также при каждой перезагрузке (при стандартных /etc/rc и init).
> >> Кстати, стандартный ntpd обновляет RTC?
> VD> Вряд ли. Впрочем, посмоти в документации.
>
>Там написано:
>
>Most operating systems and hardware of today incorporate a time-of-year
>(TOY) chip to maintain the time during periods when the power is off.
>When the machine is booted, the chip is used to initialize the operating
>system time. After the machine has synchronized to a NTP server, the
>operating system corrects the chip from time to time.
Значит, этим занимается не ntpd, а какая-то другая часть операционной
системы.
Вал. Дав.
Valentin Davydov
> Date: Mon, 15 Aug 2005 15:36:53 +0000 (UTC)
>
>Для синхронизации времени использую openntpd. Раньше использовал ntpd, но с
>ним возникали проблемы с убеганием времени на сильно нагруженных машинах.
А всякими найсами поиграться, частоту таймера понизить не пробовал?
>Я пробовал при загрузке
>запускать ntpdate из rc.conf, однако на серверах используется динамическая
>маршрутизация (OSPF) и к моменту запуска ntpdate таблица маршрутизации еще
>пуста, поэтому сервер времени недоступен. Что можно сделать?
У меня в сети обычно имеется выделенный сервер времени со статической
маршрутизацией в интернет и небольшой дисковой/сетевой нагрузкой,
который рассылает по локалке NTP-бродкасты, а их уже подбирают все,
кому надо.
Вал. Дав.
Valentin Davydov
> Date: Wed, 17 Aug 2005 03:04:09 +0000 (UTC)
>
> VG>> Такое расхождение openntpd выравнивал почти сутки. Я пробовал при
> VG>> загрузке
> VG>> запускать ntpdate из rc.conf, однако на серверах используется
> VG>> динамическая
> VG>> маршрутизация (OSPF) и к моменту запуска ntpdate таблица
> VG>> маршрутизации еще
> VG>> пуста, поэтому сервер времени недоступен. Что можно сделать?
> EG> Использовать статики с низкой administrative distance, например.
>
>Предположим я это сделаю на всех серверах. Но ntpdate при загрузке серверов
>сработает только в том случае, если компьютер внутри сети, на котором поднят
>NTP-сервер, не перезагружался. Если же произошло отключение питания и упс
>выключил сразу все сервера, включая NTP-сервер, то при их одновременной
>загрузке после включения питания к моменту, когда другие сервера начнут
>синхронизацию времени по ntpdate, NTP-сервер скорее всего еще не загрузится
>до конца и не будет способен ответить.
Отсюда вывод: не следует пользоваться ntpdate для синхронизации времени.
О чём и в документации написано.
>Более того, сам NTP-сервер при
>загрузке должен синхронизировать свое время с удаленным NTP-сервером.
Не должен. Он должен быть запущен, а уж с какими из удалённых серверов
и каким способом синхронизировать время - он сам разберётся. Единственное
условие, которое надо выполнить - к моменту старта ntpd доменные имена
удалённых серверов должны резолвиться в DNS. Ну, или в конфиг прямо
IP-адреса прописывать.
Вал. Дав.
Vadim Guchenko
You wrote to Vadim Guchenko on Wed, 17 Aug 2005 15:06:26 +0000 (UTC):
>>>> А есть какая-нибудь утилита, которая периодически записывает
>>>> системное время в RTC?
VD>>> adjkerntz(8), например.
>> Судя по всему, оно записывает время в RTC раз в полгода. Когда
>> сменяется TZ при переходе на летнее или зимнее время.
VD> А также при каждой перезагрузке (при стандартных /etc/rc и init).
А чем тогда объяснить скачок во времени между шатдауном и загрузкой, который
я приводил в первом письме:
Aug 17 22:58:35 router ntpd[63993]: adjusting local clock by 0.104225s
Aug 17 23:08:36 router ntpd[63993]: adjusting local clock by 0.092758s
Aug 17 23:10:06 router ntpd[63993]: adjusting local clock by 0.079951s
Aug 17 23:11:14 router ntpd[63993]: adjusting local clock by -0.256664s
Aug 17 23:30:46 router ntpd[63993]: adjusting local clock by 0.092515s
Aug 17 23:57:52 router ntpd[63993]: adjusting local clock by -0.059742s
Aug 18 00:15:34 router ntpd[63994]: ntp engine exiting
Aug 18 00:15:34 router ntpd[63993]: Terminating
Aug 18 00:17:31 router ntpd[566]: ntp engine ready
Aug 18 00:18:46 router ntpd[566]: peer 87.236.40.251 now valid
Aug 18 00:19:31 router ntpd[565]: adjusting local clock by -45.838532s
Aug 18 00:20:01 router ntpd[565]: adjusting local clock by -45.839935s
Aug 18 00:21:31 router ntpd[565]: adjusting local clock by -45.526075s
Aug 18 00:24:31 router ntpd[565]: adjusting local clock by -44.707632s
Aug 18 00:27:01 router ntpd[565]: adjusting local clock by -43.789696s
Aug 18 00:30:01 router ntpd[565]: adjusting local clock by -43.494540s
Aug 18 00:31:01 router ntpd[565]: adjusting local clock by -43.346860s
До шатдауна время было точное, о чем свидетельствуют логи openntpd и
визуальное сравнение времени на сервере с эталонным. Перезагрузка сервера
длилась 2 минуты. После его загрузки время разошлось с эталонным на 45
секунд. Причем чем больше аптайм сервера до перезагрузки, тем больше
расхождение во времени после его последующей загрузки. Не могут же
аппаратные часы внезапно ускориться во время ребута. Батарейка тоже непричем
(такое наблюдается на всех серверах). Значит или системное время не
записывается при шатдауте в RTC, или до его записи туда во время шатдауна
системный таймер что-то сильно сбивает. Стартовые и стоповые скрипты
стандартные. adjkerntz постоянно висит в памяти. Есть подозрение, что это
связано со включенным поллингом. Буду дальше копать.
Vadim Guchenko
You wrote to Vadim Guchenko on Wed, 17 Aug 2005 15:06:26 +0000 (UTC):
VD> У меня в сети обычно имеется выделенный сервер времени со
VD> статической маршрутизацией в интернет и небольшой дисковой/сетевой
VD> нагрузкой, который рассылает по локалке NTP-бродкасты, а их уже
VD> подбирают все, кому надо.
Какая версия системы на серверах? У меня не получается заставить
ntpd-клиентов на 5.4R брать время через броадкасты или мультикасты. Конфиг
раздающего ntpd-сервера:
server 192.43.244.18 # time.nist.gov
server 192.5.41.40 # tick.usno.navy.mil
server 198.123.30.132 # ntp.nasa.gov
server 18.145.0.30 # tick.mit.edu
server 193.204.114.105 # time.ien.it
server 138.96.64.10 # ntp-sop.inria.fr
server 130.149.17.21 # ntps1-0.cs.tu-berlin.de
#broadcast 87.236.40.63
broadcast 224.0.1.1
logconfig +clockall +peerall +sysall +syncall
server1# ntpq -np
remote refid st t when poll reach delay offset
jitter
==============================================================================
+192.43.244.18 .ACTS. 1 u 48 1024 377 238.948 3.501
0.269
+192.5.41.40 .USNO. 1 u 826 1024 377 191.938 10.294
1.384
-198.123.30.132 .GPS. 1 u 875 1024 377 273.969 1.496
0.020
+18.145.0.30 .PSC. 1 u 834 1024 377 191.835 7.376
0.210
-193.204.114.105 .IEN. 1 u 873 1024 377 164.994 20.104
2.593
*138.96.64.10 .hopf. 1 u 812 1024 377 138.956 7.397
0.220
-130.149.17.21 .PPS. 1 u 877 1024 377 138.660 14.629
27.683
224.0.1.1 .MCST. 16 u - 64 0 0.000 0.000
4000.00
Конфиг ntpd-клиента:
#broadcastclient
multicastclient 224.0.1.1
logconfig +clockall +peerall +sysall +syncall
Я по очереди пробовал броадкасты и мультикасты. Пакеты от раздающего
ntpd-сервера идут каждые 64 секунды, но ntpd-клиент их как будто бы
игнорирует, т.к. время у него не синхронизируется и в логах:
Aug 21 16:35:00 control ntpd[54849]: ntpd 4.2.0-a Sun Aug 14 22:14:27 KRAST
2005 (1)
Aug 21 16:35:00 control ntpd[54849]: precision = 2.514 usec
Aug 21 16:35:00 control ntpd[54849]: no IPv6 interfaces found
Aug 21 16:35:00 control ntpd[54849]: kernel time sync status 2040
Aug 21 16:35:00 control ntpd[54849]: Frequency format error in
/var/db/ntpd.drift
Aug 21 16:35:00 control ntpd[54849]: system event 'event_restart' (0x01)
status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)
Aug 21 17:35:00 control ntpd[54849]: offset 0.000000 sec freq 0.000 ppm
error 0.000002 poll 4
Aug 21 18:35:00 control ntpd[54849]: offset 0.000000 sec freq 0.000 ppm
error 0.000002 poll 4
Aug 21 19:35:00 control ntpd[54849]: offset 0.000000 sec freq 0.000 ppm
error 0.000002 poll 4
Если в конфиге ntpd-клиента явно указать сервер, то он синхронизируется
нормально:
server 87.236.40.60
logconfig +clockall +peerall +sysall +syncall
Aug 20 22:32:32 control ntpd[79605]: offset 0.007209 sec freq 0.664 ppm
error 0.002112 poll 7
Aug 20 23:32:32 control ntpd[79605]: offset 0.012176 sec freq 1.199 ppm
error 0.001854 poll 6
Aug 21 00:32:32 control ntpd[79605]: offset 0.004113 sec freq 2.996 ppm
error 0.000678 poll 6
Aug 21 01:32:32 control ntpd[79605]: offset 0.003918 sec freq 3.792 ppm
error 0.000720 poll 6
На файрволе доступы разрешены.
Victor Sudakov
> Я по очереди пробовал броадкасты и мультикасты. Пакеты от раздающего
> ntpd-сервера идут каждые 64 секунды, но ntpd-клиент их как будто бы
> игнорирует, т.к. время у него не синхронизируется и в логах:
Попробуй на клиентах "ntpd -A". Или настрой везде authentication.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Vadim Guchenko
You wrote to "Vadim Guchenko" <s0l...@kraslan.ru> on Sun, 21 Aug 2005
18:21:49 +0000 (UTC):
>> Я по очереди пробовал броадкасты и мультикасты. Пакеты от раздающего
>> ntpd-сервера идут каждые 64 секунды, но ntpd-клиент их как будто бы
>> игнорирует, т.к. время у него не синхронизируется и в логах:
VS> Попробуй на клиентах "ntpd -A". Или настрой везде authentication.
Thx, ключик помог.
Victor Sudakov
>
> >> Я по очереди пробовал броадкасты и мультикасты. Пакеты от раздающего
> >> ntpd-сервера идут каждые 64 секунды, но ntpd-клиент их как будто бы
> >> игнорирует, т.к. время у него не синхронизируется и в логах:
> VS> Попробуй на клиентах "ntpd -A". Или настрой везде authentication.
>
> Thx, ключик помог.
Но authentication еще лучше, не зря она по умолчанию включена при
слушании NTP броадкастов.
Большое удобство authentication также и в том, что если рассылаемые
NTP сервером пакеты подписываются, а какой-то клиент не умеет NTP
authentication (например k9), он этими пакетами всё равно пользоваться
сможет.
Vadim Guchenko
You wrote to All on Mon, 15 Aug 2005 15:36:53 +0000 (UTC):
Я до сих пор пытаюсь нормально настроить синхронизацию времени. Полностью
отказался от openntpd и перешел обратно на стандартный ntpd. Сделал внутри
сети два раздающих NTP-сервера, которые синхронизируют свое время с
несколькими стратум 1 серверами в Интернете. В свою очередь эти серверы
раздают остальным серверам внутри сети время броадкастами, плюс отвечают на
юникаст-запросы клиентов. Все замечательно, никаких рассинхронизаций или
убеганий времени. Но есть одно НО. При перезагрузке любого сервера в логах
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 и скачка не будет. Несмотря на то, что тут писали про
adjkerntz, указанную функцию эта утилита у меня не выполняет, хотя и висит
все время в памяти. Поиск в гугле ничего не дал. Поэтому есть два вопроса:
1. У всех при загрузке любого сервера, который проработал хотя бы сутки, и
первой синхронизации времени ntpd делает step (reset time), даже если до
шатдауна время было синхронизировано? Или так только у меня?
2. Если у всех, то чем можно периодически и при шатдауне записывать
системное время в аппаратные часы? Есть функция resettodr(9), но я не нашел
для нее оболочки, чтобы вызывать из шелла.
Valentin Nechayev
>>> Vadim Guchenko wrote:
VG> Предложение синхронизировать время при загрузке системы однократным вызовом
VG> ntpdate из rc.conf считаю ненадежным, т.к. не во всех случаях это сработает.
А ntpd со step'ом, значит, сработает? Не понимаю логики. Даже если у
тебя ntpdate в какой-то доле случаев не сработает, вызывать его всё
равно надо: потому что оно с хорошей вероятностью поставит
правильное время не хрен знает когда, а в процессе загрузки до
запуска большинства остальных процессов и до входа пользователей.
Это чрезвычайно важно для многих видов работы.
VG> 1. У всех при загрузке любого сервера, который проработал хотя бы сутки, и
VG> первой синхронизации времени ntpd делает step (reset time), даже если до
VG> шатдауна время было синхронизировано? Или так только у меня?
У меня ntpdate. Смещения, как правило, меньше. Извини, сервер с
аптаймом менее 40 дней найти сложно, пока что не получилось. На
ноуте пишет смещения крошечные (в среднем 0.2 сек.) Может, у тебя
какая-то проблема с RTC, что в нём не записывается?
VG> 2. Если у всех, то чем можно периодически и при шатдауне записывать
VG> системное время в аппаратные часы? Есть функция resettodr(9), но я не нашел
VG> для нее оболочки, чтобы вызывать из шелла.
Нарисуй модуль который её вызовет, проблем-то. Хотя можно ещё проще:
1. settimeofday() вызывает resettodr(). Поэтому, можно написать
сишник, где-то такого содержания:
struct rtprio prio;
struct timeval now;
prio.type = RTP_PRIO_REALTIME; prio.prio = 0;
rtprio(RTP_SET, getpid(), &prio);
gettimeofday(&now, NULL);
settimeofday(&now, NULL);
2. В пятёрке установка machdep.adjkerntz вызывает resettodr(),
поэтому можно прочитать значение и записать его обратно.
-netch-
Valentin Davydov
> Date: Sun, 28 Aug 2005 11:13:56 +0000 (UTC)
>
>VG> Предложение синхронизировать время при загрузке системы однократным вызовом
>VG> ntpdate из rc.conf считаю ненадежным, т.к. не во всех случаях это сработает
>.
>
>А ntpd со step'ом, значит, сработает? Не понимаю логики. Даже если у
>тебя ntpdate в какой-то доле случаев не сработает, вызывать его всё
>равно надо: потому что оно с хорошей вероятностью поставит
систему раком до истечения DNS timeoutов.
Вал. Дав.
Valentin Davydov
> Date: Sun, 28 Aug 2005 10:55:49 +0000 (UTC)
>
>Я до сих пор пытаюсь нормально настроить синхронизацию времени. Полностью
>отказался от openntpd и перешел обратно на стандартный ntpd. Сделал внутри
>сети два раздающих NTP-сервера, которые синхронизируют свое время с
>несколькими стратум 1 серверами в Интернете.
При выборе серверов и интернете над смотреть не на стратум, который они
сами себе приписали, а на качество (стабильность задержки) каналов до них.
>В свою очередь эти серверы
>раздают остальным серверам внутри сети время броадкастами, плюс отвечают на
>юникаст-запросы клиентов. Все замечательно, никаких рассинхронизаций или
>убеганий времени. Но есть одно НО. При перезагрузке любого сервера в логах
>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
Чтобы он не степал, у ntpd есть ключик -x. Рекомендую.
>Предложение синхронизировать время при загрузке системы однократным вызовом
>ntpdate из rc.conf считаю ненадежным, т.к. не во всех случаях это сработает.
Делай это только в тех случаях, когда оно надёжно (к моменту загрузки
машины хотя бы один из серверов, перечисленных в команде ntpdate, доступен
по DNS/роутингу/каналу и выдаёт правильное время).
Вал. Дав.
Valentin Nechayev
>>> Valentin Davydov wrote:
>VG>> Предложение синхронизировать время при загрузке системы однократным вызовом
>VG>> ntpdate из rc.conf считаю ненадежным, т.к. не во всех случаях это сработает
>>.
>>А ntpd со step'ом, значит, сработает? Не понимаю логики. Даже если у
>>тебя ntpdate в какой-то доле случаев не сработает, вызывать его всё
>>равно надо: потому что оно с хорошей вероятностью поставит
VD> систему раком до истечения DNS timeoutов.
У меня не ставит. если у тебя ставит - ищи проблему в руках.
-netch-
Vadim Guchenko
You wrote to Vadim Guchenko <s0l...@kraslan.ru> on Sun, 28 Aug 2005 11:13:56
+0000 (UTC):
VG>> Предложение синхронизировать время при загрузке системы однократным
VG>> вызовом ntpdate из rc.conf считаю ненадежным, т.к. не во всех
VG>> случаях это сработает.
VN> А ntpd со step'ом, значит, сработает? Не понимаю логики.
ntpd со step'ом рано или поздно сработает, даже если NTP-сервера какое-то
время были недоступны. Но я вообще хочу избавиться от степов, даже при
загрузке.
VN> Даже если у тебя ntpdate в какой-то доле случаев не сработает, вызывать
VN> его всё равно надо: потому что оно с хорошей вероятностью поставит
VN> правильное время не хрен знает когда, а в процессе загрузки до
VN> запуска большинства остальных процессов и до входа пользователей.
VN> Это чрезвычайно важно для многих видов работы.
А если точное время перед шатдауном записать в аппаратные часы, а при
загрузке сервера его оттуда снять, то это будет еще лучше. Тогда можно ntpd
запускать с ключом -x, а доступность серверов времени перед запуском
процессов становится некритичной.
VG>> 1. У всех при загрузке любого сервера, который проработал хотя бы
VG>> сутки, и первой синхронизации времени ntpd делает step (reset
VG>> time), даже если до шатдауна время было синхронизировано? Или так
VG>> только у меня?
VN> У меня ntpdate. Смещения, как правило, меньше. Извини, сервер с
VN> аптаймом менее 40 дней найти сложно, пока что не получилось.
А если ребутнуть сервер с большим аптаймом, какое будет смещение времени при
старте?
VN> На ноуте пишет смещения крошечные (в среднем 0.2 сек.). Может, у тебя
VN> какая-то проблема с RTC, что в нём не записывается?
Не знаю я, что может быть с RTC. Не может же RTC не работать сразу на всех
серверах. Аппаратные часы убегают примерно на 2-3 секунды в день. Я считаю
это нормальным.
VN> 2. В пятёрке установка machdep.adjkerntz вызывает resettodr(),
VN> поэтому можно прочитать значение и записать его обратно.
Спасибо, попробую. Вставил в крон:
0,30 * * * * sysctl `sysctl -e machdep.adjkerntz`
Подожду некоторое время и сообщу о результатах.
Valentin Nechayev
>>> Vadim Guchenko wrote:
VG>>> Предложение синхронизировать время при загрузке системы однократным
VG>>> вызовом ntpdate из rc.conf считаю ненадежным, т.к. не во всех
VG>>> случаях это сработает.
VN>> А ntpd со step'ом, значит, сработает? Не понимаю логики.
VG> ntpd со step'ом рано или поздно сработает, даже если NTP-сервера какое-то
VG> время были недоступны. Но я вообще хочу избавиться от степов, даже при
VG> загрузке.
Как программа-максимум - да, хорошо. Но программа-минимум должна
быть - минимизировать вред от прыжка. И для этого ntpdate - лучшее
средство.
VG>>> 1. У всех при загрузке любого сервера, который проработал хотя бы
VG>>> сутки, и первой синхронизации времени ntpd делает step (reset
VG>>> time), даже если до шатдауна время было синхронизировано? Или так
VG>>> только у меня?
VN>> У меня ntpdate. Смещения, как правило, меньше. Извини, сервер с
VN>> аптаймом менее 40 дней найти сложно, пока что не получилось.
VG> А если ребутнуть сервер с большим аптаймом, какое будет смещение времени при
VG> старте?
Хе-хе. Проверил на практике. -130. Аптайм был 41 день.
Надо будет попробовать форсировать запись в RTC.
VN>> 2. В пятёрке установка machdep.adjkerntz вызывает resettodr(),
VN>> поэтому можно прочитать значение и записать его обратно.
VG> Спасибо, попробую. Вставил в крон:
VG> 0,30 * * * * sysctl `sysctl -e machdep.adjkerntz`
VG> Подожду некоторое время и сообщу о результатах.
Я тоже поиграюсь на чём-нибудь :)
-netch-
Valentin Nechayev
>>> Valentin Davydov wrote:
>>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
VD> Чтобы он не степал, у ntpd есть ключик -x. Рекомендую.
Опять ерунда какая-то. Назад нельзя переводить прыжком после старта
системы, а вперёд для большинства - можно. В новом ntpd это рулится
через tinker.
>>Предложение синхронизировать время при загрузке системы однократным вызовом
>>ntpdate из rc.conf считаю ненадежным, т.к. не во всех случаях это сработает.
VD> Делай это только в тех случаях, когда оно надёжно (к моменту загрузки
VD> машины хотя бы один из серверов, перечисленных в команде ntpdate, доступен
VD> по DNS/роутингу/каналу и выдаёт правильное время).
Так в большинстве случаев и получается.
-netch-
Vadim Guchenko
You wrote to Valentin Nechayev on Mon, 29 Aug 2005 01:35:02 +0000 (UTC):
VN>> 2. В пятёрке установка machdep.adjkerntz вызывает resettodr(),
VN>> поэтому можно прочитать значение и записать его обратно.
VG> Спасибо, попробую. Вставил в крон:
VG> 0,30 * * * * sysctl `sysctl -e machdep.adjkerntz`
VG> Подожду некоторое время и сообщу о результатах.
Все заработало как и хотелось.
Andriy Gapon
> Hello, Vadim!
> You wrote to Valentin Nechayev on Mon, 29 Aug 2005 01:35:02 +0000 (UTC):
>
> VN>> 2. В пятёрке установка machdep.adjkerntz вызывает resettodr(),
> VN>> поэтому можно прочитать значение и записать его обратно.
> VG> Спасибо, попробую. Вставил в крон:
> VG> 0,30 * * * * sysctl `sysctl -e machdep.adjkerntz`
> VG> Подожду некоторое время и сообщу о результатах.
я б еще 6-23 или */6 или что-то в таком духе вставил во второй позиции,
чтобы вдруг не возникло проблем при переводе времени.
P.S. да, я знаю, что adjkerntz запускается в 01,31, но тем не менее
--
Andriy Gapon