Я не могу гарантировать нормальные часы реального времени на некоторых машинах (время может быть неправильным на часы, месяцы или даже годы). Поскольку у меня также периодически возникают сети, я настроил Chrony в надежде, что это поможет решить проблему.
Но похоже, что Хрони хочет медленно настраивать часы с течением времени, сохраняя их монотонность и без резких изменений. Этого достаточно, когда дрейф составляет порядка секунд, но это просто не решение для моего случая (в моих тестах потребовались часы, чтобы исправить 10-минутный дрейф). Я отключил maxupdateskew, Кстати.
На самом деле я хочу внести большое изменение на ранней стадии загрузки (немонотонное, если время установлено в будущем), с точностью до секунд или (даже лучше) миллисекунд, и после его применения клиент ntp может делать его постепенные корректировки. Я предположил, что это важный вариант использования для клиентов ntp, особенно для машин без RTC, но я не могу найти хорошо поддерживаемые решения для этой проблемы.
Я учел следующее:
Бег hwclock --set --date="$(magically-get-correct-time)"; hwclock -s прямо перед тем, как Хрони сделает свою работу. Проблема в том, что magically-get-correct-time по-прежнему нужно собирать данные через ntp или другой сервис, а затем мне нужно запланировать запуск Chrony после его успешного выполнения ... это сложно сделать (например: что, если эта команда не сработает из-за плохой сети? Это может быстро усложниться). В общем, это похоже на заклеивание изолентой.
С помощью ntpdate прямо перед Хрони. Google сообщает, что это предлагалось на некоторых форумах. Я не знаю, насколько хорошо это сработает, да еще и похоже на скотч. (также сообщается, что ntpdate устарел)
Прямо сейчас я действительно ищу способ решить эту проблему, используя только Chrony. Что заставило меня так подумать мощь решить эту проблему можно на странице Fedora Wiki относительно Chrony в качестве клиента NTP по умолчанию. Он утверждает:
после начальной синхронизации часы никогда не изменяются, это хорошо для приложений, которым требуется, чтобы системное время было монотонным
Для меня это говорит о том, что во время чего-то вызванного начальная синхронизация, Chrony может делать немонотонный шаг. По крайней мере, я так надеюсь. Но на моей установке, когда он говорит
Feb 19 17:15:30 black chronyd[696]: System clock wrong by -759.702379 seconds, adjustment started
Это не прыгайте, чтобы агрессивно исправить это как можно скорее; вместо этого он распределяет изменение по часам, никогда не делая немонотонных изменений. Так что я не вижу упоминания об этой «начальной синхронизации». И я не смог узнать, как настроить его, чтобы любой немонотонная настройка вообще.
Кстати, я использую Arch Linux с Chrony 1.27.
Использовать initstepslew как показано в документация.
Например:
initstepslew 30 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org
И замените батарейки ...