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

[Christian Ebner]

On 11/20/25 6:22 PM, Thomas Lamprecht wrote:
> 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.

I think I came up with a solution over night, which does not require us 
to bump the file limits: After all one can better control and work 
around the max number of flocks needed during phase 2 of garbage 
collection for the s3 backed datastores, without sacrificing to much 
performance.