haproxy/contrib/systemd/haproxy.service.in

[Unit]
Description=HAProxy Load Balancer
After=network.target

[Service]
# You can point the environment variable HAPROXY_STATS_SOCKET to a stats
# socket if you want seamless reloads.
Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid"
ExecStartPre=@SBINDIR@/haproxy -f $CONFIG -c -q
ExecStart=@SBINDIR@/haproxy -Ws -f $CONFIG -p $PIDFILE
ExecReload=@SBINDIR@/haproxy -f $CONFIG -c -q
ExecReload=/bin/kill -USR2 $MAINPID
KillMode=mixed
Restart=always
Type=notify

[Install]
WantedBy=multi-user.target
MEDIUM: add systemd service Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com> 2013-02-13 08:28:50 +00:00			`[Unit]`
			`Description=HAProxy Load Balancer`
			`After=network.target`

			`[Service]`
MINOR: systemd wrapper: add support for passing the -x option. Make the systemd wrapper chech if HAPROXY_STATS_SOCKET if set. If set, it will use it as an argument to the "-x" option, which makes haproxy asks for any listening socket, on the stats socket, in order to achieve reloads with no new connection lost. 2017-04-09 14:28:10 +00:00			`# You can point the environment variable HAPROXY_STATS_SOCKET to a stats`
			`# socket if you want seamless reloads.`
MINOR: systemd: Use variable for config and pidfile paths Users can set the location of haproxy.cfg and pidfile files by providing a systemd overwrite file /etc/systemd/system/haproxy.service.d/overwrite.conf with the following content: [Service] Environment=CONFIG=/etc/foobar/haproxy.cfg 2016-06-14 11:28:20 +00:00			`Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid"`
			`ExecStartPre=@SBINDIR@/haproxy -f $CONFIG -c -q`
MEDIUM: mworker: Add systemd `Type=notify` support This patch adds support for `Type=notify` to the systemd unit. Supporting `Type=notify` improves both starting as well as reloading of the unit, because systemd will be let known when the action completed. See this quote from `systemd.service(5)`: > Note however that reloading a daemon by sending a signal (as with the > example line above) is usually not a good choice, because this is an > asynchronous operation and hence not suitable to order reloads of > multiple services against each other. It is strongly recommended to > set ExecReload= to a command that not only triggers a configuration > reload of the daemon, but also synchronously waits for it to complete. By making systemd aware of a reload in progress it is able to wait until the reload actually succeeded. This patch introduces both a new `USE_SYSTEMD` build option which controls including the sd-daemon library as well as a `-Ws` runtime option which runs haproxy in master-worker mode with systemd support. When haproxy is running in master-worker mode with systemd support it will send status messages to systemd using `sd_notify(3)` in the following cases: - The master process forked off the worker processes (READY=1) - The master process entered the `mworker_reload()` function (RELOADING=1) - The master process received the SIGUSR1 or SIGTERM signal (STOPPING=1) Change the unit file to specify `Type=notify` and replace master-worker mode (`-W`) with master-worker mode with systemd support (`-Ws`). Future evolutions of this feature could include making use of the `STATUS` feature of `sd_notify()` to send information about the number of active connections to systemd. This would require bidirectional communication between the master and the workers and thus is left for future work. 2017-11-20 14:58:35 +00:00			`ExecStart=@SBINDIR@/haproxy -Ws -f $CONFIG -p $PIDFILE`
MINOR: systemd: Perform sanity check on config before reload 2016-06-15 08:20:31 +00:00			`ExecReload=@SBINDIR@/haproxy -f $CONFIG -c -q`
MEDIUM: add systemd service Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com> 2013-02-13 08:28:50 +00:00			`ExecReload=/bin/kill -USR2 $MAINPID`
BUG/MEDIUM: systemd: set KillMode to 'mixed' By default systemd will send SIGTERM to all processes in the service's control group. In our case, this includes the wrapper, the master process and all worker processes. Since commit c54bdd2a the wrapper actually catches SIGTERM and survives to see the master process getting killed by systemd and regard this as an error, placing the unit in a failed state during "systemctl stop". Since the wrapper now handles SIGTERM by itself, we switch the kill mode to 'mixed', which means that systemd will deliver the initial SIGTERM to the wrapper only, and if the actual haproxy processes don't exit after a given amount of time (default: 90s), a SIGKILL is sent to all remaining processes in the control group. See systemd.kill(5) for more information. This should also be backported to 1.5. 2014-10-08 12:14:41 +00:00			`KillMode=mixed`
MEDIUM: add systemd service Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com> 2013-02-13 08:28:50 +00:00			`Restart=always`
MEDIUM: mworker: Add systemd `Type=notify` support This patch adds support for `Type=notify` to the systemd unit. Supporting `Type=notify` improves both starting as well as reloading of the unit, because systemd will be let known when the action completed. See this quote from `systemd.service(5)`: > Note however that reloading a daemon by sending a signal (as with the > example line above) is usually not a good choice, because this is an > asynchronous operation and hence not suitable to order reloads of > multiple services against each other. It is strongly recommended to > set ExecReload= to a command that not only triggers a configuration > reload of the daemon, but also synchronously waits for it to complete. By making systemd aware of a reload in progress it is able to wait until the reload actually succeeded. This patch introduces both a new `USE_SYSTEMD` build option which controls including the sd-daemon library as well as a `-Ws` runtime option which runs haproxy in master-worker mode with systemd support. When haproxy is running in master-worker mode with systemd support it will send status messages to systemd using `sd_notify(3)` in the following cases: - The master process forked off the worker processes (READY=1) - The master process entered the `mworker_reload()` function (RELOADING=1) - The master process received the SIGUSR1 or SIGTERM signal (STOPPING=1) Change the unit file to specify `Type=notify` and replace master-worker mode (`-W`) with master-worker mode with systemd support (`-Ws`). Future evolutions of this feature could include making use of the `STATUS` feature of `sd_notify()` to send information about the number of active connections to systemd. This would require bidirectional communication between the master and the workers and thus is left for future work. 2017-11-20 14:58:35 +00:00			`Type=notify`
MEDIUM: add systemd service Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com> 2013-02-13 08:28:50 +00:00
			`[Install]`
			`WantedBy=multi-user.target`