服务反复重启怎么排查
服务起来又挂、反复循环，通常是配置错误、依赖服务未就绪、端口被占用或资源超限触发了重启策略。排查要先看清重启策略与实际失败原因：状态摘要给的是结论，细节在日志里；确认根因修复后，再考虑调整重启参数。高频重启本身会放大资源与日志压力，必要时先把自动重启关掉或用启动频率限制稳住现场。
基本信息
| 状态查看 | systemctl status 服务名 查看摘要 |
|---|---|
| 日志查看 | journalctl -u 服务名 --since 时间范围 |
| 重启策略 | systemctl show 查看 Restart 与重启次数 |
| 启动命令 | 查看 ExecStart、User 与 Environment 配置 |
| 失败复位 | systemctl reset-failed 后重新启动 |
典型使用场景
- 服务部署后持续重启，需要找到真实失败原因
- 配置改动后服务无法启动，核对生效的配置内容
- 依赖的数据库或中间件未就绪，服务启动即退出
- 端口被占用导致启动失败并要求反复重试
- 内存超限被杀后由重启策略拉起，表现为间歇性可用
- 梳理单元依赖关系，避免启动顺序导致的偶发失败
观察与复位
观察与复位
systemctl status app-web --no-pager | head -20 # 状态摘要与最近日志
journalctl -u app-web --since '30 min ago' | tail -50 # 关键：真实失败原因
systemctl show app-web -p NRestarts -p Restart # 重启次数与策略
systemctl show app-web -p ExecStart -p User -p Environment # 启动参数与身份
systemctl show app-web -p Requires -p After # 依赖与顺序关系
ss -lntp | grep <端口> # 确认端口是否被占用
systemctl reset-failed app-web && systemctl start app-web # 复位后重启
systemctl list-dependencies app-web --no-pager | head常见原因与线索
| 原因 | 线索 | 处理方向 |
|---|---|---|
| 配置错误 | 启动即退出并打印参数错误 | 核对生效配置并校验语法 |
| 依赖未就绪 | 日志提示连接失败或超时 | 补充顺序依赖或加等待逻辑 |
| 端口被占用 | 提示地址已在用 | 找到占用进程并调整端口 |
| 内存超限 | 被内核终止且无应用日志 | 调整内存上限与配额 |
| 权限不足 | 文件或目录访问被拒 | 核对运行用户与路径权限 |
高频重启会放大资源消耗与日志量，可能引发连锁故障；排查期间可临时把自动重启关闭或限制启动频率，先把现场稳住再定位原因。
状态摘要只给出结论，日志才是原因所在；两步都要看，只看状态容易得出「服务异常」这种无法行动的结论。