如何使用 systemd 在启动时启动 Linux 服务

确保关键服务在服务器重启时自动启动是任何 Linux 系统管理员最基本的职责之一。无论您在 VPS Hosting 环境中运行 Web 应用程序、数据库引擎还是自定义守护程序，意外重启都不应该意味着长时间的停机。使用 systemd —— 为当今大多数 Linux 发行版提供支持的现代初始化系统 —— 您可以精确定义服务如何、何时以及以谁的身份启动，所有这些都通过一个清晰的声明式单元文件完成。

本综合指南将引导您完成每一步：了解 systemd 是什么、创建生产就绪的服务单元文件、验证权限、测试可执行文件以及管理服务生命周期。最后，您的自定义应用程序将在每次重启时自动运行。

什么是 systemd 以及为什么它很重要？

systemd 是一个初始化系统和服务管理器，已在大多数主要 Linux 发行版（包括 Ubuntu、Debian、CentOS、Rocky Linux、AlmaLinux 和 Fedora）中替代了 SysVinit 和 Upstart 等较旧的替代方案。systemd 不是在启动时执行一系列顺序的 shell 脚本，而是并行化服务启动、解决依赖关系排序，并从单一统一的界面管理系统进程的整个生命周期。

systemd 在服务器环境中的主要优势

对于在 Dedicated Servers 或 VPS 实例上管理应用程序的任何人来说，这些功能直接转化为更高的正常运行时间和在负载下更可预测的行为。

理解 systemd 单元文件

systemd 管理的所有内容都由一个单元文件表示——一个纯文本配置文件，分为多个部分。一个 .service 单元文件告诉 systemd：

• 什么是服务（元数据、描述、依赖关系）
• 如何运行它（可执行文件路径、工作目录、用户上下文）
• 何时启动它（启动目标、相对于其他单元的顺序）
• 如果失败该做什么（重启策略、重启延迟）

系统范围服务的单元文件位于 /etc/systemd/system/。放置在此处的文件优先于 /lib/systemd/system/ 中供应商提供的单元，并在软件包升级后保持不变。

分步指南：创建 systemd 服务单元

以下演练使用一个名为 myapp 的虚构应用程序。将 myapp、myuser 和 /usr/bin/myapp 的每个实例替换为适合您自己环境的值。

步骤 1：准备工作目录

在编写单元文件之前，决定应用程序将从哪里运行。专用工作目录可以保持配置文件、日志和运行时数据的组织，并使权限管理变得简单明了。

如果目录不存在，请创建它：

sudo mkdir -p /opt/myapp

> 为什么选择 /opt/ 而不是 /etc/systemd/？

> /etc/systemd/ 树是为 systemd 自己的配置保留的。将应用程序数据放在那里是非标准的，可能会导致混淆。根据最适合您的工作负载的文件系统层次结构标准类别，使用 /opt/myapp、/srv/myapp 或 /var/lib/myapp。

将所有权分配给将运行该服务的用户：

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myuser
sudo chown -R myuser:myuser /opt/myapp

使用专用系统账户（无登录 shell，无主目录）是安全最佳实践。如果应用程序遭到破坏，它会限制影响范围。

验证结果：

ls -ld /opt/myapp
# Expected output: drwxr-xr-x 2 myuser myuser 4096 Jan 1 00:00 /opt/myapp

步骤 2：创建服务单元文件

使用您喜欢的编辑器打开一个新的单元文件：

sudo nano /etc/systemd/system/myapp.service

粘贴以下内容，调整值以匹配您的应用程序：

[Unit]
Description=My Custom Application
Documentation=https://example.com/docs
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/myapp --config /opt/myapp/myapp.conf
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
User=myuser
Group=myuser
WorkingDirectory=/opt/myapp
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

使用 Ctrl+O 保存文件，然后使用 Ctrl+X 退出。

步骤 3：理解每个指令

[Unit] 部分

> network-online.target 与 network.target：对于真正需要完全配置的网络接口的服务，使用 network-online.target（与 Wants=network-online.target 结合）— 例如，在启动时连接到远程数据库或外部 API 的应用程序。network.target 仅保证网络子系统已被*启动*，不保证接口已启动且地址已分配。

[Service] 部分

[Install] 部分

步骤 4：验证文件和目录权限

在重新加载 systemd 之前，确认服务用户实际上可以访问它需要的所有内容：

# Check working directory ownership and permissions
ls -ld /opt/myapp

# Confirm the executable exists and is executable
ls -l /usr/bin/myapp

# Verify the config file is readable by myuser
sudo -u myuser cat /opt/myapp/myapp.conf

如果这些检查中的任何一个失败，请在继续之前更正权限：

# Make the binary executable
sudo chmod +x /usr/bin/myapp

# Grant read access to the config file
sudo chmod 640 /opt/myapp/myapp.conf
sudo chown myuser:myuser /opt/myapp/myapp.conf

步骤 5：手动测试可执行文件

在将控制权交给 systemd 之前，始终验证您的应用程序运行正确。这将应用程序错误与 systemd 配置问题隔离开来：

sudo -u myuser /usr/bin/myapp --config /opt/myapp/myapp.conf

如果应用程序启动没有错误，按 Ctrl+C 停止它并继续。如果失败，对应用程序本身进行故障排除 — 检查所有依赖项是否已安装、环境变量是否已设置以及所需的端口是否可用。

步骤 6：重新加载 systemd 并启用服务

保存单元文件后，指示 systemd 重新读取其配置：

sudo systemctl daemon-reload

启用服务，使其在每次后续启动时自动启动：

sudo systemctl enable myapp.service

此命令在适当的 .wants 目录中创建一个符号链接，将您的单元文件链接到 multi-user.target 启动序列中。您应该看到类似的输出：

Created symlink /etc/systemd/system/multi-user.target.wants/myapp.service → /etc/systemd/system/myapp.service.

立即启动服务，无需重新启动：

sudo systemctl start myapp.service

步骤 7：验证服务正在运行

检查服务的当前状态：

sudo systemctl status myapp.service

健康的服务会产生如下输出：

● myapp.service - My Custom Application
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2025-01-01 12:00:00 UTC; 5s ago
   Main PID: 12345 (myapp)
      Tasks: 4 (limit: 4915)
     Memory: 12.3M
        CPU: 45ms
     CGroup: /system.slice/myapp.service
             └─12345 /usr/bin/myapp --config /opt/myapp/myapp.conf

要验证的关键字段：

• Loaded — 确认单元文件已成功解析，并显示它是否为启动时的 enabled 或 disabled
• Active: active (running) — 服务当前正在运行
• Main PID — 您的应用程序的进程 ID

步骤 8：使用 journalctl 监控日志

systemd 将所有服务输出路由到日志，一个结构化的、可查询的日志存储。使用 journalctl 检查它：

# View all logs for myapp (most recent last)
journalctl -u myapp.service

# Follow live log output (like tail -f)
journalctl -u myapp.service -f

# Show only logs since the last boot
journalctl -u myapp.service -b

# Show the last 50 lines
journalctl -u myapp.service -n 50

# Show logs since a specific time
journalctl -u myapp.service --since "2025-01-01 12:00:00"

如果您的服务无法启动，日志几乎总是包含解释原因的确切错误消息。这是在进行任何更改之前首先要查看的地方。

步骤 9：测试启动行为

要确认服务在重新启动后能够存活，而无需手动检查启动序列，您可以模拟它：

# Reboot the server (only if safe to do so)
sudo reboot

服务器重新上线后，再次检查服务状态：

sudo systemctl status myapp.service

如果它显示 active (running)，您的服务已正确配置为自动启动。

管理服务生命周期

一旦您的服务运行，您将定期使用以下命令：

常见 systemctl 命令

# Start the service
sudo systemctl start myapp.service

# Stop the service gracefully
sudo systemctl stop myapp.service

# Restart the service (stop + start)
sudo systemctl restart myapp.service

# Reload configuration without restarting (if ExecReload is defined)
sudo systemctl reload myapp.service

# Enable automatic startup at boot
sudo systemctl enable myapp.service

# Disable automatic startup at boot
sudo systemctl disable myapp.service

# Check whether the service is enabled
sudo systemctl is-enabled myapp.service

# Check whether the service is currently active
sudo systemctl is-active myapp.service

# View the full unit file as systemd interprets it
sudo systemctl cat myapp.service

# Edit the unit file and reload in one step
sudo systemctl edit --full myapp.service

故障排除常见问题

服务启动失败：”No such file or directory”

这通常意味着 ExecStart 指向不存在的二进制文件或 WorkingDirectory 不存在。验证两个路径：

which myapp
ls -l /opt/myapp

服务启动但立即退出

检查日志以查看应用程序自身的错误输出：

journalctl -u myapp.service -n 100 --no-pager

还要验证 Type=simple 对您的应用程序是否正确。如果您的二进制文件将自身分叉到后台，请改用 Type=forking。

“Permission denied”错误

服务用户缺少对所需文件或目录的访问权限。使用 ls -l 审计权限，使用 sudo -u myuser 交互式测试访问。

端口已在使用中

另一个进程绑定到您的应用程序需要的端口。使用以下命令识别它：

sudo ss -tlnp | grep :<port>

服务在循环中重启

如果 Restart=on-failure 导致快速重启循环，systemd 最终会限制重启。检查 [Unit] 部分中的 StartLimitIntervalSec 和 StartLimitBurst 以调整此行为，并始终在日志中调查根本原因。

生产服务器的高级 systemd 模式

环境变量和环境文件

永远不要在单元文件中硬编码机密。改用环境文件：

[Service]
EnvironmentFile=/etc/myapp/myapp.env
ExecStart=/usr/bin/myapp

创建 /etc/myapp/myapp.env 包含 chmod 600 和 chown root:myuser 来限制访问：

DATABASE_URL=postgresql://user:password@localhost/mydb
API_KEY=supersecretkey

服务依赖关系和排序

如果您的应用程序依赖于数据库服务（例如 PostgreSQL 或 MySQL），请明确声明该依赖关系：

[Unit]
After=network-online.target postgresql.service
Requires=postgresql.service

Requires 是硬依赖 — 如果 PostgreSQL 启动失败，systemd 也不会尝试启动您的服务。

监视程序集成

对于关键任务服务，启用 systemd 的内置监视程序来检测挂起的进程：

[Service]
WatchdogSec=30s
Restart=on-watchdog

您的应用程序必须定期调用 sd_notify(0, "WATCHDOG=1") 来重置监视程序计时器。如果在 WatchdogSec 内未能这样做，systemd 会杀死并重启该服务。

选择正确的托管环境

本指南中描述的 systemd 配置模式适用于所有 Linux 服务器类型，但您选择的托管基础设施会影响您对 init 系统和服务管理的控制程度。

• VPS 托管 — 完全的 root 访问权限、完整的 systemd 控制、非常适合自定义应用程序部署。AlexHost VPS 计划运行在 KVM 虚拟化上，为您提供真正隔离的内核环境。
• 专用服务器 — 为资源密集型服务提供最大性能和隔离。完全的硬件访问权限，没有嘈杂的邻居。
• 带 cPanel 的 VPS — 将根级别的 systemd 访问权限与图形控制面板相结合，适合从单个界面管理系统服务和网络托管的团队。
• 共享网络托管 — 适合不需要自定义系统服务的标准网络应用程序。没有 root 访问权限，但零服务器管理开销。

如果您部署自定义守护程序、微服务或任何需要在重启后自动继续运行的应用程序，具有完全 root 访问权限的 VPS 或专用服务器是适当的选择。

快速参考：完整 systemd 服务检查清单

在认为您的服务已准备好投入生产之前，请验证此检查清单中的每一项：

• [ ] 单元文件已保存到 /etc/systemd/system/myapp.service
• [ ] ExecStart 使用指向有效的可执行二进制文件的绝对路径
• [ ] WorkingDirectory 存在且由服务用户拥有
• [ ] 服务以专用非 root 系统账户运行
• [ ] sudo systemctl daemon-reload 在任何单元文件更改后执行
• [ ] sudo systemctl enable myapp.service 确认符号链接已创建
• [ ] sudo systemctl status myapp.service 显示 active (running)
• [ ] journalctl -u myapp.service 显示无错误
• [ ] 服务器已重启，并确认服务在启动后运行
• [ ] 已应用安全加固指令（NoNewPrivileges、ProtectSystem、PrivateTmp）

结论

systemd 是现代 Linux 服务器的明确服务管理层。通过创建结构良好的 .service 单元文件，您可以获得自动启动、智能重启策略、集中式日志记录和细粒度安全控制 — 无需编写任何 shell 脚本。

该过程很简单：准备一个专用工作目录和系统用户，使用正确的 [Unit]、[Service] 和 [Install] 部分编写单元文件，重新加载 systemd 守护程序，启用并启动服务，然后使用 systemctl status 和 journalctl 进行验证。应用上述安全加固指令，您的服务将既具有弹性，又能与系统其余部分进行适当的沙箱隔离。

无论您在 AlexHost VPS Hosting 或 Dedicated Servers 计划上部署 Node.js API、Python 工作进程、Go 二进制文件或任何其他自定义应用程序，此 systemd 工作流都可确保您的服务在用户需要时始终运行 — 即使在意外重启后也是如此。