Linux 下用 systemd 管理常驻脚本：从手写 service 文件到开机自启与日志查看

很多常驻脚本一开始都跑在终端里：用 nohup 加 & 挂到后台，关掉终端就靠运气续命。机器一重启，脚本不会自己回来；出了问题，也只能翻散落在各处的输出文件。systemd 就是为了解决这类问题而存在的：它把一个长期运行的程序变成可以启动、停止、开机自启、自动重启并集中看日志的服务。

先准备一个最简单的常驻脚本，例如每分钟写一行心跳日志，放在 /opt/demo/app.py。写完先手动跑一次，确认没有语法、路径和权限问题，再交给 systemd 接管。没跑通过的脚本直接做成服务，只会把排错现场从终端搬到日志里。

接下来手写 service 文件，系统级服务通常放在 /etc/systemd/system/demo.service。Unit 段写描述和启动顺序，例如 After=network-online.target 表示尽量在网络就绪后再启动。Service 段是核心：Type=simple 表示前台主进程就是服务本身；ExecStart 必须写绝对路径，例如 /usr/bin/python3 /opt/demo/app.py；WorkingDirectory 指定工作目录；User 指定运行用户，不要习惯性用 root 跑普通脚本；Restart=on-failure 让异常退出后自动重试。Install 段写 WantedBy=multi-user.target，决定开机自启挂在哪一个目标上。

写好后先 reload 再试运行：systemctl daemon-reload、systemctl start demo、systemctl status demo。status 里的 active(running) 是最直接的体检报告。如果启动失败，先看 status 尾部提示，再看 journalctl -u demo -e，两处通常已经把找不到解释器、权限被拒绝、端口被占用说得很清楚。确认能手动启动后，用 systemctl enable --now demo 一步完成开机自启和启动，再用 is-enabled 验证输出 enabled。重启后 status 仍为 active(running)，这条链路才算闭环。

日志是 systemd 最容易被低估的好处：脚本的标准输出和标准错误默认进入 journal，不用再为每个脚本单独维护日志文件。日常用 journalctl -u demo 查看，实时追踪用 -f，日志量大时用 -n 100 只看最后 100 行，或用 -p err 只看错误级别。排错也有一张固定清单：ExecStart 必须是绝对路径；环境变量不会自动继承 shell 配置，需要的变量用 Environment= 写进文件；相对路径和家目录假设是常见坑；改了 service 文件一定要 daemon-reload，否则用的还是旧配置。

最后养成一个习惯：升级前先 stop，升级后 start 并看一眼 status；临时停用用 disable 而不是直接删文件；不再需要时先 stop、再 disable，最后删除文件并 daemon-reload。这样，重启后服务还在、挂了能自己起来、出了问题能找到日志，就会变成默认状态，而不是每次靠运气。