[gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with

[Piotr Karbowski]

Hi,

I'd like to touch base on the topic of pam_limits and the defaults that 
we ended up with in Gentoo.

Currently on default system installation without any modification to 
/etc/security/limits.{conf,d/*} user will end up with limit o 1024 of 
file descriptors and 4096 limit of threads.

Most of limits.conf makes a lot of sense on systems that are meant to be 
used remotely by many people simultaneously and have much less of 
importance on single user desktop systems.

Recently I've been haunted by random and and not reproducible failures 
of random applications during runs with ffmpeg's libsvtav1 integration. 
Having a 4 instances of ffmpeg with was enough to get me random 
failures, terminals not to open, up until I actually seen in shell 
'cannot allocate resource' while trying to run a script.

Turns out, I was running over the limit of 4096 threads, as nproc 
somewhat suggests this is limit of processes, it is actually a limit of 
PIDs, and every thread gets its own pid.

I have strong opinion on this one, that users that runs multi users 
systems will be well aware of the need to tune limits.conf of 
pam_limits, while the users that will actually suffer are the regular 
Joe that just uses Gentoo as a single user system.

What I'd like to do is to bump the limits.conf we ship with pam to following

     * hard nproc 16384
     * soft nproc 16384
     * hard nofile 16384
     * soft nofile 16384

Those are still reasonable defaults that are much more suitable the 
modern systems. I can only see benefits in it and am unable to think 
about the potential drawbacks of bumping *defaults*.

Any thoughts?

Unless there's strong opposition to not bump those 1024/4096 current 
defaults, I'd like to bump those limits. Normally I'd create a bug and 
assign it to maintainer, however our sys-libs/pam maintainer has not 
been seen in last half a year, so I'd end up joining as co-maintainer 
there in the result.

-- Piotr.