- systemd 259 引入了对 musl 的部分支持、libsystemd 的更高模块化程度，以及使用 run0 --empower 强制执行的特权模型。
- 系统要求提高了：Linux 内核 5.10、glibc 2.34、OpenSSL 3.0.0 和其他现代库成为强制性最低要求。
- 传统技术淘汰正在加速：告别 SysV 脚本，停止支持 TPM 1.2，放弃 iptables 并全面采用 nftables。
- 它们通过默认启用持久日志、新增 OOMKills 指标以及对网络、容器和 homed 进行多项调整来提高可观测性和安全性。
systemd 259 稳定版的发布，标志着 Linux 生态系统中最具争议也最关键的组件之一又迎来了新的变化。我们所说的 systemd 是一个用于启动和管理服务的框架，它已经主导了大多数 Linux 发行版。此次发布进一步收紧了技术要求、安全性和对传统技术的淘汰。
此次更新历经数月密集开发，主要集中在三个方面：与新 C 库的兼容性、增强的安全性以及清理遗留代码（SysV 脚本、TPM 1.2、iptables 等）。此外，它还对 run0 的权限管理、systemd-oomd 的内存处理、日志存储以及 libsystemd 的内部依赖模型进行了重大改进。
systemd 259 和对 musl 的实验性支持
该版本最受关注的特性之一是systemd 259 首次引入了对 C 标准库 musl 的部分支持。musl 库广泛应用于轻量级系统、极简容器和嵌入式环境，这些环境需要相比 glibc 更简洁、资源消耗更低的库。
要启用对 musl 的支持，需要将Meson 构建系统的“libc”选项设置为“musl”。然而，这种集成远未完成：musl 没有实现名称服务切换 (NSS) 机制，这导致在针对该库进行编译时，systemd 的某些部分会被强制禁用。
具体来说，使用 musl 构建 systemd 259会排除一些关键组件，例如 nss-systemd、nss-resolve、systemd-homed、systemd-userdbd 和 systemd-nsresourced。DynamicUser选项以及以非特权方式运行 systemd-nspawn 的功能也不可用，这在严重依赖这些功能的容器环境中尤为重要。
开发者们也承认他们无法保证长期支持。支持的持续与否取决于社区的实际兴趣、提供 musl 所缺乏功能的附加层的成熟度，以及针对此库的特定错误报告。如果需求低迷或维护过于复杂，那么在未来的版本中重新评估此支持也就不足为奇了。
然而，向 musl 开放具有重要的象征意义：多年来，systemd 一直因其几乎完全依赖 glibc 而备受诟病，这使得它对其他发行版和极简主义场景并不友好。这一举措虽然不能解决所有问题，但它打破了 systemd 完全封闭、与其他 C 库隔绝的形象。
run0 和新的权限模型：sudo 的替代方案
systemd 259 的另一个主要特性是实用程序 run0 被提议作为 sudo 的现代且更安全的替代品。该工具原本就基于 systemd-run 构建，但现在它获得了一项关键功能：选项 --empower.
新的 `--empower` 参数允许您在不将用户 ID 更改为 root 的情况下，以提升的权限启动会话。`run0` 并非使用传统的用户切换，而是利用内核功能（例如 `CAP_SYS_ADMIN`）来精确授予执行特权操作所需的权限，从而完全避免了成为 root 用户的风险。
此外，采用这种方法启动的进程会被归入一个逻辑上的“赋能”组，该组拥有对 Polkit 管理的一系列广泛操作的访问权限。其理念是，权限的提升是精细且可控的，与传统的 sudo 相比，权限划分更加严格，避免了权限过度开放的问题。
这种方法符合尽可能避免直接使用 root 用户的趋势，而避免使用 root 用户是一项备受重视的安全原则。然而，run0 的真正有效性仍需在生产环境中验证：我们需要观察它如何与各个发行版的策略集成，其功能在实践中如何配置，以及系统管理如何适应新的工作流程。
停止支持 SysV 初始化和遗留清理
systemd 259 也标志着System V 式服务脚本的彻底终结。多年来，对这些经典机制的兼容性一直被认为“即将退出”，而现在，移除它们的明确时间表已经制定。
此版本宣布，展望下一个主要版本， 将会移除 systemd-sysv-generator、systemd-rc-local-generator 和 systemd-sysv-install 等历史组件。也就是说，脚本在 /etc/init.d/ systemd 将不再考虑它们，这标志着持续近十年的过渡期结束。
对于仍然维护基于 SysV 脚本的自定义服务的管理员来说，这意味着需要着手工作：所有这些脚本都需要清点并迁移到原生 systemd 单元（.service、.socket 等）。大型发行版几乎已经完成了整个迁移过程，但在自定义环境或较旧的安装中，一些“遗留”脚本可能仍在后台运行。
这种遗留系统清理过程并非仅限于 SysV。最新版本的 systemd 已经开始移除对 `/forcefsck` 和 `/fastboot` 等传统方法的支持，并用内核参数和更现代的凭证机制取而代之。259 版本也遵循同样的方向：牺牲一些向后兼容性，换取更易于维护和一致的代码库。
systemd 最低要求 259：内核、库和环境
对老旧系统影响最大的变化之一是提高了运行 systemd 259 的最低软件要求。此版本不再关注非常老旧的硬件或堆栈，显然是向现代平台靠拢。
systemd 259 中整合的关键要求包括：致力于现代平台
- Linux 内核版本至少为 5.10 （建议至少达到 5.14）。
- glibc 2.34 作为 GNU 标准库的最小版本。
- OpenSSL 3.0.0 作为所支持的加密功能的必要基础。
- util-linux 2.37 这是系统基本功能的必要条件。
- libxcrypt 4.4.0 用于管理与密码相关的加密功能。
- cryptsetup 2.4.0 和 libseccomp 2.4.0 用于卷加密和系统调用过滤。
- Python的3.9.0 作为辅助工具的最低依赖项。
- 一些笔记还提到 小精灵 0.177 作为更新后的依赖项集的一部分。
这种收紧意味着，除非底层技术更新，否则使用5.10 之前内核分支的非常老旧的系统或发行版将被自动排除在此版本支持范围之外。作为回报，这将实现一个更加同质化的生态系统，减少特殊情况和折衷方案。
对于大多数通用桌面和服务器发行版而言，这些要求应该不成问题：现代 LTS 内核分支早已远远超过 5.10 的限制，而且提到的库也广泛可用。最大的问题可能出现在嵌入式系统、设备或更新频率很低的保守安装环境中。
增强安全性：TPM 2.0、加密和设备限制
在安全领域，systemd 259 通过几项重要决策加快了发展步伐。最显著的一点是systemd-boot 和 systemd-stub 彻底放弃了对 TPM 1.2 的支持，因此从现在起，只有 TPM 2.0 被视为参考标准。
这意味着，依赖TPM 1.2 管理安全启动策略或加密密钥的系统，如果想要继续在新版 systemd-boot 中使用这些功能，则需要升级硬件（例如，更换主板）。许多 Linux 桌面用户已禁用 TPM 和安全启动，因此他们可能不会注意到这一变化，但这在企业或高安全环境中可能会产生影响。
在之前的版本中，例如 systemd 258，这方面已经做出了重大调整：OpenSSL 成为 systemd-resolved 和 systemd-importd 唯一支持的加密库，而 GnuTLS 和 libgcrypt 等替代方案则被排除在外。所有这些都表明，加密工具正在向一个规模更小、控制更严格的集合靠拢。
此外，在 258 分支中，tty/pts 的默认访问限制也更加严格：节点创建的权限从 0620 改为 0600，从而阻止其他用户写入我们的终端。这再次体现了 systemd 如何持续优化底层细节，最终增强系统的整体安全性。
libsystemd 模块化程度更高，并且可以动态加载。
为了提高效率并降低依赖项，systemd 259对 libsystemd 与其他系统库的交互方式进行了重大更改。其目标是防止所有依赖项一开始就被加载，而是仅在需要时才加载。
具体来说，libsystemd 现在使用 dlopen() 函数动态加载 libacl、libblkid、libseccomp、libselinux 和 libmount 等库。这意味着这些依赖项在编译时并非严格链接，也不会始终加载到内存中：它们仅在特定函数需要时才会激活。
`dlopen()` 的这种机制同样适用于与 Linux 审计子系统和 PAM 的集成。这样，在不需要同时运行所有这些组件的环境中，systemd 的启动和正常运行可以更加轻量级。
另一方面，之前由 libcap 库提供的功能已直接集成到 libsystemd 中。这消除了另一个外部依赖项，简化了构建流程，并减少了潜在的故障点或不兼容性。
总的来说，这种方法提供了更好的模块化和更小的内存和磁盘占用空间，尤其是在需要快速启动时间和紧密集成的服务集的系统中。
网络和容器变更：告别 iptables，迎接 nftables
网络和虚拟化领域也发生了重大变化。从 systemd 259 版本开始，systemd-networkd 和 systemd-nspawn 不再支持使用 iptables/libiptc 创建 NAT 规则。唯一受支持的防火墙后端变为 nftables。
这直接影响到使用 systemd-nspawn 管理的、依赖 iptables 进行 NAT 的容器，以及使用 systemd-networkd 定义、采用经典后端地址转换规则的网络。在对候选版本进行测试时，观察到 NAT 功能出现静默故障，直到整个配置迁移到 nftables 后才恢复正常。
除了地址翻译之外， systemd-resolved 获得了使用本地钩子的能力 en /run/systemd/resolve.hook/每次执行本地名称解析查询时，都会执行这些命令。这为管理员进行高级 DNS 自定义和编写特定逻辑提供了可能。
在图像导入和管理领域， systemd-importd 集成了用于处理 TAR 文件的原生逻辑依赖于 GNU tar 工具中的 libarchive 库。此外，systemd-importd 和 systemd-machined 现在都可以在用户模式下运行，管理放置在 中的系统镜像。 ~/.local/state/machines/.
为了控制这些模式，importctl 工具添加了“--user”和“--system”选项，方便用户选择是在用户上下文还是系统级别进行操作。这种方法适用于开发和测试环境，在这些环境中，您无需修改机器的全局配置。
默认启用持久日志记录和磁盘空间管理
另一个具有实际影响的变化是对以下方面的修改： 默认日志存储模式这是 systemd 的日志子系统。此前，“自动”行为取决于目录是否存在。 /var/log/journal.
systemd 259 版本将默认模式设为“持久化”，无论文件夹之前是否存在。这意味着日志默认情况下会永久保存到磁盘，而不是存储在易失性 RAM 中。
这项决定有利有弊。一方面，它大大简化了故障排除，因为日志在重启后仍然保留，无需管理员进行任何特殊操作。另一方面，在嵌入式系统、轻量级容器或存储空间非常有限的环境中，它可能会导致磁盘使用量显著增加。
在这些情况下，调整日志轮换和大小策略将比以往任何时候都更加重要，甚至如果您想避免过度磨损（例如，在写入周期有限的闪存中），还可以强制采用不同的存储模式。
systemd-oomd，OOM 跟踪和资源控制
内存管理和“内存不足”场景也得到了显著改进。负责响应内存不足情况的 systemd-oomd 组件新增了一些属性，以提供更清晰的可见性。
具体来说，现在服务可以使用 OOMKills 和 ManagedOOMKills 属性，这些属性会记录因内存不足而被内核或 systemd-oomd 本身终止的进程数。可以使用 systemd 工具直接访问此信息，从而方便后续的事件分析。
当一个进程失控并开始“吞噬”RAM 以致危及系统时，这些指标可以让你一目了然地看到哪些单元受到了影响，OOM 机制被触发了多少次，以及哪些组件造成了最大的内存压力。
对于高负载环境或资源非常紧张的系统的管理员来说，这种更强的观察 OOM 的能力尤其有用，因为它有助于识别以前可能未被注意到的规模过小的服务或内存泄漏。
systemd 259 的其他显著改进
除了上述主要变化之外，systemd 259 还包含大量改进和细微调整，这些改进和调整遍布整个生态系统。其中许多都比较技术性，但值得仔细了解，因为它们加起来带来了显著的变化。
API 的新功能包括： 基于Varlink协议的接口正在扩展 允许访问服务配置并执行诸如此类的 IPC 调用 Reload() y Reexecute()此外，还添加了专门的调用来处理 systemd-repart、systemd-resolved 和 systemd-networkd 功能。
在配置和单元方面，新增了ExecReloadPost 选项，允许在服务配置重新加载后立即执行命令。此外，以“.ignore”结尾的配置文件现在会自动丢弃，这是一种无需删除或大幅重命名即可禁用文件的简单方法。
临时单位获得所有权 根目录文件描述符它定义了与根目录对应的文件描述符，并添加了一个新选项。 用户名空间路径它允许您通过指定路径将驱动器链接到用户命名空间。 /proc在 systemd-nspawn 中，该指令出现 部分中的命名空间路径 从 .nspawn 文件中获取要使用的网络命名空间。
其他组件如 systemd-sysext 和 systemd-confext 包含专用的配置文件 en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.conf环境变量 SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS 它们允许您调整叠加层的安装选项。
在 udev 的世界里，添加了这个选项。 OPTIONS=»dump-json» 到 systemd-udevd 要以 JSON 格式显示事件的当前状态，可以使用以下函数 net_id 它为具有 DeviceTree 的系统上的无线接口生成可预测的名称，并创建符号链接。 /dev/gpio/by-id/... 适用于 GPIO 设备。
用户和账户部分也在不断加强： 用户数据库包含一个 UUID 字段userdbctl 工具支持使用“-uuid”选项按此标识符进行搜索，并且 homectl update 现在支持使用“--recovery-key”向现有帐户添加恢复密钥。
在 systemd-homed 中，选项“--prompt-shell”和“--prompt-groups”在首次启动时通过 systemd-homed-firstboot.service集成；而在 systemd-firstboot 中，“--prompt-keymap-auto”似乎会在首次启动时使用本地控制台时请求键盘映射。
El systemd-boot 启动管理器增加了定义日志详细程度的功能。 带参数 log-level en loader.conf 或使用 SMBIOS 字段 io.systemd.boot.loglevel此外，对 XBOOTLDR 等分区提出了更严格的要求，现在必须采用 VFAT 格式，这与现代 UEFI 系统中 ESP 的要求一致。
在高级网络层面，systemd-networkd 为 DHCP 服务器添加了 EmitDomain 和 Domain 选项，并实现了一个控制器，该控制器使用 DNS 解析来确定通过 DHCP 分配的主机名。同时，systemd-modules-load 并行加载内核模块，从而缩短了驱动程序较多的系统的启动时间。
最后，在完整性部分，systemd-integrity-setup 增加了对 HMAC-SHA256、PHMAC-SHA256 和 PHMAC-SHA512 算法的支持，扩展了可用于保护系统完整性的加密选项范围。
凭借这些变化，systemd 259 巩固了其作为一款技术性强、要求高且明显面向未来的版本的地位。它促使用户放弃 SysV init、iptables 和 TPM 1.2 等传统技术，加强了安全性和资源控制，改进了内部模块化，并允许使用 musl 进行新的配置，尽管这种配置是部分且有条件的。对于使用小版本发行版的最终用户而言，许多新特性几乎不会被注意到；但对于持续使用最新版本的管理员和项目而言，在进行切换之前，应该仔细审查脚本、单元和硬件要求。
