systemd-coredump: allow reverting to traditional, local directory coredump behaviour selectively and locally for specific services

Submission type

• Request for enhancement (RFE)

systemd version the issue has been seen with

231

Used distribution

Fedora 25

Request

When systemd-coredump is active, it would sometimes be preferable to
exempt certain user programs from the journal processing. For instance,
consider a developer on a multi-user system whose program frequently
crashes during a debug session. The system administrator would probably
not be interested in these crashes. And most of the resulting core files
can likely be deleted soon after their creation. In that case it is more
appropriate to dump the core file into the user's directory and suppress
the journal entry, such that:

• no system journal flooding occurs;
• core dump size and processing time can be fully accounted to the user;
• no extra step (such as coredumpctl) is needed for dump retrieval;
• core file dumping and processing is more easily scriptable.

This would particularly benefit use cases such as the GDB test suite,
which deliberately generates multiple core files and performs various
tests with GDB on them. Currently the GDB test suite is not prepared to
execute core file tests when systemd-coredump is active. Invoking
coredumpctl there has been discussed and considered troublesome:
https://sourceware.org/ml/gdb-patches/2017-10/msg00537.html

An open question is how to switch this "classical" core dump behavior on
or off. One option may be a user-controllable per-process setting --
something like "ulimit -c unlimited" or an environment variable. Another
might be a system-level configuration option that enables "classical"
handling based on characteristics of the crashed program, e.g. owner,
path, which namespaces it is associated with, etc.

The issue names no files, tests, or entry points. Start by mapping systemd-coredump's current journal and core-file handling, then determine whether selective local behavior should be controlled per process or at the system level. Done means an agreed mechanism is implemented for specific services, with the requested suppression and local core-file behavior verified.