systemd通过unit统一管理各类资源，socket activation需同步更新.Listenstream=，依赖需用Wants+After组合，Restart=on-failure不重启exit(0)，应结合SuccessExitStatus和journalctl深入排查。
systemd 不是传统 init 的简单替代，它把服务、套接字、挂载、定时器等全部抽象为“unit”，用统一模型管理生命周期和依赖——这意味着你不能只靠 systemctl start 就认为服务真在运行。
unit 类型决定启动逻辑和存活条件
同一个服务文件，.service 和 .socket 启动行为完全不同：.service 由 systemctl start 显式触发；而 .socket 单元启用后，systemd 会监听端口或 unix 套接字，只有首个连接到达时才按需拉起对应 .service（即 socket activation）。如果你改了服务监听地址但没同步更新 .socket 中的 ListenStream=，服务就永远不会被激活。
常见误操作：
- 把 Web 应用写成
.service，却在 nginx 反向代理里配成 upstream 到 localhost:8000，结果发现服务根本没启动——其实该用.socket+Accept=false模式 - 用
.path触发脚本处理文件，但忘了在 service 文件里加StartLimitIntervalSec=0，导致连续写入多次后被 systemd 限频拦截 -
.timer单元默认不启用OnBootSec=，若想开机 30 秒后首次运行，必须显式设置，否则只响应OnUnitActiveSec=
依赖声明不是启动顺序保证
After= 和 Wants= 只控制 unit 加载与启动请求的先后，不等待目标 unit 进入 active 状态。比如 After=network.target 并不意味网络已配置完成，只是 network.target 已被请求启动；真实需要 IP 地址的服务（如绑定到 0.0.0.0:8080 的 http 服务），应使用 After=network-online.target 并搭配 Wants=network-online.target，否则可能因网卡尚未获取地址而启动失败。
更隐蔽的问题：
-
RequiresMountsFor=/data比After=local-fs.target更可靠，后者不保证 /data 分区已挂载成功 - 数据库服务依赖 redis，写
After=redis.service不够，必须加Wants=redis.service，否则 redis.service 启动失败时你的服务仍会尝试启动 - 使用
BindsTo=可实现强耦合：若绑定的 unit 停止或失败，当前 unit 也会被自动停止
服务退出码直接决定 restart 行为
systemd 根据 ExecStart= 启动的进程退出码判断是否重启。默认情况下，仅当进程以非 0 状态退出且未配置 Restart= 时才不重启；但一旦设了 Restart=on-failure，连 exit(0) 都不会触发重启——除非你明确加上 RestartPreventExitStatus=0。很多 go/python 服务在收到 SIGTERM 后优雅退出并返回 0，结果 systemd 认为“正常结束”，不再拉起新实例。
典型配置组合：
-
Restart=always：不管什么退出码都重启（适合守护进程） -
Restart=on-abnormal：排除 0 和RestartPreventExitStatus指定的码（适合崩溃后恢复） -
SuccessExitStatus=0 143：把 SIGTERM（143）也视为成功退出，避免误重启 -
RestartSec=5：两次重启间隔至少 5 秒，防止快速失败循环
真正难调试的是那些“看似启动成功却无法响应请求”的情况——比如 socket activation 下服务进程已运行，但 stdout/stderr 被重定向到 journal 后没做日志轮转，磁盘满导致后续日志写入失败，systemd 无法感知，服务仍在 active 状态，只是内部卡死。这类问题必须结合 journalctl -u xxx.service -o cat 和 systemctl show xxx.service 查看 ActiveEnterTimestampMonotonic 与 ExecMainPID 是否匹配，而不是只信 systemctl status 的绿色 active 字样。