On Tue, 12.01.16 18:08, Simon McVittie ([email protected]) wrote:
> On 12/01/16 17:51, Lennart Poettering wrote: > > On Fri, 08.01.16 17:31, Robert O'Callahan ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
