Re: [PATCH v3] tools/xenconsoled: Increase file descriptor limit

[Ian Jackson <Ian.Jackson@eu.citrix.com>]

Andrew Cooper writes ("Re: [PATCH v3] tools/xenconsoled: Increase file descriptor limit"):
> On 19/02/15 16:30, Ian Jackson wrote:
> > Why is this only a stopgap solution ?
> 
> It is yet another place with an arbitrary limit, which is one more
> moving part to go wrong.

OIC.  I meant `unlimited', but...

> >>> As Xenconsoled genuinely needs a large number of file descriptors
> >>> if a large number of domains are running, and is well behaved with
> >>> its descriptors, attempt to up the limit to the system maximum.
> > Perhaps you mean it should be "unlimited" but that doesn't seem right
> > either.
> 
> Where do I perhaps mean "unlimited"?
> 
> Attempting to set NOFILE with RLIM_INFINITY is an unconditional failure,
> and there is unfortunately no RLIM_SYSTEM_MAX.

Urgh.

I think this is a bug in Linux.

  http://pubs.opengroup.org/onlinepubs/9699919799/functions/getrlimit.html

  [EPERM]
      The limit specified to setrlimit() would have raised the maximum
      limit value, and the calling process does not have appropriate
      privileges.

But that's not what's happening, or at least, it's a contorted
interpretation.

Best in shell is using `sysctl':
   ulimit -H -n "$(sysctl -n fs.nr_open)"
But not very portable.

So I am now convinced this should be done in C :-/.

> > The value should be some multiple of the maximum number of
> > domains.
> 
> The maximum number of domains (limited by the domid abi) is 32751
...
> That would put the number of fds needed at 131004 + overhead (20
> perhaps?).  This is substantially larger than the default on Linux, but
> within the default system max of 2^20.

Considering this, and looking at your actual code I think you should
simply set the value to 131004[1] (plus say 1000 spare for libc use
and so on) and not bother with trying to find the system maximum.

It would be nice to warn if the attempt fails.

[1] Computed from appropriate #defines.

Ian.