Какой вред наносит дополнительная секунда в системе Unix?
Определил ПУТЬ внутри скрипта и внес некоторые «косметические» изменения.
#!/bin/bash
# Define caminho dos binarios
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
# Carrega uptime
up=("$(uptime -p | awk '{$1=""; sub(" ", " "); print}')")
# Carrega nome do host
host=("$(hostname)")
# Carrega IPs do host
meu_ip=("$(ifconfig | awk '/inet addr/{print substr($2,6)}' | awk 'NR==1{print $1}')")
# Carrega data/hora atual
data=("$(date +"%Y-%m-%d")")
hora=("$(date +"%T")")
# Carrega servicos iniciados durante o boot, ordenados alfabeticamente
servicos=("$(ls -1 /etc/rc$(/sbin/runlevel| cut -d" " -f2).d/S* | awk -F'[0-9][0-9]' '{print " Servico :-> " $2}' | sort -k 3)")
### Define parametros de e-mail ###
email="myemail@address.com" # E-mail do destinatario do alerta
assunto=$host": [Alert] Restart ["$meu_ip"]" # Assunto do email
# Envio de email de alerta
printf "%b\n" "Sistema [$host] ($meu_ip) reiniciado em $data.\n
Uptime: $up\n
Carregado na inicializacao:\n$servicos" | mail -s "$assunto" "$email"
# Aguarda 10s para que o email seja enviado corretamente
sleep 10
# Reinicia o equipamento
reboot
Ни в коем случае.
Дополнительные секунды появляются с 1972 года, и системы Unix все это время переживали их совершенно невредимыми .
RedHat, решивший на этот раз разместить янтарное предупреждение в верхней части своего WWW-сайта службы поддержки клиентов, производит у людей совершенно неверное впечатление и заставляет людей думать, что это что-то вроде вирусного предупреждения нулевого дня, и реагирует таким образом, как показано на Ошибка дополнительной секунды 31 декабря 2016 г. говорит о «ошибке секунды координации».
Дополнительная секунда не является ошибкой , и системы Unix прекрасно справляются с ней. Библиотека C на протяжении десятилетий продвигала идею, что поле tm_sec структуры tm может иногда иметь значение 60 .
На самом деле, единственная реальная проблема заключается в том, что системы Unix и Linux имеют широкий спектр различных способов справиться с ними на любой вкус. Поэтому нужно знать, какую установку он выбрал, чтобы знать, какие действия нужно предпринять, если они вообще есть.
Страница RedHat скорее скрывает это под обширным фоном, делает ложное предположение о системах TAI-10 и не является ответом на вопрос, который задает об операционных системах Unix и Linux в целом (хотя это хороший ответ на мировоззрение, которое ограничено RedHat Linux ).
По сути, вам нужны ответы на три вопроса, чтобы знать, что вам нужно делать:
- Часы вашего ядра работают по всемирному координированному времени? Или в TAI-10?
- Что вы используете для синхронизации часов вашей машины с другими системами?
- Как другие системы справляются с дополнительной секундой?
Некоторые случаи, что делать
Ваше ядро clock - это TAI-10, и машина синхронизируется с помощью TAI-осведомленного инструмента с серверами TAI-10
. Инструмент синхронизации будет чем-то вроде тайклока Дэниела Дж. Бернштейна , Laurent Bercot s6- taiclock или OpenBSD rdate в режиме TAI-10 по умолчанию.
В этом сценарии вам практически не нужно ничего делать, кроме как следить за тем, чтобы ваши таблицы дополнительных секунд были в актуальном состоянии. Часы ядра продолжают отсчитывать одну секунду СИ в секунду (поправки на дрейф генератора и т.п., если это разрешено), а таблицы дополнительных секунд обрабатывают корректировки от TAI-10 до UTC.
Есть два набора таблиц, которые нужно обновлять:
- те, что находятся в ваших файлах
right /часовых поясов, которые вы обновляете, следя за тем, чтобы у вас была последняя версия версия вашего пакета файлов часовых поясов (независимо от того, что это такое) в вашей системе - те, которые используются Bernstein и другими инструментами, которые находятся в
/etc/leapsecs.datM. Бернштейн не обновлял
leapsecs.datна cr.yp.to , но я опубликовал обновленныйleapsecs.dat, который включает 2016 -12-31 23:59:60 UTC секунда координации, упакованная в пакетleapsecs.
Так как серверы, которые вы синхронизируете, также используют TAI-10, секунды, которые они публикуют, также должны быть всегда длиной в одну секунду SI. Серверы, говорящие на TAI-10, не будут шагать, поворачивать или смазывать. Все отмечают секунды SI постоянной длины, а дополнительная секунда видна только как артефакт вашей библиотеки C.
Часы вашего ядра - TAI-10, и машина синхронизируется с помощью инструмента, поддерживающего TAI, с серверами UTC
Инструмент синхронизации будет чем-то вроде rdate OpenBSD в режиме UTC.
Опять же в этом сценарии вам практически не нужно ничего делать, кроме как проверять актуальность таблиц дополнительных секунд, как и в предыдущем сценарии. И снова часы ядра продолжают отсчитывать одну секунду СИ в секунду.
Проблема в том, что серверов нет.
- Если они замазывают дополнительную секунду, то они сообщают о небольшом замедлении времени в течение большей части последнего дня года. Ваш инструмент синхронизации времени без необходимости настраивал TAI-10, чтобы синхронизировать его с этим ложным UTC, в результате чего TAI-10 оказывался с отставанием до секунды, когда наступает дополнительная секунда. Сразу после дополнительной секунды ваши инструменты синхронизации должны будут ускорить часы, чтобы догнать дополнительный тик TAI-10, который они пропустили, пока они были синхронизированы с секундами UTC, превышающими единицу SI, и секундами системных часов. будет короче секунды СИ на некоторое время для компенсации.
- Если они уменьшили дополнительную секунду, то они будут сообщать немного опережающее время на короткое время в первый день нового года. Ваши инструменты синхронизации времени будут без необходимости настраивать TAI-10 для синхронизации с этим ложным UTC. По иронии судьбы, они начнут с корректировки TAI-10 сразу же в дополнительную секунду, и она будет постепенно отклоняться от правильной в течение следующего дня, а затем снова возвращаться позже, поскольку серверы времени постепенно замедляются обратно до UTC, пока ваши инструменты синхронизации Попробуй одновременно ускорить TAI-10 к их ложному времени UTC.
- Если они шагают в секунду координации, они просто не будут сообщать вам о монотонно увеличивающемся времени, но вставка секунды координации, выполненная вашими инструментами синхронизации, должна фактически вычислить вещи правильно, за исключением самого момента дополнительная секунда, когда отчет в формате UTC с серверов неоднозначен. Тем не менее, они будут, по крайней мере, тикать со скоростью одна СИ-секунда в секунду, и TAI-10 будет оставаться правильным в дни до и после, и не будет колебаться из-за ненужных попыток синхронизировать TAI-10 с временем UTC, которое на самом деле неправильно.
Итак, если вы работаете с TAI-10, вам, как правило, нравятся серверы времени UTC, которые шаг увеличивают секунды, потому что другие параметры фактически заставляют ваше время TAI-10 синхронизироваться с ускорением или замедлением. -низить UTC без надобности и потерять один СИ в секунду в секунду.
Часы вашего ядра - UTC, и машина синхронизируется с серверами UTC с помощью инструмента UTC.
Этот случай подразделяется в зависимости от того, что делают серверы времени, с которыми вы синхронизируете.
- Если они замазывают дополнительную секунду, то они сообщают о небольшом замедлении времени в течение большей части последнего дня года. Ваш инструмент синхронизации времени синхронизируется с этим, и ваши часы будут отставать от времени в течение дня.
- Если они убили дополнительную секунду, то они будут сообщать немного опережающее время на короткое время в первый день нового года. Ваш инструмент синхронизации времени синхронизируется с этим, и ваши часы будут опережать время на часть дня.
- Если они перейдут на дополнительную секунду, они просто не будут сообщать вам о монотонно увеличивающемся времени, а вашим инструментам синхронизации покажется, что системные часы внезапно превышают значение секунды и требуют корректировки. . Их реакция будет зависеть от того, как вы настроили инструменты синхронизации.
- Они могут просто перешагнуть системные часы, и в этом случае ваши приложения будут видеть шаг назад на секунду.
- Однако они с большей вероятностью отключат системные часы; в этом случае ваша машина какое-то время будет отсчитывать секунды, которые длиннее, чем фактическая секунда в системе СИ, и опережать время на часть дня.
- Если они объявляют дополнительную секунду, то есть просто переходят с предупреждением о приближении шага, то они передают решение о том, что делать вашим инструментам синхронизации. {{1 }}
- Они могут просто перешагнуть системные часы, и в этом случае ваши приложения увидят временной шаг назад на секунду.
- Однако они, скорее всего, приведут к снижению или искажению системных часов; в этом случае ваша машина будет показывать секунды, которые длиннее, чем фактическая секунда в системе СИ, либо за предыдущий, либо за следующий день.
Последствия
Только в одном из случаев, когда серверы UTC + машина UTC время вашей машины будет правильным, в случае, когда приложения видят, что время идет в обратном направлении, то, что приложения Unix не любят видеть.Во всех остальных случаях UTC-серверы + UTC-машина время вашего компьютера будет неверным в течение суток.
В случае TAI-10-серверы + TAI-10-машина время вашей машины будет всегда правильным. И в одном из случаев UTC-сервер + TAI-10-машина, когда сервер шагает время, время вашей машины также будет правильным, если только не произойдет опрос прямо на неоднозначное время UTC.
Последствия того, что время вашей машины неверное, проявляются на уровне приложения. Операционная система с этим справляется. (Вопреки распространенному мнению, POSIX фактически допускает, чтобы системные часы были, возможно, преднамеренно неправильными.) Если вы делаете такие вещи, как, например, выставление счетов людям по секундам, ваше представление о том, как долго длится секунда и когда происходит каждая секунда. , отличается от идеи ваших клиентов, возможно, на два дня. Возможно, вы и ваши клиенты выбрали разные настройки.
Тогда есть возможная проблема, связанная с вашим выбором синхронизации со смешанным набором серверов времени, некоторые из которых изменяли UTC, некоторые из которых шаг UTC, а некоторые из которых мазок UTC. В этом случае возникает много веселья, поскольку вы путаете ад из своих инструментов синхронизации. Там тоже много иронии. «Тупые» инструменты синхронизации лучше справляются с рассинхронизированными источниками времени, чем «умные», которые пытаются определить, какой источник времени показывает правильное время. В этой конкретной ситуации только степперы показывают правильное время .Принимая во внимание, что у слюнявчиков и разморчителей есть противоречивые представления о том, что такое неправильное всемирное координированное время.
Последнее бесчестное упоминание касается ядра Linux, обсуждаемого на странице RedHat. Инструменты синхронизации могут выбирать шаг времени самостоятельно или могут указать ядру на это. Как сообщает RedHat,есть история проблем с этим, от внутренних механизмов синхронизации в ядре, которые не работают правильно, до зависания машины.