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

При каждой загрузке в Arch я замечаю, что время отличается на несколько минут. Время RTC сбито (насколько я понял, оно “сбилось”). Это влияет на аппаратные часы.

$ timedatectl status
                      Локальное время: Пн 2018-02-12 12:45:18 CET
                  Всемирное время: Пн 2018-02-12 11:45:18 UTC
                        Время RTC: Пн 2018-02-12 11:45:18
                       Часовой пояс: Европа/Берлин (CET, +0100)
       Системные часы синхронизированы: нет
systemd-timesyncd.service активно: нет
                 RTC в локальном TZ: нет

ИЗМЕНЕНИЕ При написании этого поста я не осознал, что значения времени выше этой строки согласованы друг с другом. Однако они имеют смещение относительно времени моих часов и смартфона, которое составляет упомянутые 7 минут.

И моя локаль:

$ locale
LANG=de_DE.utf8
LC_CTYPE="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_PAPER="de_DE.utf8"
LC_NAME="de_DE.utf8"
LC_ADDRESS="de_DE.utf8"
LC_TELEPHONE="de_DE.utf8"
LC_MEASUREMENT="de_DE.utf8"
LC_IDENTIFICATION="de_DE.utf8"
LC_ALL=

Пока я очень неохотно использую hwclock --hctosys, так как мануал гласит:

Эта функция никогда не должна использоваться на работающей системе. Переход системного времени приведет к проблемам, таким как поврежденные временные метки файловых систем. Также, если что-то изменило аппаратные часы, например, ’11-минутный режим’ NTP, то –hctosys установит время неправильно, учитывая компенсацию дрейфа.

Насколько я могу судить, я правильно настроил Windows 10. Есть ли что-то, что я пропустил, или я неправильно настроил часы?

ИЗМЕНЕНИЕ 2 По запросу, содержимое /etc/ntp.conf:

# Пожалуйста, подумайте о присоединении к пулу:
#
#     http://www.pool.ntp.org/join.html
#
# Для дополнительной информации смотрите:
# - https://wiki.archlinux.org/index.php/Network_Time_Protocol_daemon
# - http://support.ntp.org/bin/view/Support/GettingStarted
# - страница мануала ntp.conf

# Присоединяюсь к NTP пулу Arch
server 0.arch.pool.ntp.org
server 1.arch.pool.ntp.org
server 2.arch.pool.ntp.org
server 3.arch.pool.ntp.org

# По умолчанию сервер позволяет:
# - все запросы от локального хоста
# - только временные запросы от удаленных хостов, защищенные ограничением по скорости и kod
restrict default kod limited nomodify nopeer noquery notrap
restrict 127.0.0.1
restrict ::1

# Место расположения файла дрейфа
driftfile /var/lib/ntp/ntp.drift

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

Я бы добавил в ваш файл /etc/ntp.conf в качестве первой строки (это должна быть первая строка):

tinker panic 0

tinker panic – Устанавливает порог паники в секундах с умолчанием
1000 с. Если установить его в ноль, проверка паники отключается, и смещение часов
любого значения будет приниматься.

Хотя это может решить проблему времени Linux в настоящем, я бы также исследовал со временем основные причины дрейфа времени между двумя ОС.

Поскольку команда timedatectl сообщает, что “Всемирное время” (т.е. представление UTC ядра) и “время RTC” синхронизированы, реальное время часов находится в UTC, и время было успешно передано от RTC к часовому ядру при загрузке.

Но Системные часы синхронизированы: нет указывает на то, что ntpd не успешно синхронизируется, возможно, потому что разница между реальным UTC и представлением системы о UTC слишком велика. Ответ Руя Ф. Рибейро был направлен на исправление этого.

Вы должны проверить содержимое файла /etc/adjtime. Первая строка должна содержать три значения, разделенные пробелами. Первое – это предполагаемая системная скорость дрейфа батарейного RTC в секундах в день. Второе значение – это UNIX timestamp последнего времени, когда RTC был отрегулирован для компенсации дрейфа.

Если скорость дрейфа неверно велика (возможно, потому что RTC был отрегулирован другой ОС, пока она работала, что было ошибочно обнаружено как дрейф RTC), это может вызвать 7-минутную ошибку при загрузке.

Поскольку коррекция скорости дрейфа применяется в момент загрузки, когда время копируется от батарейного RTC к часовому ядру, любая ошибка, вызванная неправильной скоростью дрейфа, также может быть передана к часовому ядру. Это объясняет, почему оба часа синхронизированы между собой, оставаясь на 7 минут опережая реальный UTC. Это также означает, что выполнение hwclock --hctosys не исправит проблему.

Если скорость дрейфа в /etc/adjtime аномально велика, вы должны установить ее в ноль или даже удалить весь файл, чтобы предотвратить неправильную коррекцию скорости дрейфа от корректировки ваших часов. Если системные часы будут синхронизированы с NTP, они обычно также передадут синхронизированное время батарейным RTC.

Если вы хотите установить /etc/adjtime так, чтобы он автоматически компенсировал скорость “холодного” дрейфа (т.е. дрейф, который произошел в то время, когда система была выключена или работала под другой ОС), вы можете воспользоваться следующей процедурой:

1.) Просмотрите ваши скрипты запуска и завершения работы, чтобы убедиться, что вы понимаете все моменты, где работают системные часы или батарейный RTC.

2.) Выберите время, когда система будет отключена на относительно длительный период (минимум 4 часа; на ночь или на выходные было бы лучше). Затем временно отключите всю автоматическую NTP синхронизацию. Убедитесь, что скрипты initramfs также охвачены.

3.) Непосредственно перед завершением работы системы убедитесь, что системные часы показывают правильное время, затем выполните > /etc/adjtime; hwclock --systohc --utc --update-drift. Убедитесь, что /etc/adjtime теперь имеет 0.0 как первое значение первой строки, и текущий Unix timestamp как второе значение первой строки + в качестве единственного значения на второй строке, а третья строка содержит UTC. Затем завершите работу системы.

4.) После повторного запуска системы используйте ntpdate или другой метод, который только устанавливает системные часы, чтобы установить систему на точное время UTC. Затем снова выполните hwclock --systohc --utc --update-drift. Теперь первое значение в /etc/adjtime должно обновиться, чтобы соответствовать скорости, на которую дрейфовал RTC, пока система была выключена.

5.) Затем убедитесь, что никакая работа по запуску/завершению/cron не выполняет hwclock --update-drift автоматически; на системе с NTP-синхронизацией вы хотите обновлять скорость дрейфа только тогда, когда вы точно знаете, что ничего не корректировало RTC в течение периода времени, который вы используете для оценки скорости дрейфа.

6.) Наконец, снова включите синхронизацию NTP. Если вы используете двойную загрузку с двумя или более ОС, идеально, чтобы только одна ОС делала корректировки RTC; в противном случае оценки скорости дрейфа будут неточными.

Я не проверял недавние ядра Linux, но более старые имели очень странный код для обновления RTC из системного времени (в RAM). Много лет назад я пытался это исправить, но этот код так и не попал в ядро.

Я думаю, что в современных системах RTC обновляется из системного времени при завершении работы или перезагрузке (если это включено).

Если ваша дистрибуция не предоставляет механизм, вы можете добавить задачу cron (или таймер systemd), чтобы периодически обновлять RTC.