| |
@@ -22,7 +22,7 @@
|
| |
the upstream packages. Please consider working with upstream to integrate the
|
| |
systemd files you prepare in the upstream sources. Information for developers
|
| |
on how to integrate systemd support best with their build system you may find
|
| |
- on http://0pointer.de/public/systemd-man/daemon.html
|
| |
+ in https://www.freedesktop.org/software/systemd/man/daemon.html[daemon(8)].
|
| |
|
| |
==== Naming
|
| |
|
| |
@@ -67,9 +67,8 @@
|
| |
should be "dbus", for traditional services "forking" is usually a good idea,
|
| |
for services not offering any interfaces to other services "simple" is best.
|
| |
For "one-shot" scripts "oneshot" is ideal, often combined with
|
| |
- `+RemainAfterExit=+`. See
|
| |
- http://0pointer.de/public/systemd-man/systemd.service.html for further
|
| |
- discussion on the topic. Since "simple" is the default type,
|
| |
+ `+RemainAfterExit=+`. See https://www.freedesktop.org/software/systemd/man/systemd.service.html[systemd.service(5)]
|
| |
+ for further discussion on the topic. Since "simple" is the default type,
|
| |
`+.service+` files which would normally set `+Type=simple+` may simply
|
| |
omit the `+Type+` line altogether.
|
| |
|
| |
@@ -90,7 +89,7 @@
|
| |
|
| |
The recommended parameters for `+WantedBy=+` are either `+graphical.target+` (services related to the graphical user interface) or `+multi-user.target+` (for everything else). When the user (or our scriptlets) invoke `+systemctl enable+` the service will be set to start in these targets.
|
| |
|
| |
- For more information regarding these options see http://0pointer.de/public/systemd-man/systemd.unit.html and http://0pointer.de/public/systemd-man/systemd.service.html
|
| |
+ For more information regarding these options see https://www.freedesktop.org/software/systemd/man/systemd.unit.html[systemd.unit(5)] and https://www.freedesktop.org/software/systemd/man/systemd.service.html[systemd.service(5)].
|
| |
|
| |
==== EnvironmentFiles and support for /etc/sysconfig files
|
| |
|
| |
@@ -213,7 +212,7 @@
|
| |
SystemdService=console-kit-daemon.service
|
| |
....
|
| |
|
| |
- And the matching systemd unit file /lib/systemd/system/console-kit-daemon.service:
|
| |
+ And the matching systemd unit file /usr/lib/systemd/system/console-kit-daemon.service:
|
| |
|
| |
....
|
| |
[Unit]
|
| |
@@ -260,7 +259,7 @@
|
| |
Exec=/bin/false
|
| |
....
|
| |
|
| |
- Here is the Avahi systemd unit `+.service+` file (/lib/systemd/system/avahi-daemon.service):
|
| |
+ Here is the Avahi systemd unit `+.service+` file (/usr/lib/systemd/system/avahi-daemon.service):
|
| |
|
| |
....
|
| |
[Unit]
|
| |
@@ -308,7 +307,7 @@
|
| |
|
| |
in your unit's `+.service+` file for this.
|
| |
|
| |
- The former will tell systemd to restart the daemon as soon as it fails regardless of the precise reason. It's a good choice for most long-running services. Some daemons require a way to escape constant restarting by exiting with any non-zero exit code. For those services use `+Restart=on-abnormal+`, which will still restart the daemon when it fails "abnormally", on unclean signal, core dump, timeout or watchdog exits, but not on unclean exit codes. It is recommended to to enable automatic restarts for all long-running services, but which setting is the right one, and whether it is useful at all depends on the specific service. Please consult the `+systemd.service(5)+` man page for more information on the various settings.
|
| |
+ The former will tell systemd to restart the daemon as soon as it fails regardless of the precise reason. It's a good choice for most long-running services. Some daemons require a way to escape constant restarting by exiting with any non-zero exit code. For those services use `+Restart=on-abnormal+`, which will still restart the daemon when it fails "abnormally", on unclean signal, core dump, timeout or watchdog exits, but not on unclean exit codes. It is recommended to to enable automatic restarts for all long-running services, but which setting is the right one, and whether it is useful at all depends on the specific service. Please consult the https://www.freedesktop.org/software/systemd/man/systemd.service.html[systemd.service(5)] man page for more information on the various settings.
|
| |
|
| |
=== Private devices and networking
|
| |
|
| |
@@ -334,13 +333,13 @@
|
| |
* This also disconnects the AF_UNIX abstract namespace from the host (In case you wonder what this refers to: sockets listed in /proc/net/unix that start with an @ are in the abstract namespace, those which start in / are in the file system namespace). This means that services which listen or connect to AF_UNIX sockets in the abstract namespaces might break. AF_UNIX sockets in the file system continue to work correctly even with PrivateNetwork?=yes. We strongly recommend anyway to stop using abstract namespace AF_UNIX sockets, as they bring very little benefit these days. If your package uses them please consider moving them into the file system into a subdirectory in /run (system services) or $XDG_RUNTIME_DIR (user services).
|
| |
* This also disconnects the AF_NETLINK and AF_AUDIT socket families from the host. For services requiring auditing, that need to subscribe to network configuration changes, or want to subscribe to hardware devices coming and going (udev) PrivateNetwork?=yes cannot be used hence.
|
| |
|
| |
- For further details see the systemd.exec(5) man page.
|
| |
+ For further details see the https://www.freedesktop.org/software/systemd/man/systemd.exec.html[systemd.exec(5)] man page.
|
| |
|
| |
== Packaging
|
| |
|
| |
=== Filesystem locations
|
| |
|
| |
- Packages with systemd unit files *must* put them into `+%{_unitdir}+`. `+%{_unitdir}+` evaluates to /lib/systemd/system on all Fedora systems (F-15+). Unit files are architecture independent (hence, not `+%{_lib}+`) and needed early in the boot process.
|
| |
+ Packages with systemd unit files *must* put them into `+%{_unitdir}+`. `+%{_unitdir}+` evaluates to /usr/lib/systemd/system on all Fedora systems (F-15+). Unit files are architecture independent (hence, not `+%{_lib}+`) and needed early in the boot process.
|
| |
|
| |
Please note that in order for the `+%{_unitdir}+` macro to exist, your package must have:
|
| |
|
| |
As I have outlined in the mailing list, I think we should change to default to
%{?systemd_ordering}
and only suggest using%{?systemd_requires}
in cases where it's actually needed.