On Mon, 16 May 2016 23:50:04 +0200 Remko Tronçon <[email protected]> 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 do. 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. eto
