Bug 1657158
| Summary: | In ABRT + systemd-coredump environment, "sysctl --system" disables abrt-hook-ccpp | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Kazuo Moriwaka <kmoriwak> |
| Component: | redhat-release | Assignee: | Djordje Todorovic <dtodorov> |
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | low | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.0 | CC: | abrt-devel-list, dtodorov, geovannisantosgmc, jwright, lisas, msobczyk, pkotvan, pzatko, sgoveas, stalexan |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | 8.3 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 01:46:28 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: | |||
| Bug Blocks: | 1812825, 1812830, 1812833, 1842946 | ||
|
Description
Kazuo Moriwaka
2018-12-07 09:51:12 UTC
This is a bit late, but what is the actual issue? Do you *want* to use abrt-hook-ccpp? At first, I just want to use abrt-ccpp. And I was very confused by this conflict. This could be fixed by KCS solution about a workaround. After I understand what was happen, I wanted is to improve the user experience. Configure enable/disable abrt-ccpp by just one abrt-install-ccpp-hook command. My proposed solution is for later one. Thanks, Okay, I just wanted to make sure whether you simply wanted ABRT to work or to use abrt-hook-ccpp specifically, since ABRT can also monitor the system journal and pick up crashes from there. I’m going to do it as you suggested, but the recommendation is to move to the abrt-journal-core service. (And for some reason the link to the knowledge base article doesn’t work) Right, so sysctl configs cannot have arbitrary commands, so this is not going to work at all. Moreover, it would unconditionally set kernel.core_pattern, which is not what you would want if you disable abrt-ccpp.service or enable abrt-journal-core.service. What could be a solution, though, is changing the way abrt-install-ccpp-hook works: instead of poking /proc/sys/kernel/core_pattern directly, we install a sysctl configuration file with contents like such: #kernel.core_pattern=|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I %h %e And the install/uninstall commands would comment and uncomment the line accordingly. No need to stash the previous core_pattern value, either. Reassigning to redhat-release. Can we please have abrt-journal-core.service in the preset instead of abrt-ccpp.service? That was the change implemented in Fedora and it works better with systemd. That would take care of new installations, but we can also add some release notes to document the situation. Should anyone actually want to continue using abrt-hook-ccpp, then we will consider fixing this issue the proposed way. The Jira issue has a label set. Yes, 8.3.0. > Should anyone actually want to continue using abrt-hook-ccpp, then we will
> consider fixing this issue the proposed way.
'abrt-hook-ccpp' is still relevant for oVirt/RHV use case - currently the 'systemd-coredump'
approach works in a way that you end up with 2 copies of the same core dump which is very
problematic for VMs since the core files they generate are very big. It would be very nice
to have this issue resolved and to prioritize a feature that avoids the duplication when
using 'systemd-coredump'.
Hello Ernestas, it seems that swaping abrt-journal-core.service in the preset instead of abrt-ccpp.service would have some possible impact on some teams considering comment 13. From qe point of view I would grant qa_ack for the solutions as it is covered by automated test, but I would like to know whether the change is really intended or if tou consider fixing this issue the proposed way. (In reply to Petr Zatko from comment #14) > Hello Ernestas, it seems that swaping abrt-journal-core.service in the > preset instead of abrt-ccpp.service would have some possible impact on some > teams considering comment 13. > From qe point of view I would grant qa_ack for the solutions as it is > covered by automated test, but I would like to know whether the change is > really intended or if tou consider fixing this issue the proposed way. The above was discussed in private already and the impact is minimal, because the ability to use our custom hook for core dump analysis is still there. The proposed solution is still pending implementation upstream and is going to be more invasive, so there is greater potential for breakage should we decide to backport it, but it’s still an open question. The agreement in the team was that this should be fine for new users if it is documented in the release notes. For most cases, it does not matter, because we have solutions in place to limit the impact of large core dumps being copied. The cases where it does matter are specialized (usually it’s a developer dealing with specific technologies, like WebKit). In fact, my understanding is that switching the preset should have been done prior to RHEL 8.0, as was done in the Fedora version it’s based on. Thank you for the clarification, granting qa_ack and updating our test to reflect that. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (redhat-release bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4495 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days |