On Wed, Feb 3, 2016 at 7:48 PM Willy Tarreau <w...@1wt.eu> wrote: > Hi David, > > On Tue, Feb 02, 2016 at 11:56:25PM +0000, David Birdsong wrote: > > Has nobody else run into this w/ consul? Given the plethora of tools > around > > consul and haproxy and templating, I know others are using reloads to > keep > > backend current, but the old haproxy PIDs stick around listening w/ > > incorrect backends. > > No and this behaviour is really weird. Are you sure the list of pids > passed after "-sf" is *always* correct ? Since you're running on a > kernel 3.13, it supports SO_REUSEPORT, so this means that it supports > multiple processes being bound to the same port. Thus, if sometimes > you pass the wrong pid or an incomplete list, it will not prevent the > new process from starting but the old process will stay there listening. > > You should probably check using "ps" that remaining processes really > appear in the -sf line on the new process. > > There's one similar case I've seen a long time ago, a customer was > using "-sf $(cat /var/run/haproxy.pid)" in the startup script, and > was running two independant instances accidently using the same > pid file. Thus one instance would overwrite the other one's pid > list and the reload would fail half of the times because the old > pids would not be properly signaled. > > I don't know if that helps, > Willy > > Ok, I think this thread helped to uncover the root issue: https://github.com/hashicorp/consul-template/issues/442
root cause in go 1.5: https://github.com/golang/go/issues/13164
