没人想负责的 Systemd Bug

I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content of the article (excluding the source line you already provided) here? Once I have the text, I’ll translate it into Simplified Chinese while preserving the original formatting and markdown.

TL;DR

存在一个命名空间错误，影响 Ubuntu 20.04、 22.04 和 24.04 服务器，导致随机的服务失败。自 2021 年起在 systemd、Ubuntu、Fedora 和 Red Hat 的跟踪系统中都有报告。大多数报告要么已过期，要么标记为 “not‑our‑bug”。只有重启才能解决它。

如果你在运行 Ubuntu 服务器，并且在日志中看到过以下信息：

Failed to set up mount namespacing: /run/systemd/unit-root/dev: Invalid argument
Failed at step NAMESPACE spawning: Invalid argument
Main process exited, code=exited, status=226/NAMESPACE

恭喜你。你遇到了 Linux 生态系统中最令人沮丧的 bug 之一——它在内核团队和 systemd 团队之间来回折腾了多年，却始终没有得到解决。

会发生什么

随机的 systemd 服务——包括关键的 systemd-resolved、systemd-timesyncd、systemd-journald 以及你自己的自定义服务——会突然无法启动。错误信息提到了 “mount namespacing” 和 “Invalid argument”。

• 重启服务没有帮助。
• systemctl daemon-reload 没有帮助。
• 唯一可靠的解决办法是完整的系统重启。

如果你在运行容器化工作负载（LXC、LXD、Proxmox），情况会更糟：该 bug 可能影响整个宿主节点，容器重启也无法解决——必须重启超管（hypervisor）本身。

归咎游戏

我已经在多个问题跟踪系统中追踪到了这个 bug：

• systemd/systemd #24798 — Ubuntu 20.04，2022 年 9 月
• systemd/systemd #19926 — 标记为 not-our-bug，2021 年 6 月
• Ubuntu Launchpad #1990659 — 因长期未活动而失效
• Fedora CoreOS #1296 — 影响 PXE/无盘启动
• Red Hat Bugzilla #2111863 — 已迁移至 Jira，状态未知
• dbus-broker #297 — CentOS Stream 9

模式始终相同：用户报告 bug，维护者要求调试日志，随后 bug 过期或以 “not‑our‑bug” 关闭。systemd 团队称这是内核问题。内核团队……嗯，我还没有找到任何内核团队成员在积极调查此事。

根本原因（我们所能判断的）

该错误似乎涉及：

• 竞争条件 在挂载命名空间设置中——systemd 在尝试重新挂载 /sys 和 /dev 时，其他卸载操作正在进行。
• 挂载传播问题——systemd 将默认值从 MS_PRIVATE 改为 MS_SHARED，导致意外交互。
• 资源耗尽——有时与 inotify 限制 (fs.inotify.max_user_instances) 相关。
• 容器/虚拟化边缘情况——在 LXC/LXD 环境中更为常见。

尚无人进行明确的根本原因分析。该错误是间歇性的，难以按需复现，并且影响已经运行数周或数月仍正常的系统。

讽刺

还记得 /etc/init.d/ 脚本“直接起作用”的时候吗？启动一个服务只需要运行一个执行二进制文件的 shell 脚本？

systemd 为我们带来了依赖管理、套接字激活、cgroups 集成以及诸如 PrivateDevices=、ProtectSystem=、PrivateTmp= 等数十项安全特性。这些都是实实在在有用的功能。

但它们也引入了复杂性。导致此 bug 的命名空间隔离正是因为 systemd 为启用了安全加固的服务创建了私有挂载命名空间。这是一个特性，直到它出错为止。

旧的 init 系统没有这个 bug，因为它没有使用命名空间。服务在全局命名空间中运行。更不安全？是的。但也意味着出错的环节更少。

变通方法

1. 为受影响的服务禁用命名空间隔离

sudo systemctl edit your-service.service

添加以下覆盖：

[Service]
PrivateDevices=no
ProtectHome=no
ProtectSystem=no

2. 清除损坏的 systemd 状态

sudo rm -rf /run/systemd/unit-root/
sudo systemctl daemon-reload

3. 增加 inotify 限制

echo "fs.inotify.max_user_instances=512" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

4. 监控并自动重启

* */3 * * * systemctl list-units --failed | grep -q NAMESPACE && reboot

是的，最后那条是计划重启。我们就是这样了。

应该发生的情况

有人——Canonical、Red Hat 或 systemd 团队——需要：

• 创建一个可靠的复现案例。
• 添加仪器以捕获故障发生时的确切内核 / systemd 状态。
• 进行适当的根本原因分析。
• 在内核、systemd 或两者中进行修复。

在此之前，我们只能不断重启服务器并抱有希望。

你遇到过这个 bug 吗？有什么变通办法？ 我很想听听任何进行过深入调查或找到永久解决方案的人的经验。