Version-Release number of selected component: systemd-216-3.fc21 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: journalctl --verify crash_function: journal_file_object_verify executable: /usr/bin/journalctl kernel: 3.17.0-300.fc21.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (3 frames) #0 journal_file_object_verify at ../src/journal/journal-verify.c:312 #1 journal_file_verify at ../src/journal/journal-verify.c:885 #2 verify.lto_priv.183 at ../src/journal/journalctl.c:1500
Created attachment 946109 [details] File: backtrace
Created attachment 946110 [details] File: cgroup
Created attachment 946111 [details] File: core_backtrace
Created attachment 946112 [details] File: dso_list
Created attachment 946113 [details] File: environ
Created attachment 946114 [details] File: exploitable
Created attachment 946115 [details] File: limits
Created attachment 946116 [details] File: maps
Created attachment 946117 [details] File: open_fds
Created attachment 946118 [details] File: proc_pid_status
Created attachment 946119 [details] File: var_log_messages
This seems nicely repeatable. Any chance you could upload the journal directory somewhere (can be privately)?
I've found problematic journal file. Suprise: cp: error reading ‘/var/log/journal/bd2f536c5eec7709c68df1884a3434ff/system~’: Input/output error Even though there are no I/O errors in dmesg. I have to take this particular to btrfs guys. On the other hand: journal reading should be more robust. One broken file makes system logs inaccessible; also each "systemctl status" ended with SIGBUS.
*** Bug 1151847 has been marked as a duplicate of this bug. ***
*** Bug 1151776 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 1045810 ***