X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=man%2Fdaemon.xml;h=d5a8491850aa21c53ef4e705a36d0883e9dde764;hp=8e9e9395321c657a6f6c85ca802f1d4473843b9d;hb=bccc1d8859175f0927652d694796892c9e9c21d6;hpb=72f957066d9ccc43699c813d0498fc7f6732a838 diff --git a/man/daemon.xml b/man/daemon.xml index 8e9e93953..d5a849185 100644 --- a/man/daemon.xml +++ b/man/daemon.xml @@ -115,7 +115,7 @@ In the child, call fork() again, to - ensure the daemon can never re-aquire + ensure the daemon can never re-acquire a terminal again. Call exit() in the @@ -384,7 +384,7 @@ communication channels are established already, and no request is lost because client requests will be queued by the bus system (in case of D-Bus) or the kernel (in - case of sockets), until the activation + case of sockets), until the activation is completed. @@ -397,7 +397,7 @@ url="http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB Linux Standard Base Core Specification. This method of - activation is supported ubiquitiously on Linux + activation is supported ubiquitously on Linux init systems, both old-style and new-style systems. Among other issues SysV init scripts have the disadvantage of involving shell @@ -449,7 +449,7 @@ activation of daemons. However, the primary advantage of this scheme is that all providers and all consumers of the sockets can be - started in parallel as soon als all sockets + started in parallel as soon as all sockets are established. In addition to that daemons can be restarted with losing only a minimal number of client transactions or even any @@ -543,10 +543,10 @@ the hardware of the respective kind is plugged in or otherwise becomes available. In a new-style init system it is possible to bind - activation to hardware plug/unplug events. In systemd, - kernel devices appearing in the sysfs/udev - device tree can be exposed as units if they - are tagged with the string + activation to hardware plug/unplug events. In + systemd, kernel devices appearing in the + sysfs/udev device tree can be exposed as units + if they are tagged with the string "systemd". Like any other kind of unit they may then pull in other units when activated (i.e. Plugged in) and thus @@ -570,8 +570,9 @@ bluetoothd.service via controlling a bluetooth.target.wants/ - symlink uniformly with a tool like - systemd-install1 + symlink uniformly with a command like + enable of + systemctl1 instead of manipulating the udev ruleset. @@ -643,7 +644,7 @@ to the CPU and IO schedulers. If a process executed by the init system shall not negatively impact the amount of CPU or IO - bandwith available to other processes, it + bandwidth available to other processes, it should be configured with CPUSchedulingPolicy=idle and/or @@ -678,7 +679,8 @@ If your daemon registers a D-Bus name on the bus, make sure to use - Type=dbus if + Type=dbus in the + service file if possible. Make sure to set a @@ -703,16 +705,45 @@ operating system-independent. + Since not all syslog + implementations are socket-activatable + yet, it is recommended to place an + After=syslog.target + dependency in service files for + daemons that can log to + syslog. syslog.target + then either pulls in the syslog daemon + itself or simply the activation + socket. A Wants= or + even Requires= + dependency should generally not be + added, since it should be up to the + administrator whether he wants to + enable logging or not, and most syslog + clients work fine if no log daemon is + running. + Make sure to include - an [Install] section including - installation information for the unit - file. See + an [Install] + section including installation + information for the unit file. See systemd.unit5 for details. To activate your service on boot make sure to add a WantedBy=multi-user.target or - WantedBy=graphical.target directive. + WantedBy=graphical.target + directive. To activate your socket on + boot, make sure to add + WantedBy=sockets.target. Usually + you also want to make sure that when + your service is installed your socket + is installed too, hence add + Also=foo.socket in + your service file + foo.service, for + a hypothetical program + foo. @@ -726,19 +757,20 @@ install their systemd unit files in the directory returned by pkg-config systemd - --variable=systemdsystemnunitdir - (for system services), - resp. pkg-config systemd - --variable=systemdsessionunitdir - (for session services). This will make the + --variable=systemdsystemunitdir (for + system services), resp. pkg-config + systemd + --variable=systemduserunitdir + (for user services). This will make the services available in the system on explicit request but not activate them automatically during boot. Optionally, during package installation (e.g. rpm -i by the administrator) symlinks should be created in the systemd configuration - directories via the - systemd-install1 + directories via the enable + command of the + systemctl1 tool, to activate them automatically on boot. @@ -753,15 +785,17 @@ AC_ARG_WITH([systemdsystemunitdir], AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files]), [], [with_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)]) -AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir]) -AM_CONDITIONAL(HAVE_SYSTEMD, [test -n "$with_systemdsystemunitdir"]) +if test "x$with_systemdsystemunitdir" != xno; then + AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir]) +fi +AM_CONDITIONAL(HAVE_SYSTEMD, [test -n "$with_systemdsystemunitdir" -a "x$with_systemdsystemunitdir" != xno ]) This snippet allows automatic installation of the unit files on systemd machines, and optionally allows their installation even on machines lacking systemd. (Modification of this snippet for the - session unit directory is left as excercise to the + user unit directory is left as an exercise for the reader.) Additionally, to ensure that @@ -793,13 +827,64 @@ endif package managers: %post -/usr/bin/systemd-install --start enable foobar.service foobar.socket >/dev/null 2>&1 || : +if [ $1 -eq 1 ]; then + # On install (not upgrade), enable (but don't start) the + # units by default + /bin/systemctl enable foobar.service foobar.socket >/dev/null 2>&1 || : + + # Alternatively, just call + # /bin/systemctl daemon-reload >/dev/null 2>&1 || : + # here, if the daemon should not be enabled by default on + # installation +fi %preun -if [ "$1" -eq 0 ]; then - /usr/bin/systemd-install --start disable foobar.service foobar.socket >/dev/null 2>&1 || : +if [ $1 -eq 0 ]; then + # On uninstall (not upgrade), disable and stop the units + /bin/systemctl --no-reload disable foobar.service foobar.socket >/dev/null 2>&1 || : + /bin/systemctl stop foobar.service foobar.socket >/dev/null 2>&1 || : +fi + +%postun +# Reload init system configuration, to make systemd honour changed +# or deleted unit files +/bin/systemctl daemon-reload >/dev/null 2>&1 || : +if [ $1 -ge 1 ] ; then + # On upgrade (not uninstall), optionally, restart the daemon + /bin/systemctl try-restart foobar.service >/dev/null 2>&1 || : +fi + + Depending on whether your service should + or should not be started/stopped/restarted + during package installation, deinstallation or + upgrade, a different set of commands may be + specified. See + systemctl1 + for details. + + To facilitate upgrades from a package + version that shipped only SysV init scripts to + a package version that ships both a SysV init + script and a native systemd service file, use + a fragment like the following: + + %triggerun -- foobar < 0.47.11-1 +if /sbin/chkconfig --level 5 foobar ; then + /bin/systemctl --no-reload enable foobar.service foobar.socket >/dev/null 2>&1 || : fi + Where 0.47.11-1 is the first package + version that includes the native unit + file. This fragment will ensure that the first + time the unit file is installed it will be + enabled if and only if the SysV init script is + enabled, thus making sure that the enable + status is not changed. Note that + chkconfig is a command + specific to Fedora which can be used to check + whether a SysV init script is enabled. Other + operating systems will have to use different + commands here. @@ -809,8 +894,8 @@ fi Since new-style init systems such as systemd are compatible with traditional SysV init systems it is not strictly necessary to port existing daemons to the - new style. However doing this offers additional - functionality to the daemons as well as it simplifies + new style. However doing so offers additional + functionality to the daemons as well as simplifying integration into new-style init systems. To port an existing SysV compatible daemon the @@ -849,7 +934,7 @@ fi left-over file descriptors are passed to executed processes, it might be a good choice to simply skip the closing of all remaining - open file descriptors if file descriptors are + open file descriptors if sockets are passed. Write and install a systemd @@ -870,7 +955,6 @@ fi See Also systemd1, - systemd-install1, sd-daemon7, sd_listen_fds3, sd_notify3,