systemdでboot_idの値をすばやく変更します。

別のコンピュータに保存されているいくつかのログファイルを表示している間、いくつかのログエントリの値が__BOOT_ID異なり、それらの間の時間間隔が非常に狭いことがわかりました。たとえば、ミリ秒で区切られたログエントリは異なる__BOOT_ID値を持ちます。これは短い間隔でシステムを再起動できないため、これは不可能です。

実行すると、journalctl -o verbose --directory <dir path> | grep -B 30 -A 30 -- "-- Reboot --"次の実際の例が参照されていることがわかります。ここでは、10ミリ秒間隔でログイベントに2つの異なる開始ID値があります。

Wed 2019-11-13 21:35:58.469925 ...
    _TRANSPORT=kernel
    PRIORITY=6
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    _BOOT_ID=fec227a60ef24474aacd023d6c02733f
...
...
...
    MESSAGE=spi1.0: ttyMAX1 at I/O 0x20 (irq = 30, base_baud = 3000000) is a MAX3109
-- Reboot --
Wed 2019-11-13 21:35:58.470352 ...
    _SOURCE_MONOTONIC_TIMESTAMP=0
    _TRANSPORT=kernel
    PRIORITY=6
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    MESSAGE=Booting Linux on physical CPU 0x0
    _BOOT_ID=21b95aabab034009a19d1b7deac80327
...
...
...

ブートIDが急速に変化する原因を見つけようとしましたが、成功しませんでした。バージョン（v243）のシステムソースを見ると、sd_id128_get_boot()これは開始IDを読み取るために使用される関数のようです。ファイルからカーネル生成値を読みます。。

        if (sd_id128_is_null(saved_boot_id)) {
                r = id128_read("/proc/sys/kernel/random/boot_id", ID128_UUID, &saved_boot_id);
                if (r < 0)
                        return r;
        }

        *ret = saved_boot_id;
        return 0;

最終結果はログに表示されるリブートのリストですが、最終的にリブートされない可能性があります。興味深いことに、journalctl --list-bootsこれは再起動としてまったく表示されません（現在のget_boots()実装を理解しようとしています）。

以前にこのような振る舞いを見たことがある人がいたら、コメントやコメントをお寄せいただきありがとうございます。これが再起動リストを取得できる場所であることはわかっていますが、jounalctl --list-boots特定の再起動情報セットを含むログを分析したいと思います。これらの誤った肯定は、私が書こうとしたスクリプトの結果を汚染しました。