- 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生态系统中最具争议也最关键的组件之一又有了新的变化。我们指的是用于启动和管理服务的框架，它已经主导了大多数发行版，而此次发布更是在技术要求、安全性和对传统技术的弃用方面进一步收紧了限制。
此次更新是在经过数月的密集工作后进行的，重点是 三大重点领域：与新的 C 库兼容、增强安全性以及清理遗留代码 （SysV 脚本、TPM 1.2、iptables 等）。它还引入了对 run0 权限管理、systemd-oomd 内存处理、日志存储以及 libsystemd 内部依赖模型的重大更改。
systemd 259 和对 musl 的实验性支持
这一版本中最受关注的举措之一是： systemd 259 首次实现了与 C musl 标准库的部分兼容性该库广泛用于轻量级系统、极简容器和嵌入式环境，在这些环境中，与 glibc 相比，需要的是简单性和更低的资源消耗。
通过配置该选项来激活 Musl 支持 Meson 编译系统的“libc”，值为“musl”。然而，这种集成远未完成：musl 没有实现 NSS（名称服务切换）机制，这导致在针对此库进行编译时，systemd 的几个部分会被强制禁用。
具体来说，当使用 musl 构建 systemd 259 时，会得到以下结果。 移除关键组件，例如 nss-systemd、nss-resolve、systemd-homed、systemd-userdbd 和 systemd-nsresourcedDynamicUser 选项和以非特权方式运行 systemd-nspawn 的功能也不可用，这在严重依赖这些功能的容器环境中尤为重要。
开发人员自己也警告说， 他们不保证长期维持这种支持。该库的持续支持将取决于社区的实际需求、提供 musl 未包含功能的附加层的成熟度，以及针对该库的错误报告。如果需求量低或维护过于复杂，那么在未来的版本中重新评估其支持也不足为奇。
然而，这种对穆斯林的开放态度具有重要的象征意义： 多年来，systemd 一直因其几乎完全依赖 glibc 而备受诟病。这使得它对其他发行版和极简主义场景不太友好。虽然这一步并不能解决所有问题，但它打破了该组件完全封闭、与其他 C 库隔绝的固有印象。
run0 和新的权限模型：sudo 的替代方案
systemd 259 的另一个主要特性是实用程序 run0 被提议作为 sudo 的现代且更安全的替代品。该工具原本就基于 systemd-run 构建，但现在它获得了一项关键功能：选项 --empower.
新论点 –empower 参数允许您以提升的权限启动会话，而无需将 UID 更改为 root。run0 不使用传统的用户切换，而是利用内核功能（例如 CAP_SYS_ADMIN）来授予执行特权操作所需的精确权限，从而完全降低成为 root 用户的风险。
此外，以这种方式启动的过程被归类为： 逻辑组“empower”拥有对 Polkit 管理的一系列广泛操作的访问权限其理念是，特权的增加应该是细致入微且可控的，保持比传统南方通常提供的更为严格的隔离，因为南方的大门往往敞开得太大。
这种方法符合以下趋势： 尽可能避免直接使用 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 的默认访问限制更加严格这些节点被创建时使用了 0600 而非 0620 的权限，从而阻止其他用户写入我们的终端。这再次体现了 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 工具直接访问此信息，从而方便后续的事件分析。
当一个过程失控并开始 过度占用内存，以至于危及系统安全这些指标让您可以一目了然地看到哪些单元受到了影响，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 进行新配置打开大门（尽管是部分且有条件的）。对于使用小版本发行版的最终用户而言，这些新功能中的许多几乎不会被注意到；但对于不断更新到最新版本的管理员和项目而言，在进行切换之前，是时候仔细审查脚本、单元和硬件要求了。
