Re: Which package is responsible for setting rlimits?

[Ansgar <ansgar@debian.org>]

Hi, Simon,

Simon Richter writes:
> For systemd, resource limits should not be set by pam_limits, because
> pam_limits reads /etc/security/limits.conf, while the systemd ecosystem
> stores resource limits in the unit files.

Please read [1].

  [1]: https://lists.debian.org/debian-devel/2021/02/msg00014.html

> Teaching pam_limits to interrogate systemd would create a functional
> dependency between the PAM and systemd packages where we could only update
> them in lock step, so that would be a maintenance nightmare.

This is wrong.  Just like we don't have to update consumers and
producers of other things like /etc/resolv.conf in lock step.  Or users
and providers of libc.

>> 2. The defaults for resource limits on non-systemd systems are no longer
>>    a good default and should be changed.
>
>>    This is probably true for both for system services and user
>>    processes, so somewhat independent from the behavior of pam_limits.
>
> My expectation for a non-systemd system is that I have to explicitly
> configure anything but "unlimited", and I will do so if necessary.

So sysvinit should set the resource limits as high as possible?  Seems
like a reasonable change to sysvinit (as it doesn't do so currently as
far as I know; the thread came from those limits too low on sysvinit
systems after all).

> tl;dr: pam_limits is for non-systemd setups, and only gets in the way of
> users configuring limits according to systemd.resource-limits(5).It should
> not do anything if pid 1 is systemd so it doesn't interfere, and be split
> off into a separate package along with its configuration file to reduce
> confusion.

This doesn't seem correct.

> The behaviour of copying rlimits from pid 1 in the absence of
> explicit configuration is hacky but good enough for the other init
> systems.

And neither this as then we wouldn't have gotten this thread at all
which is about those defaults being too low for some applications.

Ansgar