服务启动失败时应按顺序执行 systemctl status、journalctl 查日志、systemctl cat 查配置、systemd-analyze verify 验证语法、systemctl show 检查环境，聚焦配置路径、权限、端口、环境变量四类问题。
服务启动失败时，systemctl 提供了完整的诊断链条，关键不是猜，而是按顺序查日志、看状态、验配置。
查看服务当前状态和最近错误
运行 systemctl status 服务名（如 systemctl status nginx），重点关注三部分：
- 第一行显示“active (failed)”或“inactive (dead)”，确认是否真的失败
- “Loaded”行会指出配置文件路径，检查是否加载了预期的 unit 文件
- 下方的 journal 日志片段（通常带红色文字）直接显示进程退出原因，比如 “failed to bind port 80” 或 “permission denied”
深入查看完整日志输出
journalctl 是核心排查工具，常用组合如下：
-
journalctl -u 服务名 -n 50 --no-pager：查看该服务最近 50 行日志，不翻页更易定位 -
journalctl -u 服务名 --since "2 minutes ago"：聚焦刚执行启动后的日志 -
journalctl -u 服务名 -f：启动服务同时用此命令实时跟踪输出（先开一个终端运行该命令，再在另一个终端执行systemctl start）
检查 Unit 文件语法与依赖关系
配置错误常导致 silent fail（无明显报错但无法启动）：
- 用
systemctl cat 服务名查看实际加载的 unit 文件内容，确认路径和内容符合预期 - 运行
systemctl list-dependencies 服务名 --reverse检查是否有未满足的 Before/After/WantedBy 依赖 - 用
systemd-analyze verify /etc/systemd/system/服务名.service验证语法（注意路径要写全）
模拟启动过程并捕获环境差异
有些服务失败是因为 systemd 环境与手动运行不一致：
- 用
systemctl show 服务名查看 Environment、WorkingDirectory、User 等实际生效值 - 尝试在相同上下文中手动运行 ExecStart 命令（注意替换 %i、%n 等变量，并加上 Environment 中定义的变量）
- 若服务需网络就绪，检查是否遗漏
After=network-online.target和Wants=network-online.target
不复杂但容易忽略。多数问题集中在配置路径错误、权限不足、端口被占、环境变量缺失这四类，顺着 status → journal → unit → 环境这条线走，基本能快速定位。
