Michael Biebl <bi...@debian.org> wrote: > For processes that are spawned by PID 1, the limits are set differently > though, so the unlimited rlimit for PID 1 should have no effect on other > processes. > > Problem is, pam_limits.so in Debian ships a custom patch, which reads > the limits from PID 1 and set those for login sessions.
Yeah, attaching gdb to kdeinit5 shows that rlim_max is 2^30, so not quite INT_MAX, but still very high. > So, ultimately, it's both a bug in pam_limits but also kinit, which > should behave more sensibly if rlimit is set to a high value. Arguably it's a bug in linux in that it's incapable of spawning a new process without inheriting file descriptors from the caller, thus requiring ugly workarounds like this ;) > We can work around that in systemd though, which is what I plan to do > for the time being. > > For a (temporary) workaround you can create a file > /etc/security/limits.d/systemd.conf containing: > > * hard nofile 524288 > > This will make pam_limits behave properly. Thanks!