From: Piotr Karbowski <slashbeast@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with
Date: Sun, 11 Dec 2022 09:28:14 +0100 [thread overview]
Message-ID: <8e75c01a-e798-d822-312d-cb21b6d70d45@gentoo.org> (raw)
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.
next reply other threads:[~2022-12-11 8:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-11 8:28 Piotr Karbowski [this message]
2022-12-11 12:46 ` [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with Sam James
2022-12-11 15:38 ` Piotr Karbowski
2022-12-12 5:52 ` Robin H. Johnson
2022-12-12 21:55 ` Piotr Karbowski
2022-12-12 22:06 ` Sam James
2022-12-12 22:26 ` Piotr Karbowski
2022-12-12 22:53 ` Sam James
2022-12-13 3:24 ` John Helmert III
2022-12-13 5:18 ` Joonas Niilola
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8e75c01a-e798-d822-312d-cb21b6d70d45@gentoo.org \
--to=slashbeast@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox