☰

boot.logファイルのどの部分がバイナリですか？

tag-icon • tag-icon linux grep logs cat binary
boot.logファイルのどの部分がバイナリですか？

私のシステムは、カーネルの更新後に常にランダムに起動に失敗するようです。したがって、問題の原因を特定するためにログを読んでいます。これは起動ログの1つです。

$ sudo cat /var/log/boot.log.1
------------ Sat Aug 26 12:45:00 GMT 2023 ------------
/dev/mapper/linux--vg-root: clean, 1261921/90649104 files, 50539269/60917669 blocks
[  OK  ] Finished plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data.
[  OK  ] Finished systemd-binfmt.service - Set Up Additional Binary Formats.
         Starting binfmt-support.service - Enable support for additional executable binary formats...
[  OK  ] Finished systemd-tmpfiles-setup.service - Create Volatile Files and Directories.
[  OK  ] Started resolvconf.service - Nameserver information manager.
[  OK  ] Reached target network-pre.target - Preparation for Network.
         Starting systemd-update-utmp.service - Record System Boot/Shutdown in UTMP...
[  OK  ] Finished systemd-update-utmp.service - Record System Boot/Shutdown in UTMP.
[  OK  ] Finished binfmt-support.service - Enable support for additional executable binary formats.
[  OK  ] Finished apparmor.service - Load AppArmor profiles.
[  OK  ] Started haveged.service - Entropy Daemon based on the HAVEGE algorithm.
         Starting networking.service - Raise network interfaces...
         Starting snapd.apparmor.service - Load AppArmor profiles managed internally by snapd...
(Redacted)
[  OK  ] Started snapd.service - Snap Daemon.
         Starting snapd.seeded.service - Wait until snapd is fully seeded...

ただし、失敗した行をフィルタリングしようとすると、grep表示は拒否されます。

$ sudo cat /var/log/boot.log.1 | grep "FAILED"
grep: (standard input): binary file matches

有効にした場合にのみ-a出力を表示できます。

$ sudo cat /var/log/boot.log.1 | grep -a "FAILED"
[FAILED] Failed to start apache2.service - The Apache HTTP Server.

cat出力にバイナリは表示されません。どこ？しかし、これがapacheブート失敗の原因になる可能性がありますか？

ベストアンサー1

ログファイルへの書き込み中にシステムがクラッシュする場合、一部の種類のファイルシステムでは、ファイルの末尾にNULL（つまりASCII 0バイト）ブロックの程度が発生する可能性があります。これは通常、grepファイルをバイナリファイルとして扱います。

クラッシュ後にファイルシステムログが復元されると、ファイルシステムはログファイルにブロックを割り当てましたが、そこに書き込む必要があった実際のデータが失われる可能性があります（ext4ファイルシステムが一部のjournal_data_writebackモードにあるなど）。ファイルシステムは、欠落しているデータの実際の長さ（全ブロック以下）を知らず、ファイル内の特定のデータの正確な位置が重要であるかどうかを知らないため、ブロックはゼロバイトのデータで埋められます。データがありません。

別の考えられる原因は、UTF8以外のロケールを使用し、一部のログメッセージに使用されている文字セットに属していない文字が含まれている場合です。これはgrep、ファイルをバイナリファイルとして扱うことによっても発生する可能性があります。

おすすめ記事