Your message dated Mon, 20 Jan 2025 15:10:39 -0700 with message-id <[email protected]> and subject line pam_limits does not choose the default limits has caused the Debian Bug report #1076384, regarding Limit nfile set too low to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1076384: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076384 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libpam-modules Version: 1.5.3-7 $ ulimit -n; ulimit -n -H 1024 4096 The soft limit has some merit, since some (old) programs still cannot handle file descriptors about 1024. On the other hand, I see no reason to keep the hard limit that low: if a program changes the limit, it probably knows what it's doing, and a few thousand file descriptors should not be prohibitive on a modern system, even an SBC. Please consider increasing the default nfile hard limit. 16384 should be a fine value for most setups, but you might consider going the full way up to 65535. -- Juliusz Chroboczek
--- End Message ---
--- Begin Message ---version: 1.7.0-1 Hi. pam_limits does not actually choose the default for max number of open files. Prior to version 1.7.0-1 (currently in experimental) it reads the limits from pid 1. Which depending on your version of systemd either gives you 4096 or 1073741816 Starting with 1.7.0-1, we do not change the limit on open files unless you set an explicit limit or include the set_all option. In this case you get whatever open file limit you inherit from systemd. In any case the 4096 number is coming from the linux kernel not pam_limits.
--- End Message ---
