I have the log entry
Jan 25 04:02:33 lbtest1 haproxy[24428]: Server LDAPFarm/dp1 is DOWN,
reason: Layer7 timeout, check duration: 5001ms. 2 active and 0 backup
servers online. 0 sessions requeued, 0 total in queue.
In my /var/logs/messages. I run a healthcheck (mode httpchk) via
xinetd on the same host as haproxy runs. Does this imply that my
xinetd/health-check script didn't "answer" for 5 seconds? Or does the
log entry imply the xinetd/health-check script did answer but the
script in turn did not return any information?
My config is
listen LDAPFarm AA:389
mode tcp
option tcplog
option httpchk
balance roundrobin
timeout connect 5s
timeout client 3h
timeout server 3h
timeout check 900ms
server dp1 BB check addr 127.0.0.1 port 9101 inter 5s
fastinter 1s downinter 3s fall 2 rise 2
All my backend servers were flagged as down (I have more server dp#...
lines), all because of the same reason. Looking at my backend server,
I don't see any actual problem with them at that time. So I was
wondering if my health-check script was misbehaving for some reason
or my xinetd broke or what.
My other services also controlled by the same haproxy process (but
using a different health-check and different backend-servers) were all
ok during my "downtime".
After all my back-end servers for the particular listen stanza were
flagged as down, I started getting in my logs:
Jan 25 04:03:02 lbtest1 haproxy[24428]: XXXX:33312
[25/Jan/2010:04:03:02.930] LDAPFarm LDAPFarm/<NOSRV> -1/-1/0 0 SC
420/99/99/0/0 0/0
So I'm guessing I got one of these such log lines every time a client
requested this particular LDAP service, but couldn't get anywhere
because there were no back-end servers running.
Does haproxy queue them up (up to some maximum queue/backlog number)?
Or does haproxy reject them immediately?
Thank you,
PH
