Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 2211640

Summary: Abrt does not report a segfault which is reported in journalctl.
Product: Red Hat Enterprise Linux 8 Reporter: Martin Kyral <mkyral>
Component: abrtAssignee: abrt <abrt-devel-list>
Status: CLOSED WONTFIX QA Contact: CS System Management SST QE <rhel-cs-system-management-subsystem-qe>
Severity: high Docs Contact:
Priority: unspecified    
Version: 8.8CC: abrt-devel-list, abrt-sig, awilliam, extras-qa, jakub, jmilan, lbrabec, lruzicka, mgrabovs, michal.toman, msrb, ovasik, robatino
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: RejectedBlocker AcceptedFreezeException
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 2128662 Environment:
Last Closed: 2023-06-30 08:19:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2128662    
Bug Blocks: 2009540    

Description Martin Kyral 2023-06-01 10:14:06 UTC
+++ 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.