+++ This bug was initially created as a clone of Bug #2128662 +++ Description of problem: Abrt does not show any notification, nor does it show and report a simulated segfault on Fedora 37 pre-Final (20220920). The segmentation fault is correctly displayed in journalctl, which means that the system knows about it. Version-Release number of selected component (if applicable): abrt-2.15.1-4 kernel 5.19.9-300 How reproducible: Always Steps to Reproduce: 1. Install the `will-crash` package that simulates various crashes. 2. Run `will_segfault` to simulate a segfault. 3. Wait for notifications -> none will come in 120 seconds 4. Open Abrt -> the segfault will not be displayed there. Actual results: Abrt might not be able to catch system issues which means that it cannot report them either. Expected results: Abrt should catch the issue, notify about it, show it in the application and allow to report it (or trace locally). Additional info: Journalctl has the info about the segfault: --- Sep 21 12:41:09 platypus systemd-coredump[46119]: Process 46117 (will_segfault) of user 1000 dumped core. Module linux-vdso.so.1 with build-id 6daaf8b06a8e9606d0faa8151c085374ea451a22 Module ld-linux-x86-64.so.2 with build-id 653dfb54d6e6d9c27c349f698a8af1ab86d5501d Module libc.so.6 with build-id a6572cd46182057d3dbacf1685a12edab0e2eda1 Module libwillcrash.so with build-id d17a8ed3a0098089a90ecaa1fd2c2dd21a85341f Metadata for module libwillcrash.so owned by FDO found: { "type" : "rpm", "name" : "will-crash", "version" : "0.13.5-2.fc37", "architecture" : "x86_64", "osCpe" : "cpe:/o:fedoraproject:fedora:37" } Module will_segfault with build-id fc7b52fa0e3611a64622a30d94b5bdd4a86e4d9b Metadata for module will_segfault owned by FDO found: { "type" : "rpm", "name" : "will-crash", "version" : "0.13.5-2.fc37", "architecture" : "x86_64", "osCpe" : "cpe:/o:fedoraproject:fedora:37" } Stack trace of thread 46117: #0 0x000055abb5664262 crash.constprop.0 (will_segfault + 0x1262) #1 0x000055abb5664335 varargs (will_segfault + 0x1335) #2 0x000055abb566436e f (will_segfault + 0x136e) #3 0x000055abb566439d callback (will_segfault + 0x139d) #4 0x00007ff0dca8113d call_me_back (libwillcrash.so + 0x113d) #5 0x000055abb5664232 recursive.constprop.0 (will_segfault + 0x1232) #6 0x000055abb56640f6 main (will_segfault + 0x10f6) #7 0x00007ff0dc8b7510 __libc_start_call_main (libc.so.6 + 0x23510) #8 0x00007ff0dc8b75c9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x235c9) #9 0x000055abb5664155 _start (will_segfault + 0x1155) ELF object binary architecture: AMD x86-64 Sep 21 12:41:09 platypus systemd[1]: systemd-coredump: Deactivated successfully. --- --- Additional comment from Michal Srb on 2022-10-19 05:47:33 UTC --- Thanks ;) Indeed, I also see the problem on freshly installed f37 RC. It seems like the problem goes away when: * systemd-coredump reports a crash in journal * abrt-journal-core.service or the whole system is restarted I.e. abrt-journal-core.service somehow doesn't see the first crash (or crashes before first restart after them). I see the same error in journal: Oct 18 11:13:22 fedora abrt-dump-journal-core[792]: Cannot save journal watch's position I am wondering if abrt-journal-core.service is somehow incorrectly initializing the journal cursor, if there are no prior (valid) crashes in journal. I think I have an idea when the problem might be. Another fix incoming today.