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 の処理が完了した時点ですでに適用されています。

needs-restarting のインストール

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

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

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

needs-restarting -r
dnf needs-restarting -r

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

Rocky Linux 10 および AlmaLinux 10 系列では、引き続き DNF 4 が使用されています。2026-10-12 時点で、両方の BaseOS リポジトリには dnf 4.20.0 と dnf-plugins-core 4.7.0、および yum-utils が含まれており、dnf5 パッケージはありません。そのため、これらの環境の needs-restarting は、このページで説明するものと同じ dnf-plugins-core プラグインです。以下の説明はすべて適用されます。これには、再起動の必要性と終了コードを示す -r も含まれます。したがって、スクリプトから削除しないでください。Rocky および Alma 9 には、より古い dnf-plugins-core 4.3.0 ビルドが含まれています。2 つのビルドで動作が異なる箇所には、以下で印を付けています。

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 で囲んでいます。

再起動が必要と判定されるパッケージは、プラグイン内部の短い固定リストに定義されています。Rocky Linux 10 と AlmaLinux 10 のビルドでは、kernel、kernel-core、kernel-rt、glibc、linux-firmware、systemd、dbus、dbus-broker、dbus-daemon、microcode_ctl が含まれます。Rocky と Alma の 9 のビルドでは kernel-core がない以外は同じリストです。これは、次のセクションで説明する理由に関係します。思い込みで判断せず、実際の環境を確認してください。

各項目がリストに含まれる理由は、明確に説明できます。新しい kernel パッケージは /boot と /lib/modules にファイルを書き込むだけです。実行中の kernel をその下で交換することはできないため、再起動するまで変更は反映されません。システム上のほぼすべての userspace プロセスは glibc にリンクしており、PID 1 も例外ではありません。そのため「影響を受けるサービスを再起動する」とは 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 が変更されたら、関連するすべてのサービスでその library が読み込まれているかを調べるより、再起動するほうがよい」という判断です。

再起動のヒントが実際に判定している内容

needs-restarting -r は、実行中のカーネルのバージョンと、インストール済みで最も新しいカーネルのバージョンを比較しているわけではありません。タイムスタンプを比較しています。対象となるコアパッケージごとに RPM のインストール時刻を読み取り、システムの起動時刻と比較します。コアパッケージが最後の起動後にインストールされていれば、判定結果は「再起動が必要」です。起動時刻は、利用可能な場合は systemd の UnitsLoadStartTimestamp から D-Bus 経由で取得します。それ以外の場合は、/proc/1 の更新時刻と /proc/stat の btime フィールドのうち、後の時刻を使用します。

この仕組みには、把握しておくべき帰結があります。カーネルをインストールして再起動した後、ブート時のデフォルト設定が固定されているため古いカーネルで起動した場合、インストール時刻は起動時刻より前になります。そのため needs-restarting -r は何も通知しなくなります。これは、needs-restarting -r 自身が判定している問いには正しく答えています。ただし、あなたが確認したい問いとは異なります。カーネルは別途確認してください。

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

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

Rocky と Alma 9 には、別の差異があります。これらのプラグインのビルドは kernel を監視しますが kernel-core は監視しません。そのため、kernel パッケージなしで kernel-core を更新するトランザクションを実行すると、新しいカーネルがインストール済みで未実行の状態になります。それでも needs-restarting -r は再起動不要と報告します。Red Hat は、Enterprise Linux 9 についてこの動作を説明しています。kernel パッケージがインストールされたマシンで通常の dnf update を実行すると、そのパッケージも更新されるため、ヒントは引き続き通知します。rpm -q kernel を実行して確認してください。パッケージがインストールされていないと表示された場合、そのマシンでは再起動のヒントがカーネル更新を検出できません。代わりに uname -r と rpm -q --last kernel-core を比較してください。

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

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

sudo needs-restarting -s

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

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

1 つ目のコマンドは、影響を受ける各プロセスの PID とコマンドラインを表示します。2 つ目のコマンドは、すでに systemd サービスで管理されているプロセスを除外します。その結果、ログインシェル、tmux セッション、cron ジョブ、手動で起動したプロセスが残ります。これらは自動的に再起動されません。--exclude-servicesは Rocky と Alma 10 のビルドにのみ存在します。9 にはこのオプションがないため、sudo needs-restarting の一覧全体を読み、-s の出力にあるサービスに属するプロセスを除外してください。

dbus-broker.serviceなど、リブート層のパッケージに属するサービスを一覧から再起動しないでください。代わりにリブートします。2026-10-12 時点で、Rocky Linux と AlmaLinux がリリースするビルドでは、そのようなサービスも通常のサービスと同じように表示されます。CentOS Stream 10 のパッケージには、2026 年 7 月に変更が追加されました。この変更により、そのようなサービスは一覧から除外され、stderr に 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 で、9 では通常の sudo needs-restarting を使います。

dnf-automatic を使用するマシンで、未適用の修正が数週間残る理由

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

修正は /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 の live kernel patching が別の選択肢です。これは再起動せずに、実行中の kernel へ特定の修正を適用します。ただし、対象は kernel の問題の一部に限られ、glibc やサービスには対応しません。そのため、再起動を不要にする方法ではなく、再起動の間隔を延ばす方法として扱ってください。再起動するときは意図的に実行し、マシンが応答するまでログインした状態を維持します。kernel 更新は、マシンが復旧しない最も一般的な原因だからです。コンソールにアクセスできないマシンを再起動する前に、kernel 更新後に 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 と Debian でも同じです。対処方法も同じです。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 が yum-utils がインストールされていないことを示します。インストールするか、dnf-plugins-core が存在すればすぐに動作する dnf needs-restarting を呼び出します。
• エラーメッセージを表示せず、再起動チェックでスクリプトが停止する場合は、set -e で終了コード 1 が返されています。このコードは「再起動が必要」という意味です。そのため、スクリプトを終了させるのではなく、このコードに応じて分岐します。
• ライブラリ更新の直後に needs-restarting -s が何も表示しない場合は、通常、sudo なしで実行しています。root でなければ、自分のプロセスだけが対象になります。
• needs-restarting -r が再起動不要と報告し、uname -r が最新のインストール済みカーネルより古いバージョンを示している場合は、古いカーネルで起動している可能性があります。このチェックはインストール時刻と起動時刻を比較しますが、現在はどちらも過去の時刻です。grubby --default-kernel を確認してください。Rocky または Alma 9 では、別の原因もあります。更新によって kernel パッケージなしで kernel-core が変更された場合、9 のビルドはその変更を監視しないため、再起動が必要な状態が残ります。
• needs-restarting --exclude-services が認識されない引数のエラーで失敗する場合は、そのオプションがない 9 のビルドを使用しています。単純な sudo needs-restarting を使用してください。
• 再起動した数分後、次回の実行でサービスが再び表示される場合は、通常、別の仕組みがサービスを再起動しているか、unit が復帰に失敗しています。2 回目の再起動を行う前に、その unit の systemctl status を確認してください。

FAQ

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

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

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

短い一覧に含まれるコアパッケージの RPM インストール時刻と、システムのブート時刻を比較しているためです。実行中の kernel のバージョンと、インストール済みで最新の kernel のバージョンを比較することはありません。kernel をインストールして再起動した後、bootloader のデフォルト設定によって古い kernel で起動した場合、インストール時刻はブート時刻より前になるため、チェックでは問題が検出されません。Rocky と Alma 9 では、kernel パッケージなしで kernel-core の更新を行った場合も検出できません。9 用ビルドの一覧に kernel-core が含まれていないためです。実際の状態を確認するには、uname -r、rpm -q --last kernel、sudo grubby --default-kernel を実行します。

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

plugin 内にハードコードされた一覧があります。Rocky と Alma 10 では、kernel、kernel-core、kernel-rt、glibc、linux-firmware、systemd、dbus、dbus-broker、dbus-daemon、microcode_ctl が含まれます。9 では、kernel-core を除いた同じ一覧です。拡張することもできます。/etc/dnf/plugins/needs-restarting.d/ に .conf ファイルを配置し、パッケージ名を 1 行に 1 つずつ記載します。そこに記載した名前も再起動の判定対象になります。

dnf-automatic は単独でサーバーを再起動できますか？

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

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

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