Skip to content
Snippets Groups Projects
Commit 023b92a4 authored by Daniel Kahn Gillmor's avatar Daniel Kahn Gillmor
Browse files

update documentation to explain systemd socket-activation configuration

parent ed62cc88
Branches
Tags
No related merge requests found
......@@ -111,6 +111,10 @@ With this option, the daemon is started in non-interactive mode and instead crea
UNIX socket in \fIrundir\fR that the operator can connect to for interactive session.
A number greater than 1 forks the daemon N times, all forks will bind to same addresses
and the kernel will load-balance between them on Linux with \fISO_REUSEPORT\fR support.
When socket-activated and supervised by systemd or the equivalent, kresd defaults to
--forks=1, and must not be set to any other value. If you want multiple concurrent
processes supervised in this way, they should be supervised independently.
.TP
.B \-q\fR, \fB\-\-quiet
Daemon will refrain from printing any informative messages, not even a prompt.
......
[Unit]
Description=Knot DNS Resolver daemon
After=network.target
[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/kresd
ExecStart=/usr/sbin/kresd -c /etc/kresd/config -f $KRESD_WORKERS $KRESD_OPTIONS /var/lib/kresd/
Restart=on-abort
[Install]
WantedBy=multi-user.target
## Path: System/DNS
## Description: Number of worker processes to spawn
## Type: integer
## Default: 1
## ServiceRestart: kresd
##
#
# Number of workers to spawn for kresd.
# If you get start up failures with "already in use" your libuv is too
# old and you have to stick to 1.
#
KRESD_WORKERS=1
# Additional options
KRESD_OPTIONS=
Running Knot Resolver under systemd (or equivalent) socket activation
=====================================================================
You can use the files in this directory to run kresd under supervision
by systemd (or any supervisor that provides equivalent file descriptor
initialization via the interface supported by
sd_listen_fds_with_names(3)).
When run in this configuration:
* it will be run under a non-privileged user, which means it will not
be able to open any new non-privileged ports.
* it will use a single process (implicitly uses --forks=1, and will
fail if that configuration variable is set to a different value).
If you want multiple daemons to listen on these ports publicly
concurrently, you'll need the supervisor to manage them
differently, for example via a systemd generator:
https://www.freedesktop.org/software/systemd/man/systemd.generator.html
If you have a useful systemd generator for multiple concurrent
processes, please contribute it upstream!
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment