Enable systemd-coredump by default
Summary
Enable systemd-coredump by default. Core dumps will be accessible via the coredumpctl tool.
Owner
- Name: Michael Catanzaro
- Email: <mcatanzaro@gnome.org>
- Release notes owner:
Current status
Detailed Description
systemd-coredump will be enabled by default. Core dumps will be processed by systemd-coredump and metadata about core dumps will be stored in the system journal. Currently abrt-ccpp.service installs its own core pattern to /proc/sys/kernel/core_pattern that overrides the core pattern set by systemd. We will simply disable abrt-ccpp.service in the Fedora systemd presets to avoid this. This change only affects default behavior. After this change, it will still be possible and easy to revert to traditional Linux behavior by overriding RLIMIT_CORE and the sysctl variable kernel.core_pattern.
Note that coredumpctl is intended as a developer tool, not as an automatic bug reporting tool nor as a replacement for ABRT. ABRT will continue to automatically report C and C++ crashes to the Fedora Analysis Framework (FAF), and users will still be able to manually report crashes to Red Hat Bugzilla using ABRT's Problem Reporting application. Nor does coredumpctl replace ABRT's ability to catch non-C/C++ issues like Java exceptions, Python exceptions, or machine check events. ABRT remains an important component of Fedora, and will continue to function largely as before as it has support for retrieving core files from systemd-coredump using abrt-journal-core.service.
Benefit to Fedora
Software developers who have used coredumpctl on other Linux distributions are often frustrated when it is not available or enabled. Working with core dumps manually can be annoying and is often considered primitive by developers who are familiar with coredumpctl. Enabling coredumpctl by default means we will have a better out-of-the-box developer experience than distributions that have not yet enabled this functionality. Developers who prefer to manually work with core dumps will still be able to revert to the previous behavior.
Scope
- Proposal owners: We will disable abrt-ccpp.service in our systemd presets and enable abrt-journal-core.service. That's it.
- Other developers: We request some assistance from SELinux developers to address an incompatibility between SELinux and coredumpctl that was introduced in Fedora 24, RHBZ #1341829, and an incompatibility between SELinux and abrt-journal-core, RHBZ #1419980.
- Release engineering: No changes needed
- List of deliverables: No changes needed
- Policies and guidelines: No changes needed
- Trademark approval: Not needed for this change
Upgrade/compatibility impact
Because this is a change of systemd preset, most users will automatically receive the new behavior. Users who wish to revert to previous Fedora behavior will need to manually enable and start abrt-ccpp.service and disable abrt-journal-core.service. Users who have previously disabled abrt-ccpp.service will see no changes.
How To Test
Send SIGSEGV to a process, then verify that you get a backtrace by running 'coredumpctl gdb'. Also verify that reporting crashes in Fedora applications with ABRT still works as expected: crashes should still be automatically reported to the retrace server, and it should still be possible to manually report to Red Hat Bugzilla using the installed ABRT GUI.
User Experience
Users who dislike coredumpctl may be disappointed that Fedora does not conform to traditional Linux core handling (by default); however, this has already not worked (by default) since Fedora 24. In Fedora 23 and earlier releases, ABRT created core dumps in the crashing process's current working directory if the appropriate ulimit is set to allow it, mimicking traditional Linux core handling behavior. However, this no longer occurs in Fedora 24 or Fedora 25 because systemd now sets the ulimit to unlimited by default, meaning ABRT no longer has any way to determine if the user wants core files generated in the current working directory (RHBZ #1309172).
Currently, obtaining a core dump from a crashing program requires manually changing the ulimit, executing the program until it crashes, and then opening the core dump in gdb. It is inconvenient to obtain a core dump if the program is an unpackaged system service/daemon. It is also very inconvenient if the crash is sporadic and not easy to reproduce. ABRT already handles these cases well as a bug reporting tool for system packages, and it is already able to handle crashes of unpackaged applications with some configuration changes, but it is not as convenient to use for development purposes as coredumpctl. For instance, simply running 'coredumpctl gdb' will automatically launch gdb and generate a stacktrace for the most recent crash that occured on the system.
coredumpctl is supported by the large systemd developer community and is quite mature. It rate-limits core dump generation and automatically removes old core dumps to save disk space. It stores short truncated stacktraces in the journal indefinitely, even after the associated core dump has been removed.
Dependencies
Packages that depend on systemd should not be directly affected by this change.
Unfortunately Fedora 24 introduced an incompatibility between SELinux and coredumpctl that remains unfixed: RHBZ #1341829. We will not be able to ship this feature until this SELinux bug is fixed as it would result in us losing all automatic bug reports in the meantime. We request assistance from the SELinux developers to address this bug.
Contingency Plan
- Contingency mechanism: The contingency mechanism is to simply revert the systemd preset so that abrt-ccpp.service is once again enabled by default, and abrt-journal-core.service is no longer enabled by default.
- Contingency deadline: Beta freeze
- Blocks release? No
- Blocks product? No
Documentation
coredumpctl is well-documented in manpages. Refer to coredumpctl(1), systemd-coredump(8), or coredump.conf(5).
Release Notes
By default, core dumps from crashing programs are now stored by systemd-coredump, rather than created in the crashing process's current working directory by ABRT. They may be extracted using the coredumpctl tool. For example, simply run 'coredumpctl gdb' to view a backtrace for the most recent crash in gdb. For more information on this change, refer to the manpages coredumpctl(1), systemd-coredump(8), and coredump.conf(5).