On Tue, Apr 12, 2016 at 03:49:09PM -0500, Michael Catanzaro wrote:
Currently we have coredumpctl installed by default, but it doesn't work
because core dumps are consumed by ABRT instead. I'd like to get
coredumpctl working out-of-the-box. We can do this by changing our
systemd presets  to disable abrt-ccpp.service.
ABRT will continue to function thanks to the ABRT developers' work on
coredumpctl integration via abrt-vmcore.service. There is a somewhat-
reduced feature set, but I've been running this for several months
happily and I haven't noticed any issues; my crashes are being reported
to FAF, and I can manually report to Bugzilla. See  for details.
integrating abrt to use coredump as a "backend".
This might be slightly controversial for two reasons. First, the big
change here is that core dumps will appear in the magical and super-
awesome coredumpctl tool in addition to ABRT, but would no longer be
created in the cwd when ulimit is set appropriately (we would need to
feature that in the release notes).
I don't think that's a problem in
practice. For most people coredumps
are annoying, and use up disk space unless you remember to clean them
up. And coredumps stored by systemd-coredump are still easily accessible
(although they might be compressed, but this can be easily turned off
Having the coredumps go through systemd-coredump gives us a robust
and convenient way to gather coredumps, also during boot.
This aligns us with upstream
systemd behavior, but diverges from Debian and Ubuntu, which still
create the old-style coredumps in the cwd. Second, my understanding is
that the ABRT developers prefer to improve abrt-cli and tell people to
use that rather than coredumpctl. But as coredumpctl is very mature
(nicer) and cross-distro so it gets many more contributors, I
definitely prefer to instruct people to use coredumpctl instead for
We could totally do this change for F24 as well as it should be just a
one-line change, but in the spirit of beta freeze I figure it's
probably best left for F25.