• HOME
  • OSのカーネルアップデートとセキュリティパッチの適用手順（Ubuntu・RHEL系）

2026年9月9日

  • シェア
  • ツイート

    • 2026年9月9日

    OSのカーネルアップデートとセキュリティパッチの適用手順（Ubuntu・RHEL系）

    OS のセキュリティパッチは「更新を確認する → 影響を見る → 適用する → 再起動の要否を判断する → 動作を確認する」の順で進めると、WordPress を止める時間を短くできます。この記事では、Ubuntu/Debian 系と RHEL 系（AlmaLinux、Rocky Linux など）を例に、カーネルを含む更新の確認方法、自動更新の設定、再起動の判断、問題が起きたときに前のカーネルへ戻す方法を説明します。

    カーネル更新が他の更新と違う点

    多くのパッケージは、更新後にそのサービスを再起動すれば新しいコードで動きます。カーネルは OS そのものなので、新しいカーネルをインストールしても、再起動するまでは古いカーネルのまま動き続けます。「更新したのに脆弱性スキャンで古いと言われる」という相談の多くはこれが原因です。

    また、カーネル以外でも OpenSSL や glibc のような共有ライブラリを更新した場合、それを使っているプロセス（Nginx、PHP-FPM、MySQL など）を再起動するまでは古いライブラリがメモリ上に残ります。パッチの適用は「インストール」と「再起動（OS またはサービス）」の2段階で考えます。

    もう1つの注意点は、VPS の種類です。コンテナ型の仮想化（OpenVZ や LXC 系）の VPS では、カーネルはホスト側と共有されており、利用者がカーネルを更新することはできません。uname -r の結果がパッケージの更新後も変わらない場合は、サービスの仕様を確認してください。

    1. 現在の状態と更新を確認する

    # いま動いているカーネル
uname -r

# Ubuntu/Debian：インストール済みのカーネルと更新の一覧
dpkg -l 'linux-image*' | grep ^ii
sudo apt update
apt list --upgradable

# RHEL 系：インストール済みのカーネルとセキュリティ更新の一覧
rpm -q kernel
sudo dnf check-update --security
sudo dnf updateinfo list --security

    どの更新がどの脆弱性に対応しているかは、各ディストリビューションのセキュリティ情報で確認できます。Ubuntu は Ubuntu Security Notices（USN）、Debian は Debian Security Advisories（DSA）、Red Hat 系は Red Hat Security Advisories（RHSA）や各派生ディストリビューションの告知が一次情報です。ニュースで話題になった脆弱性が自分の環境に関係するかは、ここで対象バージョンを照らし合わせて判断します。

    2. 適用前の準備

    本番サーバーで作業する前に、次の準備をしておきます。

    • スナップショットまたはバックアップ：VPS やクラウドのスナップショット機能があれば作業直前に取得します。なければ、少なくとも WordPress のファイルとデータベースのバックアップを取ります。
    • コンソール接続の確認：再起動後に SSH がつながらない場合に備え、事業者の管理画面から使えるコンソールの場所を確認しておきます。
    • 作業時間の決定：アクセスの少ない時間帯を選び、必要ならメンテナンスの告知をします。
    • 検証環境での確認：同じ OS バージョンのステージング環境があれば、先に適用して WordPress とプラグインの動作を見ておきます。

    3. 更新を適用する

    # Ubuntu/Debian
sudo apt update
sudo apt upgrade

# RHEL 系：すべての更新
sudo dnf upgrade
# RHEL 系：セキュリティ更新だけ
sudo dnf upgrade --security

    Ubuntu/Debian では、apt upgrade は新しい依存パッケージを必要とする更新を保留することがあります。カーネルのメタパッケージ更新が保留された場合は、内容を確認したうえで sudo apt full-upgrade を使います。full-upgrade はパッケージの削除を伴うことがあるため、表示される一覧を読んでから進めてください。

    ディスク容量にも注意します。古いカーネルが溜まって /boot が満杯になると、更新が途中で失敗します。Ubuntu/Debian では sudo apt autoremove で不要な古いカーネルを整理できます。RHEL 系では /etc/dnf/dnf.conf の installonly_limit で保持するカーネルの数が決まっています。

    4. 再起動が必要かを判断する

    # Ubuntu/Debian：このファイルがあれば再起動が必要
cat /var/run/reboot-required
cat /var/run/reboot-required.pkgs

# Ubuntu/Debian：needrestart で再起動が必要なサービスを確認
sudo needrestart

# RHEL 系：OS の再起動が必要か（dnf-plugins-core / dnf-utils に含まれる）
sudo dnf needs-restarting -r
# RHEL 系：再起動が必要なプロセスの一覧
sudo dnf needs-restarting

    カーネルの更新があれば OS の再起動が必要です。ライブラリだけの更新なら、該当するサービスの再起動で済むことが多いです。needrestart は Ubuntu の新しいバージョンでは apt の実行後に自動で起動し、サービスの再起動を提案します。

    再起動を減らすライブパッチ

    再起動せずにカーネルの修正を当てる「ライブパッチ」という仕組みもあります。Ubuntu の Livepatch（Ubuntu Pro の機能）、RHEL の kpatch、TuxCare の KernelCare などが代表例です。ただし、すべての修正がライブパッチで提供されるわけではなく、いずれは通常の再起動が必要になります。対象のバージョンや契約条件は変わるため、各提供元の情報を確認してください（2026年10月現在）。

    5. 自動更新を設定する

    セキュリティ更新は、手作業だけに頼ると適用が遅れがちです。自動適用し、再起動だけは人が判断する、という運用がよく使われます。

    Ubuntu/Debian：unattended-upgrades

    sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

    詳細は /etc/apt/apt.conf.d/50unattended-upgrades で設定します。自動再起動の有無は次の項目で決まります。

    Unattended-Upgrade::Automatic-Reboot "false";
// 自動再起動を許可する場合は時刻も指定できる
// Unattended-Upgrade::Automatic-Reboot-Time "04:00";

    動作は sudo unattended-upgrade --dry-run --debug で確認でき、実行記録は /var/log/unattended-upgrades/ に残ります。

    RHEL 系：dnf-automatic

    sudo dnf install dnf-automatic

    /etc/dnf/automatic.conf で、適用する更新の種類と、適用まで行うかを設定します。

    [commands]
upgrade_type = security
apply_updates = yes
    sudo systemctl enable --now dnf-automatic.timer

    設定項目やタイマー名は dnf のバージョンによって変わることがあるため、インストールされたファイルのコメントを確認してから編集してください。

    6. 再起動後の確認

    再起動したら、次の順で確認します。

    uname -r                      # 新しいカーネルで起動しているか
systemctl --failed            # 起動に失敗したサービスがないか
systemctl status nginx php8.3-fpm mariadb   # サービス名は環境に合わせる
curl -I https://example.com/  # サイトが応答するか

    PHP-FPM のサービス名は PHP のバージョンやディストリビューションで異なります（RHEL 系では php-fpm が一般的です）。WordPress の管理画面にログインし、フォームの送信やメール送信など、外部と通信する機能も動かしてみます。

    7. 問題が起きたら前のカーネルで起動する

    新しいカーネルでドライバーやネットワークに問題が出た場合は、古いカーネルで起動し直せます。

    • 起動時の GRUB メニューで、詳細オプションから前のカーネルを選びます。VPS ではコンソール接続からメニューを操作します。
    • RHEL 系では sudo grubby --info=ALL で登録済みのカーネルを確認し、sudo grubby --set-default /boot/vmlinuz-バージョン で既定のカーネルを変更できます。

    前のカーネルで起動できたら、慌てて新しいカーネルを削除せず、ディストリビューションのバグ情報を確認し、修正版が出るまで既定のカーネルを固定しておきます。どうしても戻らない場合は、作業前のスナップショットから復元します。

    まとめ

    • カーネルは再起動するまで新しくならない。ライブラリ更新後はサービスの再起動も必要
    • コンテナ型 VPS ではカーネルを利用者が更新できない場合がある
    • 適用前にスナップショット・コンソール接続・作業時間・検証環境を準備する
    • reboot-required、needrestart、dnf needs-restarting で再起動の要否を判断する
    • unattended-upgrades や dnf-automatic でセキュリティ更新を自動化し、再起動は計画的に行う
    • 問題が出たら GRUB で前のカーネルを選び、原因を確かめてから次の手を打つ
    Views: 39

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲