Путеводитель по Руководству Linux
  User  |  Syst  |  Libr  |  Device  |  Files  |  Other  |  Admin  |  Head  |


   daemon    ( 7 )

написание и упаковка системных демонов (Writing and packaging system daemons)
  Name  |  Description  |  Activation  |  Integration with systemd  |    Porting existing daemons    |  Placing daemon data  |  See also  |  Note  |

PORTING EXISTING DAEMONS

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 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 following steps are recommended:

1. If not already implemented, add an optional command line switch to the daemon to disable daemonization. This is useful not only for using the daemon in new-style init systems, but also to ease debugging.

2. If the daemon offers interfaces to other software running on the local system via local AF_UNIX sockets, consider implementing socket-based activation (see above). Usually, a minimal patch is sufficient to implement this: Extend the socket creation in the daemon code so that sd_listen_fds(3) is checked for already passed sockets first. If sockets are passed (i.e. when sd_listen_fds() returns a positive value), skip the socket creation step and use the passed sockets. Secondly, ensure that the file system socket nodes for local AF_UNIX sockets used in the socket-based activation are not removed when the daemon shuts down, if sockets have been passed. Third, if the daemon normally closes all remaining open file descriptors as part of its initialization, the sockets passed from the init system must be spared. Since new-style init systems guarantee that no 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 sockets are passed.

3. Write and install a systemd unit file for the service (and the sockets if socket-based activation is used, as well as a path unit file, if the daemon processes a spool directory), see above for details.

4. If the daemon exposes interfaces via D-Bus, write and install a D-Bus activation file for the service, see above for details.