------------------------------------------------------------------------
*From:* Willy Tarreau [mailto:w...@1wt.eu]
*Sent:* Monday, April 29, 2019, 23:55 EDT
*To:* William Lallemand <wlallem...@haproxy.com>
*Cc:* Tim Düsterhus <t...@bastelstu.be>, Patrick Hemmer
<hapr...@stormcloud9.net>, haproxy@formilux.org
*Subject:* [PATCH] MINOR: systemd: Make use of master socket in systemd unit
On Tue, Apr 30, 2019 at 01:47:13AM +0200, William Lallemand wrote:
the systemd API
is limited and it's not possible to report a fail during a reload with
sd_notify.
Anyway a service manager which requires daemons to stay in foreground,
does not allow processes to be replaced, and relies on asynchronous and
unidirectional signal delivery to perform critical actions such as config
updates is obviously misdesigned and can only result from the lack of
experience of production servers and people making them work every day.
I tend to think that the only longterm solution to work around all the
systemd imposed mess is to have haproxy become its own service manager.
It is a shame as it significantly complicates haproxy management on Linux
compared to sane operating systems, but I'm having a hard time accepting
that haproxy has become less reliable on Linux due to systemd. We've
already made progress in this direction with the master-worker model,
but we need to go further and make haproxy be able to serve as a client
to talk to an existing master and return relevant status codes. This
way we'll be able to emulate the start/reload/restart operations that
are performed on sane systems and gain reliability again, at the
expense of using a total of 3 processes talking to each other during
a reload instead of just one. The advantage is that it should work on
other operating systems too if needed.
In my opinion this is something we seriously need to work on for 2.1,
and address remaining limitations (doubled memory usage and CLI being
closed on reload).
By the way, does systemd support passing actions on stdin and getting
the result on stdout ? Given that the master process is forced to
stay in foreground, at least we could have the equivalent of the CLI
on stdio used as a "console" and not require a third process to talk
to it.
Willy
Not to start a systemd flame war, but you can always tell systemd to
stop tracking the process, and you can then do whatever you want. Of
course you won't get automatic restarts if it dies, but that's how all
the other "sane operating systems" behave.
Just add to the service file:
Type=oneshot
RemainAfterExit=yes
Assuming we don't do that, and going back to the original issue at hand
of putting the master socket in the systemd unit: do we want to do this?
From all the discussion, whether or not we add a `haproxy reload`
command to the haproxy binary, it still seems like we will need master
socket support to make it work. So should this patch be adopted?
-Patrick
