On Thu, May 09, 2019 at 11:42:54AM -0600, ericr wrote:
> A couple of weeks ago I installed haproxy on our server running FreeBSD
> 11.0-RELEASE-p16. (yes, I know it's an old version of the OS, I'm going to
> upgrade it as soon as I solve my haproxy problem.)

Can you tell us what exact version you're running ? Please send the output
of "haproxy -vv".

> Haproxy is supposed to load balance between 2 web servers running apache.
> haproxy ran fine and balanced well for about 2 weeks, and then it stopped
> sending client connections to the second web server.

But it still works for the first one ?

> It still does health checks to both servers just fine, and reports L7OK/200
> at every check for both servers. I've tried using both roundrobin and
> leastconn, with no luck.  I've restarted haproxy several times, and
> rebooted the server it's running on, and it the behavior doesn't change.

Did you notice if it's always after the exact same amount of time ? Or
maybe after a certain number of requests ? We could have imagined a bug
with one LB algo but if it does it regardless of the algo this rules it

Oh wait a minute :

> # info about backend servers
> backend web_servers
>         balance leastconn
>         cookie phpsessid insert indirect nocache
>         option httpchk HEAD /
>         default-server check maxconn 2048
>         server vi-www3 cookie phpsessid inter 120s
>         server vi-www4 cookie phpsessid inter 120s

So for both servers you're setting a response cookie "phpsessid=phpsessid"
which has the effect that all your visitors will come back with this cookie
and that the first server which matches this value will take it, hence the
first server. First, I recommend against naming your stickiness cookies
"phpsessid" as it makes one think about the application's cookie which it
is not. Second, you need to use different cookie values here, for example
"cookie w3" and "cookie w4" for your two respective servers.

Lat recommendation, I don't know if it's on purpose that you check your
servers only once every two minutes, because it's extremely slow and will
take a very long time to detect a failure. Unless you're facing a specific
limitation, you should significantly shorten this interval to just a few


Reply via email to