Red Hat Bugzilla – Bug 1476518
abrt (or journald/coredumpctl) does not deal well with journal disk corruption
Last modified: 2017-07-29 15:14:10 EDT
Created attachment 1306364 [details]
log extract of abrt looping around
I recently had some laptop trouble which I had to hard-reboot from. This caused some disk corruption. When I got back after a restart, abrt started going crazy (see attachment).
I ended up having to wipe my journal (rm -rf /var/log/journal), restart systemd-journald, and abrt-everything to get things quiet again. Unfortunately, I don't have a copy for post-mortem purposes; I didn't think of that until *after* I was trying to stop it from reporting a few hundred crashes a minute.
My guess is that something did actually crash (which subsequently caused me to have to hard-reboot); this was logged in the journal in a corrupted form, and abrt (or some other piece of the puzzle) didn't manage to cope with that situation. Note that the line:
Jul 29 21:00:28 adele abrt-dump-journal-oops: abrt-dump-journal-oops: Found oopses: 6
... was repeated, always with the same 6 oopses count, further leading me to believe that something got "stuck".
Setting severity to high, because although I doubt this sort of situation occurs often, it's very difficult to recover from when it does happen.
Note that I do still a bunch (422 to be exact) of repeated crash reports in the UI. If those would be of use somehow, I can provide them.