Comment # 56 on bug 1165351 from Thomas Blume

(In reply to Luis Chamberlain from comment #55)
> (In reply to Franck Bui from comment #54)
> > (In reply to Luis Chamberlain from comment #53)
> > > Yes you can hammer on that system all you like until the issue can be
> > > root-caused. Do as you think is needed :)
> > 
> > Are you kidding ?
> > 
> > This issue has been understood since comment #14...
> 
> On comment #44 Thomas mentioned he was not sure if libtirpc was the real
> issue here. So I'll defer to the systemd folks to decide. I'm just happy to
> make the system available to further diagnose.

I've created a debug version of libtirpc3 and did some testing.
After some discussion with Franck, it turns out that, unlike any other daemon
on the system, a systemd user daemon has neither user nor system slice limits.
Instead it inherits the limits of the parent systemd daemon (e.g. pid1) which
has, for file_open the limits of /proc/sys/fs/nr_open, e.g. no limits.

I don't want to discuss here whether a systemd user daemon should respect slice
limits, but I see that all other daemons do (at least the limits of
system.slice).
Therefore, I think there is no danger in limiting libtirpc to  LimitNOFILE of
the system slice.
If that wouldn't be enough for libtirpc3, all daemons that use it and have the
limits of system slice would have a problem.
Franck, do you see any problem for the systemd user daemon with this approach?