私は奇妙な観察を発見しました。
私がするなら：journalctl -k -b -0 | sed -e 's/^\(.\{76\}\).*/\1.../;3q'
次の内容が表示されます。
-- Journal begins at Sun 2022-08-07 12:06:55 CEST, ends at Mon 2023-02-20 08... Jan 09 15:07:39 magnet kernel: Linux version 5.10.0-20-amd64 (debian-kernel@... Jan 09 15:07:39 magnet kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0...
以下と一致する必要があります。dmesg | sed -e 's/^\(.\{76\}\).*/\1.../;2q'
[ 0.000000] Linux version 5.10.0-20-amd64 ([email protected]... [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-20-amd64 root=/...
本当に素敵ですね。フルタイムスタンプを含むリリースの最初の行が表示されます！
しかし：私が打った場合：ps ho lstart,cmd 1
Mon Jan 9 15:07:26 2023 /sbin/init
私が正しく説明した場合：プロセスinit13秒開始今後コア！ ？
次のコマンドを使用して他の多くのホストでテストされました。
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"次のとおり30"：init今後kernel、他のホストから-50"、-3354他のRaspberry Piで...どこinitおそらく一時間後に始まると思います。コア？
これはバグですか？
それなら（私の考えには）これはpsバグなのでjournactlはないか！ ？
注: 読みました。ps lstartの出力が変更されました。しかし、わずか41日で30秒の差があるという点には同意できません！
ログの抜粋（Lenovoノートブックから）：
（下記の全命令根ユーザー：
# paste -d\ <( dmesg |
sed 's/$/ /;s/^\(.\{32\}\).*/ \1/'
) <(
LANG=C journalctl -k -b -0|sed 's/\(.\{40\}\).*/\1/'
)
)
いくつかの手動バージョンもあります：
|-- dmesg output --| |-- journalctl output --| -------------------------------- ---------------------------------------- [ 0.000000] Linux version 5.1 -- Journal begins at Sun 2021-10-03 13:2 [ 0.000000] Command line: BOO Feb 26 12:09:12 host kernel: Linux versi [ 0.000000] x86/fpu: x87 FPU Feb 26 12:09:12 host kernel: Command lin [ 0.000000] BIOS-provided phy Feb 26 12:09:12 host kernel: x86/fpu: x8 [ 0.000000] BIOS-e820: [mem 0 Feb 26 12:09:12 host kernel: BIOS-provid [ 0.000000] BIOS-e820: [mem 0 Feb 26 12:09:12 host kernel: BIOS-e820: ... 58 lines skipped [ 0.018652] RAMDISK: [mem 0x3 Feb 26 12:09:12 host kernel: found SMP M ...802 lines skipped ...102 lines skipped [ 4.557467] EXT4-fs (dm-0): m Feb 26 12:09:12 host kernel: PM: Image n [ 4.623199] Not activating Ma Feb 26 12:09:12 host kernel: EXT4-fs (dm [ 4.730262] systemd[1]: Inser Feb 26 12:09:12 host kernel: Not activat [ 4.751319] systemd[1]: syste Feb 26 12:09:12 host systemd[1]: Inserte [ 4.767877] systemd[1]: Detec Feb 26 12:09:12 host systemd[1]: systemd ...140 lines skipped [ 5.882062] iwlwifi 0000:03:0 Feb 26 12:09:12 host kernel: iwlwifi 000 [ 5.895585] uvcvideo: Found U Feb 26 12:09:12 host kernel: uvcvideo: F [ 5.898230] input: Integrated Feb 26 12:09:13 host kernel: input: Inte [ 5.898319] usbcore: register Feb 26 12:09:13 host kernel: usbcore: re ... 49 lines skipped [ 10.702190] e1000e 0000:00:19 Feb 26 12:09:17 host kernel: e1000e 0000
そして
initSeconds
Kernel : dim 26 fév 12:09:12
Systemd: dim 26 fév 12:09:07 (5" before)
実際、systemdは5秒間始まりました。後ろにカーネル（4.730262）ですが、これは否定的なギャップを説明しません。
答え1
プロセスの開始時間は、デフォルトでは「システム起動後の秒」形式でカーネルに保存されます。確認すると確認できます/proc/1/statファイル形式。
このpsコマンドは、これを人間が読める壁時計タイムスタンプに変換します。コマンド実行時。
一方、ログのタイムスタンプは、「起動後の秒数」形式からそれに対応するUTC形式（おそらくUnixタイムスタンプなど）に変換されました。ログエントリを作成するとき。
ほとんどのRaspberry Piモデルにはバッテリ駆動のリアルタイムクロック（RTC）が含まれていないため、カーネルが起動しても実際のシステム時間は決まりません。時間を元に戻す必要がない合理的な仮定は、システムが最後に実行されたときに最後のタイムスタンプをルートファイルシステムに記録し、1秒を追加してからNTPサーバーが到達できるまでシステム時間として使用することです。 。 。
システムが長時間ダウンしている場合、最初のNTP同期にはかなりの順方向時間ジャンプが必要です。しかし、これは時計を後ろに回すよりも安全であり、とにかくシステムが初期ブート段階にあるので、ハードになることはありません。一貫したシームレスなタイミングの要件は依然として適用されるべきです。
システムは通常、ルートファイルシステムが準備されて書き込み可能になるとすぐにログに書き込みを開始するため、システムに正しいRTCがないと、ログの初期起動タイムスタンプが多少歪んでしまいます。システム時間が調整されたら、調整イベント自体をログに記録する必要がありますがjournald、いいえ作成されたログエントリのタイムスタンプを返して調整します。ログ全体を見ると、システムクロックが調整されているすべての時点でタイムスタンプの不連続性を確認できます。
したがって、カーネルの起動時間と最初のNTP同期設定時間の間に記録されたタイムスタンプのみを解釈できます。互いに相対的な、実際の壁時計時間との対応が不確実なため、特にRTCの正確なバッテリーサポートを持たないシステムで。
systemd実際にここに適用される2つの目標があります。 RTCがあるシステムでは、time-set.target起動プロセス中にシステムクロックがRTC時間に設定されているポイントが表示されます。その後、システム時間は少なくとも正しい範囲になければなりません。 RTCは良いです。
2番目の目標は、time-sync.targetシステムクロックがNTPまたは他の信頼できる外部タイムソースと同期しているポイントを表示することです。 （ほとんどの）RasPisなどの機能的なバッテリサポートRTCを持たないシステムでは、この目標に達する前に記録された初期ブートタイムスタンプは互いに関連してのみ利用可能であると仮定する必要があります。