直接查看服务日志比翻/var/log/零散文件更快；先用systemctl status确认状态，若failed则末尾红字是线索，再用journalctl -u服务名结合--since、-b、-p和grep精准定位错误；需启用持久化存储才能查历史崩溃日志。

直接看服务日志，重点抓启动失败和异常退出的痕迹，比翻/var/log/下的零散文件快得多。 先确认服务当前状态再查日志 systemctl status 服务名（如 firewalld.service 或 nginx.service）能快速告诉你服务是 active、failed 还是 inactive。如果显示 failed，末尾那行红字通常是关键线索，比如 “timeout exceeded” 或 “failed to start”。别只盯着这句，它只是结果，真正原因藏在 journalctl 的完整启动流程里。 用 -u 和 --since 快速定位最近一次崩溃 服务刚出问题，马上执行： journalctl -u 服务名 --since "5 minutes ago" --no-pager 加 --no-pager 是为了方便复制粘贴，避免卡在分页器里。 如果服务反复崩溃又自启，加 -b 只看本次开机后的日志： journalctl -u sshd.service -b --no-pager 这样能排除上次关机前的旧记录干扰。 聚焦错误和警告，跳过大量无关信息 日志太多时，用 -p 参数过滤优先级： journalctl -u docker.service -p err —— 只看 error 级别及以上（含 crit、alert、emerg） journalctl -u NetworkManager.service -p warning —— 警告也可能是隐患前兆，比如 DHCP 获取失败、证书过期提示 配合 grep 进一步缩小范围： journalctl -u postfix.service --no-pager | grep -i "refused\|denied\|timeout\|fail" 注意日志是否持久化，避免重启后“断档” 默认 journal 日志存在 /run/log/journal/，重启就清空。想查历史崩溃原因，必须启用持久存储： sudo mkdir -p /var/log/journal sudo systemctl restart systemd-journald 之后再用 journalctl --list-boots 就能看到多个启动记录，-b -1 就能查上一次开机的日志，对分析偶发性崩溃特别有用。 不复杂但容易忽略