☰

boot.log 文件的哪一部分是二进制的？

tag-icon • tag-icon linux grep logs cat binary
boot.log 文件的哪一部分是二进制的？

我的系统在内核更新后似乎总是随机无法启动。因此，我正在阅读日志以尝试确定问题的原因。这是启动日志之一：

$ 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

如果您的系统在写入日志文件时崩溃，对于某些文件系统类型，您可能会在文件末尾处出现一块左右的 NUL（即 ASCII 零字节）。这通常会将grep文件视为二进制文件。

当崩溃后恢复文件系统日志时，文件系统可能已经为日志文件分配了块，但丢失了应该写入那里的实际数据（例如，ext4文件系统处于某种journal_data_writeback模式）。由于文件系统不知道丢失数据的实际长度（完整块或更少？），也不知道文件中特定数据的确切位置是否重要，因此它最终会用零字节的丢失数据填充这些块。

另一个可能的原因是，如果您使用非 UTF8 语言环境，并且某些日志消息包含不属于您正在使用的字符集的字符：这也可能是由于grep将文件视为二进制文件而导致的。

相关内容