最有效方法是用 journalctl -u 服务名.service -n 10 -p err 提取最后十行错误日志，因 systemctl status 仅显示最近 3–4 行摘要；需结合 active 状态、process 退出码和 loaded 路径综合判断故障原因。
直接用 systemctl status 就能快速看到故障服务的详细运行状态和最近几行日志，但默认只显示最后 3–4 行。要稳定获取“最后十行报错日志”，需配合 journalctl 精准提取。
查看故障服务的详细运行状态
执行：
sudo systemctl status 服务名.service（例如 sudo systemctl status nginx.service）
重点关注以下字段：
-
Active: 显示
failed或inactive (dead)表示异常；若为active (running)但功能异常，可能是子进程崩溃或响应超时 -
Process: 查看
ExecStart=后的命令及退出码（如code=exited, status=1），这是启动失败的直接线索 - Loaded: 确认单元文件路径是否正确，避免配置被覆盖或软链接损坏
- Logs: 底部默认显示最近 3–4 行 journal 日志，常含关键错误关键词（如 “permission denied”、“address already in use”）
提取控制台输出的最后十行报错日志
systemctl status 不支持固定输出 10 行错误日志，必须用 journalctl 替代：
执行：
sudo journalctl -u 服务名.service -n 10 -p err
说明：
-
-n 10：只取最新 10 行 -
-p err：仅过滤 error 及以上级别（err、crit、alert、emerg），排除 info 和 debug 干扰 - 若服务刚失败，可加
-b限定本次启动会话：sudo journalctl -u 服务名.service -b -n 10 -p err
补充技巧：快速定位报错源头
如果 journalctl -p err 仍显冗余，可进一步聚焦：
- 用
grep高亮关键词：sudo journalctl -u 服务名.service -n 50 | grep -i "fail\|error\|timeout\|denied" - 从
systemctl status输出中复制主 PID（如Main PID: 12345），再查专属进程日志：sudo journalctl _PID=12345 - 导出分析：
sudo journalctl -u 服务名.service -b -p err -n 20 > debug.log
验证是否真为控制台输出（stdout/stderr）
部分服务将日志重定向到文件而非 systemd journal，可检查其 unit 文件：
sudo systemctl cat 服务名.service | grep -E "(StandardOutput|StandardError|ExecStart)"
若发现类似 StandardError=journal 或未重定向，则 journalctl 确实捕获的是控制台输出；若重定向到 /var/log/xxx.log，则需同步查看对应文件。
