为什么‘`journalctl -k -b -0’和‘`ps ho lstart 1’之间存在差距？

Question

我遇到一个奇怪的观察：

如果我做了：journalctl -k -b -0 | sed -e 's/^\(.\{76\}\).*/\1.../;3q'

我会看到这样的情况：

-日刊始于2022-08-07 12:06:55 CEST，结束于2023-02-2008.09年01月15日:07:39磁铁内核: Linux版本5.10.0-20-AMD 64(debian-内核@.09年01月15日:07:39磁铁内核:命令行:boot_IMAGE=/boot/vmlinuz-5.10.0

应该与：dmesg | sed -e 's/^\(.\{76\}\).*/\1.../;2q'匹配的

Linux版本5.10.0-20-AMD 64(debian-内核@lists.debian.org)命令行:boot_IMAGE=/boot/vmlinuz-5.10.0-20-AMD 64 root=/.

这很酷，我看到了带有完全时间戳的第一行引导！

但是：如果我按下：ps ho lstart,cmd 1

星期一一月九日15:07:26 2023 /sbin/init

如果我正确地解释了: Process init在内核之前启动了13次？

使用这种命令在许多其他主机上进行了测试：

initSeconds() { 
    sdtext=(before after)
    { read -r kstart
      read -r sstart ;} < <(
        date -f <(LC_ALL=C journalctl -k -b -0 |
            sed -e "2{s/$HOSTNAME.*//;q};d"
            LC_ALL=C ps ho lstart 1) +%s
    )
    sdiff=$((sstart-kstart))
    printf 'Kernel : %(%a %d %b %T)T\nSystemd: %(%a %d %b %T)T (%s" %s)\n' \
        $kstart $sstart ${sdiff#-} ${sdtext[sdiff>0]}
}

然后

sudo bash < <(declare -f initSeconds;echo initSeconds)

Kernel : Mon 09 Jan 11:33:53
Systemd: Mon 09 Jan 11:33:23 (30" before)

ssh pi@raspberrypi sudo bash < <(declare -f initSeconds;echo initSeconds)

我收到了不同的结果：

• 13"，18"，upto 30"：init <#>在 kernel之前，在不同主机上，
• -50"，-3354在不同的.init可以在内核之后一个小时内启动到哪里？

这是个虫子吗？

如果是(我认为是)，这是ps bug还是journactl bug!？

注:我读了ps启动的输出改变，但我不能同意在仅仅41天内看到30秒的间隙！

日志提取(从联想笔记本)：

(根用户下的完整命令：

# paste -d\   <( dmesg |
    sed 's/$/                        /;s/^\(.\{32\}\).*/    \1/'
  ) <(
    LANG=C journalctl -k -b -0|sed 's/\(.\{40\}\).*/\1/'
  )

)

还有一些手册：

13:2命令行: BOO Feb 26 12:09:12 :12:12:12:12:12:12:12:12:12:12:12:12:12:12:12:12主机内核:命令lin BIOS: 12:09:12主机内核: x86/ FPU : x8 BIOS-E 820：[mem 0 2月26 12:09:12 :12主机内核：[mem 0 Feb 26 12:09:12主机内核: BIOS-e820: 58行跳过RAMDISK]内核: SMP M ...802系列跳过EXT4 4-fs (dm-0)：Ma 26 12:09:12主机内核: PM:映像n不激活Ma Feb 26 12:09:12主机内核:EXT4 4-fs (dm systemd: Inser Feb 26 12:09:12主机内核: activating systemd: systemd Feb 26 12:09:12主机系统d: Inserte systemd: Detec Feb 26 12:09:12 :12:12:12主机系统d:systemd ...140线跳过iwlwifi :03:0 Feb 26 12:09: 09:09:09:09:09:012主机内核: iwlwifi 2000 uvcvideo: Found F 26 12:09:12 :12主机内核: uvcvideo: f输入:集成的2月26 12:09:13主机内核:输入: Inte usbcore:寄存器2月26 12:09:13主机内核: usbcore: re . 49行跳过e1000e 0000:00:19 Feb 26 12:09:17主机内核: e1000e 0000

和

initSeconds
Kernel : dim 26 fév 12:09:12
Systemd: dim 26 fév 12:09:07 (5" before)

实际上，systemd是在内核(4.730262)之后5秒内启动的，但这并不能解释负差距。

Answer 1

从根本上说，进程的启动时间作为“系统启动后的几秒钟”存储在内核中。您可以通过检查的格式。/proc/1/stat文件来确认这一点。

运行命令时，ps命令将其转换为人类可读的挂钟时间戳。

另一方面，日志中的时间戳已经从“启动后的秒”格式转换为UTC格式(可能是Unix时间戳或类似的)。

大多数Raspberry Pi模型不包括电池支持的实时时钟(RTC)，因此当内核启动时，系统的实际时间将是不确定的。一个很好的假设是，最有可能避免向后跳时间的假设是，在系统最后一次运行时，取最后一个写入根文件系统的时间戳，并添加1秒，并将其用作系统时间，直到可以到达NTP服务器为止。

如果系统已经关闭了相当长的时间，那么第一次NTP同步将需要一个重要的前向时间跳转--但这比倒转时钟更安全，而且由于系统处于启动的早期阶段，还不应该运行任何需要一致和平稳时间的硬要求。

由于系统通常在根文件系统准备就绪和可写时就开始写入日志，因此日志中的早期引导时间戳将减少一定数量，除非系统具有准确的RTC。当系统时间被调整时，调整事件本身应该记录在日志中，但是journald将而不是返回并调整已经写好的日志条目的时间戳。如果您查看整个日记，您应该会看到时间戳在系统时钟被调整的任何一点上的不连续性。

因此，内核启动时间和第一次NTP同步建立时间之间的日志时间戳只应相互解释，因为它们与真正的壁时钟时间的对应将是不确定的，特别是在没有精确电池支持RTC的系统中。

systemd实际上包括两个适用于此的目标:在具有RTC的系统上，time-set.target标记启动过程中使用RTC时间设置系统时钟的点，因此假定RTC是好的，系统时间至少应该在正确的位置。

第二个目标是time-sync.target，它标记系统时钟与NTP或其他可靠的外部时间源同步的点。在没有功能电池支持的RTC的系统上，如(大多数) RasPis，在达到此目标之前记录的任何早期启动时间戳都应该假定只有在彼此之间才能使用。