journalctl-보고서 손상 확인

방금이 verify옵션을 발견 journalctl하고 그것을 포기하기로 결정했습니다. 부패를 보이고 있습니다. 그 원인은 무엇입니까? 그리고 내가 그것에 대해 무엇을해야합니까? 더 조사해야합니까?

journalctl --verify
PASS: /var/log/journal/19184893a1d645c7a43729e79b10a876/user-1000.journal
Invalid object contents at 3733856░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   0%
File corruption detected at /var/log/journal/19184893a1d645c7a43729e79b10a876/system.journal:3733856 (of 91734016, 4%).
FAIL: /var/log/journal/19184893a1d645c7a43729e79b10a876/system.journal (Bad message)
Invalid object contents at 21575496░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  45%
File corruption detected at /var/log/journal/19184893a1d645c7a43729e79b10a876/system@60e058db556e4de4b256d0b1ff176aa4-0000000000000001-0004e0b436d20aa1.journal:21575496 (of 44052480, 48%).
FAIL: /var/log/journal/19184893a1d645c7a43729e79b10a876/system@60e058db556e4de4b256d0b1ff176aa4-0000000000000001-0004e0b436d20aa1.journal (Bad message)
PASS: /var/log/journal/19184893a1d645c7a43729e79b10a876/user-1000@60e058db556e4de4b256d0b1ff176aa4-0000000000000a91-0004e0b4ff9a949a.journal
PASS: /var/log/journal/19184893a1d645c7a43729e79b10a876/user-1001.journal

현재 journalctl은 손상된 로그를 감지 할 수 있지만 복구를 시도하는 "fsck"유형 명령이 없습니다. 저널은 문제를 발견하자마자 새로운 "깨끗한"파일을 작성하도록 자동 전환하므로 이론적으로 데이터 손실이 최소화되어야합니다.

파일 복구 명령이있을 때까지 손상된 저널 파일을 찾아서 제거하는 것이 유일한 치료법입니다. 저널 전용 로깅을 기본값으로 설정하는 것 보다 Fedora 메가 스레드에서 이에 대한 자세한 내용을 확인할 수 있습니다 .

꼬리 손상의 경우 일반적인 저널 도구는 파일에서 구할 수있는 한 많은 정보를 제공합니다. 마지막 완전한 로그 라인을 출력 한 다음 완료됩니다. 이것은 당신이 얻을 수있는 정도에 가깝습니다.

중간의 부패에 대해서는 상황이 다릅니다. 우리는 그러한 부패로부터 데이터를 구할 수있는 훌륭한 도구는 없지만 비교적 쉽게 쓸 수 있습니다. 그러나 저널의 "첨부 전용"모델로 인한 가능성이 높지 않으므로 TODO 목록에 포함되지 않았습니다.

물론 처음에 문제를 일으킨 원인을 식별하고보고 할 수 있다면 좋을 것입니다.

이 글은 ArchLinux 위키에서이 글과 관련된 것 같습니다 : journalctl issues . 이 설정을 함께 할 수있는 뭔가가있는 것 SystemMaxUse에를 /etc/systemd/journald.conf.

스레드는 결정적이지는 않지만 여러 사람들이 로그를 지우 /var/log/journal/*거나에 대한 값을 높이는 데 운이 좋았습니다 SystemMaxUse.