必须同时配置 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、BWants=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，整个依赖链就断在起点。
