用 systemd 管理自研服务：开机自启、日志与失败重启实战

很多自研服务一开始靠 nohup 加 & 跑在后台：终端一断、机器一重启、进程一崩，服务就悄悄没了，排查时连日志都找不到。交给 systemd 管理，就是把启动、重启、日志和权限收敛到同一套规则里。

一、一个服务就是一个 unit

systemd 是主流 Linux 发行版的服务管理器，一个服务对应一个 .service 文件。系统级服务放在 /etc/systemd/system/，个人开发机的小服务可用 ~/.config/systemd/user/。

二、最小可用模板

[Unit]
Description=MyApp Service
After=network-online.target

[Service]
Type=simple
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/app --config /opt/myapp/config.yaml
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

ExecStart 必须写绝对路径，不要依赖 PATH；Type=simple 适合前台运行的程序；WorkingDirectory 决定相对路径的基准，缺了它，读配置和写文件都可能跑偏。

三、启用与重载别搞反

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
sudo systemctl status myapp.service

改了 unit 文件必须先 daemon-reload，否则用的是旧配置，排错会越走越偏。enable 管开机自启，–now 顺带当次启动，停用则用 stop 与 disable。

四、日志交给 journald

journalctl -u myapp.service -f
journalctl -u myapp.service --since "2026-10-30 09:00" --no-pager
journalctl -u myapp.service -p err --since yesterday

-f 实时跟踪，–since 按时间过滤，-p err 只看错误。

五、失败重启要有边界

Restart=on-failure 加 RestartSec=5，能兜住偶发崩溃，但不能掩盖配置错误。程序启动即退出时，systemd 会因启动频率限制进入 failed 状态，这是提醒你修根因，而不是放任无限重启。

六、环境、权限与排错

环境变量建议用 EnvironmentFile 集中管理，密钥不要写进 unit 文件或代码仓库，运行用户用专用账号而非 root。起不来时按序查：status 与 journalctl 的报错、ExecStart 路径与权限、端口占用、依赖服务是否就绪，最后确认是否忘了 daemon-reload。

结语

一份清晰的 unit 文件、一条固定的查日志方式、一套失败重启的边界，再加上最小权限，就足以让自研服务从“能跑”变成“可运维”。