CachyOS 启动卡死：定位并止损 systemd 重启风暴

现象#

更新完成后安装了新内核：

1
linux-cachyos 7.1.5-1 -> 7.1.6-1
2
linux-cachyos-lts 6.18.40-1 -> 6.18.42-1

重启后连续出现短生命周期的启动记录：系统能进入图形界面，但大约一两分钟后失去响应，只能强制重启。last -x 中出现多次 crash，每次运行时间只有两三分钟。

这类问题不要先回滚整个系统快照。先保留证据，区分以下几类原因：

• 内核锁死、GPU reset、NVMe 或 Btrfs 错误；
• 内存耗尽和 OOM killer；
• 某个用户态服务崩溃并不断重启；
• 已卸载软件遗留的 systemd 单元持续失败。

环境#

• 系统：CachyOS / Arch Linux
• 内核：linux-cachyos 7.1.6-1
• GPU：AMD Radeon 680M，驱动 amdgpu
• 桌面会话：Niri Wayland
• 文件系统：Btrfs，系统盘为 NVMe
• 常驻客户端：atrust-bin 2.5.16.30-4

先确认是不是内核或硬件问题#

先看当前和上一轮启动中的高优先级日志：

1
journalctl -b -p warning..alert --no-pager
2
journalctl -b -1 -p warning..alert --no-pager
3
journalctl -k -b --no-pager | grep -Ei \
4
  'oom|hung|stall|lockup|gpu|amdgpu|nvme|btrfs|mce|hardware'

再检查失败单元、内存和启动历史：

1
systemctl --failed --no-pager
2
free -h
3
last -x | head -n 30

这次没有看到 OOM killer、amdgpu reset、NVMe timeout、Btrfs error、MCE 或 kernel lockup。内存也还有约 11 GiB 可用。

启动期间会出现少量 ACPI BIOS warning、VirtualBox 的 out-of-tree module taint 以及 clocksource 超时提示，但它们没有和卡死时刻形成因果链。排查时不要把“看起来可怕的 warning”当成根因，真正的失败通常会反复出现并带有明确的服务名、退出码或 coredump。

排查 systemd 服务#

接着筛选本次启动中的异常事件：

1
journalctl -b --no-pager -o short-iso | grep -Ei \
2
  'segfault|core-dump|restart|failed|oom|lockup|amdgpu|nvme|btrfs'
3

4
systemctl list-units --type=service --all --no-pager | \
5
  grep -E 'aTrust|clash|plasma|sddm|niri'

很快能看到两个稳定复现的问题。

1
aTrustAgent[...] segfault at 28 ... in libcrypto.so.1.1
2
systemd-coredump: Process ... (aTrustAgent) dumped core.
3
aTrustDaemon.service: Main process exited, code=dumped, status=11/SEGV

1
coredumpctl list --no-pager | tail -n 30
2
systemctl cat aTrustDaemon.service
3
systemctl show aTrustDaemon.service \
4
  -p ActiveState -p SubState -p Restart -p RestartUSec -p NRestarts \
5
  --no-pager

1
Restart=always
2
RestartSec=5s
3
KillMode=process

1
aTrustDaemon.service: Unit process ... remains running after unit stopped.
2
aTrustDaemon.service: Found left-over process ... while starting unit.

1
readelf -d /usr/share/sangfor/aTrust/resources/bin/aTrustAgent | grep NEEDED
2
ldd /usr/share/sangfor/aTrust/resources/bin/aTrustAgent | grep -E 'ssl|crypto|curl'

1
clash-verge-service.service: Failed at step EXEC spawning /usr/bin/clash-verge-service: No such file or directory
2
clash-verge-service.service: Main process exited, code=exited, status=203/EXEC

1
ExecStart=/usr/bin/clash-verge-service
2
Restart=always
3
RestartSec=5

根因#

本次事故的直接根因是两个服务共同构成的重启风暴，其中严重程度不同：

1. aTrustDaemon 是主因。 aTrustAgent 持续在其 OpenSSL 网络调用链中触发 SIGSEGV；服务策略强制重启，停止时又残留 aTrust 子进程。
2. clash-verge-service 是并存的配置债务。 它已经找不到可执行文件，却仍被设置为无限重启。
3. 新内核不是已证实的根因。 本次没有内核、GPU、存储或 OOM 级别错误可将卡死归因给 7.1.6-1。

排查结论应严格区分“与本次更新同时发生”和“由更新导致”。后者没有证据时，不应该为了求快就整体回滚。

止损#

如果当前不需要 aTrust VPN，可以先做可逆止损：停止并禁用两个单元，再清理 aTrust 残留 cgroup。

1
sudo systemctl disable --now clash-verge-service.service
2
sudo systemctl disable --now aTrustDaemon.service
3
sudo systemctl kill --kill-whom=all --signal=SIGKILL aTrustDaemon.service
4
sudo systemctl reset-failed aTrustDaemon.service

这里要注意两点：

• disable --now 同时处理当前运行实例和下次开机自启；
• aTrust 的停止脚本没有可靠结束全部子进程，所以额外使用 systemctl kill --kill-whom=all 清理整个服务 cgroup。

对于已卸载软件遗留的单元，后续可在确认不再使用后删除其 unit 文件；这次先禁用即可，避免扩大变更范围。

验证#

止损后不应只看 systemctl stop 返回成功，而要观察一段时间：

1
for unit in aTrustDaemon.service clash-verge-service.service; do
2
  echo "-- $unit --"
3
  systemctl is-enabled "$unit" || true
4
  systemctl is-active "$unit" || true
5
  systemctl show "$unit" -p ActiveState -p SubState -p NRestarts --no-pager
6
 done
7

8
pgrep -a -f 'aTrustAgent|aTrustXtunnel|clash-verge-service' || true
9
systemctl --failed --no-pager

本次操作后，两个服务均为：

1
disabled
2
inactive
3
ActiveState=inactive
4
SubState=dead
5
NRestarts=0

随后观察 75 秒，重启计数没有增长，未再发现 aTrust、aTrustXtunnel 或 Clash Verge 服务进程，systemctl --failed 也回到 0 个失败单元。观察窗口内没有新的 OOM、GPU、NVMe、Btrfs、lockup 或 segfault 记录。

这说明止损生效；它不等于 aTrust 已经修复，只是把已确认的故障源从启动路径中移除。

后续处理建议#

需要再次使用 aTrust 前，不要直接重新启用开机自启。更合理的顺序是：

1. 询问公司 IT 或供应商是否有适配当前 Arch/CachyOS、OpenSSL 与 Wayland 环境的新客户端；
2. 在独立测试窗口中手动启动 aTrust，收集新的 journalctl -u aTrustDaemon.service 与 coredumpctl 证据；
3. 若必须长期使用，优先寻找官方支持的容器、虚拟机或受支持发行版运行方式，而不是长期容忍一个 root 常驻崩溃服务；
4. 在确定稳定前保持服务禁用，只在确实需要 VPN 时临时启用并观察。

总结#

系统更新后出现卡死，并不代表新内核一定有问题。先用日志把问题缩小到具体服务，再检查其重启策略、子进程清理和资源变化，往往比盲目回滚更快、更安全。

这次真正需要移除的是 aTrust 的崩溃循环和遗留 Clash Verge 单元。停止、禁用并验证没有残留后，系统恢复稳定；而 aTrust 的兼容性修复则应作为独立问题继续处理。