systemd failed units 与 reboot-required：服务器状态不干净时怎么看

这个主题来自一次真实巡检：OpenClaw 和 Nginx 都正常工作，但系统同时出现了 systemctl --failed 里的 failed units，以及 /var/run/reboot-required 提示。它不是“网站立刻坏了”，而是说明服务器进入了需要维护的状态。

如果只记一句话：

服务是否在线，只说明当前请求能不能处理；failed units 和 reboot-required 说明这台机器的系统状态是否干净、是否需要安排维护窗口。

---

1. systemd 是什么

现代 Linux 服务器上，大部分后台服务都由 systemd 管理，例如：

• SSH
• Docker
• Nginx
• OpenClaw Gateway 的用户服务
• 网络初始化任务
• 定时任务和 timer

systemd 不只负责“启动服务”，还会记录服务是否启动成功、是否崩溃、是否启用开机自启。

因此，日常巡检不能只看网页能不能打开，还要看 systemd 眼里的系统状态。

---

2. failed units 代表什么

systemctl --failed 会列出当前处于 failed 状态的 units。

failed 不一定等于业务不可用。常见情况有：

• 某个非关键服务启动失败
• 启动阶段等待网络超时
• 某个硬件/固件更新服务失败
• 某个服务曾经失败，但主业务已经绕过它继续运行

例如巡检里出现的：

• fwupd-refresh.service
• systemd-networkd-wait-online.service

这类问题通常不是立刻中断业务的故障，但它们会污染系统状态。长期不看，会导致真正故障出现时你分不清哪些是旧问题，哪些是新问题。

---

3. reboot-required 代表什么

Ubuntu/Debian 系统在安装某些关键更新后，会写入：

/var/run/reboot-required
/var/run/reboot-required.pkgs

它表示：

有些更新已经安装到磁盘上，但当前运行中的内核或核心库还没切换到新版本。

常见触发项包括：

• Linux kernel
• systemd
• libc6
• dbus
• 低层系统库

这次巡检就是这种情况：系统提示新内核和核心包需要重启后生效。

---

4. 为什么不是更新完就万事大吉

Linux 更新分两层：

1. 包文件更新到磁盘
2. 正在运行的进程切换到新版本

很多普通软件更新后，重启服务就够了。
但内核、系统库、systemd 这类底层组件，通常需要整机重启。

如果不重启：

• 漏洞补丁可能没有真正应用到当前运行内核
• 系统显示已安装新版本，但实际仍跑旧版本
• 后续排障时版本判断会混乱
• 下次不可控重启时，才暴露启动问题

所以 reboot-required 不是紧急报警，但它应该进入维护计划。

---

5. 什么时候应该重启 VPS

个人 VPS 不建议一看到提示就立刻重启，尤其机器上跑着 OpenClaw、Nginx、Docker、自动化任务。

更稳的做法是：

1. 确认 SSH 仍可用
2. 确认关键服务有开机自启
3. 确认没有正在进行的重要任务
4. 安排一个可接受的维护窗口
5. 重启后立刻复查

重启后重点检查：

• SSH 是否还能连
• OpenClaw Gateway 是否恢复
• Nginx / Docker 是否恢复
• 80/443 端口是否正常
• systemctl --failed 是否清理
• /var/run/reboot-required 是否消失

---

6. 自动更新和自动重启的取舍

服务器安全更新可以自动化，但自动重启要谨慎。

自动安全更新的优点

• 减少漏补安全漏洞
• 降低维护负担
• 对个人 VPS 很实用

自动重启的风险

• 服务没有正确开机自启会直接下线
• 重启后 SSH 或网络异常会造成远程不可达
• 半夜自动重启可能影响正在运行的任务
• 如果没有 VNC/控制台兜底，恢复成本更高

所以更推荐：

自动安装安全更新，但重启由你或维护流程确认后执行。

---

7. 和当前服务器的关系

这台 VPS 现在承担了：

• OpenClaw Gateway
• 飞书入口
• Gmail monitor
• Nginx + tech-kb
• Uptime Kuma / Dozzle 等本地服务

这意味着它不是一次性测试机，而是逐渐变成个人基础设施节点。

对这种机器，巡检重点不是“有没有报错”这么简单，而是判断它是否处于可维护状态：

服务在线 + 系统状态干净 + 更新策略明确 + 重启路径可控

如果系统长期处于 reboot-required 状态，短期也许没事，但安全和可恢复性会变差。

---

推荐阅读

DigitalOcean：How To Use systemctl to Manage Systemd Services and Units

https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

推荐原因：系统性解释 service、unit、status、restart、enable，适合建立 systemd 的基础模型。

nixCraft：Systemd systemctl list all failed units/services on Linux

https://www.cyberciti.biz/faq/systemd-systemctl-list-all-failed-units-services-on-linux/

推荐原因：短平快，适合当作查看 failed units 的操作备忘。

Linux Audit：Using unattended-upgrades on Debian and Ubuntu

https://linux-audit.com/using-unattended-upgrades-on-debian-and-ubuntu/

推荐原因：解释自动安全更新、日志位置，以及 /var/run/reboot-required 的作用。

Linux Audit：Troubleshooting a failed systemd unit

https://linux-audit.com/systemd/troubleshooting-a-failed-systemd-unit/

推荐原因：适合以后遇到某个服务启动失败时，按排错思路查 journal、unit 配置和依赖关系。