Re: HAProxy Hot Reconfiguration with s6

From: Martin \ <>
Date: Wed, 18 May 2016 15:26:56 +0200

On Mon, 16 May 2016 23:50:04 +0200
Remko Tronçon <> wrote:

> You spawn a new haproxy instance yourself, and pass it the PID of the process
> you want to replace:
> The new instance uses SO_REUSEPORT to attach to the same port, and then sends
> a FINISH signal to the given PID to gracefully shut down the running
> instance.

I see, this works quite different from what I expected even. As I am
starting to understand s6 and supervison principles and their tie ins into
unix ideas more and more, it appears to me that this "simple" PID is quite
interesting resource.

Easiest solution and doable right now, is definately "two alternating
services" approach. But it got me thinking how would one do this "correctly".
"correctly" here depends on personal views, I am afraid. I, personally, am
trying to arrange my stuff as neat process trees. So take this reasoning with
grain of salt please.

IMHO more "proper" or rather interesting approach, could perhaps be some kind
of helper program - "injecting" "alternator" sub-process - which would be
running under s6-supervise. It would be capable of spawning several service
daemons, eg "inject" them as it's children, based on external event and wait on
them. It would "switch/alternate" in monitoring latest "injectee". I am already
experimenting with similar waiting parent approach, but without injection.

This would be probably more "elaborate" piece of program (eg many
parts of s6 are dead simple, but some are really crazy to look at (at least for
me)) and then, there is question of communication protocol as well - I don't
think signals would be enough to convey to this "alternator" sub-process what to

Also, what I started calling "generational distance" between processes,
increases by one generation with this approach, which is probably worse than
with two services switching, where each is direct child of given s6-supervise.

Ofc one should switch s6-supervise, with supervisor of their choice.

Received on Wed May 18 2016 - 13:26:56 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC