手順

1. vim エディターで /etc/default/grub ファイルを開きます。

   # vim /etc/default/grub
   GRUB_TIMEOUT=5
   GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
   GRUB_DEFAULT=saved
   GRUB_DISABLE_SUBMENU=true
   GRUB_TERMINAL_OUTPUT="console"
   GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet"
   GRUB_DISABLE_RECOVERY="true"
   GRUB_ENABLE_BLSCFG=true

2. GRUB_CMDLINE_LINUX の行でパラメーターの追加、編集、または削除を行います。

3. GRUB2 設定ファイルを更新します。

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

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

手順

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

   default 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. 関連する baseos リポジトリーおよび appstream リポジトリーを有効にします。

   # subscription-manager repos --enable baseos repository

   # subscription-manager repos --enable appstream repository

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. 必要に応じて、カーネルバージョンを確認します。

   # 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. メモリーリソースコントローラーディレクトリーにサブディレクトリーを作成します。

   # mkdir /sys/fs/cgroup/memory/example/

   上記のディレクトリーは、特定のプロセスを配置でき、特定のメモリー制限をプロセスに適用できるコントロールグループです。

2. 必要に応じて、新しく作成したコントロールグループを調べます。

   # ll /sys/fs/cgroup/memory/example/
   -rw-r—​r--. 1 root root 0 Apr 25 16:34 cgroup.clone_children
   --w—​w—​w-. 1 root root 0 Apr 25 16:34 cgroup.event_control
   -rw-r—​r--. 1 root root 0 Apr 25 16:42 cgroup.procs
   …​

   このサンプル出力は、サンプルコントロールグループが親リソースコントローラーから継承したファイルを示しています。デフォルトでは、新しく作成されたコントロールグループは、システムメモリー全体へのアクセスを制限なしで継承します。

3. コントロールグループのメモリー制限を設定します。

   # echo 700000 > /sys/fs/cgroup/memory/example/memory.limit_in_bytes

   このサンプルコマンドでは、メモリー制限を 700 キロバイトに設定します。

4. この制限を確認します。

   # cat /sys/fs/cgroup/memory/example/memory.limit_in_bytes
   696320

   この出力例では、メモリーの制限値を 4096 バイトの倍数 (カーネルページサイズ) で表示します。

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

   # echo 23453 > /sys/fs/cgroup/memory/example/cgroup.procs

   このサンプルコマンドは、目的のアプリケーションが、コントロールグループで設定したメモリー制限を超えないようにします。PID はシステム内の既存プロセスから取得されます。ここでの PID 23453 は架空の ID です。

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

   # ps -o cgroup 23453
   CGROUP
   11:memory:/example,5:devices:/system.slice/example.service,4:pids:/system.slice/example.service,1:name=systemd:/system.slice/example.service

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