systemd 258 とは何か――変更の文脈を押さえる
systemd 258 は 2025 年前半にリリースされた systemd のメジャーリリースです。単なる機能追加ではなく、数年にわたって段階的に進められてきた「レガシー互換の切り捨て」が一つの節目を迎えたリリースとして位置づけられます。
その中心にあるのが cgroup v1 サポートの廃止と、それに連動したカーネル最低要件の引き上げです。どちらも「いつかは来るとわかっていた変更」ですが、実際にリリースノートで明示されると、対応を先送りにしてきた環境では即座に影響が出ます。以降では、各変更の技術的な背景と運用現場への具体的な影響を整理します。
cgroup v1 廃止――なぜ今なのか
Linux のコントロールグループ（cgroup）には v1 と v2 の二世代が存在します。v1 は 2008 年ごろから存在するオリジナルの実装で、各サブシステム（cpu・memory・blkio など）が独立した階層ツリーを持つ設計です。一方、v2（unified hierarchy）は 2016 年に Linux 4.5 でマージされ、単一の階層ですべてのリソース制御を扱う設計に刷新されました。
systemd は v2 をデフォルトにする方針を早い段階で打ち出し、systemd 231（2016 年）から段階的に移行を進めてきました。v1 の非推奨（deprecated）宣言は systemd 254（2023 年）で行われており、258 はその宣言を実際のコード削除として具体化したリリースです。Linux カーネル側でも v1 は「メンテナンスのみ」の扱いとなっており、2026 年現在は将来的な完全削除に向けた議論がカーネルコミュニティで継続しています。
systemd 258 での具体的な変更としては、systemd-cgls や systemd-cgtop といったツールが v1 固有のパスを参照しなくなった点、cgroup_enable=memory のようなブートパラメータによる v1 強制起動を前提にした互換コードパスが削除された点が挙げられます。これにより、起動時に systemd.unified_cgroup_hierarchy=0 を渡して意図的に v1 を使用していた環境では、サービスの起動失敗やリソース制限の無効化が生じる可能性があります。
コンテナ環境への波及
影響が比較的大きいのはコンテナ運用です。Docker の旧バージョン（20.10 以前）や一部の LXC 設定は cgroup v1 を前提としていたため、ホスト側が v1 を提供しなくなると起動オプションの見直しが必要になります。現行の Docker 24 以降・containerd 1.7 以降・Podman 4 以降はいずれも v2 に対応済みですが、カスタムの cgroupfs マウント設定や社内製の監視エージェントが v1 パスをハードコードしていないかは個別に確認が必要です。
カーネル要件の引き上げ――何が最低ラインになったか
systemd 258 ではカーネルの最低要件が引き上げられ、Linux 4.15 未満のカーネルは非サポートとなりました。さらに、cgroup v2 関連の機能については Linux 5.8 以上を推奨するラインが明記されています。
Linux 4.15 は 2018 年 1 月リリースのカーネルです。主要ディストリビューションのサポートライフサイクルで見ると、Ubuntu 18.04 LTS（HWE スタック除く）が出荷時に 4.15 系を採用していました。2026 年時点で Ubuntu 18.04 はすでに EOL を迎えていますが、社内の長期稼働サーバや組み込み系の Linux 環境では 4.x 台のカーネルが残存しているケースがあります。そのような環境で systemd をアップグレードすると、起動時に要件チェックで警告が出力されるか、最悪の場合 systemd 自体が起動を拒否します。
一方、現行の主要ディストリビューションはいずれもこの要件を満たしています。
- Ubuntu 22.04 LTS：Linux 5.15 系（HWE で 6.x も選択可）
- Ubuntu 24.04 LTS：Linux 6.8 系
- Debian 12（Bookworm）：Linux 6.1 系
- RHEL 9 / AlmaLinux 9 / Rocky Linux 9：Linux 5.14 系
- Fedora 41 以降：Linux 6.11 系以上
問題になるのは、上記以外の自前ビルドカーネルや、EOL 済みディストリの延命運用環境です。
運用現場が行うべき事前確認
systemd 258 を含むディストリビューションへアップグレードする前に、以下の確認を行うことが推奨されます。
cgroup のマウント状態を確認する
現在のホストが v1 と v2 のどちらで動いているかは次のコマンドで確認できます。
stat -fc %T /sys/fs/cgroup/tmpfs が返る場合は v1（またはハイブリッドモード）、cgroup2fs が返る場合は v2 のみで動作しています。v2 であれば systemd 258 への移行で cgroup 関連の問題は基本的に発生しません。
カーネルバージョンを確認する
uname -r出力が 4.15 未満であれば、systemd のアップグレード前にカーネルのアップデートが必要です。
サービスの cgroup 設定を棚卸しする
ユニットファイルや /etc/systemd/system/ 配下のオーバーライドに、v1 固有のオプション（CPUAccounting の旧構文や MemoryLimit など）が残っていないかを確認します。
grep -r 'MemoryLimit\|CPUShares\|BlockIOWeight' /etc/systemd/system/MemoryLimit は v2 では MemoryMax に、CPUShares は CPUWeight に置き換えが必要です。systemd はこれらの旧オプションに対して警告を出力しますが、systemd 258 以降では一部が完全に無視されるようになります。
移行時の注意点と切り戻しの考え方
v1 から v2 への移行は、カーネルのブートパラメータで制御されています。多くのディストリビューションはすでに v2 をデフォルトにしており、意図的に変更していなければ対応不要です。ただし、過去に何らかの理由で v1 を強制していた場合は次の手順で確認と切り替えを行います。
GRUB を使用する環境では /etc/default/grub の GRUB_CMDLINE_LINUX から systemd.unified_cgroup_hierarchy=0 を削除し、update-grub（Debian 系）または grub2-mkconfig（RHEL 系）を実行して再起動します。
切り戻しが必要な場面としては、社内の監視エージェントや APM ツールが v2 の /sys/fs/cgroup/ パス構造に対応していない場合が典型です。この場合、ツール側のアップデートが最優先ですが、一時的な対処として旧パラメータを再設定してカーネルを再起動することで v1 に戻すことは技術的には可能です。ただし systemd 258 以降は v1 強制起動時の動作保証が薄れているため、あくまでも暫定措置として扱い、ツール側の対応を急ぐことが現実的です。
コンテナ環境では、ホスト側が v2 に移行しても既存のコンテナイメージ自体は影響を受けません。影響があるのはコンテナランタイムのデーモン設定と、コンテナ内で systemd を動かしている場合（いわゆる systemd コンテナ）です。後者は --cgroupns=host オプションの要否や、コンテナ内 PID 1 の挙動に変化が生じる可能性があるため、ステージング環境での検証が不可欠です。
2026 年時点のディストリビューション対応状況
2026 年 7 月現在、主要ディストリビューションの systemd 採用バージョンは以下のとおりです。
- Fedora 42：systemd 257 系（258 は次サイクルで採用見込み）
- Ubuntu 24.04 LTS：systemd 255 系（SRU 経由で順次更新）
- Debian sid（unstable）：systemd 257〜258 系が流入中
- RHEL 9 / AlmaLinux 9：systemd 252 系（独自バックポートで機能補完）
- Arch Linux：ローリングリリースのため最新版を随時採用
RHEL 系は独自のバックポートポリシーを持つため、upstream の systemd 258 が持つ変更がそのままの形では入らないことに注意が必要です。RHEL 9 の systemd 252 ベースでも cgroup v2 はデフォルトになっており、実質的な運用への影響は upstream と大きくは変わりません。一方、RHEL 10（2025 年リリース）では systemd 257 系が採用されており、258 相当の変更の一部がバックポートで取り込まれています。
Arch Linux のような rolling release 環境では、systemd 258 はすでに本番稼働しているケースがあります。Arch を業務で利用している場合は、pacman -Syu でのフルアップグレード前に上述の確認手順を実施しておくことが安全です。
全体的な傾向として、2026 年時点では「cgroup v2 が当たり前の前提」という状況が主要ディストリビューションでは完成しつつあります。新規構築環境で v1 を意識する場面はほぼなくなりましたが、数年前に構築したサーバをそのまま延命している環境や、組み込み・エッジ系の Linux 運用では引き続き注意が必要です。systemd 258 が直接の引き金になるかどうかに関わらず、cgroup v1 への依存を棚卸しするタイミングとして捉えることが運用上の合理的な判断といえます。
「コマンドは打てる。次は”現場で通用する型”を最短で身につけたい」——そんなあなたへ。
ネットの断片的なTipsをコピペするだけでは、体系的な運用スキルはなかなか積み上がりません。リナックスマスター.JPの無料メルマガ「リナマガ」では、現場で実際に使うLinuxサーバー運用の考え方を、順を追って実務目線でお届けしています。いま登録された方には、安全なサーバー構築の「型」をまとめた『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼント中です。
＞＞ 図解60P『Linux入門マニュアル』を無料で受け取る
（メルマガ登録は10秒・いつでも解除OK）
※ 「独学の時間がもったいない」「プロから現場の技術を最短で学びたい」という本気の方には、2日で実務レベルが身につく初心者向けハンズオンセミナーもご用意しています。
PR・広告
［試して理解］Linuxのしくみ 増補改訂版（Amazon）
プロセス・権限・ファイルシステムなどLinux内部を図解で理解できる一冊。運用判断の勘所に。
※ Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
