On Wed, 2019-01-30 at 14:58 +0000, Clint Adams wrote: > On Wed, Jan 30, 2019 at 09:51:42AM -0500, Dan Martins wrote: > > On systems where the nofile limit is large, fakeroot hangs > > For example on an Arch Linux system, where > > DefaultLimitNOFILE=infinity > > in /etc/systemd/system.conf: > > Any idea how other programs are being patched to cope with this?
No.. Initially, I was hoping you might have some idea. After digging some more, I found a few reports in the debian bug tracker for other software (kdeinit, mount.nfs) having similar issues. Things in debian seem a bit more complicated due to a patched pam_limits, but the workaround appears to be limiting the hard limit via systemd or pam. So infinity doesn't really mean infinity. I didn't find any reports where the program itself was patched to handle this better. https://github.com/systemd/systemd/issues/10921 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917167 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917168 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917357 It may be this commit https://salsa.debian.org/systemd-team/systemd/commit/084e84e33a403868b7f84159da745689e2ff0ba9 Which on a debian system appears to limit nr_open $ cat /proc/sys/fs/nr_open 1048576 And in turn caps the hard limit, even when 'infinity' is used in the systemd configuration: ulimit -Hn 1048576 With this limit, fakeroot operates without significant delay. Arch typically doesn't patch upstream so I think it is unlikely they will take a similar approach. With that said, I'm not aware of a real reason to set DefaultLimitNOFILE to infinity.
