journalctl 排查服务启动失败的套路

结论先说：服务起不来，多数答案就写在 journalctl -u 服务名 -xe 的输出里，先看日志再动手，比反复重启碰运气有效得多。 基本命令怎么用？ journalctl -u nginx 看 nginx 这个 unit 的全部日志；加 -n 100 只看最近一百行；-f 挂在尾部实时滚动，适合边改配置边观察；-xe 里的 e 是补充解释、x 是展开上下文，报错行下面的解释经常直接给出原因，比如"端口被占用""权限不足"。日志太长就接管道过滤：journalctl -u nginx --since today | grep -i error。 拿真实报错走一遍 日志里看到 bind() to 0.0.0.0:80 failed (98: Address already in use)，就不用再怀疑配置文件了：ss -tlnp | grep :80 找出占用端口的进程，停掉它或换监听端口，再启动，一气呵成。两个补充过滤：-p err 只看错误及以上级别，大日志先抓重点；--output short-iso 换成人读友好的时间戳，摘出来贴给同事更清楚。把报错原文原样丢进检索，命中同类案例的概率也不低。 这次开机之前的日志还在吗？ 在，但要指定启动序号。journalctl -b 只看本次开机以来的日志；journalctl -b -1 看上一次开机的，排查"开机没起来"全靠它。想按编号挑，journalctl --list-boots 列出历次开机，配 -b 编号用更直观。按时间过滤用 --since 和 --until，支持相对时间，比如 journalctl -u nginx --since "10 min ago"，也支持 "2026-10-01 08:00:00" 这种精确写法。 日志被轮转后怎么找？ journald 的日志默认可能只存内存，重启就没了。先确认持久化：ls /var/log/journal，目录存在才有历史；没有就 mkdir /var/log/journal && systemctl restart systemd-journald 开启。开启之后历史日志都归它管，journalctl 会自动跨文件检索，用 --since 指定时间段即可，不用自己翻归档文件。磁盘紧张的机器记得限制占用：/etc/systemd/journald.conf 里设 SystemMaxUse=500M，服务多的机器建议每次都设。 顺带一个习惯：改完配置 systemctl restart xxx 之后，立刻接一条 journalctl -u xxx -n 20，出问题马上能看到，不用等监控报警再来翻账。复盘后把报错行与处置命令记回运维手册，同类问题下次就是三分钟的事。