- systemd 259 では、musl の部分的なサポート、libsystemd のモジュール性の向上、run0 --empower で強制される権限モデルが導入されています。
- 要件のハードルが引き上げられ、Linux カーネル 5.10、glibc 2.34、OpenSSL 3.0.0 およびその他の最新ライブラリが必須の最低要件となります。
- レガシーの廃止が加速しています。SysV スクリプトは廃止され、TPM 1.2 のサポートは終了し、iptables は放棄され、nftables が完全に採用されます。
- デフォルトでの永続ジャーナル、新しい OOMKills メトリック、ネットワーク、コンテナー、ホーム全体にわたる複数の調整により、可観測性とセキュリティが向上します。
systemd 259が安定版としてリリースされたことは、Linuxエコシステムにおいて最も議論の的となっている、しかし不可欠なコンポーネントの一つに新たな展開をもたらすものです。ここで言うsystemdとは、既に多くのディストリビューションで主流となっている、サービスの開始と管理のためのフレームワークのことです。今回のリリースは、技術要件、セキュリティ、そして旧来のテクノロジーの廃止という点で、さらに厳しい制約を課すものとなります。
今回のアップデートは、数か月にわたる集中的な作業を経て実現したもので、主に3つの分野に焦点を当てています。新しいCライブラリとの互換性、セキュリティの強化、そしてレガシーコード（SysVスクリプト、TPM 1.2、iptablesなど）のクリーンアップです。また、run0による特権管理、systemd-oomdによるメモリ管理、ログストレージ、そしてlibsystemdの内部依存関係モデルにも大幅な変更が加えられています。
systemd 259とmuslの実験的なサポート
このバージョンで最も注目されている機能の一つは、systemd 259が初めてC標準ライブラリmuslの部分的なサポートを組み込んだことです。このライブラリは、glibcに比べてシンプルさとリソース消費量の削減が求められる軽量システム、ミニマルなコンテナ、組み込み環境などで広く使用されています。
Mesonビルドシステムの「libc」オプションを「musl」に設定することで、muslのサポートが有効になります。ただし、この統合はまだ完全ではありません。muslはネームサービススイッチ（NSS）メカニズムを実装していないため、このライブラリに対してコンパイルする際にsystemdのいくつかの部分を無効にする必要があります。
具体的には、musl を使用して systemd 259 をビルドすると、nss-systemd、nss-resolve、systemd-homed、systemd-userdbd、systemd-nsresourced などの重要なコンポーネントが除外されます。また、DynamicUser オプションや、systemd-nspawn を権限なしで実行する機能も利用できなくなります。これは、これらの機能に大きく依存するコンテナ環境では特に重要です。
開発者自身も、長期的なサポートを保証できないことを認めています。サポートの継続は、コミュニティの実際の関心度、muslに不足している機能を提供する追加レイヤーの成熟度、そしてこのライブラリ特有のバグ報告に左右されます。需要が低い場合や、メンテナンスが複雑すぎる場合は、将来のバージョンでサポートが見直される可能性も十分にあります。
しかし、今回のmuslへの対応は象徴的な意味合いで重要です。systemdは長年にわたり、glibcへの依存度が極めて高いため、他のディストリビューションや極めてシンプルな構成には不向きであると批判されてきました。今回の対応ですべてが解決するわけではありませんが、他のCライブラリに対して完全に閉鎖的なシステムというイメージを払拭するものです。
run0と新しい権限モデル: sudoの代替
systemd 259のもう一つの大きな特徴は、ユーティリティである run0 は、sudo の現代的でより安全な代替として提案されています。このツールはすでにsystemd-run上に構築されていますが、今回、重要な機能が追加されました。オプション --empower.
新しい引数`--empower`を使用すると、ユーザーIDをrootに変更することなく、特権昇格された状態でセッションを開始できます。従来のユーザー切り替えの代わりに、`run0`はカーネル機能（`CAP_SYS_ADMIN`など）を活用して、特権操作を実行するために必要な権限を正確に付与することで、root権限を完全に取得するリスクを軽減します。
さらに、この方法で開始されたプロセスは、Polkitによって管理される幅広いアクションへのアクセス権を持つ論理的な「権限付与」グループにグループ化されます。この考え方は、権限の拡大が細分化され、制御されているため、アクセスが広すぎることが多い従来のsudoよりも厳格な分離が維持されるというものです。
このアプローチは、可能な限りrootユーザーの直接使用を避けるという、非常に重要なセキュリティ原則に沿ったものです。しかし、run0の真の有効性は、実運用環境で実証される必要があります。各ディストリビューションのポリシーとの統合方法、実際の運用における機能構成、そしてシステム管理者が新しいワークフローにどれだけうまく適応できるかを見極める必要があります。
SysV init およびレガシークリーンアップのサポート終了
systemd 259は、System Vスタイルのサービススクリプトの終焉を決定的に告げるものでもあります。これらの従来のメカニズムとの互換性は長年「廃止に向かっている」とされてきましたが、今回、それらを削除するための明確なスケジュールが確立されました。
このバージョンでは、次のメジャーリリースに向けて、 systemd-sysv-generator、systemd-rc-local-generator、systemd-sysv-install などの従来のコンポーネントは削除されます。つまり、 /etc/init.d/ これらは systemd によって考慮されなくなり、これにより 10 年近く続いた移行が完了します。
SysVスクリプトに基づいたカスタムサービスをまだ維持している管理者にとっては、これは作業に取り掛かることを意味します。つまり、それらのスクリプトをすべて一覧化し、ネイティブのsystemdユニット（.service、.socketなど）に移行する必要があります。大規模なディストリビューションでは、この移行はほぼ完了していますが、カスタム環境や古いインストール環境では、一部の「遺物」がバックグラウンドで実行されている可能性があります。
このレガシーシステムのクリーンアッププロセスはSysVに限ったものではありません。systemdの最近のバージョンでは、`/forcefsck`や`/fastboot`といった従来の方法のサポートが既に削除され、カーネルパラメータやより現代的な認証メカニズムに置き換えられています。バージョン259でもその方向性は同じで、後方互換性を犠牲にする代わりに、より保守しやすく一貫性のあるコードベースを目指しています。
最小 systemd 要件 259: カーネル、ライブラリ、環境
古いシステムに最も大きな影響を与える可能性のある変更点の1つは、systemd 259を実行するための最小ソフトウェア要件の増加です。このバージョンでは、非常に古いハードウェアやスタックは考慮されなくなり、明らかに最新のプラットフォームへの移行が推進されています。
systemd 259に統合された主要な要件には、最新のプラットフォームへの取り組みが含まれます。
- Linuxカーネル5.10以上 (少なくとも 5.14 までアップグレードすることをお勧めします)。
- glibc2.34 GNU 標準ライブラリの最小バージョンとして。
- SSL3.0.0を開きます サポートされている暗号化機能の必須の基礎として。
- ユーティリティ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などの以前のリリースでは、この分野で既に大きな調整が行われていました。systemd -resolvedとsystemd-importdでサポートされる暗号化ライブラリはOpenSSLのみとなり、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のみとなります。
これは、iptables を介した NAT に依存していた systemd-nspawn で管理されているコンテナ、および従来のバックエンドでアドレス変換ルールを使用していた systemd-networkd で定義されたネットワークに直接影響します。リリース候補版でのテストでは、設定全体を nftables に移行するまで、NAT 機能にサイレントな障害が発生していました。
住所の翻訳だけでなく、 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コンポーネントには、可視性を向上させるための新しいプロパティが組み込まれています。
具体的には、カーネルまたはsystemd-oomd自体によってメモリ不足のために終了されたプロセスの数を記録する、 OOMKillsおよびManagedOOMKillsプロパティがサービスで利用可能になりました。この情報はsystemdツールを使用して直接アクセスできるため、その後のインシデント分析が容易になります。
プロセスが制御不能になり、システムを危険にさらすほどRAMを「消費」し始めた場合、これらのメトリックを使用すると、どのユニットが影響を受けているか、OOMメカニズムが何回トリガーされたか、どのコンポーネントが最もメモリ負荷を引き起こしているかを一目で確認できます。
高負荷環境やリソースが非常に限られているシステムの管理者にとって、OOM（メモリ不足）をより詳細に監視できる機能は特に有用です。なぜなら、これまで見過ごされていた可能性のある、不適切なサイズのサービスやメモリリークを特定できるからです。
systemd 259のその他の注目すべき改善点
上記で述べた主要な変更点に加え、systemd 259にはエコシステム全体にわたって数多くの改善点や細かな調整が盛り込まれています。技術的な内容が多いものの、それらをすべて確認する価値はあります。なぜなら、それらが積み重なることで大きな変化をもたらすからです。
APIの新機能の中には、 Varlinkプロトコルベースのインターフェースが拡張されている サービス構成へのアクセスを許可し、次のようなIPC呼び出しを実行します。 Reload() y Reexecute()systemd-repart、systemd-resolved、および systemd-networkd 機能を処理するための特定の呼び出しも追加されます。
設定とユニットの分野では、 ExecReloadPost オプションが導入されました。これにより、サービスの設定が再読み込みされた直後にコマンドを実行できるようになります。さらに、拡張子が ".ignore" の設定ファイルは自動的に破棄されるようになりました。これは、ファイルを削除したり大幅に名前を変更したりすることなく、簡単にファイルを無効にするための便利な機能です。
一時ユニットが所有権を取得 ルートディレクトリファイル記述子ルートディレクトリに対応するファイル記述子を定義し、新しいオプションが追加されました ユーザー名前空間パス、パスを指定してドライブをユーザー名前空間にリンクすることができます。 /procsystemd-nspawnでは、ディレクティブは セクションのNamespacePath .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さらに、最新の UEFI システムの ESP にすでに要求されている要件に合わせて、XBOOTLDR などのパーティションに対しても、より厳しい要件が統合され、VFAT で記述する必要が生じています。
高度なネットワークレベルでは、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 を使用した新たな構成への道を開きます（ただし、部分的かつ条件付きです）。ポイントリリース版を使用しているエンドユーザーにとっては、これらの新機能の多くはほとんど気づかれないでしょう。しかし、常に最新バージョンを使用している管理者やプロジェクトにとっては、切り替えを行う前にスクリプト、ユニット、ハードウェア要件を慎重に見直す時期です。
