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

[Lennart Poettering]

On Tue, 12.01.16 18:08, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

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

Yes, we have a setting already for this, and I think it would make a
ton of sense to just bump this to a higher default by default at the
same time as we add the prlimit() stuff. After all a higher default
RLIMIT_CORE that is honoured is certainly in all ways more useful than
an RLIMIT_CORE that is always ignored and without effect.

Lennart

-- 
Lennart Poettering, Red Hat