服务频繁崩溃重启需还原完整生命周期：先用systemctl status和journalctl -u 服务名 -b查状态与全量日志，抓“starting…”后及“failed”“timeout”等关键词；再查restart策略、dmesg确认oom killer、依赖目标就绪情况、应用自身日志及环境因素。
服务频繁崩溃重启，日志是第一线索。别只盯着最后一行报错，要还原从加载、启动、运行到退出的完整链条，重点抓“失败前一刻”发生了什么。
查 systemd 服务状态和原始日志
先确认服务是否真在反复重启：
- 运行 systemctl status 服务名，看 Active 状态是不是反复出现 “failed” 或卡在 “activating (auto-restart)”
- 用 journalctl -u 服务名 -b --no-pager 查本次启动中该服务的全部日志，不加时间限制，避免漏掉早期初始化错误
- 重点关注 “Starting…” 后面几行、“failed”、“timeout”、“denied”、“cannot access”、“address already in use” 这类关键词，前后各 3–5 行常含真实原因（比如配置文件路径写错、端口被占、用户不存在）
- 检查服务单元是否设置了自动重启策略：运行 systemctl show 服务名 | grep -E "(Restart=|RestartSec=)"，确认是 on-failure 还是 always，避免误判为“异常”
看内核和系统级上下文
很多服务失败不是自身问题，而是底层环境没准备好：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 执行 journalctl -b -p err，一次性列出本次启动所有 error 级别日志，快速定位根因：网络未就绪、时间未同步、磁盘挂载失败、OOM Killer 杀进程等
- 单独看内核事件：dmesg -b 或 journalctl -k -b，找 “Out of memory”, “Killed process”, “PCIe error”, “Hardware Error” 等关键提示
- 验证依赖目标是否就绪：journalctl --unit=network.target --unit=multi-user.target -b，如果 network.target 没 ready，很多服务会因超时直接退出
确认是否被 OOM Killer 终止
内存不足导致的“假性崩溃”很常见，进程不是自己退出，而是被内核强制杀掉后由 systemd 拉起：
- 运行 dmesg -T | grep -i "killed process"，看是否有类似 “Killed process 12345 (myapp) total-vm:123456kB, anon-rss:45678kB” 的记录
- 检查服务是否被设了内存限制：systemctl show 服务名 | grep Memory，留意 MemoryMax= 或 MemoryLimit= 的值是否过小
- 对比 free -h 和 ps aux --sort=-%mem | head -n5，看可用内存是否长期低于 100MB，或某个进程 RSS 占用突增
排除应用自身与外部干预因素
有些崩溃藏在应用日志里，不在 journal 中；有些则是被外部机制强制重启：
- 查服务主进程自己的日志文件（如 /var/log/myapp/error.log），找 panic、segmentation fault、uncaught exception、NullPointerException 等堆栈信息
- 确认是否启用了健康探针：比如 Kubernetes 的 liveness probe、supervisord、monit，它们可能因响应超时或返回 5xx 而触发重启
- 检查环境变量、配置文件权限（如服务以 www-data 运行，但配置文件属 root 且无读权限）、证书过期、时区不一致等静默失败点
