journalctl 是 systemd 日志管理核心工具，支持按服务、时间、优先级筛选和实时跟踪日志，结合 systemctl status 与上下文分析可快速定位服务启动失败根本原因。

journalctl 是 systemd 日志管理的核心工具，能直接查看服务启动、崩溃、配置错误等全过程记录，比翻找分散的 /var/log/ 下日志文件更高效、更准确。

快速定位某个服务的完整日志

用 -u 选项指定服务名，例如排查 nginx 是否正常启动：

• journalctl -u nginx.service —— 查看该服务所有历史日志（从最早到最新）
• journalctl -u nginx.service -n 50 —— 只显示最近 50 行
• journalctl -u nginx.service --since "2024-05-20 14:00" —— 查指定时间之后的日志

注意：服务名要带 .service 后缀；若不确定全名，可用 systemctl list-units --type=service | grep nginx 先确认。

实时跟踪服务日志并高亮错误

加 -f 实时滚动输出，配合 --priority 筛选严重级别：

• journalctl -u sshd.service -f —— 实时看 sshd 日志
• journalctl -u docker.service -f -p err —— 只实时显示错误（err）及以上级别（如 alert、crit）
• journalctl -u mariadb.service -p 3 —— -p 3 等价于 err（0=emerg, 1=alert, 2=crit, 3=err）

错误信息常含关键词如 “failed”、“cannot bind”、“permission denied”、“timeout”，可配合 grep 过滤：journalctl -u httpd.service | grep -i "fail\|denied"

识别服务启动失败的根本原因

很多服务“启动失败”其实卡在依赖或配置阶段，需结合多维度日志分析：

• 先看服务最终状态：systemctl status nginx.service —— 输出里会提示“failed”及最近一条错误行
• 再查完整启动过程：journalctl -u nginx.service --since "2024-05-20" --no-pager —— 加 --no-pager 避免分页干扰，方便复制粘贴
• 重点检查 “Starting…” 后紧跟着的几行 —— 失败通常发生在第一处报错，比如配置语法错误、端口被占、证书路径不存在
• 若提示 “Unit not found”，说明服务单元文件缺失或名字拼错；若提示 “Activation via systemd failed”，可能是依赖服务（如 network.target）未就绪

清理与持久化日志提升排查效率

默认 journal 日志只存在内存或 /run/log/journal（重启丢失），长期排查建议启用持久存储：

• 创建日志目录：sudo mkdir -p /var/log/journal
• 重启 journald：sudo systemctl restart systemd-journald
• 查看当前日志占用：journalctl --disk-usage
• 清理旧日志（保留最近 7 天）：sudo journalctl --vacuum-time=7d
• 限制最大用量（如 200MB）：sudo journalctl --vacuum-size=200M

日志过大时，--no-pager 和重定向到文件（journalctl -u app.service > debug.log）更利于后续分析。

掌握这几个常用组合，90% 的服务异常都能在几分钟内定位到关键线索。不复杂但容易忽略的是：别只盯最后一行报错，要回溯启动上下文，尤其关注 “Loaded”、“Active”、“Started” 状态变化之间的日志断层。