RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
haproxy/contrib/systemd/haproxy.service.in

36 lines
1.2 KiB
SYSTEMD
Raw Normal View History

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: 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
MINOR: systemd: consider exit status 143 as successful The master process will exit with the status of the last worker. When the worker is killed with SIGTERM, it is expected to get 143 as an exit status. Therefore, we consider this exit status as normal from a systemd point of view. If it happens when not stopping, the systemd unit is configured to always restart, so it has no adverse effect. This has mostly a cosmetic effect. Without the patch, stopping HAProxy leads to the following status: ● haproxy.service - HAProxy Load Balancer Loaded: loaded (/lib/systemd/system/haproxy.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2018-06-22 20:35:42 CEST; 8min ago Docs: man:haproxy(1) file:/usr/share/doc/haproxy/configuration.txt.gz Process: 32715 ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE $EXTRAOPTS (code=exited, status=143) Process: 32714 ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS (code=exited, status=0/SUCCESS) Main PID: 32715 (code=exited, status=143) After the patch: ● haproxy.service - HAProxy Load Balancer Loaded: loaded (/lib/systemd/system/haproxy.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:haproxy(1) file:/usr/share/doc/haproxy/configuration.txt.gz
2018-06-22 18:57:03 +00:00
SuccessExitStatus=143
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
MINOR: systemd: Add section for SystemD sandboxing to unit file This commit adds a warning for settings that possibly provide better sandboxing and explains their tradeoffs.
2018-02-27 19:19:03 +00:00
# The following lines leverage SystemD's sandboxing options to provide
# defense in depth protection at the expense of restricting some flexibility
# in your setup (e.g. placement of your configuration files) or possibly
# reduced performance. See systemd.service(5) and systemd.exec(5) for further
# information.
MINOR: systemd: Add SystemD's Protect*= options to the unit file While the haproxy workers usually are running chrooted the master process is not. This patch is a pretty safe defense in depth measure to ensure haproxy cannot touch sensitive parts of the file system. ProtectSystem takes non-boolean arguments in newer SystemD versions, but setting those would leave older systems such as Ubuntu Xenial unprotected. Distro maintainers and system administrators could adapt the ProtectSystem value to the SystemD version they ship.
2018-02-27 19:19:04 +00:00
# NoNewPrivileges=true
# ProtectHome=true
# If you want to use 'ProtectSystem=strict' you should whitelist the PIDFILE,
# any state files and any other files written using 'ReadWritePaths' or
# 'RuntimeDirectory'.
# ProtectSystem=true
# ProtectKernelTunables=true
# ProtectKernelModules=true
# ProtectControlGroups=true
MINOR: systemd: Add SystemD's SystemCallFilter option to the unit file This option takes away system calls that are unneeded for haproxy's operation and thus is a good defense in depth measure.
2018-02-27 19:19:05 +00:00
# If your SystemD version supports them, you can add: @reboot, @swap, @sync
# SystemCallFilter=~@cpu-emulation @keyring @module @obsolete @raw-io
MINOR: systemd: Add SystemD's Protect*= options to the unit file While the haproxy workers usually are running chrooted the master process is not. This patch is a pretty safe defense in depth measure to ensure haproxy cannot touch sensitive parts of the file system. ProtectSystem takes non-boolean arguments in newer SystemD versions, but setting those would leave older systems such as Ubuntu Xenial unprotected. Distro maintainers and system administrators could adapt the ProtectSystem value to the SystemD version they ship.
2018-02-27 19:19:04 +00:00
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