[systemd-devel] How to suppress coredumps when systemd-coredump is in use?

[Simon McVittie]

On 12/01/16 17:51, Lennart Poettering wrote:
> On Fri, 08.01.16 17:31, Robert O'Callahan (robert at ocallahan.org) wrote:
>> Maybe systemd could query the
>> dumping process's RLIMIT_CORE with prlimit() and throw the coredump away if
>> the limit is 0.
> 
> Yes, we really should check RLIMIT_CORE of the dumped process, and
> honour it. Happy to take a patch for that!

Please see the thread around https://lkml.org/lkml/2011/8/25/124
(explaining the reason why the kernel still dumps cores to pipes when
the limit is 0) before doing so. Neil Horman writes:

    The case (ispipe==true && cprm.lmit==0) has to result in us dumping
    a core. I use to be convinced otherwise, but several user space
    developers changed my mind, particularly the guys writing the abrt
    daemon.  The reason being, the default process limit for
    RLIMIT_CORE is zero.  If you're writing a daemon like abrt that
    wants to catch program crashes, even during boot, there are tons of
    hoops you have to jump through to get core pipes enabled properly
    if you need to change RLIMIT_CORE.  Specifically you have to modify
    all existing processes RLIMIT_CORE values to be non-zero (a racy
    proposition) as well as modify the init processes RLIMIT_CORE value
    (so that it gets inherited by future processes).  Thats a pretty
    rickety thing to set up, and they really didn't want to have that
    much fiddling to do to get it all working, and I don't blame them.

If systemd's pid 1 has a way to set RLIMIT_CORE globally (including for
itself), then perhaps that argument doesn't hold on system systems, but
it's something to think about before making this change.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>