Hi Joe, On Sun, Sep 19, 2010 at 12:38:48AM +0200, R.Nagy József wrote: > Okay so here it is, let it die (after just 71secs this time!) with > modified srces and socket stats:
fantastic ! > Relevant message from debug window: > setsockopt: Connection reset by peer > [ALERT] 260/230253 (30302) : frontend_accept(): cannot set the socket > 11 in non blocking mode. Giving up > > 2nd try: > setsockopt: Connection reset by peer > [ALERT] 260/232249 (31233) : frontend_accept(): cannot set the socket > 7 in non blocking mode. Giving up > > So it is in frontend.c.. (there it is, am a coder after all;)) Very nice, now we know that the FD does not get corrupted, but when haproxy wants to use it, it's already closed on the other side. Probably that a TCP rule causes a reject that closes the connection and that there is a possible return path that escapes from the controlll, leading to frontend_accept() trying to continue to use the closed FD. I'll now try to find something in that spirit. Also, it looks like only TCP is affected by this, because your unix-stream connection worked like a charm, and used the same FD (7). I don't see anything suspect in the traces, but they clearly help eliminate wrong guesses. Thanks Joe, I'll keep you informed if I find anything ! Willy
