Re: Bug or enhancement on Haproxy 1.3.14.2

Hi Romuald,

On Thu, Mar 27, 2008 at 11:02:11AM +0100, Romuald du Song wrote:
> Hy everybody,
>
> When we change our haproxy configuration file we use those switches :
> /usr/local/sbin/$BASENAME -D -f $CONFIG -p $PIDFILE -sf $(cat $PIDFILE)
>
> to relaunch haproxy. It works allrigth.
>
> But if there is a new proxy defined on a port that haproxy cannot bind on
> haproxy quits. So all your services are down !
>
> I'd rather like it to keep serving other proxies.
>
> Does it make sense to anyone else ?

Seems strange to me, because the old process only goes away once the new one has *completely* started.

On systems with SO_REUSEPORT (*BSD, patched linux), the start up goes like this :

• new process reads conf
• new process binds to all ports
• new process sends SIGUSR1 to old processes ($PIDFILE)
• old processes finish current sessions then exit

On systems without SO_REUSEPORT (linux, solaris, ...) what happens in your case above becomes this :

• new process reads conf
• new process tries to bind to all ports. One conflict is found, the error is marked retryable, so the new process stops binding itself to every port.
• new process sends SIGTTOU to old processes ($PIDFILE)
• old process stops listening to all ports
• new process binds to all ports.
• if binding works, new process sends SIGUSR1 to old processes ($PIDFILE), which finish current sessions then exit
• if binding fails, new process stops listening, sends SIGTTIN to old processes ($PIDFILE), which then re-enables listening on old sockets, and continues its work.

If this is not what you have observed, obviously there is a problem somewhere. What precise system (and version) are you running this on, and what haproxy version ? If you could send a small configuration which triggers the problem, it would help a lot.

Regards,
Willy Received on 2008/03/31 07:36