カーネルの管理、監視、および更新

手順

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

   $ yum repoquery <package_name>

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

   $ yum repoquery -l <package_name>

手順

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 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

検証

1. 再起動後、関連するモジュールがロードされていることを確認します。

   $ 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. 起動するカーネルを選択します。
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>

   コマンドを使用して適用された設定の変更は永続的なものではなく、システムを再起動すると消えてしまいます。

検証

1. 新しく設定したカーネルパラメーターの値を確認します。

   # 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 オプションを追加します。

   注記

   カーネルコマンドラインに 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

   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 です。

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

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

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

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

手順

1. Anaconda インストーラーで、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. kdumpctl を使用して kdump サービスのステータスを確認します。

   # 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. multi-user.target の kdump サービスを有効にします。

   # systemctl enable kdump.service

2. 現在のセッションでサービスを起動します。

   # systemctl start kdump.service

3. kdump サービスを停止します。

   # systemctl stop kdump.service

4. kdump サービスを無効にします。

   # systemctl disable kdump.service

手順

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. Web コンソールで、Kernel dump タブを開き、Kernel crash dump スイッチをオンに設定して kdump サービスを起動します。

2. ターミナルで kdump のメモリー使用量を設定します。以下に例を示します。

   $ sudo grubby --update-kernel ALL --args crashkernel=512M

   変更を適用するにはシステムを再起動します。

3. Kernel dump タブで、Crash dump location フィールドの末尾にある Edit をクリックします。

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

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

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

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

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

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

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

       注記

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

5. オプション: View automation script をクリッ自動化スクリプトを表示します。

   生成されたスクリプトを含むウィンドウが開きます。シェルスクリプトと Ansible Playbook 生成オプションのタブを参照できます。

6. オプション: Copy to clipboard をクリックして、スクリプトをコピーします。

   このスクリプトを使用すると、複数のマシンに同じ設定を適用できます。

検証

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

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

   警告

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

手順

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. 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 と入力します。

   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 メカニズムに登録されます。

手順

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

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

検証

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

   # 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. システムを再起動します。

検証

1. カーネルパッチモジュールがアンインストールされていることを確認します。

   # 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
   ...

   PID 6955 を持つ sha1sum サンプルアプリケーションが、大量の 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 ファイルは、コントロールグループ内のすべてのプロセスが 1 つの期間 (cpu.cfs_period_us で定義) 中にまとめて実行できる合計時間をマイクロ秒単位で表します。コントロールグループ内のプロセスが 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

   アプリケーションのプロセスは、アプリケーションのプロセスに CPU 制限を適用する Example コントロールグループで実行されます。

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 上で時間を競合するプロセスが少なくとも 2 つある場合にのみアクティブになります。

検証

1. オプション: 直下の子 cgroups に対して CPU 関連コントローラーが有効になっていることを確認します。

   # 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 時間が、そのメンバープロセス間で均等に分配されます。

検証

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

   # cat /proc/33373/cgroup /proc/33374/cgroup /proc/33377/cgroup
   0::/Example/g1
   0::/Example/g2
   0::/Example/g3

   コマンド出力は、Example/g*/ サブ cgroups で実行される指定されたアプリケーションのプロセスを示しています。

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

   # top
   top - 05:17:18 up 1 day, 18:25,  1 user,  load average: 3.03, 3.03, 3.00
   Tasks:  95 total,   4 running,  91 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 18.1 us, 81.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st
   MiB Mem :   3737.0 total,   3233.7 free,    132.8 used,    370.5 buff/cache
   MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3373.1 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     33373 root      20   0   18720   1748   1460 R  49.5   0.0 415:05.87 sha1sum
     33374 root      20   0   18720   1756   1464 R  32.9   0.0 412:58.33 sha1sum
     33377 root      20   0   18720   1860   1568 R  16.3   0.0 411:03.12 sha1sum
       760 root      20   0  416620  28540  15296 S   0.3   0.7   0:10.23 tuned
         1 root      20   0  186328  14108   9484 S   0.0   0.4   0:02.00 systemd
         2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthread
   ...

   注記

   わかりやすくするために、すべてのプロセスを単一の CPU 上で実行しています。CPU の重みは、複数の CPU で使用される場合にも、同じ原則を適用します。

   PID 33373、PID 33374、および PID 33377 の CPU リソースが、それぞれの子 cgroups に割り当てた 150、100、および 50 の重みに基づいて割り当てられていることに注意してください。重みは、各アプリケーションの CPU 時間の約 50%、33%、および 16% の配分に対応します。