Hi, We've noticed that our haproxy processes accumulate many file descriptors to /dev/urandom over time. This coincidences with reloads;
rnewson@lb2:~$ sudo service haproxy restart rnewson@lb2:~$ sudo ls -l /proc/$(pgrep -o haproxy)/fd | grep -c '/dev/urandom' 1 rnewson@lb2:~$ sudo ls -l /proc/$(pgrep -o haproxy)/fd | grep -c '/dev/urandom' 1 rnewson@lb2:~$ sudo service haproxy reload rnewson@lb2:~$ sudo ls -l /proc/$(pgrep -o haproxy)/fd | grep -c '/dev/urandom' 2 rnewson@lb2:~$ sudo ls -l /proc/$(pgrep -o haproxy)/fd | grep -c '/dev/urandom' 2 rnewson@lb2:~$ sudo service haproxy reload rnewson@lb2:~$ sudo ls -l /proc/$(pgrep -o haproxy)/fd | grep -c '/dev/urandom' 3 rnewson@lb2:~$ sudo service haproxy reload rnewson@lb2:~$ sudo ls -l /proc/$(pgrep -o haproxy)/fd | grep -c '/dev/urandom' 4 We've seen a node with over 20,000 open file descriptors to this same file. We are running under systemd. Our config is quite complicated so I'm not posting it here just yet, I'd appreciate guidance on which parts might be relevant. We do use "expose-fd listeners" to hand over open sockets cleanly during reload but nothing else seems obviously related. We see this with haproxy 1.8.16 and 1.9.6. We have a few deployments of 1.7.9 where the count remains at 0 (which is also odd given we use TLS exclusively). Any suggestions? B. -- Robert Samuel Newson rnew...@apache.org
