手順

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

   # yum update kernel

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

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

手順

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

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

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

   # modprobe <MODULE_NAME>

   注記

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

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

   $ lsmod | grep <MODULE_NAME>

   モジュールが正しく読み込まれた場合、このコマンドは関連するカーネルモジュールを表示します。以下に例を示します。

   $ lsmod | grep serio_raw
   serio_raw              16384  0

手順

1. lsmod コマンドを実行して、アンロードするカーネルモジュールを選択します。

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

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

   # modprobe -r <MODULE_NAME>

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

   警告

   実行中のシステムで使用される場合は、カーネルモジュールをアンロードしないでください。これを行うと、システムが不安定になったり、動作しなくなったりすることがあります。

3. 必要に応じて、関連モジュールがアンロードされたことを確認します。

   $ lsmod | grep <MODULE_NAME>

   モジュールが正常にアンロードされた場合、このコマンドは出力を表示しません。

手順

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
   
   Module                  Size  Used by
   fuse                  126976  3
   xt_CHECKSUM            16384  1
   ipt_MASQUERADE         16384  1
   uinput                 20480  1
   xt_conntrack           16384  1
   …​

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

   • もしくは、読み込みを阻止する、アンロードしたカーネルモジュールを特定します。

     すべてのカーネルモジュールは、/lib/modules/<KERNEL_VERSION>/kernel/<subsystem>/ ディレクトリーにあります。

2. 拒否リスト用の設定ファイルを作成します。

   # vim /etc/modprobe.d/blacklist.conf
   
   	# Blacklists <KERNEL_MODULE_1>
   	blacklist <MODULE_NAME_1>
   	install <MODULE_NAME_1> /bin/false
   
   	# Blacklists <KERNEL_MODULE_2>
   	blacklist <MODULE_NAME_2>
   	install <MODULE_NAME_2> /bin/false
   
   	# Blacklists <KERNEL_MODULE_n>
   	blacklist <MODULE_NAME_n>
   	install <MODULE_NAME_n> /bin/false
   	…​

   この例では、vim エディターで編集した blacklist.conf ファイルの内容を示しています。blacklist の行では、システムの起動プロセス中に関連のカーネルモジュールが自動的に読み込まれないように指定します。ただし、blacklist コマンドは、拒否リストに入っていない他のカーネルモジュールの依存関係としてのモジュールの読み込みを阻止することはありません。したがって、install の行では、モジュールのインストールの代わりに、/bin/false が実行されます。

   ハッシュ記号で始まる行は、ファイルがより読みやすいコメントです。

   注記

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

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

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

   上記のコマンドは、新しいバージョンに予期しない問題が発生したときに、バックアップの initramfs イメージを作成します。

   • または、カーネルモジュールを拒否リストに指定するカーネルバージョンに対応する、その他の初期 ramdisk イメージのバックアップコピーを作成します。

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

4. 変更を反映するために新しい初期 ramdisk イメージを生成します。

   # dracut -f -v

   • 現在起動しているものとは異なるカーネルバージョンの初期 ramdisk イメージを構築する場合は、ターゲット initramfs とカーネルバージョンの両方を指定します。

     # dracut -f -v /boot/initramfs-<TARGET_VERSION>.img <CORRESPONDING_TARGET_KERNEL_VERSION>

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

   $ 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 言語で記述した複数のソースファイルで共有する関数宣言とマクロ定義が含まれています。

     次に、init_module() 関数および cleanup_module() 関数に従い、テキストを出力するカーネルログ機能 printk() を起動および終了します。

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

   obj-m := test.o

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

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

   # 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. キーペア生成のパラメーターで設定ファイルを作成します。

   # cat << EOF > configuration_file.config
   [ req ]
   default_bits = 4096
   distinguished_name = req_distinguished_name
   prompt = no
   string_mask = utf8only
   x509_extensions = myexts
   
   [ req_distinguished_name ]
   O = Organization
   CN = Organization signing key
   emailAddress = E-mail address
   
   [ myexts ]
   basicConstraints=critical,CA:FALSE
   keyUsage=digitalSignature
   subjectKeyIdentifier=hash
   authorityKeyIdentifier=keyid
   EOF

2. X.509 公開鍵と秘密鍵のペアを以下の例のように作成します。

   # openssl req -x509 -new -nodes -utf8 -sha256 -days 36500 \
   -batch -config configuration_file.config -outform DER \
   -out my_signing_key_pub.der \
   -keyout my_signing_key.priv

   公開鍵は my_signing_key_pub.der ファイルに書き込まれます。この秘密鍵は my_signing_key.priv ファイルに書き込まれます。

   重要

   RHEL 8 では、鍵ペアの有効期限は重要ではありません。鍵の有効期限はありませんが、カーネルモジュールは署名鍵の有効期間内に署名することがセキュリティー上、推奨されます。ただし、sign-file ユーティリティーは警告を発せず、鍵は有効期限に関係なく使用できます。

3. 必要に応じて、以下の例のように公開鍵の有効期限を確認できます。

   # openssl x509 -inform der -text -noout -in my_signing_key_pub.der
   
   Validity
               Not Before: Feb 14 16:34:37 2019 GMT
               Not After : Feb 11 16:34:37 2029 GMT

4. カーネルモジュールを認証、読み込むすべてのシステムに公開鍵を登録します。

手順

1. 公開鍵を MOK リストに追加するようリクエストします。

   # mokutil --import my_signing_key_pub.der

   この MOK 登録リクエストに関するパスワードの入力と確認が求められます。

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

   この MOK 鍵登録リクエストは shim.efi が発見し、MokManager.efi を起動して UEFI コンソールからの登録が完了できるようになります。

3. MOK の登録を選択し、登録を求められたら、この要求に以前関連付けたパスワードを入力します。

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

手順

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

   # keyctl list %:.platform

2. /lib/modules/$(uname -r)/extra/ ディレクトリーを作成する kernel-modules-extra パッケージをインストールします。

   # yum -y install kernel-modules-extra

3. 任意のカーネルの /extra/ ディレクトリーにカーネルモジュールをコピーします。

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

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

   # depmod -a

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

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

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

   注記

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

4. 必要に応じてカーネルパラメーターを編集します。たとえば、緊急モードでシステムを実行するには、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 パラメーターを削除します。

5. 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. インストールメディアのブートメニューで、トラブルシューティング を選択します。

   

3. トラブルシューティング メニューで Red Hat Enterprise Linux システムのレスキュー オプションを選択します。

   

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. /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. device 引数を指定して grub2-install コマンドを発行します。たとえば、sda がデバイスの場合は、以下のようになります。

   # grub2-install /dev/sda

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

   # reboot

手順

1. grub2-efi および shim ブートローダーファイルを使用して yum reinstall コマンドを実行します。

   # yum reinstall grub2-efi shim

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

   # 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 項目に移動します。

2. kdump が有効になっていない場合は有効にします。

   

3. 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 のメモリーを予約します。オフセットパラメーターが 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 を有効にしてシステムを再起動します。

2. kdump が動作していることを確認します。

   # systemctl is-active kdump
   active

3. Linux カーネルを強制的にクラッシュさせます。

   echo 1 > /proc/sys/kernel/sysrq
   echo c > /proc/sysrq-trigger

   警告

   上記のコマンドによりカーネルがクラッシュし、再起動が必要になります。

   もう一度起動すると、/etc/kdump.conf ファイルで指定した場所 (デフォルトでは /var/crash/) に address-YYYY-MM-DD-HH:MM:SS/vmcore ファイルが作成されます。

   注記

   このアクションで、設定の妥当性が確認されます。また、このアクションを使用して、一般的な作業負荷でクラッシュダンプの完了にかかる時間を記録することもできます。

手順

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

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

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 カーネルを、システムの GRUB (Grand Unified Bootloader) 設定ファイルに追加します。

   以下に例を示します。

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

3. kdump を有効にします。

   # systemctl enable --now kdump.service

手順

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

   # systemctl stop kdump.service

2. 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. Test configuration をクリックします。

   2. Test kdump settings フィールドで、Crash system をクリックします。

      警告

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

手順

1. /etc/kdump.conf ファイルを編集し、final_action パラメーターを追加します。

   final_action <reboot | halt | poweroff>

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"

   重要

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

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

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 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. zswap を永続的に有効にします。

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="zswap.enabled=1"

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

手順

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. 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 のメンバープロセスに均等に配分されます。

検証

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% の配分に対応します。

手順

1. サービスのメモリー使用量を制限するには、以下のように /usr/lib/systemd/system/example.service ファイルを変更します。

   …​
   [Service]
   MemoryMax=1500K
   …​

   上記の設定では、(example.service が含まれる) コントロールグループで実行されるプロセスの最大メモリー消費量に制限があります。

   注記

   測定単位のキロバイト、メガバイト、ギガバイト、またはテラバイトを指定するには、接尾辞 K、M、G、または T を使用します。

2. すべてのユニット設定ファイルを再読み込みします。

   # systemctl daemon-reload

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

   # systemctl restart example.service

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

5. 必要に応じて、変更が反映されたことを確認します。

   # cat /sys/fs/cgroup/memory/system.slice/example.service/memory.limit_in_bytes
   1536000

   この出力例では、メモリー消費量が約 1,500 KB に制限されていることを示しています。

   注記

   memory.limit_in_bytes ファイルは、メモリー制限を 4096 バイトの倍数 (AMD64 および Intel 64 に固有のカーネルページサイズ) として保存します。実際のバイト数は、CPU アーキテクチャーによって異なります。

手順

1. サービスユニットを停止します。

   # systemctl stop <name>.service

2. サービスユニットを無効にします。

   # systemctl disable <name>.service

3. 関連するユニット設定ファイルを削除します。

   # rm /usr/lib/systemd/system/<name>.service

4. すべてのユニット設定ファイルを再度読み込み、変更を有効にします。

   # systemctl daemon-reload

手順

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. systemd-cgtop コマンドを使用して、現在実行中の cgroups の動的アカウントを表示します。

   # 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. 選択したサービスで、CPU 時間割り当てポリシーオプションに割り当てた値を確認します。

   $ systemctl show --property <CPU time allocation policy option> <service name>

2. root として、CPU 時間割り当てポリシーのオプションで必要な値を設定します。

   # systemctl set-property <service name> <CPU time allocation policy option>=<value>

   注記

   cgroup プロパティーは、プロパティーの設定直後に適用されます。したがって、このサービスを再起動する必要はありません。

1. 選択したサービスで、メモリー割り当て設定オプションに割り当てた値を確認します。

   $ systemctl show --property <memory allocation configuration option> <service name>

2. root として、メモリー割り当ての設定オプションで必要な値を設定します。

   # systemctl set-property <service name> <memory allocation configuration option>=<value>