最直接有效的方式是用 journalctl -u 查指定服务的完整日志，再配合 systemctl status 快速定位状态和关键线索——两者结合才是排查 systemd 服务问题的标准路径。
最直接有效的方式是用 journalctl -u 查指定服务的完整日志，再配合 systemctl status 快速定位状态和关键线索——两者结合才是排查 systemd 服务问题的标准路径。
用 journalctl 查服务全量日志
所有由 systemd 管理的服务日志都由 journald 统一收集，journalctl -u servicename.service 是查日志的权威命令：
- 查全部日志：
journalctl -u nginx.service - 只看最近 50 行：
journalctl -u mysql.service -n 50 - 实时跟踪（类似 tail -f）：
journalctl -u sshd.service -f - 查本次启动后的日志（排除旧 boot 干扰）：
journalctl -b -u docker.service - 按时间范围查：
journalctl -u httpd.service --since "2026-07-28 14:00" --until "2026-07-28 15:30"
用 systemctl status 快速确认状态和线索
systemctl status 不是查日志主力，但能一眼判断服务是否真正在跑，并给出关键诊断入口：
- 看 Active: 行：只有
active (running)才算健康；failed或inactive (dead)都需立即跟进 - 留意 Main PID 和 Process: 行：若 PID 为 0 或出现
ExecStart=...后紧接报错，说明启动命令本身失败 - 末尾几行日志是摘要，够初步判断；真正原因得靠
journalctl -u xxx --since "XX:XX"往前翻 -
Loaded: 行末路径可直接
cat查 unit 文件，确认配置是否被 mask 或路径错误
精准过滤和聚焦关键信息
原始日志往往冗长，用这些方式快速抓重点：
- 只看错误：
journalctl -u redis.service -p err（-p支持 debug/info/warning/err/crit） - 按 PID 追查（从 status 输出复制 PID）：
journalctl _PID=1234 - 高亮关键词：
journalctl -u nginx.service | grep -i "timeout\|refused\|failed" - 导出分析：
journalctl -u php-fpm.service --since "1 hour ago" > php-debug.log
确保日志可长期追溯
默认 journal 日志存在内存或 /run/log/journal（重启即丢），如需保留历史记录并控制磁盘占用：
- 启用持久化：
sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald - 限制大小和保留期：在
/etc/systemd/journald.conf.d/limit.conf中写入SystemMaxUse=500MMaxRetentionSec=4week - 手动清理：
sudo journalctl --vacuum-time=30d或--vacuum-size=200M
