服务「装了却起不来」、开机偶发失败、改完 unit 不生效多数落在依赖顺序、Type 类型、环境变量与 drop-in 覆盖。本文把 systemd 服务管理从 unit 结构讲到systemctl排障便于对照本机验证。源码锚点路径 / 手册作用man systemd.serviceService 单元字段语义man systemd.unit通用单元、依赖、条件man systemctl启停、状态、编辑/etc/systemd/system/管理员单元与 drop-in/lib/systemd/system/软件包默认单元最小 service 示例[Unit] DescriptionExample daemon Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple ExecStart/usr/local/bin/mydaemon Restarton-failure [Install] WantedBymulti-user.target调用链systemctl start foosystemd PID1加载 unit / drop-in满足 After/Requires执行 ExecStart按 Type 判定就绪journal 记录enable → 写 want 链接 start → 解析依赖 → fork/exec → 状态 active/failed reload / daemon-reload → 重新加载单元定义重点知识Type 决定「成功」含义simpleExecStart 一拉起即认为启动默认常见。forking旧 daemon 双 fork需PIDFile。oneshot跑完即结束常配RemainAfterExityes。notify就绪后经sd_notify告知适合真正要等初始化完成的服务。选错 Type 会出现「systemctl 显示 active 但端口未听」或「一直 activating」。依赖与启动顺序After只排序不强制依赖Requires/Wants才表达依赖强弱。网络类服务优先Afternetwork-online.target并理解有的镜像没有真正的 online。drop-in 覆盖systemctl edit foo.service# 生成 /etc/systemd/system/foo.service.d/override.confsystemctl daemon-reload systemctl restart foo不要直接改/lib/systemd/system/里的包文件升级会被覆盖。排障命令systemctl status foo.service-lsystemctl show foo-pFragmentPath-pDropInPaths-pActiveState journalctl-ufoo-b--no-pager|tail-100systemctlcatfoo systemd-analyze verify /etc/systemd/system/foo.service失败常见原因ExecStart路径错、权限不足、缺环境变量、Typeforking无 PIDFile、依赖的 socket/网络未好。嵌入式注意只读根上 unit 放可写覆盖目录精简系统若无network-online.target避免死等。容器里 PID1 不一定是 systemd命令集合不同。