■ space · 散文道

六个选项，卡片式

-p 阶梯，自高向低——journalctl -p warning..alert 可取区间 · -p err 是主力

为什么不直接读 /var/log/syslog？

老派 Linux 日志把纯文本文件写在 /var/log — syslog, auth.log, messages. systemd replaced that with systemd 用 the journal（日志库） 取代了它：由 . Plain grep cannot read it; journalctl 是唯一的前门；作为交换，按服务、时间、启动和严重度过滤都不用再练正则体操。

心智模型：日志库存一切，journalctl 负责查询。服务不需要自己的日志文件——systemd 下任何写到 stdout/stderr 的内容都自动落进日志库。volatile（存在 /run，重启即清空），因为 /var/log/journal 不存在。一次修好：

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

验证：ls /var/log/journal → 目录存在——启动记录开始累积而不是被清掉

行数、跟踪、unit

-n 把输出限制为最新 N 行（默认 10）。--no-pager 比看上去更重要：没有它，journalctl 会打开 less，你的脚本、管道或 ssh 单行命令就会卡在等按键上——任何要继续接管道的命令都该带上它。

journalctl -n 100                      # last 100 lines of everything
journalctl -u nginx -n 100             # last 100 lines from one unit
journalctl -n 100 --no-pager           # print and exit — perfect for piping

就是 journalctl 的 is journalctl's tail -f——新条目出现时实时流出。在第一个终端重启服务时，就在第二个终端跑它：一个面板 systemctl restart nginx，另一个面板 journalctl -u nginx -f，崩溃原因通常几秒内自己现形。

journalctl -f                    # everything, live
journalctl -u sshd -f            # just the SSH daemon, live
journalctl -u ollama -f -n 50    # live, but start with the last 50 lines

按 systemd unit 过滤——一个、多个，或精确匹配的替代写法： filters by systemd unit — one, several, or the exact-match alternative:

journalctl -u nginx                    # one unit, all history
journalctl -u nginx -u redis           # several units at once
journalctl _SYSTEMD_UNIT=nginx.service # exact match

-u <服务> 什么都没显示但服务明明在跑？unit 可能生出了收留关键输出的辅助 unit——挂掉的 web 应用有时把日志写进systemctl list-units --type=service | grep -i <guess>。同样的套路适用于 timer（systemctl list-timers 会列出名字），也适用于跑在 systemd --user 下的东西，加上 --user: journalctl --user -u pipewire -n 50.

时间与严重度

--since and --until 接受时间戳，也接受宽松的相对说法。时间窗配 unit，一行完成事故分诊——“

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

-p 按上面那张 syslog 阶梯过滤优先级。机器“表现怪异”时，journalctl -p err -b --since today 是最快的体检——回答“到底有没有东西在失败”，还不被例行 info 行打扰。

journalctl -p err -b                    # errors only, since this boot
journalctl -p warning..alert -u nginx   # a range of severities

启动批次

被你重启掉的崩溃还在日志库里。 启动即崩的服务会在本次启动之前产生日志行，而 journalctl 默默只显示当前启动。-b 用来选启动批次——对付“它坏了、我重启了、现在看不到报错”的最有用旗标：

journalctl -b                 # current boot only
journalctl -b -1              # previous boot
journalctl -b -1 -u sshd      # why SSH died last time
journalctl --list-boots       # index of stored boots

磁盘

先看看日志库花掉多少，再设上限——现在 vacuum 一次，配置行管永远：

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # keep newest 500 MB
sudo journalctl --vacuum-time=30d      # keep newest 30 days

要让上限永久生效，在 SystemMaxUse=500M 的 [Journal][Journal] 小节里设 /etc/systemd/journald.conf，然后 。大小上限加启动过滤，日志库就一直是工具，而不是慢性磁盘泄漏。

08先看哪个日志？

• journalctl——应用与服务的行为。systemd 管的一切都在这里，带索引、可过滤。默认第一站。
• journalctl -k / ——内核与硬件：OOM 击杀、USB 重置、磁盘错误。进程死得蹊跷时，先来这里找 OOM killer，再怪应用。 — kernel and hardware: OOM kills, USB resets, disk errors. If a process died mysteriously, look for the OOM killer here before blaming the app.
• ——只适用于自己做文件日志的应用（nginx 访问日志、PostgreSQL）。即便如此，启动报错通常仍会落进日志库。 — only for apps that do their own file logging (nginx access logs, PostgreSQL). Even then, startup errors usually still land in the journal.

同一套流程也适用于本地 AI 服务——ollama serve 的 unit 卡住时，journalctl -u ollama -n 100 立刻显示模型加载失败。这就是整张速查表：-u 选 unit，-f 跟踪，-n 行数，--since 时间，-p 严重度，-b 启动批次。六个旗标几乎覆盖 Linux 机器会问你的所有日志问题——而当问题是“systemd 服务为什么起不来”时，这些

速查表到此为止 · 未取一分毫 · 一切皆本地