深入掌握 systemd：从零创建服务到高效排查故障全攻略

52JinY 助手

用了好几年 Linux，感觉 systemd 这个东西真的是又爱又恨。爱它是因为它确实统一了服务管理的方式，恨它是因为刚上手的时候那堆概念能把人绕晕。今天趁着有空，把我自己摸索出来的一些经验整理一下，希望对刚接触 systemd 的朋友有点帮助。

先说创建服务单元文件这一块。自定义服务的配置文件一般放在 /etc/systemd/system/ 目录下，文件后缀是 .service。一个最基础的单元文件结构分三个区块：[Unit]、[Service]、[Install]。[Unit] 里写描述和依赖关系，[Service] 里写具体怎么启动、用什么用户跑、进程类型是什么，[Install] 里写 WantedBy，一般设成 multi-user.target 就够了。有个细节很多人忽略，就是 ExecStart 必须写绝对路径，不能依赖 PATH 环境变量，我当初就在这里踩坑，折腾了好久才发现。Type 字段也要注意，如果你的程序会 fork 子进程，要用 forking；如果是普通的前台进程，simple 就行；还有个 notify 类型，是专门给那些支持 sd_notify 协议的程序用的。

写好配置文件之后，一定要记得执行 systemctl daemon-reload，不然 systemd 读不到你新加的文件。然后用 systemctl enable 来让服务开机自启，用 systemctl start 立即启动。这两步可以合并成 systemctl enable --now，省一条命令。停止服务用 stop，重启用 restart，重新加载配置（如果服务支持的话）用 reload，这几个操作是日常最高频的。

重点讲讲故障排查，这才是真正花时间的地方。第一步永远是 systemctl status 服务名，这个命令会告诉你服务当前状态、最近几条日志、PID 等等，很多简单的问题这一步就能看出来，比如配置文件语法错误、可执行文件路径写错了。如果 status 给的信息不够，就上 journalctl。看某个服务的完整日志用 journalctl -u 服务名，加上 -e 参数直接跳到末尾，加上 -f 参数实时跟踪输出，这在调试刚启动就崩的服务时特别好用。如果想看启动失败的详细原因，journalctl -u 服务名 --since "10 minutes ago" 把时间范围缩一下，信息会更清晰。

还有一个容易被忽略的排查点是权限问题。很多人喜欢在 [Service] 里写 User=root 图省事，其实挺危险的。应该尽量用专门的低权限用户来跑服务，但这样的话就要确保那个用户对相关目录和文件有读写权限，否则服务启动后会因为权限不足悄悄报错。用 systemctl status 看到 "ermission denied" 之类的字样，基本就是这个问题。另外 SELinux 或者 AppArmor 开着的系统上，有时候权限看起来对了但还是跑不起来，这时候要去看安全模块的日志，别在 systemd 这边死磕。

最后分享一个小技巧，在正式写 service 文件之前，可以先用 systemd-analyze verify 你的.service文件路径 来做语法检查，比等到运行时报错效率高多了。另外 systemd-analyze blame 可以列出各服务的启动耗时，排查系统启动慢的问题非常直观。systemd 的文档其实写得相当详细，man systemd.service 和 man systemd.exec 翻一翻，很多冷门但有用的参数都在里面藏着。慢慢用，慢慢就顺手了。