> > If I disable this (as it was before) everything works as it should. It > > even figures out (correctly) that one server returns "all_is_ok" and > > another just empty string - and takes the other one down. > > Interesting. Have you run haproxy -d from the command line to check > the debugging output? "option log-health-checks" is also useful.
I was running it from the command line (too) because logging was not working (rsyslogd's UDP support was disabled). That was the output I have sent in the first mails. > It's a half-close. HAProxy only sends one request, and then waits for > the response, so we might as well close the transmit channel. Are you sure nothing is being sent anymore through this socket? Never? > When tcpdump'ing the problem system that led me to work on this, I > found that HAProxy was not closing the transmit channel properly. The > real servers were sending FIN to close their side, and HAProxy was > responding with RST. So I put in the half-close to make sure the > connection was cleanly shut down. I think this is not the proper way to deal with this, but as I said, I am no expert in sockets programming. I would say that haproxy still tries to sent RST but can't - which leads to an error somewhere. > It's interesting that this has caused problems in your system. As well > as running HAProxy in debug mode, would you be able to do a tcpdump on > the system running haproxy? If you could do that both with and without > the half-close, that would be very useful. Hmmm, I am a bit out of depths here. I would love to help out, but please send me more specific instructions on what you need. What arguments should I use with tcpdump so it helps you? Also, if you don't mind, I'd like to send it privately to you and Willy (so I don't need to clean up too much private / security sensitive info from it). > If required, I can send you a version of checks.c with debugging code > in it - that will dump a lot of data on the checks if you run it in > debug. Sure, bring it on. ;) > > option httpchk GET /check.php HTTP/1.0 > > ... > > > option httpchk HEAD /check.php HTTP/1.0 > > Those two will not check the content - I'll need to trawl through the > config code to check whether it defaults to checking the HTTP return > code in these cases. I have tested GET with the fixed version (no half-closed socket) and it works. But it would still be good if you checked it out for sure. There are a lot of existing configs that are setup like this - it wouldn't be good if they broke down in next version. ;) Thanks, Anze
