How do I recompile HAProxy with ZLIB support?

Question

We are running a high-traffic, load-balanced site on CentOS. When I installed haproxy, I used:

make TARGET=linux26 USE_OPENSSL=1 ADDLIB=-lz
make PREFIX=/usr/local/haproxy install

but now I need to add zlib support.

I know that the command for a fresh install would be:

make TARGET=linux26 USE_OPENSSL=1 USE_ZLIB=1 ADDLIB=-lz
make PREFIX=/usr/local/haproxy install

But how do I recompile it into an existing haproxy install without uninstalling first? The site is too high traffic to take it down for even a minute.

I spent 30 minutes Googling for the answer and while I found something that talks about using make clean to do a recompilation, as somewhat of a Linux noob, I thought I should ask the experts how it's supposed to be done and for the exact syntax.

Answer 1

make clean will indeed clean your compilation directory.

My advice would be to:

• clean the compilation directory, NOT the install dir
• recompile with zlib support
• install in another dir
• change the currently installed non zlib haproxy to another path

which translates in bash to

make clean
make TARGET=linux26 USE_OPENSSL=1 USE_ZLIB=1 ADDLIB=-lz
make PREFIX=/usr/local/haproxy-zlibed install
mv /usr/local/haproxy /usr/local/haproxy-not-zlibed
ln -s /usr/local/haproxy-not-zlibed /usr/local/haproxy

At this point you're in the exact same situation as you were before.

then use symbolic links to switch from your current haproxy to the other:

use the current haproxy (without zlib)

rm -fr /usr/local/haproxy
ln -s /usr/local/haproxy-not-zlibed /usr/local/haproxy

and restart haproxy your usual way

or, to use the haproxy with zlib support

rm -fr /usr/local/haproxy
ln -s /usr/local/haproxy-zlibed /usr/local/haproxy

and restart haproxy your usual way

That way you can test your new zlibd haproxy and rollback if necessary

Answer 2

On Linux there's no need to uninstall or even stop a service before you recompile and reinstall.

That's true because of how modern (and even not-so-modern) filesystems work: File contents are attached to inodes and inodes are attached to directory entries (having a 1:0..n relationship). Thus, you can delete the directory entry for a running program, but as long as its inode isn't deallocated (which will never happen so long as it continues running), it still has a file handle on its own executable, and can continue to work.

Now, with HAProxy in particular, there's support for seamless restarts -- where a new process starts up, tells the old process to drop its listen sockets but keep servicing the existing connection, grabs new listen sockets itself, tells the old process that this succeeded (or if it failed, in which case the old process regrabs its own listen sockets), and then allows the old process to shut down when done. See http://www.mgoff.in/2010/04/18/haproxy-reloading-your-config-with-minimal-service-impact/ for a writeup on the process.