Re: [PATCH v4 2/2] tools/xenstore: set open file descriptor limit for xenstored

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Juergen Gross writes ("Re: [PATCH v4 2/2] tools/xenstore: set open file 
descriptor limit for xenstored"):
> On 27.09.21 16:13, Andrew Cooper wrote:
> > both work fine, and strace confirms they issue correct system calls.
> 
> Not on my test system:
> 
> # prlimit --pid 734 --nofile=unlimited
> prlimit: failed to set the NOFILE resource limit: Operation not permitted
> # prlimit --pid 734 --nofile=262144
> #
> 
> > Support for "unlimited" as a parameter has existed for the entire
> > lifetime of the utility,
> > https://github.com/karelzak/util-linux/commit/6bac2825af7216c5471148e219dbcf62ec5ede84
> 
> Yes, but not all systems seem to support raising the limit to
> "unlimited".

This is strange.  Are you running in some kind of restricted
environment ?  <strike>Or maybe prlimit is trying to adjust the soft
limit (only) but failing to remove the hard limit too ?  I confess
that I never use prlimit, just ulimit.</strike>

I just tried this on my laptop:

root(ian)@zealot:~> ulimit -Hn 1048577
bash: ulimit: open files: cannot modify limit: Operation not permitted
root(ian)@zealot:~> ulimit -Hn 1048576
root(ian)@zealot:~>

????

1048576 is 0x100000.
1048577 is 0x100001.

The intertubes caused me to check sysctl fs.file-max (1591013),
/etc/security/limits.conf (nothing uncommented).  Eventually a helpful
person pointed me to /proc/sys/fs/nr_open.

root(ian)@zealot:~> cat /proc/sys/fs/nr_open
1048576

This is completely deranged.  The internet is full of people working
around this (if you are unluckloy you try to set nofile unlimited in
some file in /etc/security and then you can't log in!).

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60fd760fb9ff7034360bab7137c917c0330628c2
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f

^ that explains why things are like this.  Oh woe is us what madness
have we collectively perpetrated.

I suggest the following workaround for our scripts: try to read
/proc/sys/fs/nr_open and use the value from there if there is one;
otherwise use "unlimited".

I think that is better than sort-of-guessing 262144.  What you do you
think ?

Thanks,
Ian.