- 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）。
- glibc2.34 作為 GNU 標準函式庫的最小版本。
- 打開 SSL 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 進行新的配置，儘管這種配置是部分且有條件的。對於使用小版本發行版的最終用戶而言，許多新功能幾乎不會被注意到；但對於持續使用最新版本的管理員和專案而言，在進行切換之前，應仔細審查腳本、單元和硬體要求。
