Дрожь в нуле: почему отказ NTP‑сервера ломает промышленную логику

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

Вы когда‑нибудь задумывались, что будет, если время на вашем Linux‑сервере внезапно «поплывёт»? В мире IT это может означать разрозненные логи и путаницу в cron‑задачах.

В промышленной автоматике это куда серьезнее: потеря синхронизации времени между контроллерами и SCADA‑системой делает бесполезной всю хронологию событий. Аварии перестают быть связанными во времени, и найти первопричину становится невозможно.

Давайте разберемся с тем, как на практике диагностировать проблемы с синхронизацией времени на Linux‑сервере, какие инструменты для этого есть и как перейти от обычного NTP к микросекундной точности PTP.

А есть ли синхронизация?

Начнем с самого простого. В современных дистрибутивах Linux за синхронизацию часто отвечает сервис systemd-timesyncd. Проверить его состояние можно командой timedatectl:

Обратите внимание на две ключевые строки:

1. System clock synchronized: yes;

2. NTP service: active.

Если здесь стоит no — значит, синхронизация не работает и в плане времени сервер живет своей жизнью.

Но это лишь верхушка айсберга. Даже если timedatectl говорит «да», это не гарантирует точности. В промышленности нужны микросекунды, а не миллисекунды. 

Диагностируем дрейф системного времени

Если ваш сервер работает без внешней синхронизации (например, в изолированной сети) или синхронизация нестабильна, системные часы начинают «дрейфовать». Это происходит из‑за неточности кварцевого резонатора на материнской плате.

И здесь нам поможет Adjtimex — утилита для управления временными переменными ядра в Linux.

По сути, adjtimex — это низкоуровневый инструмент для настройки системных часов. Он позволяет увидеть, насколько сильно «убегает» время, и скорректировать это.

Сначала просто посмотрим текущие параметры:

Вывод показывает параметры ядра для системных часов. Частота frequency (в единицах 2⁻¹⁶ секунд за тик) отражает текущую корректировку скорости хода часов. Если вы видите большие отклонения, часы пытаются догнать или замедлиться.

Вот пример из реальной практики, когда системные часы теряли примерно секунду каждый час. Администратор вручную подобрал параметры, которые решили проблему:

$ sudo adjtimex --tick 10002 --freq 4000000

Здесь tick это число микросекунд на прерывание таймера и freq — частота коррекции.

Синхронизация с аппаратными часами (RTC)

Если у вас нет доступа к NTP‑серверу, системное время можно синхронизировать с аппаратными часами (CMOS/RTC). Для оценки расхождения используем команду hwclock:

Команда adjtimex может помочь автоматически подобрать параметры, сравнивая системное время с аппаратным. В сложных случаях, когда ntpd не может справиться с дрейфом, используется ручная калибровка через adjtimex или утилита adjtimexconfig.

Диагностика NTP‑сервера и сети

Если синхронизация все же есть, но вы подозреваете проблемы, нужно проверить связь с самим NTP‑сервером.

Ключевые моменты в выводе утилитыchronyc sources -v:

• Символ ^* перед адресом сервера означает, что именно с ним сейчас синхронизируется ваша система. Если вместо ^* вы видите ? (недоступен) или x (ложный тик), есть проблема.

• Offset — отклонение текущего времени от NTP‑сервера. В примере оно составляет около 30 микросекунд (+30us), что отлично для обычной сети.

Если отклонение составляет миллисекунды или больше, нужно искать причину: сетевые задержки, перегруженный NTP‑сервер или неправильные настройки.

Переход на PTP для микросекундной точности

Обычного NTP недостаточно для распределенных систем управления, где требуются метки времени с точностью до долей микросекунды. Здесь на помощь приходит PTP (Precision Time Protocol), определенный стандартом IEEE 1588.

Для начала установим пакет linuxptp, необходимый для работы с этим протоколом:

$ sudo apt update

$ sudo apt install linuxptp

Далее давайте проверим наличие поддержки аппаратного штампа времени. Для этого сначала убедимся, что сетевая карта поддерживает аппаратную отметку времени.

Это критически важно для точности PTP. Команда ethtool покажет, что поддерживает сетевая карта:

Наличие строк hardware-transmit, hardware-receive и hardware-raw-clock говорит о том, что карта поддерживает аппаратный PTP, и можно достигать субмикросекундной точности.

Запуск и анализ работы PTP

Сначала запускаем демон ptp4l, который реализует протокол PTP на выбранном интерфейсе:

Здесь -i eth0 указывает интерфейс, -m выводит сообщения в консоль, -2 использует multicast, а ключ -s означает, что устройство является ведомым (slave). В выводе видно, как устройство инициализируется и становится ведомым, получив время от ведущего (grandmaster).

Для синхронизации системного времени с аппаратными PTP‑часами запускается второй демон — phc2sys (PTP Hardware Clock to system clock):

В этом выводе phc2sys показывает, как он корректирует системное время.

• phc offset — это текущее отклонение системного времени от аппаратных PTP‑часов. Изначально оно было огромным (55 341 микросекунд), но демон быстро его уменьшает.

• s0, s1, s2 — это состояния частотной коррекции. s2 означает, что демон нашел стабильную частоту для подстройки и вышел на нужный режим.

После нескольких итераций offset стремится к нулю (в примере -73), что говорит об успешной синхронизации.

Типовые проблемы и их решения

Теперь давайте рассмотрим несколько типовых проблем, с которыми можно столкнуться при работе с временем.

• Прежде всего, может возникнуть ситуация, когда время не синхронизируется, timedatectl показывает «NTP service: no». Здесь в качестве решения необходимо включить синхронизацию через systemd-timesyncd:

$ sudo timedatectl set-ntp true

• Также возможна ситуация, когда большое расхождение времени блокирует синхронизацию. NTP‑клиент отказывается резко переводить время, если разница слишком велика. 

В таком случае следует установить время вручную, приблизив его к реальному, и снова включить NTP:

$ sudo timedatectl set-ntp false

$ sudo date -s "2026-08-10 14:30:00"

$ sudo timedatectl set-ntp true

• Еще одна типичная проблема, когда в PTP выводе ptp4l отсутствуют сообщения о синхронизации, а offset в phc2sys не уменьшается.

Здесь прежде всего необходимо проверить сетевую связность, а именно выяснить доходят ли PTP‑пакеты. Возможно, их блокирует файрволл на порту 319/320. Проверьте поддержку мультикаста или, если сеть не поддерживает PTP‑коммутаторы, используйте двухшаговый режим (-2).

• Наконец, можно столкнуться с высоким джиттером в PTP‑синхронизации. phc2sys показывает скачущий offset (например, сотни наносекунд туда‑сюда).

Это может быть связано с нагрузкой на процессор или особенностями работы драйвера сетевой карты. Один из способов — убедиться, что к одному аппаратному PTP‑устройству не обращаются несколько процессов одновременно, так как это может вносить нестабильность.

Заключение

Диагностика проблем с синхронизацией времени в промышленной среде — задача многоуровневая. Начинать всегда стоит с проверки состояния timedatectl, затем переходить к анализу NTP‑серверов через chronyc. Для систем, требующих микросекундной точности, нужно освоить PTP, проверив поддержку оборудования через ethtool и отслеживая процесс коррекции через phc2sys.

Помните: даже если все работает, периодически проверяйте логи phc2sys и ptp4l. Дрейф может нарастать со временем, и лучше заметить его на ранней стадии, чем заниматься расследованием аварии с потерянными временными метками.

Если поиск проблем с NTP начинается с анализа состояния системы и логов, важно понимать, где Linux хранит эту информацию и как её правильно использовать. На бесплатном открытом уроке разберём структуру файловой системы, расположение конфигураций и журналов, которые помогают диагностировать сбои.

• 17 сентября в 20:00. «Где Linux хранит настройки и логи: разбираем файловую структуру на практике» — Записаться.