Комментарии 36
Но в любом случае всё сказанное в статье справедливо только для администраторов ntpd?
Если у меня просто клиент, то я не должен ничего делать, ведь так?
Если у меня просто клиент, то я не должен ничего делать, ведь так?
Не совсем. Вы можете попробовать убедиться, что ваш клиент использует корректно сконфигурированные серверы. Например, если два сервера ответят, что коррекции не будет, а один, что будет — ваш клиент будет считать, что коррекции не будет.
Как убедится — зависит от конкретного софта. В случае канонического ntp будут полезны ntpq -c rv, ntpdc -c kern, ntptime. Универсальный способ проверки — анализ пакетов NTP от серверов к вашему клиенту 30 июня 2012 UTC.
Как убедится — зависит от конкретного софта. В случае канонического ntp будут полезны ntpq -c rv, ntpdc -c kern, ntptime. Универсальный способ проверки — анализ пакетов NTP от серверов к вашему клиенту 30 июня 2012 UTC.
Если честно, я так и не понял для каких сервисов это может вызывать проблемы? Ну синхронизируется он через час постфактумом на эту секунду и что?
В некотором плане вы правы и для корректно спроектированных систем это не критично.
Но если в течение этого часа в вашей сети произойдет какой-либо инцидент, то даже 1 секунда разницы может добавить работы при его расследование.
В случае же, если компенсация происходит рывком, а в случае с ntpd с дефолтными настройками (step 0.128) так и будет, возможны неприятности с повторным запуском на исполнение того, что не надо. Например, запуск криво сделанного скрипта для импорта данных в какой-нибудь варехауз.
Но если в течение этого часа в вашей сети произойдет какой-либо инцидент, то даже 1 секунда разницы может добавить работы при его расследование.
В случае же, если компенсация происходит рывком, а в случае с ntpd с дефолтными настройками (step 0.128) так и будет, возможны неприятности с повторным запуском на исполнение того, что не надо. Например, запуск криво сделанного скрипта для импорта данных в какой-нибудь варехауз.
Нефиг скрипты ставить на исполнение в 00:00 и +- 30мин. Что бы проблем не было, т.к. время могло локально убежать и в 00:00 отсинхронится назад на 23:59 например и гг, скрипты и без этой секунды второй раз побегут.
Я для себя соблюдаю правила, что такие ночные задачи надо запускать в 02:00 примерно.
Я для себя соблюдаю правила, что такие ночные задачи надо запускать в 02:00 примерно.
Хорошо если вы можете быть так же уверены и в стороннем софте, что в какой-то момент он не скажет что-нибудь типа: «обнаружен файл из будущего, дохну». Кстати, в ряде случаев это может быть вполне оправданное поведение.
А вы не испытывали проблем осенью, при переходе на зимнее время, когда 02:00 случается дважды в сутки?
Кстати, 30 минут может быть мало. Вполне типичный интервал опроса 1024 с + дефолтный stepout timeout 900 c дают 1924 c, что несколько больше получаса.
Кроме того, скрипты обычно ставят на исполнение по локальному времени, а leap second привязана с 00:00 по UTC.
Кроме того, скрипты обычно ставят на исполнение по локальному времени, а leap second привязана с 00:00 по UTC.
Я на все сервера на всякий случай запилил. Вкратце:
wget ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.3535142400 -O /etc/ntp.leap
echo "leapfile /etc/ntp.leap" >> /etc/ntp.conf
/etc/init.d/ntp restart
Разве в tzdata нет сведений о високосных секундах?
Главное — не забывать обновляться. И все будет хорошо!
Главное — не забывать обновляться. И все будет хорошо!
Есть. Но обычно используется версия без учета високосных секундах. В противном случае получится, что система у вас идет не по UTC, а по TAI. Что несколько идет в разрез с POSIX и рушит всю арифметику, основанную на том, что в сутках 86400. Когда я проводил подобный эксперимент, первое, что было замечено, это съехавшие даты в mysql.
Сам бы я тоже хочу, чтобы системное время шло по TAI, API было расширенно функциями для работы с TAI, а текущее API осуществляло бы прозрачный пересчет между TAI и UTC аналогично работе с локальным временем, но пока это, к сожалению, не так.
GPS даёт время без поправки на leap seconds. Cоответственно, некоторые, неправильно реализованные GPS-приёмники могут начать грешить на одну секунду: 'GPS time may differ from UTC because GPS time is a continuous time scale, while UTC is corrected periodically with an integer number of leap seconds. (...) The navigation data contains the requisite data for relating GPS time to UTC' (отсюда). Ситуация усугубляется тем, что последнее время было много разговоров, что поправочные секунды отменят вообще, и какой-то из производителей мог решить рискнуть.
Узнать, нормальный ли у вас приёмник, скорее всего придётся на опыте — если, конечно, вы не запаслись симулятором спутникового сигнала за 10k$.
С GLONASS всё проще, там шкала времени, насколько я помню, совпадает с UTC + 3 часа.
Узнать, нормальный ли у вас приёмник, скорее всего придётся на опыте — если, конечно, вы не запаслись симулятором спутникового сигнала за 10k$.
С GLONASS всё проще, там шкала времени, насколько я помню, совпадает с UTC + 3 часа.
Да, GPS дает время в своей шкале, но так же дает и разницу с UTC. Лично я еще не видел ни одного GPS-приемника, который бы не мог справиться с такой арифметикой. Тем более, что NMEA 0183 явно специфицирует, что время в UTC.
И чем же с GLONASS проще в плане leap seconds? Собственно корректируется то шкала UTC, а часы спутника так же продолжают монотонно тикать вперед.
И чем же с GLONASS проще в плане leap seconds? Собственно корректируется то шкала UTC, а часы спутника так же продолжают монотонно тикать вперед.
Что же касается NTP, то опасаться двойного выполнения скриптов, назначенных на полночь, скорее всего нет необходимости, потому что от возможно кривого корневого сервера до ваших систем скачок времени дойдёт не меньше чем минут за пять-десять, т.е. где-то к 0:05. К службе времени Windows это тоже применимо.
Под linux есть ещё такой способ способ избежать скачка времени: добавить в ntp.conf строчку «tinker step 1.5». Правда, потом её лучше убрать, т.к. она негативно сказывается на точности времени в среднем.
Под linux есть ещё такой способ способ избежать скачка времени: добавить в ntp.conf строчку «tinker step 1.5». Правда, потом её лучше убрать, т.к. она негативно сказывается на точности времени в среднем.
Только вот перед тем как изобретать велосипеды для того, чтобы не делать правильно, неплохо было бы вспомнить такую строчку из мануала:
«Note: The kernel time discipline is disabled if the step threshold is set to zero or greater than 0.5 s.»
«Note: The kernel time discipline is disabled if the step threshold is set to zero or greater than 0.5 s.»
То, что kernel time discipline disabled означает только то, что в микро(!) секундном маштабе нарушится плавность времени — adj_systime будет выполняться путём добавления нескольких микросекунд каждую секунду, а не через эквивалентный механизм ядра.
Я лично запускал конфигурации вообще с tinker step 0, и ничего — достаточно успешно.
«Делать правильно» означает выбрать адекватный первичный сервер или аппаратный источник, всё остальное, включая прикручивание ручками файла leap-seconds — велосипеды чтобы не делать правильно :)
Я лично запускал конфигурации вообще с tinker step 0, и ничего — достаточно успешно.
«Делать правильно» означает выбрать адекватный первичный сервер или аппаратный источник, всё остальное, включая прикручивание ручками файла leap-seconds — велосипеды чтобы не делать правильно :)
Вообще, интервал в котором до моих систем дойдет время скачек времени можно оценить таким образом для ntpd:
[(2^minpoll + stepout timeout) * (stratum — 1), (2^maxpoll + stepout timeout) * (stratum — 1)], где stratum — текущий stratum вашего сервера. (в реальности, там еще добавляется некое рандомное значение)
Подставляем дефолтные для ntpd значения и видим:
StratumИнтервал, с
2[964, 1924]
3[1928, 3848]
4[2892, 5772]
5[3856, 7696]
[(2^minpoll + stepout timeout) * (stratum — 1), (2^maxpoll + stepout timeout) * (stratum — 1)], где stratum — текущий stratum вашего сервера. (в реальности, там еще добавляется некое рандомное значение)
Подставляем дефолтные для ntpd значения и видим:
StratumИнтервал, с
2[964, 1924]
3[1928, 3848]
4[2892, 5772]
5[3856, 7696]
Верхнюю границу интервала вы оценили неправильно, так как при подключении без burst часть запросов фильтруются (oversampling) и реально при maxpoll==10 может быть обработан не первый полученный пакет, а второй или даже третий. Соответственно вместо рассуждений про рандомное значение — оценку неплохо бы утроить с учётом механизма clock filter)
Даже в этом приближении она уже больше оглашенных вами пяти минут.
Отлично, значит мы сойдёмся в том что опасаться двойного выполнения скриптов, назначенных на полночь, скорее всего нет необходимости
Собственно, с полночью это не ко мне. Я как раз в разговоре с вами и с еще одним человеком до вас упорно намекал, что стрельнет далеко не в полночь, но если на этот момент придется исполнение какой-нибудь, критичной к монотонности времени, софтины, то можно наступить на грабли. И чтобы не наступить на грабли, то в случае unix-like систем стоит посмотреть на сервера с которыми вы синхронизуетесь (это все же правильнее чем крутить step), а в случае Windows придется посмотреть, не накрутил ли кто MaxAllowedPhaseOffset так, что она сделает рывок назад (по закону подлости в самый неподходящий момент). Ну а для владельцев Stratum 1 — что не желательно, чтобы их сервера «отравили» клиентов, так как парочку таких серверов я уже находил.
Вспомнилась забавная история, когда во внутренней сети были какие-то странности со временем. Вроде бы все часы у оборудования были синхронизированы, но при этом отличались от реальных часов на несколько секунд (что в работе было довольно критично). Оказалось что при перенастройке одного из головных серверов (который по совместительству местный ntp сервер) его синхронизация была настроена на соседний сервер (вместо одно из глобальный ntp как раньше). В свою очередь тот второй сервер синхронизировался от первого. Так они весело синхронизируясь друг от друга и отставали на несколько секунд в месяц.
Что-то в этой истории недоговорено, поскольку протокол NTPv4 предусматривает защиту от подобного «цикла» из двух серверов: с помощью нумерации уровней (stratum), и с помощью поля пакета (refid). Может, использовалось какое-то нестандартное ПО?
Подробностей, к сожалению, не расскажу. Меня тогда тоже удивило такое поведение. Учитывая что сервера были настроены так криво то и какие-то отключенные проверки или еще что-то в самом ntp были возможны вполне.
Я бы предположил, что в конфиге была директива tos orphan на случай, чтобы часы внутри сети не шли в разнобой при потере внешнего канала. А когда по какой-то причине внешний источник «потерялся» насовсем, машины в сети стали синхронизировать время с системным временем одного из серверов. Если бы не Orphan Mode, то был бы еще и цирк с разным временем на машинах внутри сети.
Писал статью предполагая, что наиболее вероятный сценарий — «прощелканная клювом» секунда координации. И вот обнаружился Stratum 1 сервер, который наоборот анонсирует секунду координации слишком заранее (уже несколько дней) — Time2.Stupi.SE.
Рекомендую воздержаться от его использования, так как в ряде случаев при использовании старых версий ntpd (например, 4.2.4p5) это может приводить к ложной секунде координации.
Рекомендую воздержаться от его использования, так как в ряде случаев при использовании старых версий ntpd (например, 4.2.4p5) это может приводить к ложной секунде координации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Секунда координации (leap second) — что это такое и как «соломки» подстелить