Red Hat Training

A Red Hat training course is available for RHEL 8

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

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 8 上で Linux カーネルを管理するためのガイド

概要

本ドキュメントでは、Linux カーネルレベルでワークステーションを設定するために必要な情報をユーザーおよび管理者向けに説明します。このような調整により、パフォーマンスの強化、トラブルシューティングやシステムの最適化が容易になります。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック (英語のみ)

ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。

  • 特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

    1. Bugzilla の Web サイトにアクセスします。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 Linux カーネル RPM

以下のセクションでは、Red Hat が提供および管理する Linux カーネル RPM パッケージを説明します。

1.1. RPM とは

RPM パッケージは、他のファイルとそのメタデータ (システムが必要とするファイルに関する情報) を含むファイルです。

特に、RPM パッケージは cpio アーカイブで構成されています。

cpio アーカイブには以下が含まれます。

  • ファイル
  • RPM ヘッダー (パッケージのメタデータ)

    rpm パッケージマネージャーはこのメタデータを使用して依存関係、ファイルのインストール先、およびその他の情報を決定します。

RPM パッケージの種類

RPM パッケージには 2 つの種類があります。いずれも、同じファイル形式とツールを使用しますが、コンテンツが異なるため、目的が異なります。

  • ソース RPM (SRPM)

    SRPM には、ソースコードと SPEC ファイルが含まれます。これには、ソースコードをバイナリー RPM にビルドする方法が書かれています。必要に応じて、ソースコードへのパッチも含まれます。

  • バイナリー RPM

    バイナリー RPM には、ソースおよびパッチから構築されたバイナリーが含まれます。

1.2. Linux カーネル RPM パッケージの概要

カーネル RPM は、ファイルを含まないメタパッケージで、以下の必須サブパッケージが正しくインストールされるようにします。

  • kernel-core - コア機能を確保するために、カーネルのバイナリーイメージ、システムを起動するためのすべての initramfs 関連オブジェクト、および最小限のカーネルモジュールが含まれます。このサブパッケージ単体は、仮想環境およびクラウド環境で使用して、Red Hat Enterprise Linux 8 カーネルのブート時間を短縮し、ディスクサイズを抑えます。
  • kernel-modules - kernel-core にない残りのカーネルモジュールが含まれます。

上記の kernel サブパッケージをいくつか用意することで、特に仮想環境やクラウド環境でのシステム管理者へのメンテナンス面を低減させることを目指します。

任意のカーネルパッケージは、以下の例のようになります。

  • kernel-modules-extra - まれなハードウェア用のカーネルモジュールと、読み込みがデフォルトで無効になっているモジュールが含まれます。
  • kernel-debug — カーネル診断ができるように複数のデバッグオプションが有効になっているカーネルが含まれます。 デバッグオプションが有効になっているとパフォーマンスが低下します。
  • kernel-tools — Linux カーネル操作のツールとサポートドキュメントが含まれています。
  • kernel-develkernel パッケージに対して、モジュールを構築するのに十分なカーネルヘッダーと makefiles を含んでいます。
  • kernel-abi-whitelists- Red Hat Enterprise Linux カーネル ABI に関連する情報が含まれています。これには、外部の Linux カーネルモジュールが必要とするカーネルシンボルのリストと、実施を支援するyumプラグインが含まれています。
  • kernel-headers — Linux カーネルと、ユーザー空間ライブラリーおよびプログラムとの間のインターフェースを指定する C ヘッダーファイルが含まれます。ヘッダーファイルは、ほとんどの標準プログラムを構築するのに必要な構造と定数を定義します。

1.3. カーネルパッケージの内容の表示

次の手順では、rpm コマンドを使用してインストールを行わずに、カーネルパッケージおよびそのサブパッケージのコンテンツを表示する方法を説明します。

前提条件

  • 使用している CPU アーキテクチャー用の kernelkernel-corekernel-moduleskernel-modules-extra RPM パッケージを取得していること

手順

  • kernel 用のモジュールを一覧表示します。

    $ rpm -qlp <kernel_rpm>
    (contains no files)
    …​
  • kernel-core のモジュールを一覧表示します。

    $ rpm -qlp <kernel-core_rpm>
    …​
    /lib/modules/4.18.0-80.el8.x86_64/kernel/fs/udf/udf.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/kernel/fs/xfs
    /lib/modules/4.18.0-80.el8.x86_64/kernel/fs/xfs/xfs.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/kernel/kernel
    /lib/modules/4.18.0-80.el8.x86_64/kernel/kernel/trace
    /lib/modules/4.18.0-80.el8.x86_64/kernel/kernel/trace/ring_buffer_benchmark.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/kernel/lib
    /lib/modules/4.18.0-80.el8.x86_64/kernel/lib/cordic.ko.xz
    …​
  • kernel-modules のモジュールを一覧表示します。

    $ rpm -qlp <kernel-modules_rpm>
    …​
    /lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/mlx4/mlx4_ib.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/mlx5/mlx5_ib.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/qedr/qedr.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/usnic/usnic_verbs.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/vmw_pvrdma/vmw_pvrdma.ko.xz
    …​
  • kernel-modules-extra のモジュールを一覧表示します。

    $ rpm -qlp <kernel-modules-extra_rpm>
    …​
    /lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_cbq.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_choke.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_drr.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_dsmark.ko.xz
    /lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_gred.ko.xz
    …​

関連情報

第2章 yum を使用したカーネルの更新

以下のセクションでは、Red Hat (Red Hat kernel) が提供および管理する Linux カーネルと、Red Hat カーネルの更新を維持する方法を説明します。結果として、このオペレーティングシステムには、最新のバグ修正、パフォーマンス強化、パッチがすべて適用され、新しいハードウェアとの互換性が確保されます。

2.1. カーネルの概要

カーネルは Linux オペレーティングシステムのコア部分で、システムリソースを管理し、ハードウェアアプリケーションおよびソフトウェアアプリケーション間のインターフェースを確立します。Red Hat カーネルは、アップストリームの Linux メインラインカーネルをベースにしたカスタムカーネルです。Red Hat のエンジニアは、安定性と、最新のテクノロジーおよびハードウェアとの互換性に重点を置き、さらなる開発と強化を行っています。

Red Hat が新しいカーネルバージョンをリリースする前に、カーネルは厳格な品質保証テストをクリアしなければなりません。

Red Hat カーネルは RPM 形式でパッケージ化されるため、yum パッケージマネージャーによるアップグレードと検証が容易になります。

警告

Red Hat によってコンパイルされていないカーネルは、Red Hat ではサポートされていません

2.2. yum とは

このセクションでは、yum パッケージマネージャーの説明を行います。

関連情報

2.3. カーネルの更新

以下の手順では、yum パッケージマネージャーを使用してカーネルを更新する方法を説明します。

手順

  1. カーネルを更新するには、以下を実行します。

    # yum update kernel

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

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

Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 にアップグレードする場合は、『RHEL 7 から RHEL 8 へのアップグレード』の関連セクションを参照してください。

2.4. カーネルのインストール

以下の手順では、yum パッケージマネージャーを使用して新しいカーネルをインストールする方法を説明します。

手順

  • 特定のカーネルバージョンをインストールするには、以下を使用します。

    # yum install kernel-{version}

第3章 カーネルモジュールの管理

以下のセクションでは、カーネルモジュールの概要、カーネルモジュールの表示方法、カーネルモジュールでの基本的な管理タスクの実行方法を説明します。

3.1. モジュールの紹介

Red Hat Enterprise Linux カーネルは、システムを再起動しなくても、カーネルモジュールと呼ばれる追加機能で拡張できます。Red Hat Enterprise Linux 8 では、カーネルモジュールは追加のカーネルコードで、圧縮された <KERNEL_MODULE_NAME>.ko.xz オブジェクトファイルに組み込まれています。

カーネルモジュールにより有効になっている最も一般的な機能は、以下のとおりです。

  • 新しいハードウェアへのサポートを強化するデバイスドライバー
  • GFS2NFSなどのファイルシステムのサポート
  • システムコール

最新のシステムでは、必要に応じて自動的にカーネルモジュールが読み込まれます。ただし、場合によっては、モジュールを手動でロードまたはアンロードする必要があります。

モジュールは、カーネル自体と同様に、必要に応じてその動作をカスタマイズするパラメーターを受けることができます。

ツールでは、現在実行しているモジュール、カーネルに読み込みできるモジュール、モジュールが受け入れるパラメーターを調べることができます。このツールは、実行中のカーネルに、カーネルモジュールのロードおよびアンロードを行うためのメカニズムを提供します。

3.2. ブートローダー仕様の概要

BootLoader Specification (BLS) は、ブートローダー設定ファイルを操作せずに、ドロップインディレクトリーの各起動オプションのブートローダー設定を管理するスキームとファイル形式を定義します。前述の方法とは異なり、各ブートエントリーはドロップインディレクトリーの個別の設定ファイルで表されるようになりました。ドロップインディレクトリーは、設定ファイルを編集または再生成せずに設定を拡張します。BLS は、ブートメニューエントリーのこの概念を拡張します。

BLS を使用すると、ディレクトリー内の個々のブートエントリーファイルを追加、削除、または編集して、ブートローダーメニューのオプションを管理できます。これにより、カーネルのインストールプロセスがはるかに簡素化され、異なるアーキテクチャーの間でこのプロセスの一貫性を保つことができます。

grubby ツールは、BLS に関するシンラッパースクリプトで、同じ grubby 引数およびオプションをサポートします。dracut を実行して、初期 ramdisk イメージを作成します。この設定では、コアブートローダーの設定ファイルは静的で、カーネルのインストール後に変更されません。

Red Hat Enterprise Linux 8 では、すべてのアーキテクチャーで同じブートローダーを使用していないため、Red Hat Enterprise Linux 8 には特に関係があります。GRUB2 は、64 ビット ARM などのほとんどのアーキテクチャーに使用されますが、Open Power Abstraction Layer (OPAL) を使用する IBM Power Systems のリトルエンディアンバリアントは Petitboot を使用し、IBM Z アーキテクチャーは zipl を使用します。

関連情報

3.3. カーネルモジュールの依存関係

特定のカーネルモジュールは、複数の他のカーネルモジュールに依存する場合があります。/lib/modules/<KERNEL_VERSION>/modules.dep ファイルには、各カーネルバージョンに対するカーネルモジュールの依存関係の完全な一覧が含まれます。

依存関係ファイルは、kmod パッケージの一部である depmod プログラムにより生成されます。kmod によるユーティリティーの多くは、操作を実行する際にモジュールの依存関係を考慮に入れるため、手動 で依存関係を追跡する必要はほとんどありません。

警告

カーネルモジュールのコードは、制限のないモードのカーネルスペースで実行されます。そのため、読み込むモジュールに注意してください。

関連情報

  • modules.dep(5) の man ページ
  • depmod(8) の man ページ

3.4. 現在読み込み済みカーネルモジュールの一覧表示

以下の手順では、現在読み込まれているカーネルモジュールを確認する方法を説明します。

前提条件

  • kmod パッケージがインストールされている。

手順

  • 現在読み込み済みのカーネルモジュールの一覧を表示するには、以下のコマンドを実行します。

    $ lsmod
    
    Module                  Size  Used by
    fuse                  126976  3
    uinput                 20480  1
    xt_CHECKSUM            16384  1
    ipt_MASQUERADE         16384  1
    xt_conntrack           16384  1
    ipt_REJECT             16384  1
    nft_counter            16384  16
    nf_nat_tftp            16384  0
    nf_conntrack_tftp      16384  1 nf_nat_tftp
    tun                    49152  1
    bridge                192512  0
    stp                    16384  1 bridge
    llc                    16384  2 bridge,stp
    nf_tables_set          32768  5
    nft_fib_inet           16384  1
    …​

    上記の例:

    • 最初の列は、現在読み込まれているモジュールの名前を示します。
    • 次のコラムは、モジュールごとのメモリー容量をキロバイト単位で表示します。
    • 最後のコラムは、数字と、オプションで特定のモジュールに依存するモジュール名を表示します。

関連情報

  • /usr/share/doc/kmod/README ファイル
  • lsmod(8) の man ページ

3.5. インストール済みカーネルの一覧表示

以下の手順では、コマンドラインツール grubby を使用して、GRUB2 ブートエントリーの一覧を表示する方法を説明します。

手順

カーネルの起動エントリーを一覧表示するには、以下を行います。

  • カーネルの起動エントリーを一覧表示するには、次のコマンドを実行します。

    # grubby --info=ALL | grep title

    このコマンドは、カーネルの起動エントリーを表示します。kernel フィールドは、カーネルパスを表示します。

    以下の手順では、grubby ユーティリティーを使用して、カーネルコマンドラインでシステムにインストールされているカーネルの一覧を表示する方法を説明します。

たとえば、BLS インストールと BLS インストール以外の両方の Grub2 メニューから grubby-8.40-17 を一覧表示することを検討してください。

手順

インストール済みのすべてのカーネルモジュールを一覧表示するには、以下を行います。

  • 以下のコマンドを実行します。

    # grubby --info=ALL | grep title

    インストールされているカーネルの一覧は、以下のようになります。

    title=Red Hat Enterprise Linux (4.18.0-20.el8.x86_64) 8.0 (Ootpa)
    title=Red Hat Enterprise Linux (4.18.0-19.el8.x86_64) 8.0 (Ootpa)
    title=Red Hat Enterprise Linux (4.18.0-12.el8.x86_64) 8.0 (Ootpa)
    title=Red Hat Enterprise Linux (4.18.0) 8.0 (Ootpa)
    title=Red Hat Enterprise Linux (0-rescue-2fb13ddde2e24fde9e6a246a942caed1) 8.0 (Ootpa)

上記の出力では、Grub2 メニューを使用して grubby-8.40-17 にインストールされたカーネルの一覧が表示されます。

3.6. カーネルのデフォルトとしての設定

以下の手順では、grubby コマンドラインツールおよび GRUB2 を使用して、特定のカーネルをデフォルトとして設定する方法を説明します。

手順

grubby ツールを使用した、カーネルのデフォルトとしての設定
  • 以下のコマンドを実行し、grubby ツールを使用してカーネルをデフォルトとして設定します。

# grubby --set-default $kernel_path

コマンドは、.conf の接尾辞のないマシン ID を引数として使用します。

注記

マシン ID は /boot/loader/entries/ ディレクトリーにあります。

id 引数を使用したカーネルのデフォルト設定
  • id 引数を使用してブートエントリーの一覧を表示し、任意のカーネルをデフォルトとして設定します。
# grubby --info ALL | grep id
# grubby --set-default /boot/vmlinuz-<version>.<architecture>
注記

title 引数を使用してブートエントリーの一覧を表示するには、# grubby --info=ALL | grep title コマンドを実行します。

次回の起動時のみのデフォルトカーネルの設定
  • 次のコマンドを実行し、grub2-reboot コマンドを使用して、次回の再起動限定でデフォルトのカーネルを設定します。
# grub2-reboot <index|title|id>
警告

取り扱いに注意して、次回の起動時限定のデフォルトのカーネルを設定します。新しいカーネル RPM、自己ビルドカーネルをインストールし、エントリーを /boot/loader/entries/ ディレクトリーに手動で追加すると、インデックス値が変更される可能性があります。

3.7. モジュール情報の表示

カーネルモジュールの操作を行う場合は、そのモジュールに関する詳細が表示される場合があります。この手順では、カーネルモジュールに関する追加情報を表示する方法を説明します。

前提条件

  • kmod パッケージがインストールされている。

手順

  • カーネルモジュールの情報を表示するには、以下を実行します。

    $ modinfo <KERNEL_MODULE_NAME>
    
    For example:
    $ modinfo virtio_net
    
    filename:       /lib/modules/4.18.0-94.el8.x86_64/kernel/drivers/net/virtio_net.ko.xz
    license:        GPL
    description:    Virtio network driver
    rhelversion:    8.1
    srcversion:     2E9345B281A898A91319773
    alias:          virtio:d00000001v*
    depends:        net_failover
    intree:         Y
    name:           virtio_net
    vermagic:       4.18.0-94.el8.x86_64 SMP mod_unload modversions
    …​
    parm:           napi_weight:int
    parm:           csum:bool
    parm:           gso:bool
    parm:           napi_tx:bool

    modinfo コマンドは、指定したカーネルモジュールの詳細情報を表示します。読み込まれているかどうかに関わらず、利用可能なすべてのモジュールの情報を照会できます。parm エントリーは、ユーザーがモジュールに設定できるパラメーターと、期待される値のタイプを示します。

    注記

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

関連情報

  • modinfo(8) の man ページ

3.8. システムランタイム時のカーネルモジュールの読み込み

Linux カーネルの機能を拡張する最適な方法は、カーネルモジュールを読み込むことです。以下の手順では、modprobe コマンドを使用して、カーネルモジュールを検出し、現在実行しているカーネルに読み込む方法を説明します。

前提条件

  • root 権限
  • kmod パッケージがインストールされている。
  • 関連のカーネルモジュールが読み込まれていない。これを確認するには、ロードしているカーネルモジュール を一覧表示します。

手順

  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
重要

この手順で説明されている変更は、システムを再起動は維持されません。システムの再起動後にも 設定を維持する ようにカーネルモジュールを読み込む方法は、「システムの起動時に自動的にカーネルモジュールを読み込む」を参照してください。

関連情報

  • modprobe(8) の man ページ

3.9. システムランタイム時のカーネルモジュールのアンロード

時折、実行中のカーネルから特定のカーネルモジュールをアンロードする必要性に駆られることがあります。以下の手順では、modprobe コマンドを使用して、現在読み込まれているカーネルから、システムの実行時にカーネルモジュールを見つけてアンロードする方法を説明します。

前提条件

  • root 権限
  • kmod パッケージがインストールされている。

手順

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

    カーネルモジュールに依存関係がある場合は、カーネルモジュールをアンロードする前に、これらをアンロードします。依存関係のあるモジュールを特定する方法は、「現在読み込まれているカーネルモジュールの一覧表示」および「カーネルモジュールの依存関係」を参照してください。

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

    # modprobe -r <MODULE_NAME>

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

    警告

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

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

    $ lsmod | grep <MODULE_NAME>

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

重要

この手順を終了すると、システムの起動時に自動的に読み込まれるように定義したカーネルモジュールは、システムを再起動してもアンロードされません。この結果を追跡する方法は、システムの起動時にカーネルモジュールが自動的にロードされないようにする」を参照してください。

関連情報

  • modprobe(8) の man ページ

3.10. システムの起動時に自動的にカーネルモジュールを読み込む

以下の手順では、ブートプロセス中に自動的に読み込まれるようにカーネルモジュールを設定する方法を説明します。

前提条件

  • root 権限
  • kmod パッケージがインストールされている。

手順

  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>

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

重要

この手順で説明している変更は、システムを再起動しても持続されます

関連情報

  • modules-load.d(5) の man ページ

3.11. システムの起動時にカーネルモジュールが自動的にロードされないようにする

以下の手順では、システムの起動プロセス中にカーネルモジュールが自動的に読み込まれないように拒否リストに追加する方法を説明します。

前提条件

  • root 権限
  • kmod パッケージがインストールされている。
  • 拒否リストに指定したカーネルモジュールが現在のシステム設定に重要でないことを確認する。

手順

  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
重要

この手順で説明している変更は、システムを再起動しても持続されます。主要なカーネルモジュールを拒否リストに誤って追加した場合には、システムが不安定になったり、稼働しなくなったりする可能性があります。

関連情報

  • dracut(8) の man ページ

第4章 セキュアブート用のカーネルモジュールの署名

署名付きカーネルモジュールを使用して、システムのセキュリティーを強化できます。以下のセクションでは、セキュアブートが有効になっている UEFI ベースのビルドシステムで、RHEL 8 で使用するプライベートに構築されたカーネルモジュールへの自己署名の方法を説明します。また、カーネルモジュールの展開を希望するターゲットシステムに公開鍵をインポートするのに利用可能なオプションについても説明しています。

カーネルモジュールに署名して読み込むには、以下を行う必要があります。

セキュアブートが有効な場合は、UEFI オペレーティングシステムのブートローダー、Red Hat Enterprise Linux のカーネル、およびすべてのカーネルモジュールを秘密鍵で署名し、対応する公開鍵で認証する必要があります。それらが署名・認証されてなければ、システムは起動プロセスを終了できません。

RHEL 8 ディストリビューションには、以下が含まれます。

  • 署名付きブートローダー
  • 署名付きカーネル
  • 署名付きカーネルモジュール

また、署名された第 1 ステージのブートローダーと署名されたカーネルには、組み込み Red Hat 公開鍵が含まれています。この署名済みの実行可能なバイナリーおよび組み込み鍵により、RHEL 8 は UEFI セキュアブートに対応するシステムで、UEFI ファームウェアが提供する Microsoft UEFI セキュアブート認証局の鍵を使用してインストール、起動、実行できます。すべての UEFI ベースのシステムにセキュアブートのサポートが含まれているわけではないことに注意してください。

前提条件

外部でビルドされたカーネルモジュールに署名できるようにするには、次の表にリストされているユーティリティをビルドシステムにインストールします。

表4.1 必要なユーティリティー

ユーティリティー提供するパッケージ使用対象目的

openssl

openssl

ビルドシステム

公開および秘密 X.509 鍵のペアを生成

sign-file

kernel-devel

ビルドシステム

秘密鍵でカーネルモジュールに署名するために使用する実行ファイル

mokutil

mokutil

ターゲットシステム

公開鍵を手動で登録する際に使用するオプションのユーティリティ

keyctl

keyutils

ターゲットシステム

システムキーリングへの公開鍵の表示時に使用するオプションのユーティリティー

注記

カーネルモジュールを構築、署名するビルドシステムは、UEFI セキュアブートを有効にする必要がなく、UEFI ベースのシステムである必要すらありません。

4.1. X.509 鍵でカーネルモジュールを認証するための要件

RHEL 8 では、カーネルモジュールが読み込まれると、カーネルは、カーネルシステムキーリング (.builtin_trusted_keys) およびカーネルプラットフォームキーリング (.platform) からの公開 X.509 鍵に対して、モジュールの署名を確認します。.platform キーリングには、サードパーティーのプラットフォームプロバイダーからの鍵と、カスタム公開鍵が含まれています。カーネルシステム .blacklist キーリングのキーは検証から除外されます。以下のセクションでは、キー、キーリングのソースの概要、システム内のさまざまなソースから読み込んだ鍵の例を説明します。また、カーネルモジュールを認証する方法も確認できます。

UEFI セキュアブート機能が有効なシステムでカーネルモジュールを読み込むには、特定の条件を満たす必要があります。

UEFI セキュアブートが有効になっているか、module.sig_enforce カーネルパラメーターが指定されている場合は、次のコマンドを実行します。

  • 署名がシステムキーリング (.builtin_trusted_keys) およびプラットフォームキーリング (.platform) からの鍵に対して認証された署名付きカーネルモジュールのみを読み込むことができます。
  • 公開鍵は、システムで取り消された鍵リング (.blacklist) には置けません。

UEFI セキュアブートが無効で、module.sig_enforce カーネルパラメーターが指定されていない場合は、次のようになります。

  • 公開鍵なしで、署名なしのカーネルモジュールと署名付きカーネルモジュールを読み込むことができます。

システムが UEFI ベースでないか、UEFI セキュアブートが無効になっている場合は、次のコマンドを実行します。

  • .builtin_trusted_keys および .platform には、カーネルに組み込まれている鍵のみが読み込まれます。
  • カーネルの再構築なしでキーセットを拡張することはできません。

表4.2 カーネルモジュールの読み込み認証要件

モジュールの署名公開鍵ありおよび署名が有効UEFI セキュアブートの状態sig_enforceモジュールの読み込みカーネルの汚染

署名なし

-

有効でない

有効でない

成功

はい

有効でない

有効

失敗

-

有効

-

失敗

-

署名あり

いいえ

有効でない

有効でない

成功

はい

有効でない

有効

失敗

-

有効

-

失敗

-

署名あり

はい

有効でない

有効でない

成功

いいえ

有効でない

有効

成功

いいえ

有効

-

成功

いいえ

4.2. 公開鍵のソース

システムの起動時に、カーネルは永続鍵ストアのセットから、次の鍵リングに X.509 鍵を読み込みます。

  • システムキーリング (.builtin_trusted_keys)
  • .platform キーリング
  • システム .blacklist キーリング

表4.3 システムキーリングのソース

X.509 鍵のソースユーザーは鍵を追加できます。UEFI セキュアブートの状態ブート中に読み込まれる鍵

カーネルに埋め込み

×

-

.builtin_trusted_keys

UEFI セキュアブート "db"

限定的

有効でない

いいえ

有効

.platform

shim.efi ブートローダーに埋め込み

いいえ

有効でない

いいえ

有効

.builtin_trusted_keys

Machine Owner Key (MOK) リスト

はい

有効でない

いいえ

有効

.platform

.builtin_trusted_keys:

  • 起動時に構築される鍵リング
  • 信頼された公開鍵を含む
  • キーの表示には、root 権限が必要

.platform:

  • 起動時に構築される鍵リング
  • サードパーティーのプラットフォームプロバイダーからの鍵と、カスタム公開鍵が含まれている
  • キーの表示には、root 権限が必要

.blacklist

  • 取り消された X.509 鍵を持つキーリング
  • 公開鍵が .builtin_trusted_keys に存在しても、.blacklist の鍵で署名した 1 つのモジュールが認証に失敗します。

UEFI Secure Boot db:

  • 署名データベース
  • UEFI アプリケーション、UEFI ドライバー、およびブートローダーの鍵 (ハッシュ) を保存
  • 鍵はマシンに読み込み可能

UEFI Secure Boot dbx:

  • 取り消された署名データベース
  • キーの読み込みを阻止する
  • このデータベースーから取り消された鍵は、. ブラックリスト キーリングに追加されます。

4.3. 公開鍵と秘密鍵の生成

セキュアブートを有効化したシステム上でカーネルモジュールを使用する作業を正常に行うには、公開および秘密 X.509 鍵ペアを生成する必要があります。後で秘密鍵を使用してカーネルモジュールに署名します。セキュアブートで署名済みモジュールを検証するには、適切な公開鍵を Machine Owner Key (MOK) に追加する必要があります。

このキーペア生成のパラメーターの一部は、設定ファイルで指定するのが最適です。

手順

  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 では、鍵のペアの有効期限は重要です。キーの有効期限はありませんが、カーネルモジュールはその署名キーの有効期間内に署名する必要があります。たとえば、2019 でのみ有効な鍵を使用して、その鍵で 2019 で署名されたカーネルモジュールを認証できます。ただし、ユーザーはこの鍵を使用して 2020 でカーネルモジュールに署名することはできません。

  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. カーネルモジュールを認証、読み込むすべてのシステムに公開鍵を登録します。
警告

強力なセキュリティー対策とアクセスポリシーを適用して、秘密鍵の内容を保護します。悪用すれば、この鍵は、一致する公開鍵で認証されるシステムのセキュリティに危害を与えるために使用できます。

4.4. システムキーリングの出力例

keyctl ユーティリティーを使用して、システムのキーリングの鍵に関する情報を表示できます。

以下は、UEFI セキュアブートが有効になっている RHEL 8 システムからの .builtin_trusted_keys.platform.blacklist の短い出力例です。

# keyctl list %:.builtin_trusted_keys
6 keys in keyring:
...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87...
...asymmetric: Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29...
...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed...
...asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e...
...asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b...
...asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...

# keyctl list %:.platform
4 keys in keyring:
...asymmetric: VMware, Inc.: 4ad8da0472073...
...asymmetric: Red Hat Secure Boot CA 5: cc6fafe72...
...asymmetric: Microsoft Windows Production PCA 2011: a929f298e1...
...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4e0bd82...

# keyctl list %:.blacklist
4 keys in keyring:
...blacklist: bin:f5ff83a...
...blacklist: bin:0dfdbec...
...blacklist: bin:38f1d22...
...blacklist: bin:51f831f...

上記の .builtin_trusted_keys キーリングでは、UEFI セキュアブート "db" 鍵から加わった 2 つの鍵と、shim.efi ブートローダーに組み込まれている Red Hat Secure Boot (CA key 1) が示されています。

以下の例は、カーネルコンソールの出力を示しています。このメッセージでは、UEFI セキュアブート関連のソースを持つキーが識別されます。これには、UEFI セキュアブート db、組み込み shim、および MOK リストが含まれます。

# dmesg | grep 'EFI: Loaded cert'
[5.160660] EFI: Loaded cert 'Microsoft Windows Production PCA 2011: a9290239...
[5.160674] EFI: Loaded cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309b...
[5.165794] EFI: Loaded cert 'Red Hat Secure Boot (CA key 1): 4016841644ce3a8...

関連情報

  • keyctl(1),dmesg(1)マニュアルページ

4.5. 公開鍵を MOK リストに追加することでターゲットシステムで公開鍵を登録する手順

セキュアブートが有効になっている UEFI ベースのシステムで RHEL 8 を起動すると、カーネルは、セキュアブート db の鍵データベースにある公開鍵をすべてシステムキーリング (.builtin_trusted_keys) に読み込みます。同時に、カーネルは、失効した鍵の dbx データベースにある鍵を除外します。以下のセクションでは、システムキーリング (.builtin_trusted_keys) が公開鍵を使用してカーネルモジュールを認証できるように、ターゲットシステムで公開鍵をインポートする方法を説明します。

Machine Owner Key (MOK) 機能を使用して、UEFI セキュアブートキーデータベースを拡張することができます。セキュアブートが有効な UEFI 対応システムで RHEL 8 を起動すると、鍵データベースの鍵に加えて、MOK の一覧の鍵もシステムキーリング (.builtin_trusted_keys) に追加されます。MOK リストの鍵は、セキュアブートデータベースの鍵と同様に永続的かつ安全な方法で保存されますが、これらは別個の機能です。MOK 機能は、shim.efiMokManager.efigrubx64.efi および mokutil ユーティリティーでサポートされています。

MOK 鍵の登録は、各ターゲットシステムの UEFI システムコンソールでユーザーが物理的に手動で対応する必要があります。それにもかかわらず、MOK 機能は、新規生成された鍵ペアのテストとこれで署名されたカーネルモジュールのテストにおいて便利な方法を提供します。

手順

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

    # mokutil --import my_signing_key_pub.der

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

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

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

  3. このリクエストに関連付けたパスワードを入力し、登録を確認します。

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

鍵が MOK リストに追加されると、UEFI セキュアブートが有効な場合にこの鍵がシステムのキーリングに自動的に伝播され、その後のブートが可能になります。

注記

システムでカーネルモジュールの認証を実現するために、ファクトリーファームウェアイメージで公開鍵を UEFI セキュアブート鍵データベースに組み入れるようシステムベンダーに要求することを検討します。

4.6. 秘密鍵を使用したカーネルモジュールの署名

UEFI セキュアブートメカニズムが有効な場合は、署名済みカーネルモジュールを読み込むことで、使用中のシステムでセキュリティーが強化され利点を得ることができます。以下のセクションでは、秘密鍵を使用してカーネルモジュールに署名する方法を説明します。

前提条件

手順

  • 以下の例のようにパラメーターを使用して sign-file ユーティリティーを実行します。

    # /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 my_signing_key.priv my_signing_key_pub.der my_module.ko

    sign-file は、署名を計算して、カーネルモジュールファイルの ELF イメージに直接追加します。modinfo ユーティリティーを使うと、カーネルモジュールの署名がある場合は、それについての情報を表示できます。

    注記

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

    これでカーネルモジュールの読み込み準備が完了しました。署名済みのカーネルモジュールは、UEFI セキュアブートが無効となっているシステムまたは UEFI 以外のシステムでも読み込み可能であることに注意してください。つまり、署名済みのカーネルモジュールと署名なしのカーネルモジュールの両方を提供する必要はないことになります。

    重要

    RHEL 8 では、鍵のペアの有効期限は重要です。キーの有効期限はありませんが、カーネルモジュールはその署名キーの有効期間内に署名する必要があります。sign-file ユーティリティーでは、これに関する警告は表示されません。たとえば、2019 でのみ有効な鍵を使用して、その鍵で 2019 で署名されたカーネルモジュールを認証できます。ただし、ユーザーはこの鍵を使用して 2020 でカーネルモジュールに署名することはできません。

4.7. 署名付きカーネルモジュールの読み込み

公開鍵がシステムキーリング (.builtin_trusted_keys) および MOK リストに登録されると、以下のセクションで説明されているように、modprobe コマンドを使用して各カーネルモジュールに秘密鍵で署名されたカーネルモジュールを読み込むことができます。

前提条件

手順

  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

第5章 カーネルコマンドラインパラメーターの設定

カーネルコマンドラインパラメーターは、システムの起動時に Red Hat Enterprise Linux カーネルの特定の側面の動作を変更する手段のひとつです。システム管理者は、システムの起動時に設定されるオプションを完全に制御できます。特定のカーネルの動作はシステムの起動時にのみ設定できるため、この変更を行う方法を理解することが管理スキルの鍵となります。

重要

カーネルコマンドラインパラメーターを変更することで、システムの動作が変更するオプションは、システムに悪影響を及ぼす可能性があります。したがって、実稼働環境にデプロイする前に変更をテストする必要があります。詳細なガイダンスは、Red Hat サポートまでご連絡ください。

5.1. カーネルコマンドラインパラメーターの概要

カーネルコマンドラインパラメーターは、以下のシステムの起動時間設定に使用されます。

  • Red Hat Enterprise Linux カーネル
  • 初期 RAM ディスク
  • ユーザー領域機能

カーネルの起動時間パラメーターは、デフォルト値を上書きしたり、特定のハードウェア構成にするために使用されます。

デフォルトでは、GRUB2 ブートローダーを使用するシステムのカーネルコマンドラインパラメーターは、すべてのカーネルブートエントリーの /boot/grub2/grubenv ファイルの kernelopts 変数で定義されます。

注記

IBM Z では、zipl ブートローダーは環境変数に対応していないため、カーネルコマンドラインパラメーターはブートエントリー設定ファイルに保存されます。したがって、kernelopts 環境変数は使用できません。

関連情報

5.2. grubby とは

grubby は、ブートローダー固有の設定ファイルを操作するユーティリティーです。

grubby は、デフォルトのブートエントリーの変更や、GRUB2 メニューエントリーから引数の追加または削除にも使用できます。

詳細は、grubby(8) の man ページを参照してください。

5.3. ブートエントリーとは

ブートエントリーは設定ファイルに格納され、特定のカーネルバージョンに関連付けられるオプションの集合です。実際には、ブートエントリーは、システムにカーネルがインストールされているのと同じ数だけあります。ブートエントリーの設定ファイルは、/boot/loader/entries/ ディレクトリーにあり、以下のようになります。

6f9cc9cb7d7845d49698c9537337cedc-4.18.0-5.el8.x86_64.conf

上記のファイル名は、/etc/machine-id ファイルに保存されているマシン ID と、カーネルバージョンから構成されます。

ブートエントリーの設定ファイルには、カーネルバージョン、初期 ramdisk イメージ、および kernelopts 環境変数 (カーネルコマンドラインパラメーターを含む) に関する情報が含まれます。ブートエントリーの設定の内容は、以下で確認できます。

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

kernelopts 環境変数は /boot/grub2/grubenv ファイルで定義されます。

5.4. すべてのブートエントリーでカーネルコマンドラインパラメーターの変更

この手順では、システムにあるすべてのブートエントリーのカーネルコマンドラインパラメーターを変更する方法を説明します。

前提条件

  • grubby ユーティリティーおよび zipl ユーティリティーがシステムにインストールされている。

手順

  • パラメーターを追加するには、以下を行います。

    # grubby --update-kernel=ALL --args="<NEW_PARAMETER>"

    GRUB2 ブートローダーを使用するシステムの場合は、/boot/grub2/grubenvkernelopts 変数に新しいカーネルパラメーターを追加して、ファイルを更新します。

    zIPL ブートローダーを使用する IBM Z では、新しいカーネルパラメーターを各 /boot/loader/entries/<ENTRY>.conf ファイルに追加します。

    • IBM Z で、起動メニューを更新するオプションを指定せずに zipl コマンドを実行します。
  • パラメーターを削除するには、次のコマンドを実行します。

    # grubby --update-kernel=ALL --remove-args="<PARAMETER_TO_REMOVE>"
    • IBM Z で、起動メニューを更新するオプションを指定せずに zipl コマンドを実行します。

関連情報

5.5. 1 つのブートエントリーでカーネルコマンドラインパラメーターの変更

この手順では、システム上の単一のブートエントリーのカーネルコマンドラインパラメーターを変更する方法を説明します。

前提条件

  • grubby ユーティリティーおよび zipl ユーティリティーがシステムにインストールされている。

手順

  • パラメーターを追加するには、以下を行います。

    grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="<NEW_PARAMETER>"
    • IBM Z で、起動メニューを更新するオプションを指定せずに zipl コマンドを実行します。
  • パラメーターを削除するには、以下のコマンドを使用します。

    grubby --update-kernel=/boot/vmlinuz-$(uname -r) --remove-args="<PARAMETER_TO_REMOVE>"
    • IBM Z で、起動メニューを更新するオプションを指定せずに zipl コマンドを実行します。
注記

grub.cfg ファイルを使用するシステムでは、デフォルトで、カーネルブートエントリーごとに options パラメーターがあり、これは kernelopts 変数に設定されます。この変数は、/boot/grub2/grubenv 設定ファイルで定義されます。

重要

GRUB2 システムの場合:

  • すべてのブートエントリーに対してカーネルコマンドラインパラメーターを変更する場合には、grubby ユーティリティーは /boot/grub2/grubenv ファイルの kernelopts 変数を更新します。
  • 1 つのブートエントリーのカーネルコマンドラインパラメーターが変更されると、kernelopts 変数の拡張やカーネルパラメーターの変更が行われ、得られた値は各ブートエントリーの /boot/loader/entries/<RELEVANT_KERNEL_BOOT_ENTRY.conf> ファイルに保存されます。

zIPL システムの場合:

  • grubby は、個別のカーネルブートエントリーのカーネルコマンドラインパラメーターを変更して、/boot/loader/entries/<ENTRY>.conf ファイルに保存します。

関連情報

第6章 ランタイム時のカーネルパラメーターの設定

システム管理者は、ランタイム時に Red Hat Enterprise Linux カーネルの動作を多数変更できます。本セクションでは、sysctl コマンドを使用し、/etc/sysctl.d//proc/sys/ ディレクトリーにある設定ファイルを変更して、ランタイム時にカーネルのパラメーターを設定する方法を説明します。

6.1. カーネルパラメーターとは

カーネルパラメーターは、システムの実行中に調整できる調整可能な値です。変更を有効にする場合でも、カーネルの再起動や再コンパイルは不要です。

以下を使用してカーネルパラメーターに対応できます。

  • sysctl コマンド
  • /proc/sys/ ディレクトリーにマウントされている仮想ファイルシステム
  • /etc/sysctl.d/ ディレクトリー内の設定ファイル

調整可能パラメーターは、カーネルサブシステムでクラスに分割されます。Red Hat Enterprise Linux には、以下の調整可能のクラスがあります。

表6.1 sysctl クラスの表

調整パラメーターのクラスサブシステム

abi

実行ドメインおよびパーソナリティー

crypto

暗号化インターフェース

debug

カーネルのデバッグインターフェース

dev

デバイス固有の情報

fs

グローバルおよび固有の調整可能なファイルシステム

kernel

グローバルなカーネルの設定項目

net

ネットワークの設定項目

sunrpc

Sun Remote Procedure Call (NFS)

user

ユーザー名前空間の制限

vm

メモリー、バッファー、およびキャッシュのチューニングと管理

重要

プロダクションシステムでカーネルパラメーターを設定するには、慎重なプランニングが必要です。プランニングが欠如した変更では、カーネルが不安定になり、システムの再起動が必要とることがあります。カーネル値を変更する前に、有効なオプションを使用していることを確認してください。

関連情報

  • sysctl(8) および sysctl.d(5) の man ページ

6.2. sysctl でカーネルパラメーターの一時的な設定

以下の手順では、sysctl コマンドを使用して、ランタイム時にカーネルパラメーターを一時的に設定する方法を説明します。このコマンドは、調整可能パラメーターの一覧表示およびフィルタリングにも便利です。

前提条件

  • root 権限

手順

  1. すべてのパラメーターとそれらの値を一覧表示するには、以下を実行します。

    # sysctl -a
    注記

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

  2. パラメーターを一時的に設定するには、以下の例のようにコマンドを実行します。

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

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

    注記

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

6.3. sysctl でカーネルパラメーターを永続的に設定

以下の手順では、sysctl コマンドを使用して、カーネルパラメーターを永続的に設定する方法を説明します。

前提条件

  • root 権限

手順

  1. すべてのパラメーターを一覧表示するには、以下を実行します。

    # sysctl -a

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

  2. パラメーターを永続的に設定するには、以下のコマンドを実行します。

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

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

注記

カーネルパラメーターを永続的に変更するには、/etc/sysctl.d/ ディレクトリーの設定ファイルに手動で変更を行ってください。

関連情報

6.4. /etc/sysctl.d/ の設定ファイルでカーネルパラメーターの調整

以下の手順では、/etc/sysctl.d/ ディレクトリーの設定ファイルを手動で修正して、カーネルパラメーターを永続的に設定する方法を説明します。

前提条件

  • root 権限

手順

  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>

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

関連情報

  • sysctl(8)sysctl.d(5) の man ページ

6.5. /proc/sys/ でカーネルパラメーターの一時的な設定

以下の手順では、仮想ファイルシステム /proc/sys/ ディレクトリー内のファイルを使用して、カーネルパラメーターを一時的に設定する方法を説明します。

前提条件

  • root 権限

手順

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

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

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

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

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

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

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

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

第7章 仮想化環境でカーネルパニックのパラメーターを無効のままにする

Red Hat Enterprise Linux 8 (RHEL 8) に仮想化環境を設定する場合、仮想化環境は、システムパニックを必要としない誤ったソフトロックアップを発生させる可能性があるため、カーネルパラメーター softlockup_panic および nmi_watchdog を有効にしないでください。

次のセクションでは、このアドバイスの理由を、以下の点に要約して説明します。

  • ソフトロックアップの原因
  • ソフトロックアップ時にシステムの動作を制御するカーネルパラメーターの説明
  • 仮想化環境でソフトロックがどのように発生するかの説明

7.1. ソフトロックアップとは

ソフトロックアップは、通常、タスクが再スケジュールされずに CPU のカーネル領域で実行しているときにバグによって生じる状況です。また、このタスクは、その他のタスクがその特定の CPU で実行することを許可しません。これにより、警告が、システムコンソールを介してユーザーに表示されます。この問題は、ソフトロックアップの発生 (fire) とも呼ばれます。

7.2. カーネルパニックを制御するパラメーター

ソフトロックの検出時にシステムの動作を制御する、以下のカーネルパラメーターを設定できます。

softlockup_panic

ソフトロックアップが検出されたときにカーネルでパニックを発生させるどうかを制御します。

Effect

整数

0

カーネルが、ソフトロックアップでパニックにならない

整数

1

カーネルが、ソフトロックアップでパニックになる

RHEL 8 では、この値のデフォルトは 0 です。

パニックを発生させるためには、システムで、最初にハードロックアップを検出する必要があります。検出は、nmi_watchdog パラメーターで制御されます。

nmi_watchdog

ロックアップ検出メカニズム (watchdogs) がアクティブかどうかを制御します。このパラメーターは整数型です。

Effect

0

ロックアップ検出を無効にする

1

ロックアップ検出を有効にする

ハードロックアップ検出は、各 CPU で割り込みに応答する機能を監視します。

watchdog_thresh

ウォッチドッグの hrtimer、NMI イベント、およびソフトロックアップまたはハードロックアップのしきい値を制御します。

デフォルトのしきい値ソフトロックアップのしきい値

10 秒

2 * watchdog_thresh

このパラメーターをゼロに設定すると、ロックアップ検出を無効にします。

7.3. 仮想化環境で誤ったソフトロックアップ

「ソフトロックアップとは」で説明されている物理ホストでのソフトロックアップの発生は、通常、カーネルまたはハードウェアのバグを示しています。仮想化環境のゲストオペレーティングシステムで同じ現象が発生すると、誤った警告が表示される場合があります。

ホストの負荷が重い場合や、メモリーなどの特定リソースに対する競合が多い場合は、通常、ソフトロックアップが誤って発生します。これは、ホストが 20 秒よりも長い期間、ゲストの CPU をスケジュールすることが原因となる場合があります。その後、再度、ホストで実行するようにゲスト CPU がスケジュールされると、タイマーにより発生する 時間ジャンプ が発生します。タイマーには、ウォッチドッグの hrtimer も含まれます。これにより、ゲスト CPU のソフトロックアップを報告できます。

仮想化環境でのソフトロックアップは誤りである可能性があるため、ゲスト CPU でソフトロックアップが報告されたときにシステムパニックを発生させるカーネルパラメーターは有効にしないでください。

重要

ゲストのソフトロックアップについて理解するには、ホストがゲストをタスクとしてスケジュールしてから、ゲストが独自のタスクをスケジュールしていることを理解することが重要になります。

第8章 データベースサーバーのカーネルパラメーターの調整

特定のデータベースアプリケーションのパフォーマンスに影響を与える可能性のあるカーネルパラメーターのセットには、様々なものがあります。以下のセクションでは、データベースサーバーおよびデータベースの効率的な運用を確保するために構成するカーネルパラメーターを説明します。

8.1. データベースサーバーの概要

データベースサーバーは、データベース管理システム (DBMS) の機能を提供するサービスです。DBMS は、データベース管理のためのユーティリティーを提供し、エンドユーザー、アプリケーション、およびデータベースと対話します。

Red Hat Enterprise Linux 8 は、以下のデータベース管理システムを提供します。

  • MariaDB 10.3
  • MariaDB 10.5 - RHEL 8.4 以降で利用できます。
  • MySQL 8.0
  • PostgreSQL 10
  • PostgreSQL 9.6
  • PostgreSQL 12 - RHEL 8.1.1 以降で利用できます。
  • PostgreSQL 13: RHEL 8.4 以降で利用できます。

8.2. データベースアプリケーションのパフォーマンスに影響するパラメーター

次のカーネルパラメーターは、データベースアプリケーションのパフォーマンスに影響します。

fs.aio-max-nr

サーバー上でシステムが処理できる非同期 I/O 操作の最大数を定義します。

注記

fs.aio-max-nr パラメーターを増やしても、aio の制限以上を追加することはありません。

fs.file-max

システムがインスタンスで対応するファイルハンドル (一時ファイル名または開いているファイルに割り当てられた ID) の最大数を定義します。

カーネルは、アプリケーションからファイルハンドルが要求されるたびに、ファイルハンドルを動的に割り当てます。ただし、カーネルは、そのファイルハンドルがアプリケーションによって解放されたときに解放しません。代わりに、カーネルはこれらのファイルハンドルをリサイクルします。これは、現在使用しているファイルハンドルの数が少なくても、時間の経過とともに割り当てられたファイルハンドルの合計が増加することを意味します。

kernel.shmall
システム全体で使用できる共有メモリーページの合計を定義します。メインメモリー全体を使用するには、kernel.shmall パラメーターの値が、メインメモリーの合計サイズ以下である必要があります。
kernel.shmmax
Linux プロセスが仮想アドレス空間に割り当てることができる 1 つの共有メモリーセグメントの最大サイズをバイト単位で定義します。
kernel.shmmni
データベースサーバーが処理できる共有メモリーセグメントの最大数を定義します。
net.ipv4.ip_local_port_range
特定のポート番号なしでデータベースサーバーに接続するプログラムにシステムが使用できるポート範囲を定義します。
net.core.rmem_default
TCP (Transmission Control Protocol) を介してデフォルトの受信ソケットメモリーを定義します。
net.core.rmem_max
TCP (Transmission Control Protocol) による最大受信ソケットメモリーを定義します。
net.core.wmem_default
TCP (Transmission Control Protocol) によるデフォルトの送信ソケットメモリーを定義します。
net.core.wmem_max
TCP (Transmission Control Protocol) による最大送信ソケットメモリーを定義します。
vm.dirty_bytes / vm.dirty_ratio
ダーティーデータを生成するプロセスが write() 関数で開始するダーティー可能メモリーの割合 (バイト単位) でしきい値を定義します。
注記

一度に指定できるのは、vm.dirty_bytes または vm.dirty_ratioいずれか です。

vm.dirty_background_bytes / vm.dirty_background_ratio
カーネルがダーティーデータをハードディスクにアクティブに書き込もうとする、ダーティー可能なメモリーの割合 (バイト単位) でしきい値を定義します。
注記

一度に指定できるのは、vm.dirty_background_bytes または vm.dirty_background_ratioいずれか です。

vm.dirty_writeback_centisecs

ハードディスクへのダーティーデータの書き込みを行うカーネルスレッドの起動を定期的に行う間隔を定義します。

このカーネルパラメーターは、100 分の 1 秒単位で測定されます。

vm.dirty_expire_centisecs

ダーティーデータがハードディスクに書き込まれるまでの時間を定義します。

このカーネルパラメーターは、100 分の 1 秒単位で測定されます。

第9章 カーネルロギングの使用

ログファイルは、システム (カーネル、サービス、および実行中のアプリケーションなど) に関するメッセージが含まれるファイルです。Red Hat Enterprise Linux におけるロギングシステムは、組み込みの syslog プロトコルに基づいています。さまざまなユーティリティーがこのシステムを使用してイベントを記録し、ログファイルにまとめます。このファイルは、オペレーティングシステムの監査や問題のトラブルシューティングに役に立ちます。

9.1. カーネルリングバッファーとは

コンソールは、システムの起動プロセス時に、システム起動の初期段階に関する重要な情報を多数提供します。先に出力されたメッセージが失われないように、カーネルではリングバッファーと呼ばれるものが使用されています。このバッファーは、カーネルコード内の printk() 関数により生成されるブートメッセージなど、すべてのメッセージを格納します。次に、カーネルリングバッファーからのメッセージは、syslog サービスなどの永続ストレージのログファイルに読み込まれ、保存されます。

上記のバッファーは、固定サイズの循環データ構造であり、カーネルにハードコーディングされています。ユーザーは、dmesg コマンドまたは /var/log/boot.log ファイル介して、カーネルリングバッファーに保存されているデータを表示できます。リングバッファーが満杯になると、新しいデータにより古いデータが上書きされます。

関連情報

  • syslog(2) および dmesg(1) の man ページ

9.2. ログレベルおよびカーネルロギングにおける printk の役割

カーネルが報告する各メッセージには、メッセージの重要性を定義するログレベルが関連付けられています。カーネルリングバッファーは、「カーネルリングバッファーとは」で説明されているように、すべてのログレベルのカーネルメッセージを収集します。バッファーからコンソールに出力されるメッセージを定義するのは kernel.printk パラメーターです。

ログレベルの値は、以下の順序で分類されます。

  • 0 - カーネルの緊急事態。システムが利用できません。
  • 1 - カーネルアラート。すぐに対処する必要があります。
  • 2 - 重大な問題があると見なされるカーネルの状態。
  • 3 - 一般的なカーネルのエラー状態。
  • 4 - 一般的なカーネルの警告状態。
  • 5 - 正常だが重大な状態のカーネル通知。
  • 6 - カーネル情報メッセージ。
  • 7 - カーネルのデバッグレベルメッセージ。

RHEL 8 の kernel.printk には、デフォルトで以下の 4 つの値が含まれます。

# sysctl kernel.printk
kernel.printk = 7	4	1	7

この 4 つの値は、以下を定義します。

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

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

重要

デフォルトの 7 4 1 7 printk 値を使用することで、カーネルアクティビティーのデバッグを改善できます。ただし、シリアルコンソールと組み合わせると、この printk 設定が原因で、集中的な I/O バーストが発生して、RHEL システムが一時的に応答しなくなる可能性があります。通常 4 4 1 7printk 値を設定するとこのような状況を回避できますが、代わりに追加のデバッグ情報が失われてしまいます。

また、quietdebug などの特定のカーネルコマンドラインパラメーターにより、デフォルトの kernel.printk 値が変更される点に注意してください。

関連情報

  • syslog(2) の man ページ

第10章 kdump のインストール

多くの場合、kdump サービスは、新しい Red Hat Enterprise Linux インストールにデフォルトでインストールされ、アクティベートされます。次のセクションでは、kdump に関する情報と、kdump がデフォルトで有効化されていない場合の kdump のインストール方法を説明します。

10.1. kdump とは

kdump は、クラッシュダンプメカニズムを提供するサービスです。サービスを使用すると、システムのメモリー内容を保存し、後で分析することができます。kdumpkexec システムコールを使用して再起動せずに 2 番目のカーネル (キャプチャーカーネル)で起動し、2 番目のカーネルメモリーの内容 (crash dump または vmcore) をキャプチャーして保存します。この第 2 のカーネルは、システムメモリーの予約部分に収納されています。

重要

カーネルクラッシュダンプは、システム障害 (重大なバグ) 時に利用できる唯一の情報になります。したがって、ミッションクリティカルな環境では、kdump を確実に稼働させることが重要です。Red Hat は、システム管理者が通常のカーネル更新サイクルで kexec-tools を定期的に更新してテストすることをお勧めします。これは、新しいカーネル機能が実装されている場合に特に重要です。

10.2. kdump インストールの実行

Anaconda インストーラーは、グラフィカルまたはテキストインターフェースを使用してインタラクティブなインストールを実行する際に kdump 設定用の画面を表示します。インストーラーの画面には Kdump という名前が付けられ、メインのインストールの概要画面から利用できます。また、選択できるのは kdump が有効かどうか、どの程度のメモリーが予約されているかのみで、限られた設定を行うことができます。

RHEL インストール時の kdump の有効化

カスタムのキックスタートインストールなど、一部のインストールオプションは、デフォルトでは kdump のインストールや有効化を行わない場合があります。お使いのシステムでこれが当てはまる場合は、以下の手順に従って kdump をインストールしてください。

前提条件

  • アクティブな Red Hat Enterprise Linux サブスクリプション
  • システムの CPU アーキテクチャー用の kexec-tools パッケージを含むリポジトリー
  • kdump 設定とターゲットの要件をすべて満たしている

手順

  1. 以下のコマンドを実行して、kdump がシステムにインストールされているかどうかを確認します。

    $ rpm -q kexec-tools

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

    kexec-tools-2.0.17-11.el8.x86_64

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

    package kexec-tools is not installed
  2. kdump および必要なパッケージをインストールします。

    # yum install kexec-tools
重要

Red Hat Enterprise Linux 7.4 (kernel-3.10.0-693.el7) 以降から、kdumpでは Intel IOMMU ドライバーがサポートされています。以前のバージョンの Red Hat Enterprise Linux 7.3 (ernel-3.10.0-514[.XYZ].el7) またはそれ以前では、Intel IOMMU サポートを無効にすることが推奨されています。無効にしない場合、kdump カーネルが応答しなくなる可能性が高くなります。

第11章 コマンドラインで kdump の設定

kdump 用メモリーは、システムの起動時に予約されています。メモリーサイズは、システムの GRUB (Grand Unified Bootloader) 2 設定ファイルで設定されています。メモリーサイズは、設定ファイルで指定された crashkernel= 値と、システムの物理メモリーのサイズにより異なります。

11.1. メモリー使用量の設定

crashkernel= オプションは、複数の方法で定義できます。crashkernel= の値を指定するか、auto を設定できます。crashkernel=auto 起動オプションは、システムの物理メモリーの総量に応じて、メモリーを自動的に予約します。設定すると、カーネルは kdump カーネルに必要な適切なメモリーを自動的に予約します。これにより、OOM (Out-of-Memory) エラーが発生しないようにするのに役立ちます。

注記

kdump の自動メモリー割り当ては、システムハードウェアアーキテクチャーと利用可能なメモリーサイズにより異なります。

たとえば、AMD64 および Intel 64 では、利用可能なメモリーが 1GB 以上で、64 ビットの ARM アーキテクチャーで、IBM Power Systems が利用可能なメモリーが 2GB を超える場合に限り、crashkernel=auto パラメーターが機能します。

システムに、自動割り当ての最小メモリーしきい値未満がある場合は、手動で予約メモリーの量を設定できます。

前提条件

  • kdump の設定とターゲットの要件をすべて満たしている

手順

  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
注記

kdump にメモリーを設定する別の方法は、すべてのブートエントリーを更新する grub2-editenv で、kernelopts 変数 に crashkernel=<SOME_VALUE> パラメーターを追加することです。または、grubby ユーティリティーを使用して、単一のエントリーのカーネルコマンドラインパラメーターを更新することもできます。

11.2. kdump ターゲットの設定

カーネルクラッシュがキャプチャーされると、コアダンプはローカルファイルシステムのファイルとして保存したり、デバイスに直接書き込みしたり、NFS (Network File System) または SSH (Secure Shell) プロトコルを使用してネットワーク上で送信したりすることができます。これらのオプションは同時に設定することはできません。デフォルトの動作では、vmcore ファイルはローカルのファイルシステムの /var/pkcs/ ディレクトリーに保存されます。

前提条件

  • kdump の設定とターゲットの要件をすべて満たしている

手順

  • vmcore ファイルをローカルファイルシステムの /var/crash/ ディレクトリーに保存するには、/etc/kdump.conf ファイルを編集してパスを指定します。

    path /var/crash

    オプション path /var/crash は、kdumpvmcore ファイルを保存するファイルシステムへのパスを表します。/etc/kdump.conf ファイルでダンプターゲットを指定すると、path は指定されたダンプ出力先に対する相対パスになります。

    ダンプターゲットが /etc/kdump.conf ファイルで指定されていない場合には、パス は root ディレクトリーからの絶対パスになります。現在のシステムにマウントされている内容に応じて、ダンプターゲットと調整されるダンプパスが自動的に適用されます。

警告

kdump は、ダンプターゲットが /var/crash にマウントされ、オプションの path/etc/kdump.conf ファイルの /var/crash として設定されていると、vmcore ファイルを /var/crash/var/crash ディレクトリーに保存します。たとえば、以下の例では、ext4 ファイルシステムが /var/crash にすでにマウントされており、 path/var/crash として設定されます。

grep -v ^# etc/kdump.conf | grep -v ^$
ext4 /dev/mapper/vg00-varcrashvol
path /var/crash
core_collector makedumpfile -c --message-level 1 -d 31

そのため、/var/crash/var/crash パスが作成されます。この問題を解決するには、path /var/crash の代わりに path / オプションを使用します。

  • コアダンプを保存するローカルディレクトリーを変更するには、root で、以下のように /etc/kdump.conf 設定ファイルを編集します。

    1. #path /var/crash の行頭にあるハッシュ記号 ("#") を削除します。
    2. 値を対象のディレクトリーパスに置き換えます。以下に例を示します。

      path /usr/local/cores
      重要

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

  • 別のパーティションにファイルを書き込むには、root で、以下のように /etc/kdump.conf 設定ファイルを編集します。

    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
  • NFS プロトコルを使用して、リモートのマシンにダンプを保存するには、以下を行います。

    1. #nfs my.server.com:/export/tmp の行頭にあるハッシュ記号 ("#") を削除します。
    2. 値を、正しいホスト名およびディレクトリーパスに置き換えます。以下は例になります。

      nfs penguin.example.com:/export/cores
  • SSH プロトコルを使用してリモートマシンにダンプを保存するには、以下を行います。

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

      • #sshkey /root/.ssh/kdump_id_rsa の行頭にあるハッシュ記号 ("#") を削除します。
      • 値を、ダンプ先のサーバー上で正しいキーの場所に変更します。以下は例になります。

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

11.3. コアコレクターの設定

kdump サービスは、core_collector を使用して vmcore イメージをキャプチャーします。RHEL では、makedumpfile ユーティリティがデフォルトのコアコレクターです。

makedumpfile は、ダンプファイルのサイズを圧縮し、さまざまなダンプレベルで必要なページのみをコピーするダンププログラムです。

makedumpfile では、ダンプデータの圧縮や、不要なページの削除などを行って、ダンプファイルを縮小しています。最初のカーネルデバッグ情報は、最初のカーネルがメモリーをどのように使用するかを理解するために必要です。これにより、必要なページを検出できます。

構文

core_collector makedumpfile -l --message-level 1 -d 31

オプション

  • -c-l、または -p: -czlib-llzo オプションまたは -p オプションに snappy のいずれかを使用して、各ページでダンプファイル形式を圧縮します。
  • -d (dump_level): ダンプファイルにコピーされないように、ページを除外します。
  • --message-level: メッセージの種類を指定します。このオプションで message_level を指定すると、出力を制限できます。たとえば、message_level に 7 を指定すると、一般的なメッセージとエラーメッセージが出力されます。message_level の上限は 31 です。

前提条件

  • kdump の設定とターゲットの要件をすべて満たしている

手順

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

詳細は以下のようになります。

  • -l には、dump の圧縮ファイル形式を指定します。
  • -d では、ダンプレベルを 31 に指定します。
  • --message-level では、メッセージレベルを 1 に指定します。

また、オプション -c および -p を使用した以下の例を検討してください。

  • -c を使用してダンプファイルを圧縮するには、以下のコマンドを実行します。
core_collector makedumpfile -c -d 31 --message-level 1
  • -p を使用してダンプファイルを圧縮するには、以下のコマンドを実行します。
core_collector makedumpfile -p -d 31 --message-level 1

関連情報

  • makedumpfile(8) の man ページ

11.4. kdump のデフォルト障害応答の設定

デフォルトでは、kdump が設定したターゲットの場所で vmcore ファイルを作成できず、システムが再起動し、プロセス内でダンプが失われます。この場合は、以下の手順を実施します。

前提条件

  • kdump の設定とターゲットの要件をすべて満たしている

手順

  1. root で、/etc/kdump.conf 設定ファイルの #failure_action の行頭にあるハッシュ記号 ("#") を削除します。
  2. 値を任意のアクションに置き換えます。

    failure_action poweroff

11.5. kdump の設定ファイル

kdump カーネルの設定ファイルは /etc/sysconfig/kdump です。このファイルは、kdump カーネルコマンドラインパラメーターを制御します。

ほとんどの設定では、デフォルトオプションを使用します。ただし、シナリオによっては、kdump カーネルの動作を制御するために特定のパラメーターを変更する必要があります。たとえば、kdump kernel コマンドラインを追加するように変更すると、詳細なデバッグ出力が得られます。

本セクションでは、kdumpKDUMP_COMMANDLINE_REMOVE オプションおよび KDUMP_COMMANDLINE_REMOVE オプションの変更方法を説明します。追加の設定オプションの詳細は、Documentation/admin-guide/kernel-parameters.txt または /etc/sysconfig/kdump を参照してください。

  • KDUMP_COMMANDLINE_REMOVE

    現在の kdump コマンドラインから引数を削除します。これにより、kdumpエラーやkdump カーネルブートエラーの原因となるパラメーターが削除されます。このパラメーターは、以前のKDUMP_COMMANDLINEプロセスで解析されたか、/proc/cmdline ファイルから継承された可能性があります。この変数が設定されていない場合は、/proc/cmdline ファイルからすべての値が継承されます。このオプションを設定すると、問題のデバッグに役立つ情報も提供されます。

    特定の引数を削除するには、以下のようにしてKDUMP_COMMANDLINE_REMOVE に追加します。

    KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
  • KDUMP_COMMANDLINE_APPEND

    このオプションは、現在のコマンドラインに引数を追加します。これらの引数は、以前の KDUMP_COMMANDLINE_REMOVE 変数で解析されている可能性があります。

    kdump カーネルの場合は、mcecgroupnumahest_disable などの特定のモジュールを無効にすると、カーネルエラーを防ぐのに役立ちます。これらのモジュールは、kdump 用に予約されているカーネルメモリーの大部分を消費したり、kdump カーネルの起動に失敗する可能性があります。

    kdump カーネルコマンドラインでメモリーcgroupを無効にするには、以下のコマンドを実行します。

    KDUMP_COMMANDLINE_APPEND="cgroup_disable=memory"

関連情報

  • Documentation/admin-guide/kernel-parameters.txt file
  • /etc/sysconfig/kdump ファイル

11.6. kdump サービスの有効化および無効化

システムの起動時に kdump サービスを開始するには、以下の手順を行います。

前提条件

  • kdump の設定とターゲットの要件をすべて満たしている
  • kdump のインストール用のオプションがすべて、要件に応じて設定されている

手順

  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
警告

kptr_restrict=1 をデフォルトとして設定することが推奨されます。kptr_restrict をデフォルトで (1) に設定すると、kdumpctl サービスは、Kernel Address Space Layout (KASLR) が有効または無効であるかに拘らず、クラッシュカーネルを読み込みます。

トラブルシューティングの手順

kptr_restrict が (1) に設定されておらず、KASLR が有効になっている場合は、/proc/kore ファイルの内容がすべてゼロとして生成されます。したがって、kdumpctl サービスは /proc/kcore にアクセスしてクラッシュカーネルを読み込むことができません。

推奨の設定を kptr_restrict=1 のままにするように指定して kexec-kdump-howto.txt ファイルで警告メッセージを表示し、この問題を回避します。

kdumpctl サービスでクラッシュカーネルが読み込まれるようにするには、以下を確認します。

  • sysctl.conf ファイルでのカーネルの kptr_restrict=1 設定

関連情報

11.7. kdump 設定のテスト

以下の手順では、カーネルダンププロセスが動作し、マシンが実稼働環境に入る前に有効であることをテストする方法を説明します。

警告

以下のコマンドでは、カーネルがクラッシュします。以下の手順に従って、アクティブな実稼働システムで不注意に使用しないでください。

手順

  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/) にアドレス-YYYY-MM-DD-HHH:MM:SS/vmcore ファイルが作成されます。

    注記

    設定の妥当性を確認することに加え、このアクションを利用して、代表的な負荷が稼働しているときに、クラッシュダンプが完了するのにかかる時間を記録することができます。

11.8. kexec を使用したカーネルの再起動

kexec システムコールを使用すると現在実行中のカーネルから別のカーネルを読み込んだり、起動したりすることが可能で、カーネル内のブートローダーとして機能します。

kexec ユーティリティーは、kexec システムコールのカーネルおよび initramfs イメージを読み込み、別のカーネルで起動します。

以下の手順では、kexec ユーティリティーを使用して別のカーネルに再起動する時に、kexec システムコールを手動で呼び出す方法を説明します。

手順

  1. kexec ユーティリティーを実行します。

    # kexec -l /boot/vmlinuz-3.10.0-1040.el7.x86_64 --initrd=/boot/initramfs-3.10.0-1040.el7.x86_64.img --reuse-cmdline

    このコマンドは、kexec システムコールのカーネルおよび initramfs イメージを手動で読み込みます。

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

    # reboot

    このコマンドはカーネルを検出し、すべてのサービスをシャットダウンしてから、kexec システムコールを呼び出して直前の手順で指定したカーネルに再起動します。

警告

kexec -3 コマンドを使用してカーネルを再起動すると、システムは、次のカーネルを起動する前に標準のシャットダウンシーケンスを通過しません。そのため、データ損失や応答しないシステムが発生する可能性があります。

11.9. カーネルドライバーが kdump を読み込まないようにする設定

本セクションでは、/etc/sysconfig/kdump 設定ファイルを使用して、kdump カーネルが特定のカーネルドライバーを読み込みないようにする方法を説明します。/etc/sysconfig/kdump ファイルに KDUMP_COMMANDLINE_APPEND= 変数を追加すると、kdump initramfs が指定のカーネルモジュールを読み込まれなくなります。これにより、oom killer などのクラッシュカーネルの障害を防ぐことができます。

以下の設定オプションのいずれかを使用して、KDUMP_COMMANDLINE_APPEND= 変数を追加することができます。

  • rd.driver.blacklist=<modules>
  • modprobe.blacklist=<modules>

手順

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

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

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

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

    KDUMP_COMMANDLINE_APPEND="modprobe.blacklist=emcp modprobe.blacklist=bnx2fc modprobe.blacklist=libfcoe modprobe.blacklist=fcoe"
  3. kdump サービスを再起動します。

    $ systemctl restart kdump

関連情報

  • dracut.cmdline の man ページ

11.10. 暗号化されたディスクがあるシステムでの kdump の実行

LUKS 暗号化パーティションを実行すると、システムで利用可能なメモリーが一定量必要になります。システムが必要なメモリー量を下回ると、cryptsetup ユーティリティーがパーティションのマウントに失敗します。その結果、2 番目のカーネル (キャプチャーカーネル) で、暗号化したターゲットの場所にvmcore ファイルをキャプチャーできませんでした。

kdumpctl estimate を使用すると、kdump に必要なメモリー容量を予測できます。kdumpctl estimate は、Recommended crashkernel の値を出力します。これは、kdumpに必要な推奨メモリーサイズです。

Recommended crashkernel の値は、現在のカーネルサイズ、カーネルモジュール、initramfs、および暗号化したターゲットメモリー要件に基づいて計算されます。

カスタムの crashkernel= を使用している場合は、kdumpctl estimate は、LUKS で暗号化したものに必要なメモリーサイズである LUKS required size 値を出力します。

手順

  1. 次のコマンドを実行して、crashkernel= の推定値を出力します。

    # kdumpctl estimate
    
    Encrypted kdump target requires extra memory, assuming using the keyslot  with minimum memory requirement
       Reserved crashkernel:    256M
       Recommended crashkernel: 652M
    
       Kernel image size:   47M
       Kernel modules size: 8M
       Initramfs size:      20M
       Runtime reservation: 64M
       LUKS required size:  512M
       Large modules: <none>
       WARNING: Current crashkernel size is lower than recommended size 652M.
  2. crashkernel= の値を必要な値まで上げて、必要なメモリーの量を設定します。
  3. システムを再起動します。
注記

それでもkdumpがダンプファイルを暗号化したターゲットに保存できない場合は、必要に応じて crashkernel= を増やしてください。

第12章 Web コンソールで kdump の設定

RHEL 8 Web コンソールで kdump 設定を指定してテストします。

Web コンソールは、Red Hat Enterprise Linux 8 のデフォルトインストールに含まれており、システムの起動時に kdump サービスを有効または無効にできます。さらには、kdump に予約メモリーを設定したり、非圧縮または圧縮の形式で vmcore の保存場所を選択したりすることもできます。

12.1. 関連情報

12.2. Web コンソールで kdump メモリーの使用量およびターゲットの場所を設定

以下の手順は、Red Hat Enterprise Linux Web コンソールインターフェースで Kernel Dump タブを使用して、kdump カーネル用に予約されたメモリー容量を設定する方法を説明します。この手順では、vmcore ダンプファイルのターゲットの場所を指定する方法と、設定をテストする方法を説明します。

手順

  1. Kernel Dump タブを開き、kdump サービスを開始します。
  2. コマンドラインで kdump のメモリー使用量を設定します。
  3. クラッシュダンプの場所 オプションの横にあるリンクをクリックします。

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

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

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

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

      注記

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

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

    Web コンソールテスト kdump config
    警告

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

第13章 サポートしている kdump の設定とダンプ出力先

13.1. kdump メモリー要件

kdump でカーネルクラッシュのダンプをキャプチャーして分析のため保存するには、キャプチャーカーネル用にシステムメモリーの一部を永続的に予約しておく必要があります。予約されている場合、システムメモリーのこの部分はメインカーネルでは使用できません。

メモリー要件は、特定のシステムパラメーターによって異なります。主な要因は、システムのハードウェアアーキテクチャーです。正確なマシンアーキテクチャー (Intel 64 や AMD64 (x86_64) など) を調べ、それを標準出力に出力するには、以下のコマンドを使用します。

$ uname -m

表 10.1 には、利用可能な最新バージョンで kdump のメモリーサイズを自動的に予約する最小メモリー要件一覧が含まれます。システムのアーキテクチャーと利用可能な物理メモリーの合計に応じて、サイズが変更されます。

表13.1 kdump 用に必要な最小予約メモリー

アーキテクチャー使用可能なメモリー最小予約メモリー

AMD64 と Intel 64 (x86_64)

1 GB から 4 GB

160 MB のメモリー

4 GB から 64 GB

192 MB のメモリー

64 GB から 1 TB

256 MB のメモリー

1TB 以上

512 MB のメモリー

64 ビット ARM アーキテクチャー (arm64)

2 GB 以上

448 MB のメモリー

IBM Power Systems (ppc64le)

2 GB から 4 GB

384 MB のメモリー

4 GB から 16 GB

512 MB のメモリー

16 GB から 64 GB

1 GB のメモリー

64 GB から 128 GB

2 GB のメモリー

128 GB 以上

4 GB のメモリー

IBM Z (s390x)

1 GB から 4 GB

160 MB のメモリー

4 GB から 64 GB

192 MB のメモリー

64 GB から 1 TB

256 MB のメモリー

1TB 以上

512 MB のメモリー

多くのシステムでは、kdump は必要なメモリー量を予測して、自動的に予約できます。この動作はデフォルトで有効になっていますが、利用可能な合計メモリーサイズが一定以上搭載されているシステムに限られます。この自動割り当て動作に必要なメモリーサイズはシステムのアーキテクチャーによって異なります。

重要

システムのメモリー合計量に基づく予約メモリーの自動設定は、ベストエフォート予測です。実際に必要なメモリーは、I/O デバイスなどの他の要素により異なる場合があります。メモリーが十分でない場合は、カーネルパニックが発生したときにデバッグカーネルがキャプチャーカーネルとして起動できなくなる可能性があります。この問題を回避するには、クラッシュカーネルメモリーを十分なサイズにします。

13.2. メモリー自動予約の最小しきい値

一部のシステムでは、ブートローダー設定ファイルで crashkernel=auto パラメーターを使用するか、グラフィカル設定ユーティリティーでこのオプションを有効にすることで、kdump 用のメモリーを自動的に割り当てることができます。ただし、この自動予約が機能するには、合計メモリーの特定量のメモリーを利用できる必要があります。必要な容量は、システムのアーキテクチャーによって異なります。

表 10.2 は、自動メモリー割り当てのしきい値の一覧です。システムのメモリーが指定のしきい値よりも小さい場合は、メモリーを手動で設定する必要があります。

表13.2 自動メモリー予約に必要な最小メモリーサイズ

アーキテクチャー必要なメモリー

AMD64 と Intel 64 (x86_64)

2 GB

IBM Power Systems (ppc64le)

2 GB

IBM  Z (s390x)

4 GB

13.3. サポートしている kdump のダンプ出力先

カーネルクラッシュがキャプチャされたら、vmcore ダンプファイルはデバイスに直接書き込むか、ローカルフィアルシステム上でファイルとして保存されるか、ネットワークで送信されます。以下の表に、現在対応のダンプ出力先、または kdumpが明示的に対応していないダンプ出力先の完全な一覧を示します。

Type対応しているダンプ出力先対応していないダンプ出力先

Raw デバイス

ローカルで添付されたすべての raw ディスクとパーティション

 

ローカルファイルシステム

直接接続されているディスクドライブ、ハードウェア RAID 論理ドライブ、LVM デバイス、mdraid アレイ上の ext2ext 3ext4、および xfs ファイルシステム。

auto タイプ (自動ファイルシステム検出) など、この表で明示的にサポート対象とされていないローカルファイルシステム。

リモートディレクトリー

IPv4NFS または SSH プロトコルを使用してアクセスしたリモートディレクトリー。

NFS プロトコルを使用してアクセスした rootfs ファイルシステム上のリモートディレクトリー。

ハードウェアおよびソフトウェアイニシエーター上で iSCSI プロトコルを使用してアクセスするリモートディレクトリー。

be2iscsi ハードウェア上で iSCSI プロトコルを使用してアクセスするリモートディレクトリー。

マルチパスベースのストレージ

 

IPv6 上でアクセスするリモートディレクトリー

 

SMB または CIFS を使ってアクセスするリモートディレクトリー。

 

FCoE (Fibre Channel over Ethernet) プロトコルを使用してアクセスするリモートディレクトリー。

 

ワイヤレスネットワークインターフェースを使ってアクセスするリモートディレクトリー

重要

fadump (firmware assisted dump) を使用して vmcore を取得し、SSH プロトコルまたは NFS プロトコルを使用してリモートマシンに保存すると、ネットワークインターフェースの名前が kdump-<interface-name> に変更になります。名前変更は、<interface-name>*eth#net# などのように一般的な場合に発生します。この問題は、初期 RAM ディスク (initrd) の vmcore 取得スクリプトが、ネットワークインターフェース名に接尾辞 kdump- を追加して、永続的な名前付けを保護するために発生します。同じ initrd が通常の起動にも使用されるため、実稼働環境のカーネルのインターフェース名も変更されます。

13.4. 対応している kdump のフィルターレベル

ダンプファイルのサイズを縮小するために、kdumpmakedumpfile コアコレクターを使用してデータを圧縮し、必要に応じて不要な情報を省略します。以下の表に、makedumpfile ユーティリティーで現在対応しているフィルターレベルの完全な一覧を示します。

オプション説明

1

ゼロページ

2

キャッシュページ

4

キャッシュプライベート

8

ユーザーページ

16

フリーページ

注記

makedumpfile コマンドは、透過的な大規模ページおよび hugetlbfs ページの削除に対応しています。これらのタイプの hugepages User Page の両方を考えて、-8 レベルを使用して削除します。

13.5. 対応しているデフォルトの障害応答

デフォルトでは、kdump がコアダンプを作成できない場合、オペレーティングシステムが再起動します。ただし、コアダンプをプライマリーターゲットに保存できない場合は、kdump が別の操作を実行するように設定できます。次の表は、現在対応しているすべてのデフォルトアクションの一覧です。

オプション説明

dump_to_rootfs

root ファイルシステムにコアダンプの保存を試行します。ネットワーク上のダンプ出力先と併用する場合に特に便利なオプションです。ネットワーク上のダンプ出力先にアクセスできない場合、ローカルにコアダンプを保存するよう kdump の設定を行います。システムは、後で再起動します。

reboot

システムを再起動します。コアダンプは失われます。

halt

システムを停止します。コアダンプは失われます。

poweroff

システムの電源を切ります。コアダンプは失われます。

shell

initramfs 内から shell セッションを実行して、ユーザーが手動でコアダンプを記録できるようにします。

final_action

kdump の成功後、または shell または dump_to_rootfs の失敗アクションの完了時に、reboothalt および poweroff アクションなどの追加の操作を有効にします。デフォルトの final_action オプションは reboot です。

13.6. final_action パラメーターの使用

final_action パラメーターを使用すると、kdump の成功後、または、 shell または dump_to_rootfs を使用した無効な failure_response メカニズムの完了時に、reboothalt および poweroff アクションなど、特定の操作を追加で使用できます。final_action オプションを指定しない場合には、この値はデフォルトで reboot になります。

手順

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

    final_action <reboot | halt | poweroff>
  2. kdump サービスを再起動します。

    kdumpctl restart

13.7. kdumpサイズの見積もり

kdump 環境のプランニングや構築の際には、ダンプファイルに必要な容量を把握してから作成する必要があります。

makedumpfile --mem-usage コマンドは、除外可能なページに関する有用なレポートを生成し、割り当てるダンプレベルを決定するために使用できます。システムが代表的な負荷においてこのコマンドを実行します。それ以外の場合、makedumpfile --mem-usage は実稼働環境で想定されている値より小さい値を返します。

[root@hostname ~]# makedumpfile --mem-usage /proc/kcore

TYPE            PAGES                   EXCLUDABLE      DESCRIPTION
----------------------------------------------------------------------
ZERO            501635                  yes             Pages filled with zero
CACHE           51657                   yes             Cache pages
CACHE_PRIVATE   5442                    yes             Cache pages + private
USER            16301                   yes             User process pages
FREE            77738211                yes             Free pages
KERN_DATA       1333192                 no              Dumpable kernel data
重要

makedumpfile --mem-usage コマンドは、ページ単位の報告を行います。つまり、カーネルページサイズに対して、使用中のメモリーのサイズを計算する必要があります。デフォルトでは、Red Hat Enterprise Linux カーネルは、AMD64 および Intel 64 アーキテクチャーに 4 KB のサイズのページを使用し、IBM POWER アーキテクチャーには 64 KB のサイズのページを使用します。

第14章 ファームウェア支援ダンプの仕組み

ファームウェア支援ダンプ (fadump) は、IBM POWER システムの kdump メカニズムの代わりに提供されるダンプ取得メカニズムです。kexec および kdump のメカニズムは、AMD64 および Intel 64 システムでコアダンプを取得する際に役立ちます。ただし、最小システムやメインフレームコンピューターなどの一部のハードウェアでは、オンボードファームウェアを活用してメモリー領域を分離して、クラッシュ分析に重要なデータが誤って上書きされないようにします。本セクションでは、fadump メカニズムと RHEL との統合方法を説明します。fadump ユーティリティーは、IBM POWER システムで拡張されたダンプ機能に対して最適化されています。

14.1. IBM PowerPC ハードウェアにおけるファームウェア支援ダンプ

fadump ユーティリティーは、PCI デバイスおよび I/O デバイスが搭載され、完全にリセットされたシステムから vmcore ファイルをキャプチャーします。この仕組みでは、クラッシュするとファームウェアを使用してメモリー領域を保存し、kdump ユーザー空間スクリプトをもう一度使用して vmcore ファイルを保存します。このメモリー領域には、ブートメモリー、システムレジスター、およびハードウェアのページテーブルエントリー (PTE) を除く、すべてのシステムメモリーコンテンツが含まれます。

fadump メカニズムは、パーティションを再起動し、新規カーネルを使用して以前のカーネルクラッシュからのデータをダンプすることで従来のダンプタイプに比べて信頼性が向上されています。fadump には、IBM POWER6 プロセッサーベースまたはそれ以降バージョンのハードウェアプラットフォームが必要です。

PowerPC 固有のハードウェアのリセット方法など、fadump メカニズムの詳細は、/usr/share/doc/kexec-tools/fadump-howto.txt ファイルを参照してください。

注記

保持されないメモリー領域はブートメモリーと呼ばれており、この領域はクラッシュ後にカーネルを正常に起動するのに必要なメモリー容量です。デフォルトのブートメモリーサイズは、256 MB または全システム RAM の 5% のいずれか大きい方です。

kexec で開始されたイベントとは異なり、fadump メカニズムでは実稼働用のカーネルを使用してクラッシュダンプを復元します。PowerPC ハードウェアは、クラッシュ後の起動時に、デバイスノード /proc/device-tree/rtas/ibm.kernel-dumpproc ファイルシステム (procfs) で利用できるようにします。fadump-aware kdump スクリプトでは、保存された vmcore があるかを確認してから、システムの再起動を正常に完了させます。

14.2. ファームウェア支援ダンプメカニズムの有効化

IBM POWER システムのクラッシュダンプ機能は、ファームウェア支援ダンプ (fadump) メカニズムを有効にすることで強化できます。

手順

  1. 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/grubGRUB_CMDLINE_LINUXcrashkernel=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= 引数で指定する値を増やします。この場合は、トライアンドエラーが必要になることがあります。

14.3. IBM Z ハードウェアにおけるファームウェア支援ダンプの仕組み

IBM Z システムは、以下のファームウェア支援ダンプメカニズムをサポートします。

  • スタンドアロンダンプ (sadump)
  • VMDUMP

IBM Z システムでは、kdump インフラストラクチャーはサポート対象で、使用されています。ただし、IBM Z にファームウェア支援ダンプ (fadump) を使用すると、さまざまな利点が得られます。

  • sadump メカニズムはシステムコンソールで開始および制御され、IPL 起動可能なデバイスに保存されます。
  • VMDUMP メカニズムは sadump に似ています。このツールもシステムコンソールから開始しますが、ハードウェアから生成されたダンプを取得して解析用にシステムにコピーします。
  • (他のハードウェアベースのダンプメカニズムと同様に) これらの手法では、(kdump サービスが開始される前の) 起動初期段階におけるマシンの状態をキャプチャーできます。
  • VMDUMP には、ハードウェアからコピーしたダンプファイルを Red Hat Enterprise Linux システムに格納する仕組みがありますが、IBM Z ハードウェアコンソールから、VMDUMP の設定および制御が管理されます。

IBM は、 sadump について「Stand-alone dump program 記事で 、VMDUMP について Creating dumps on z/VM with VMDUMP 記事で詳説しています。

また、IBM は、Using the Dump Tools on Red Hat Enterprise Linux 7.4 記事で Red Hat Linux Enterprise Linux 7 でダンプツールを使用するための一連のドキュメントも用意しています。

14.4. Fujitsu PRIMEQUEST システムにおける sadump の使用

Fujitsu sadump メカニズムは、kdump が正常に完了しないイベントで fallback ダンプキャプチャーを提供するように設計されています。sadump メカニズムは、システムの ManageMent Board (MMB) インターフェースから手動で呼び出します。MMB を使用して、Intel 64 サーバーまたは AMD 64 サーバーのように kdump を設定し、sadump の有効化手順を追加で実施します。

手順

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

    kernel.panic=0
    kernel.unknown_nmi_panic=1
    警告

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

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

    failure_action shell

関連情報

  • FUJITSU Server PRIMEQUEST 2000 Series インストールマニュアル

第15章 コアダンプの分析

システムクラッシュの原因を確認するには、crash ユーティリティーを使用します。これにより、GDB (GNU Debugger) と非常によく似たインタラクティブなプロンプトを利用できます。このユーティリティーでは、kdumpnetdumpdiskdump、またはxendump によって作成されたコアダンプ、実行中の Linux システムなどをインタラクティブに分析できます。または、Kernel Oops Analyzer または Kdump Helper ツールを使用する選択肢もあります。

15.1. crash ユーティリティーのインストール

次の手順では、crash 分析ツールの方法を説明します。

手順

  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

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

関連情報

15.2. crash ユーティリティーの終了

以下の手順では、システムクラッシュの原因を分析するために crash ユーティリティーを起動する方法を説明します。

前提条件

  • 現在実行しているカーネルを特定します (4.18.0-5.el8.x86_64 など)。

手順

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

      例15.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 を使用します。

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

    crash> exit
    ~]#
注記

crash コマンドは、ライブシステムをデバッグする強力なツールとして使用することもできます。ただし、システムを破損しないように注意してください。

15.3. crash ユーティリティーのさまざまなインジケーターの表示

以下の手順では、crash ユーティリティーを使用して、カーネルメッセージバッファー、バックトレース、プロセスステータス、仮想メモリー情報、オープンファイルなど、さまざまなインジケーターを表示する方法を説明します。

メッセージバッファーの表示
  • カーネルメッセージバッファーを表示するには、以下の例で示されているように対話式プロンプトで log コマンドを実行します。
crash> log
... several lines omitted ...
EIP: 0060:[<c068124f>] EFLAGS: 00010096 CPU: 2
EIP is at sysrq_handle_crash+0xf/0x20
EAX: 00000063 EBX: 00000063 ECX: c09e1c8c EDX: 00000000
ESI: c0a09ca0 EDI: 00000286 EBP: 00000000 ESP: ef4dbf24
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process bash (pid: 5591, ti=ef4da000 task=f196d560 task.ti=ef4da000)
Stack:
 c068146b c0960891 c0968653 00000003 00000000 00000002 efade5c0 c06814d0
<0> fffffffb c068150f b7776000 f2600c40 c0569ec4 ef4dbf9c 00000002 b7776000
<0> efade5c0 00000002 b7776000 c0569e60 c051de50 ef4dbf9c f196d560 ef4dbfb4
Call Trace:
 [<c068146b>] ? __handle_sysrq+0xfb/0x160
 [<c06814d0>] ? write_sysrq_trigger+0x0/0x50
 [<c068150f>] ? write_sysrq_trigger+0x3f/0x50
 [<c0569ec4>] ? proc_reg_write+0x64/0xa0
 [<c0569e60>] ? proc_reg_write+0x0/0xa0
 [<c051de50>] ? vfs_write+0xa0/0x190
 [<c051e8d1>] ? sys_write+0x41/0x70
 [<c0409adc>] ? syscall_call+0x7/0xb
Code: a0 c0 01 0f b6 41 03 19 d2 f7 d2 83 e2 03 83 e0 cf c1 e2 04 09 d0 88 41 03 f3 c3 90 c7 05 c8 1b 9e c0 01 00 00 00 0f ae f8 89 f6 <c6> 05 00 00 00 00 01 c3 89 f6 8d bc 27 00 00 00 00 8d 50 d0 83
EIP: [<c068124f>] sysrq_handle_crash+0xf/0x20 SS:ESP 0068:ef4dbf24
CR2: 0000000000000000

コマンドの使用の詳細は help log を実行します。

注記

カーネルメッセージバッファーには、システムクラッシュに関する最も重要な情報が含まれています。したがって、これは常に最初に vmcore-dmesg.txt ファイルにダンプされます。これは、たとえば、ターゲットの場所にスペースがないために、 vmcore ファイル全体の取得試行に失敗するときに便利です。デフォルトでは、vmcore-dmesg.txt/var/pkcs/directory/ あります。

バックトレースの表示
  • カーネルスタックトレースを表示するには、bt コマンドを使用します。
crash> bt
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
 #0 [ef4dbdcc] crash_kexec at c0494922
 #1 [ef4dbe20] oops_end at c080e402
 #2 [ef4dbe34] no_context at c043089d
 #3 [ef4dbe58] bad_area at c0430b26
 #4 [ef4dbe6c] do_page_fault at c080fb9b
 #5 [ef4dbee4] error_code (via page_fault) at c080d809
    EAX: 00000063  EBX: 00000063  ECX: c09e1c8c  EDX: 00000000  EBP: 00000000
    DS:  007b      ESI: c0a09ca0  ES:  007b      EDI: 00000286  GS:  00e0
    CS:  0060      EIP: c068124f  ERR: ffffffff  EFLAGS: 00010096
 #6 [ef4dbf18] sysrq_handle_crash at c068124f
 #7 [ef4dbf24] __handle_sysrq at c0681469
 #8 [ef4dbf48] write_sysrq_trigger at c068150a
 #9 [ef4dbf54] proc_reg_write at c0569ec2
#10 [ef4dbf74] vfs_write at c051de4e
#11 [ef4dbf94] sys_write at c051e8cc
#12 [ef4dbfb0] system_call at c0409ad5
    EAX: ffffffda  EBX: 00000001  ECX: b7776000  EDX: 00000002
    DS:  007b      ESI: 00000002  ES:  007b      EDI: b7776000
    SS:  007b      ESP: bfcb2088  EBP: bfcb20b4  GS:  0033
    CS:  0073      EIP: 00edc416  ERR: 00000004  EFLAGS: 00000246

bt <pid> を入力して特定のプロセスのバックトレースを表示するか、help bt を実行して、bt の使用についての詳細を表示します。

プロセスの状態表示
  • システム内のプロセスの状態を表示するには、ps コマンドを使用します。
crash> ps
   PID    PPID  CPU   TASK    ST  %MEM     VSZ    RSS  COMM
>     0      0   0  c09dc560  RU   0.0       0      0  [swapper]
>     0      0   1  f7072030  RU   0.0       0      0  [swapper]
      0      0   2  f70a3a90  RU   0.0       0      0  [swapper]
>     0      0   3  f70ac560  RU   0.0       0      0  [swapper]
      1      0   1  f705ba90  IN   0.0    2828   1424  init
... several lines omitted ...
   5566      1   1  f2592560  IN   0.0   12876    784  auditd
   5567      1   2  ef427560  IN   0.0   12876    784  auditd
   5587   5132   0  f196d030  IN   0.0   11064   3184  sshd
>  5591   5587   2  f196d560  RU   0.0    5084   1648  bash

ps <pid> を使用して、単一プロセスのステータスを表示します。ps の詳細な使用方法は、help ps を使用します。

仮想メモリー情報の表示
  • 基本的な仮想メモリー情報を表示するには、対話式プロンプトで vm コマンドを入力します。
crash> vm
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
   MM       PGD      RSS    TOTAL_VM
f19b5900  ef9c6000  1648k    5084k
  VMA       START      END    FLAGS  FILE
f1bb0310    242000    260000 8000875  /lib/ld-2.12.so
f26af0b8    260000    261000 8100871  /lib/ld-2.12.so
efbc275c    261000    262000 8100873  /lib/ld-2.12.so
efbc2a18    268000    3ed000 8000075  /lib/libc-2.12.so
efbc23d8    3ed000    3ee000 8000070  /lib/libc-2.12.so
efbc2888    3ee000    3f0000 8100071  /lib/libc-2.12.so
efbc2cd4    3f0000    3f1000 8100073  /lib/libc-2.12.so
efbc243c    3f1000    3f4000 100073
efbc28ec    3f6000    3f9000 8000075  /lib/libdl-2.12.so
efbc2568    3f9000    3fa000 8100071  /lib/libdl-2.12.so
efbc2f2c    3fa000    3fb000 8100073  /lib/libdl-2.12.so
f26af888    7e6000    7fc000 8000075  /lib/libtinfo.so.5.7
f26aff2c    7fc000    7ff000 8100073  /lib/libtinfo.so.5.7
efbc211c    d83000    d8f000 8000075  /lib/libnss_files-2.12.so
efbc2504    d8f000    d90000 8100071  /lib/libnss_files-2.12.so
efbc2950    d90000    d91000 8100073  /lib/libnss_files-2.12.so
f26afe00    edc000    edd000 4040075
f1bb0a18   8047000   8118000 8001875  /bin/bash
f1bb01e4   8118000   811d000 8101873  /bin/bash
f1bb0c70   811d000   8122000 100073
f26afae0   9fd9000   9ffa000 100073
... several lines omitted ...

vm <pid> を実行して、1 つのプロセスの情報を表示するか、help vm を実行して、vm の使用方法を表示します。

オープンファイルの表示
  • オープンファイルの情報を表示するには、files コマンドを実行します。
crash> files
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
ROOT: /    CWD: /root
 FD    FILE     DENTRY    INODE    TYPE  PATH
  0  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
  1  efade5c0  eee14090  f00431d4  REG   /proc/sysrq-trigger
  2  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
 10  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
255  f734f640  eedc2c6c  eecd6048  CHR   /pts/0

files <pid> を実行して、選択した 1 つのプロセスによって開かれたファイルを表示するか、help files を実行して、files の使用方法を表示します。

15.4. Kernel Oops Analyzer の使用

Kernel Oops Analyzer ツールでは、ナレッジベースの既知の問題で oops メッセージを比較することでクラッシュダンプを分析します。

前提条件

  • oops メッセージのセキュリティーを保護し、Kernel Oops Analyzer にフィードしている。

手順

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

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

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

15.5. Kdump Helper ツール

Kdump ヘルパーツールは、提供された情報を使用してkdumpを設定するのに役立ちます。Kdump Helper は、ユーザーの設定に基づいて設定スクリプトを生成します。サーバーでスクリプトを開始して実行すると、kdump サービスが設定されます。

関連情報

第16章 early kdump を使用した起動時間クラッシュの取得

システム管理者は、kdump サービスの early kdump サポートを使用して、起動プロセスの初期段階でクラッシュカーネルの vmcore ファイルを取得できます。本セクションは、early kdump の概要、設定方法、およびこのメカニズムのステータスを確認する方法を説明します。

16.1. early kdump の概要

kdump サービスが起動していないと、起動段階でカーネルがクラッシュし、クラッシュしたカーネルメモリーの内容を取得して保存できません。そのため、トラブルシューティングの重要な情報は失われます。

この問題を対処するために、RHEL 8 では、early kdump 機能が kdump サービスの一部として導入されました。

16.2. early kdump の有効化

本セクションでは、early kdump 機能を有効にして、起動初期のカーネルクラッシュに関する情報が失われるリスクをなくす方法を説明します。

前提条件

  • アクティブな Red Hat Enterprise Linux サブスクリプション
  • システムの CPU アーキテクチャー用の kexec-tools パッケージを含むリポジトリー
  • kdump の設定とターゲットの要件を満たしている

手順

  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

関連情報

第17章 カーネルライブパッチでパッチの適用

Red Hat Enterprise Linux カーネルのライブパッチソリューションを使用して、システムの再起動またはプロセスの再起動を行わずに、実行中のカーネルにパッチを当てることができます。

このソリューションでは、システム管理者は以下を行うことができます。

  • 重大なセキュリティーパッチをカーネルに即座に適用することが可能。
  • 長時間実行しているタスクの完了、ユーザーのログオフ、スケジュールダウンタイムを待つ必要がない。
  • システムのアップタイムをより制御し、セキュリティーや安定性を犠牲にしない。

重要な、重要なすべての CVE は、カーネルライブパッチソリューションで解決されるわけではありません。この目的は、セキュリティー関連パッチに必要な再起動を減らすことであり、完全になくすことではありません。ライブパッチの範囲の詳細は、「RHEL 7 はライブカーネルパッチ (kpatch) をサポートしていますか?」 を参照してください。

警告

カーネルのライブマイグレーションパッチと、その他のカーネルサブコンポーネントとの間に、いくらか非互換性が存在します。カーネルのライブパッチを使用する前に、kpatch の制限 を慎重に確認してください。

17.1. kpatch の制限

  • kpatch 機能は、汎用のカーネルアップグレードメカニズムではありません。システムをすぐに再起動できない場合など、単純なセキュリティーおよびバグ修正の更新を適用する場合に使用します。
  • パッチの読み込み中または読み込み後は、SystemTap ツールまたは kprobe ツールを使用しないでください。このようなプローブが削除されるまでは、パッチが適用できなくなる可能性があります。

17.2. サードパーティーのライブパッチサポート

kpatch ユーティリティーは、Red Hat リポジトリー提供の RPM モジュールを含む、Red Hat がサポートする唯一のカーネルライブパッチユーティリティーです。Red Hat は、Red Hat 提供でないライブカーネルパッチはサポートしません。

サードパーティーのライブパッチで発生する問題に対応する必要がある場合、Red Hat では、原因発見を必要とする調査のアウトセットで、ライブパッチベンダーにケースを開くことを奨していますこれにより、ベンダーが許可すれば、ソースコードの供給が可能になり、Red Hat サポートに調査を依頼する前に、サポート組織への原因追及を支援することがになります。

サードパーティーのライブパッチを実行しているシステムの場合、Red Hat は、Red Hat が同梱し、サポートしているソフトウェアの複製を求める権利を有します。これが可能でない場合、Red Hat は、同じ動作が発生するかどうかを確認するために、ライブパッチを適用せずに、お使いのテスト環境で同じようなシステムとワークロードの展開を求めます。

サードパーティソフトウェアサポートポリシーの詳細は、「Red Hat グローバルサポートサービスは、サードパーティーのソフトウェア、ドライバー、そして認定されていないハードウェアおよびハイパーバイザー、もしくはゲストのオペレーティングシステムについてどのようなサポートを提供していますか?」を参照してください。

17.3. カーネルライブパッチへのアクセス

ライブのカーネルパッチ機能は、RPM パッケージとして提供されるカーネルモジュール (kmod) として実装されます。

すべてのお客様は、通常のチャンネルから提供されるカーネルライブパッチにアクセスできます。ただし、延長サポートサービスにサブスクライブしていないお客様は、次のマイナーリリースが利用可能になると、現行のマイナーリリースに対する新しいパッチへのアクセスを失うことになります。たとえば、標準のサブスクリプションを購入しているお客様は、RHEL 8.3 カーネルがリリースされるまで RHEL 8.2 カーネルのライブパッチのみを行うことができます。

17.4. カーネルライブパッチのコンポーネント

カーネルのライブパッチのコンポーネントは、以下のようになります。

カーネルパッチモジュール

  • カーネルライブパッチの配信メカニズム
  • パッチが適用されるカーネル用に構築したカーネルモジュール。
  • パッチモジュールには、カーネルに必要な修正のコードが含まれます。
  • パッチモジュールは、kpatch カーネルサブシステムで登録し、置き換えられるオリジナル機能の情報を提供します。また、置換される機能に一致するポインターも含まれます。カーネルパッチモジュールは RPM として提供されます。
  • 命名規則は、kpatch_<kernel version>_<kpatch version>_<kpatch release> です。名前の「kernel version」部分の ドット は、アンダースコア に置き換えます。
kpatch ユーティリティー
パッチモジュールを管理するためのコマンドラインユーティリティー。
kpatch サービス
multiuser.target で必要な systemd サービス。このターゲットは、システムの起動時にカーネルパッチをロードします。
kpatch-dnf パッケージ
RPM パッケージ形式で配信される DNF プラグイン。このプラグインは、カーネルライブパッチへの自動サブスクリプションを管理します。

17.5. カーネルライブパッチの仕組み

kpatch カーネルパッチソリューションは、livepatch カーネルサブシステムを使用して、古い機能の出力先を新しい機能に変更します。ライブカーネルパッチがシステムに適用されると、以下が発生します。

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

図17.1 カーネルライブパッチの仕組み

rhel kpatch の概要

17.6. 現在インストールされているカーネルをライブパッチストリームにサブスクライブする手順

カーネルパッチモジュールは RPM パッケージに含まれ、パッチが適用されたカーネルバージョンに固有のものとなります。各 RPM パッケージは、徐々に蓄積されていきます。

以下の手順では、指定のカーネルに対して、今後の累積パッチ更新をすべてサブスクライブする方法を説明します。ライブパッチは累積的であるため、特定のカーネルにデプロイされている個々のパッチを選択できません。

警告

Red Hat は、Red Hat がサポートするシステムに適用されたサードパーティーのライブパッチをサポートしません。

前提条件

  • root 権限

手順

  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 パッケージの最新の修正でパッチが当てられています。

関連情報

17.7. ライブパッチストリームに新しいカーネルを自動的にサブスクライブする手順

kpatch-dnf DNF プラグインを使用して、カーネルパッチモジュール (別称 カーネルライブパッチ) が提供する修正にシステムをサブスクライブできます。このプラグインは、現在システムが使用するカーネルと、今後インストールされる カーネルの 自動 サブスクリプションを有効にします。

前提条件

  • root 権限

手順

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

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

    # kpatch list
    Loaded patch modules:
    kpatch_4_18_0_240_10_1_0_1 [enabled]
    
    Installed patch modules:
    kpatch_4_18_0_240_10_1_0_1 (4.18.0-240.10.1.el8_3.x86_64)
    kpatch_4_18_0_240_15_1_0_2 (4.18.0-240.15.1.el8_3.x86_64)

    この出力から、実行中のカーネルとインストールされている他のカーネル両方に kpatch-patch-4_18_0-240_10_1-0-1.rpmkpatch-patch-4_18_0-240_15_1-0-1.rpm パッケージそれぞれからの修正が適用されたことが分かります。

関連情報

17.8. カーネルパッチモジュールの更新

カーネルパッチモジュールが配信され、RPM パッケージを通じて適用されているため、累計のカーネルパッチモジュール更新は、他の RPM パッケージの更新と似ています。

前提条件

手順

  • 現在のカーネルの新しい累積バージョンを更新します。

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

    上記のコマンドは、現在実行中のカーネルに利用可能な更新を自動的にインストールし、適用します。これには、新たにリリースされた累計なライブパッチが含まれます。

  • もしくは、インストールしたすべてのカーネルパッチモジュールを更新します。

    # yum update "kpatch-patch"
注記

システムが同じカーネルで再起動すると、kpatch.service systemd サービスにより、カーネルが自動的に再適用されます。

関連情報

17.9. ライブパッチパッケージの削除

以下の手順は、ライブパッチパッケージを削除して、Red Hat Enterprise Linux カーネルのライブパッチソリューションを無効にする方法を説明します。

前提条件

  • root 権限
  • ライブパッチパッケージがインストールされている。

手順

  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:

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

重要

現在、Red Hat はシステムの再起動なしで、ライブパッチを元に戻すことはサポートしていません。ご不明な点がございましたら、サポートチームまでお問い合わせください。

関連情報

17.10. カーネルパッチモジュールのアンインストール

以下の手順では、Red Hat Enterprise Linux カーネルライブパッチソリューションが、後続のブートでカーネルパッチモジュールを適用しないようにする方法を説明します。

前提条件

  • root 権限
  • ライブパッチパッケージがインストールされている。
  • カーネルパッチモジュールがインストールされ、ロードされている。

手順

  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:
    …​

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

重要

現在、Red Hat はシステムの再起動なしで、ライブパッチを元に戻すことはサポートしていません。ご不明な点がございましたら、サポートチームまでお問い合わせください。

関連情報

  • kpatch(1)マニュアルページ

17.11. kpatch.service の無効化

以下の手順では、Red Hat Enterprise Linux カーネルライブパッチソリューションが、後続のブートでカーネルパッチモジュールをグローバルに適用しないようにする方法を説明します。

前提条件

  • root 権限
  • ライブパッチパッケージがインストールされている。
  • カーネルパッチモジュールがインストールされ、ロードされている。

手順

  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)

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

重要

現在、Red Hat はシステムの再起動なしで、ライブパッチを元に戻すことはサポートしていません。ご不明な点がございましたら、サポートチームまでお問い合わせください。

関連情報

第18章 アプリケーションの制限の設定

コントロールグループ (cgroup) のカーネル機能を使用して、プロセスのハードウェアリソースの制限や優先順位を設定したりまたは分離できます。これにより、アプリケーションのリソース使用状況をより詳細に制御して、効率的に使用できます。

18.1. コントロールグループについて

コントロールグループは、プロセスを階層的に順序付けされた cgroups グループに編成できる Linux カーネル機能です。階層 (コントロールグループツリー) は、cgroups 仮想ファイルシステムに構造を提供して定義されます。デフォルトでは /sys/fs/cgroup ディレクトリーにマウントされます。これは、/sys/fs/cgroup のサブディレクトリーを作成および削除することで手動で行います。systemd システムおよびサービスマネージャーを使用することも可能です。

リソースコントローラー (カーネルコンポーネント) は、これらのプロセスのシステムリソース (CPU 時間、メモリー、ネットワーク帯域幅、各種組み合わせなど) を制限、優先順位付け、または割り当てることで cgroup 内のプロセスの動作を変更します。

cgroups に追加された値はプロセスアグリゲーションで、アプリケーションとユーザー間のハードウェアリソースの分割を可能にします。その結果、ユーザー環境の全体的な効率、安定性、およびセキュリティーが向上します。

コントロールグループ 1

コントロールグループバージョン 1 (cgroups-v1) はリソースごとのコントローラー階層を提供します。これは、CPU、メモリー、I/O などの各リソースに、独自のコントロールグループ階層があることを意味します。あるコントローラーが、各リソースの管理において別のものと連携できるように、別のコントロールグループ階層を組み合わせることができます。ただし、2 つのコントローラーは異なるプロセス階層に属する可能性があり、適切な調整はできません。

cgroups-v1 コントローラーは、長期間に渡って開発されているため、制御ファイルの動作と命名は均一ではありません。

コントロールグループ 2

階層の柔軟性から生じるコントローラー連携の問題は、control groups version 2 の発展につながっていました。

Control groups version 2 (cgroups-v2) では、すべてのリソースコントロールがマウントされることに対して単一のコントロールグループ階層を指定します。

コントロールファイルの動作と命名は、さまざまなコントローラーにおいて一貫性があります。

警告

RHEL 8 では、限られた数のリソースコントローラーを持つテクノロジープレビューとして cgroups-v2 を利用できます。関連するリソースコントローラーの詳細は、cgroups-v2 release noteを参照してください。

このサブセクションは、Devconf.cz 2019 プレゼンテーションにを基にしています。[1]

18.2. Linux カーネルリソースコントローラーとは

コントロールグループの機能は、カーネルリソースコントローラーで有効化します。RHEL 8 は、コントロールグループバージョン 1 (cgroups-v1) および コントロールグループバージョン 2 (cgroups-v2) のさまざまなコントローラーをサポートします。

コントロールグループサブシステムとも呼ばれるリソースコントローラーは、1 つのリソース (CPU 時間、メモリー、ネットワーク帯域幅、ディスク I/O など)を表すカーネルサブシステムです。Linux カーネルは、systemd システムおよびサービスマネージャーが自動的にマウントされるリソースコントローラーの範囲を指定します。/proc/cgroups エントリーで現在マウントされているリソースコントローラーの一覧を検索します。

cgroups-v1 では、以下のコントローラーを使用できます。

  • blkio - ブロックデバイスへの入出力アクセスに制限を設定できます。
  • cpu - コントロールグループのタスクに対して、Completely Fair Scheduler (CFS) スケジューラーのパラメーターを調整できます。これは、同じマウントで cpuacct コントローラーとともにマウントされます。
  • cpuacct - コントロールグループ内のタスクが使用する CPU リソースに関する自動レポートを作成します。これは、同じマウント上の cpu コントローラーとともにマウントされます。
  • cpuset - コントロールグループタスクが CPU の特定のサブセットでのみ実行されるように制限したり、指定メモリーノードでのみメモリーを使用できるようにタスクに指示したりできます。
  • デバイス - コントロールグループのタスクに関してデバイスへのアクセスを制御できます。
  • freezer - コントロールグループのタスクを一時停止または再開するのに使用できます。
  • memory - コントロールグループ内のタスクでメモリー使用を設定し、そのタスクによって使用されるメモリーリソースに関する自動レポートを生成するのに使用できます。
  • net_cls - 特定のコントロールグループタスクから発信されたパケットを識別できるようにするために Linux トラフィックコントローラー (tc コマンド) を有効にするクラス識別子 (classic) でネットワークパケットをタグ付けします。net_cls のサブシステム net_ filter (iptables) でも、このタグを使用して、そのようなパケットに対するアクションを実行することができます。net_filter は、ファイアウォール識別子 (fwid) でネットワークソケットをタグ付けします。これにより、(iptables コマンドで) Linux ファイアウォールが、特定のコントールグループタスクから発信されたパケットを識別できるようになります。
  • net_prio - ネットワークトラフィックの優先度を設定します。
  • pids - コントロールグループ内の多数のプロセスと子に制限を設定できます。
  • perf_event - perf パフォーマンス監視およびレポートユーティリティーにより、監視するタスクをグループ化できます。
  • rdma - コントロールグループ内のリモートダイレクトメモリーアクセス/InfiniB 固有のリソースに制限を設定できます。
  • hugetlb - コントロールグループ内のタスクで大容量の仮想メモリーページの使用を制限するのに使用できます。

cgroups-v2 では、次のモードを使用できます。

  • io - cgroups-v1blkio へのフォローアップ
  • memory - cgroups-v1メモリー へのフォローアップ
  • pids - cgroups-v1pids と同じ
  • RDMA - cgroups-v1rdma と同じ
  • cpu - cpu - cgroups-v1cpucpuacct へのフォローアップ
  • cpuset - コア機能 (cpus{,.effective}, mems{,.effective}) のみを新しいパーティション機能でサポートします。
  • perf_event - サポートは継承され、明示的な制御ファイルはありません。perf コマンドに v2 cgroup をパラメーターとして指定でき、対象の cgroup 内のタスクすべてがプロファイリングされます。
重要

リソースコントローラーは、cgroups-v1 階層または cgroups-v 2 階層のいずれかで使用できますが、両方を同時に使用することはできません。

関連情報

  • cgroups(7)マニュアルページ
  • usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/ディレクトリのドキュメント。

18.3. 名前空間とは

名前空間は、ソフトウェアオブジェクトを整理および特定するための最も重要な方法の 1 つです。

名前空間は、グローバルシステムリソース (マウントポイント、ネットワークデバイス、ホスト名など) を抽象化してラップすることで、グローバルリソースごとに分離されたインスタンスを含む対象の名前空間にプロセスを表示させることができます。名前空間を使用する最も一般的なテクノロジーの 1 つとしてコンテナーが挙げられます。

特定のグローバルリソースへの変更は、その名前空間のプロセスにのみ表示され、残りのシステムまたは他の名前空間には影響しません。

プロセスがどの名前空間に所属するかを確認するには、/proc/<PID>/ns/ ディレクトリーのシンボリックリンクを確認します。

以下の表は、分離されるサポート対象の名前空間およびリソースを示しています。

名前空間分離

Mount

マウントポイント

UTS

ホスト名および NIS ドメイン名

IPC

System V IPC、POSIX メッセージキュー

PID

プロセス ID

Network

ネットワークデバイス、スタック、ポートなど。

User

ユーザーおよびグループ ID

Control groups

コントロールグループの root ディレクトリー

関連情報

18.4. cgroups-v1 を使用したアプリケーションへの CPU 制限の設定

アプリケーションが CPU 時間を過剰に消費すると、環境の全体的な健全性に悪影響を及ぼす可能性があります。/sys/fs/ 仮想ファイルシステムを使用して、コントロールグループバージョン 1 (cgroups-v1) を使用してアプリケーションへの CPU 制限を設定します。

前提条件

  • CPU 消費を制限するアプリケーション。
  • 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)
    cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpu,cpuacct)
    cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
    cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)
    ...

手順

  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.usagecpu.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] Linux Control Group v2 - An Introduction, Devconf.cz 2019 presentation by Waiman Long

第19章 systemd によるコントロールグループバージョン 1 の使用

以下のセクションでは、コントロールグループ (cgroups) の作成、変更、および削除に関連するタスクを概説します。systemd システムおよびサービスマネージャーが提供するユーティリティーは、cgroups 管理の推奨の方法であり、今後サポートされる予定です。

19.1. コントロールグループバージョン 1 における systemd の役割

Red Hat Enterprise Linux 8 では、cgroup 階層のシステムを systemd ユニットツリーにバインドすることにより、リソース管理設定をプロセスレベルからアプリケーションレベルに移行します。したがって、システムリソースは、systemctl コマンドを使用するか、systemd ユニットファイルを変更して管理できます。

デフォルトでは、systemd システムおよびサービスマネージャーは、スライス ユニット、スコープ ユニット、および サービス ユニットを使用して、コントロールグループ内のプロセスを整理および構造化します。systemctl コマンドを使用すると、カスタムの スライス を作成してこの構造をさらに変更できます。また、systemd は、重要なカーネルリソースコントローラーの階層を /sys/fs/cgroup/ ディレクトリーに自動的にマウントします。

systemd の 3 つのユニットタイプは、リソース制御に使用します。

  • Service - ユニット設定ファイルに従って systemd が起動したプロセスまたはプロセスのグループ。サービスは、指定したプロセスをカプセル化して、1 つのセットとして起動および停止できるようにします。サービスの名前は以下の方法で指定されます。

    <name>.service
  • スコープ - 外部で作成されたプロセスのグループ。スコープは、fork() 関数を介して任意のプロセスで開始および停止されたプロセスをカプセル化し、ランタイム時に systemd で登録します。たとえば、ユーザーセッション、コンテナー、および仮想マシンはスコープとして処理されます。スコープの名前は以下のように指定されます。

    <name>.scope
  • スライス - 階層的に編成されたユニットのグループ。スライスは、スコープおよびサービスを配置する階層を編成します。実際のプロセスはスコープまたはサービスに含まれます。スライスユニットの名前はすべて、階層内の場所へのパスに対応します。ハイフン (「-」) 文字は、-.slice ルートスライスからのスライスへのパスコンポーネントの区切り文字として機能します。以下の例では、下記の点を前提としています。

    <parent-name>.slice

    parent-name.slice は、parent.slice です。これは、-.slice root スライスのサブスライスです。parent-name.slice は、parent-name-name2.slice という名前の独自のサブスライスなどを持つことができます。

サービススコープスライス ユニットは、コントロールグループ階層のオブジェクトに直接マッピングされます。これらのユニットがアクティブになると、ユニット名から構築されるグループパスを制御するように直接マッピングされます。

以下は、コントロールグループ階層の省略形の例です。

Control group /:
-.slice
├─user.slice
│ ├─user-42.slice
│ │ ├─session-c1.scope
│ │ │ ├─ 967 gdm-session-worker [pam/gdm-launch-environment]
│ │ │ ├─1035 /usr/libexec/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
│ │ │ ├─1054 /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/42/gdm/Xauthority -background none -noreset -keeptty -verbose 3
│ │ │ ├─1212 /usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
│ │ │ ├─1369 /usr/bin/gnome-shell
│ │ │ ├─1732 ibus-daemon --xim --panel disable
│ │ │ ├─1752 /usr/libexec/ibus-dconf
│ │ │ ├─1762 /usr/libexec/ibus-x11 --kill-daemon
│ │ │ ├─1912 /usr/libexec/gsd-xsettings
│ │ │ ├─1917 /usr/libexec/gsd-a11y-settings
│ │ │ ├─1920 /usr/libexec/gsd-clipboard
…​
├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
└─system.slice
  ├─rngd.service
  │ └─800 /sbin/rngd -f
  ├─systemd-udevd.service
  │ └─659 /usr/lib/systemd/systemd-udevd
  ├─chronyd.service
  │ └─823 /usr/sbin/chronyd
  ├─auditd.service
  │ ├─761 /sbin/auditd
  │ └─763 /usr/sbin/sedispatch
  ├─accounts-daemon.service
  │ └─876 /usr/libexec/accounts-daemon
  ├─example.service
  │ ├─ 929 /bin/bash /home/jdoe/example.sh
  │ └─4902 sleep 1
  …​

上記の例では、サービスおよびスコープにプロセスが含まれており、独自のプロセスを含まないスライスに置かれていることを示しています。

関連情報

19.2. 一時的なコントロールグループの作成

一時的な cgroups は、ランタイム時にユニット (サービスまたはスコープ) が消費するリソースに制限を設定します。

手順

  • 一時的なコントロールグループを作成するには、以下の形式で systemd-run コマンドを使用します。

    # systemd-run --unit=<name> --slice=<name>.slice <command>

    このコマンドは、一時的なサービスまたはスコープユニットを作成し、開始し、そのユニットでカスタムコマンドを実行します。

    • --unit=<name> オプションは、ユニットに名前を指定します。--unit が指定されていないと、名前は自動的に生成されます。
    • --slice=<name>.slice オプションは、サービスまたはスコープユニットを指定のスライスのメンバーにします。<name>.slice は、既存のスライスの名前 (systemctl -t slice の出力に表示) に置き換えるか、または一意の名前を指定して新規スライスを作成します。デフォルトでは、サービスおよびスコープは system.slice のメンバーとして作成されます。
    • <command> は、サービスまたはスコープユニットで実行するコマンドに置き換えます。

      以下のような、サービスまたはスコープが正常に作成され開始したことを確認するメッセージが表示されます。

      # Running as unit <name>.service
  • 必要に応じて、ランタイム情報を収集するため、プロセスが終了した後もユニットを実行したままにします。

    # systemd-run --unit=<name> --slice=<name>.slice --remain-after-exit <command>

    コマンドは、一時的なサービスユニットを作成して開始し、そのユニットでカスタムコマンドを実行します。--remain-after-exit オプションを使用すると、プロセスの終了後もサービスが実行し続けます。

19.3. 永続的なコントロールグループの作成

永続的なコントロールグループをサービスに割り当てるには、そのユニット設定ファイルを編集する必要があります。この設定はシステム再起動後も保存されるので、これを使用して自動的に起動されたサービスを管理できます。

手順

  • 永続的なコントロールグループを作成するには、次のコマンドを実行します。

    # systemctl enable <name>.service

    上記のコマンドは、ユニット設定ファイルを自動的に /usr/lib/systemd/system/ ディレクトリーに作成し、デフォルトで <name>.servicesystem.slice ユニットに割り当てます。

19.4. コマンドラインでのメモリーリソース制御の設定

プロセスのグループのハードウェアリソースに対するアクセス権限を設定して優先順位を付け、制御する方法の 1 つとして、コマンドラインインターフェースでコマンドを実行する方法があります。

手順

  • サービスのメモリー使用量を制限するには、以下を実行します。

    # systemctl set-property example.service MemoryLimit=1500K

    このコマンドは、example.service サービスが所属するコントロールグループで実行されるプロセスに対して、1,500 キロバイトのメモリー制限を割り当てます。この設定バリアントの MemoryLimit パラメーターは /etc/systemd/system.control/example.service.d/50-MemoryLimit.conf ファイルに定義され、/sys/fs/cgroup/memory/system.slice/example.service/memory.limit_in_bytes ファイルの値を制御します。

  • 必要に応じて、サービスのメモリー使用量を一時的に制限するには、以下を実行します。

    # systemctl set-property --runtime example.service MemoryLimit=1500K

    このコマンドは、メモリー制限を example.service サービスに即座に割り当てます。MemoryLimit パラメーターは、次回起動時まで /run/systemd/system.control/example.service.d/50-MemoryLimit.conf ファイルに定義されます。再起動すると、/run/systemd/system.control/ ディレクトリー全体と MemoryLimit が削除されます。

注記

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

19.5. ユニットファイルを使用したメモリーリソース制御の設定

各永続的なユニットは systemd システムおよびサービスマネージャーによって監視され、/usr/lib/systemd/system/ ディレクトリーにユニット設定ファイルがあります。永続的なユニットのリソース制御設定を変更するには、そのユニット設定ファイルをテキストエディターまたはコマンドラインインターフェースで手動で変更します。

プロセスのグループのハードウェアリソースに対するアクセス権限を設定して優先順位を付け、制御する方法の 1 つとして、ユニットファイルを手動で変更する方法があります。

手順

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

    …​
    [Service]
    MemoryLimit=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 キロバイトに制限されていることを示しています。

    注記

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

19.6. 一時的なコントロールグループの削除

systemd システムおよびサービスマネージャーを使用して、プロセスのグループのハードウェアリソースへのアクセスを制限して優先順位を付け、制御する必要がなくなった場合に、一時的なコントロールグループ (cgroup) を削除できます。

一時的な cgroups は、サービスまたはスコープユニットに含まれる全プロセスが完了すると、自動的に解放されます、

手順

  • すべてのプロセスでサービスユニットを停止するには、以下のコマンドを実行します。

    # systemctl stop <name>.service
  • ユニットプロセスを 1 つ以上終了するには、以下を実行します。

    # systemctl kill <name>.service --kill-who=PID,…​ --signal=signal

    上記のコマンドは、--kill-who オプションを使用して、終了するコントロールグループからプロセスを選択します。複数のプロセスを同時に強制終了するには、PID のコンマ区切りの一覧を指定します。--signal オプションは、指定されたプロセスに送信する POSIX シグナルのタイプを決定します。デフォルトのシグナルは SIGTERM です。

19.7. 永続的なコントロールグループの削除

systemd システムおよびサービスマネージャーを使用して、プロセスのグループのハードウェアリソースへのアクセスを制限して優先順位を付け、制御する必要がなくなった場合に、永続的なコントロールグループおよび永続コントロールグループ (cgroup) を削除できます。

永続的な cgroups は、サービスまたはスコープユニットが停止または無効化されてその設定ファイルが削除されると解放されます。

手順

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

    # systemctl stop <name>.service
  2. サービスユニットを無効にします。

    # systemctl disable <name>.service
  3. 関連するユニット設定ファイルを削除します。

    # rm /usr/lib/systemd/system/<name>.service
  4. すべてのユニット設定ファイルを再度読み込み、変更を有効にします。

    # systemctl daemon-reload

19.8. Systemd ユニットの一覧表示

以下の手順では、systemd システムおよびサービスマネージャーを使用してユニットを一覧表示する方法を説明します。

手順

  • システム上のアクティブなユニットをすべて一覧表示するには、# systemctl コマンドを実行します。ターミナルでは、以下の例のような出力を返します。

    # systemctl
    UNIT                                                LOAD   ACTIVE SUB       DESCRIPTION
    …​
    init.scope                                          loaded active running   System and Service Manager
    session-2.scope                                     loaded active running   Session 2 of user jdoe
    abrt-ccpp.service                                   loaded active exited    Install ABRT coredump hook
    abrt-oops.service                                   loaded active running   ABRT kernel log watcher
    abrt-vmcore.service                                 loaded active exited    Harvest vmcores for ABRT
    abrt-xorg.service                                   loaded active running   ABRT Xorg log watcher
    …​
    -.slice                                             loaded active active    Root Slice
    machine.slice                                       loaded active active    Virtual Machine and Container Slice system-getty.slice                                                                       loaded active active    system-getty.slice
    system-lvm2\x2dpvscan.slice                         loaded active active    system-lvm2\x2dpvscan.slice
    system-sshd\x2dkeygen.slice                         loaded active active    system-sshd\x2dkeygen.slice
    system-systemd\x2dhibernate\x2dresume.slice         loaded active active    system-systemd\x2dhibernate\x2dresume>
    system-user\x2druntime\x2ddir.slice                 loaded active active    system-user\x2druntime\x2ddir.slice
    system.slice                                        loaded active active    System Slice
    user-1000.slice                                     loaded active active    User Slice of UID 1000
    user-42.slice                                       loaded active active    User Slice of UID 42
    user.slice                                          loaded active active    User and Session Slice
    …​
    • UNIT - コントロールグループ階層内のユニットの位置も反映するユニットの名前です。リソース制御に関連するユニットは、スライススコープ および サービス です。
    • LOAD - ユニット設定ファイルが正しく読み込まれたかどうかを示します。ユニットファイルの読み込みに失敗した場合には、フィールドの状態が loaded ではなく error になります。ユニットの読み込みの状態は他に stub, merged, and masked などがあります。
    • ACTIVE - ユニットのアクティベーションの状態 (概要レベル)。こちらは SUB の概要レベルの状態です。
    • SUB - ユニットのアクティベーションの状態 (詳細レベル)。許容値の範囲は、ユニットタイプによって異なります。
    • DESCRIPTION - ユニットのコンテンツおよび機能の説明。
  • アクティブではないユニットを一覧表示するには、次のコマンドを実行します。

    # systemctl --all
  • 出力の情報量を制限するには、以下を実行します。

    # systemctl --type service,masked

    --type オプションでは、サービス および スライス などのユニットタイプのコンマ区切りの一覧、または 読み込み済みマスク済み などのユニットの読み込み状態が必要です。

関連情報

19.9. コントロールグループバージョン 1 の階層の表示

以下の手順では、特定の cgroups で実行しているコントロールグループ (cgroups) 階層およびプロセスを表示する方法を説明します。

手順

  • システムの cgroups 階層全体を表示するには、# systemd-cgls を実行します。

    # systemd-cgls
    Control group /:
    -.slice
    ├─user.slice
    │ ├─user-42.slice
    │ │ ├─session-c1.scope
    │ │ │ ├─ 965 gdm-session-worker [pam/gdm-launch-environment]
    │ │ │ ├─1040 /usr/libexec/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
    …​
    ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
    └─system.slice
      …​
      ├─example.service
      │ ├─6882 /bin/bash /home/jdoe/example.sh
      │ └─6902 sleep 1
      ├─systemd-journald.service
        └─629 /usr/lib/systemd/systemd-journald
      …​

    この出力例では cgroups 階層全体を返します。この海藻は、slices で形成される最も高いレベルです。

  • cgroups 階層を、リソースコントローラー別にフィルタリングして表示するには、# systemd-cgls <resource_controller> を実行します。

    # systemd-cgls memory
    Controller memory; Control group /:
    ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
    ├─user.slice
    │ ├─user-42.slice
    │ │ ├─session-c1.scope
    │ │ │ ├─ 965 gdm-session-worker [pam/gdm-launch-environment]
    …​
    └─system.slice
      |
      …​
      ├─chronyd.service
      │ └─844 /usr/sbin/chronyd
      ├─example.service
      │ ├─8914 /bin/bash /home/jdoe/example.sh
      │ └─8916 sleep 1
      …​

    上記のコマンドの出力例では、選択したコントローラーと対話するサービスの一覧を表示します。

  • 特定のユニットと cgroups 階層の一部に関する詳細情報を表示するには、# systemctl status <system_unit> を実行します。

    # systemctl status example.service
    ● example.service - My example service
       Loaded: loaded (/usr/lib/systemd/system/example.service; enabled; vendor preset: disabled)
       Active: active (running) since Tue 2019-04-16 12:12:39 CEST; 3s ago
     Main PID: 17737 (bash)
        Tasks: 2 (limit: 11522)
       Memory: 496.0K (limit: 1.5M)
       CGroup: /system.slice/example.service
               ├─17737 /bin/bash /home/jdoe/example.sh
               └─17743 sleep 1
    Apr 16 12:12:39 redhat systemd[1]: Started My example service.
    Apr 16 12:12:39 redhat bash[17737]: The current time is Tue Apr 16 12:12:39 CEST 2019
    Apr 16 12:12:40 redhat bash[17737]: The current time is Tue Apr 16 12:12:40 CEST 2019

関連情報

19.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 が起動するすべてのユニットで同じになります。

関連情報

  • cgroups(7)マニュアルページ
  • usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/ディレクトリにあるドキュメント。

19.11. リソース消費の監視

以下の手順では、現在実行中のコントロールグループ (cgroup) とそのリソース消費の一覧をリアルタイムで表示する方法を説明します。

手順

  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 秒ごとに一覧が更新されます。そのため、コントロールグループごとに、実際のリソースの使用状況について動的な見解が得られるようになります。

関連情報

  • systemd-cgtop(1) manual page

19.12. systemdによるCPUSETコントローラの設定

systemdのリソース管理APIでは、サービスが使用できるCPUやNUMAノードの制限を設定することができます。この制限により、プロセスが利用するシステムリソースへのアクセスが制限されます。要求された設定は、cpuset.cpuscpuset.memsに書かれています。しかし、親のcgroupが`cpus`やmemsのいずれかを制限しているため、要求された構成は使用できないかもしれません。現在の構成にアクセスするには、cpuset.cpus.effectiveおよびcpuset.mems.effectiveファイルがユーザーにエクスポートされます。

手順

  • AllowedCPUsを設定するには

    # systemctl set-property service_name.service AllowedCPUs=value

    以下に例を示します。

    systemctl set-property service_name.service AllowedCPUs=0-5
  • AllowedMemoryNodesを設定するには、次のようにします。

    # systemctl set-property service_name.service AllowedMemoryNodes=value

    以下に例を示します。

    # systemctl set-property service_name.service AllowedMemoryNodes=0

第20章 systemd での cgroups バージョン 2 を使用するリソース管理の設定

systemd は主に、サービスの管理と監視を行い、適切なサービスが適切なタイミングで、起動プロセス中に正しい順番に起動されるようにします。サービスの実行時には、スムーズに実行して基盤のハードウェアプラットフォームを最適に使用する必要があります。したがって、systemd には、リソース管理ポリシーの定義や、さまざまなオプションを調整する機能もあるので、サービスのパフォーマンスが改善されます。

20.1. 前提条件

20.2. リソース分散モデルの概要

リソース管理では、systemd は cgroups v2 インターフェースを使用します。

RHEL 8 はデフォルトで cgroups v1 を使用することに注意してください。したがって、cgroups v2 を有効にして、systemd がリソース管理に cgroups v2 インターフェースを使用できるようにする必要があります。cgroups v2 を有効にする方法は、「cgroups-v2 を使用したアプリケーションへの CPU 制限の設定」を参照してください。

システムリソースの配分を変更するには、以下のリソース分散モデルに 1 つまたは複数を適用できます。

加重

全サブグループの加重を乗算し、サブグループごとに合計の比率にあった分を渡して、分散します。

たとえば、cgroups が 10 個あり、各 cgroups の値が 100 の場合には、合計は 1000 で、cgroup ごとにリソースの 10 分の 1 を受け取ります。

加重は通常、ステートレスリソースの分散に使用されます。CPUWeight= オプションは、このリソース分散モデルの実装です。

制限

cgroup は、設定したリソースの量だけ使用できますが、リソースをオーバーコミットすることもできます。そのため、サブグループ制限の合計は、親 cgroup の制限を超える可能性があります。

MemoryMax= オプションは、このリソースの分散モデルの実装です。

保護

cgroup に、保護するリソース量を設定できます。リソースの使用状況が保護されるリソース量を下回る場合には、カーネルは、同じリソースを取得しようしている他の cgroup が優先されるように、この cgroup にペナルティーを課します。オーバーコミットも可能です。

MemoryLow= オプションは、このリソースの分散モデルの実装です。

割り当て
リソースに上限がある場合に、絶対量を特別に割り当てます。オーバーコミットはできません。Linux でこのリソースのタイプとして、リアルタイムの予算などが例として挙げられます。

20.3. systemd を使用した CPU リソースの割り当て

systemd が管理するシステムでは、各システムサービスは対象の cgroup で起動します。CPU cgroup コントローラーのサポートを有効にすると、システムはプロセスごとのディストリビューションではなく、CPU リソースのサービス対応ディストリビューションを使用します。サービス対応ディストリビューションでは、サービスを構成するプロセスの数にかかわらず、システムで実行中の他の全サービスと比較して、ほぼ同じ CPU 時間を受け取ります。

特定のサービスで多くの CPU リソースが必要な場合は、サービスの CPU 時間割り当てポリシーを変更することでリソースを付与できます。

手順

systemd の使用時に CPU 時間割り当てポリシーオプションを設定するには、以下を実行します。

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

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

検証手順

  • サービスに必要な CPU 時間割り当てポリシーオプションの値が正常に変更されたかどうかを確認するには、以下のコマンドを実行します。

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

20.4. systemd の CPU 時間割り当てポリシーオプション

最も頻繁に使用される CPU 時間割り当てポリシーオプションには、以下が含まれます。

CPUWeight=

特定のサービスに対して、他の全サービスよりも 優先度を高く 割り当てます。間隔 1 - 10,000 の値から選択できます。デフォルト値は 100 です。

たとえば、他の全サービスと比べて 2 倍の CPU を httpd.service に割り当てるには、値を CPUWeight=200 に設定します。

CPUWeight= は、オペレーティングシステムはオーバーロードされた場合にのみ適用されます。

CPUQuota=

絶対 CPU 時間のクォータ をサービスに割り当てます。このオプションの値は、利用可能な CPU 時間合計に対してサービスが受け取る CPU 時間の最大比率 (例: CPUQuota=30%) を指定します。

CPUQuota= は、「リソース分散モデルの概要」で説明されている特定のリソース分散モデルの制限値を表している点に注意してください。

CPUQuota= の詳細は、systemd.resource-control(5) の man ページを参照してください。

20.5. systemd を使用したメモリーリソースの割り当て

このセクションでは、メモリー設定オプション (MemoryMinMemoryLowMemoryHighMemoryMaxMemorySwapMax) のいずれかを使用して、systemd でメモリーリソースを割り当てる方法を説明します。

手順

systemd の使用時にメモリー割り当て設定オプションを指定するには、以下を実行します。

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

    $ systemctl show --property <memory allocation configuration option> <service name>
  2. root として、メモリー割り当ての設定オプションで必要な値を設定します。

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

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

検証手順

  • サービスに必要なメモリー割り当ての設定オプションの値が正常に変更されたかどうかを確認するには、以下のコマンドを実行します。

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

20.6. systemd のメモリー割り当て設定オプション

systemd を使用してシステムメモリー割り当てを設定する場合には、以下のオプションを使用できます。

MemoryMin
ハードメモリーの保護。メモリー使用量が上限を下回る場合には、cgroup メモリーは要求されません。
MemoryLow
ソフトメモリーの保護。メモリーの使用量が上限を下回り、保護されていない cgroup からメモリーが要求されなかった場合のみ、cgroup のメモリーを要求できます。
MemoryHigh
メモリースロットルの制限。メモリー使用量が上限を超えると、cgroup のプロセスがスロットリングされ、要求の負荷が高くなります。
MemoryMax
メモリー使用量の絶対上限。キロバイト (K)、メガバイト (M)、ギガバイト (G)、テラバイト (T) のサフィックス (例: MemoryMax=1G) を使用できます。
MemorySwapMax
swap の使用量のハード制限。
注記

メモリーの上限を超えると、OOM (Out-of-memory) killer は実行中のサービスを停止します。これを回避するには、MemoryMax=1G の値を減らして、メモリーの耐性を高めます。

20.7. systemd を使用した I/O 帯域幅の設定

RHEL 8 で特定のサービスのパフォーマンスを改善するには、systemd を使用してそのサービスに I/O 帯域幅リソースを割り当てることができます。

これには、以下の I/O 設定オプションを使用できます。

  • IOWeight
  • IODeviceWeight
  • IOReadBandwidthMax
  • IOWriteBandwidthMax
  • IOReadIOPSMax
  • IOWriteIOPSMax

手順

systemd を使用して I/O 帯域幅設定オプション を設定するには、以下を実行します。

  1. 選択したサービスで、I/O 帯域幅設定オプションに割り当てた値を確認します。

    $ systemctl show --property <I/O bandwidth configuration option> <service name>
  2. root として、I/O 帯域幅の設定オプションで必要な値を設定します。

    # systemctl set-property <service name> <I/O bandwidth configuration option>=<value>

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

検証手順

  • サービスに必要な I/O 帯域幅の設定オプションの値が正常に変更されたかどうかを確認するには、以下のコマンドを実行します。

    $ systemctl show --property <I/O bandwidth configuration option> <service name>

20.8. systemd の I/O 帯域幅設定オプション

systemd でブロックレイヤー I/O ポリシーを管理するには、次の設定オプションを使用できます。

IOWeight
デフォルトの I/O 加重を設定します。加重の値をベースとして使用し、他のサービスと比べ、実際に受け取る I/O 帯域幅を計算します。
IODeviceWeight

特定のブロックデバイスの I/O 加重を設定します。

たとえば、IODeviceWeight=/dev/disk/by-id/dm-name-rhel-root 200 などです。

IOReadBandwidthMaxIOWriteBandwidthMax

デバイスまたはマウントポイントごとの絶対帯域幅を設定します。

たとえば、IOWriteBandwith=/var/log 5M などです。

注記

systemd は、ファイルシステムからデバイスの変換を自動的に処理します。

IOReadIOPSMaxIOWriteIOPSMax
1 つ前のオプションと同様: Input/Output Operations Per second (IOPS) の絶対帯域幅を設定します。
注記

加重ベースのオプションは、ブロックデバイスが CFQ I/O スケジューラーを使用している場合にのみサポートされます。デバイスが Multi-Queue Block I/O キューメカニズムを使用する場合は、オプションのサポートはありません。

第21章 systemd を使用した CPU のアフィニティーおよび NUMA ポリシーの設定

CPU 管理、メモリー管理、および I/O 帯域幅オプションで、利用可能なリソースを分割します。

21.1. systemd を使用した CPU アフィニティーの設定

CPU アフィニティーの設定は、特定のプロセスにアクセスできる CPU を一部だけに制限する場合に役立ちます。実際には、CPU スケジューラーでは、プロセスのアフィニティーマスク上にない CPU で実行するプロセスはスケジューリングされません。

デフォルトの CPU アフィニティーマスクは、systemd が管理するすべてのサービスに適用されます。

特定の systemd サービスの CPU アフィニティーマスクを設定するには、systemd の /etc/systemd/system.conf でユニットファイルオプションとマネージャー設定オプション両方として CPUAffinity= を指定します。

CPUAffinity= ユニットファイルのオプション では、CPU または CPU 範囲の一覧を設定し、アフィニティーマスクとしてマージして使用されます。/etc/systemd/system.conf ファイルの CPUAffinity オプション は、プロセス ID 番号 (PID) 1 と、PID1 でフォークされた全プロセスにアフィニティーマスクを定義します。これにより、各サービスで CPUAffinity を上書きできます。

注記

特定の systemd サービスの CPU アフィニティーマスクを設定したら、システムを再起動して変更を適用する必要があります。

手順

CPUAffinity ユニットファイル オプションを使用して特定の systemd サービスの CPU アフィニティーマスクを設定するには以下を実行します。

  1. 選択したサービスで CPUAffinity ユニットファイルオプションの値を確認します。

    $ systemctl show --property <CPU affinity configuration option> <service name>
  2. root として、アフィニティーマスクとして使用する CPU 範囲の CPUAffinity ユニットファイルで必要な値を設定します。

    # systemctl set-property <service name> CPUAffinity=<value>
  3. サービスを再起動して変更を適用します。

    # systemctl restart <service name>

manager configuration オプションを使用して特定の systemd サービスの CPU アフィニティーマスクを設定するには、以下を実行します。

  1. /etc/systemd/system.conf ファイルを編集します。

    # vi /etc/systemd/system.conf
  2. CPUAffinity= オプションを検索して、CPU 数を設定します。
  3. 編集したファイルを保存し、サーバーを再起動して変更を適用します。

21.2. systemd を使用した NUMA の設定

Non-Uniform Memory Access (NUMA) は、コンピューターメモリーのサブシステム設計で、この設計ではメモリーのアクセス時間は、プロセッサーからのメモリーの場所により異なります。CPU に近いメモリーは、別の CPU のローカルにあるメモリーや、一連の CPU 間で共有されているメモリーと比べ、レイテンシーが低くなっています (ローカルメモリー)。

Linux カーネルでは、NUMA ポリシーを使用して、カーネルがプロセス用に物理メモリーを割り当てる場所 (例: NUMA ノード) を制御します。

NUMA を設定するには、systemd の /etc/systemd/system.conf ファイルで NUMAPolicyNUMAMask のユニットファイルオプションおよびマネージャーの設定オプションを指定します。

手順

NUMAPolicy ユニットファイル オプションで NUMA メモリーポリシーを設定するには以下を実行します。

  1. 選択したサービスで NUMAPolicy ユニットファイルオプションの値を確認します。

    $ systemctl show --property <NUMA policy configuration option> <service name>
  2. root として、NUMAPolicy ユニットファイルオプションに必要なポリシータイプを設定します。

    # systemctl set-property <service name> NUMAPolicy=<value>
  3. サービスを再起動して変更を適用します。

    # systemctl restart <service name>

マネージャー設定 オプションで NUMAPolicy を設定するには以下を実行します。

  1. /etc/systemd/system.conf ファイルを編集します。

    # vi /etc/systemd/system.conf
  2. NUMAPolicy オプションを検索し、ポリシー種別を設定します。
  3. 編集したファイルを保存し、サーバーを再起動して変更を適用します。

21.3. systemd の NUMA ポリシー設定オプション

systemd で以下のオプションを指定して、NUMA ポリシーを設定します。

NUMAPolicy

実行したプロセスの NUMA メモリーポリシーを制御します。以下のポリシー種別を使用できます。

  • default
  • preferred
  • bind
  • interleave
  • local
NUMAMask

選択した NUMA ポリシーに関連付けられた NUMA ノード一覧を制御します。

NUMAmask オプションは、以下のポリシーに指定する必要はありません。

  • default
  • local

優先ポリシーの場合、この一覧で指定できるのは単一の NUMA ノードのみです。

関連情報

第22章 「BPF コンパイラーコレクションでシステムパフォーマンスの分析」

システム管理者として BPF コンパイラーコレクション (BCC) ライブラリーで Linux オペレーティングシステムのパフォーマンスを分析するツールを作成します。ただし、他のインターフェース経由での取得は困難な場合があります。

22.1. BCC の概要

BPF コンパイラーコレクション (BCC) は、eBPF (extended Berkeley Packet Filter) プログラムの作成を容易にするライブラリーです。この主なユーティリティーは、オーバーヘッドやセキュリティー上の問題が発生することなく、OS のパフォーマンスおよびネットワークパフォーマンスを分析するものです。

BCC により、ユーザーは eBPF の技術詳細を把握する必要がなくなり、事前に作成した eBPF プログラムを含む bcc-tools パッケージなど、多くの標準スタートポイントを利用できます。

注記

eBPF プログラムは、ディスク I/O、TCP 接続、プロセス作成などのイベントでトリガーされます。プログラムがカーネルのセーフ仮想マシンで実行するため、カーネルがクラッシュしたり、ループしたり、応答しなくなることはあまりありません。

22.2. bcc-tools パッケージのインストール

このセクションでは、BCC (BPF コンパイラーコレクション) ライブラリーを含む bcc-tools パッケージをインストールする方法を説明します。

前提条件

手順

  1. bcc-tools をインストールします。

    # yum install bcc-tools

    BCC ツールは、/usr/share/bcc/tools/ ディレクトリーにインストールされます。

  2. 必要に応じて、ツールを検証します。

    # ll /usr/share/bcc/tools/
    ...
    -rwxr-xr-x. 1 root root  4198 Dec 14 17:53 dcsnoop
    -rwxr-xr-x. 1 root root  3931 Dec 14 17:53 dcstat
    -rwxr-xr-x. 1 root root 20040 Dec 14 17:53 deadlock_detector
    -rw-r--r--. 1 root root  7105 Dec 14 17:53 deadlock_detector.c
    drwxr-xr-x. 3 root root  8192 Mar 11 10:28 doc
    -rwxr-xr-x. 1 root root  7588 Dec 14 17:53 execsnoop
    -rwxr-xr-x. 1 root root  6373 Dec 14 17:53 ext4dist
    -rwxr-xr-x. 1 root root 10401 Dec 14 17:53 ext4slower
    ...

    上記の一覧にある doc ディレクトリーには、各ツールのドキュメントが含まれます。

22.3. bcc-tools でパフォーマンスの分析

このセクションでは、BPF コンパイラーコレクション (BCC) ライブラリーから特定の事前作成されたプログラムを使用して、イベントごとにシステムパフォーマンスを効率的かつ安全に分析する方法を説明します。BCC ライブラリーで事前作成されたプログラムセットは、追加プログラム作成の例として使用できます。

execsnoop を使用したシステムプロセスの検証

  1. ある端末で execsnoop プログラムを実行します。

    # /usr/share/bcc/tools/execsnoop
  2. 別の端末で、以下のように実行します。

    $ ls /usr/share/bcc/tools/doc/

    これにより、ls コマンドの短命プロセスが作成されます。

  3. execsnoop を実行している端末は、以下のような出力を表示します。

    PCOMM	PID    PPID   RET ARGS
    ls   	8382   8287     0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/
    sed 	8385   8383     0 /usr/bin/sed s/^ *[0-9]\+ *//
    ...

    execsnoop プログラムは、新しいプロセスごとに出力行を出力するため、システムリソースを消費します。また、ls などの非常に短期間に実行されるプログラムのプロセスを検出します。なお、ほとんどの監視ツールはそれらを登録しません。

    execsnoop 出力には以下のフィールドが表示されます。

    • PCOMM - 親プロセス名。(ls)
    • PID - プロセス ID(8382)
    • ppid: 親プロセス ID。(8287)
    • RET - exec() のシステム呼び出しの戻り値 (0)。プログラムコードを新規プロセスに読み込みます。
    • ARGS - 引数を使用して開始したプログラムの場所。

execsnoop の詳細、例、およびオプションを確認するには、/usr/share/bcc/tools/doc/execsnoop_example.txt ファイルを参照してください。

exec() の詳細は、exec(3) man ページを参照してください。

opensnoop を使用した、コマンドにより開かれるファイルの追跡

  1. ある端末で opensnoop プログラムを実行します。

    # /usr/share/bcc/tools/opensnoop -n uname

    上記の出力では、uname コマンドのプロセスによってのみ開かれるファイルの内容が出力されます。

  2. 別の端末で、以下を実行します。

    $ uname

    上記のコマンドは、特定のファイルを開きます。このファイルは次のステップでキャプチャーされます。

  3. opensnoop を実行している端末は、以下のような出力を表示します。

    PID    COMM 	FD ERR PATH
    8596   uname 	3  0   /etc/ld.so.cache
    8596   uname 	3  0   /lib64/libc.so.6
    8596   uname 	3  0   /usr/lib/locale/locale-archive
    ...

    opensnoop プログラムは、システム全体で open() システム呼び出しを監視し、uname が開こうとしたファイルごとに出力行を出力します。

    opensnoop 出力には、以下のフィールドが表示されます。

    • PID - プロセス ID(8596)
    • COMM - プロセス名 (uname)
    • FD - ファイルの記述子。開いたファイルを参照するために open() が返す値。(3)
    • ERR - すべてのエラー
    • PATH - open() で開こうとしたファイルの場所。

      コマンドが、存在しないファイルを読み込もうとすると、FD コラムは -1 を返し、ERR コラムは関連するエラーに対応する値を出力します。その結果、opennoop は、適切に動作しないアプリケーションの特定に役立ちます。

opensnoop の詳細、例、およびオプションを確認するには、/usr/share/bcc/tools/doc/opensnoop_example.txt ファイルを参照してください。

open() の詳細は、open(2) man ページを参照してください。

ディスク上の I/O 操作を調べるための biotop の使用

  1. ある端末で biotop プログラムを実行します。

    # /usr/share/bcc/tools/biotop 30

    このコマンドにより、ディスク上で I/O 操作を実行する上位のプロセスを監視できます。この引数は、コマンドが 30 秒の概要を生成するようにします。

    注記

    引数を指定しないと、デフォルトでは 1 秒ごとに出力画面が更新されます。

  2. 別の端末では、以下のようになります。

    # dd if=/dev/vda of=/dev/zero

    上記のコマンドは、ローカルのハードディスクデバイスからコンテンツを読み込み、出力を /dev/zero ファイルに書き込みます。この手順では、biotop を示す特定の I/O トラフィックを生成します。

  3. biotop を実行している端末は、以下のような出力を表示します。

    PID    COMM             D MAJ MIN DISK       I/O  Kbytes     AVGms
    9568   dd               R 252 0   vda      16294 14440636.0  3.69
    48     kswapd0          W 252 0   vda       1763 120696.0    1.65
    7571   gnome-shell      R 252 0   vda        834 83612.0     0.33
    1891   gnome-shell      R 252 0   vda       1379 19792.0     0.15
    7515   Xorg             R 252 0   vda        280  9940.0     0.28
    7579   llvmpipe-1       R 252 0   vda        228  6928.0     0.19
    9515   gnome-control-c  R 252 0   vda         62  6444.0     0.43
    8112   gnome-terminal-  R 252 0   vda         67  2572.0     1.54
    7807   gnome-software   R 252 0   vda         31  2336.0     0.73
    9578   awk              R 252 0   vda         17  2228.0     0.66
    7578   llvmpipe-0       R 252 0   vda        156  2204.0     0.07
    9581   pgrep            R 252 0   vda         58  1748.0     0.42
    7531   InputThread      R 252 0   vda         30  1200.0     0.48
    7504   gdbus            R 252 0   vda          3  1164.0     0.30
    1983   llvmpipe-1       R 252 0   vda         39   724.0     0.08
    1982   llvmpipe-0       R 252 0   vda         36   652.0     0.06
    ...

    biotop 出力には、以下のフィールドが表示されます。

    • PID - プロセス ID(9568)
    • COMM - プロセス名。(dd)
    • DISK - 読み取り操作を実行するディスク。(vda)
    • I/O - 実行された読み取り操作の数。(16294)
    • kbytes - 読み取り操作によって使用したバイト数 (KB)。(14,440,636)
    • AVGms - 読み取り操作の平均 I/O 時間。(3.69)

biotop の詳細、例、およびオプションを確認するには、/usr/share/bcc/tools/doc/biotop_example.txt ファイルを参照してください。

dd の詳細は、dd(1) man ページを参照してください。

xfsslower を使用した、予想外に遅いファイルシステム動作の明確化

  1. 端末で xfsslower プログラムを実行します。

    # /usr/share/bcc/tools/xfsslower 1

    上記のコマンドは、XFS ファイルシステムが、読み込み、書き込み、開く、または同期 (fsync) 操作を実行するのに費やした時間を測定します。1 引数を指定すると、1 ms よりも遅い操作のみが表示されます。

    注記

    引数を指定しないと、xfsslower はデフォルトで 10 ms よりも低速な操作を表示します。

  2. 別の端末で、たとえば以下を実行します。

    $ vim text

    上記のコマンドは、vim エディターでテキストファイルを作成し、XFS ファイルシステムと特定の対話を開始します。

  3. xfsslower を実行している端末は、前の手順でファイルを保存した場合と同様の内容を示しています。

    TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
    13:07:14 b'bash'        4754   R 256     0           7.11 b'vim'
    13:07:14 b'vim'         4754   R 832     0           4.03 b'libgpm.so.2.1.0'
    13:07:14 b'vim'         4754   R 32      20          1.04 b'libgpm.so.2.1.0'
    13:07:14 b'vim'         4754   R 1982    0           2.30 b'vimrc'
    13:07:14 b'vim'         4754   R 1393    0           2.52 b'getscriptPlugin.vim'
    13:07:45 b'vim'         4754   S 0       0           6.71 b'text'
    13:07:45 b'pool'        2588   R 16      0           5.58 b'text'
    ...

    上記の各行はファイルシステム内の操作を表し、特定のしきい値よりも時間がかかります。xfsslower は、操作に想定以上に時間がかかるなど、ファイルシステムで発生し得る問題を表面化するのに適しています。

    xfsslower 出力には、以下のフィールドが表示されます。

    • COMM - プロセス名。(b'bash')
    • T - 操作の種類。(R)

      • Read
      • Write
      • Sync
    • OFF_KB - ファイルオフセット(KB)。(0)
    • FILENAME - 読み取り、書き込み、または同期するファイルです。

xfsslower の詳細、例、およびオプションについては、/usr/share/bcc/tools/doc/xfsslower_example.txt ファイルを参照してください。

fsync の詳細は、fsync(2) の man ページを参照してください。

第23章 カーネル整合性サブシステムによるセキュリティーの強化

カーネル整合性サブシステムのコンポーネントを利用することにより、システムの保護を強化できます。以下のセクションでは、関連するコンポーネントを紹介し、その構成に関するガイダンスを提供します。

23.1. カーネル整合性サブシステム

整合性サブシステムは、システム全体のデータの整合性を維持するカーネルの一部です。このサブシステムを使用すると、特定のシステムを構築時と同じ状態に保つので、特定のシステムファイルが必要に変更されるのを防ぐことができます。

カーネル整合性サブシステムは、2 つの主要なコンポーネントで構成されています。

Integrity Measurement Architecture (IMA)
  • ファイルのコンテンツの測定を、それが実行され、開かれるたびに実行します。ユーザーは、カスタムポリシーを適用してこの動作を変更できます。
  • 測定された値をカーネルのメモリー領域に置くと、システムのユーザーが変更を加えることができなくなります。
  • ローカルおよびリモートのユーザーが測定値を検証できるようにします。
Extended Verification Module (EVM)
  • IMA 測定や SELinux 属性など、システムのセキュリティーに関連するファイルの拡張属性 (xattr としても知られている) を保護するには、対応する値を暗号でハッシュ化します。

IMA と EVM のどちらにも、追加機能を備えた多くの機能拡張が含まれます。以下は例になります。

IMA-Appraisal
  • カーネルメモリー内の測定ファイルに以前に保存されていた値に対して、現在のファイルの内容をローカルで検証します。この拡張機能では、現在と以前の測定が一致しない場合に、特定のファイルでの操作を禁止します。
EVM デジタル署名
  • カーネルのキーリングに保存される暗号鍵でデジタル署名を使用できるようにします。
注記

機能拡張は相互に補完しますが、それぞれを独立して設定し、使用することができます。

カーネル整合性サブシステムは、TPM (Trusted Platform Module) を利用して、システムのセキュリティーをさらに強化できます。TPM は、重要な暗号化機能についての TNC (Trusted Computing Group) による仕様です。TPM は通常、プラットフォームのマザーボードに接続されている専用のハードウェアとして構築され、ハードウェアチップの改ざん防止の保護領域から暗号化機能を提供することでソフトウェアベースの攻撃を防ぎます。TPM 機能には、以下の機能が含まれます。

  • 乱数ジェネレーター
  • 暗号化キーのジェネレーターと安全なストレージ
  • ハッシュジェネレーター
  • リモート認証

23.2. Integrity Measurement Architecture

Integrity Measurement Architecture (IMA) は、カーネル整合性サブシステムのコンポーネントです。IMA は、ローカルファイルのコンテンツを維持することを目的としています。具体的には、IMA はアクセスされる前にファイルのハッシュを測定、保存、評価します。これにより、信頼できないデータの読み取りと実行が防止されます。これにより、IMA はシステムのセキュリティーを強化します。

23.3. 拡張検証モジュール

拡張検証モジュール (EVM) は、ファイルの拡張属性 (xattr) の変更を監視するカーネル整合性サブシステムのコンポーネントです。Integrity Measurement Architecture (IMA) を含む多くのセキュリティー指向のテクノロジーは、コンテンツハッシュなどの機密ファイル情報を拡張属性に保存します。EVM は、この拡張属性と特別な鍵から別のハッシュを作成します。これはシステムの起動時に読み込まれます。結果のハッシュは、拡張属性が使用されるたびに検証されます。たとえば、IMA がファイルを評価する場合です。

RHEL 8 は、evm-key キーリングで特別な暗号化鍵を受け入れます。この鍵は、カーネルキーリングに格納されている マスターキー で作成されています。

23.4. 信頼できる鍵および暗号化された鍵

以下のセクションでは、システムセキュリティーの強化で重要な役割を果たす信頼できる鍵および暗号化鍵について紹介します。

信頼できる 鍵と 暗号化 鍵は、カーネルキーリングサービスを使用するカーネルが生成する可変長の対称鍵です。このタイプの鍵は、暗号化されていない形式ではユーザー空間に表示されないため、その整合性を検証できます。つまり、拡張検証モジュール (EVM) などで実行中のシステムの整合性を検証および確認する時に使用できます。ユーザーレベルのプログラムがアクセス可能なのは、暗号化された ブロブ の形式での鍵のみです。

信頼できる鍵は、Trusted Platform Module (TPM) チップというハードウェアが必要になります。これは、鍵を作成し、暗号化 (保護) するために使用されます。TPM は storage root key (SRK) という 2048 ビットの RSA 鍵を使用して鍵を保護します。

注記

TPM 1.2 仕様を使用するには、マシンファームウェアの設定、またはユーティリティーの tpm-tools パッケージの tpm_setactive コマンドを使用して、この仕様を有効にしてアクティブにします。また、TrouSers ソフトウェアスタックをインストールし、tcsd デーモンを実行して TPM (専用のハードウェア) と通信させる必要があります。tcsd デーモンは TrouSers スイートの一部で、trousers パッケージから入手できます。より新しい、後方互換性のない TPM 2.0 は、別のソフトウェアスタックを使用して、そのソフトウェアの tpm2-tools または ibm-tss ユーティリティーで専用のハードウェアにアクセスできるようにします。

さらに、ユーザーは TPM の platform configuration register (PCR) 値の特定セットで信頼できる鍵を保護できます。PCR には、ファームウェア、ブートローダー、およびオペレーティングシステムを反映する整合性管理値のセットが含まれます。つまり、PCR で保護された鍵は、暗号化を行った同じシステム上にある TPM でしか復号できません。ただし、PCR で保護された信頼できる鍵が読み込まれると (キーリングに追加されると)、新しいカーネルなどを起動できるように、関連する PCR 値が検証され、新しい (または今後の) PCR 値に更新されます。1 つの鍵を複数のブロブとして保存することもできますが、それぞれ PCR 値が異なります。

暗号化鍵は、カーネルの AES (Advanced Encryption Standard) を使用するため、TPM を必要としないので、信頼できる鍵よりも高速になります。暗号化鍵は、カーネルが生成した乱数を使用して作成され、ユーザー空間のブロブへのエクスポート時に マスターキー により暗号化されます。マスターキーは信頼できる鍵か、ユーザーキーのいずれかです。マスターキーが信頼されていない場合には、暗号化鍵のセキュリティーは、暗号化に使用されたユーザーキーと同じように保護されます。

23.5. 信頼できる鍵での作業

次のセクションでは、keyctl ユーティリティーを使用して信頼できる鍵を作成、エクスポート、読み込み、または更新して、システムセキュリティーを強化する方法を説明します。

前提条件

手順

  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 <pass:quotes[name]> "new [format] <pass:quotes[key_type]>:<pass:quotes[primary_key_name]> <pass:quotes[keylength]>" <pass:quotes[key_ring]>
    • 構文に基づいて、すでに作成された信頼できる鍵を使用して暗号化鍵を生成します。

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

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

23.6. 暗号化鍵での作業

次のセクションでは、TPM (Trusted Platform Module) が利用できないシステムでのセキュリティー強化に暗号化鍵を管理する方法を説明します。

前提条件

  • 64 ビット ARM アーキテクチャーおよび IBM Z の場合は、encrypted-keys カーネルモジュールを読み込む必要があります。カーネルモジュールを読み込む方法は、「カーネルモジュールの管理」を参照してください。

手順

  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
重要

暗号化鍵が信頼できるプライマリーキーで保護されていない場合には、ユーザーのプライマリーキー (乱数キー) を使用して暗号化した場合のセキュリティーと同程度でしかない点に注意してください。そのため、プライマリーユーザーキーはできるだけ安全に、システムの起動プロセスの早い段階で読み込む必要があります。

関連情報

23.7. Integrity Measurement Architecture および Extended Verification Module の有効化

整合性測定アーキテクチャー (IMA) および拡張検証モジュール (EVM) は、カーネル整合性サブシステムに属し、さまざまな方法でシステムセキュリティーを強化します。次のセクションでは、IMA および EVM を有効にして設定し、オペレーティングシステムのセキュリティーを強化する方法を説明します。

前提条件

  • securityfs ファイルシステムが /sys/kernel/security/ ディレクトリーにマウントされており、/sys/kernel/security/integrity/ima/ ディレクトリーが存在することを確認します。

    # mount
    …​
    securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
    …​
  • systemd サービスマネージャーに、システムの起動時に IMA および EVM に対応するパッチがすでに適用されていることを確認します。

    # dmesg | grep -i -e EVM -e IMA
    [    0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.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
    [    0.000000] kvm-clock: cpu 0, msr 23601001, primary cpu clock
    [    0.000000] Using crashkernel=auto, the size chosen is a best effort estimation.
    [    0.000000] Kernel command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.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
    [    0.911527] ima: No TPM chip found, activating TPM-bypass!
    [    0.911538] ima: Allocated hash algorithm: sha1
    [    0.911580] evm: Initialising EVM extended attributes:
    [    0.911581] evm: security.selinux
    [    0.911581] evm: security.ima
    [    0.911582] evm: security.capability
    [    0.911582] evm: HMAC attrs: 0x1
    [    1.715151] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy)
    [    3.824198] fbcon: qxldrmfb (fb0) is primary device
    [    4.673457] PM: Image not found (code -22)
    [    6.549966] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy)

手順

  1. 以下のカーネルコマンドラインパラメーターを追加します。

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="ima_policy=appraise_tcb ima_appraise=fix evm=fix"

    このコマンドは、現在のブートエントリーの fix モードで IMA および EVM を有効にしてユーザーが IMA 測定を収集し、更新できるようにします。

    ima_policy=appraise_tcb カーネルコマンドラインパラメーターにより、カーネルは、デフォルトの TCB (Trusted Computing Base) 測定ポリシーと評価手順を使用するようになります。評価部分は、以前の測定と現在の測定が一致しないファイルへのアクセスを禁止します。

  2. 再起動して変更を適用します。
  3. 必要に応じて、パラメーターがカーネルコマンドラインに追加されていることを確認します。

    # cat /proc/cmdline
    BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.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 ima_policy=appraise_tcb ima_appraise=fix evm=fix
  4. カーネルマスターキーを作成して、EVM 鍵を保護します。

    # keyctl add user kmk "$(dd if=/dev/urandom bs=1 count=32 2> /dev/null)" @u
    748544121

    カーネルマスターキー (kmk) はすべて、カーネル領域メモリーに保持されます。カーネルマスターキー kmk の 32 バイトの Long 値は、/dev/urandom ファイルの乱数バイト数から生成し、ユーザーの (@u) キーリングに配置します。鍵のシリアル番号は、前の出力の 2 行目にあります。

  5. kmk 鍵をもとに暗号化された EVM 鍵を作成します。

    # keyctl add encrypted evm-key "new user:kmk 64" @u
    641780271

    kmk を使用して 64 バイトの long 型ユーザーキー (evm-key) を生成してユーザー (@u) のキーリングに配置します。鍵のシリアル番号は、前の出力の 2 行目にあります。

    重要

    ユーザーキーの名前は evm-key (EVM サブシステムが想定して使用している名前) にする必要があります。

  6. エクスポートする鍵のディレクトリーを作成します。

    # mkdir -p /etc/keys/
  7. kmk 鍵を検索し、その値をファイルにエクスポートします。

    # keyctl pipe keyctl search @u user kmk > /etc/keys/kmk*

    このコマンドは、カーネルマスターキー (kmk) の非暗号化値を、以前に定義した場所 (/etc/keys/) にあるファイルに配置します。

  8. ユーザーキー evm-key を検索し、その値をファイルにエクスポートします。

    # keyctl pipe keyctl search @u encrypted evm-key > /etc/keys/evm-key

    このコマンドは、ユーザーの evm-key 鍵の暗号化値を、任意の場所にあるファイルに追加します。evm-key は、すでにカーネルのマスターキーにより暗号化されています。

  9. 必要に応じて、新規作成されたキーを表示します。

    # keyctl show
    Session Keyring
    974575405   --alswrv     0        0      keyring: _ses
    299489774   --alswrv     0    65534       \_ keyring: _uid.0
    748544121   --alswrv     0        0           \_ user: kmk
    641780271   --alswrv     0        0           \_ encrypted: evm-key

    同様の出力が表示されるはずです。

  10. EVM をアクティベートします。

    # echo 1 > /sys/kernel/security/evm
  11. 必要に応じて、EVM が初期化されていることを確認します。

    # dmesg | tail -1
    […​] evm: key initialized

23.8. Integrity Measurement Architecture によるファイルのハッシュの収集

Integrity Measurement Architecture (IMA) の最初の操作段階は、 Measurement フェーズです。ここでは、ファイルのハッシュを作成し、それらをファイルの拡張属性 (xattrs) として保存することができます。以下のセクションでは、ファイルのハッシュを作成し、検証する方法を説明します。

前提条件

  • Integrity Measurement Architecture (IMA) と Extended Verification Module (EVM) を「Integrity Measurement Architecture および Extended Verification Module の有効化」で説明されているように有効化する。
  • ima-evm-utilsattr、および keyutils パッケージがすでにインストールされていることを確認する。

    # yum install ima-evm-utils attr keyutils
    Updating Subscription Management repositories.
    This system is registered to Red Hat Subscription Management, but is not receiving updates. You can use subscription-manager to assign subscriptions.
    Last metadata expiration check: 0:58:22 ago on Fri 14 Feb 2020 09:58:23 AM CET.
    Package ima-evm-utils-1.1-5.el8.x86_64 is already installed.
    Package attr-2.4.48-3.el8.x86_64 is already installed.
    Package keyutils-1.5.10-7.el8.x86_64 is already installed.
    Dependencies resolved.
    Nothing to do.
    Complete!

手順

  1. テストファイルを作成します。

    # echo <Test_text> > test_file

    IMA および EVM には、サンプルファイル test_file にハッシュ値が割り当てられ、拡張属性として保存されます。

  2. ファイルの拡張属性を検証します。

    # getfattr -m . -d test_file
    # file: test_file
    security.evm=0sAnDIy4VPA0HArpPO/EqiutnNyBql
    security.ima=0sAQOEDeuUnWzwwKYk+n66h/vby3eD
    security.selinux="unconfined_u:object_r:admin_home_t:s0"

    上記の出力例では、SELinux、IMA ハッシュ値、および EVM ハッシュ値に関連する拡張属性を示しています。EVM は、security.evm 拡張属性をアクティブに追加し、ファイルのコンテンツの整合性に直接関連する security.ima などの他のファイルの xattrs に対するオフライン改ざんを検出します。security.evm フィールドの値は、evm-key ユーザーキーで生成された Hash-based Message Authentication Code (HMAC-SHA1) になります。

第24章 Ansible ロールを使用したカーネルパラメーターの永続的な設定

Red Hat Ansible Engine の詳しい知識がある経験のあるユーザーは、kernel_settings ロールを使用して、複数のクライアントにカーネルパラメーターを一度に設定することができます。この解決策は以下のとおりです。

  • 効率的な入力設定を持つ使いやすいインターフェースを提供します。
  • すべてのカーネルパラメーターを 1 か所で保持します。

コントロールマシンから kernel_settings ロールを実行すると、カーネルパラメーターはすぐに管理システムに適用され、再起動後も維持されます。

24.1. カーネル設定ロールの概要

RHEL システムロールは、複数のシステムをリモートで管理する一貫した構成インターフェースを提供するAnsible Automation Platformのロールおよびモジュールの集合です。

kernel_settings システムロールを使用してカーネルの自動設定に、RHEL システムロールが導入されました。rhel-system-roles パッケージには、このシステムロールと参考ドキュメントも含まれます。

カーネルパラメーターを自動的に 1 つ以上のシステムに適用するには、Playbook で選択したロール変数を 1 つ以上使用して、kernel_settings ロールを使用します。Playbook は人間が判読でき、YAML 形式で記述される 1 つ以上のプレイの一覧です。

インベントリーファイルを使用して、Ansible Engine が Playbook に従って設定するシステムセットを定義することができます。

kernel_settings ロールを使用して、以下を設定できます。

  • kernel_settings_sysctl ロールを使用したカーネルパラメーター
  • kernel_settings_sysfs ロールを使用したさまざまなカーネルサブシステム、ハードウェアデバイス、およびデバイスドライバー
  • systemd サービスマネージャーの CPU アフィニティーを、kernel_settings_systemd_cpu_affinity ロール変数を使用してフォーク処理します。
  • kernel_settings_transparent_hugepages および kernel_settings_transparent_hugepages_defrag のロール変数を使用したカーネルメモリーサブシステムの Transparent Huge Page

関連情報

24.2. カーネル設定ロールを使用した選択したカーネルパラメーターの適用

以下の手順に従って、Ansible Playbook を準備および適用し、複数の管理システムで永続化の影響でカーネルパラメーターをリモートに設定します。

前提条件

  • Red Hat Ansible Engine サブスクリプションが、kernel_settings ロールの実行元となる コントロールマシン とも呼ばれるシステムに割り当てられている。詳細は、「Red Hat Ansible Engine のダウンロードおよびインストールの方法」 を参照してください。
  • コントロールマシンで Ansible Engine リポジトリーが有効になっている。
  • Ansible Engine がコントロールマシンにインストールされている。

    注記

    Ansible Engine を、管理ホスト とも呼ばれるシステムにインストールする必要はありません。ここでは、カーネルパラメーターを設定する必要があります。

  • rhel-system-roles パッケージがコントロールマシンにインストールされている。
  • 管理ホストのインベントリーがコントロールマシンに存在し、Ansible Engine がそれらのホストに接続できる。

手順

  1. 必要に応じて、図の目的で inventory ファイルを確認します。

    #  cat /home/jdoe/<ansible_project_name>/inventory
    [testingservers]
    pdoe@192.168.122.98
    fdoe@192.168.122.226
    
    [db-servers]
    db1.example.com
    db2.example.com
    
    [webservers]
    web1.example.com
    web2.example.com
    192.0.2.42

    ファイルは [testingservers] グループと他のグループを定義します。これにより、特定のシステムのコレクションに対して Ansible Engine をより効果的に実行できます。

  2. Ansible Engine 操作のデフォルトおよび権限昇格を設定するための設定ファイルを作成します。

    1. 新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。

      #  vi /home/jdoe/<ansible_project_name>/ansible.cfg
    2. 以下の内容をファイルに挿入します。

      [defaults]
      inventory = ./inventory
      
      [privilege_escalation]
      become = true
      become_method = sudo
      become_user = root
      become_ask_pass = true

      [defaults] セクションは、管理対象ホストのインベントリーファイルへのパスを指定します。[privilege_escalation] セクションでは、指定した管理対象ホストのユーザー権限が root に移行されることを定義します。これは、カーネルパラメーターを正常に設定するために必要です。Ansible Playbook を実行すると、ユーザーパスワードの入力が求められます。管理対象ホストへの接続後に、sudo により root に自動的に切り替わります。

  3. kernel_settings ロールを使用する Ansible Playbook を作成します。

    1. 新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。

      #  vi /home/jdoe/<ansible_project_name>/kernel_roles.yml

      このファイルは Playbook を表し、通常は、inventory ファイルから選択した特定の管理対象ホストに対して実行される、プレイ とも呼ばれるタスクの順序付きリストが含まれます。

    2. 以下の内容をファイルに挿入します。

      ---
      - name: Configure kernel settings
        hosts: testingservers
      
        vars:
          kernel_settings_sysctl:
            - name: fs.file-max
              value: 400000
            - name: kernel.threads-max
              value: 65536
          kernel_settings_sysfs:
            - name: /sys/class/net/lo/mtu
              value: 65000
          kernel_settings_transparent_hugepages: madvise
      
        roles:
          - linux-system-roles.kernel_settings

      name キーは任意です。任意の文字列をラベルとしてプレイに関連付け、プレイの対象を特定します。プレイの hosts キーは、プレイを実行するホストを指定します。このキーの値または値は、管理対象ホストの個別名または inventory ファイルで定義されているホストのグループとして指定できます。

      vars セクションは、設定する必要がある、選択したカーネルパラメーター名および値が含まれる変数の一覧を表します。

      roles キーは、vars セクションで説明されているパラメーターおよび値を設定するシステムロールを指定します。

      注記

      必要に応じて、Playbook のカーネルパラメーターとその値を変更することができます。

  4. 必要に応じて、プレイ内の構文が正しいことを確認します。

    #  ansible-playbook --syntax-check kernel-roles.yml
    
    playbook: kernel-roles.yml

    以下の例では、Playbook の検証が成功したことを示しています。

  5. Playbook を実行します。

    #  ansible-playbook kernel-roles.yml
    BECOME password:
    
    PLAY [Configure kernel settings]  ... PLAY RECAP **
    fdoe@192.168.122.226       : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0
    pdoe@192.168.122.98        : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0

    Ansible Engine が Playbook を実行する前に、パスワードの入力を求められます。これにより、管理対象ホストのユーザーが root に切り替わります。これは、カーネルパラメーターの設定に必要です。

    recap セクションは、すべての管理対象ホストのプレイが正常に終了したこと (failed=0)、および 4 つのカーネルパラメーターが適用されたこと (changed=4) を示しています。

  6. 管理対象ホストを再起動して、影響を受けるカーネルパラメーターをチェックし、変更が適用され、再起動後も維持されていることを確認します。

関連情報