On Wed, Nov 29, 2017 at 11:54:28AM +0100, Willy Tarreau wrote: > On Wed, Nov 29, 2017 at 10:41:18AM +0100, Willy Tarreau wrote: > > > 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. > > I understand now. It's embarrassing. Sessions are released only when > instanciated from a connection but never from an applet. So indeed we > keep a non-null job count which prevents the old process from quitting.
Now fixed in both mainline and 1.8. Thanks for the report Manu! Willy
