systemd 服务管理：从开机自启到日志排查

后端服务上线后最怕两件事：服务器一重启服务没起来，出了问题又找不到日志。systemd 是现代 Linux 发行版默认的服务管理器，掌握它，上面两个问题都能一次解决。

一、一个最小的服务单元

假设你写了一个 Python 后端 app.py，监听 8000 端口。给它写一个 unit 文件 /etc/systemd/system/myapp.service：

[Unit]
Description=My backend app
After=network.target

[Service]
Type=simple
User=app
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

几个关键字段值得记住：After=network.target 保证网络就绪后再启动；Restart=on-failure 让进程异常退出后自动拉起，RestartSec=5 是两次重启之间的间隔，避免瞬间反复崩溃把日志刷爆。

写好后执行 systemctl daemon-reload 让 systemd 重新加载配置，再 systemctl enable --now myapp，一条命令同时完成开机自启和立即启动。

二、常用操作就这几条

systemctl status myapp      # 看状态、最近日志、是否开机自启
systemctl start/stop/restart myapp
systemctl enable/disable myapp   # 开机自启开 / 关

status 的输出里有一行 Loaded 和一行 Active，前者告诉你配置文件有没有被正确加载，后者是当前运行状态。服务起不来时先看这里，十有八九能看到报错原因。

三、日志都在 journalctl 里

systemd 的服务默认把标准输出和标准错误都收进 journal，不需要你自己再写日志文件：

journalctl -u myapp -f        # 实时跟随，像 tail -f
journalctl -u myapp --since "10 minutes ago"   # 只看最近 10 分钟
journalctl -u myapp -p err     # 只看错误级别

一个实用技巧：在代码里把日志打到标准输出，级别用前缀区分，排查时直接按级别过滤，比翻几百兆的文本日志快得多。

四、两个容易踩的坑

第一，ExecStart 里不要用 shell 语法。需要管道或重定向时，把命令写进一个 start.sh 再让 ExecStart 去执行它，否则 systemd 会把 | 当成普通参数传给程序。

第二，环境变量别写在代码里。unit 文件支持 EnvironmentFile=/opt/myapp/.env，把数据库地址、密钥放进这个文件，文件权限设为 600，只让运行服务的用户读取。服务要重启才能读到新变量，改完记得 systemctl restart。

五、一个检查清单

服务上线前，对着这张清单过一遍：

1. enable 了吗？重启后能不能自己起来？
2. Restart=on-failure 配了吗？进程崩了会不会自动恢复？
3. 日志能用 journalctl -u 查到吗？
4. 敏感配置是不是在 EnvironmentFile 里，而不是代码里？

四项都打勾，这个服务才算真正"上线"了，而不是"碰巧在跑"。

systemd 看起来配置项很多，但日常 90% 的场景就是上面这些：写一个 unit、enable、看 status、出问题查 journal。把这套流程跑熟一次，以后每个新服务都能十分钟内接管。