Idézet (Willy Tarreau <[email protected]>):
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 !
Thanks Willy,
Awaiting the discovery! :P
Willy
