☰

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 0바이트) 블록 정도가 생길 수 있습니다. 이는 일반적으로 grep파일을 바이너리 파일로 처리합니다.

충돌 후 파일 시스템 로그가 복원되면 파일 시스템이 로그 파일에 대한 블록을 할당했지만 거기에 기록되어야 했던 실제 데이터가 손실되었을 수 있습니다(예: ext4파일 시스템이 일부 journal_data_writeback모드에 있음). 파일 시스템은 누락된 데이터의 실제 길이(전체 블록 또는 그 이하)를 모르며 파일에 있는 특정 데이터의 정확한 위치가 중요한지 여부도 모르기 때문에 해당 블록을 0바이트의 데이터로 채우게 됩니다. 데이터가 누락되었습니다.

또 다른 가능한 원인은 UTF8이 아닌 로케일을 사용하고 일부 로그 메시지에 사용 중인 문자 집합에 속하지 않는 문자가 포함되어 있는 경우입니다. 이는 grep파일을 이진 파일로 처리하여 발생할 수도 있습니다.

관련 정보