http://bugzilla.suse.com/show_bug.cgi?id=1165351 http://bugzilla.suse.com/show_bug.cgi?id=1165351#c56 --- Comment #56 from Thomas Blume <thomas.blume@suse.com> --- (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? -- You are receiving this mail because: You are on the CC list for the bug.