This patch has been verified using systemd 229 on Ubuntu 16.04. I've
tested the following cases:
- haproxy properly sends READY=1 to systemd (because otherwise the unit
would not have been marked as running in systemd).
- haproxy properly sends RELOADING=1 to systemd (by removing the READY=1
I could verify that haproxy was stuck in the reloading state in systemd).
- haproxy properly sends STOPPING=1 to systemd (sending the signal to haproxy
manually by using kill(1) properly updated the status in haproxy, while it
did not when removing that status message).
Note: Using the modified unit file and *not* building haproxy with
USE_SYSTEMD=1 will cause issues, as systemd waits for the READY=1
message that will never arrive. This might need to be documented.
If this patch is *not* going to be merged then the commit
6db884d96158aa25b95131986c6db8ad2d987734 [1] should be reviewed
again. The systemd documentation states:
> If set to forking, it is expected that the process configured with
> ExecStart= will call fork() as part of its start-up. The parent
> process is expected to exit when start-up is complete and all
> communication channels are set up. The child continues to run as
> the main daemon process. This is the behavior of traditional UNIX
> daemons. If this setting is used, it is recommended to also use the
> PIDFile= option, so that systemd can identify the main process of
> the daemon. systemd will proceed with starting follow-up units as
> soon as the parent process exits.
The -D option is not specified in the unit file, though. When `daemon`
is not specified in the haproxy.cfg then the start up might be delayed,
because systemd won't start any follow-up units until the process exits.
[1]
http://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=6db884d96158aa25b95131986c6db8ad2d987734
