On Wed, Jan 13, 2010 at 01:33:58PM -0800, Paul Hirose wrote:
> I stumbled across a few "SC" results in my logs, which the docs say is:
> "
> SC The server or an equipement between it and haproxy explicitly refused
> the TCP connection (the proxy received a TCP RST or an ICMP message
> in return). Under some circumstances, it can also be the network
> stack telling the proxy that the server is unreachable (eg: no
> route,
> or no ARP response on local network). When this happens in HTTP
> mode,
> the status code is likely a 502 or 503 here.
> "
>
> Is there a way to tell which backend server haproxy was trying to
> connect to? The log just says "...<NOSRV> -1/-1/0 0 SC 0/0/0/0/0
> 0/0"? I'm strictly mode tcp and option tcplog. I do mostly LDAP/S
> connections.
normally you shouldn't have any SC with <NOSRV>, precisely because it
would mean the server was already known. However I remember that in the
past, we used SC also for the queue, which could have explained that,
but your queue was empty here so that's not the case. I wonder if we
still get this flag when there is no server available (503 in return).
Could you check your logs to see if your servers were still available ?
In such a case, it seems we should try to change this flag to write PC
to indicate that it's the proxy which detected the condition preventing
the connection from happening.
> I have "retries 3" and "option redispatch". So does the above log
> entry imply one of by backends refused a connection, and haproxy thus
> sent it to another backend server instead?
if so, the retry counter (the fifth of the 5 values) would have increased,
and in case of a redispatch, it would have been prepended with a '+' sign,
like this :
SC 0/0/0/0/+3
> And just for clarity, does haproxy try twice to the bad backend, and then
> the final third try is to another backend?
yes, that's it.
Regards,
Willy
