Re: httpchk - checking request body

> > 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 Received on 2010/03/13 21:08