Hi, Currently, to reload haproxy configuration, you have to use "-sf".
Systemd philosophy is for the daemon not to fork by themselves, but rather let the init process do it for them. My first patch adds a new option "-Ds" which is exactly like "-D", but instead of forking n times to get n jobs running and then exiting, prefers to wait for all the children it just created. With this done, haproxy becomes more systemd-compliant, without changing anything for other systems. Now comes a problem with the "-sf" way to do things. First of all, in the systemd world, reload commands should be "oneshot" ones, which means they should not be the new main process but rather a tool which makes a call to it and then exits. With the current approach, the reload command is the new main command and moreover, it makes the previous one exit. Systemd only tracks the main program, seeing it ending, it assumes it either finished or failed, and kills everything remaining as a grabage collector. We then end up with no haproxy running at all. My second patch is a wrapper around haproxy, no changes at all have been made into it, so it's not intrusive and doesn't change anything for other hosts. What this wrapper does is basically launching haproxy as a child, listen to the SIGUSR2 (not to conflict with haproxy itself) signal, and spawing a new haproxy with "-sf" as a child to relay the first one. The third patch is a logical continuation to the two first ones, providing a systemd service file.
