Re: Maintenance mode

From: Aleksandar Lazic <>
Date: Wed, 10 Sep 2008 23:47:52 +0200

Dear Alexander,

On Mit 10.09.2008 23:03, Alexander Staubo wrote:
>Guys, I would like to bring this subject up again. I have not been able
>to work out a satisfactory solution to the problem.
>In a nutshell, when we -- my company -- perform a site update, we want
>to display a static web page showing the current maintenance state. A
>site update usually involves taking down all Rails processes, checking
>out new code, and bringing Rails up again. So while this is going on,
>HAProxy will attempt, and fail, to connect to its backend servers.

how about


frontend www

         mode http
         acl site_dead nbsrv(dynamic) lt 1
         acl site_dead nbsrv(static)  lt 1
         monitor-uri   /site_alive
         monitor fail  if site_dead


As the thread start with the nginx example, please can you tell us, only if you can / want, how your setup looks like?

e.g.: ? -> haproxy -> mongrel -> rails

on the same server?

What are the steps @site update?

Maybe it is possible to send a http errorcode other then 503 e.g. 506 to haproxy and you can catch it with

acl maintenance_mode status 506 acl status_error status 400:599

Yust some ideas.

but yes this is not a easy task, with the lower excludes.

>There are a few possible solutions, all of them unsatisfactory:

[snipp the not working ways]

>Now, I have a suggestion for a proper solution, and if Willy likes it I
>will try my hand at coughing up a patch. The idea is to support
>user-defined variables that are settable at runtime. In the
>configuration, these variables would be usable as ACLs:
> frontend http
> ...
> acl variable maintenance_mode true
> use_backend maintenance if maintenance_mode
>To control a variable you would invoke the haproxy binary:
> $ haproxy -S maintenance_mode=true
> $ haproxy -S maintenance_mode=false
>Using shared memory for these variables is probably the easiest,
>fastest and secure. It would be mapped into HAProxy's local address
>space, so a lookup is essentially just a local memory read, cheap
>enough to check on every request. Similarly, read and write access to
>the variables could then be limited to the HAProxy user, if I remember
>my POSIX shared memory semantics correctly.
>Having such variables at hand would also let you do other tricks not
>specifically related to maintenance. For example, you can have
>external monitoring scripts that modify the behaviour of HAProxy based
>on some sort of load parameter.

Sounds nice, but very deep intervention into haproxy.

If you have the time and leisure, yes a fast and small shared memory implementaion would be a nice benefit for haproxy, from my point of view ;-)

Aleks Received on 2008/09/10 23:47

This archive was generated by hypermail 2.2.0 : 2008/09/11 00:00 CEST