Documentation for systemd service files can be automatically viewed
using systemctl help servicename if this field is present. Thus add the
relevant man page, the local and online documentation to the
documentation key.
On systems where you have both services, salt-master and salt-minion,
enabled, you want that salt-minion.service starts after
salt-master.service so that the minion will be able to connect to the
master on first attempt.
When systemd-python is not installed, systemd notification falls back to
using the systemd-notify for service notification. This cannot be used
however unless the unit has NotifyAccess=all set.
The particular use case for this is when Salt is installed using pip. We
don't put systemd-python into the requirements.txt because we can't be
sure that the minion supports systemd, so pip installs won't necessarily
have systemd-python available.
Declaring After=syslog.target is unnecessary by now because syslog is
socket-activated and will therefore be started when needed. Thus remove
the obsolete syslog.target from the systemd service files.
Fixes#22993.
The change is only made for the minion process because, theoretically,
only the minion could create the problem described. salt-master and
salt-syndic do not theoretically spawn non-salt processes during the
lifetime of their processes, whereas salt-minion does this by design.
The default behavior for systemd killMode seems to be control-group,
which means all processes that share the same control group as the
minion process will also be killed by systemd when the minion service is
stopped (killed).
It is reasonable to expect that activity done on a system by a salt
minion should persist beyond the lifetime of the minion process, so
let's not kill procs that the minion starts even when the minion exits.
Since service files might be used by many distros (arch, rpm-based,
gentoo, mindriva, mageia) I think it would be useful to symlink to
standard ones (and copy and edit them if differences are needed).
