journalctl - zweryfikuj raporty o uszkodzeniach

22

Właśnie zauważyłem tę verifyopcję journalctli postanowiłem ją wypróbować, bo pokazuje korupcję, co może być przyczyną? a co jeśli powinienem z tym zrobić? czy powinienem to zbadać?

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
systemd systemd-journald ksenoterracid
źródło

Odpowiedzi:

14

Obecnie Journalctl może wykrywać uszkodzone dzienniki, ale nie ma polecenia typu „fsck”, aby podjąć próbę naprawy. Journald automatycznie przełączy się na pisanie nowego „czystego” pliku, gdy tylko wykryje problem, więc teoretycznie utrata danych powinna być minimalna.

Dopóki nie pojawi się polecenie naprawy pliku, znalezienie uszkodzonego pliku dziennika i usunięcie go jest jedynym lekarstwem. Możesz dowiedzieć się więcej na ten temat w naszym megawątku Fedory, nad tym, czy domyślnym logowaniem do dziennika jest tylko:

W przypadku zepsucia ogona normalne narzędzie Journalctl dostarczy Ci jak najwięcej informacji do odzyskania z pliku. Wyświetli ostatnią pełną linię dziennika, a następnie zakończy. Jest to bardzo zbliżone do tego, jak dobrze możesz uzyskać.

Inaczej wygląda sytuacja w przypadku zepsucia w środku. Nie mamy przyjemnego narzędzia do ratowania danych przed taką korupcją, ale można je stosunkowo łatwo zapisać. Ponieważ jednak są one mało prawdopodobne ze względu na model czasopisma „tylko do dołączania”, nie było go na naszej liście TODO.

Oczywiście, jeśli potrafisz zidentyfikować przyczynę problemu i zgłosić go, byłoby miło.

mattdm
źródło
co to jest FAA?
ksenoterrakid
@ xenoterracide to dziwna literówka telefoniczna. :)
mattdm,
1
@slm Tak, z biura jest długa jazda autobusem. :) Przepraszam za marnowanie czasu - mam nadzieję, że przynajmniej nauczyłeś się czegoś o lotnictwie.
mattdm,
1
w moim systemie przynajmniej skorumpowane czasopisma wydają się być powszechne ... czy jest jakaś rada, jak rozpoznać przyczynę problemu?
ksenoterrakid
2
W każdym systemie, jaki widziałem, uszkodzone dzienniki dziennika są powszechne. Ta odpowiedź ma już prawie 5 lat i, o ile mogę stwierdzić, nie ma rozwiązania tego problemu.
MountainX dla Moniki Cellio
2

Wygląda na to, że jest powiązany z tym wątkiem na wiki ArchLinux, zatytułowanym: journalctl problems . Wydaje się, że ma coś wspólnego z tym ustawieniem SystemMaxUsew /etc/systemd/journald.conf.

Wątek nie jest rozstrzygający, ale kilka osób miało szczęście albo wyczyściło dzienniki poniżej, /var/log/journal/*albo zwiększyło wartość SystemMaxUse.

slm
źródło
niestety gra z tą wartością nie pomogła. Podejrzewam, że czyszczenie dzienników pomaga, ponieważ usuwa nieprawidłowe dzienniki.
ksenoterracid
@xenoterracide - będę szukał dalej. Tak, czyszczenie dzienników również wydawało mi się nonsensowne, ale ludzie to zgłaszali, więc pomyślałem, że warto spróbować.
slm