这太疯狂了。
我有一个双引导系统,一个操作系统是 FreeDOS(它没有能力处理除本地时间之外的 CMOS 时钟),另一个操作系统是 Linux Mint 17。
该系统的使用方式是我们坐在 Linux 中等待“触发器”(软件触发器)开始测试。测试是在 FreeDOS 下完成的,因此脚本在 Linux 中设置所有内容,然后将系统设置为启动 FreeDOS 并运行测试,然后重新启动回 Linux。这种情况从每隔几分钟到每隔几天发生一次。
我们注意到,有时时钟会完全混乱。我们似乎陷入了一个循环:‘将 CMOS 时钟设置为 UTC;加载 CMOS 时钟,假设它是本地时间(砰,快了 8 小时);将 CMOS 时钟设置为 UTC(再加 8 小时!!!);重复’。
在两个系统中,时钟正确是绝对要求(嗯,绝对希望),无论我们从一个系统启动到另一个系统的频率或很少。
我在Linux端设置了NTP,通常工作正常。
显然我处于 11 分钟模式。
以下是将硬件(CMOS)时钟设置为本地时间,然后等待 11 分钟并再次查看后发生的情况:
tjr2pc1 ~ # date ;timedatectl status ; sleep 660 ; date;timedatectl status
Thu Feb 4 12:03:33 MST 2016
Local time: Thu 2016-02-04 12:03:33 MST
Universal time: Thu 2016-02-04 19:03:33 UTC
RTC time: **Thu 2016-02-04 12:03:33**
Timezone: America/Phoenix (MST, -0700)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes
DST active: n/a
Warning: The RTC is configured to maintain time in the local time zone. This
mode is not fully supported and will create various problems with time
zone changes and daylight saving adjustments. If at all possible use
RTC in UTC, by calling 'timedatectl set-local-rtc 0'.
Thu Feb 4 12:14:33 MST 2016
Local time: Thu 2016-02-04 12:14:33 MST
Universal time: Thu 2016-02-04 19:14:33 UTC
RTC time: **Thu 2016-02-04 19:14:33**
Timezone: America/Phoenix (MST, -0700)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes
DST active: n/a
-----------------
请注意,CMOS 时钟突然变为 UTC 时间! ****请停下来***
我什至尝试安装 fake-hwclock,这种情况仍然发生。我什至将 /sbin/hwclock 重命名为 /sbin/real_hwclock ,试图让内核只留下被破坏的 CMOS。
回顾一下:我们的目标是让时间在 FreeDOS 和 Linux 上都发挥作用。
我不在乎这是否意味着 Linux 将 CMOS 时钟设置为 UTC,然后在关机时将其恢复为本地时间,或者我是否可以以某种方式强制 Linux 将其设置为本地时间而不是 UTC。或者如果我可以让 Linux 完全忽略 CMOS 时钟(这就是我安装 fake_hwclock 的原因 - 我希望这样可以做到。但没有)。我不在乎如何,我只需要在 Linux 关闭后将 CMOS 时钟设置为正确的本地时间(以便 FreeDOS 获得正确的时间)。 (由于太复杂的原因,无法打扰大家,不可能在 FreeDOS 下运行网络,所以我可以使用 ntp 或脚本或其他东西来自动正确设置时间。并使“转到 FreeDOS 脚本编写一个脚本”在 FreeDOS 下设置时间和日期是愚蠢的,但我将这样做只是为了停止与愚蠢作斗争)
我已经说过timedatectl
CMOS 时钟是当地时间。
/etc/default/rcS
说:
UTC=no
然而,每隔 11 分钟就会有人(我猜是内核)将 CMOS 时钟设置为 UTC 时间!尽管我明确表示应该是当地时间。
而且,是的,自从将 rcS 设置为 UTC=no 以来,我已经重新启动(多次)。是否还有另一个配置文件可以让内核保留 CMOS 时钟,或者强制将其设置为本地时间?
更新:我发现了一些关于“11 分钟模式”的有趣的事情,包括 reddit 上的一个问题,它讨论了这件事,并指责 ntp 和 adjtimex (内核内部,而不是可执行文件)。还没有解决方案,我将编写一个每分钟运行一次的 cron 作业,并强制硬件时钟回到本地时间。 (我讨厌使用这样的大锤,但我真的需要时间正确 - 尽快,因为我们的时钟完全混乱了(一台计算机的时间慢了 12 小时以上(奇怪),一台计算机快了 7 小时,一台计算机的时间快了 7 小时)从周五到周一就提前了差不多一天半!)
答案1
好吧,首先,我不明白为什么我在这个问题上被否决了。
无论如何,三年后我终于找到了解决方案:
确保 /etc/adjtime 有“LOCAL”而不是“UTC”(在我的例子中,它是文件的最后一行)。
确保 /etc/hardwareclock 中有“localtime”(在我的例子中,这是一个新文件,并且只有该行)。
执行上述操作似乎关闭了内核中的“NTP 同步”标志,这使得内核在关闭时无法将 UTC 时间写入 CMOS 时钟。所以内核很可能不会在 CMOS 时钟中保存系统时间(我还没有验证这一点)。然而,上述2个变化似乎关闭了“11分钟模式”。
这是“timedatectl”的输出:
rusty@quigon2 ~ $ timedatectl
Local time: Wed 2019-01-30 14:18:53 MST
Universal time: Wed 2019-01-30 21:18:53 UTC
RTC time: Wed 2019-01-30 14:18:50
Time zone: America/Phoenix (MST, -0700)
Network time on: yes
NTP synchronized: no
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
...blah blah...
(请注意上面的“NTP 同步”信息)。
如果您想与 NTP 同步(通过 ntpd 或 rdate 或其他方式),那就是另一回事了。 (我使用 cron 作业每 30 分钟进行一次 rdate 和 hwclock --systohc...)
使用某些特定选项运行 timedatectl 可能会对上述文件执行上述更改,我尚未对此进行测试。
答案2
man datetimectl
有帮助
两步:
timedatectl set-local-rtc 1
--> 将 CMOS 设置为当地时间sudo hwclock --systohc
--> 将本地时间复制到 CMOS 时钟
答案3
就我而言,我决定在 hwclock 中使用 UTC 以避免夏令时问题。
/etc/default/rcS
启动时,如果该行存在 ,则来自 hwclock 的系统时间设置将起作用UTC=yes
。
但能否正常hwclock --systohc
工作取决于各种设置。
使用TZ=UTC0
环境变量似乎是一个糟糕的选择,因为它会覆盖 UTC 的设置/etc/localtime
并且date
也可以在 UTC 中工作。
使用hwclock --systohc --utc
可以用于手动设置,但当时间由 ntp 设置并自动将时间存储到 hwclock 时会失败。
另外,该reboot
命令似乎使用错误的时区写入 hwclock。
我的/etc/default/ntpdate
包含
# Configuration script used by ntpdate-sync script
NTPSERVERS="de.pool.ntp.org"
# Set to "yes" to write time to hardware clock on success
UPDATE_HWCLOCK="yes"
但你可以修改//etc/adjtime
创建
0 0 0
0
UTC
这只会影响hwclock
并强制它以 UTC 格式存储/读取时间。
顺便提一句。对于某些系统(如 Yocto/busybox),文件可能存储在不同的位置,在我的例子中/var/lib/hwclock/adjtime