Hello Anze.
On 13 March 2010 18:42, Anze <anzen...@volja.net> wrote:
>> I will try to trace where the check fails and why. I guess it is easiest
>> for me to do it because i can replicate the error anytime. ...
>
> Ok, looks like the culprit is this piece of code:
> -----
> /* Close the transmit channel, leaving the connection half-open... */
> int shut = shutdown(fd, SHUT_WR);
> int err = errno;
>
> if (shut == -1)
> {
> Alert("event_srv_chk_w(): err = %i, %s\n", err, strerror(err));
> }
> -----
>
> 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.
> However, I have no idea why it works now. My knowledge of sockets is very
> limited. Also, I have found this in the first 10 minutes of looking at the
> code - I found that httpchk_expect() is not even called, so I checked other
> stuff in the patch and this looked very suspicious to me so I disabled it. And
> it just started working. I also figured that shutting down socket for writes
> only is... well, a bit black-magic-ish and not really necessary. ;) You must
> shutdown the whole socket sometime later anyway.
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.
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.
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.
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.
Replying to your earlier message...
> option httpchk GET /check.php HTTP/1.0
> http-check expect rstring all_is_ok
...
> option httpchk GET /check.php HTTP/1.0
> http-check expect string all_is_ok
Those configurations should work - at least, they do in my tests.
> 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.
Nick.
--
Nick Chalk.
Loadbalancer.org Ltd.
Phone: +44 (0)870 443 8779
http://www.loadbalancer.org/
