systemctl status 服务 --no-pager是 failed、还是 activating 卡住、还是 inactive，附最近几行日志。
服务起不来怎么查
约 1266 字大约 4 分钟
2026-05-14
systemctl start 之后服务没起来——别急着反复 restart。systemd 和 journal 已经把失败原因记下来了，照着看就行。这篇是固定的排查路线：status 看状态、journalctl 看原因、配置检查、修复后验证。
阅读导览
服务起不来怎么查
按 systemctl status 看状态、journalctl 看失败原因、配置自检、修复后验证状态和端口的固定流程排查服务启动失败。
- status 看成没成,journalctl 看为什么
- 反复 restart 解决不了问题
- 很多服务自带配置检查命令
- 修复后要确认状态和端口都正常
命令速查
服务起不来排查清单
别急着 restartjournalctl -u 服务 -n 100 --no-pager服务为什么起不来，答案基本都在这。
nginx -t很多服务自带配置检查（nginx -t、sshd -t 等）。
ss -lntp确认端口真的起来了，不只是 status 显示 active。
第一步:status 看状态
systemctl status 服务 --no-pager先看 Active: 那行到底是什么状态：
failed—— 启动失败了，往下看日志找原因activating卡住 —— 启动卡在某一步，可能在等依赖、等网络inactive (dead)—— 根本没尝试启动，可能是没 enable、或被 maskactive (running)但功能不对 —— 进程起来了但行为异常，查应用日志
status 还会附最近几行日志，往往第一眼就能看到线索。
第二步:journalctl 看为什么
status 告诉你“成没成”，journalctl 告诉你“为什么”：
journalctl -u 服务 -n 100 --no-pager # 最近 100 行
journalctl -u 服务 --since "10 min ago" # 最近 10 分钟服务起不来的原因绝大多数都明明白白写在这里：配置语法错误、端口被占用、依赖的文件 / 目录不存在、权限不足、依赖的服务没起。反复 systemctl restart 不会让原因消失——它只是让你一次次撞同一堵墙。原因在日志里，不在重试里。
第三步：对症自检
根据日志里的线索，做针对性检查。很多服务自带配置检查命令，改完配置先自检再重启：
nginx -t # nginx 配置语法检查
sshd -t # sshd 配置检查常见根因和对应检查：
| 日志里的线索 | 检查什么 |
|---|---|
| 配置语法错误 | 用服务自带的 -t 检查，或核对刚改过的配置 |
Address already in use | ss -lntp 看端口被谁占了 |
Permission denied | 服务运行用户对相关文件 / 目录的权限（见 Permission denied 怎么查） |
No such file or directory | 配置里引用的路径是否存在 |
| 卡在 activating | 看它在等什么依赖、After= 的服务起没起 |
第四步：修复后验证
改完重启，别只看 status 显示 active 就完事——进程起来了不代表功能正常。多确认一步：
systemctl status 服务 # active (running)？
ss -lntp # 该监听的端口真的在监听了？
journalctl -u 服务 -f # 跟一会儿日志，确认没在反复重启Restart=on-failure 的服务可能在“起来→崩→自动重启→再崩”的循环里，status 抓拍那一下正好是 active，但其实一直在崩。跟一会儿日志才能确认真稳了。
改配置先备份,reload 优先于 restart
排查服务问题常常要改配置，守住两条：① 改之前 cp 备份原配置，改错能立刻回滚；② 能 reload 就别 restart——生产环境的 restart 意味着真实的服务中断，挑低峰期、想好回滚再做(见 服务生命周期)。systemctl status、journalctl 是只读的，放心用来收集证据，确认根因再动手改。
常见误区
| 误区 | 更稳妥的做法 |
|---|---|
服务起不来反复 restart | 原因在 journalctl -u 里，不在重试里 |
只看 status，不看 journalctl | status 说成没成,journalctl 说为什么 |
| 改完配置不自检直接重启 | 用服务自带的 -t 先检查配置语法 |
看到 active 就认为修好了 | 再 ss -lntp 验端口、跟一会儿日志确认没在反复崩 |
实践清单
练习清单
- 1对一个服务跑 `systemctl status --no-pager`，认一认 Active、Main PID、最近日志几部分。
- 2故意把某个服务的配置改错，重启它，用 `journalctl -u` 找到报错原因。
- 3对支持配置检查的服务（如 nginx）跑一次 `-t`，体会改完先自检的习惯。
- 4修复后用 `ss -lntp` 和 `journalctl -u -f` 双重确认服务真的稳了。
重点总结
要点回收
- status 看状态(failed/activating/inactive),journalctl -u 看失败原因——反复 restart 没用。
- 对症自检：配置用服务自带的 -t、端口占用看 ss、权限看运行用户。
- 修复后别只看 status active，再验端口、跟日志确认没在反复崩；改配置先备份。
版权所有
版权归属：Shuo Liu