对于大学任务,我有一个系统可以进行一些调查。当我分析 kern.log 以及 syslog 和 auth.log 文件时,我想知道一个特定的行为:每次系统启动时,日志中的某个点的日志时间戳会向后跳两个小时。
我的第一个想法是,系统以 hwclock UTC 时间启动,在某个时刻,将应用时区 (UTC+2)。但由于时区是 UTC+2(而不是 UTC-2),我希望向前跳跃而不是向后跳跃。
有谁可以给我这种行为的解释(或解释的提示)吗?
这就是我的意思:
...
Jun 5 20:05:27 pc kernel: [ 11.383305] snd_hda_codec_idt hdaudioC0D0: autoconfig for STAC9221 A1: line_outs=3 (0xc/0xf/0xb/0x0/0x0) type:speaker
Jun 5 20:05:27 pc kernel: [ 11.383307] snd_hda_codec_idt hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Jun 5 20:05:27 pc kernel: [ 11.383308] snd_hda_codec_idt hdaudioC0D0: hp_outs=1 (0xa/0x0/0x0/0x0/0x0)
Jun 5 20:05:27 pc kernel: [ 11.383309] snd_hda_codec_idt hdaudioC0D0: mono: mono_out=0x0
Jun 5 20:05:27 pc kernel: [ 11.383310] snd_hda_codec_idt hdaudioC0D0: dig-out=0x10/0x0
Jun 5 20:05:27 pc kernel: [ 11.383310] snd_hda_codec_idt hdaudioC0D0: inputs:
Jun 5 20:05:27 pc kernel: [ 11.383311] snd_hda_codec_idt hdaudioC0D0: Mic=0xd
Jun 5 20:05:27 pc kernel: [ 11.383312] snd_hda_codec_idt hdaudioC0D0: Line=0xe
Jun 5 20:05:27 pc kernel: [ 11.383313] snd_hda_codec_idt hdaudioC0D0: CD=0x15
Jun 5 20:05:27 pc kernel: [ 11.383314] snd_hda_codec_idt hdaudioC0D0: dig-in=0x11
Jun 5 20:05:27 pc kernel: [ 11.407403] input: HDA Intel Mic as /devices/pci0000:00/0000:00:05.0/sound/card0/input8
Jun 5 20:05:27 pc kernel: [ 11.407540] input: HDA Intel Line as /devices/pci0000:00/0000:00:05.0/sound/card0/input9
Jun 5 20:05:27 pc kernel: [ 11.407675] input: HDA Intel Speaker Front as /devices/pci0000:00/0000:00:05.0/sound/card0/input10
Jun 5 20:05:27 pc kernel: [ 11.407810] input: HDA Intel Speaker CLFE as /devices/pci0000:00/0000:00:05.0/sound/card0/input11
Jun 5 20:05:27 pc kernel: [ 11.407938] input: HDA Intel Front Headphone as /devices/pci0000:00/0000:00:05.0/sound/card0/input12
Jun 5 20:05:27 pc kernel: [ 11.408111] input: HDA Intel SPDIF In as /devices/pci0000:00/0000:00:05.0/sound/card0/input13
Jun 5 20:05:27 pc kernel: [ 14.635240] audit: type=1400 audit(1591380319.980:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" pid=620 comm="apparmor_parser"
Jun 5 20:05:27 pc kernel: [ 14.655840] audit: type=1400 audit(1591380320.004:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=618 comm="apparmor_parser"
Jun 5 20:05:27 pc kernel: [ 14.741500] audit: type=1400 audit(1591380320.088:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=617 comm="apparmor_parser"
Jun 5 20:05:27 pc kernel: [ 14.742736] audit: type=1400 audit(1591380320.088:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="ippusbxd" pid=616 comm="apparmor_parser"
Jun 5 20:05:27 pc kernel: [ 15.019051] audit: type=1400 audit(1591380320.364:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=624 comm="apparmor_parser"
Jun 5 20:05:27 pc kernel: [ 15.053162] audit: type=1400 audit(1591380320.400:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=627 comm="apparmor_parser"
Jun 5 20:05:27 pc kernel: [ 15.053165] audit: type=1400 audit(1591380320.400:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=627 comm="apparmor_parser"
Jun 5 20:05:27 pc kernel: [ 15.084543] audit: type=1400 audit(1591380320.428:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/tcpdump" pid=619 comm="apparmor_parser"
Jun 5 20:05:27 pc kernel: [ 15.158035] audit: type=1400 audit(1591380320.504:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="system_tor" pid=623 comm="apparmor_parser"
Jun 5 20:05:27 pc kernel: [ 15.748144] audit: type=1400 audit(1591380320.652:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=632 comm="apparmor_parser"
Jun 5 20:05:38 pc kernel: [ 32.906512] kauditd_printk_skb: 28 callbacks suppressed
Jun 5 20:05:38 pc kernel: [ 32.906515] audit: type=1400 audit(1591380338.248:40): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=765 comm="cups-browsed" capability=23 capname="sys_nice"
Jun 5 20:05:40 pc kernel: [ 34.654094] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Jun 5 20:05:40 pc kernel: [ 34.654536] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s3: link becomes ready
Jun 5 18:05:55 pc kernel: [ 49.364257] snd_hda_intel 0000:00:05.0: Invalid position buffer, using LPIB read method instead.
Jun 5 18:05:55 pc kernel: [ 49.571782] snd_hda_intel 0000:00:05.0: Invalid position buffer, using LPIB read method instead.
Jun 5 18:06:21 pc kernel: [ 75.730326] rfkill: input handler disabled
Jun 5 18:07:45 pc kernel: [ 159.004723] rfkill: input handler enabled
Jun 5 18:07:57 pc kernel: [ 171.241572] rfkill: input handler disabled
...
答案1
您错误地将硬件 RTC 配置为本地时间。
这从来就不是一个好主意,现在也不是一个好主意。它的这个特殊问题(几个之一)几十年来一直是众所周知的。
发生的事情是这样的。
- 在引导程序中,内核设置系统时钟(总是从硬件时钟以 UTC 运行)。这会将您的系统时钟设置为错误的时间,因为您的硬件 RTC 未设置为应有的 UTC 时间。硬件 RTC 芯片(在常见平台中)没有时区信息。
- 稍后在引导程序中,非内核程序通过查询 C 库的语言环境数据库、使用配置文件中的“全局”时区设置来计算从本地时间到 UTC 的偏移量,并告诉内核该偏移量。
- 内核将偏移量应用于系统时钟和各种假装时间为本地时间的驱动程序(例如 FAT 文件系统驱动程序)。系统时钟现已设置为正确的 UTC 值。系统时钟跳跃 UTC 偏移值。
当配置的“全局”时区落后于 UTC 时(如在美洲),系统时钟会晚于 UTC(硬件时钟错误地如此)开始,并在system-manager
/systemd/whatever 提供时区偏移后向前跳转到 UTC。当时区早于 UTC 时(例如在欧洲/非洲和亚洲的部分地区),系统时钟会向后跳,这是应用程序不希望出现的情况。
BSD 有办法解决这个问题。可以通过文件中的加载程序变量将与 UTC 的时区偏移告知引导加载程序loader.conf
。所以内核已经知道应用于硬件 RTC 值的偏移量,以便在执行硬件 RTC 的初始读取时获取将系统时钟设置为的 UTC 值。
Linux 没有这种机制,而是对第一个settimeofday()
以特定方式调用该函数的程序具有神奇的意义。该程序通常是 systemd、noshsystem-manager
或hwclock
程序的第一次调用。
以 UTC 运行硬件实时时钟,并配置所有操作系统以了解这一点。
进一步阅读
- 乔纳森·德博因·波拉德 (2018)。“系统时钟”。
system-manager
。nosh 工具集手册页。软件。 - 乔纳森·德博因·波拉德 (2009)。DOS Think 的计时方式从根本上被打破了。。常见答案。
- 弗洛里安·韦默 (2019-08-12)。 请勿
struct timezone
与settimeofday
。系统错误#13305。 - 左宗棠 (2008-01-08)。 回复:ext3 的日志方式。 <[电子邮件受保护]>。 fa.linux.kernel
- 左宗棠 (2009-09-10)。回复:buggy_init_scritps 和 e2fsprogs 1.41.9。 linux-ext4。
- https://unix.stackexchange.com/a/294715/5132