Linux 服务启动顺序优化实践

必须同时配置 after= 和 wants=/requires= 才能确保依赖服务启动，仅 after= 仅控制顺序；usesyslog=yes 已被忽略；type=simple 不保证服务就绪，应改用 type=notify 或 execstartpost 检查健康状态。

systemd 服务依赖写错会导致启动卡住

很多服务看似配置了 After=network.target，但实际启动时仍等不到网络就失败——因为 After 只控制顺序，不建立依赖关系。真正起作用的是 Wants= 或 Requires=。

常见错误现象：systemctl status myapp.service 显示 activating (start) 卡住几十秒，日志里反复出现连接 refused；查 journalctl -u myapp.service -n 50 发现应用在尝试连 localhost:5432，但 postgresql.service 还没起来。

• 必须同时写 After=postgresql.service 和 Wants=postgresql.service（或 Requires=），否则 systemd 不会主动拉起依赖服务
• Requires= 失败会导致本服务直接 abort；Wants= 更宽松，适合非强依赖场景
• 避免循环依赖：比如 A Wants=B、B Wants=A，systemd 会拒绝加载并报错 Found ordering cycle
• 检查依赖链用：systemctl list-dependencies --reverse myapp.service

自定义服务中 UseSyslog=yes 实际无效

有些老文档建议加 UseSyslog=yes 让日志进 journald，但在现代 systemd（v240+）中这个配置项已被忽略，所有服务默认都走 journal，该字段纯粹是兼容占位符。

真实影响在于日志可检索性和调试效率：如果服务自己用 printf 或 echo 输出到 stdout/stderr，这些内容会被自动捕获；但如果服务后台化（如加了 nohup、重定向到文件、或调用 daemon()），journald 就收不到任何输出。

• 确认服务是否真正前台运行：ps aux | grep myapp 看有没有 ? 在 TTY 列，或者用 systemctl show myapp.service | grep Type；推荐设为 Type=simple（默认）或 Type=notify
• 禁用日志重定向：删掉 service 文件里的 StandardOutput=file:/var/log/myapp.log 这类行，让输出保持标准流
• 若必须写文件，用 StandardOutput=append:/var/log/myapp.log，但记得配好 logrotate，否则 journal 里看不到实时内容

multi-user.target 之前启动的服务容易被 kill

把服务设成 Before=multi-user.target 并不能让它“更早启动”，反而可能因系统初始化阶段资源未就绪而被强制终止——比如此时 cgroup、Namespace、甚至 /proc/sys/net 之类路径都还没完全 ready。

典型场景：想赶在 sshd 启动前做网络策略加固，结果服务刚 fork 就被 systemd 杀掉，journal 里只有 Killed 没有堆栈。

• 优先用 WantedBy=multi-user.target + 合理的 After=，而不是强行往前塞
• 真要抢在基础服务前运行，改用 WantedBy=sysinit.target，但必须确保不依赖任何用户空间设施（如 DNS、磁盘挂载、udev）
• 加 TimeoutStartSec=90 防止 systemd 因超时误判服务失败
• 用 systemctl cat myapp.service 确认最终生效的 unit 文件路径，避免被 /etc/systemd/system/ 下的覆盖版本干扰

服务启动慢但 systemctl status 显示 active (running)

active (running) 只代表主进程已 fork 成功，并不表示服务内部已 ready。比如一个 Go Web 服务可能 200ms 就启进程，但还要花 3 秒加载配置、连 DB、预热缓存——这期间发请求必然 502。

这时候靠 Type=simple 是不够的，必须让 systemd 知道“真正 ready”的信号点。

• 改用 Type=notify，并在代码里调用 sd_notify(0, "READY=1")（C）或用对应语言的 sdnotify 库（如 Python 的 systemd.daemon.notify("READY=1")）
• 没有代码修改权限？用 Type=exec + ExecStartPost=/bin/sh -c 'while ! curl -sf http://127.0.0.1:8080/health; do sleep 0.5; done'，但注意别引入死循环风险
• 检查 readiness：用 systemctl is-system-running 看是否到 running 状态；再用 systemctl show myapp.service | grep ActiveState 和 SubState 组合判断

最常被忽略的是：After= 和 Wants= 必须成对出现，且目标服务本身得是 enabled 的——哪怕只漏掉一个 systemctl enable postgresql.service，整个依赖链就断在起点。