【ITニュース解説】Stop Paying Full Reboot Downtime: Practical systemd soft-reboot on Linux

システム運用において、アプリケーションやライブラリの更新後、システム上のサービス群を新しい状態で確実に動作させる必要が頻繁に生じる。これまでの一般的な方法では、サーバー全体を再起動する「フルリブート」が選択されてきた。しかし、フルリブートは、ファームウェアの初期化、ブートローダーの起動、カーネルの読み込み、初期RAMディスクの準備といった一連のプロセスを経るため、システムが利用できないダウンタイムが長くなるという大きな問題があった。特にカーネル自体に変更がない場合でも、これらの低レベルなプロセスが毎回実行されるため、時間とリソースの無駄が生じていたのが実情だ。

この課題を解決するために、Linuxのシステム管理ツールであるsystemdは、バージョン254以降で「ソフトリブート」という新機能を導入した。ソフトリブートは、システムの中核であるカーネルを稼働させたまま、ユーザー空間（アプリケーションやサービスが動作する領域）だけを再起動するという画期的なアプローチである。これにより、フルリブートと比較してダウンタイムを大幅に短縮できる。ソフトリブートでは、ファームウェアやブートローダー、カーネルといった低レベルな部分は一切触れず、システムを管理する最初のプロセス（PID 1）が自身のプログラムを再実行し、新しいサービス群の起動プロセスを開始するのみだ。

ソフトリブートはsystemctl soft-rebootコマンドで実行される。このコマンドは、システムをsoft-reboot.targetという特別な状態へ移行させる。この過程で、実行中のユーザー空間プロセスは通常通り停止され、最終的に残ったプロセスは強制終了される。重要なのは、完全なシャットダウンプロセスやカーネルの再初期化をスキップする点だ。このため、カーネルのバージョンや/proc/sys、/sys以下のカーネルパラメータの状態は、ソフトリブート後も維持される。

システムには、再起動の深さに応じて三つの主要な方法がある。一つ目は「ソフトリブート」で、カーネルやファームウェアをスキップし、ユーザー空間のみをリフレッシュする。アプリケーションの更新や、後述するルートファイルシステムの切り替えに利用される。二つ目は「kexec」で、これは新しいカーネルに切り替えるが、ファームウェアやブートローダーの多くをスキップする。カーネルのアップデートに有効だ。三つ目は「フルリブート」で、systemctl rebootにより実行され、ファームウェアからカーネルまで全てが再初期化される。これはファームウェアの更新や大規模なハードウェア変更時に適している。ソフトリブートは、これらの中で最も影響範囲が限定され、高速なユーザー空間のリフレッシュ手段だと理解すべきだ。

ソフトリブートを利用するには、systemdのバージョンが254以降であること、そしてroot権限が必要となる。主な利用シナリオは、ユーザー空間のパッケージ更新や設定変更後のサービス再起動、あるいはイメージベースのルートファイルシステム切り替えだ。カーネルの状態や/proc/sys、/sysの各種設定はリセットされないため、これらの変更が必要な場合はフルリブートが必要となる。特に、カーネルや初期RAMディスクが更新された場合は、ソフトリブートでは新しいカーネルを読み込めないため、kexecまたはフルリブートが不可欠だ。

ソフトリブートの大きな特徴として、/run/nextroot/ディレクトリを利用したルートファイルシステムの切り替え機能がある。これは、実行中のカーネルを維持したまま、新しいOSイメージや異なるユーザー空間環境へ移行できる強力な機能だ。例えば、A/Bアップデートを行うシステムで、新しいルートファイルシステムを事前に/run/nextroot/にマウントしておけば、ソフトリブートの実行時にその新しいルートファイルシステムへと切り替わって起動する。これにより、稼働中にOSのバージョンアップや大規模なシステム変更を迅速に適用できる。/run/nextroot/は、既存の/run上の一時ディレクトリやマウントポイント、シンボリックリンクとして準備できる。

ただし、/run/nextroot/が設定されている場合、systemctl rebootコマンドを実行すると意図せずソフトリブートが実行されてしまう点に注意が必要だ。これは自動的な動作だが、もし確実にフルリブートが必要な場合は、export SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1という環境変数を設定した上でsystemctl rebootを実行する必要がある。

ソフトリブートはユーザー空間を再起動するが、一部のリソースを次のユーザー空間サイクルに引き継ぐことも可能だ。例えば、/runディレクトリはソフトリブートを跨いでマウントされたままとなるため、/run/nextroot/のステージングや一時的な情報共有に利用できる。しかし、/runを永続的なストレージとして扱うべきではない。また、systemdのファイルディスクリプタストア機能を利用することで、サービスが保持していたファイルディスクリプタを次のサイクルに引き継ぐことができる。FileDescriptorStorePreserve=yesなどの設定を用いることで、サービスが停止してもファイルディスクリプタストアを維持することが可能だ。さらに、ソケットユニットも適切に設定すれば、そのソケットは開いたままとなり、クライアントはユーザー空間の再起動中も接続を維持できる可能性がある。

特定のサービスプロセスをソフトリブート後も継続して稼働させる「サバイバープロセス」という特殊な機能も存在する。これには特別な設定が必要だが、この方法は通常は避けるべきだとされている。なぜなら、サバイバープロセスは古いファイルシステムマウントやライブラリをメモリ上に固定し、そのプロセスのコード更新をスキップするため、部分的に古いシステム状態が残存するという「半更新」の状態を引き起こす可能性があるからだ。

実運用における一般的なパターンとしては、カーネルに変更がないユーザー空間のパッケージ更新後、sudo systemctl soft-rebootを実行してサービス群をクリーンな状態にリフレッシュする方法がある。ただし、新しいカーネルや初期RAMディスクがインストールされた場合は、ソフトリブートではこれらを有効化できないため、kexecまたはフルリブートを計画する必要がある。

ソフトリブートの成功を確認するためには、いくつかのチェックポイントがある。uname -rコマンドでカーネルのバージョンが変更されていないこと、systemctl show -p UserspaceTimestampでユーザー空間の起動時刻が新しくなっていること、そしてsystemctl --failedで起動失敗したサービスがないことを確認する。/run/nextroot/を利用した場合は、findmnt /コマンドで新しいルートファイルシステムに切り替わっていることを確認することが重要だ。

ソフトリブートが適さない場面も明確に存在する。新しいカーネルやモジュール、初期RAMディスクを適用したい場合は、systemctl kexecまたはフルリブートが必要となる。ファームウェアの変更やUEFI設定の更新が必要な場合も、フルリブートが不可欠だ。また、/proc/sysやカーネルオブジェクトの状態を完全にリセットしたい場合も、フルリブートが求められる。システムのクラッシュダンプやコールドデバイスの再プローブなど、カーネルレベルの動作が関わる場面でもソフトリブートは適切ではない。

最後に、ソフトリブートを導入する際には、まずテスト環境の仮想マシンなどで十分に検証を行うことが推奨される。カーネルとユーザー空間のタイムスタンプの変化などを確認し、システムの挙動を理解することが重要だ。特別な理由がない限り、サバイバープロセスやファイルディスクリプタストアによるリソースの引き継ぎは避けるべきだ。システム監視においては、カーネルの稼働時間とユーザー空間の起動時間という二つの異なる時間を理解し、それぞれを適切に監視することが、ソフトリブート環境での安定稼働に繋がる。ソフトリブートは、カーネルやファームウェアの変更が不要で、ユーザー空間だけをクリーンにしたい場合に、ダウンタイムを最小限に抑えるための強力なツールである。しかし、その限界と特性を理解し、適切な場面で利用することが不可欠である。