Arch Linux 系统卡死排查与修复记录

适用场景：Arch Linux 桌面突然完全冻结（鼠标键盘无响应、合成器画面卡死），只能强制关机。你会学到用 journalctl 定位异常启动会话、从时间线找出元凶（I/O 饱和、systemd 服务频繁重启、容器无内存上限）并逐一修复的完整排查思路。

问题现象

系统突然完全冻结，鼠标键盘无响应，Niri 合成器画面卡死，只能长按电源键强制关机。重启后需要找出原因。

排查工具

  • journalctl — systemd 日志，查看各启动会话
  • dmesg — 内核日志
  • systemctl — 服务状态管理
  • docker stats — 容器资源监控

日志分析

通过 journalctl --list-boots 查看所有启动历史，定位到卡死时的会话（boot -1）：

IDX  BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -1  15803db...  Sun 2026-07-19 13:15:37 CST  Sun 2026-07-19 13:49:15 CST
  0  d02c25f...  Sun 2026-07-19 13:50:51 CST  Sun 2026-07-19 14:32:15 CST

中间仅间隔 1.5 分钟，说明 boot -1 非正常关机。

卡死会话时间线

时间事件
13:15:37系统启动，用户登录
13:17Telegram 启动
13:18批量打开 kitty 终端
13:15~13:40Docker 容器运行：5.9G 内存峰值，25 分钟内写入 7.9GB 磁盘、读取 2.3GB
13:32ant-chrome 自动化浏览器启动
13:42Firefox：3.9G 内存峰值，10 分钟 CPU
13:49:15日志中断（长按电源键强制关机）

根因分析

元凶一：Docker 容器写爆磁盘（主因）

docker-6b48aff...scope:
  Consumed 52.193s CPU time over 24min 58.983s wall clock time,
  5.9G memory peak,
  2.3G read from disk, 7.9G written to disk.

一个 Docker 容器在 25 分钟内写入 7.9GB、读取 2.3GB 数据，峰值内存 5.9GB。持续的 I/O 负载压满 NVMe 带宽，导致 Niri 合成器无法获取帧缓冲。

元凶二：axonhub.service 每 5 秒失败重启

$ systemctl --user status axonhub.service
     Active: activating (auto-restart)
    Process: ExecStart=/home/shial/.local/bin/axonhub
             (code=exited, status=203/EXEC)

查看服务文件：

[Service]
ExecStart=%h/.local/bin/axonhub
Restart=on-failure
RestartSec=5

二进制文件 /home/shial/.local/bin/axonhub 根本不存在，但 systemd 每 5 秒 fork 一次失败进程，重启计数器飙到 379+ 次。每次重启都触发 systemd 调度 + journald 写日志，形成无意义的资源消耗叠加。

而真正的 axonhub 其实在 Docker 中正常运行，这个 systemd 服务是旧的残留配置。

元凶三：Docker 容器无内存上限

$ docker inspect axonhub --format '{{.HostConfig.Memory}}'
0   # 0 = 无限制

三个容器均可使用全部 30GB 内存，Docker + Firefox 合计约 10GB，在 I/O 饱和时进一步加剧系统压力。

触发链

Docker 容器 I/O 激增 (7.9GB/25min)
    ↓
NVMe 磁盘带宽饱和
    ↓
Niri 合成器 DRM page flip 阻塞
    ↓
桌面完全冻结 → 只能长按电源键强制关机

修复方案

修复一：停用无用的 axonhub.service

systemctl --user stop axonhub.service
systemctl --user disable axonhub.service

删除残留的 systemd 用户服务，消除每 5 秒的 fork 开销。

修复二：Docker 容器添加内存上限

根据容器实际使用量设置合理上限：

docker update --memory 512m --memory-swap 1g axonhub
docker update --memory 256m --memory-swap 512m octopus
docker update --memory 256m --memory-swap 512m openlist

验证结果

$ systemctl --user status axonhub.service
○ axonhub.service - AxonHub AI Gateway
     Active: inactive (dead)

$ docker stats --no-stream
CONTAINER ID   NAME       MEM USAGE / LIMIT
25b88354a29b   axonhub     61.72MiB / 512MiB
f499698fce21   octopus     31.6MiB  / 256MiB
76899497df6b   openlist    41.97MiB / 256MiB

关于 zram

$ zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL
/dev/zram0 zstd         15.4G   4K   64B   20K

当前 zram 使用量为零（15.4G 空闲），并非卡死原因。卡死是磁盘 I/O 饱和，而非内存不足触发 swap 压缩。zram 的中文名是 zram，不是 zwap。

总结

类别问题修复
🔴 主因Docker 容器 25 分钟写 7.9GB 磁盘已加内存上限，避免 I/O 暴增
🟡 辅因axonhub.service 每 5 秒失败重启已停用
🟢 潜在容器无内存上限已设置 256M~512M 限制

排查的关键是善用 journalctl -b 查看不同启动会话的日志，从时间线中定位异常进程。这次卡死的本质是 I/O 饱和导致合成器阻塞，修复后系统响应恢复正常。

验证与自查

  1. journalctl --list-boots 能列出各启动会话，异常关机（非正常结束）的会话一目了然
  2. systemctl --user status axonhub.service 状态为 inactive (dead)，不再每 5 秒重启
  3. docker stats --no-stream 中每个容器内存使用低于所设 limit（axonhub < 512MiB 等）
  4. 卡死复现时先用 zramctl 确认 zram 使用率，排除内存不足，再查 journalctl -b -1 的 I/O 时间线

参考