用 systemd 管理自研 QT 后台服务，核心是写对 .service 文件，关键在 Type、ExecStart、Restart 和环境变量四点；必须用绝对路径、非 root 用户、Restart=on-failure、QT_QPA_PLATFORM=offscreen，并执行 daemon-reload。
直接上结论：用 systemd 管理自研程序做后台服务，核心是写对 .service 文件，关键在 Type、ExecStart、Restart 和环境变量这四点。别用 & 或 nohup 临时凑合——它们扛不住重启、没日志聚合、不响应依赖关系。
怎么写一个能跑起来的 .service 文件
把服务文件放到 /etc/systemd/system/myapp.service，内容至少包含三块：
-
[Unit]：加After=network.target（多数网络服务需要），有数据库依赖就加Wants=postgresql.service+After=postgresql.service -
[Service]：必须用绝对路径写ExecStart=/opt/myapp/bin/myapp --config /etc/myapp/conf.yaml；User和Group建议设为非 root（如User=myapp）；Restart=on-failure是底线，别写always（会掩盖启动失败） -
[Install]：固定写WantedBy=multi-user.target，这是标准运行级
写完立刻执行 systemctl daemon-reload，否则 systemctl start 会报 “unit not found”。
Type=simple 还是 Type=notify？
选哪个取决于你的程序是否主动通知 systemd “我准备好了”：
- 如果你的程序是传统风格：启动后立即进入主循环、不 fork、不 daemonize，用
Type=simple（默认值，可省略） - 如果你用了 QtService、libsystemd 的
sd_notify()，或 .NET 的HostBuilder.UseSystemd()，那就必须设Type=notify，否则systemctl status会卡在 “activating (start)” 状态 - 别乱试
Type=forking：除非你明确 fork 一次且父进程退出，否则容易被 systemd 杀掉子进程
判断方法很简单：启动后看 systemctl status myapp 输出里 Main PID 是否稳定。如果一会儿变、一会儿空，大概率是 Type 配错了。
常见启动失败原因和对应 fix
启动失败时，先看 systemctl status myapp 最后几行，再查 journalctl -u myapp -n 50 -o short-precise。高频问题：
-
Failed at step EXEC spawning：路径错或没执行权限 → 检查ExecStart绝对路径，运行ls -l /opt/myapp/bin/myapp -
qt.qpa.xcb: could not connect to display：QT 程序没关 GUI → 加Environment="QT_QPA_PLATFORM=offscreen" -
Permission denied（读配置/写日志）：User=myapp但目录属主还是 root →chown -R myapp:myapp /opt/myapp /var/log/myapp -
Started myapp.service but then exited：程序启动即退出 → 先手动运行sudo -u myapp /opt/myapp/bin/myapp --config /etc/myapp/conf.yaml看报错
为什么不要用 nohup & 或 screen 代替 systemd
这些方式看似简单，但实际埋了坑：
- 终端关闭后进程可能还在，但 systemd 完全不知道它存在，无法做资源限制、自动拉起、依赖管理
- 日志散落在
nohup.out或 screen 会话里，没法用journalctl统一检索、按时间过滤、导出 JSON - 没 CGroup 隔离：一个失控的自研程序能把整台机器内存吃光，而
systemd可配MemoryLimit=512M、CPUQuota=50% - 开机不自启：得自己写 rc.local 或 crontab @reboot，既不标准又难维护
真正麻烦的从来不是写 service 文件，而是程序本身没处理好信号（比如收到 SIGTERM 不优雅退出）、没关闭 stdout/stderr 重定向、或硬编码了路径。这些细节 systemd 不帮你兜底。
