14.2. パッケージおよびイメージモードでのソフトリブート動作

イメージモードで実行されているシステムは、ユーザー空間のみを再起動するパッケージモードシステムと同じ方法でソフトリブートを実行します。違いは、これらのパッケージとサービスの更新を最初にコンテナーイメージ上にビルドする必要があることです。

ユーザー空間のパッチ適用は、ユーザー向けのアプリケーションと共有ライブラリーのセキュリティー上の脆弱性とバグに対処します。パッチを適用する場合、新しいコードをロードするにはソフトリブートまたはプロセスの再起動が必要です。以下に例を示します。

Web サーバー、データベース、SSH デーモンなどの OpenSSL を使用するアプリケーションは、再起動しない限り脆弱性にさらされた状態が続き、引き続き脆弱な共有ライブラリーを使用します。

ソフトリブートソリューション: dnf update openssl の実行後にソフトリブートを実行すると、依存プロセスが停止します。その後、Systemd は、これらのサービスを再起動し、新しいパッチ適用済みの libssl.so および libcrypto.so ライブラリーを自動的にロードして、マシン全体を再起動せずにシステムを保護します。

問題: Glibc は、システム上のほぼすべてのプログラムが依存する基本的なユーザー空間コンポーネントです。glibc の脆弱性はシステム全体に影響を及ぼします。1 つか 2 つのサービスを再起動するだけでは不十分です。他の多くのプロセスは依然として脆弱なままだからです。

ソフトリブートによる解決策: dnf update glibc を実行してからソフトリブートを行うことが、すべてのプロセスが再起動して新しい glibc に再リンクされることを確実にする最も確実な方法です。これにより、システム全体の再起動が原因で長くなるダウンタイムを回避しながら、更新がすべての場所に適用されます。

使用例: セキュリティーまたはパフォーマンスのために dbus-broker デーモンを更新します。

問題: Dbus-broker は重要なシステムサービスです。通常更新しても影響はありませんが、プロトコルが敏感に反応するため、ブローカーと関連サービスを再起動する必要があります。

ソフトリブートソリューション: ソフトリブートは、dbus-broker とすべての依存サービスおよびアプリケーションを再起動し、systemd により、正常にシャットダウンおよび再初期化されます。

イメージベースのシステムでは、次の 2 つの方法で更新を管理できます。

ソフトリブートを実行すると、システムは新しくステージングされた更新済みのルートファイルシステムに切り替わり、ユーザー空間全体が一度に置き換えられます。システムは新しく更新されたオペレーティングシステムイメージで起動し、問題が発生した場合は、次回の起動時に以前のイメージにロールバックする機能が保持されます。

これを使用すると、カーネルに触れることなく現在のソフトウェアの状態をリセットできます。これは、イメージレベル以外の変更を適用したり、ユーザー空間の問題を解決したりするのに役立ちます。

systemd のソフトリブートのメカニズムは、kexec のリブートとは異なります。kexec およびカーネル切り替え (kernel switching) 機能は、systemd のソフトリブートでは使用できません。ソフトリブートはユーザー空間のみを再起動し、カーネルはそのままの状態にするためです。これにより継続性が確保され、ハードウェアをリセットせずにカーネルを変更することで発生する可能性のある複雑さや不整合を回避できます。新しいカーネルバージョンを含む更新されたオペレーティングシステムイメージでは、従来どおりの完全な再起動が必要です。