Comment # 19 on bug 1165351 from Luis Chamberlain

(In reply to Thorsten Kukuk from comment #17)
> (In reply to Thomas Blume from comment #15)
> > (In reply to Franck Bui from comment #14)
> > > After some more debugging I finally found that the bug is essentially the
> > > same as the one reported here:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1705641
> > > 
> > > A more interesting discussion can be found here
> > > https://github.com/systemd/systemd/pull/13359 but unfortunately it led to
> > > nowhere.
> > > 
> > > Adding Thomas in Cc as he's the libtirpc maintainer.
> > 
> > Indeed:
> > 
> >          return (tbsize = (int)rl.rlim_max);
> > 
> > seems to be a bit excessive.
> > But I'm not sure how else to determine a good value.
> > Thorsten, would be changing this to the soft limit appropriate, e.g:
> > 
> >          return (tbsize = (int)rl.rlim_cur);
> > 
> > ?
> 
> As far as I understand the code, no, this will not work. To be fast they are
> doing something which is very fast, but also very memory consuming: have a
> table for all possible file descriptors to lookup the data instead of going
> through a list of existing file descriptors.

Let us think proactively as well, if this was done, was it inspired by another
codebase? Who else might be doing similar practice?

> If you set the limit lower than
> possible, you could get a out of array access.
> The code was written at a time, when 1024 file handles was the maximum
> possible, not for that big numbers as of today.

chivo:~/:[0]# cat /proc/sys/fs/file-max
9223372036854775807

> I would discuss this on the tirpc mailing list. The whole code needs to be
> rewritten to be less memory consuming.

And probably backported... down to what release? :)

A puzzle I don't see yet resolved is that this issue triggers only on one
system, and not for another twin system with the same software/hardware. Any
ideas on that?

ie, I am not sure if this issue is easily reproducible on all systems.