我正在运行 Debian Stretch 和 Linux 内核版本 4.9.110-3+deb9u4,并修改了配置。我观察到以下奇怪的行为
- 将硬件时钟设置为
2016-01-01 00:00:00 UTC
- 重启
dmesg
报告读取硬件时钟,类似于之前设置的内容date
报告2016-11-03 17:16:42 UTC
在 之前的任何日期都会观察到上述行为2016-11-03 17:00:00 UTC
。我没有进一步缩小范围。
内核源代码没有更改,我也没有运行任何自定义内核模块。我还通过使用 Debian 存储库中的 4.9.168 内核以及stretch-backports 中的 4.19.37 内核观察到了这一点。我还能够在运行 Stretch 和 4.9.168 的 DigitalOcean Droplet 上重现这一点。
当我设置2016-11-03之后的日期时,我没有看到这个问题发生。这似乎不太可能,但内核似乎正在强制执行一些最短日期。
有人对此有线索吗?
来自我的虚拟机的日志:
root@debian-vm:~# timedatectl
Local time: Thu 2016-11-03 17:17:02 UTC
Universal time: Thu 2016-11-03 17:17:02 UTC
RTC time: Fri 2016-01-01 00:29:00
Time zone: Etc/UTC (UTC, +0000)
Network time on: yes
NTP synchronized: no
RTC in local TZ: no
root@debian-vm:~# dmesg | grep rtc
[ 0.985653] rtc_cmos 00:01: registered as rtc0
[ 0.985670] rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[ 1.032409] rtc_cmos 00:01: setting system clock to 2016-01-01 00:28:37 UTC (1451608117)
来自 DigitalOcean Droplet 的日志:
root@debian-s-1vcpu-1gb-sfo2-01:~# timedatectl
Local time: Thu 2016-11-03 17:17:05 UTC
Universal time: Thu 2016-11-03 17:17:05 UTC
RTC time: Fri 2016-01-01 00:00:46
Time zone: Etc/UTC (UTC, +0000)
Network time on: yes
NTP synchronized: no
RTC in local TZ: no
答案1
原来这不是在Linux内核中,而是在systemd中。 systemd 时钟实用程序在构建时定义了一个最小时钟值,如果从 RTC 读取的时间早于该时钟时间,它将强制系统时钟为该最小时间。这个“最短时间”可以由Meson构建系统指定,也可以从构建环境中NEWS文件的创建时间中读取。
以下日志显示 systemd 正在使时钟提前,并显示最小时钟值。
root@debian-vm:~# journalctl -b | grep time | grep systemd
Nov 03 17:16:43 debian-vm systemd[1]: System time before build time, advancing clock.
root@debian-vm:~# date --date="$(uptime -s)" +%s
1478193400
root@debian-vm:~# uptime -s
2016-11-03 17:16:40
您可以查看检查最小时钟的 systemd 源代码这里