Rocky/Almaで再起動が必要な更新を確認する方法

Rocky Linux と AlmaLinux で再起動が必要な更新

Rocky Linux と AlmaLinux では、dnf update は新しいファイルをディスクに書き込み、その時点で処理を終了します。起動中の kernel は動作し続けます。すでにライブラリを開いているプロセスは、開いた時点のコピーを使い続けます。Linux は、そのファイルを保持している最後のプロセスが終了するまで、古いファイルをディスク上で保持するためです。そのため、マシン上で利用可能な更新が 0 件と表示されても、更新によって置き換えられたコードが実行されていることがあります。両ディストリビューションは同じ Red Hat のソースを再構築しているため、この点に違いはありません。ここで扱う内容に関して、Rocky と Alma の選択を左右するのは互換性に関する方針と CPU サポートであり、動作の違いではありません。以下のコマンドが CentOS のマシンで使われていたものと同じなのも偶然ではありません。両プロジェクトは 2020 年の Stream 発表後、CentOS の代替として構築されました。

再起動が必要な更新と、サービスの再起動だけで済む更新を判断するには、マシンに確認する必要があります。その答えを返すコマンドが needs-restarting です。更新は 3 つの層に分かれます。kernel と一部の主要パッケージでは、完全な再起動が必要です。通常のライブラリ更新では、そのライブラリを使用するサービスを再起動する必要があります。それ以外の更新は、RPM の処理が完了した時点ですでに適用されています。

Install needs-restarting

needs-restarting は DNF プラグインです。このプラグインは dnf-plugins-core に含まれており、ほとんどの Rocky および Alma のインストール環境にすでに存在します。/usr/bin/needs-restarting コマンドは、dnf-utils に含まれる小さなラッパーです。

sudo dnf install -y dnf-utils
needs-restarting --help

どちらの表記でも同じコードが実行されます。ラッパーが DNF のサブコマンドを呼び出すためです。

needs-restarting -r
dnf needs-restarting -r

どちらのパッケージもディストリビューション独自のリポジトリから提供されます。そのため、この処理のために EPEL または CRB リポジトリを有効にする必要はありません。

Rocky Linux 10 および AlmaLinux 10 系では、dnf は DNF 5 で、needs-restarting は dnf5-plugins パッケージに含まれる独自のコマンドです。この環境では、オプションなしで dnf needs-restarting を実行すると、再起動が必要かどうかが直接表示されます。-r も引き続き受け付けられますが、マニュアルによると効果はなく、DNF 4 のスクリプトとの互換性を保つためだけに存在します。

Tier 1: 再起動が必要な更新

最初に再起動チェックを実行します。RPM データベースとシステムの起動時刻だけを読み取るため、高速で、root も必要ありません。

needs-restarting -r

起動後に重要な変更がない場合は、2 行を出力します。

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

変更がある場合は、Core libraries or services have been updated since boot-up:、検出したパッケージ名、続いて次の内容を出力します。

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943

終了コードも同じ結果を示します。再起動が不要な場合は 0、必要な場合は 1 です。スクリプトで判定するのはこの部分です。

if ! needs-restarting -r >/dev/null; then
  logger -t updates "reboot pending on $(hostname -s)"
fi

ここで終了コード 1 は失敗ではなく、通常の結果です。set -e の下では、保護していない needs-restarting -r によってその行でスクリプトが終了します。そのため、上の例では if で囲んでいます。

再起動が必要と判定するパッケージは、プラグイン内にハードコードされた短い一覧です。現在のバージョンでは、kernel、kernel-core、kernel-rt、glibc、linux-firmware、systemd、dbus、dbus-broker、dbus-daemon、microcode_ctl が含まれます。古いプラグインのビルドでは一覧が少し短いため、前提を置かずに自分の環境を確認してください。

各項目が一覧に含まれる理由は、明確に説明できます。新しい kernel パッケージは /boot と /lib/modules にファイルを書き込むだけです。実行中の kernel をその下で入れ替えることはできないため、起動し直すまで変更は反映されません。システム上のすべてのプロセスは glibc にリンクしています。つまり、「影響を受けるサービスを再起動する」とは PID 1 も再起動することになり、再起動のほうが安全です。dbus と dbus-broker はシステム上のすべてのクライアント接続を担っています。そのため、稼働中のマシンで bus を停止すると、接続中のクライアントが動作しなくなります。linux-firmware と microcode_ctl は起動時にロードされます。VPS では、microcode の部分によって通常は確認できる変化が生じません。物理 CPU は hypervisor ホストが管理しているためです。

独自のパッケージを追加することもできます。/etc/dnf/plugins/needs-restarting.d/ 配下の .conf ファイルは、1 行に 1 つのパッケージ名を記載した一覧として読み込まれ、その名前が再起動対象の一覧に追加されます。

echo 'openssl-libs' | sudo tee /etc/dnf/plugins/needs-restarting.d/openssl.conf

これは修正ではなく、ポリシーの選択です。「TLS library が変更されたら、マッピングしたすべてのサービスを特定するよりも再起動する」という判断です。

再起動のヒントが実際に基づく情報

needs-restarting -r は、実行中の kernel version と、インストール済みの最新 kernel version を比較しません。タイムスタンプを比較します。この主要パッケージ一覧に含まれる各パッケージについて、RPM のインストール時刻を読み取り、システムの起動時刻と比較します。主要パッケージが前回の起動後にインストールされていれば、結果は「再起動が必要」です。起動時刻は、利用可能な場合は systemd の UnitsLoadStartTimestamp を D-Bus 経由で取得します。それ以外の場合は、/proc/1 の更新時刻と /proc/stat の btime フィールドのうち、後の時刻を使用します。

この仕組みには、知っておくべき結果が1つあります。kernel をインストールして再起動した後、起動時のデフォルト設定が固定されているため古い kernel で起動した場合、インストール時刻は起動時刻より前になります。そのため needs-restarting -r は何も表示しなくなります。needs-restarting -r は自身が設定された問いには正しく答えています。しかし、それはあなたが確認したい問いではありません。kernel は別途確認してください。

uname -r
rpm -q --last kernel
sudo grubby --default-kernel

最初のコマンドは、現在実行中の kernel を表示します。rpm -q --last kernel の1行目は、直近にインストールされた kernel です。grubby --default-kernel は、次回起動時に bootloader が選択する kernel を表示します。この3つが一致しない場合は、コンソール経由で接続できないマシンを再起動する前に、起動時のデフォルト設定を修正してください。

サービス再起動が必要な更新

RPM が共有ライブラリを置き換えると、古いファイルのリンクを解除して新しいファイルを書き込みます。すでに古いファイルをメモリーマッピングしているプロセスは、古い inode を保持したまま、古いコードを実行し続けます。openssl-libs が最も重要なケースです。libcrypto の修正が Web サーバーに反映されるのは、その Web サーバーを再起動した後です。

sudo needs-restarting -s

これは、サービスの起動後に、サービス自身のファイルまたは依存関係にあるファイルが更新された systemd サービスを一覧表示します。sudo を使用します。root で実行しない場合、このツールは自分のプロセスに対応する /proc エントリしか読み取れません。そのため結果が少なく表示され、問題がないように見えます。

sudo needs-restarting
sudo needs-restarting --exclude-services

最初のコマンドは、影響を受けるすべてのプロセスについて PID とコマンドラインを表示します。2 つ目のコマンドは、すでに systemd サービスで管理されているプロセスを除外します。その結果、ログインシェル、tmux セッション、cron ジョブ、手動で起動したプロセスが残ります。これらは自動的には再起動されません。

一覧にあるサービスが再起動ではなく再起動 tier のパッケージでもある場合、ツールはその上に Warning: The following services should not be restarted but require a reboot: を表示します。その指示に従い、サービスではなくシステムを再起動してください。

残りのサービスは 1 つずつ再起動し、次へ進む前にそれぞれの状態を確認します。

sudo systemctl restart nginx
systemctl status nginx

一覧を systemctl restart にパイプしないでください。現在の SSH セッションが切断される可能性があるためです。RHEL 系では、sshd.service は KillMode=process とともに提供されます。そのため、待ち受けデーモンにシグナルを送るだけで、接続ごとのプロセスはそのまま残り、開いているセッションも維持されます。systemctl cat sshd | grep KillMode で自分の環境でも確認し、初回は必ず 2 つ目のセッションを開いたまま作業してください。

DNF を使わずに同じプロセスを確認することもできます。関連するファイルパスを確認したい場合に便利です。

sudo dnf install -y lsof
sudo lsof -n +c 0 2>/dev/null | grep -w DEL

DEL は、ディスク上から削除されたメモリーマッピング済みファイルを示します。操作する前にパスを確認してください。削除済みの一時ファイルやメモリーバックドファイルもここに表示されますが、それらは再起動の理由にはなりません。

Tier 3: その他すべて

ほとんどの更新はここに該当し、追加の対応は必要ありません。curl、tar、vim、dnf 自体のように、コマンドの起動時にだけファイルが読み込まれるパッケージは、RPM が処理を完了した時点で完全に適用されます。次回の実行時に新しいバイナリが読み込まれるためです。設定ファイル、スクリプト、ドキュメント、データパッケージも同様です。needs-restarting はこれらのいずれについても通知しません。この通知がないことが正しい結果であり、検出漏れではありません。

この Tier の注意点は、プロセスの実行期間です。更新前に起動したプロセスは、パッケージの内容がどれほど単純でも、終了するまで古い実行ファイルを使い続けます。そのために sudo needs-restarting --exclude-services があります。

dnf-automatic で動くマシンが未適用の修正を数週間抱える理由

ここで、3 つの層の違いが単なる知識ではなくなります。dnf-automatic による自動更新はタイマーでパッケージをインストールします。/etc/dnf/automatic.conf のデフォルトの reboot 設定は never です。apply_updates = yes と reboot = never の組み合わせでは、6 週間の間にカーネル更新を 6 回適用し、glibc の修正も適用したのに、マシンが 0 週目に起動したカーネルと C ライブラリを使い続けることがあります。更新ログには問題がありません。しかし、実行中のシステムには更新内容が何も反映されていません。

/etc/dnf/automatic.conf に次の 3 行を追加すると解決します。

[commands]
upgrade_type = security
apply_updates = yes
reboot = when-needed
reboot_command = "shutdown -r +5 'Rebooting after applying package updates'"

reboot は never、when-changed、when-needed を受け付けます。never がデフォルトで、再起動の判断をすべて管理者に委ねます。when-changed は、パッケージを変更したトランザクションの後に再起動します。単純ですが、動作を予測できます。when-needed は、直前に適用したトランザクションで再起動が必要かどうかを DNF に確認します。そのため、ユーザー空間だけを更新する夜間処理では再起動しません。実際に実行されるのは reboot_command です。デフォルトでは、ログイン中のユーザーに 5 分前に警告します。random_sleep とタイマーのスケジュールを設定し、マシンの復旧を確認できる時間帯に再起動されるようにしてください。

systemctl list-timers 'dnf-*' で有効にした unit を確認します。dnf-automatic には複数の variant が含まれており、すべてが同じ動作をするわけではありません。そのため、設定ファイルだけでは実行される処理を判断できません。

スケジュール実行の後は、ログではなくマシンに確認します。

needs-restarting -r; echo "exit: $?"
uname -r
rpm -q --last kernel | head -1

再起動の時間を設定できない場合は、VPS のライブカーネルパッチが別の方法です。これは再起動せずに、実行中のカーネルへ特定のカーネル修正を適用します。ただし、対象はカーネル問題の一部に限られ、glibc やサービスには何も対応しません。そのため、再起動をなくす方法ではなく、再起動の間隔を延ばす方法として扱ってください。再起動するときは、意図したタイミングで実行し、マシンが応答するまでログインしたままにします。カーネル更新は、マシンが復旧しない最も一般的な原因だからです。コンソールにアクセスできないマシンを再起動する前に、カーネル更新後に VPS が起動しない場合の対処方法を確認してください。また、再起動の確認を定期的なサーバーメンテナンスチェックリストに組み込み、インシデントの後でしか思い出さない作業にならないようにします。

Ubuntu と Debian で同じ処理を行う

混在したサーバー群では、それぞれに対応する方法が必要です。Ubuntu と Debian では、再起動フラグはコマンドではなくファイルです。パッケージスクリプトが /run/reboot-required を作成し、/run/reboot-required.pkgs にはそのファイルを要求したパッケージが一覧表示されます。そのため、[ -f /run/reboot-required ] は needs-restarting -r に相当する単純な方法です。古いドキュメントでは /var/run/reboot-required と記載されています。これは同じファイルを指します。/var/run が /run へのシンボリックリンクだからです。

サービス側は needrestart です。最近の Ubuntu Server のリリースではデフォルトでインストールされています。apt upgrade の実行中に動作し、sudo needrestart -r l を単独で実行すれば、何も変更せずに再起動が必要な対象を一覧表示できます。自動更新に関する問題も同じで、解決方法も同じです。Ubuntu の unattended-upgrades は /etc/apt/apt.conf.d/50unattended-upgrades で Unattended-Upgrade::Automatic-Reboot "true"; と Unattended-Upgrade::Automatic-Reboot-Time "02:00"; を受け取ります。

障害パターンと表示される内容

• needs-restarting: command not found は dnf-utils がインストールされていないことを示します。dnf-utils をインストールするか、dnf-plugins-core が存在すればすぐに動作する dnf needs-restarting を呼び出します。
• 再起動チェックでエラーメッセージを表示せずに停止するスクリプトは、set -e で終了コード 1 になっています。このコードは「再起動が必要」という意味です。そのため、スクリプトを終了させず、この終了コードに応じて分岐します。
• ライブラリを更新した直後に needs-restarting -s が何も表示しない場合、通常は sudo なしで実行しています。root でなければ、自分のプロセスだけが表示されます。
• needs-restarting -r が再起動不要と報告する一方で uname -r に古いバージョンが表示される場合は、古い kernel で起動しています。このチェックはインストール時刻と起動時刻を比較しますが、どちらも現在の起動より前のものです。grubby --default-kernel を確認してください。
• 再起動してから数分後、次の実行時にサービスが再び表示される場合は、通常、別の仕組みがサービスを再起動しているか、unit が正常に復帰していません。2 回目の再起動を行う前に、その unit の systemctl status を確認してください。

FAQ

Rocky Linux では dnf update によってサービスが再起動されますか？

原則として、再起動されません。トランザクションはファイルを書き込んで終了します。ただし、一部のパッケージには、アップグレード時に自身のサービスを再起動する RPM scriptlet が含まれています。そのため、動作はシステム全体の保証ではなく、パッケージごとに異なります。sudo needs-restarting -s を基準にしてください。これは、サービスの起動後に自身のファイルまたは依存関係にあるパッケージのファイルが変更されたサービスを、scriptlet の動作にかかわらず一覧表示します。

新しい kernel をインストールしたのに、needs-restarting -r が再起動不要と表示するのはなぜですか？

RPM の主要パッケージのインストール時刻と、システムの起動時刻を比較しているためです。実行中の kernel のバージョンと、インストール済みの最新 kernel のバージョンを比較することはありません。kernel をインストールして再起動した後、bootloader のデフォルト設定が古い kernel を指しているために古い kernel で起動した場合、インストール時刻は起動時刻より前になります。そのため、チェックでは問題が検出されません。実際の状態を確認するには、uname -r、rpm -q --last kernel、sudo grubby --default-kernel を実行してください。

Rocky と Alma では、どのパッケージが再起動のヒントを表示しますか？

plugin 内にハードコードされた一覧があり、現在のバージョンでは kernel、kernel-core、kernel-rt、glibc、linux-firmware、systemd、dbus、dbus-broker、dbus-daemon、microcode_ctl が含まれています。一覧は拡張できます。.conf ファイルを /etc/dnf/plugins/needs-restarting.d/ に配置し、パッケージ名を1行に1つずつ記述してください。これらの名前も再起動の判定対象になります。

dnf-automatic でサーバーを自動的に再起動できますか？

できます。/etc/dnf/automatic.conf の [commands] セクションで reboot = when-needed を設定すると、適用したトランザクションで再起動が必要な場合に限り再起動します。when-changed はパッケージに変更があった場合に毎回再起動し、never がデフォルトです。再起動の方法は reboot_command で制御します。デフォルトでは、ログイン中のユーザーに5分前の警告を表示します。コンソールにアクセスできない VPS で無人再起動を行うと復旧できない場合があるため、起動状態を復旧できるマシンでのみ有効にしてください。

needs-restarting はコンテナ内のプロセスを検出しますか？

実用上は検出できません。needs-restarting は実行中のプロセスをホストの RPM データベースと照合します。コンテナイメージ内のパッケージはそのデータベースに含まれないため、イメージに組み込まれた古いライブラリは表示されません。イメージを再ビルドして再デプロイしてください。ホスト側の状態は引き続き重要です。コンテナランタイムと、コンテナが共有する kernel はホストのパッケージであり、これらは検出されます。