手順

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

   # keyctl list %:.builtin_trusted_keys

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

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

3. モジュールの依存関係の一覧を更新します。

   # depmod -a

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

   # modprobe -v my_module
   # lsmod | grep my_module

   1. 必要に応じて、システムの起動時にモジュールを読み込むには、そのモジュールを /etc/modules-loaded.d/my_module.conf ファイルに追加します。

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

手順

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 行ごとにカーネルパラメーターを含めます。

   <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. root パーミッションで /etc/default/grub ファイルを編集します。

2. 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 が kdump 用に予約されます。

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

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

     crashkernel=128M@16M

     上記の例は、kdump が 16 MB (物理アドレス 0x01000000) から始まる 128 MB のメモリーを予約していることを示しています。オフセットパラメーターが 0 に設定されている場合、または完全に省略されている場合、kdump は自動的に予約メモリーをオフセットします。上記のように、変数メモリー予約を設定する場合にもこの構文を使用します。この場合、オフセットは常に最後に指定されます (例: crashkernel=512M-2G:64M,2G-:128 _M@16 _M)。

3. 以下のコマンドを使用して、GRUB2 設定ファイルを更新します。

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

1. #path /var/crash の行頭にあるハッシュ記号 ("#") を削除します。

2. 値を対象のディレクトリーパスに置き換えます。以下に例を示します。

   path /usr/local/cores

   重要

   Red Hat Enterprise Linux 8 では、path ディレクティブを使用して kdump ターゲットとして定義したディレクトリーが kdump systemd サービスの開始時に存在していなければなりません。これが存在しない場合は、サービスが失敗します。この動作は、サービスの起動時にそのディレクトリーが存在しない場合に自動的に作成されていた Red hat Enterprise Linux の以前のリリースのものとは異なります。

1. 必要に応じて #ext4 の行頭にあるハッシュ記号 ("#") を削除します。

   • デバイス名 (#ext4 /dev/vg/lv_kdump 行）
   • ファイルシステムラベル (#0ext4 LABEL=/boot 行)
   • UUID (#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937 の行)

2. ファイルシステムタイプと、デバイス名、ラベル、UUID を希望の値に変更します。以下に例を示します。

   ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937

   重要

   LABEL= UUID= を使用してストレージデバイスを指定することが推奨されます。/dev/sda3 などのディスクデバイス名は、再起動しても一貫性は保証されません。

   重要

   IBM Z ハードウェア上の Direct Access Storage Device (DASD) にダンプする場合、処理を行う前に /etc/dasd.conf でダンプデバイスが正しく指定されている必要があります。

1. #raw /dev/vg/lv_kdump の行頭にあるハッシュ記号 ("#") を削除します。

2. 値を対象のデバイス名に置き換えます。以下に例を示します。

   raw /dev/sdb1

1. #nfs my.server.com:/export/tmp の行頭にあるハッシュ記号 ("#") を削除します。

2. 値を、正しいホスト名およびディレクトリーパスに置き換えます。以下に例を示します。

   nfs penguin.example.com:/export/cores

1. #ssh user@my.server.com の行頭にあるハッシュ記号 ("#") を削除します。
2. 値を正しいユーザー名およびホスト名に置き換えます。

3. SSH キーを設定に含めます。

   • #sshkey /root/.ssh/kdump_id_rsa の行頭にあるハッシュ記号 ("#") を削除します。

   • 値を、ダンプ先のサーバー上で正しいキーの場所に変更します。以下に例を示します。

     ssh john@penguin.example.com
     sshkey /root/.ssh/mykey

手順

1. root で、/etc/kdump.conf 設定ファイルを編集し、#core_collector makedumpfile -l --message-level 1 -d 31 の行頭にあるハッシュ記号 ("#") を削除します。

2. -c パラメーターを追加します。以下に例を示します。

   core_collector makedumpfile -c

   上記のコマンドを使用すると、ダンプファイルの圧縮が有効になります。

3. -d 値パラメーターを追加します。以下に例を示します。

   core_collector makedumpfile -d 17 -c

   上記のコマンドは、ダンプからゼロページと空きページの両方を削除します。この 値はビットマスクを表します。ここでは、各ビットが特定のタイプのメモリーページに関連付けられ、そのタイプのページが収集されるかどうかを判断します。各ビットの説明は、「対応している kdump のフィルターレベル」を参照してください。

手順

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

2. 「対応しているデフォルトの障害応答」の説明どおり、値を希望のアクションに置き換えます。以下に例を示します。

   failure_action poweroff

手順

1. kdump サービスを有効にするには、以下のコマンドを実行します。

   # systemctl enable kdump.service

   これにより、multi-user.target のサービスが有効になります。

2. 現行セッションでサービスを開始するには、以下のコマンドを使用します。

   # systemctl start kdump.service

3. kdump サービスを停止するには、以下のコマンドを実行します。

   # systemctl stop kdump.service

4. kdump サービスを無効にするには、以下のコマンドを実行します。

   # systemctl disable kdump.service

手順

1. Kernel Dump タブを開き、kdump サービスを開始します。
2. コマンドラインで kdump のメモリー使用量を設定します。

3. クラッシュダンプの場所 オプションの横にあるリンクをクリックします。

   

4. ドロップダウンメニューから ローカルファイルシステム を選択し、ダンプを保存するディレクトリーを指定します。

   

   • または、ドロップダウンから SSH 経由のリモート オプションを選択し、SSH プロトコルを使用して、vmcore をリモートマシンに送信します。

     Server、ssh key、Directory の各フィールドに、リモートマシンのアドレス、ssh キーの場所、およびターゲットディレクトリーを入力します。

   • または、ドロップダウンから NFS 経由のリモート オプションを選択し、マウント フィールドに入力して、NFS プロトコルを使用して vmcore をリモートマシンに送信することもできます。

     注記

     圧縮 チェックボックスにチェックマークを入れ、vmcore ファイルのサイズを小さくします。

5. カーネルをクラッシュして、設定をテストします。

   
   警告

   この手順では、カーネルの実行を中断し、システムクラッシュやデータの損失が発生します。

手順

1. 第 7 章の kdump のインストールと設定で説明されているように、kdump をインストールして設定します。

2. /etc/default/grub ファイルの GRUB_CMDLINE_LINUX の行に fadump=on を追加します。

   GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=auto
   rd.lvm.lv=rhel/root rhgb quiet fadump=on"

3. (この操作は必須ではありません) 予約ブートメモリーサイズに、デフォルト値を使わずに具体的な値を指定する場合は、/etc/default/grub の GRUB_CMDLINE_LINUX に crashkernel=xxM を追加します。xx は必要なメモリーサイズ (メガバイト単位) に指定してください。

   GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=xxM rd.lvm.lv=rhel/root rhgb quiet fadump=on"

   重要

   Red Hat は、すべての起動オプションを実行する前に、起動オプションをすべてテストすることを推奨します。クラッシュカーネルから起動時に Out of Memory (OOM) エラーが発生する場合は、クラッシュカーネルが正常に起動できるまで 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

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

手順

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> のバージョンを使用します。

     例7.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 を終了するには、crash または q を使用します。

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

   crash> exit
   ~]#

手順

1. Kernel Oops Analyzer リンクに従って、ツールにアクセスします。

2. 参照を押して、oops メッセージを参照します。

   
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

5. 必要に応じて、rd.earlykdump が正常に追加され、early kdump 機能が有効になっていることを確認します。

   # cat /proc/cmdline
   BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-187.el8.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 rd.earlykdump
   
   # journalctl -x | grep early-kdump
   Mar 20 15:44:41 redhat dracut-cmdline[304]: early-kdump is enabled.
   Mar 20 15:44:42 redhat dracut-cmdline[304]: kexec: loaded early-kdump kernel

手順

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 のインストールを行うと、指定のカーネルの将来のすべてのライブパッチにシステムがサブスクライブされます。

4. 必要に応じて、カーネルがパッチを当てていることを確認します。

   # 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)
   …​

   この出力は、カーネルパッチモジュールがカーネルに読み込まれていることを示しています。つまり、カーネルは現在、kpatch-patch-4_18_0-94-1-1.el8.x86_64.rpm パッケージの最新の修正でパッチが当てられています。

手順

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 プログラムの出力例は、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 リソースへのアクセスが再割り当てされる頻度について、マイクロ秒単位の期間 (ここでは「us」と表示されますが µs) を表します。上限は 1 秒で、下限は 1000 マイクロ秒です。

   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
   
   or
   
   # echo "6955" > /sys/fs/cgroup/cpu/Example/tasks

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

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

   # 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 制限が適用されることを示しています。

8. スロットルアプリケーションの現在の 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. システム起動時に cgroups-v1 が自動的にマウントされないようにします。

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="cgroup_no_v1=all"

   コマンドは、カーネルコマンドラインパラメーターを現在のブートエントリーに追加します。cgroup_no_v1=all パラメーターは、cgroups-v1 が自動的にマウントされないようにします。

   または、systemd.unified_cgroup_hierarchy=1 カーネルコマンドラインパラメーターを使用して、システム起動時にデフォルトで cgroups-v2 をマウントします。

   注記

   RHEL 8 は、cgroups-v1 と cgroups-v2 の両方に対応します。ただし、cgroups-v1 は、ブートプロセス時にデフォルトで有効になっており、マウントされます。

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

3. 必要に応じて、cgroups-v1 機能が無効になっていることを確認します。

   # mount -l | grep cgroup
   tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
   cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)

   cgroups-v1 が正常に無効にされている場合は、出力に systemd に属するものを除き、「type cgroup」の参照は表示されません。

4. cgroups-v2 をファイルシステムの任意の場所にマウントします。

   # mount -t cgroup2 none <MOUNT_POINT>

5. 必要に応じて、cgroups-v2 機能がマウントされていることを確認します。

   # mount -l | grep cgroup2
   none on /cgroups-v2 type cgroup2 (rw,relatime,seclabel)

   この出力例は、cgroups-v2 が /cgroups-v2/ ディレクトリーにマウントされていることを示しています。

6. 必要に応じて、/cgroups-v2/ ディレクトリーの内容を確認します。

   # ll /cgroups-v2/
   -r—​r—​r--. 1 root root 0 Mar 13 11:57 cgroup.controllers
   -rw-r—​r--. 1 root root 0 Mar 13 11:57 cgroup.max.depth
   -rw-r—​r--. 1 root root 0 Mar 13 11:57 cgroup.max.descendants
   -rw-r—​r--. 1 root root 0 Mar 13 11:57 cgroup.procs
   -r—​r—​r--. 1 root root 0 Mar 13 11:57 cgroup.stat
   -rw-r—​r--. 1 root root 0 Mar 13 11:58 cgroup.subtree_control
   -rw-r—​r--. 1 root root 0 Mar 13 11:57 cgroup.threads
   -rw-r—​r--. 1 root root 0 Mar 13 11:57 cpu.pressure
   -r—​r—​r--. 1 root root 0 Mar 13 11:57 cpuset.cpus.effective
   -r—​r—​r--. 1 root root 0 Mar 13 11:57 cpuset.mems.effective
   -rw-r—​r--. 1 root root 0 Mar 13 11:57 io.pressure
   -rw-r—​r--. 1 root root 0 Mar 13 11:57 memory.pressure

   /cgroups-v2/ ディレクトリーには、root コントロールグループとも呼ばれるインターフェースファイル (cgroup で始まる) と、cpuset.cpus.effective などのコントローラー固有のファイルが含まれます。

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

   # top
   top - 15:39:52 up  3:45,  1 user,  load average: 0.79, 0.20, 0.07
   Tasks: 265 total,   3 running, 262 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 74.3 us,  6.1 sy,  0.0 ni, 19.4 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
   MiB Mem :   1826.8 total,    243.8 free,   1102.1 used,    480.9 buff/cache
   MiB Swap:   1536.0 total,   1526.2 free,      9.8 used.    565.6 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    5473 root      20   0  228440   1740   1456 R  99.7   0.1   0:12.11 sha1sum
    5439 root      20   0  222616   3420   3052 R  60.5   0.2   0:27.08 cpu_load_generator
    2170 jdoe      20   0 3600716 209960  67548 S   0.3  11.2   1:18.50 gnome-shell
    3051 root      20   0  274424   3976   3092 R   0.3   0.2   1:01.25 top
       1 root      20   0  245448  10256   5448 S   0.0   0.5   0:02.52 systemd
   ...

   top プログラムの出力例は、PID 5473 および 5439 (具体例のアプリケーション sha1sum および cpu_load_generator) が CPU などの多くのリソースを消費することを示しています。いずれも cgroups-v2 機能の管理に使用するアプリケーションの例です。

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

   # echo "+cpu" > /cgroups-v2/cgroup.subtree_control
   # echo "+cpuset" > /cgroups-v2/cgroup.subtree_control

   上記のコマンドは、root コントロールグループ /cgroups-v2/ の即時サブコントロールグループに cpu および cpuset コントローラーを有効にします。

9. 以前に作成した /cgroups-v2/ ディレクトリーにサブディレクトリーを作成します。

   # mkdir /cgroups-v2/Example/

   /cgroups-v2/Example/ ディレクトリーはサブコントロールグループを表します。このグループでは、特定のプロセスを配置でき、各種の CPU 制限をプロセスに適用できます。また、前の手順では、このサブ制御グループの cpu コントローラーおよび cpuset コントローラーを有効にしていました。

   /cgroups-v2/Example/ の作成時に、cgroups-v2 インターフェースファイルと cpu および cpuset のコントローラー固有のファイルがディレクトリーに作成されます。

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

    # ll /cgroups-v2/Example/
    -r—​r—​r--. 1 root root 0 Mar 13 14:48 cgroup.controllers
    -r—​r—​r--. 1 root root 0 Mar 13 14:48 cgroup.events
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.freeze
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.max.depth
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.max.descendants
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.procs
    -r—​r—​r--. 1 root root 0 Mar 13 14:48 cgroup.stat
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.subtree_control
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.threads
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.type
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cpu.max
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cpu.pressure
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cpuset.cpus
    -r—​r—​r--. 1 root root 0 Mar 13 14:48 cpuset.cpus.effective
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cpuset.cpus.partition
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cpuset.mems
    -r—​r—​r--. 1 root root 0 Mar 13 14:48 cpuset.mems.effective
    -r—​r—​r--. 1 root root 0 Mar 13 14:48 cpu.stat
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cpu.weight
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 cpu.weight.nice
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 io.pressure
    -rw-r—​r--. 1 root root 0 Mar 13 14:48 memory.pressure

    出力例には、cpuset.cpus や cpu.max などのファイルが表示されます。ファイルは、/cgroups-v2/cgroup.subtree_control ファイルを使用して、ルート (/cgroups-v2/) ダイレクト子コントロールグループに対して有効にした cpuset コントローラーおよび cpu コントローラーに固有のものです。また、cgroup.procs、cgroup.controllers などの一般的な cgroup コントロールインターフェースファイルは、有効なコントローラーに関係なく、すべてのコントロールグループに共通します。

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

11. 同じ CPU 上の CPU 時間について、制限するプロセスを確認します。

    # echo "1" > /cgroups-v2/Example/cpuset.cpus

    上記のコマンドは、Example サブコントロールグループに置かれたプロセスを、同じ CPU で保護します。この設定は、cpu コントローラーをアクティベートするのに重要です。

    重要

    cpu コントローラーは、関連するサブコントロールグループに 2 つ以上のプロセスがある場合にのみアクティベートされます。これは、1 つの CPU でしばらく有効になります。

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

    # echo "200000 1000000" > /cgroups-v2/Example/cpu.max

    最初の値は、サブコントロールグループのすべてのプロセスが一定期間 (次の値で指定) に実行できる、許可される時間クォータ (マイクロ秒単位) です。シングルピリオドでは、コントロールグループのプロセスがこのクォータで指定されたすべての時間を完全に使い切ると、残りの期間はスロットリングされ、次の期間まで実行できなくなります。

    コマンド例は、Example サブコントロールグループのすべてのプロセスが 1 秒あたり 0.2 秒のみ CPU で実行可能になるように CPU 時間制限を設定します。

13. 必要に応じて、制限を確認します。

    # cat /cgroups-v2/Example/cpu.max
    200000 1000000

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

    # echo "5473" > /cgroups-v2/Example/cgroup.procs
    # echo "5439" > /cgroups-v2/Example/cgroup.procs

    上記のコマンド例は、アプリケーションが Example サブコントロールグループのメンバーであることを確認するため、Example サブコントロールグループに設定された CPU 制限を超えないようにします。

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

    # cat /proc/5473/cgroup /proc/5439/cgroup
    1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
    0::/Example
    1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
    0::/Example

    上記の出力例は、必要なアプリケーションのプロセスが Example サブコントロールグループで実行されることを示しています。

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

    # top
    top - 15:56:27 up  4:02,  1 user,  load average: 0.03, 0.41, 0.55
    Tasks: 265 total,   4 running, 261 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  9.6 us,  0.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
    MiB Mem :   1826.8 total,    243.4 free,   1102.1 used,    481.3 buff/cache
    MiB Swap:   1536.0 total,   1526.2 free,      9.8 used.    565.5 avail Mem
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     5439 root      20   0  222616   3420   3052 R  10.0   0.2   6:15.83 cpu_load_generator
     5473 root      20   0  228440   1740   1456 R  10.0   0.1   9:20.65 sha1sum
     2753 jdoe      20   0  743928  35328  20608 S   0.7   1.9   0:20.36 gnome-terminal-
     2170 jdoe      20   0 3599688 208820  67552 S   0.3  11.2   1:33.06 gnome-shell
     5934 root      20   0  274428   5064   4176 R   0.3   0.3   0:00.04 top
     ...

    PID 5439 および PID 5473 の CPU 消費量が 10% に減少していることに注意してください。Example サブコントロールグループは、そのプロセスを CPU 時間の 20% に制限します。コントロールグループに 2 つのプロセスがあるため、各プロセスは CPU 時間の 10% を使用できます。

手順

1. プロセスが対話するリソースコントローラーを表示するには、# cat proc/<PID>/cgroup コマンドを実行します。

   # cat /proc/11269/cgroup
   12:freezer:/
   11:cpuset:/
   10:devices:/system.slice
   9:memory:/system.slice/example.service
   8:pids:/system.slice/example.service
   7:hugetlb:/
   6:rdma:/
   5:perf_event:/
   4:cpu,cpuacct:/
   3:net_cls,net_prio:/
   2:blkio:/
   1:name=systemd:/system.slice/example.service

   この出力例は、対象のプロセスに関連しています。この場合、これは、example.service ユニットに属する PID 11269 で識別されるプロセスです。systemd ユニットファイルの仕様で定義される適切なコントロールグループにプロセスが置かれているかどうかを判断できます。

   注記

   デフォルトでは、デフォルトのリソースコントローラーがすべて自動的にマウントされるため、リソースコントローラーの一覧にある項目とその順序は、systemd が起動するすべてのユニットで同じになります。

手順

1. 現在実行中の cgroups の動的アカウントを表示するには、# systemd-cgtop コマンドを実行します。

   # systemd-cgtop
   Control Group                            Tasks   %CPU   Memory  Input/s Output/s
   /                                          607   29.8     1.5G        -        -
   /system.slice                              125      -   428.7M        -        -
   /system.slice/ModemManager.service           3      -     8.6M        -        -
   /system.slice/NetworkManager.service         3      -    12.8M        -        -
   /system.slice/accounts-daemon.service        3      -     1.8M        -        -
   /system.slice/boot.mount                     -      -    48.0K        -        -
   /system.slice/chronyd.service                1      -     2.0M        -        -
   /system.slice/cockpit.socket                 -      -     1.3M        -        -
   /system.slice/colord.service                 3      -     3.5M        -        -
   /system.slice/crond.service                  1      -     1.8M        -        -
   /system.slice/cups.service                   1      -     3.1M        -        -
   /system.slice/dev-hugepages.mount            -      -   244.0K        -        -
   /system.slice/dev-mapper-rhel\x2dswap.swap   -      -   912.0K        -        -
   /system.slice/dev-mqueue.mount               -      -    48.0K        -        -
   /system.slice/example.service                2      -     2.0M        -        -
   /system.slice/firewalld.service              2      -    28.8M        -        -
   ...

   この出力例では、現在実行中の cgroups が、リソースの使用状況 (CPU、メモリー、ディスク I/O 負荷) の順に表示されています。デフォルトでは 1 秒ごとに一覧が更新されます。したがって、各コントロールグループの実際のリソース使用状況に対する動的な洞察を提供します。

手順

1. TPM を使用して信頼できる鍵を作成するには、次のコマンドを実行します。

   # keyctl add trusted <name> "new <key_length> [options]" <key_ring>

   • 構文に基づいて、以下のようにサンプルコマンドを作成します。

     # keyctl add trusted kmk "new 32" @u
     642500861

     このコマンドは、kmk という名前の信頼できる鍵を 32 バイト (256 ビット) の長さで作成し、ユーザーキーリング (@u) に置きます。鍵の長さは 32 から 128 バイト (256 から 1024 ビット) です。

2. カーネルキーリングの現在の構造を一覧表示するには、以下を実行します。

   # keyctl show
   Session Keyring
          -3 --alswrv    500   500  keyring: ses 97833714 --alswrv 500 -1 \ keyring: uid.1000 642500861 --alswrv 500 500 \ trusted: kmk

3. ユーザー空間のブロブに鍵をエクスポートするには、次のコマンドを実行します。

   # keyctl pipe 642500861 > kmk.blob

   このコマンドは、pipe サブコマンドと kmk のシリアル番号を使用します。

4. ユーザー空間のブロブから信頼できる鍵を読み込むには、ブログを引数として add サブコマンドを使用します。

   # keyctl add trusted kmk "load `cat kmk.blob`" @u
   268728824

5. TPM で保護された信頼できる鍵に基づいて、安全な暗号化された鍵を作成します。

   # keyctl add encrypted <name> "new [format] <key_type>:<master_key_name> <keylength>" <key_ring>

   • 構文に基づいて、すでに作成された信頼できる鍵を使用して暗号化された鍵を生成します。

     # keyctl add encrypted encr-key "new trusted:kmk 32" @u
     159771175

     このコマンドは、前の手順で生成した TPM で保護された信頼できる鍵 (kmk) を、暗号化された鍵を生成する マスターキー として使用します。

手順

1. 無作為に数列を使用してユーザーキーを生成します。

   # keyctl add user kmk-user “dd if=/dev/urandom bs=1 count=32 2>/dev/null” @u
   427069434

   このコマンドは、マスターキー として動作する kmk-user という名前のユーザーキーを生成し、実際の暗号化された鍵を保護するために使用されます。

2. 直前の手順のマスターキーを使用して、暗号化されたキーを生成します。

   # keyctl add encrypted encr-key "new user:kmk-user 32" @u
   1012412758

3. 必要に応じて、指定したユーザーキーリングにあるすべての鍵を一覧表示します。

   # keyctl list @u
   2 keys in keyring:
   427069434: --alswrv  1000  1000 user: kmk-user
   1012412758: --alswrv  1000  1000 encrypted: encr-key