On 16/05/2016 23:50, Remko Tronçon wrote:
> You spawn a new haproxy instance yourself, and pass it the PID of the
> process you want to replace:
>
> haproxy -f haproxy.cfg -sf $(pidof haproxy)
>
> 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.
Yeah, that's not going to work as is with s6; you'll need workarounds.
It's a quite quirky way to proceed; generally, processes that want to
replace themselves do so by execve()ing into themselves when they get a
certain signal - so they keep the same pid, and it works transparently
with supervision.
Here, you spawn a different instance, and the pid changes, so you cannot
reuse the same service. However, you can use two services (a current one
and a backup one), and alternate between the two. It's more complex, but
it can be made to work. Here's how I would do it:
* have two services haproxy-1 and haproxy-2.
* have symbolic links haproxy-current and haproxy-alt (*not* in the
scandir); initially the former points to haproxy-1 and the latter points
to haproxy-2.
* Both services have the same run script: run by replacing the pid of
the service running as haproxy-current
* Have a distinct "restart-haproxy" script, that will be the only one
you execute manually when you want a haproxy restart. This script
- performs s6-svc -O on haproxy-current
- listens to haproxy-current then performs s6-svc -u on haproxy-alt
(use s6-svlisten1 for this)
- when haproxy-current is down, switches the symlinks so that the
"up" service is always named haproxy-current.
This setup will flip-flop between haproxy-1 and haproxy-2. Depending on
how haproxy reacts to being given an invalid pid to replace, you may need
to specialcase the first start (at boot time) in the haproxy-1 run script.
--
Laurent
Received on Tue May 17 2016 - 01:00:58 UTC