「*** System restart required ***」はいつ再起動すべきか？ダウンタイムを最小化する運用判断ルール

この記事は約6分で読めます。
この記事が役立ったらブックマーク！ あとで読み返したり、環境構築時のリファレンスに活用できます
B! はてなブックマークに追加

UbuntuサーバーへSSHログインした際、ウェルカムメッセージ（MOTD）の末尾に表示されるこの一文。

Plaintext
27 additional security updates can be applied with ESM Apps.
Learn more about enabling ESM Apps service at https://ubuntu.com/esm

*** System restart required ***

「今すぐ再起動（sudo reboot）すべきか？」「稼働中のWebサイトやAPIが止まるから後回しでいいのか？」と迷う場面は少なくありません。

本記事では、このメッセージが表示される技術的メカニズムと、「即座に再起動すべきケース」と「週末やメンテ枠まで延期してよいケース」の見極め方、そして再起動時のダウンタイムを最小限に抑える事前準備の手順を解説します。

1. なぜ「System restart required」が表示されるのか？

この通知は、「稼働中のメモリ上に読み込まれている古いバイナリやカーネルを、OS全体の再起動なしには最新化できないアップデートが適用された」 ことを意味します。

Ubuntuでは、パッケージ更新時に再起動が必要と判定されると、内部的に /var/run/reboot-required というフラグファイルが生成されます。SSHログイン時のスクリプト（pam_motd）がこのファイルの存在を検知し、バナーに警告文を表示する仕組みです。

再起動を要求する主なパッケージは以下の通りです。

  • Linuxカーネル（linux-image-*）:OSの根幹。新しいカーネルをロードするにはシステムの完全なリブートが必須です。
  • glibc（libc6）:すべてのプロセスが利用するC標準共有ライブラリ。プロセス単位の再起動では完全に切り替えが難しいため、通常はシステム再起動が推奨されます。
  • systemdや主要な初期化プロセス:PID 1を含むコアコンポーネントの更新時。

2. いつ再起動すべきか？判断の切り分け基準

「警告が出た＝今すぐ何が何でも再起動」ではありません。状況に応じた判断基準を持ちましょう。

即座（または当日夜間）に再起動すべきケース

  • 重大な脆弱性（リモートコード実行や権限昇格など、CVEスコアが高いもの）のカーネル修正が入った場合
  • ハードウェアドライバやファイルシステムのクリティカルなバグ修正が入った場合

計画メンテナンス（数日〜1週間以内）まで延期してよいケース

  • 特定のローカル権限昇格バグで、サーバーに一般ユーザーのログイン権限を一切与えていない（単一Webサーバー運用）場合
  • 稼働中のコアサービス（Nginx、PHP-FPM、MariaDB等）単体の再起動で主要なセキュリティパッチが反映されている場合

3. 実践：何が再起動を求めているのかを特定する

闇雲に再起動する前に、どのパッケージが原因で再起動を要求されているのかを確認します。

原因パッケージの確認

Bash
cat /var/run/reboot-required.pkgs

出力例：

Plaintext
linux-image-6.8.0-45-generic
linux-base
libc6

上記のように linux-image-* や libc6 が含まれている場合、OS全体の再起動以外にパッチを完全適用する手段はありません。

needrestart コマンドでサービス単位の影響度を可視化する

Ubuntuには、ライブラリ更新後に「どのデーモンが古いライブラリを掴んだままか」を診断するツールが標準または簡単に導入できます。

Bash
sudo needrestart
  • NEEDRESTART-KSTA: 1 (Reboot Required): カーネルの更新があるため再起動が必要。
  • Services to be restarted: NginxやRedisなど、個別のサービス再起動（systemctl restart）だけで古いライブラリの参照を解放できるものが一覧表示されます。

カーネルではなく個別ミドルウェアのみが原因であれば、サービス単位のリスタートだけで済む場合もあります。

4. ダウンタイムを最小化する安全な再起動手順

本番・商用環境で再起動を行う際は、単に sudo reboot を打つのではなく、以下の事前・事後チェックを行うことで不意の起動失敗を防ぎます。

ステップ1：設定ファイルの文法チェック（最重要）

再起動後にWebサーバーやDBが構文エラーで立ち上がらない事態を防ぐため、事前にコンフィグの整合性を確認します。

Bash
# Nginxの設定構文テスト
sudo nginx -t

# PHP-FPMの設定テスト
sudo php-fpm -t

ステップ2：自動起動（enabled）の確認

再起動後に自動で立ち上がるべきサービスが enabled になっているか確認します。

Bash
sudo systemctl is-enabled nginx php-fpm mariadb redis-server

すべて enabled と返ってくれば、再起動後に人手でコマンドを叩かなくても自動復旧します。

ステップ3：再起動の実行

Bash
sudo reboot

近年のNVMe SSDやクラウドVPSであれば、OS停止からネットワーク復旧までは通常30秒〜1分程度で完了します。

ステップ4：復旧後の疎通・ログ確認

SSH再接続後、各サービスが正常に稼働しているか確認します。

Bash
# 全体ステータスの確認
systemctl status nginx php-fpm mariadb redis-server

# ロードアベレージと起動直後プロセスの安定確認
top -c -b -n 1 | head -n 20

まとめ

*** System restart required *** は、システムがセキュアな状態へ移行するためのバトンを受け取っている合図です。

  • /var/run/reboot-required.pkgs でカーネル更新の有無を確認する
  • nginx -t などの構文チェックを済ませてから再起動をかける
  • 全サービスの enabled 状態を確認しておき、ダウンタイムを数十秒で完結させる

この段取りをルーチン化しておくことで、サーバーの堅牢性を保ちながら、予期せぬトラブルのない安定した再起動運用が可能になります。

コメント

タイトルとURLをコピーしました