Hi, Thanks for the suggestion and, yes, we're using the master-worker mode (-Ws specifically). I made a custom build as directed (https://github.com/cloudant/haproxy-1.9/tree/urandom-leak) and tried it out. Same leak, unfortunately. An extra /dev/urandom fd each reload.
B. -- Robert Samuel Newson [email protected] On Wed, 24 Apr 2019, at 14:02, Willy Tarreau wrote: > Hi Robert, > > On Tue, Apr 23, 2019 at 12:31:29PM -0400, Robert Newson wrote: > > We've noticed that our haproxy processes accumulate many file descriptors to > > /dev/urandom over time. This coincidences with reloads; > (...) > > We've seen a node with over 20,000 open file descriptors to this same file. > > I think I know what's happening. You're probably using the master-worker > mode since you're under systemd. We have to make openssl initialize its > RNG very early in the boot (before the chroot at least) and I suspect > that it doesn't mark the FD with CLOEXEC, so when the master re-execs > itself, the FD is not closed and a new openssl instance opens another FD > for /dev/urandom. > > If you want to run a quick test, please add "return 1;" at the beginning > of ssl_sock.c:ssl_initialize_random() and run your config without the > "chroot" directive so that /dev/urandom remains accessible during all > the process' life. If the issue disappears it comes from here. Otherwise > it may still come from here or from other places. > > We try to close all relevant FDs before execve() but it's possible that > a few slipped through the cracks :-/ > > Willy > >
