Hi Pierre,

On Fri, Oct 14, 2016 at 10:54:43AM +0000, Pierre Cheynier wrote:
> Hi Lukas,
> 
> > I did not meant no-reuseport to workaround or "solve" the problem 
> definitely, but rather to see if the problems can still be triggered, 
> since you can reproduce the problem easily.
> 
> This still happens using snapshot 20161005 with no-reuseport set, a bit less 
> probably because reload is faster.
> 
> Here is what I observe after reloading 50 times, waiting 0.1 sec between 
> each: 
> 
> $ ps fauxww | tail -9
> root     50253  0.1  0.0  46340  1820 ?        Ss   10:43   0:00 
> /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p 
> /run/haproxy.pid
> haproxy  51003  0.0  0.0  78256  9144 ?        S    10:44   0:00  \_ 
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 
> 51000
> haproxy  51025  0.3  0.0  78256  9208 ?        Ss   10:44   0:00  |   \_ 
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 
> 51000
> haproxy  51777  0.0  0.0  78256  9144 ?        S    10:44   0:00  \_ 
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 
> 51771
> haproxy  51834  0.3  0.0  78256  9208 ?        Ss   10:44   0:00  |   \_ 
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 
> 51771
> haproxy  51800  0.0  0.0  78256  9140 ?        S    10:44   0:00  \_ 
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 
> 51785
> haproxy  51819  0.3  0.0  78256  9204 ?        Ss   10:44   0:00  |   \_ 
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 
> 51785
> haproxy  52083  0.0  0.0  78256  9144 ?        S    10:47   0:00  \_ 
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 
> 52076
> haproxy  52084  0.3  0.0  78256  3308 ?        Ss   10:47   0:00      \_ 
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 
> 52076
> 
> $ sudo ss -tanp |grep -i listen | grep 80
> LISTEN     0      128          *:80                       *:*                 
>   users:(("haproxy",pid=52084,fd=8))
> LISTEN     0      128          *:8080                     *:*                 
>   users:(("haproxy",pid=52084,fd=6))
> LISTEN     0      128    10.5.6.7:8000                     *:*                
>    users:(("haproxy",pid=52084,fd=7))
> 
> $ head -12 /etc/haproxy/haproxy.cfg
> global
>      log 127.0.0.1 local0 warning
>      log 127.0.0.1 local1 notice
>      maxconn 262144
>      user haproxy
>      group haproxy
>      nbproc 1
>      chroot /var/lib/haproxy
>      pidfile /var/run/haproxy.pid
>      stats socket /var/lib/haproxy/stats
>      noreuseport
> 
> Definitely, some instances seems to be "lost" (not referenced by another) and
> will never be stopped.

Is this with live traffic or on a test machine ? Could you please check
whether these instances have one connection attached ? I don't see any
valid reason for a dying process not to leave once it doesn't have any
more connection. And during my last attempts at fixing such issues by
carefully reviewing the code and hammering the systemd-wrapper like mad,
I couldn't get this behaviour to happen a single time. Thus it would be
nice to know what these processes are doing there and why they don't
stop.

Regards,
Willy

Reply via email to