精通 Systemd：创建您的第一个自定义服务单元文件

Systemd 已成为现代 Linux 发行版中无处不在的服务管理器，负责管理从系统启动初始化到处理正在运行的用户空间服务的所有事务。了解如何编写自定义单元文件是自动化应用程序部署、确保服务正确重启以及将定制流程无缝集成到操作系统生命周期的基础。

本综合指南将引导您了解 Systemd 服务单元文件的基本结构，涵盖关键的 [Unit]、[Service] 和 [Install] 部分。完成本教程后，您将能够定义、启用和管理自己的自定义服务。

先决条件

在深入研究配置之前，请确保您具有管理权限（sudo）并对 Linux 文件系统有基本的了解。本指南假设您正在使用 Systemd 的现代发行版（例如 Debian、Ubuntu、Fedora、CentOS 7+/RHEL 7+）。

理解 Systemd 单元文件

A Systemd 单元文件是 INI 样式的配置文件，用于描述由 Systemd 管理的资源。对于服务，这些文件通常位于 /etc/systemd/system/（用于自定义或管理员定义的服务），或位于 /lib/systemd/system/（用于供应商提供的服务）。

服务单元文件必须以 .service 扩展名结尾（例如 mydaemon.service）。结构分为必需和可选部分，其中最关键的三个是 [Unit]、[Service] 和 [Install]。

步骤 1：创建服务脚本（可执行文件）

在创建单元文件之前，我们需要一个由服务管理的简单脚本或应用程序。在此示例中，我们将创建一个每 10 秒记录一条消息的基本脚本。

1. 创建脚本目录和文件：

   bash sudo mkdir -p /opt/my-custom-service sudo nano /opt/my-custom-service/reporter.sh

2. 将以下内容添加到 reporter.sh：

   ```bash

   !/bin/bash

   LOG_FILE="/var/log/reporter.log"
   while true; do
   echo "$(date +'%Y-%m-%d %H:%M:%S') - Custom service heartbeat active." >> $LOG_FILE
   sleep 10
   done
   ```

3. 使脚本可执行：

   bash sudo chmod +x /opt/my-custom-service/reporter.sh

步骤 2：定义自定义服务单元文件

现在，我们创建 Systemd 单元文件，告知 Systemd 如何 运行我们的脚本。

1. 创建服务文件：

   bash sudo nano /etc/systemd/system/my-reporter.service

2. 用标准部分填充文件：

[Unit] 部分

此部分包含有关服务的元数据，并定义其与其他单元（服务、套接字、挂载点等）的关系。

• Description: 服务的可读名称。
• After: 指定此服务应在列出的单元成功启动之后才启动。

[Unit]
Description=My Custom Reporter Daemon
# 仅在基本网络和日志服务启动运行后才启动
After=network.target

[Service] 部分

这是核心部分，定义了运行哪个命令以及 Systemd 应如何管理该进程。

• Type: 定义进程启动类型。simple 是对于持续在前台运行的脚本的标准类型。
• User/Group: 指定在哪个用户上下文下运行进程（出于安全原因强烈推荐）。
• ExecStart: 执行服务时要执行的命令或脚本的绝对路径。
• Restart: 定义自动重启策略（例如 on-failure、always）。

[Service]
Type=simple
User=your_username # 重要提示：如果可能，请将 'your_username' 替换为非 root 用户
Group=your_group # 可选，通常与用户组匹配

# Systemd 执行的命令
ExecStart=/opt/my-custom-service/reporter.sh

# 重启策略
Restart=on-failure
RestartSec=5s # 尝试重启前等待 5 秒
StandardOutput=journal # 将输出定向到 Systemd 日志
StandardError=journal

安全警告： 除非绝对必要，否则切勿以 root 用户身份运行自定义服务。为应用程序进程定义一个专用的、权限最小化的用户。

[Install] 部分

此部分指定服务应如何启用——具体来说，它应该链接到哪个目标，以便在启动时自动启动。

• WantedBy: 指定应包含此服务的目标。对于应在正常启动时启动的标准系统服务，multi-user.target 是标准选择。

[Install]
WantedBy=multi-user.target

步骤 3：重新加载、启用和启动服务

创建或修改单元文件后，您必须告知 Systemd 重新加载其配置守护程序，然后管理新服务。

1. 重新加载 Systemd 管理器配置：
   每当添加或修改单元文件时，此步骤都是必需的。

   bash sudo systemctl daemon-reload

2. 启用服务（开机自动启动）：
   这会在适当的目标目录（例如 multi-user.target.wants/）下创建指向您的服务文件的符号链接，确保它在系统启动时自动启动。

   bash sudo systemctl enable my-reporter.service
   输出将确认符号链接的创建。

3. 启动服务：
   这会立即启动 ExecStart 中定义的进程。

   bash sudo systemctl start my-reporter.service

步骤 4：验证服务状态和日志

验证服务是否已正确启动并按预期运行至关重要。

1. 检查状态：
   status 命令提供当前状态、最近的日志行和执行详细信息。

   bash systemctl status my-reporter.service

   在输出中查找 Active: active (running)。

2. 查看日志 (Journalctl)：
   由于我们在 [Service] 部分中将输出定向到日志，因此我们可以使用 journalctl 查看运行时消息。

   bash journalctl -u my-reporter.service -f

3. 验证文件输出：
   检查脚本中指定的日志文件：

   bash tail -f /var/log/reporter.log

基本管理命令

定义后，使用 systemctl 命令可以轻松管理您的服务：

总结和后续步骤

通过掌握 [Unit]、[Service] 和 [Install] 部分，您已成功使用 Systemd 构建了一个强大的、受管理的服务。此基础结构使您能够管理复杂的应用程序生命周期，确保可靠的启动顺序、出现故障时的自动重启以及通过 Systemd 日志进行集中化日志记录。

对于更高级的用例，请探索 [Service] 部分中的选项，例如用于配置加载的 EnvironmentFile，或将 Type 更改为 forking 以进行传统守护进程管理。