☰

尽管区域设置和时区是正确的，但每次启动时硬件和系统时钟都会偏移大约 7 分钟

tag-icon • tag-icon linux timezone clock
尽管区域设置和时区是正确的，但每次启动时硬件和系统时钟都会偏移大约 7 分钟

每次启动 Arch 时，我都会看到时间晚了几分钟。 RTC时间关闭（据我所知，它已经“漂移”。）并影响硬件时钟。

$ timedatectl status
                      Local time: Mo 2018-02-12 12:45:18 CET
                  Universal time: Mo 2018-02-12 11:45:18 UTC
                        RTC time: Mo 2018-02-12 11:45:18
                       Time zone: Europe/Berlin (CET, +0100)
       System clock synchronized: no
systemd-timesyncd.service active: no
                 RTC in local TZ: no

编辑在写这篇文章时，我没有意识到这条线上方的时间值与另一条线是一致的。然而，他们对我的手表和智能手机时间有一个偏移，即前面提到的 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手册页所述的内容：

切勿在正在运行的系统上使用此函数。跳跃系统时间会导致问题，例如文件系统时间戳损坏。另外，如果硬件时钟发生了变化，例如 NTP 的“11 分钟模式”，那么 --hctosys 将通过包含漂移补偿来错误地设置时间。

据我所知，我正确配置了 Windows 10。我是否遗漏了什么或者我没有正确设置时钟？

编辑2根据要求，内容/etc/ntp.conf：

# Please consider joining the pool:
#
#     http://www.pool.ntp.org/join.html
#
# For additional information see:
# - https://wiki.archlinux.org/index.php/Network_Time_Protocol_daemon
# - http://support.ntp.org/bin/view/Support/GettingStarted
# - the ntp.conf man page

# Associate to Arch's NTP pool
server 0.arch.pool.ntp.org
server 1.arch.pool.ntp.org
server 2.arch.pool.ntp.org
server 3.arch.pool.ntp.org

# By default, the server allows:
# - all queries from the local host
# - only time queries from remote hosts, protected by rate limiting and kod
restrict default kod limited nomodify nopeer noquery notrap
restrict 127.0.0.1
restrict ::1

# Location of drift file
driftfile /var/lib/ntp/ntp.drift

答案1

如果启动时实际时间与 RTC 之间的时间差较大，则可以配置 NTP 在启动后一次性过度补偿，而不是随着时间的推移缓慢且增量地进行补偿。

我将添加到您的/etc/ntp.conf文件作为第一行（它必须是第一行）：

tinker panic 0

Tinker Panic - 指定恐慌阈值（以秒为单位），默认为 1000 秒。如果设置为零，则禁用恐慌健全性检查，并且将接受任何值的时钟偏移。

虽然这可能会解决目前的 Linux 时间问题，但我也会随着时间的推移调查两个操作系统之间时间漂移的根本原因。

答案2

由于该timedatectl命令报告“通用时间”（即内核对 UTC 的概念）和“RTC 时间”是同步的，因此实时时钟为 UTC 时间，并且时间已成功从 RTC 传输到内核时钟在启动时。

但System clock synchronized: no表明那ntpd是不是同步成功，可能是因为真实UTC与系统设想的UTC相差太大。 Rui F. Ribeiro 的回答旨在解决这个问题。

您应该检查该文件的内容/etc/adjtime。第一行应包含三个值，以空格分隔。第一个是电池供电的 RTC 的假设系统漂移率，以每天秒为单位。第二个值是最近一次 RTC 漂移调整时间的 UNIX 时间戳。

如果漂移率错误地较大（可能是因为RTC在运行时被另一个操作系统调整，被误检测为RTC漂移），则可能会导致启动时出现7分钟错误。

由于漂移率校正是在启动时应用的，此时时间从电池供电的 RTC 复制到内核时钟，因此由不正确的漂移率引起的任何错误也可能传播到内核时钟。这可以解释为什么两个时钟彼此同步，但与实际 UTC 相差 7 分钟。这也意味着跑步hwclock --hctosys并不能解决问题。

如果漂移率/etc/adjtime异常大，您应该将其设置为零甚至擦除整个文件，以阻止错误的漂移率校正调整您的时钟。如果系统时钟要与 NTP 同步，它通常也会将同步时间传播到电池供电的 RTC。

如果您想设置/etc/adjtime自动补偿“冷”漂移率（即系统关闭或运行另一个操作系统时发生的漂移），那么您可以使用以下过程：

1.) 检查您的启动和关闭脚本，以确保您了解系统时钟或电池供电的 RTC 运行的所有点。

2.) 选择系统停机时间相对较长的时间（至少 4 小时；过夜或周末更好）。然后暂时禁用所有自动 NTP 同步。确保 initramfs 脚本也被覆盖。

3.) 在关闭系统之前，请确保系统时钟的时间正确，然后运行> /etc/adjtime; hwclock --systohc --utc --update-drift​​。验证/etc/adjtimenow0.0作为第一行的第一个值，当前 Unix 时间戳作为第一行的第二个值 + 作为第二行的唯一值，第三行显示UTC。然后关闭系统。

4.) 再次启动系统后，使用ntpdate或其他一些方法只设置内核时钟让系统获得准确的 UTC 时间。然后再跑hwclock --systohc --utc --update-drift。现在，应更新第一个值，/etc/adjtime以匹配系统停机时 RTC 漂移的速率。

5.) 然后确保没有启动/关闭/cron 作业hwclock --update-drift自动运行；在 NTP 同步系统上，你只需要在以下情况下更新漂移率：确定知道在您用于漂移率估计的时间段内，没有任何内容调整 RTC。

6.) 最后，重新启用 NTP 同步。如果您使用两个或多个操作系统进行双启动，则理想情况下应该只有一个操作系统对 RTC 进行调整；否则漂移率估计将不准确。

答案3

我没有检查最近的 Linux 内核，但较旧的内核有一个非常奇怪的代码来从系统时间（在 RAM 中）更新 RTC。许多年前我曾尝试修复这个问题，但该代码从未进入内核。

我认为当前系统会在关机或重新启动时（如果启用）从系统时间更新 RTC。

如果您的发行版没有提供机制，您可以添加一个 cron 作业（或systemd计时器）来定期更新 RTC。

相关内容