[pbs-devel] [PATCH proxmox-backup v3] etc: raise nofile soft limit to hard limit for proxmox-backup-proxy

[Thomas Lamprecht]

Am 20.11.25 um 16:12 schrieb Christian Ebner:
> On 11/20/25 4:05 PM, Thomas Lamprecht wrote:
>> Am 20.11.25 um 15:32 schrieb Christian Ebner:
>>> This is acceptable since PBS does not directly depend on problematic
>>> select() calls as verified via `nm` and does not use it in linked
>>> libraries to the best of my knowledge.
>>>
>>
>> Isn't above and
> 
> With above I intended to state that the PBS code itself does not call into select(), while below are dependencies on shared objects which might call into select() according to their symbols.
> 

And the systemd news entry you link to in the commit message clearly states:

----8<----
Programs that want to take benefit of the increased limit have to "opt-in" into
high file descriptors explicitly by raising their soft limit. Of course, when
they do that they must acknowledge that they cannot use select() anymore (and
**neither can any shared library they use — or any shared library used by any
shared library they use and so on**).
---->8----

I just checked the apt repo, and it includes various select calls. Most seem
to center around downloading packages and such, but I'd not bet on it that
no such select is anywhere in the code paths we use.

PAM uses select in the pam_loginuid, which might be part of the login call,
albeit it uses it only if require_auditd is enabled (which I don't think it is).
I did not yet checked the others out.

I mean, one option might be to provide our own select wrapper preloaded
overriding the glibc one and keep some FDs below 1024 resereved for that, but
I really really dislike doing such things. Similar in spirit would be providing
a select compatible implementation using poll and ld_preload that, but also far
from great..

Moving either GC, or all the things that might call select as per your list,
into a dedicated process might be the nicer thing to do. But as mentioned offlist
I'll try to walk through the problem and code again tomorrow and see if I can
find some other viable options (or you/fabian got some ideas), as of my current
knowledge I cannot really accept doing this bump.