From what I understand, journalctl is supposed to show all the log in /var/log/journal/<machine-uuid>/system*.journal ? But I have a file that is reported corrupted by journalctl --verify with an invalid entry (most likely the last one) caused by a hard-reboot without fsck # journalctl --verify [...] 8a8ef0: invalid entry item (13/22 offset: 000000 8a8ef0: invalid object contents: Bad message File corruption detected at /var/log/journal/<mymachine-uuid>/system@000xxxxxxxxx-xxxxxxxxxxxxxx.journal~:8a8ef0 (of 16777216 bytes, 54%). FAIL: /var/log/journal/<mymachine-uuid>/system@000xxxxxxxxxxxx-xxxxxxxxxx.journal~ (Bad message) [...] and journalctl does not show log past/after that invalid entry i.e. it shows log from the first 2 system@*.journal~ files, but no log from the other files, where the last shown log file is from the one corrupted. I have to access each file individualy with journalctl --file=<name-of-file> using systemd 219 on ubuntu 15.04 beta 2 a similar story on archlinux forum https://bbs.archlinux.org/viewtopic.php?id=188157 p.s: where is the tool to repair corrupted log ?
It's not even the log from the same corrupted file) that are not shown but the logs from the other uncorrupted file
Created attachment 115167 [details] [review] a quick fix that skip on bad message error This is an attempt to fix that error. It does not exit on bad message when parsing entry and continue to process log. However I doubt it is generic enough to deal with all errors It could be desirable to even not return at all if output_journal gives an error but attempt to continue anyway ??
Created attachment 115178 [details] [review] skip bad entries with a new command line switch in journalctl Add a command line switch (--skip-entries) (--skip-bad-entries was too long) to skip bad or currupted entries in the journal. This simply ignore errors returned by output_journal to continue processing the journal. Is it right to do it that way ?
There have been many fixes in this area. We now try to skip invalid entries much better. If this is still an issue, please submit a patch or issue on the new bugtracker on https://github.com/systemd/systemd.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.