Journalctl 排查系统更新造成的服务兼容性日志

journalctl 是系统更新后排查服务启动失败的核心工具，通过时间（--since/--until/-b）、服务（-u）、优先级（-p）三锚点精准切片日志，结合 _COMM、_UID 等字段交叉验证配置、二进制、权限变更引发的兼容性问题。

系统更新后服务无法启动，核心是日志里藏着“不兼容”的蛛丝马迹。journalctl 不是翻日志，而是用时间、服务、级别三个锚点，把更新前后的关键行为切出来比对。

锁定更新时间窗口再查日志

更新时间就是故障起点。别猜，直接用 --since 定位：

• 如果刚执行完 yum update 或 apt upgrade，立刻查最近 30 分钟：journalctl --since "30 min ago"
• 若已知更新发生在今天上午 10:15，用精确时间框定：journalctl --since "2026-07-07 10:15:00" --until "2026-07-07 10:25:00"
• 更新后重启过？用 -b 看本次启动全程：journalctl -b；想对比重启前后，加 -b -1 看上一次启动日志

聚焦具体服务，看它启动时卡在哪

更新常导致单个服务崩，必须按服务单元过滤，且后缀不能省：

• 查 nginx 是否因配置语法变更失败：journalctl -u nginx.service -b
• 确认 docker 启动报错类型：journalctl -u docker.service --since "30 min ago" | grep -i "failed|error|permission"
• 服务名不确定？先运行 systemctl list-unit-files | grep your-service 确认注册名（比如是 mysql.service 还是 mariadb.service）

抓错误和警告，跳过冗余信息

更新引发的问题往往藏在 err 和 warning 级别里，info 和 debug 反而干扰判断：

• 只看 error 及以上：journalctl -u php-fpm.service -p err -b
• 连 warning 一起查（比如模块被弃用、参数已废弃）：journalctl -u httpd.service -p warning --since "1 hour ago"
• 常见兼容性关键词：Exec format error（架构不匹配）、No such file or directory（路径变更）、Failed to load configuration（配置格式升级）、permission denied（SELinux 或权限策略收紧）

交叉验证：进程、用户、配置文件变动线索

光看服务日志不够，得结合上下文还原现场：

• 查某个进程（如旧版二进制）崩溃前行为：journalctl _COMM=mysqld --since "20 min ago"
• 确认是否因用户或组变更导致权限问题：journalctl _UID=999 --since "1 hour ago"（替换为对应服务运行 UID）
• 导出结构化日志做文本分析：journalctl -u nginx.service -b --output=json > nginx-boot.json，方便用 jq 或脚本筛字段