On Thu, Jul 8, 2021 at 3:33 PM Yann Ylavic <ylavic....@gmail.com> wrote:
>
> On Thu, Jul 8, 2021 at 2:55 PM Stefan Eissing
> <stefan.eiss...@greenbytes.de> wrote:
> >
> > This seems to be it! Yann strikes again! And I learned something...\o/
>
> Thanks Stefan :)
>
> >
> > I needed to make small tweaks, because no all previous close checked the
> > return value and I got assert failures on your patch.
>
> Interesting, what error value was that? EBADF, EAGAIN?
>
> > I attach my version
> > below. Instead of the param, there could also be 2 functions, one without
> > checks. A matter of taste.
>
> Depending on the error cases, we might want to fix something or ignore
> or relax the assertion maybe.
> Let's see..
>
> >
> > So, I try to summarise:
> >
> > - the effect was triggered by the keep-alive connections remote endpoints
> > slumbering in a proxy connection pool where no one was monitoring the
> > sockets and reacting to TCP FIN packets.
> > - This triggered a long LINGER timeout that blocked the listener from
> > exiting. Ultimately leading to the parent killing the child.
> > - This situation could also happen, I assume, when a client drops from
> > the network, e.g. a cell phone entering bad coverage, where no one
> > in the network path really knows what to do? Or a network connectivity
> > issue or a comp crashing behind a NAT?
>
> Exactly, I think that closing kept alive connections is the right
> thing to do here, lingering close helps neither MPM event nor the
> client.
> I first tried to use the short linger timeout instead of the long one,
> but I don't see a reason to linger those connections, even a little.
> Other opinions maybe?
>
>
> Cheers;
> Yann.
