Hi Bharat,
On 02/24/2016 03:04 AM, BR Kumar wrote:
> Couple of questions related to the systemd wrapper:
>
> 1) I noticed that it spawns a 2 level hierarchy of haproxy processes
> instead of a single child process. Can someone help understand why?
It's a little complex, but I can try:
It is probably easier to understand when thinking about a scenario where
nbproc is > 1, let's say 4. When running under supervision of systemd (or
any other service manager, e.g. runit), you need a single application
process that does not daemonize. Systemd monitors this process to e.g. to
restart it if it dies. But most service managers are designed to supervise
one process per service. So if we want 4 processes, the application itself
has to manage this. This is why you would see a process hierarchy like this:
systemd
L haproxy-systemd-wrapper
L haproxy
L haproxy \
L haproxy } nbproc processes
L haproxy }
L haproxy /
Now, you might say, but there is already the systemd-wrapper , why do we
need the one additional haproxy instance? It is related to the special
(carefully designed) restart mechanism that haproxy implements. Going into
details would make this a pretty long mail, but the gist it that _all_
haproxy process will be replaced by new ones in the process, including the
parent one. Thus, the moment that the parent process were to exit, systemd
would think the service needs to be restarted and fire up yet another
instance of haproxy (even though there is already a replacement, but
systemd doesn't know about it). So the sole purpose of the wrapper is to
prevent systemd from interfering with th restart mechanism implement in the
application itself, basically.
Sorry, this leaves out a lot of details, but I hope it does make a little
sense.
> 2) The problem arises when the intermediate haproxy process dies for any
> reason and the child process is adopted by pid 1. When the systemd wrapper
> is restarted, this results in a total of 3 haproxy processes. Is this
> behavior expected? Are there fixes/workaround to ensure that only
> systemd-wrapper controlled processes are retained?
This is intentional. The restart mechanism is designed to not interrupt
existing connections. As such, the child processes will be detached from
their parent, keep running until all connections they are processing are
closed by the client side and then exit.
Cheers,
Conrad
--
Conrad Hoffmann
Traffic Engineer
SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany
Managing Director: Alexander Ljung | Incorporated in England & Wales
with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
HRB 110657B
