Bug 1083849 - systemd-coredump should be turned off by default
systemd-coredump should be turned off by default
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Other
Leap 15.0
Other Other
: P3 - Medium : Enhancement (vote)
: ---
Assigned To: systemd maintainers
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-03 20:04 UTC by Kacper Pluta
Modified: 2018-12-12 12:34 UTC (History)
9 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kacper Pluta 2018-03-03 20:04:33 UTC
On a desktop machine systemd-coredump is rather useless, and it can overloard a CPU after a crash. On my machine I work with a program which runs several processes and when the program crashes (which happens time to time) then I cannot work because just after a crash systemd-coredump is killing the CPU. 

I found a way to turn off systemd-coredump but I think it should be turned off by default. I in my opinion it causes more problems than profits.


This is a proposal for LEAP 15.
Comment 1 Franck Bui 2018-03-14 09:14:28 UTC
If an appli crashes you're supposed to report the problem to the appli developper and coredumps are useful to find out the problem.

Disabling coredumps is not the way to fix bugs and it's helpful in a lot of cases.

If you find it annoying and don't want to help fixing the crashing appli then you can turn it off as you already found but it seems wrong to make it the default.

Ludwig, WDYT ?
Comment 2 Kacper Pluta 2018-03-14 09:48:41 UTC
(In reply to Franck Bui from comment #1)
> If an appli crashes you're supposed to report the problem to the appli
> developper and coredumps are useful to find out the problem.
> 
> Disabling coredumps is not the way to fix bugs and it's helpful in a lot of
> cases.
> 
> If you find it annoying and don't want to help fixing the crashing appli
> then you can turn it off as you already found but it seems wrong to make it
> the default.
> 
> Ludwig, WDYT ?

OK. But at least, please, make it easier to turn systemd-coredump off. Maybe a switch in Yast2 services?
Comment 3 Ludwig Nussel 2018-03-14 09:54:11 UTC
From a user's perspective I have to agree with Kacper. We also completely lack any form of notification that explains the user why the system is blocked and a convenient infrastructure to actually report bugs based on the produced coredumps. All a user sees is what is described in comment#0. Llooking at the long list of tracker crashes I have on my system I'd agree that turning coredumps off by default makes sense. Note that the debuginfo repos that are required for meaningful backtraces are also off by default.

You could also use the %_with_betatest macro in the package to decide whether or not to enable coredumps. The macro is on during beta phase and turned off for the final release.
Comment 4 Ludwig Nussel 2018-03-14 09:54:47 UTC
Also in TW with a more developer orientated audience I'd certainly keep coredumps on.
Comment 5 Franck Bui 2018-03-14 10:21:50 UTC
(In reply to Ludwig Nussel from comment #3)
> Note that the debuginfo repos that are required for meaningful backtraces are also off by default.

The coredumps are usually used by developers not end users. Therefore the coredumps should be sent to people who will enable the debuginfo repos.

Anyways if you feel that coredumps are not useful for Leap, I'm fine to disable it by default, simply confirm this.
Comment 6 Franck Bui 2018-03-14 10:22:40 UTC
Kacper, how did you disable coredumps ? via /etc/systemd/coredump.conf or by other mean ?
Comment 7 Per Jessen 2018-03-14 10:39:51 UTC
(In reply to Ludwig Nussel from comment #3)
> From a user's perspective I have to agree with Kacper. We also completely
> lack any form of notification that explains the user why the system is
> blocked and a convenient infrastructure to actually report bugs based on the
> produced coredumps. All a user sees is what is described in comment#0.
> Llooking at the long list of tracker crashes I have on my system I'd agree
> that turning coredumps off by default makes sense. 

+1.

Before systemd-coredump, "ulimit -c 0" was also the default. ( think it is even ignored now?).
Comment 8 Franck Bui 2018-03-14 13:56:31 UTC
The decision belongs to Ludwig.

If systemd coredump handling should be disabled then the following *distro* policy should be installed

 # cat /usr/lib/sysctl.d/99-leap-default.conf 
 kernel.core_pattern=core

but I don't think such policy belongs to systemd.

Ludwig can you think of a package specific to Leap that could ship the file ? Something like the branding preset package ?
Comment 9 Ludwig Nussel 2018-03-14 14:23:16 UTC
hm, maybe a subpackage of systemd-presets-branding-openSUSE?

Kind of odd that systemd installs a core pattern that we then override again with another file.

Alternatives would be to ship a /usr/lib/systemd/coredump.conf.d/ file to set Storage=none, that way at least core dumps get logged.
Or coredump stuff could be put in a separate subpackage of systemd.
Comment 10 Franck Bui 2018-03-14 14:34:29 UTC
(In reply to Ludwig Nussel from comment #9)
> Alternatives would be to ship a /usr/lib/systemd/coredump.conf.d/ file to
> set Storage=none, that way at least core dumps get logged.

+1

> Or coredump stuff could be put in a separate subpackage of systemd.

+2

How the sub-package "systemd-coredump" would be pulled in for SLE and not for Leap ?

Would that be a dep encoded in systemd.spec ? if so that would put the policy in systemd which is not really nice...
Comment 11 Joachim Wagner 2018-03-14 15:04:54 UTC
Sounds like the default will be no coredump.

If you change your mind note that there may be a way to address the responsiveness issue: Looking at coredump.c in the kernel, there seems to be an interface to accept the coredump via a pipe in userspace, see also http://timetobleed.com/an-obscure-kernel-feature-to-get-more-info-about-dying-processes/ . This could be used to send the coredump through `sluice` before it hits the filesystem.
Comment 12 Joachim Wagner 2018-03-14 15:20:22 UTC
Actually, depending on what process crashes, slowing down coredumps may make the graphical interface even less responsive.
Comment 13 Ludwig Nussel 2018-03-16 08:01:40 UTC
Just to document what I said in IRC. The subpackage is IMO a nice to have feature but not mandatory. Since SLE is already on RC level it may be too late for that though. To pull in the coredump package by default, patterns-base package would have to be modified.
Comment 14 Kacper Pluta 2018-03-17 09:47:46 UTC
(In reply to Franck Bui from comment #6)
> Kacper, how did you disable coredumps ? via /etc/systemd/coredump.conf or by
> other mean ?

Hey I did this:

systemctl mask systemd-coredump.socket

and then I created a file 

/etc/sysctl.d/50-coredump.conf 

with this line

kernel.core_pattern = /tmp/core-%e-%s-%u-%g-%p-%t

I discussed this issue on the IRC and somebody—who nickname I do not remember—came with this solution.
Comment 16 Franck Bui 2018-03-28 16:19:04 UTC
FYI the split has been submitted to Factory. Will see how it goes there first and if every things work as expected I'll do a similar split next week for SLE15/Leap45.
Comment 17 Joachim Wagner 2018-03-29 09:21:14 UTC
If it is too late to change this behaviour in SLE and if it was different in previous versions of SLE it should go into the release notes, important changes and technical documentation.

While coredumps of system processes are usually small, coredumps of application processes can be large and easily exceed disk space or quota. A recent discussion on opensuse-factory mentioned SLE certification for a system running an application that keeps "150-180" TB in RAM.
Comment 20 Franck Bui 2018-04-18 06:42:14 UTC
The split has been done and released through SLE15-RC3 so I think this bug can be closed now.