手順

1. パッケージの利用可能なバージョンをリスト表示します。

   $ yum repoquery <package_name>

   たとえば、kernel-core パッケージの利用可能なバージョンをリスト表示します。

   $ yum repoquery kernel-core
   kernel-core-0:4.18.0-147.0.2.el8_1.x86_64
   kernel-core-0:4.18.0-147.0.3.el8_1.x86_64
   kernel-core-0:4.18.0-147.3.1.el8_1.x86_64
   kernel-core-0:4.18.0-147.5.1.el8_1.x86_64
   kernel-core-0:4.18.0-147.8.1.el8_1.x86_64
   kernel-core-0:4.18.0-147.el8.x86_64
   …​

2. パッケージ内のファイルをリスト表示します。

   $ yum repoquery -l <package_name>

   たとえば、kernel-core-0:5.14.0-162.23.1.el9_1.x86_64 パッケージ内のファイルをリスト表示します。

   $ yum repoquery -l kernel-core-0:4.18.0-147.8.1.el8_1.x86_64
   /boot/.vmlinuz-4.18.0-147.8.1.el8_1.x86_64.hmac
   /boot/System.map-4.18.0-147.8.1.el8_1.x86_64
   /boot/config-4.18.0-147.8.1.el8_1.x86_64
   /boot/initramfs-4.18.0-147.8.1.el8_1.x86_64.img
   /boot/symvers-4.18.0-147.8.1.el8_1.x86_64.gz
   /boot/vmlinuz-4.18.0-147.8.1.el8_1.x86_64
   /etc/ld.so.conf.d/kernel-4.18.0-147.8.1.el8_1.x86_64.conf
   /lib/modules
   /lib/modules/4.18.0-147.8.1.el8_1.x86_64
   ...

手順

1. カーネルを更新するには、次のコマンドを入力します。

   # yum update kernel

   このコマンドは、カーネルと、利用可能な最新バージョンへのすべての依存関係を更新します。

2. システムを再起動して、変更を有効にします。

手順

1. 読み込むカーネルモジュールを選択します。

   モジュールは /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ ディレクトリーにあります。

2. 関連するカーネルモジュールを読み込みます。

   # modprobe <MODULE_NAME>

   注記

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

手順

1. ロード済みの全カーネルモジュールをリスト表示します。

   # lsmod

2. アンロードするカーネルモジュールを選択します。

   カーネルモジュールに依存関係がある場合は、カーネルモジュールをアンロードする前に、これらをアンロードします。依存関係のあるモジュールを特定する方法は、Listing currently loaded kernel modules および Kernel module dependencies を参照してください。

3. 関連するカーネルモジュールをアンロードします。

   # modprobe -r <MODULE_NAME>

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

手順

1. システムをブートローダーで起動します。
2. カーソルキーを使用して、関連するブートローダーエントリーを強調表示します。

3. e キーを押してエントリーを編集します。

   図2.1 カーネルブートメニュー

   
4. カーソルキーを使用して、linux で始まる行に移動します。

5. modprobe.blacklist=module_name を行末に追加します。

   図2.2 カーネルブートエントリー

   

   serio_raw カーネルモジュールは、起動プロセスの初期段階でアンロードする不正なモジュールを示しています。

6. Ctrl+X を押して、変更した設定を使用して起動します。

手順

1. 起動プロセス中に読み込むカーネルモジュールを選択します。

   モジュールは /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ ディレクトリーにあります。

2. モジュールの設定ファイルを作成します。

   # echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf

   注記

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

3. 必要に応じて、関連モジュールが読み込まれたことを確認します。

   $ lsmod | grep <MODULE_NAME>

   上記のコマンド例は成功し、関連するカーネルモジュールを表示します。

手順

1. lsmod コマンドを使用して、現在実行中のカーネルに読み込まれているモジュールを一覧表示します。

   $ lsmod
   Module                  Size  Used by
   tls                   131072  0
   uinput                 20480  1
   snd_seq_dummy          16384  0
   snd_hrtimer            16384  1
   …

   出力で、読み込みを阻止するモジュールを特定します。

   • または、/lib/modules/<KERNEL-VERSION>/kernel/<SUBSYSTEM>/ ディレクトリーに読み込まれないようにするアンロードしたカーネルモジュールを特定します。以下に例を示します。

     $ ls /lib/modules/4.18.0-477.20.1.el8_8.x86_64/kernel/crypto/
     ansi_cprng.ko.xz        chacha20poly1305.ko.xz  md4.ko.xz               serpent_generic.ko.xz
     anubis.ko.xz            cmac.ko.xz…

2. 拒否リストとして機能する設定ファイルを作成します。

   # touch /etc/modprobe.d/denylist.conf

3. 任意のテキストエディターで、カーネルへの自動読み込みから除外するモジュール名を blacklist 設定コマンドと組み合わせます。以下に例を示します。

   # Prevents <KERNEL-MODULE-1> from being loaded
   blacklist <MODULE-NAME-1>
   install <MODULE-NAME-1> /bin/false
   
   # Prevents <KERNEL-MODULE-2> from being loaded
   blacklist <MODULE-NAME-2>
   install <MODULE-NAME-2> /bin/false
   …

   blacklist コマンドは、モジュールが、拒否リストにない別のカーネルモジュールの依存関係として読み込まれることを阻止しないため、install 行も定義する必要があります。この場合、システムはモジュールをインストールする代わりに /bin/false を実行します。ハッシュ記号で始まる行は、ファイルをより読みやすくするために使用可能なコメントです。

   注記

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

4. 再構築を行う前に、現在の初期 RAM ディスクイメージのバックアップコピーを作成します。

   # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date +%m-%d-%H%M%S).img

   • または、カーネルモジュールの自動読み込みを阻止するカーネルバージョンに対応する初期 RAM ディスクイメージのバックアップコピーを作成します。

     # cp /boot/initramfs-<VERSION>.img /boot/initramfs-<VERSION>.img.bak.$(date +%m-%d-%H%M%S)

5. 新しい初期 RAM ディスクイメージを生成して、変更を適用します。

   # dracut -f -v

   • システムで現在使用中のものとは異なるカーネルバージョンの初期 RAM ディスクイメージを構築する場合は、ターゲット initramfs とカーネルバージョンの両方を指定します。

     # dracut -f -v /boot/initramfs-<TARGET-VERSION>.img <CORRESPONDING-TARGET-KERNEL-VERSION>

6. システムを再起動します。

   $ reboot

手順

1. 以下の内容で /root/testmodule/test.c を作成します。

   #include <linux/module.h>
   #include <linux/kernel.h>
   
   int init_module(void)
       { printk("Hello World\n This is a test\n"); return 0; }
   
   void cleanup_module(void)
       { printk("Good Bye World"); }

   test.c ファイルは、カーネルモジュールに主な機能を提供するソースファイルです。このファイルは、組織的な目的で、専用の /root/testmodule/ ディレクトリーに作成されています。モジュールをコンパイルすると、/root/testmodule/ ディレクトリーには複数のファイルが含まれます。

   test.c ファイルには、システムライブラリーから次のものが含まれます。

   • サンプルコードの printk() 機能には、linux/kernel.h ヘッダーファイルが必要です。
   • linux/module.h ファイルには、C 言語で記述した複数のソースファイルで共有する関数宣言とマクロ定義が含まれています。
2. 次に、init_module() 関数および cleanup_module() 関数に従い、テキストを出力するカーネルロギング機能 printk() を起動および終了します。

3. 以下の内容で /root/testmodule/Makefile を作成します。

   obj-m := test.o

   Makefile には、コンパイラーが、test.o という名前のオブジェクトファイルを作成する必要がある指示が含まれています。obj-m ディレクティブは、生成される test.ko ファイルを、読み込み可能なカーネルモジュールとしてコンパイルすることを指定します。もしくは、obj-y ディレクティブは、組み込みカーネルモジュールとして test.ko をビルドするように指示します。

4. カーネルモジュールをコンパイルします。

   # make -C /lib/modules/$(uname -r)/build M=/root/testmodule modules
   make: Entering directory '/usr/src/kernels/4.18.0-305.el8.x86_64'
     CC [M]  /root/testmodule/test.o
     Building modules, stage 2.
     MODPOST 1 modules
   WARNING: modpost: missing MODULE_LICENSE() in /root/testmodule/test.o
   see include/linux/module.h for more information
     CC      /root/testmodule/test.mod.o
     LD [M]  /root/testmodule/test.ko
   make: Leaving directory '/usr/src/kernels/4.18.0-305.el8.x86_64'

   コンパイラーは、各ソースファイル (test.c) のオブジェクトファイル (test.o) を中間手順として作成してから、それらを最終カーネルモジュール (test.ko) にリンクします。

   コンパイルが成功すると、/root/testmodule/ には、コンパイル済みカスタムカーネルモジュールに関連する追加ファイルが含まれます。コンパイル済みモジュール自身は、test.ko ファイルで表されます。

検証

1. 必要に応じて、/root/testmodule/ ディレクトリーのコンテンツを確認します。

   # ls -l /root/testmodule/
   total 152
   -rw-r—​r--. 1 root root    16 Jul 26 08:19 Makefile
   -rw-r—​r--. 1 root root    25 Jul 26 08:20 modules.order
   -rw-r—​r--. 1 root root     0 Jul 26 08:20 Module.symvers
   -rw-r—​r--. 1 root root   224 Jul 26 08:18 test.c
   -rw-r—​r--. 1 root root 62176 Jul 26 08:20 test.ko
   -rw-r—​r--. 1 root root    25 Jul 26 08:20 test.mod
   -rw-r—​r--. 1 root root   849 Jul 26 08:20 test.mod.c
   -rw-r—​r--. 1 root root 50936 Jul 26 08:20 test.mod.o
   -rw-r—​r--. 1 root root 12912 Jul 26 08:20 test.o

2. カーネルモジュールを /lib/modules/$(uname -r)/ ディレクトリーにコピーします。

   # cp /root/testmodule/test.ko /lib/modules/$(uname -r)/

3. モジュールの依存関係のリストを更新します。

   # depmod -a

4. カーネルモジュールを読み込みます。

   # modprobe -v test
   insmod /lib/modules/4.18.0-305.el8.x86_64/test.ko

5. カーネルモジュールが正常に読み込まれたことを確認します。

   # lsmod | grep test
   test                   16384  0

6. カーネルリングバッファーから最新のメッセージを読み込みます。

   # dmesg
   [74422.545004] Hello World
                   This is a test

手順

1. 公開鍵を sb_cert.cer ファイルにエクスポートします。

   # certutil -d /etc/pki/pesign \
              -n 'Custom Secure Boot key' \
              -Lr \
              > sb_cert.cer

2. 公開鍵を MOK リストにインポートします。

   # mokutil --import sb_cert.cer

3. この MOK 登録要求の新しいパスワードを入力してください。

4. マシンを再起動します。

   shim ブートローダーは、保留中の MOK キー登録要求を認識し、MokManager.efi を起動して、UEFI コンソールから登録を完了できるようにします。

5. Enroll MOK を選択し、プロンプトが表示されたら、この要求に関連付けたパスワードを入力し、登録を確認します。

   公開鍵が MOK リストに永続的に追加されます。

   キーが MOK リストに追加されると、UEFI セキュアブートが有効になっている場合は、このブートおよび後続のブートで .platform キーリングに自動的に伝達されます。

手順

1. 公開鍵を sb_cert.cer ファイルにエクスポートします。

   # certutil -d /etc/pki/pesign \
              -n 'Custom Secure Boot key' \
              -Lr \
              > sb_cert.cer

2. NSS データベースからキーを PKCS #12 ファイルとして抽出します。

   # pk12util -o sb_cert.p12 \
              -n 'Custom Secure Boot key' \
              -d /etc/pki/pesign

3. 前のコマンドでプロンプトが表示されたら、秘密鍵を暗号化する新しいパスワードを入力します。

4. 暗号化されていない秘密鍵をエクスポートします。

   # openssl pkcs12 \
            -in sb_cert.p12 \
            -out sb_cert.priv \
            -nocerts \
            -nodes

   重要

   暗号化されていない秘密鍵は慎重に取り扱ってください。

5. カーネルモジュールに署名します。次のコマンドは、カーネルモジュールファイル内の ELF イメージに署名を直接追加します。

   # /usr/src/kernels/$(uname -r)/scripts/sign-file \
             sha256 \
             sb_cert.priv \
             sb_cert.cer \
             my_module.ko

検証

1. カーネルモジュールの署名に関する情報を表示します。

   # modinfo my_module.ko | grep signer
     signer:         Your Name Key

   生成時に入力した名前が署名に記載されていることを確認します。

   注記

   この追加された署名は ELF イメージセクションには含まれず、また ELF イメージの正式な一部ではありません。したがって、readelf などのユーティリティーは、カーネルモジュールの署名を表示できません。

2. モジュールをロードします。

   # insmod my_module.ko

3. モジュールを削除 (アンロード) します。

   # modprobe -r my_module.ko

手順

1. 公開鍵がシステムキーリング上にあることを確認します。

   # keyctl list %:.platform

2. カーネルモジュールを必要なカーネルの extra/ ディレクトリーにコピーします。

   # cp my_module.ko /lib/modules/$(uname -r)/extra/

3. モジュールの依存関係のリストを更新します。

   # depmod -a

4. カーネルモジュールを読み込みます。

   # modprobe -v my_module

5. 必要に応じて、起動時にモジュールをロードするには、モジュールを /etc/modules-loaded.d/my_module.conf ファイルに追加します。

   # echo "my_module" > /etc/modules-load.d/my_module.conf

手順

1. GRUB 2 ブートメニューを起動します。
2. 起動するカーネルを選択します。
3. e キーを押してカーネルパラメーターを編集します。
4. カーソルを下に移動してカーネルコマンドラインを見つけます。カーネルコマンドラインは、64 ビット IBM Power シリーズおよび x86-64 BIOS ベースのシステムの場合は linux で始まり、UEFI システムの場合は linuxefi で始まります。

5. カーソルを行の最後に移動します。

   注記

   行の最初に移動するには Ctrl+a を押します。行の最後に移動するには Ctrl+e を押します。システムによっては、Home キーおよび End キーも機能する場合があります。

6. 必要に応じてカーネルパラメーターを編集します。たとえば、緊急モードでシステムを実行するには、linux 行の最後に emergency パラメーターを追加します。

   linux   ($root)/vmlinuz-4.18.0-348.12.2.el8_5.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet emergency

   システムメッセージを有効にするには、rhgb および quiet パラメーターを削除します。

7. Ctrl+x を押して、選択したカーネルと変更したコマンドラインパラメーターで起動します。

手順

1. /etc/default/grub ファイルに以下の 2 つの行を追加します。

   GRUB_TERMINAL="serial"
   GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"

   最初の行は、グラフィカルターミナルを無効にします。GRUB_TERMINAL キーは、GRUB_TERMINAL_INPUT および GRUB_TERMINAL_OUTPUT の値を上書きします。

   2 行目は、ボーレート (--speed)、パリティー、および他の値を使用中の環境とハードウェアに適合するように調整します。以下のログファイルのようなタスクには、115200 のように非常に高いボーレートが推奨されます。

2. GRUB 設定ファイルを更新します。

   • BIOS ベースのマシンの場合:

     # grub2-mkconfig -o /boot/grub2/grub.cfg

   • UEFI ベースのマシンの場合:

     # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

3. システムを再起動して、変更を有効にします。

手順

1. すべてのパラメーターとその値をリストします。

   # sysctl -a

   注記

   # sysctl -a コマンドは、ランタイム時およびシステムの起動時に調整できるカーネルパラメーターを表示します。

2. パラメーターを一時的に設定するには、次のように入力します。

   # sysctl <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

   上記のサンプルコマンドは、システムの実行中にパラメーター値を変更します。この変更は、再起動なしですぐに適用されます。

   注記

   変更は、システムの再起動後にデフォルトに戻ります。

手順

1. すべてのパラメーターをリストします。

   # sysctl -a

   このコマンドは、ランタイム時に設定できるカーネルパラメーターをすべて表示します。

2. パラメーターを永続的に設定すします。

   # sysctl -w <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE> >> /etc/sysctl.conf

   サンプルコマンドは、調整可能な値を変更して、/etc/sysctl.conf ファイルに書き込みます。これにより、カーネルパラメーターのデフォルト値が上書きされます。変更は、再起動なしで即座に永続的に反映されます。

手順

1. /etc/sysctl.d/ に新しい設定ファイルを作成します。

   # vim /etc/sysctl.d/<some_file.conf>

2. カーネルパラメーターを 1 行に 1 つずつ含めます。

   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

3. 設定ファイルを作成します。

4. マシンを再起動して、変更を有効にします。

   • また、再起動せずに変更を適用するには、以下を実行します。

     # sysctl -p /etc/sysctl.d/<some_file.conf>

     このコマンドにより、以前に作成した設定ファイルから値を読み取ることができます。

手順

1. 設定するカーネルパラメーターを特定します。

   # ls -l /proc/sys/<TUNABLE_CLASS>/

   コマンドが返した書き込み可能なファイルは、カーネルの設定に使用できます。読み取り専用権限を持つユーザーは、現在の設定についてフィードバックを提供します。

2. カーネルパラメーターにターゲットの値を割り当てます。

   # echo <TARGET_VALUE> > /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

   このコマンドでは、システムが再起動すると設定変更が消えます。

3. 必要に応じて、新しく設定した設定したカーネルパラメーターの値を確認します。

   # cat /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

手順

1. GRUB ブート画面で、e キーを押して編集します。

2. Linux 行の末尾に次のパラメーターを追加します。

   systemd.unit=rescue.target

   

3. Ctrl+x を押して、レスキューモードで起動します。

   

手順

1. GRUB ブート画面で、e キーを押して編集します。

2. Linux 行の末尾に次のパラメーターを追加します。

   systemd.unit=emergency.target

   

3. Ctrl+x を押して緊急モードで起動します。

   

手順

1. GRUB ブート画面で、e キーを押して編集します。

2. Linux 行の末尾に次のパラメーターを追加します。

   systemd.debug-shell

   

3. 必要に応じて、デバッグ オプションを追加します。

   注記

   カーネルコマンドラインに debug オプションを追加すると、ログメッセージの数が増加します。systemd では、カーネルコマンドラインオプションの debug が、systemd.log_level=debug のショートカットになりました。

4. Ctrl+x を押して、デバッグシェルを起動します。

手順

1. Ctrl+Alt+F9 を押してデバッグシェルに接続します。

   仮想マシンを使用している場合は、このキーの組み合わせを送信するには、仮想化アプリケーションからのサポートが必要です。たとえば、Virtual Machine Manager を使用している場合は、メニューから Send Key → Ctrl+Alt+F9 を選択します。

2. デバッグシェルは認証を必要としないため、TTY9 で次のようなプロンプトが表示されます。

手順

1. インストールソースからホストを起動します。

2. インストールメディアのブートメニューで、Troubleshooting を選択します。

   

3. Troubleshooting メニューで Rescue a Red Hat Enterprise Linux system オプションを選択します。

   

4. Rescue メニューで 1 を選択し、Enter キーを押して続行します。

   

5. 以下のようにファイルシステム root を変更します。

   sh-4.4# chroot /mnt/sysimage

   

6. passwd コマンドを入力し、コマンドラインに表示される指示にしたがって root パスワードを変更します。

   

7. 時間がかかるディスクの SELinux の再ラベルを防ぐために、autorelable ファイルを削除します。

   sh-4.4# rm -f /.autorelabel

8. exit コマンドを入力して、chroot 環境を終了します。
9. exit コマンドを再び実行して初期化を再開し、システム起動を完了します。

手順

1. システムを起動し、GRUB ブート画面で e キーを押して編集を行います。

2. Linux 行の末尾に rd.break パラメーターを追加します。

   

3. Ctrl+x を押して変更したパラメーターでシステムを起動します。

   

4. ファイルシステムを書き込み可能で再マウントします。

   switch_root:/# mount -o remount,rw /sysroot

5. ファイルシステムの root を変更します。

   switch_root:/# chroot /sysroot

6. passwd コマンドを入力し、コマンドラインに表示される指示に従います。

   

7. 次回のシステム起動時にすべてのファイルにラベルを付け直します。

   sh-4.4# touch /.autorelabel

8. ファイルシステムを 読み取り専用 で再マウントします。

   sh-4.4# mount -o remount,ro /

9. exit コマンドを入力して、chroot 環境を終了します。

10. exit コマンドを再び実行して初期化を再開し、システム起動を完了します。

    注記

    SELinux の再ラベル付けプロセスには時間がかかる場合があります。プロセスが完了すると、システムが自動的に再起動します。

手順

1. すべてのカーネル引数をデフォルトカーネルからこの新しいカーネルエントリーにコピーします。

   # grubby --add-kernel=new_kernel --title="entry_title" --initrd="new_initrd" --copy-default

2. 利用可能なブートエントリーの一覧を取得します。

   # ls -l /boot/loader/entries/*
   -rw-r--r--. 1 root root 408 May 27 06:18 /boot/loader/entries/67db13ba8cdb420794ef3ee0a8313205-0-rescue.conf
   -rw-r--r--. 1 root root 536 Jun 30 07:53 /boot/loader/entries/67db13ba8cdb420794ef3ee0a8313205-4.18.0-372.9.1.el8.x86_64.conf
   -rw-r--r--  1 root root 336 Aug 15 15:12 /boot/loader/entries/d88fa2c7ff574ae782ec8c4288de4e85-4.18.0-193.el8.x86_64.conf

3. 新たなブートエントリーを作成します。たとえば、4.18.0-193.el8.x86_64 カーネルの場合は、次のようにコマンドを発行します。

   # grubby --grub2 --add-kernel=/boot/vmlinuz-4.18.0-193.el8.x86_64 --title="Red Hat Enterprise 8 Test" --initrd=/boot/initramfs-4.18.0-193.el8.x86_64.img --copy-default

手順

1. kernelopts 変数を使用してカーネルパラメーターをリスト表示します。

   # grub2-editenv - list | grep kernelopts
   kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet

2. カーネルのコマンドラインパラメーターを変更します。パラメーターを追加、削除、または変更できます。たとえば、debug パラメーターを追加するには、次のように入力します。

   # grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) <debug>"

3. オプション: 新しく追加したパラメーターが kernelopts に追加されていることを確認します。

   # grub2-editenv - list | grep kernelopts
   kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet debug

4. システムを再起動して、変更を有効にします。

手順

1. /etc/default/grub ファイルで GRUB_TIMEOUT_STYLE オプションを次のように設定します。

   GRUB_TIMEOUT_STYLE=hidden

2. 変更を有効にするために grub.cfg ファイルを再ビルドします。

   • BIOS ベースのマシンで、次のように入力します。

     # grub2-mkconfig -o /boot/grub2/grub.cfg

   • UEFI ベースのマシンでは、次のように入力します。

     # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

3. 起動時に Esc キーを押すと、起動可能なカーネルのリストが表示されます。

手順

1. grub2-set-default コマンドにインデックスを渡して、デフォルトでロードするオペレーティングシステムまたはカーネルを指定します。以下に例を示します。

   # grubby --set-default-index=1
   The default is /boot/loader/entries/d5151aa93c444ac89e78347a1504d6c6-4.18.0-348.el8.x86_64.conf with index 1 and kernel /boot/vmlinuz-4.18.0-348.el8.x86_64

   GRUB は、/boot/grub2/grubenv の saved_entry ディレクティブのキーとして数値を使用して、オペレーティングシステムがロードされるデフォルトの順序を変更することをサポートしています。

   注記

   インデックスカウントはゼロから始まります。したがって、前の例では、GRUB は 2 番目のエントリーをロードします。次にインストールされたカーネルで、インデックス値は上書きされます。

   注記

   grubby を使用して、カーネルのインデックスを見つけることもできます。詳細は、カーネルの GRUB メニューエントリーの表示 を参照してください。

2. オプション: システムが常に特定のメニューエントリーを使用するように強制します。

   1. 利用可能なメニューエントリーを一覧表示します。

      # grubby --info=ALL

   2. /etc/default/grub ファイルの GRUB_DEFAULT ディレクティブのキーとして、メニューエントリー名またはリスト内のメニューエントリーの位置番号を使用します。以下に例を示します。

      GRUB_DEFAULT=example-gnu-linux

3. 変更を有効にするために grub.cfg ファイルを再ビルドします。

   • BIOS ベースのマシンで、次のように入力します。

     # grub2-mkconfig -o /boot/grub2/grub.cfg

   • UEFI ベースのマシンでは、次のように入力します。

     # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

手順

1. GRUB がインストールされているデバイスに GRUB を再インストールします。たとえば、sda がデバイスの場合は、以下のようになります。

   # grub2-install /dev/sda

2. システムを再起動して、変更を有効にします。

   # reboot

手順

1. grub2-efi および shim ブートローダーファイルを再インストールします。

   # yum reinstall grub2-efi shim

2. システムを再起動して、変更を有効にします。

   # reboot

手順

1. GRUB を保存するディスクパーティションを特定します。

   # bootlist -m normal -o
   sda1

2. ディスクパーティションに GRUB を再インストールします。

   # grub2-install partition

   パーティション を、前の手順で見つけた GRUB パーティション (/dev/sda1 など) に置き換えます。

3. システムを再起動して、変更を有効にします。

   # reboot

手順

1. 設定ファイルを削除します。

   # rm /etc/grub.d/*
   # rm /etc/sysconfig/grub

2. パッケージを再インストールします。

   • BIOS ベースのマシンで、次のように入力します。

     # yum reinstall grub2-tools

   • UEFI ベースのマシンでは、次のように入力します。

     # yum reinstall grub2-efi shim grub2-tools

3. 変更を有効にするために grub.cfg ファイルを再ビルドします。

   • BIOS ベースのマシンで、次のように入力します。

     # grub2-mkconfig -o /boot/grub2/grub.cfg

   • UEFI ベースのマシンでは、次のように入力します。

     # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

4. GRUB の再インストール 手順に従って、/boot/ パーティションに GRUB を復元します。

手順

1. root で grub2-setpassword コマンドを実行します。

   # grub2-setpassword

2. ユーザーのパスワードを入力し、Enter キーを押してパスワードを確認します。

   Enter password:
   Confirm the password:

手順

1. /boot/loader/entries/ ディレクトリーから、変更するブートエントリーのブートローダー仕様 (BLS) ファイルを開きます。
2. grub_users で始まる行を見つけます。このパラメーターは追加の引数を menuentry に渡します。

3. grub_users 属性を、スーパーユーザー以外にエントリーを起動できるユーザー名に設定します。デフォルトでは、このユーザーは root です。サンプル設定ファイルは次のとおりです。

   title Red Hat Enterprise Linux (4.18.0-221.el8.x86_64) 8.3
   (Ootpa)
   version 4.18.0-221.el8.x86_64
   linux /vmlinuz-4.18.0-221.el8.x86_64
   initrd /initramfs-4.18.0-221.el8.x86_64.img $tuned_initrd
   options $kernelopts $tuned_params
   id rhel-20200625210904-4.18.0-221.el8.x86_64
   grub_users root
   grub_arg --unrestricted
   grub_class kernel

4. BLS ファイルを保存して閉じます。

1. コンソールログレベル。コンソールに出力されるメッセージの最低優先度を定義します。
2. 明示的なログレベルが付いていないメッセージのデフォルトのログレベル。
3. コンソールのログレベルに、可能な限り低いログレベル設定を設定します。

4. 起動時のコンソールのログレベルのデフォルト値を設定します。

   上記の各値は、エラーメッセージを処理するさまざまなルールを定義します。

手順

1. KDUMP フィールドで、kdump がまだ有効になっていない場合は有効にします。

   
2. メモリー予約をカスタマイズする必要がある場合は、Kdump Memory Reservation で Manual を選択します。

3. KDUMP フィールドの Memory To Be Reserved (MB) で、kdump に必要なメモリー予約を設定します。

   

手順

1. kdump がシステムにインストールされているかどうかを確認します。

   # rpm -q kexec-tools

   このパッケージがインストールされている場合は以下を出力します。

   kexec-tools-2.0.17-11.el8.x86_64

   このパッケージがインストールされていない場合は以下を出力します

   package kexec-tools is not installed

2. kdump および必要なパッケージをインストールします。

   # dnf install kexec-tools

手順

1. crashkernel= オプションを準備してください。

   • たとえば、128 MB のメモリーを予約するには、以下を使用します。

     crashkernel=128M

   • または、インストールされているメモリーの合計量に応じて、予約メモリーサイズを変数に設定できます。変数へのメモリー予約の構文は crashkernel=<range1>:<size1>,<range2>:<size2> です。以下に例を示します。

     crashkernel=512M-2G:64M,2G-:128M

     システムメモリーの合計量が 512 MB - 2 GB の範囲にある場合、64 MB のメモリーを予約します。メモリーの合計量が 2 GB を超える場合、メモリー予約は 128 MB になります。

   • 予約メモリーのオフセット。

     一部のシステムでは、crashkernel の予約が早い段階で行われるため、特定の固定オフセットでメモリーを予約する必要があります。また、特別な用途のために、さらに多くのメモリーの予約が必要になることもあります。オフセットを定義すると、予約メモリーはそこから開始されます。予約メモリーをオフセットするには、以下の構文を使用します。

     crashkernel=128M@16M

     この例では、kdump は 16 MB (物理アドレス 0x01000000) から始まる 128 MB のメモリーを予約します。offset パラメーターを 0 に設定するか、完全に省略すると、kdump は予約メモリーを自動的にオフセットします。変数のメモリー予約を設定する場合は、この構文を使用することもできます。その場合、オフセットは常に最後に指定されます。以下に例を示します。

     crashkernel=512M-2G:64M,2G-:128M@16M

2. crashkernel= オプションをブートローダー設定に適用します。

   # grubby --update-kernel=ALL --args="crashkernel=<value>"

   <value> は、前のステップで準備した crashkernel= オプションの値に置き換えます。

手順

1. root で、/etc/kdump.conf 設定ファイルを編集し、#core_collector makedumpfile -l --message-level 1 -d 31 の行頭にあるハッシュ記号 ("#") を削除します。
2. クラッシュダンプファイルの圧縮を有効にするには、以下のコマンドを実行します。

手順

1. root で、/etc/kdump.conf 設定ファイルの #failure_action の行頭にあるハッシュ記号 (#) を削除します。

2. 値を任意のアクションに置き換えます。

   failure_action poweroff

手順

1. kdump サービスを有効にします。

   # kdumpctl restart

2. kdump サービスのステータスを確認します。kdumpctl コマンドを使用すると、出力をコンソールに出力できます。

   # kdumpctl status
     kdump:Kdump is operational

   あるいは、systemctl コマンドを使用すると、出力は systemd ジャーナルに出力されます。

3. カーネルクラッシュを開始して、kdump 設定をテストします。sysrq-trigger キーの組み合わせによりカーネルがクラッシュし、必要に応じてシステムが再起動します。

   # echo c > /proc/sysrq-trigger

   カーネルの再起動時に、/etc/kdump.conf ファイルで指定した場所に address-YYYY-MM-DD-HH:MM:SS/vmcore ファイルが作成されます。デフォルトは /var/crash/ です。

手順

1. 現在実行中のカーネルに読み込まれるモジュールのリストを表示します。読み込みをブロックするカーネルモジュールを選択します。

   $ lsmod
   
   Module                  Size  Used by
   fuse                  126976  3
   xt_CHECKSUM            16384  1
   ipt_MASQUERADE         16384  1
   uinput                 20480  1
   xt_conntrack           16384  1

2. /etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_APPEND= 変数を更新します。以下に例を示します。

   KDUMP_COMMANDLINE_APPEND="rd.driver.blacklist=hv_vmbus,hv_storvsc,hv_utils,hv_netvsc,hid-hyperv"

   modprobe.blacklist=<modules> 設定オプションを使用した以下の例も検討してください。

   KDUMP_COMMANDLINE_APPEND="modprobe.blacklist=emcp modprobe.blacklist=bnx2fc modprobe.blacklist=libfcoe modprobe.blacklist=fcoe"

3. kdump サービスを再起動します。

   # systemctl restart kdump

手順

1. crashkernel= の推定値を出力します。

   # *kdumpctl estimate*
   
   Encrypted kdump target requires extra memory, assuming using the keyslot with minimum memory requirement
      Reserved crashkernel:    256M
      Recommended crashkernel: 652M
   
      Kernel image size:   47M
      Kernel modules size: 8M
      Initramfs size:      20M
      Runtime reservation: 64M
      LUKS required size:  512M
      Large modules: <none>
      WARNING: Current crashkernel size is lower than recommended size 652M.

2. crashkernel の値を増やして、必要なメモリー量を設定します。
3. システムを再起動します。

手順

1. インストールしたすべてのカーネルに crashkernel= コマンドラインパラメーターを追加します。

   # grubby --update-kernel=ALL --args="crashkernel=xxM"

   xxM は必要なメモリー (メガバイト単位) です。

2. kdump を有効にします。

   # systemctl enable --now kdump.service

手順

1. マシンにインストールされているカーネルをリスト表示します。

   # ls -a /boot/vmlinuz-*
   /boot/vmlinuz-0-rescue-2930657cd0dc43c2b75db480e5e5b4a9
   /boot/vmlinuz-4.18.0-330.el8.x86_64
   /boot/vmlinuz-4.18.0-330.rt7.111.el8.x86_64

2. 特定の kdump カーネルを、システムの Grand Unified Bootloader (GRUB) 設定に追加します。

   以下に例を示します。

   # grubby --update-kernel=vmlinuz-4.18.0-330.el8.x86_64 --args="crashkernel=xxM"

   xxM は必要なメモリー予約 (メガバイト単位) です。

3. kdump を有効にします。

   # systemctl enable --now kdump.service

手順

1. 現在のセッションで kdump を停止するには、以下のコマンドを実行します。

   # systemctl stop kdump.service

2. kdump を無効にするには、以下を行います。

   # systemctl disable kdump.service

手順

1. Web コンソールで、Kernel Dump タブを開き、Kernel crash dump スイッチをオンに設定して kdump サービスを起動します。
2. コマンドラインで kdump のメモリー使用量を設定します。

3. Kernel Dump タブで、Crash dump location に移動し、ダンプの場所へのパスを含むリンクをクリックします。

   

4. vmcore ダンプファイルを保存するターゲットディレクトリーを指定します。

   • ローカルファイルシステムの場合は、ドロップダウンメニューから Local Filesystem を選択します。

     

   • SSH プロトコルを使用したリモートシステムの場合は、ドロップダウンメニューから Remote over SSH を選択し、次のフィールドを指定します。

     • Server フィールドに、リモートサーバーのアドレスを入力します。
     • ssh key フィールドに、ssh キーの場所を入力します。
     • Directory フィールドに、ターゲットディレクトリーを入力します。

   • NFS プロトコルを使用したリモートシステムの場合は、ドロップダウンメニューから Remote over NFS を選択し、次のフィールドを指定します。

     • Server フィールドに、リモートサーバーのアドレスを入力します。
     • Export フィールドに、NFS サーバーの共有フォルダーの場所を入力します。

     • Directory フィールドに、ターゲットディレクトリーを入力します。

       注記

       Compression チェックボックスをオンにすると、vmcore ファイルのサイズを削減できます。

検証

1. Test configuration をクリックします。

   

2. Test kdump settings の下にある Crash system をクリックします。

   警告

   システムクラッシュを開始すると、カーネルの動作が停止し、システムがクラッシュしてデータが失われます。

手順

1. final_action を設定するには、/etc/kdump.conf ファイルを編集して、次のいずれかのオプションを追加します。

   • final_action reboot
   • final_action halt
   • final_action poweroff

2. 変更を有効にするには、kdump サービスを再起動します。

   # kdumpctl restart

手順:

1. ダンプが失敗した場合に実行するアクションを設定するには、/etc/kdump.conf ファイルを編集して、failure_action オプションの 1 つを指定します。

   • failure_action reboot
   • failure_action halt
   • failure_action poweroff
   • failure_action shell
   • failure_action dump_to_rootfs

2. 変更を有効にするには、kdump サービスを再起動します。

   # kdumpctl restart

手順

1. kdump のインストールと設定

2. fadump=on カーネルオプションを有効にします。

   # grubby --update-kernel=ALL --args="fadump=on"

3. (オプション) デフォルトを使用する代わりに、予約済みのブートメモリーを指定する場合は、crashkernel=xxM オプションを有効にします。ここで、xx は必要なメモリーの量 (メガバイト単位) です。

   # grubby --update-kernel=ALL --args="crashkernel=xxM fadump=on"

   重要

   ブート設定オプションを指定するときは、実行する前にすべてのブート設定オプションをテストしてください。kdump カーネルの起動に失敗した場合は、crashkernel= 引数に指定した値を徐々に増やして、適切な値を設定します。

手順

1. sadump に対して kdump が予想どおりに起動するように /etc/sysctl.conf ファイルで以下の行を追加または編集します。

   kernel.panic=0
   kernel.unknown_nmi_panic=1

   警告

   特に、kdump の後にシステムが再起動しないようにする必要があります。kdump が vmcore ファイルの保存失敗後にシステムを再起動すると、sadump を呼び出すことができません。

2. /etc/kdump.conf の failure_action パラメーターを halt または shell として適切に設定します。

   failure_action shell

手順

1. 関連するリポジトリーを有効にします。

   # subscription-manager repos --enable baseos repository

   # subscription-manager repos --enable appstream repository

   # subscription-manager repos --enable rhel-8-for-x86_64-baseos-debug-rpms

2. crash パッケージをインストールします。

   # yum install crash

3. kernel-debuginfo パッケージをインストールします。

   # yum install kernel-debuginfo

   パッケージ kernel-debuginfo は実行中のカーネルに対応し、ダンプ分析に必要なデータを提供します。

手順

1. crash ユーティリティーを起動するには、以下の 2 つの必要なパラメーターを渡します。

   • debug-info (圧縮解除された vmlinuz イメージ) (特定の kernel-debuginfo パッケージに含まれる /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux など)

   • 実際の vmcore ファイル。/var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

     その結果の crash コマンドは次のようになります。

     # crash /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

     kdump で取得したのと同じ <kernel> のバージョンを使用します。

     例20.1 crash ユーティリティーの実行

     以下の例は、4.18.0-5.el8.x86_64 カーネルを使用して、2018 年 10 月 6 日 (14:05 PM) に作成されたコアダンプの分析を示しています。

     ...
     WARNING: kernel relocated [202MB]: patching 90160 gdb minimal_symbol values
     
           KERNEL: /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux
         DUMPFILE: /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore  [PARTIAL DUMP]
             CPUS: 2
             DATE: Sat Oct  6 14:05:16 2018
           UPTIME: 01:03:57
     LOAD AVERAGE: 0.00, 0.00, 0.00
            TASKS: 586
         NODENAME: localhost.localdomain
          RELEASE: 4.18.0-5.el8.x86_64
          VERSION: #1 SMP Wed Aug 29 11:51:55 UTC 2018
          MACHINE: x86_64  (2904 Mhz)
           MEMORY: 2.9 GB
            PANIC: "sysrq: SysRq : Trigger a crash"
              PID: 10635
          COMMAND: "bash"
             TASK: ffff8d6c84271800  [THREAD_INFO: ffff8d6c84271800]
              CPU: 1
            STATE: TASK_RUNNING (SYSRQ)
     
     crash>

2. 対話型プロンプトを終了して crash を停止するには、exit または q と入力します。

   例20.2 crash ユーティリティーの終了

   crash> exit
   ~]#

手順

1. Kernel Oops Analyzer ツールにアクセスします。

2. カーネルクラッシュの問題を診断するには、vmcore に生成されたカーネルの oops ログをアップロードします。

   • テキストメッセージまたは vmcore-dmesg.txt を入力として指定して、カーネルクラッシュの問題を診断することも可能です。

     
3. DETECT をクリックして、makedumpfile からの情報に基づいて既知のソリューションと oops メッセージを比較します。

手順

1. kdump サービスが有効でアクティブであることを確認します。

   # systemctl is-enabled kdump.service && systemctl is-active kdump.service
   enabled
   active

   kdump が有効ではなく、実行されていない場合は、必要な設定をすべて設定し、kdump サービスが有効化されていることを確認します。

2. 起動カーネルの initramfs イメージを、early kdump 機能で再構築します。

   # dracut -f --add earlykdump

3. rd.earlykdump カーネルコマンドラインパラメーターを追加します。

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="rd.earlykdump"

4. システムを再起動して、変更を反映させます。

   # reboot

1. カーネルパッチモジュールは、/var/lib/kpatch/ ディレクトリーにコピーされ、次回の起動時に systemd を介して、カーネルへの再適用として登録されます。
2. 実行中のカーネルに kpatch モジュールがロードされ、新しいコードのメモリー内の場所を指定するポインターを使用して、新しい機能が ftrace メカニズムに登録されます。
3. パッチが当てられた機能にカーネルがアクセスすると、ftrace メカニズムにリダイレクトされます。これにより、元々の機能は回避され、パッチを当てたバージョンの機能にカーネルをリダイレクトします。

手順

1. 必要に応じて、カーネルバージョンを確認します。

   # uname -r
   4.18.0-94.el8.x86_64

2. カーネルのバージョンに一致するライブパッチパッケージを検索します。

   # yum search $(uname -r)

3. ライブパッチパッケージをインストールします。

   # yum install "kpatch-patch = $(uname -r)"

   上記のコマンドでは、特定カーネルにのみに最新の累積パッチをインストールし、適用します。

   ライブパッチパッケージのバージョンが 1-1 以上である場合には、パッケージにパッチモジュールが含まれます。この場合、ライブパッチパッケージのインストール時に、カーネルにパッチが自動的に適用されます。

   カーネルパッチモジュールは、今後の再起動時に systemd システムおよびサービスマネージャーにより読み込まれる /var/lib/kpatch/ ディレクトリーにもインストールされます。

   注記

   指定のカーネルに利用可能なライブパッチがない場合は、空のライブパッチパッケージがインストールされます。空のライブパッチパッケージには、kpatch_version-kpatch_release 0-0 (例: kpatch-patch-4_18_0-94-0-0.el8.x86_64.rpm) が含まれます。空の RPM のインストールを行うと、指定のカーネルの将来のすべてのライブパッチにシステムがサブスクライブされます。

手順

1. 必要に応じて、インストール済みの全カーネルと、現在実行中のカーネルを確認します。

   # yum list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64         4.18.0-240.10.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   kernel-core.x86_64         4.18.0-240.15.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   ...
   
   # uname -r
   4.18.0-240.10.1.el8_3.x86_64

2. kpatch-dnf プラグインをインストールします。

   # yum install kpatch-dnf

3. カーネルライブパッチの自動サブスクリプションを有効にします。

   # yum kpatch auto
   Updating Subscription Management repositories.
   Last metadata expiration check: 19:10:26 ago on Wed 10 Mar 2021 04:08:06 PM CET.
   Dependencies resolved.
   ==================================================
    Package                             Architecture
   ==================================================
   Installing:
    kpatch-patch-4_18_0-240_10_1        x86_64
    kpatch-patch-4_18_0-240_15_1        x86_64
   
   Transaction Summary
   ===================================================
   Install  2 Packages
   …​

   このコマンドは、現在インストールされているすべてのカーネルをサブスクライブして、カーネルライブパッチを受け取ります。このコマンドは、インストールされている全カーネルに、最新の累積パッチ (存在する場合) をインストールして適用します。

   今後、カーネルを更新すると、新しいカーネルのインストールプロセス中にライブパッチが自動的にインストールされます。

   カーネルパッチモジュールは、今後の再起動時に systemd システムおよびサービスマネージャーにより読み込まれる /var/lib/kpatch/ ディレクトリーにもインストールされます。

   注記

   指定のカーネルに利用可能なライブパッチがない場合は、空のライブパッチパッケージがインストールされます。空のライブパッチパッケージには、kpatch_version-kpatch_release 0-0 (例: kpatch-patch-4_18_0-240-0-0.el8.x86_64.rpm) が含まれます。空の RPM のインストールを行うと、指定のカーネルの将来のすべてのライブパッチにシステムがサブスクライブされます。

手順

1. 必要に応じて、インストール済みの全カーネルと、現在実行中のカーネルを確認します。

   # yum list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64         4.18.0-240.10.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   kernel-core.x86_64         4.18.0-240.15.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   ...
   
   # uname -r
   4.18.0-240.10.1.el8_3.x86_64

2. カーネルライブパッチへの自動サブスクリプションを無効にします。

   # yum kpatch manual
   Updating Subscription Management repositories.

手順

1. ライブパッチパッケージを選択します。

   # yum list installed | grep kpatch-patch
   kpatch-patch-4_18_0-94.x86_64        1-1.el8        @@commandline
   …​

   上記の出力例は、インストールしたライブパッチパッケージをリスト表示します。

2. ライブパッチパッケージを削除します。

   # yum remove kpatch-patch-4_18_0-94.x86_64

   ライブパッチパッケージが削除されると、カーネルは次回の再起動までパッチが当てられたままになりますが、カーネルパッチモジュールはディスクから削除されます。今後の再起動では、対応するカーネルにはパッチが適用されなくなります。

3. システムを再起動します。

4. ライブパッチパッケージが削除されたことを確認します。

   # yum list installed | grep kpatch-patch

   パッケージが正常に削除された場合、このコマンドでは何も出力されません。

5. 必要に応じて、カーネルのライブパッチソリューションが無効になっていることを確認します。

   # kpatch list
   Loaded patch modules:

   この出力例では、現在読み込まれているパッチモジュールがないため、カーネルにパッチが適用されておらず、ライブパッチソリューションがアクティブでないことが示されています。

手順

1. カーネルパッチモジュールを選択します。

   # kpatch list
   Loaded patch modules:
   kpatch_4_18_0_94_1_1 [enabled]
   
   Installed patch modules:
   kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)
   …​

2. 選択したカーネルパッチモジュールをアンインストールします。

   # kpatch uninstall kpatch_4_18_0_94_1_1
   uninstalling kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

   • アンインストールしたカーネルモジュールが読み込まれていることに注意してください。

     # kpatch list
     Loaded patch modules:
     kpatch_4_18_0_94_1_1 [enabled]
     
     Installed patch modules:
     <NO_RESULT>

     選択したモジュールをアンインストールすると、カーネルは次回の再起動までパッチが当てられますが、カーネルパッチモジュールはディスクから削除されます。

3. システムを再起動します。

4. 必要に応じて、カーネルパッチモジュールがアンインストールされていることを確認します。

   # kpatch list
   Loaded patch modules:
   …​

   上記の出力例では、ロードまたはインストールされたカーネルパッチモジュールが表示されていません。したがって、カーネルにパッチが適用されておらず、カーネルのライブパッチソリューションはアクティブではありません。

手順

1. kpatch.service が有効化されていることを確認します。

   # systemctl is-enabled kpatch.service
   enabled

2. kpatch.service を無効にします。

   # systemctl disable kpatch.service
   Removed /etc/systemd/system/multi-user.target.wants/kpatch.service.

   • 適用されたカーネルモジュールが依然としてロードされていることに注意してください。

     # kpatch list
     Loaded patch modules:
     kpatch_4_18_0_94_1_1 [enabled]
     
     Installed patch modules:
     kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

3. システムを再起動します。

4. 必要に応じて、kpatch.service のステータスを確認します。

   # systemctl status kpatch.service
   ● kpatch.service - "Apply kpatch kernel patches"
      Loaded: loaded (/usr/lib/systemd/system/kpatch.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

   この出力テストサンプルでは、kpatch.service が無効になっており、実行されていないことを証明しています。したがって、カーネルのライブパッチソリューションはアクティブではありません。

5. カーネルパッチモジュールがアンロードされたことを確認します。

   # kpatch list
   Loaded patch modules:
   <NO_RESULT>
   
   Installed patch modules:
   kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

   上記の出力例では、カーネルパッチモジュールがインストールされていても、カーネルにパッチが適用されていないことを示しています。

手順

1. CPU 消費を制限するアプリケーションのプロセス ID (PID) を特定します。

   # top
   top - 11:34:09 up 11 min,  1 user,  load average: 0.51, 0.27, 0.22
   Tasks: 267 total,   3 running, 264 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 49.0 us,  3.3 sy,  0.0 ni, 47.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
   MiB Mem :   1826.8 total,    303.4 free,   1046.8 used,    476.5 buff/cache
   MiB Swap:   1536.0 total,   1396.0 free,    140.0 used.    616.4 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    6955 root      20   0  228440   1752   1472 R  99.3   0.1   0:32.71 sha1sum
    5760 jdoe      20   0 3603868 205188  64196 S   3.7  11.0   0:17.19 gnome-shell
    6448 jdoe      20   0  743648  30640  19488 S   0.7   1.6   0:02.73 gnome-terminal-
       1 root      20   0  245300   6568   4116 S   0.3   0.4   0:01.87 systemd
     505 root      20   0       0      0      0 I   0.3   0.0   0:00.75 kworker/u4:4-events_unbound
   ...

   この top プログラムの出力例は、説明用のアプリケーション sha1sum (PID 6955) が CPU リソースを大量に消費することを示しています。

2. cpu リソースコントローラーディレクトリーにサブディレクトリーを作成します。

   # mkdir /sys/fs/cgroup/cpu/Example/

   このディレクトリーはコントロールグループを表します。ここに特定のプロセスを配置して、そのプロセスに特定の CPU 制限を適用できます。同時に、いくつかの cgroups-v1 インターフェイスファイルと cpu コントローラー固有のファイルがディレクトリーに作成されます。

3. オプション: 新しく作成されたコントロールグループを確認します。

   # ll /sys/fs/cgroup/cpu/Example/
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.procs
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.stat
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.shares
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpu.stat
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 notify_on_release
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 tasks

   この出力例は、特定の設定や制限を表す cpuacct.usage、cpu.cfs._period_us などのファイルを示しています。これは、Example コントロールグループのプロセスに設定できます。各ファイル名の前に、そのファイルが属するコントロールグループコントローラーの名前が接頭辞として追加されることに注意してください。

   デフォルトでは、新しく作成されたコントロールグループは、システムの CPU リソース全体へのアクセスを制限なしで継承します。

4. コントロールグループの CPU 制限を設定します。

   # echo "1000000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us
   # echo "200000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us

   • cpu.cfs_period_us ファイルは、コントロールグループの CPU リソースへのアクセスを再割り当てする頻度をマイクロ秒 (μs、ここでは "us" で表します) 単位で表します。上限は 1,000,000 マイクロ秒で、下限は 1,000 マイクロ秒です。

   • cpu.cfs_quota_us ファイルは、(cpu.cfs_period_us で定義されるように) コントロールグループのすべてのプロセスを 1 期間中に実行できる合計時間をマイクロ秒単位で表します。1 期間中にコントロールグループ内のプロセスがクォータで指定された時間をすべて使いきると、残りの時間はスロットルされて、次の期間まで実行できなくなります。下限は 1000 マイクロ秒です。

     上記のコマンド例は、CPU 時間制限を設定して、Example コントロールグループでまとめられているすべてのプロセスは、1 秒ごと (cpu.cfs_period_us に定義されている) に、0.2 秒間だけ (cpu.cfs_quota_us に定義されている) 実行できるようにしています。

5. オプション: 制限を検証します。

   # cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us
   1000000
   200000

6. アプリケーションの PID を Example コントロールグループに追加します。

   # echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs

   このコマンドによって、特定のアプリケーションが Example コントロールグループのメンバーとなり、Example コントロールグループに設定された CPU 制限を超えないようになります。PID は、システム内の既存のプロセスを表します。この PID 6955 は、プロセス sha1sum /dev/zero & に割り当てられており、cpu コントローラーの使用例を示すために使用されています。

検証

1. アプリケーションが指定のコントロールグループで実行されていることを確認します。

   # cat /proc/6955/cgroup
   12:cpuset:/
   11:hugetlb:/
   10:net_cls,net_prio:/
   9:memory:/user.slice/user-1000.slice/user@1000.service
   8:devices:/user.slice
   7:blkio:/
   6:freezer:/
   5:rdma:/
   4:pids:/user.slice/user-1000.slice/user@1000.service
   3:perf_event:/
   2:cpu,cpuacct:/Example
   1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service

   この出力例は、目的のアプリケーションのプロセスが Example コントロールグループで実行され、アプリケーションのプロセスに CPU 制限が適用されることを示しています。

2. スロットルしたアプリケーションの現在の CPU 使用率を特定します。

   # top
   top - 12:28:42 up  1:06,  1 user,  load average: 1.02, 1.02, 1.00
   Tasks: 266 total,   6 running, 260 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 11.0 us,  1.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.2 st
   MiB Mem :   1826.8 total,    287.1 free,   1054.4 used,    485.3 buff/cache
   MiB Swap:   1536.0 total,   1396.7 free,    139.2 used.    608.3 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    6955 root      20   0  228440   1752   1472 R  20.6   0.1  47:11.43 sha1sum
    5760 jdoe      20   0 3604956 208832  65316 R   2.3  11.2   0:43.50 gnome-shell
    6448 jdoe      20   0  743836  31736  19488 S   0.7   1.7   0:08.25 gnome-terminal-
     505 root      20   0       0      0      0 I   0.3   0.0   0:03.39 kworker/u4:4-events_unbound
    4217 root      20   0   74192   1612   1320 S   0.3   0.1   0:01.19 spice-vdagentd
   ...

   PID 6955 の CPU 消費が 99% から 20% に減少していることに注意してください。

手順

1. CPU 消費を制限するアプリケーションのプロセス ID (PID) を特定します。

   # top
   Tasks: 104 total,   3 running, 101 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 17.6 us, 81.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.8 hi,  0.0 si,  0.0 st
   MiB Mem :   3737.4 total,   3312.7 free,    133.3 used,    291.4 buff/cache
   MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3376.1 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     34578 root      20   0   18720   1756   1468 R  99.0   0.0   0:31.09 sha1sum
     34579 root      20   0   18720   1772   1480 R  99.0   0.0   0:30.54 sha1sum
         1 root      20   0  186192  13940   9500 S   0.0   0.4   0:01.60 systemd
         2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthreadd
         3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp
         4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par_gp
   ...

   この出力例は、PID 34578 および 34579(sha1sum の 2 つのアプリケーションとして識別) が多くのリソース (具体的には CPU) を消費していることを示しています。いずれも cgroups-v2 機能の管理に使用するアプリケーションの例です。

2. cpu および cpuset コントローラーが /sys/fs/cgroup/cgroup.controllers ファイルで利用可能であることを確認します。

   # cat /sys/fs/cgroup/cgroup.controllers
   cpuset cpu io memory hugetlb pids rdma

3. CPU 関連のコントローラーを有効にします。

   # echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control
   # echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_control

   これらのコマンドにより、/sys/fs/cgroup/ ルートコントロールグループ直下のサブグループに対して cpu および cpuset コントローラーが有効になります。サブグループ で指定した各プロセスに対して、基準に基づいてコントロールチェックを適用できます。

   ユーザーは任意のレベルの cgroup.subtree_control ファイルの内容を読み取り、直下のサブグループで有効にするコントローラーについて把握することができます。

   注記

   デフォルトでは、ルートコントロールグループの /sys/fs/cgroup/cgroup.subtree_control ファイルには memory と pids コントローラーが含まれます。

4. /sys/fs/cgroup/Example/ ディレクトリーを作成します。

   # mkdir /sys/fs/cgroup/Example/

   /sys/fs/cgroup/Example/ ディレクトリーはサブグループを定義します。また、前の手順では、このサブグループの cpu コントローラーおよび cpuset コントローラーを有効にしました。

   /sys/fs/cgroup/Example/ ディレクトリーを作成すると、cgroups-v2 インターフェイスファイルと cpu および cpuset のコントローラー固有のファイルがディレクトリーに自動的に作成されます。/sys/fs/cgroup/Example/ ディレクトリーには、memory および pids コントローラー用のコントローラー固有のファイルも含まれます。

5. 必要に応じて、新たに作成されたサブコントロールグループを確認します。

   # ll /sys/fs/cgroup/Example/
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.controllers
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.events
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.freeze
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.max.depth
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.max.descendants
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.procs
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.stat
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.subtree_control
   …​
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpuset.cpus
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cpuset.cpus.effective
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpuset.cpus.partition
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpuset.mems
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cpuset.mems.effective
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cpu.stat
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpu.weight
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpu.weight.nice
   …​
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 memory.events.local
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.high
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.low
   …​
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.current
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.events
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 pids.max

   出力例には、cpuset.cpus や cpu.max などのファイルが表示されます。これらのファイルは、cpuset コントローラーおよび cpu コントローラーに固有のものです。cpuset および cpu コントローラーは、/sys/fs/cgroup/cgroup.subtree_control ファイルを使用して、ルート (/sys/fs/cgroup/) の直下のサブコントローラーグループに対して手動で有効にされます。

   ディレクトリーには cgroup.procs または cgroup.controllers などの一般的な cgroup コントロールインターフェイスファイルがありますが、これは有効なコントローラーに関係なく、すべてのコントロールグループに共通のものです。

   memory.high および pids.max などのファイルは、memory および pids コントローラーに関連し、ルートコントロールグループ (/sys/fs/cgroup/) にあり、常にデフォルトで有効になります。

   デフォルトでは、新しく作成されたサブグループは、制限なしで、システムのすべての CPU およびメモリーリソースへのアクセスを継承します。

6. /sys/fs/cgroup/Example/ の CPU 関連のコントローラーを有効にし、CPU にのみ関連するコントローラーを取得します。

   # echo "+cpu" >> /sys/fs/cgroup/Example/cgroup.subtree_control
   # echo "+cpuset" >> /sys/fs/cgroup/Example/cgroup.subtree_control

   これらのコマンドにより、直下のサブコントロールグループに、(memory または pids コントローラーではなく) CPU 時間の配分の調整に関係するコントローラー だけが設定されるようになります。

7. /sys/fs/cgroup/Example/tasks/ ディレクトリーを作成します。

   # mkdir /sys/fs/cgroup/Example/tasks/

   /sys/fs/cgroup/Example/tasks/ ディレクトリーは、cpu および cpuset コントローラーにのみ関連するファイルを持つサブグループを定義します。

8. 必要に応じて、別のサブコントロールグループを確認します。

   # ll /sys/fs/cgroup/Example/tasks
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.controllers
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.events
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.freeze
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.depth
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.descendants
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.procs
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.stat
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.subtree_control
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.threads
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.type
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.max
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.pressure
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.effective
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.partition
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems.effective
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpu.stat
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight.nice
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 io.pressure
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 memory.pressure

9. CPU 時間を制御するプロセスが同じ CPU で競合していることを確認します。

   # echo "1" > /sys/fs/cgroup/Example/tasks/cpuset.cpus

   上記のコマンドは、Example/tasks サブコントロールグループに配置されるプロセスが同じ CPU 上で競合するようにします。この設定は、cpu コントローラーをアクティベートするのに重要です。

   重要

   cpu コントローラーは、該当のサブコントロールグループに、同じ CPU の CPU 時間を取り合うプロセスが 2 つ以上ある場合にのみ、有効になります。

検証手順

1. 必要に応じて、CPU 関連のコントローラーが直下のサブ cgroups に対して有効になっていることを確認します。

   # cat /sys/fs/cgroup/cgroup.subtree_control /sys/fs/cgroup/Example/cgroup.subtree_control
   cpuset cpu memory pids
   cpuset cpu

2. オプション:CPU 時間を制御するプロセスが同じ CPU で競合していることを確認します。

   # cat /sys/fs/cgroup/Example/tasks/cpuset.cpus
   1

手順

1. コントロールグループ内のリソース制限を実現するために CPU 帯域幅を設定します。

   # echo "200000 1000000" > /sys/fs/cgroup/Example/tasks/cpu.max

   最初の値は、一定の期間にサブグループにある全プロセスをまとめて実行できる許容される時間クォータ (マイクロ秒単位) です。2 番目の値は期間の長さを指定します。

   一期間中にコントロールグループ内のプロセスが全体としてこのクォータで指定した時間を使い切ってしまうと、残りの時間がスロットルされて、次の期間まで実行できなくなります。

   このコマンドは、/sys/fs/cgroup/Example/tasks サブグループの全プロセスが 1 秒ごとに 0.2 秒間のみ CPU で実行されるように、CPU 時間の配分の制御を設定します。つまり、毎秒 5 分の 1 です。

2. 必要に応じて、時間クォータを確認します。

   # cat /sys/fs/cgroup/Example/tasks/cpu.max
   200000 1000000

3. アプリケーションの PID を Example/tasks サブグループに追加します。

   # echo "34578" > /sys/fs/cgroup/Example/tasks/cgroup.procs
   # echo "34579" > /sys/fs/cgroup/Example/tasks/cgroup.procs

   上記のコマンド例は、目的のアプリケーションが Example/tasks サブグループのメンバーになり、このサブグループに設定された CPU 時間の配分を超えないようにします。

検証手順

1. アプリケーションが指定のコントロールグループで実行されていることを確認します。

   # cat /proc/34578/cgroup /proc/34579/cgroup
   0::/Example/tasks
   0::/Example/tasks

   上記の出力は、Example/tasks サブグループで実行される指定されたアプリケーションのプロセスを示しています。

2. スロットリングされたアプリケーションの現在の CPU 使用率を確認します。

   # top
   top - 11:13:53 up 23:10,  1 user,  load average: 0.26, 1.33, 1.66
   Tasks: 104 total,   3 running, 101 sleeping,   0 stopped,   0 zombie
   %Cpu(s):  3.0 us,  7.0 sy,  0.0 ni, 89.5 id,  0.0 wa,  0.2 hi,  0.2 si,  0.2 st
   MiB Mem :   3737.4 total,   3312.6 free,    133.4 used,    291.4 buff/cache
   MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3376.0 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     34578 root      20   0   18720   1756   1468 R  10.0   0.0  37:36.13 sha1sum
     34579 root      20   0   18720   1772   1480 R  10.0   0.0  37:41.22 sha1sum
         1 root      20   0  186192  13940   9500 S   0.0   0.4   0:01.60 systemd
         2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthreadd
         3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp
         4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par_gp
   ...

   PID 34578 および PID 34579 の CPU 使用率が 10% に減少していることが分かります。Example/tasks サブグループは、そのプロセスをまとめて 20% の CPU 時間に調整します。コントロールグループにプロセスが 2 つあるため、各プロセスは CPU 時間の 10% を使用できます。

手順

1. コントロールグループ内のリソース制限を実現するために、希望する CPU の重みを設定します。

   # echo "150" > /sys/fs/cgroup/Example/g1/cpu.weight
   # echo "100" > /sys/fs/cgroup/Example/g2/cpu.weight
   # echo "50" > /sys/fs/cgroup/Example/g3/cpu.weight

2. アプリケーションの PID を g1、g2、および g3 サブグループに追加します。

   # echo "33373" > /sys/fs/cgroup/Example/g1/cgroup.procs
   # echo "33374" > /sys/fs/cgroup/Example/g2/cgroup.procs
   # echo "33377" > /sys/fs/cgroup/Example/g3/cgroup.procs

   上記のコマンドの例は、目的のアプリケーションが Example/g*/ 子 cgroup のメンバーになり、それらの cgroup の設定に従って CPU 時間を分散させることを保証します。

   実行中のプロセスを持つサブ cgroups(g1、g2、g3) の重みは、親 cgroup のレベルで合算されます (例)。その後、CPU リソースはそれぞれの重みに基づいて相対的に配分されます。

   その結果、すべてのプロセスが同時に実行されると、カーネルはそれぞれの cgroup の cpu.weight ファイルに基づいて、それぞれのプロセスに比例配分の CPU 時間を割り当てます。

   サブ cgroup	cpu.weight ファイル	CPU 時間の割り当て
   g1	150	~ 50% (150/300)
   g2	100	~ 33% (100/300)
   g3	50	~ 16% (50/300)

   cpu.weight コントローラーファイルの値はパーセンテージではありません。

   1 つのプロセスが実行を停止し、cgroup g2 が実行中のプロセスのない状態になると、計算では cgroup g2 が省略され、cgroups g1 および g3 の重みだけが考慮されます。

   サブ cgroup	cpu.weight ファイル	CPU 時間の割り当て
   g1	150	~ 75% (150/200)
   g3	50	~ 25% (50/200)

   重要

   サブ cgroup に複数の実行中のプロセスがある場合は、それぞれの cgroup に割り当てられる CPU 時間は、その cgroup のメンバープロセスに均等に配分されます。