systemd修复

比起君子讷于言而敏于行，我更喜欢君子善于言且敏于行。

目录

场景

解决思路：

1. 重装

2. 热恢复

1）让 systemd 重新 exec 自身

2）手动拉起 D-Bus（它死了 systemd 就失联）

3）若 D-Bus 反复崩，把 systemd 与 DBus 一起重装，装完再次 kill -15 1 触发重载

4）验证

5）日志报错

总结

---

场景

前阵子为了丝滑迁移，拿到了一些虚拟机的包，放到服务器上给它们拉起来。之前都是正常的，这周遇到了一台难搞的机器，它是问题是这样的：systemctl start ssh失败，每次只要执行这个命令，虚拟机直接卡死，不停的让我重新输入密码，不得不硬重启。接着我发现，卸载ssh重装后是服务是正常的，但是呢，修改配置文件后sudo systemctl reload ssh ，正常。sudo systemctl restart ssh 失败，卡死，硬重启。接着我尝试去操作其他服务，比如docker，也是一样的现象。

定位问题为：systemd崩溃

解决思路：

1. 重装

有句经典的话怎么说来着？重启可以解决99%的问题，重装可以解决100%的问题。但是我这个是上古时期的设备，里面的服务没人知道到底咋搞的，我只能小心翼翼的全部copy。很显然不能重装。

2. 热恢复

1）让 systemd 重新 exec 自身

sudo kill -15 1

正常时 3-5 秒后systemctl is-system-running应返回running；
若仍卡，继续第 2 步。

2）手动拉起 D-Bus（它死了 systemd 就失联）

sudo /usr/bin/dbus-daemon --system --fork

再试systemctl status看是否恢复。

3）若 D-Bus 反复崩，把 systemd 与 DBus 一起重装，装完再次kill -15 1触发重载

sudo apt update sudo apt install --reinstall systemd libsystemd0 dbus

我重装的时候遇到了报错，是APT 源里版本不一致导致的，所以最好是用当前系统已装版本强行重装

# 1. 让 APT 只下载“已装版本”的 deb 包 sudo apt-get install --reinstall --download-only systemd libsystemd0 dbus \ libpam-systemd systemd-sysv # 2. 手动 dpkg 覆盖（不经过依赖检查） sudo dpkg -i --force-overwrite \ /var/cache/apt/archives/systemd_237-3ubuntu10.57_*.deb \ /var/cache/apt/archives/libsystemd0_237-3ubuntu10.57_*.deb \ /var/cache/apt/archives/dbus_*.deb \ /var/cache/apt/archives/libpam-systemd_237-3ubuntu10.57_*.deb \ /var/cache/apt/archives/systemd-sysv_*.deb # 3. 修复可能残留的依赖 sudo apt-get install -f

4）验证

sudo kill -15 1 # 让 systemd 重新 exec 自身 systemctl is-system-running # 应返回 running 或 starting journalctl -b -p err | tail -20 #若仍 degraded，查看最后20行systemd错误日志，继续搞

5）日志报错

一般吧，可能上面4）之后就结束了，很不幸，我这个还是有点子问题......

root:~# journalctl -b -p err | tail -20 -- Logs begin at Wed 2026-01-14 16:43:42 CST, end at Wed 2026-01-14 17:20:30 CST. -- Jan 14 16:53:41 10-198-11-111 systemd[1]: Timed out waiting for device dev-disk-by\x2dlabel-3F06\x2d266F.device.

问题解释：

Timed out waiting for device dev-disk-by\x2dlabel-4F05\x2d212F.device
→ fstab 里写了一个 LABEL=3F06-266F 的设备，系统找不到，导致该挂载单元失败，把整个系统拖进 maintenance 模式。

解决方案：

使用UUID去写/etc/fstab文件，我之前写错的是LABEL=3F06-266F，搞错了，应该是UUID=3F06-266F

root:~# blkid | grep 3F06-266F /dev/vda15: LABEL="UEFI" UUID="3F06-266F" TYPE="vfat" PARTUUID="4f41f-f98f-4270-ba-8d2aa2a7" root:~# cat /etc/fstab UUID=3F06-266F /boot/efi vfat defaults 0 0

最后再去执行，直到显示 running或者starting。

sudo kill -15 1 sleep 3 systemctl is-system-running

---

总结

问题链路：
raw 模板克隆
→ systemd 家族包部分升级 / 混源
→ PID 1 运行态与磁盘/库不一致
→ systemctl start/restart 阻塞
→ dbus system bus 不可用
→ ssh/docker 等全部“假死”

我的解法：
强制 systemd ABI 对齐
→ dpkg 覆盖安装
→ PID 1 re-exec
→ systemd 恢复一致运行态
→ 所有 service 恢复正常