On Tue, Nov 28, 2017 at 05:08:53PM +0100, William Lallemand wrote:
> On Tue, Nov 28, 2017 at 02:56:55PM +0100, William Lallemand wrote:
> > On Tue, Nov 28, 2017 at 12:22:04PM +0100, Emmanuel Hocdet wrote:
> > > ok, i should have something strange because it's easy to reproduce in my
> > > environnement.
> > >
> > > When i look lsof i see on master:
> > > haproxy 21355 root 4u IPv4 39007164 0t0 TCP 10.101.20.4:943
> > > (LISTEN)
> > > it's link to self ip configuration "peer L6_2 10.101.20.4:943"
> > >
> > > Master listen on peer? really?
> > > on each reload (kill -USR2) on more LISTEN appears
> > >
> >
> > I can reproduce easily the problem, the peers listener is not closed since
> > I removed
> > the deinit from the master-worker code, however that does not explain why
> > the old
> > worker does not quit.
> >
>
> Apparently this is reproducible without the master-worker, upon a reload with
> a local peer,
> the previous process doesn't leave.
I can now reproduce it. It happens that my previous failed tests didn't
trigger it because no stick table was referencing the peers.
I could bisect it to this commit from a well-known bug author :
commit 3e13cbafe2612dc026494d90ce8604f08cdaf58d
Author: Willy Tarreau <w...@1wt.eu>
Date: Sun Oct 8 11:26:30 2017 +0200
MEDIUM: session: make use of the connection's destroy callback
Now we don't remove the session when a stream dies, instead we
detach the stream and let the mux decide to release the connection
and call session_free() instead.
I don't immediately see how it can be related, but I suspect that it
results in peers connections not properly being closed.
Willy
