Hi I agree on both points. On Wed, Feb 5, 2014 at 10:03 PM, Sébastien Leblanc <leblancsebas@gmail.com> wrote:
Conclusion (as I understand it):
1. There is definitely a bug in Journalctl: it crashes (segfaults) on I/O errors.
A few months ago I had a problem with btrfs. I set +C attribute (disable copy-on-write) on existing journal files. Btrfs recommends to put the attribute on empty files and seems was confused that I applied it to non-empty files. Btrfs started returning IO error when I was trying to read the file with 'less' and journalctl started crashing with segfault. It is very similar to what being discussed here. And I agree that journalctl should play nicer. If anyone still sees this problem please run 'strace journalctl ...'. If it shows that a filesystem operation returns IO error right before SEGFAULT then it proves current thesis.
2. You have a drive that is failing, or your BIOS might not be set correctly. This is causing the I/O errors. How large is the drive? You might have to turn off settings such as "SATA legacy compatibility" or the like -- I had a 3TB drive that would cause ATA command errors on a ~2006 computer; I found this option in the BIOS and as soon as I turned it off everything worked perfectly.
Although journalctl should not crash on I/O errors, I think it is not unreasonable to assume that many other apps do not tolerate I/O errors either. So I would say: you should still report this bug upstream.
-- Sébastien Leblanc