Bug#815020: breaks coredump handling for systems without systemd-coredump

[Wouter Verhelst]

Package: systemd
Version: 229-1

Hi,

systemd contains the following line (src/core/main.c):

                        (void) write_string_file("/proc/sys/kernel/core_pattern", "|/bin/false", 0);

The intent is that at some later point, systemd-coredump is started,
which then sets it to something more useful.

However, in Debian, systemd-coredump is in a separate package that
systemd itself does not depend on. As a result, if systemd is used as
PID1, but systemd-coredump is not installed, all core dumps are thrown
into the bit bucket; not just those that are generated during bootup,
but all core dumps after boot, too.

They're still generated, however, since systemd also sets the default
soft resource limit on core file size ("ulimit -c") to the "unlimited"
value, rather than having the hard limit be unlimited and the soft limit
be set at 0.

This is not an ideal situation:
- Generating a core dump, especially in case of a program that uses a
  lot of memory at the time where the dump is generated, requires some
  processing. If the core dump is thrown away, this is wasted processing
  time. If the system is loaded (e.g., because something is forking and
  segfaulting a lot), this is problematic behaviour. By setting the soft
  core file size resource limit to 0, core dumps aren't even generated,
  improving performance.
- The kernel.core_pattern sysctl setting is a system-wide setting; it is
  not possible to modify this other than by using CAP_SYS_ADMIN (IIUC)
  permissions. In contrast, the resource limits are per-process
  configuration; any process can change its resource limits at will.
  This allows the system to have a default of "no core dumps", but at
  the same time, allows a developer or a system administrator to
  temporarily enable core dumps for a particular process, without
  requiring administrator capabilities.

I'm sure systemd-coredump replicates some of the above, but it isn't
always the best choice to have a core dump be piped into a process, and
therefore using the traditional "just dump everything to disk" logic can
still be beneficial.

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser         3.113+nmu3
ii  libacl1         2.2.52-3
ii  libapparmor1    2.10-3
ii  libaudit1       1:2.4.5-1
ii  libblkid1       2.27.1-3
ii  libc6           2.21-8
ii  libcap2         1:2.24-12
ii  libcap2-bin     1:2.24-12
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20     1.6.5-2
ii  libgpg-error0   1.21-2
ii  libkmod2        22-1
ii  liblzma5        5.1.1alpha+20120614-2.1
ii  libmount1       2.27.1-3
ii  libpam0g        1.1.8-3.2
ii  libseccomp2     2.2.3-3
ii  libselinux1     2.4-3
ii  libsystemd0     229-1
ii  mount           2.27.1-3
ii  util-linux      2.27.1-3

Versions of packages systemd recommends:
ii  dbus            1.10.6-1
ii  libpam-systemd  229-1

Versions of packages systemd suggests:
pn  systemd-container  <none>
pn  systemd-ui         <none>

Versions of packages systemd is related to:
ii  udev  229-1

-- no debconf information