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 ?

(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?

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.

Also in TW with a more developer orientated audience I'd certainly keep coredumps on.

(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.

Kacper, how did you disable coredumps ? via /etc/systemd/coredump.conf or by other mean ?

(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?).

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 ?

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.

(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...

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.

Actually, depending on what process crashes, slowing down coredumps may make the graphical interface even less responsive.

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.

(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.

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.

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.

The split has been done and released through SLE15-RC3 so I think this bug can be closed now.