直接用 journalctl -u 服务名查日志并结合 systemctl status 看状态和退出码，可定位大多数启动失败原因；关键在于还原从加载到失败的完整过程，而非仅看报错行，需依次确认服务状态、日志持久化、启动全链路、依赖上下文及精确时间窗口。
直接用 journalctl -u 服务名 查日志，再结合 systemctl status 看状态和退出码，基本就能定位大多数启动失败原因。关键不是看报错那一行，而是还原服务从加载到失败的完整过程。
先确认服务状态和日志是否可用
运行 systemctl status nginx.service（把 nginx.service 换成你的服务名），注意末尾红字提示的失败信息和退出码（比如 Result: exit-code 或 Result: timeout）。这一步能快速判断是配置问题、权限问题还是超时卡死。
接着检查日志是否持久化：执行 ls -A /var/log/journal/。如果目录为空或提示 “No journal files were found”，说明日志没存盘，需先启用持久化：sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
聚焦服务自身的启动全过程
不要只看最后一行错误，要查它从开始到失败的整条链路：
- 查最近一次启动的全部日志：
journalctl -u nginx.service -b --no-pager - 只看错误及以上级别：
journalctl -u nginx.service -b -p err - 定位关键动作前后几行：
journalctl -u nginx.service -b --no-pager | grep -A 3 -B 3 "Starting\|failed\|timeout\|denied"—— 配置路径错、端口被占、证书文件权限不足等真实原因，往往就藏在这些关键词附近
关联系统上下文找根因
很多“服务失败”其实是依赖没到位。比如网络没通、挂载点没就绪、时间不同步：
- 查本次启动所有 error 级日志：
journalctl -b -p err，快速发现 OOM killer 杀进程、network-online.target超时等系统级异常 - 单独看内核事件：
journalctl -k -b，确认是否有硬件报错、驱动加载失败或内存不足痕迹 - 验证关键目标单元：
journalctl --unit=network.target --unit=multi-user.target -b，如果 network.target 没 ready，很多服务会直接超时退出
精准锁定时间窗口缩小排查范围
对偶发或部署后立即失败的情况，“最近日志”太模糊，得精确到秒：
- 操作前记下时间：
start=$(date -Iseconds) - 启动服务后立刻执行：
journalctl --since="$start" --until="$(date -Iseconds)" -u nginx.service -p err > debug.log - 若不确定服务名，先用
systemctl list-units --type=service --state=failed列出刚失败的单元
