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