systemd多阶段启动应通过target单元建模阶段、依赖关系编排顺序；耗时操作用Type=notify或forking配合通知机制；状态共享用标记文件或EnvironmentFile；失败隔离靠StartLimit*和RestartPreventExitStatus等策略。
编写复杂的多阶段 systemd 启动服务，核心不是拼凑多个脚本，而是用 systemd 原生机制表达“阶段”逻辑——靠依赖编排、目标分组和单元类型组合来实现，而非在单个 .service 里写一堆 if-else 或 sleep 等待。
明确“阶段”本质：用 target 和依赖替代手动调度
systemd 不支持“阶段”这个概念，但可以用 .target 单元模拟。每个“阶段”对应一个自定义 target，比如 stage-precheck.target、stage-init-db.target、stage-start-app.target。它们本身不运行任何命令，只作为依赖锚点：
- 把预检脚本做成一个
Type=oneshot服务，并设WantedBy=stage-precheck.target - 数据库初始化服务设
After=stage-precheck.target且WantedBy=stage-init-db.target - 主应用服务设
After=stage-init-db.target，这样它就天然“等前一阶段完成才启动”
处理耗时操作：避免阻塞，用 proper type + 通知机制
如果某个“阶段”需要长时间运行（如数据迁移），不能用 Type=simple 干等，否则 systemd 会超时失败。推荐两种方式：
OpenExec — Deterministic Execution Boundary for Agent Systems
下载
源分发确定性执行服务，采用固定依赖。仅在带有签名审批制品（ClawShield模式）时运行，并产生可验证的输出...
-
forking 模式：程序启动后 fork 子进程并退出父进程，systemd 通过
PIDFile=跟踪子进程。适用于传统守护进程 -
notify 模式：程序前台运行，调用
systemd-notify --ready主动通知“本阶段就绪”，配合Type=notify和NotifyAccess=all。更可靠，适合 Python/Go 等现代语言
跨阶段状态传递：用文件或 systemd 环境变量
systemd 本身不提供跨服务的变量传递，但可通过轻量方式共享状态：
- 写入固定路径的标记文件（如
/run/myapp/stage1.done），后续服务用ExecStartPre=/bin/sh -c '[ -f /run/myapp/stage1.done ]'校验 - 用
EnvironmentFile=加载统一配置文件，其中可包含阶段结果（如DB_READY=yes） - 避免用环境变量直接传动态值（如端口号），优先通过配置文件或 IPC 通信
增强健壮性：失败隔离与重试控制
多阶段中某一步失败，不应让整个链路卡死。关键配置包括：
-
StartLimitIntervalSec=60和StartLimitBurst=3：限制某服务 60 秒内最多重启 3 次，防止单点反复崩溃拖垮流程 -
RestartPreventExitStatus=10：若脚本退出码是 10（例如“跳过该阶段”），不触发重启 - 对非关键阶段，用
BindsTo=替代Requires=，前者失败则下游也停，后者只影响启动顺序
