systemd 服务文件怎么写：启动、权限与失败恢复
在 SSH 窗口中启动一个程序，连接断开后怎样继续运行、失败时怎样重启、日志去哪里，往往没有统一答案。Ubuntu 24.04 使用 systemd 管理系统服务，可以把这些行为明确写入服务单元。下面用本机静态页面演示管理机制，Python 内置 HTTP 服务只用于本次验证，不作为正式网站的生产部署方案。
准备一个不会碰到现有业务的目标
先检查 command -v python3 与 sudo ss -lntp，确认 Python 可用且 18081 端口没有占用。检查 /srv/systemd-demo 和 demo-http.service 尚未使用，然后创建独立目录，放入一个无敏感内容、可公开读取的测试 HTML 文件。
目录应允许演示进程穿越，文件应可读取，例如新目录 755、新文件 644。不要把数据库备份或真实配置放进去。服务测试只需读取这些文件，不需要获得整个网站目录的写权限。
编写独立服务单元
由管理员新建 /etc/systemd/system/demo-http.service，不覆盖系统已有文件：
[Unit]
Description=Local HTTP service demonstration
[Service]
Type=exec
DynamicUser=yes
ExecStart=/usr/bin/python3 -m http.server 18081 --bind 127.0.0.1 --directory /srv/systemd-demo
Restart=on-failure
RestartSec=5s
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
[Install]
WantedBy=multi-user.target
Type=exec 可以让缺少程序或执行身份等早期错误更明确地反馈；它仍不等于 HTTP 业务已经准备就绪。DynamicUser 为这个无持久写入需求的演示提供动态身份，正式应用若需要固定数据归属，应采用适当的账号与状态目录设计。systemd.service 手册解释了启动类型和重启策略。
启动命令不会自动经过 shell
ExecStart 使用绝对路径和明确参数，不会把终端里的管道、重定向和通配符全部当作 shell 语法执行。需要复杂准备工作时，编写单独脚本并检查权限，不能把一串交互命令直接粘进来。
服务环境也不会自动继承你的登录终端。如果应用需要工作目录或环境参数，应使用对应的配置项；密钥不要直接暴露在命令行或可公开读取的文件里。演示中的保护设置限制写入和家目录访问，正式应用要按实际需要验证，不能为消除报错一次关闭全部保护。systemd.exec 手册说明了执行环境与隔离设置。
先校验，再启动，最后考虑开机启用
在服务器逐条执行：
sudo systemd-analyze verify /etc/systemd/system/demo-http.service
sudo systemctl daemon-reload
sudo systemctl start demo-http.service
systemctl status demo-http.service --no-pager
curl -I http://127.0.0.1:18081/
校验失败时先修配置。daemon-reload 让管理器重新读取单元定义，不会自动重启正在运行的应用；start 才是启动动作。状态显示 running 后，还要检查页面内容，确认不是另一个进程占用了目标端口。
完成本机验证后，确实需要随系统启动再执行 sudo systemctl enable demo-http.service。不要给一次性试验默认增加永久开机行为。正式服务需要重启主机验收时，先安排维护窗口和恢复入口。
用日志找原因，用明确动作撤回
查看 sudo journalctl -u demo-http.service --since "10 minutes ago"。端口冲突、文件不可读、参数错误和程序异常退出，应按日志分别处理。Restart=on-failure 只能帮助重试，不会修好错误配置，也不能保证无限重试；频繁失败还可能触发启动频率限制。
停止演示用 sudo systemctl stop demo-http.service，撤销开机启动用 sudo systemctl disable demo-http.service。需要移除单元时，先确认它属于本次新增内容，再将该文件移到受控备份位置并重新加载管理器。保留页面数据直到确认无需恢复，不顺手清理其他服务目录。
以后把真实应用接入 systemd 时，应额外验证关闭流程、数据持久化、超时和应用就绪状态。服务管理的价值是行为可检查、异常可定位，而不仅是让进程留在后台。