systemd通过解析.service文件依赖关系（如after=、requires=）并按图激活单元来启动服务，父进程必为pid 1，type设置错误或execstart未前台运行会导致active (exited)假象。
systemd 是怎么启动一个服务的
Linux 现代发行版（如 Ubuntu 20.04+、CentOS 8+、Debian 11+）默认用 systemd 管理服务，它不是简单地 fork 进程就完事——而是按依赖图逐层激活单元（unit），并严格管控生命周期。
关键点在于：systemd 启动服务前会先解析其 .service 文件中的 WantedBy=、After=、Requires= 等字段，决定加载顺序和依赖关系。如果依赖项失败（比如 network.target 没就绪），该服务会被挂起，直到条件满足或超时。
-
systemctl start nginx实际触发的是nginx.service单元的starttransition，而非直接执行/usr/sbin/nginx - 服务进程的父进程一定是
systemd（PID 1），不是 shell；用ps -o pid,ppid,comm -C nginx可验证 - 若服务定义了
Type=forking，systemd会等待进程首次 fork 后的子进程，并将该子进程视为主服务进程；写错PIDFile=或没正确 daemonize，会导致启动“成功”但实际未运行
为什么 systemctl status 显示 active (exited) 却没在跑
这是 Type=oneshot 或 Type=exec 服务最常见的误判场景：命令执行完就退出，systemd 认为任务完成，状态变成 active (exited)，但它根本不是长期运行的服务。
典型例子是数据库初始化脚本、一次性配置加载器，或者错误地把守护进程（daemon）当成了普通命令来写。
- 检查服务文件中
Type=的值：simple（默认，主进程即服务）、forking（需 daemonize）、oneshot（只执行一次） - 用
systemctl cat <service-name></service-name>查看完整 unit 定义，重点看ExecStart=和Type= - 如果本应长期运行却显示
exited，大概率是：Type设错了，或ExecStart=调用的是个立即返回的包装脚本（比如忘了加-g参数让redis-server前台运行）
如何让自定义脚本真正后台驻留并被 systemd 托管
别用 &、nohup 或 screen ——这些绕过 systemd 的进程管理，会导致日志丢失、无法自动重启、systemctl stop 失效。
正确做法是让脚本前台运行，并配对合适的 Type 和生命周期控制参数。
- Python 脚本：去掉
nohup python app.py &，改用ExecStart=/usr/bin/python3 /opt/myapp/app.py+Type=simple - Node.js 服务：确保
node server.js不被pm2 start或forever包裹；若必须用 pm2，得设Type=forking并提供准确的PIDFile= - 加上
Restart=always和RestartSec=5，否则进程崩溃后不会自动拉起 - 务必设置
StandardOutput=journal和StandardError=journal，否则journalctl -u <service-name></service-name>查不到日志
journalctl 日志里出现 “Failed to start xyz.service: Unit xyz.service not found” 怎么办
这不是服务启动失败，而是 systemd 根本没识别到这个 unit 文件——常见于路径错、权限错、没重载配置。
systemd 只从固定路径加载 service 文件：/etc/systemd/system/（本地优先）、/run/systemd/system/（运行时生成）、/usr/lib/systemd/system/（软件包自带）。放错地方等于没写。
- 确认文件名以
.service结尾，且内容有至少一个[Unit]和[Service]小节 - 检查文件权限：必须是
root:root，且不能有 group/o 写权限（chmod 644安全，664会拒载） - 新增或修改后必须运行
systemctl daemon-reload，否则systemctl仍用旧缓存 - 用
systemctl list-unit-files --type=service | grep xyz验证是否已加载；没出现就说明路径或语法有硬伤
服务管理不是写个脚本丢后台就完事。真正难的是让 systemd 理解你的意图——它要精确知道进程何时算“活”，怎么重启，依赖谁，日志往哪记。少一个 Restart=，少一次 daemon-reload，都可能让服务在半夜静默退出。
