Bug#815020: breaks coredump handling for systems without systemd-coredump

[Michael Biebl]

Am 19.02.2016 um 05:32 schrieb Josh Triplett:
> severity 815020 grave
> thanks
> 
> On Wed, 17 Feb 2016 21:25:43 -0300 Felipe Sateler <fsateler at debian.org> wrote:
>> On 17 February 2016 at 21:03, Wouter Verhelst <wouter at debian.org> wrote:
>>> An alternative solution would be that systemd-sysv shipped with a unit
>>> which would set the core_pattern back to default, which could be
>>> overridden or disabled by a unit shipped by a unit shipped with
>>> systemd-coredump? That would be less surprising -- I have to say I spent
>>> a long time tracking down what happened.
>>
>> I think the bigger problem is setting the default core rlimit, not the
>> core_pattern. The /bin/false core_pattern is being set because the
>> default rlimit was raised, otherwise you would get core files
>> everywhere on your system. In turn, the rlimit was raised because now
>> systemd-coredump respects the limit (previously it would ignore it and
>> save larger than allowed dumps).
> 
> No, the core_pattern is a problem as well.  Default out-of-the-box
> behavior with current systemd:
> 
> /tmp$ ulimit -c
> unlimited
> /tmp$ cat >crash.c <<EOF
>> int main(void) { return *(int *)0; }
>> EOF
> /tmp$ gcc crash.c -o crash
> /tmp$ ./crash
> Segmentation fault (core dumped)
> (139) /tmp$ ls -l core
> ls: cannot access 'core': No such file or directory
> 
> This does not work as a default configuration.  The default core_pattern
> must remain the kernel default "core".  It seems perfectly reasonable
> for systemd-coredump to override that if installed, but in the absence
> of that, setting "ulimit -c unlimited" must generate core files.  The
> sysadmin should *not* have to manually fix core_pattern to retain the
> expected behavior.
> 
> Given that the default core_pattern must remain the kernel default
> "core", then the default "ulimit -c" must remain 0.
> 
> I don't see anything wrong with systemd-coredump installing a
> systemd.conf.d file that sets DefaultLimitCORE; the sysadmin can still
> easily override that with their own systemd.conf.d file.  The package
> description should explicitly mention the behavior change caused by
> installation.  The package should also explicitly note that installing
> systemd-coredump will not enable coredumps for existing processes, and
> that the sysadmin may wish to either restart existing processes or
> manually enable coredumps for them using "prlimit -c unlimited --pid
> PID".

It would be better if you raise those concerns upstream.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20160219/c32bbee1/attachment-0002.sig>