Короткий ответ
Сначала timedatectl и кто владеет часами: systemd-timesyncd (дефолт Ubuntu Server) или chrony/ntpsec. Не запускайте оба. Если хост в AD/FreeIPA/Kerberos, не делайте date -s на часы вперёд/назад — билеты и TLS «not yet valid». Предпочтите smear/step маленькими шагами (chronyc makestep с пониманием, timesyncd сам огранивает). DNS имени NTP-сервера должен резолвиться — иначе sync не встанет.
Хост host.example (10.0.20.10), пользователь admin.
Симптомы и как отличить
timedatectl:NTP service: inactive,System clock synchronized: no;- cron/timer «не в то время» — cron, timer;
- SSH GSSAPI отваливается;
- apt Valid-Until — пересечение с репо.
| Источник | Файл |
|---|---|
| timesyncd | /etc/systemd/timesyncd.conf |
| chrony | /etc/chrony/chrony.conf |
| virtio RTC | гипервизор, timedatectl set-ntp |
Возможные причины
- timesyncd disabled, chrony не установлен.
- Firewall UDP/123 исходящий.
NTP=указывает на мёртвыйntp.exampleбез DNS.- Два клиента NTP конфликтуют.
- Часовой пояс
UTCvsEurope/Moscowпутают с «NTP сломан» — offset 3 часа при sync=yes. - Ручной
dateпосле которого timesyncd боится большого step. - RTC hwclock в локали vs UTC (
timedatectl | grep RTC).
Диагностика
timedatectl
timedatectl timesync-status
systemctl status systemd-timesyncd.service chrony.service --no-pagerЕсли timesyncd:
systemctl cat systemd-timesyncd
grep -v '^#' /etc/systemd/timesyncd.conf
resolvectl query ntp.ubuntu.com
ss -ulnp | grep 123 || truetimesyncd — клиент, не обязан слушать 123.
chrony:
chronyc tracking
chronyc sources -v
chronyc sourcestatsСеть:
# с рабочей станции админа к NTP, если разрешено политикой
nc -uzv 10.0.20.10 123На самом сервере исходящий 123 может резать UFW outbound (редко) или корпоративный FW.
Журнал:
journalctl -u systemd-timesyncd -u chrony -b --no-pager | tail -n 40Kerberos риск: если skew уже часы, план согласовать с владельцем домена до step.
Решение
Сценарий A. Вернуть timesyncd (типичный Ubuntu)
sudo systemctl disable --now chrony.service 2>/dev/null || true
sudo systemctl enable --now systemd-timesyncd
sudo timedatectl set-ntp true
timedatectl timesync-status/etc/systemd/timesyncd.conf:
[Time]
NTP=ntp.cloud.example
FallbackNTP=ntp.ubuntu.comDNS обязан резолвить эти имена.
Сценарий B. chrony как единственный клиент
Для серверов, которые сами раздают время, chrony лучше. Не вместе с timesyncd.
sudo systemctl disable --now systemd-timesyncd
sudo systemctl enable --now chrony
chronyc trackingБольшой offset: chronyc makestep если нет Kerberos, или makestep 1 -1 в conf для следующих стартов. В домене согласуйте окно.
Сценарий C. Часовой пояс, NTP уже sync
timedatectl set-timezone Europe/Moscow
dateЭто не NTP. Журналы и cron сдвинутся.
Сценарий D. Гипервизор
Включите sync RTC на хосте, отключите конфликтующий periodic sync каждую минуту плюс NTP в госте (один источник истины). Двойной slew иногда даёт осцилляцию.
Сценарий E. Firewall исходящий
Разрешите UDP/123 к корпоративным NTP, не «открыть 123/udp inbound на весь интернет» на host.example.
Kerberos, TLS и величина step
Правило: смещение < 5 минут часто лечится slew timesyncd/chrony без видимого обрыва. Смещение часы/дни — согласуйте окно: kdestroy на клиентах, перезапуск sssd/winbind, проверка TLS (openssl s_client смотрит notBefore).
timedatectl | grep -E 'Local time|Universal|synchronized|NTP'
sudo journalctl -u systemd-timesyncd -n 20 --no-pagerNTP synchronized: yes при неверном timezone всё равно даёт «cron в 3 ночи по Москве не в 3». Это не NTP.
В OpenStack/AWS метаданные иногда пишут NTP= на недоступный из приватной сети пул. Ставьте корпоративные IP в timesyncd.conf, не имена, если DNS ещё лежит (курица-яйцо с DNS).
hwclock --show vs date: расхождение после reboot значит RTC не в UTC или гипервизор переписывает часы на старте. Выберите один источник.
Не ставьте AllowNTPsec пакеты параллельно chrony «для надёжности». Один клиент.
timedatectl set-ntp true не стартует chrony, если enabled timesyncd masked. Явно: systemctl is-enabled systemd-timesyncd chrony. Masked unit (systemctl mask) переживает enable — unmask сначала.
В контейнере без /dev/rtc и без CAP_SYS_TIME timedatectl покажет read-only clock. Время берётся с хоста. Не ставьте chrony в каждый контейнер.
Для AD-клиента на Ubuntu (sssd/realmd) допустимый skew обычно 5 минут. Если DC и этот хост оба «синхронизированы», но к разным stratum с расхождением — смотрите chronyc tracking RMS offset, не только yes/no.
Не используйте ntpdate пакет: он deprecated, делает step и конфликтует. Только timesyncd или chrony.
Проверка смещения без доверия к самому хосту: сравните date -u с заведомо верным DC/телефоном в UTC. chronyc tracking поле System time — секунды, на сколько ОС впереди/позади NTP. Значение 0.00x — норма. Секунды и минуты — инцидент.
systemd-timesyncd не умеет полноценный stratum-сервер для сети. Если host.example должен раздавать время филиалам — chrony allow в LAN, firewall UDP/123 inbound только с LAN, не с интернета.
Виртуализация: пауза VM на час (snapshot) даёт скачок. chrony makestep 1.0 3 на старте помогает гостю, но снова опасен для Kerberos, если пауза регулярная. Лучше не ставить AD-клиент на часто снапаемые VM.
Как проверить, что проблема устранена
timedatectl
# System clock synchronized: yes
date -Is
chronyc tracking 2>/dev/null || timedatectl timesync-statusСравните с заведомо верным источником (телефон с NTP, другой DC). TLS к внутреннему сайту проходит. Для AD: kinit admin без skew (если используется).
Подождите 2–3 минуты после старта timesyncd — статус не всегда мгновенный.
Если не помогло
- Sync yes, приложения всё ещё skew: TZ в JVM
user.timezone, не OS. - chrony
Falseticker: разъехались три NTP источника — оставьте 3–5 согласованных. - Контейнер без CAP_SYS_TIME — время с хоста.
Профилактика
- Мониторинг
synchronized: yesи offset < 100–200 ms (свой порог). - Только один NTP-клиент.
- Корпоративные NTP, не только публичные, для Kerberos-среды.
- Запрет ручного
date -sв runbook.
FAQ
timesyncd хуже chrony?
Для обычного сервера хватает. chrony — если сами stratum, нужно makestep/offline.
Нужен ли ntp пакет?
На Ubuntu 22.04/24.04 чаще timesyncd или chrony. Пакет ntp классический — не ставьте третьим.
RTC in local TZ: yes
Для Linux сервера обычно no (UTC в железе). Иначе двойной сдвиг после reboot.
Можно ли step раз в сутки cron?
Нет. Это и есть ломание Kerberos. Используйте NTP slew.
VMWare tools time sync + chrony
Выберите одно. Два источника — дрейф.