从 musl 发行版维护者的视角看 systemd

原文 ↗ Hacker News 讨论 ↗

Linux 朝着以 systemd 作为主导 init 和服务管理器的方向迈进，因提升了可靠性、依赖处理和现代功能而受到赞扬，但也因制造了脆弱的单一文化，并把许多不相关的系统功能捆绑在一个大框架下而遭到批评。评论者指出了一些具体痛点——从二进制日志和 systemd-resolved 的怪异行为，到复杂性、安全面扩大，以及对小型或嵌入式场景的不适配——同时也承认其紧密集成在动态桌面和企业环境中往往“就是能工作”。文中还提到了 OpenRC、s6 和 nosh 等替代方案，但许多人指出，生态依赖和项目治理选择使得竞争方案很难真正获得 traction。

单一文化、治理与竞争

  • 许多人都同意 systemd 解决了真正的问题（启动并行化、监督、依赖关系），但担心它的主导地位会造成一种单一文化，阻碍替代方案并迫使实现 bug 兼容。
  • 也有人认为 systemd 之前的“多文化”混乱且更差；systemd 只是比竞争者做得更好。
  • 有些人认为发行版把 systemd 变成事实上的必选项（尤其是在 Debian 中）的方式是一种治理失败，也是长期怨气的来源。
  • 也有人认为支持多个 init 系统是可行的，但需要资源和兴趣；Gentoo 被拿来作为证明。

PID 1 的职责范围与架构

  • 关于 PID 1 “应该”做什么存在争论：是最小化的第一个用户态程序，还是进程、挂载、网络等的中央编排者。
  • 有人认为把进程管理放进 PID 1 能带来强保证；也有人把功能不断叠加（NVMe-over-TCP 等）看作“啥都塞”的臃肿。

服务管理与管理员体验

  • 许多管理员称赞 systemd 提供了标准化工具、服务/挂载/套接字之间的依赖关系、更容易的权限降级，以及 journald 按单元聚合日志的能力。
  • 也有人报告了痛点：启动/关机时超时、难以中断失败的单元，以及令人困惑的 per-user 实例（linger、loginctl）。
  • socket activation 和 inetd 风格设计引发分歧：有人认为中心监听器更安全、更简单；也有人把 super-server 看作反模式和 DoS 风险。

日志（journald）与复杂性

  • 带有丰富元数据的二进制 journal 被认为对集中式日志很强大，但：
    • 与传统文本工具（grep/rsync）配合更困难。
    • 更慢且有时会损坏，于是有人称其为“重新发明数据库”。
  • systemd 的大量单元类型和搜索路径提高了灵活性，但损害了“行为局部性”，让系统更难推理。

DNS 与网络（systemd-resolved）

  • resolved 遭到大量批评：DNSSEC 问题、在非平凡配置中的脆弱行为，以及关于其是否适合生产环境的困惑。
  • 支持者强调按接口/VPN 绑定的 split DNS 等功能，以及与其他 systemd 组件的紧密集成；批评者指出类似配置也可以用 dnsmasq 实现，只是需要更多胶水代码。

替代方案与重写

  • 文中提到了多种替代方案：OpenRC、s6/66suite、runit、dinit、nosh，以及旨在实现部分 systemd 兼容性的 Rust 重实现。
  • 有人认为最终可能会出现一个“像 PipeWire 一样”的更干净继任者，但担心 systemd 的节奏和生态锁定让这在今天很难实现。