一台 Ubuntu 20.04 的构建机原来手动加了 8G swapfile，后来删掉腾空间，重启后 ssh 登录要等一分半，systemd 日志里有一行 Job dev-disk-by swap.device/start running。
一开始怀疑是「条目用了 UUID 而 swapfile 重建后 UUID 已变，永远等不到设备」，查了一圈，方向不对。
原因不止一个，得分开看。fstab 里还有 swap 条目，systemd 会为它生成 device 单元并等满默认超时。也可能是swap 单元进入 failed 状态后，后续依赖它的服务整体被拖慢。
不容易想到的是，fstab 里还留着旧的 /dev/vdb2 路径，云盘挂载顺序变了找不到。
先看是哪个单元在等设备
systemctl list-units --failed && systemd-analyze blame | head再往下核对 fstab 里残留的 swap 行
grep -n swap /etc/fstab接着删掉失效条目并重新加载
cp /etc/fstab /etc/fstab.bak && sed -i '/swap/d' /etc/fstab && systemctl daemon-reload末了停掉残留的 swap 单元并确认启用项
systemctl stop 'dev-disk-by*.swap' 2>/dev/null; swapon --show同事提醒我看一下最近一次发布，时间点确实对得上。
改完先别撤，确认这几项。systemd-analyze blame 里不再出现等待 swap 的项，swapon –show 为空或只剩有效的 swap，重启后登录不再卡顿。
容易忽略的是，改 fstab 一定要先备份并用 mount -a 和 systemctl daemon-reload 验证；删 swap 文件前先 swapoff，否则文件一直被占用删不干净。报错文案容易误导，真正的原因往往在相邻那一层的日志里。