先看 systemctl status 确认服务状态，再用 journalctl 查看详细日志。例如 nginx 启动失败时，systemctl status 显示 Active: failed，journalctl -u nginx 发现端口 80 被占用，结合两者可快速定位问题根源。
在 Linux 系统中，journalctl 和 systemctl status 是排查服务问题最常用的两个工具。它们互补性强：systemctl status 提供服务当前运行状态的概览，而 journalctl 提供详细的日志记录。结合使用能快速定位问题根源。
理解 systemctl status 输出
执行 systemctl status 服务名 可查看服务的基本信息：
- Active：显示服务是否正在运行（active (running)）或已失败（failed）
- Main PID：进程 ID，可用于进一步追踪
- Status：简要说明最近状态变化或错误提示
- Latest unit logs：部分系统会显示最后几条日志摘要
例如，看到 Active: failed 时，说明服务启动失败，但具体原因需要查日志。
用 journalctl 查看详细日志
当 systemctl status 显示异常后，应立即使用 journalctl 深入分析：
- journalctl -u 服务名.service：只查看该服务的日志
- journalctl -u 服务名.service --since "10 minutes ago"：聚焦最近时间段
- journalctl -u 服务名.service -f：实时跟踪日志输出（类似 tail -f）
- journalctl -u 服务名.service -n 50：查看最后 50 行
重点查找 ERROR、Failed、Cannot、Permission denied 等关键词。
联合诊断典型场景
以 nginx 启动失败为例：
- 运行 systemctl status nginx，发现 Active: failed
- 看到提示 “Main PID: 1234 (code=exited, status=1/FAILURE)”
- 执行 journalctl -u nginx --no-pager
- 日志中出现 “bind() to 0.0.0.0:80 failed (98: Address already in use)”
- 结论：端口被占用，需停止冲突进程或修改配置
systemctl 告诉你“出了问题”，journalctl 告诉你“哪里出问题”和“为什么”。
提升效率的小技巧
- 用 systemctl status 快速判断服务状态和最近一次操作结果
- 配合 journalctl -xe 查看用户会话级别的扩展日志（适合桌面环境）
- 使用 --no-pager 参数避免日志分页阻塞脚本处理
- 按时间过滤：journalctl --since yesterday 或 --until "2025-04-05 10:00"
- 结合 grep 过滤关键信息：journalctl -u ssh | grep "Failed password"
基本上就这些。掌握这两个命令的协作方式，大多数服务类故障都能快速解决。不复杂但容易忽略的是：先看状态，再查日志，按时间线对齐信息。
