daemon 中文手册

传统的SysV守护进程¶

传统的SysV 守护进程 在启动的时候， 应该在初始化阶段 执行下面的步骤：

注意，这些步骤对于下文讲述的新型守护进程是不需要的， 除非为了刻意兼容传统的SysV系统。

新型守护进程¶

Linux 系统上的新型守护进程更容易被监控也更容易实现。 守护进程无需实现前文所描述的复杂步骤， 即可直接在 systemd 提供的干净的上下文环境中运行：

环境变量已经被清理、信号处理器与信号掩码已经被重置、 没有遗留的文件描述符、守护进程自动在其专属的会话中执行、 标准输入(STDIN)已被连接到 /dev/null 虚拟设备(除非另有配置)、 标准输出(STDOUT)与标准错误(STDERR)已被连接到 systemd-journald.service(8) 日志服务(除非另有配置)、umask 已经被重置 … 等等

新型守护进程 只需要遵守如下要求：

上述要求与 Apple MacOS X Daemon Requirements 类似， 但并不完全相同。

系统启动时启动¶

传统的守护进程一般是在系统启动时通过SysV初始化脚本自动启动， systemd 也支持这种启动方式。 对于 systemd 来说，如果希望确保某单元在系统启动时自动启动， 那么最佳的做法是在默认启动目标 (通常是 multi-user.target 或 graphical.target)的 .wants/ 目录中为该单元建立软链接。 参见 systemd.unit(5) 手册以了解 .wants/ 目录， 参见 systemd.special(7) 手册以了解上述两个特殊的启动目标。

基于套接字的启动¶

为了尽可能提高并行性与健壮性， 以及简化配置与开发， 对于需要监听套接字的服务， 强烈推荐使用基于套接字的启动机制。 使用此机制后， 守护进程不再需要创建和绑定套接字， 而是由 systemd 接管这个工作。 systemd 将会根据单元文件的设置， 预先创建所需的套接字， 并在第一个客户端请求接入的时候 启动该服务， 以实现服务的按需启动。 该机制的好处还在于， 预先创建好套接字之后， 所有使用此套接字通信的进程可以并行启动(包括客户端和服务端)。 此外，重启服务只会导致丢失最低限度的客户端连接， 甚至不丢失任何客户端请求 (例如对于 DNS 或 syslog 这样的无状态协议)。 因为套接字在服务重启期间 始终保持有效并且可被访问， 同时所有客户端请求 也都被排入队列等候处理。

使用此机制之后， 守护进程必须要从 systemd 接收已创建好的套接字， 而不能自己创建并绑定套接字。 关于如何使用该机制，参见 sd_listen_fds(3) 与 sd-daemon(3) 手册。 只需要小小的修改， 即可在原有启动机制的基础上 添加基于套接字的启动机制， 至于如何移植， 详见后文。

systemd 通过 .socket 单元实现该机制，详见 systemd.socket(5) 手册。 必须确保所有为支持基于套接字启动而创建的监听 socket 单元都被包含在 sockets.target 中。 建议在 socket 单元的 "[Install]" 小节加入 WantedBy=sockets.target 设置， 以确保在启用该单元时能够自动添加上述依赖关系。 除非明确设置了 DefaultDependencies=no ， 否则会为所有 socket 单元隐含的创建必要的顺序依赖。 有关 sockets.target 的解释，详见 systemd.special(7) 手册。 如果某 socket 单元已被包含在 sockets.target 中， 那么不建议在其中再添加任何额外的依赖关系(例如 multi-user.target 之类)。

基于 D-Bus 的启动¶

如果守护进程使用 D-Bus 与客户端通信， 那么它应该使用基于 D-Bus 的启动机制， 这样当客户端访问其 D-Bus 接口时，该服务将被自动启动。 该机制是通过 D-Bus service 文件实现的(不要与普通的单元文件混淆)。 为了确保让 D-Bus 使用 systemd 来启动与维护守护进程， 必须在这些 D-Bus service 文件中使用 SystemdService= 指明其匹配的服务单元。 例如，对于文件名为 org.freedesktop.RealtimeKit.service 的 D-Bus service 来说， 为了将其绑定到 rtkit-daemon.service 服务单元， 必须确保在该文件中设置了 SystemdService=rtkit-daemon.service 指令。 注意，必须明确设置 SystemdService= 指令， 否则当服务单元同时使用多种启动机制时， 可能会导致竞争条件的出现。

基于设备的启动¶

用于管理特定类型硬件的守护进程， 只应该在符合条件的硬件变为可用或者被插入时， 才需要启动。 为了达到上述目的， 可以将服务的启动/停止与硬件的插入/拔出事件绑定。 当带有 "systemd" 标签的设备出现在 sysfs/udev 设备树中时， systemd 将会自动为其创建对应的 device 单元。 通过向这些单元中添加对其他单元的 Wants= 依赖， 就可以实现当该 device 单元被启动(也就是硬件被插入)时， 连带启动其他单元，从而实现基于设备的启动。 这可以通过向 udev 规则库中添加 SYSTEMD_WANTS= 属性来实现， 详见 systemd.device(5) 手册。 通常，并不是将 service 单元直接添加到设备的 Wants= 依赖中， 而是通过专用的 target 单元间接添加。 例如，不是将 bluetoothd.service 添加到各种蓝牙设备的 Wants= 依赖中， 而是将 bluetoothd.service 添加到 bluetooth.target 的 Wants= 依赖中， 同时再将 bluetooth.target 添加到各种蓝牙设备的 Wants= 依赖中。 通过引入 bluetooth.target 这个抽象层， 系统管理员无需批量修改 udev 规则库， 仅通过 systemctl enable|disable … 命令 修改 bluetooth.target.wants/ 目录中的软链接， 即可控制 bluetoothd.service 的使用。

基于路径的启动¶

对于处理 spool 文件或目录的 守护进程(例如打印服务)来说， 仅在 spool 文件或目录状态发生变化或者内容非空时， 才需要启动。 通过 .path 单元实现的、 基于路径的启动机制正好适用于这种场合， 详见 systemd.path(5) 手册。

基于定时器的启动¶

对于周期性的操作 (例如垃圾文件清理或者网络对时)， 可以通过基于定时器的启动机制来实现。 这种机制通过 .timer 单元实现，详见 systemd.timer(5) 手册。

其他启动方式¶

在其他操作系统上还存在着其他的启动机制， 不过这些机制都可以被前述的各种机制的组合替代。因此在这里不再赘述。

编写 systemd 单元文件¶

在编写单元文件时 应当考虑下列建议：

安装 service 单元文件¶

当从源代码编译安装(make install)软件包时， 其中的系统服务单元文件会被默认安装到 pkg-config systemd --variable=systemdsystemunitdir 命令返回的目录中(通常是 /usr/lib/systemd/system)； 而其中的用户服务单元文件会被默认安装到 pkg-config systemd --variable=systemduserunitdir 命令返回的目录中(通常是 /usr/lib/systemd/user)； 但并不应该使用 systemctl enable … 命令启用它们。 当从包管理器安装(rpm -i)二进制软件包时， 其中的单元文件应该同样安装到上述位置。 但不同之处在于， 还应该使用 systemctl enable … 命令启用它们， 因此安装的单元 有可能会在开机时自动启动。

使用 autoconf(1) 的软件包可以在源代码配置期间 使用包含类似如下片段的配置脚本 来确定 单元文件的安装路径：

PKG_PROG_PKG_CONFIG
AC_ARG_WITH([systemdsystemunitdir],
     [AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],,
     [with_systemdsystemunitdir=auto])
AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [
     def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)

     AS_IF([test "x$def_systemdsystemunitdir" = "x"],
   [AS_IF([test "x$with_systemdsystemunitdir" = "xyes"],
    [AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])])
    with_systemdsystemunitdir=no],
   [with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
AS_IF([test "x$with_systemdsystemunitdir" != "xno"],
      [AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])

无论系统中 是否存在 systemd ， 上述配置片段都允许自动安装单元文件。 (上述配置片段中 并不包含用户单元目录， 怎样修改以加入用户单元目录， 就留给读者作为练习题吧)

为了确保 make distcheck 正常工作， 建议将下面的内容添加到 automake(1) 项目顶层目录的 Makefile.am 文件中：

AM_DISTCHECK_CONFIGURE_FLAGS = \
  --with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)

最后，应该使用类似下面的 automake 配置片段来安装单元文件：

if HAVE_SYSTEMD
systemdsystemunit_DATA = \
  foobar.socket \
  foobar.service
endif

在 rpm(8) .spec 文件中， 可以使用下面的配置片段在安装/卸载时启用/禁用服务单元。 这个示例中使用了由 systemd 提供的 RPM 宏。 对于非红帽系的其他发行版， 请阅读相应的打包指南， 以详细了解其软件包管理器的相应等价替代。

在文件头部：

BuildRequires: systemd
%{?systemd_requires}

下面是脚本：

%post
%systemd_post foobar.service foobar.socket

%preun
%systemd_preun foobar.service foobar.socket

%postun
%systemd_postun

如果在软件包升级时需要重启服务， 应该将上面的 "%postun" 脚本 替换为：

%postun
%systemd_postun_with_restart foobar.service

注意， "%systemd_post" 与 "%systemd_preun" 的参数是将被安装/卸载的单元名称列表(空格分隔)。 "%systemd_postun" 不需要参数。 "%systemd_postun_with_restart" 的参数是将被重启的单元名称列表(空格分隔)。

若想 从只附带 SysV init 脚本的老版本软件包升级到 同时附带 SysV init 脚本与原生 systemd 服务单元的新版本软件包， 可以使用类似下面的片段：

%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

本例中的 0.47.11-1 是第一个包含原生服务单元的版本号。 上述片段保证了首次安装单元文件时， 当且仅当原有的 SysV init 脚本已被启用的情况下， 新的原生服务单元才会被启用， 这样就确保了版本升级不会破坏服务的启用/禁用状态。注意， chkconfig 是红帽系发行版专有的命令， 用于检查 SysV init 脚本是否被启用。 其他发行版一般也都有自己专属的 功能类似的命令。