systemd管理守护进程关键在于精准配置：服务文件放/etc/systemd/system/、权限644、执行daemon-reload；unit段设description/after/wants；service段选type、写execstart、配restart与user；install段设wantedby=multi-user.target。
用 systemd 管理守护进程，核心不在写得多，而在配得准——关键字段写对、依赖理清、重启策略合理、日志路径明确，服务就能稳如系统原生组件。
服务单元文件放在哪？权限和路径有讲究
自定义服务应优先放在 /etc/systemd/system/ 目录下（例如 myapp.service），这是管理员可写、systemd 优先读取的位置。不要覆盖 /usr/lib/systemd/system/ 中的发行版默认文件，避免升级冲突。文件需属主为 root，权限设为 644（sudo chmod 644 /etc/systemd/system/myapp.service）。写完必须执行 sudo systemctl daemon-reload，否则 systemd 不会识别新配置。
[Unit] 段：声明服务意图与启动顺序
这一段不启动进程，只告诉 systemd “这个服务是干什么的”“该什么时候启动”。关键项包括：
-
Description=：简明描述，如
Description=My Python API Service -
After=：指定依赖的 target 或服务，比如
After=network.target表示等网络就绪后再启动；若还依赖数据库，可加After=postgresql.service -
Wants= 或 Requires=：声明软/硬依赖。多数场景用
Wants=network.target即可，失败不影响本服务激活；Requires则严格要求依赖成功，慎用 -
Documentation=（可选）：支持
man:myapp(8)或 URL，方便运维查文档
[Service] 段：定义进程行为与容错能力
这是守护进程真正“活起来”的部分。重点配置：
-
Type=：决定 systemd 如何判断服务是否就绪。常见值：
simple（默认，ExecStart 启动即算运行）、forking（传统 daemon 双 fork 后父进程退出）、notify（程序主动调用 sd_notify() 通知就绪，推荐用于 Python/Go 等现代应用） -
ExecStart=：必须是绝对路径的可执行命令，如
ExecStart=/usr/bin/python3 /opt/myapp/app.py。避免使用 shell 特性（如管道、重定向），如需，改用ExecStart=/bin/sh -c '...' -
Restart=：故障恢复策略。生产环境建议设为
on-failure（非正常退出时重启）或always（任何退出都重启）；搭配RestartSec=5控制重启间隔，防雪崩 -
User= 和 Group=：强制以非 root 身份运行，如
User=www-data，提升安全性 -
Environment=（可选）：注入环境变量，如
Environment=PYTHONPATH=/opt/myapp
[Install] 段：控制开机自启逻辑
只有启用（enable）后，该段才生效。最常用配置是：
-
WantedBy=multi-user.target：表示该服务属于“多用户模式”，执行
sudo systemctl enable myapp.service后，systemd 会在/etc/systemd/system/multi-user.target.wants/下创建指向本文件的软链接 - 不写此段，
enable命令会报错；写错 target（如误写graphical.target）可能导致服务在无 GUI 的服务器上不启动
配置完成后，用 systemctl status myapp 查状态，journalctl -u myapp -f 实时看日志。一个清晰、克制、职责分明的 unit 文件，比复杂脚本更可靠。
