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.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2211640 - Abrt does not report a segfault which is reported in journalctl.
Summary: Abrt does not report a segfault which is reported in journalctl.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: abrt
Version: 8.8
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: abrt
QA Contact: CS System Management SST QE
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On: 2128662
Blocks: F37FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2023-06-01 10:14 UTC by Martin Kyral
Modified: 2023-06-30 08:19 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 2128662
Environment:
Last Closed: 2023-06-30 08:19:10 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-158787 0 None None None 2023-06-01 10:16:20 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.