In the case of `stop` - I image that the stale / former sockets can be listed using: `sudo lsof | grep SOMETHING` ?
I'm wondering if an additional shell level checks / cleanup can be done in such cases were related PID's would be killed? - or perhaps there's a core part to how socets are created and managed that I'm lacking. Thanks for the input Willy! :-) On Tue, May 10, 2016 at 2:15 PM, Willy Tarreau <w...@1wt.eu> wrote: > On Mon, May 09, 2016 at 04:12:32PM +0200, Pavlos Parissis wrote: > > On 09/05/2016 02:26 ????, Christian Ruppert wrote: > > > Hi, > > > > > > it seems that HAProxy does not remove the UNIX sockets after reloading > > > (also restarting?) even though they have been removed from the > > > configuration and thus are stale afterwards. > > > At least 1.6.4 seems to be affected. Can anybody else confirm that? > It's > > > a multi-process setup in this case but it also happens with binds bound > > > to just one process. > > > > > > > I can confirm this behavior. I don't think it is easy for haproxy to > > clean up stale UNIX socket files as their names can change or stored in > > a directory which is shared with other services. > > In fact it's not exact, it does its best for this. The thing is that upon > a reload it's the new process which takes care of removing the old socket > and it does so pretty well. But if you perform a stop there's no way to > do it if the process is chrooted. In practice many daemons have the same > issue, that's how you end up with /dev/log even when syslogd is not running > or with /tmp/.X11-unix/X0 just to give a few examples. > > Hoping this helps, > Willy > > >
