Linux 服务自启动失败的排查

9次阅读

Failed to start 错误主因是服务进程启动后立即退出,需查 journalctl 日志、确认 ExecStart 命令可执行且前台运行、声明依赖(如 After=network.target)、启用服务(systemctl enable xxx.service)、检查条件指令及环境假设。

Linux 服务自启动失败的排查

systemd 服务启动时报 Failed to start 错误

多数自启动失败直接表现为 systemctl start xxx.service 或开机后 systemctl status xxx.service 显示 failed,且状态中带 Failed to start。这不是配置没生效,而是服务进程本身启动阶段就退出了。

关键排查动作:

  • 先看最近一次失败的完整日志:journalctl -u xxx.service -n 50 --no-pager,重点找 Started 后紧跟着的 Failed 行和其上方几行 stderr 输出
  • 检查 ExecStart= 指定的命令是否可执行、路径是否存在、权限是否正确(例如脚本缺少 +x
  • 确认该命令在前台运行:systemd 要求主进程不能 fork 后退出,否则会被判定为“启动完成即退出”。常见坑是启动脚本里写了 & 或调用了 nohup
  • 若依赖网络或挂载点,需显式声明:After=network.targetWants=network.target,否则可能因环境未就绪而秒退

服务配置文件写对了但开机不启动

配置文件存在、语法无误、手动 start 也成功,但 reboot 后没起来——大概率是没启用(enable),而非没加载(daemon-reload)。

验证与修复步骤:

  • 查是否启用:systemctl is-enabled xxx.service,返回 enabled 才算注册进开机流程;返回 disabledStatic 都不会自动启动
  • 启用命令必须带完整服务名:systemctl enable xxx.service(注意后缀!漏掉 .service 不报错但实际无效)
  • 如果服务类型是 Type=oneshot,默认不会持续运行,需加 RemainAfterExit=yes 才能被 enable 后参与依赖链
  • 修改配置后必须 systemctl daemon-reload,否则 enable 会基于旧版本生成 symlink

systemctl status 显示 inactive (dead) 但没报错

服务没崩溃、也没错误日志,但就是不活——常见于启动逻辑里做了静默退出判断,比如检测端口占用、配置文件缺失、或环境变量未设置时直接 exit 0

这类问题需要主动触发并观察行为:

  • systemctl start --no-block xxx.service 启动,再立刻 ps aux | grep xxx 看进程是否存在、存活多久
  • ExecStart= 命令前加 /bin/sh -c 'exec strace -f -o /tmp/xxx.strace ...'(临时调试),看它到底执行到哪一步就结束了
  • 检查 ConditionPathExists=ConditionFileIsExecutable= 等条件指令是否意外不满足,这些不会报错,但会让 systemd 直接跳过启动
  • 若服务由其他服务 WantedBy=,但那个目标单元(如 multi-user.target)本身没激活,也会导致不启动

非 root 用户服务无法自启动

用户级 service(放在 ~/.config/systemd/user/)开机不运行,不是 bug,是设计如此:systemd user instance 默认不随系统启动,需显式开启 linger。

解决方法很具体:

  • 启用用户 linger:sudo loginctl enable-linger $USER(必须用 sudo,普通用户无法给自己开 linger)
  • 确保用户 session 已通过 PAM 正确启动(桌面环境通常已处理,纯终端登录需确认 pam_systemd.so 已加载)
  • 用户服务启用命令是:systemctl --user enable xxx.service,且首次启用后需手动 systemctl --user start xxx.service 触发一次,后续才能随 login 自启
  • 注意:用户服务无法声明 WantedBy=multi-user.target,只能用 WantedBy=default.targetWantedBy=graphical-session.target

真正卡住的地方往往不在配置语法,而在服务自身对运行环境的隐含假设——比如认为 /tmp 可写、某个 socket 已监听、或者当前用户 uid 就是 1000。动手前先问一句:这个程序在 shell 里手动跑一遍,是不是也一样起不来?

text=ZqhQzanResources