Hi I agree on both points. On Wed, Feb 5, 2014 at 10:03 PM, Sébastien Leblanc <leblancsebas@xxxxxxxxx> 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
