On 12/01/16 17:51, Lennart Poettering wrote: > On Fri, 08.01.16 17:31, Robert O'Callahan (rob...@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/> _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel