Red Hat Training

A Red Hat training course is available for RHEL 8

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

Red Hat Enterprise Linux 8

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

Red Hat Customer Content Services

概要

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

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 - コア機能に必要な最小数のカーネルモジュールが含まれます。このサブパッケージ単体は、仮想環境およびクラウド環境で使用して、Red Hat Enterprise Linux 8 カーネルのブート時間を短縮し、ディスクサイズを抑えます。
  • kernel-modules - その他のカーネルモジュールが含まれます。
  • kernel-modules-extra - まれなハードウェアのカーネルモジュールが含まれます。

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

その他の一般的なカーネルパッケージの例を以下に示します。

  • kernel-debug - カーネル診断用に有効なデバッグオプションが多数含まれるカーネルが含まれます。ただし、パフォーマンスが犠牲になります。
  • kernel-tools - Linux カーネルを操作するツールやサポートドキュメントが含まれます。
  • kernel-devel - kernel パッケージに対してモジュールを構築するのに十分なカーネルヘッダーと 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
    …​

関連情報

  • 既にインストールしている kernel RPM (サブパッケージを含む) で rpm コマンドを使用する方法は、man ページの rpm(8) を参照してください。
  • RPM パッケージの概要

第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 8 へのアップグレード』の関連のセクションを参照してください。

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

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

手順

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

    # yum install kernel-{version}

関連情報

  • 利用可能なカーネルの一覧は、「Red Hat Code Browser」を参照してください。
  • 特定のカーネルバージョンのリリース日の一覧は、この記事を参照してください。

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

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

3.1. モジュールの紹介

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

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

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

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

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

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

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

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

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

警告

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

関連情報

  • /lib/modules/<KERNEL_VERSION>/modules.dep の詳細は、modules.dep(5) の man ページを参照してください。
  • depmod の概要やオプションの詳細は、man ページの depmod(8) を参照してください。

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

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

前提条件

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

    上記の例:

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

関連情報

  • kmod の詳細は、/usr/share/doc/kmod/README ファイルまたは lsmod (8) man ページを参照してください。

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

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

前提条件

  • 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 の詳細は、man ページの modinfo(8) を参照してください。

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

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 の詳細は、man ページの modprobe(8) を参照してください。

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

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

前提条件

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

手順

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

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

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

    # modprobe -r <MODULE_NAME>

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

    警告

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

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

    $ lsmod | grep <MODULE_NAME>

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

重要

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

関連情報

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

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

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

前提条件

  • 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>

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

重要

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

関連情報

  • システムの起動プロセス中のカーネルモジュールの読み込みの詳細は、man ページの modules-load.d (5) を参照してください。

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

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

前提条件

  • 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 ユーティリティの詳細は dracut(8) man ページを参照してください。

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

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

重要

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

4.1. カーネルコマンドラインパラメーターの設定

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

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

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

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

注記

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

関連情報

  • 変更可能なカーネルコマンドラインパラメーターの詳細は、man ページの kernel-command-line(7)bootparam(7)、および dracut.cmdline (7) を参照してください。

4.2. grubby とは

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

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

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

4.3. ブートエントリーの概要

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

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 ファイルで定義されます。

4.4. カーネルコマンドラインパラメーターの設定

本セクションでは、AMD64 および Intel 64 アーキテクチャー、64 ビット ARM アーキテクチャー、ならびに IBM Power Systems のリトルエンディアンバリアントでカーネルコマンドラインパラメーターを変更する方法を説明します。

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

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

手順

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

    # vim /etc/default/grub
    GRUB_TIMEOUT=5
    GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
    GRUB_DEFAULT=saved
    GRUB_DISABLE_SUBMENU=true
    GRUB_TERMINAL_OUTPUT="console"
    GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet"
    GRUB_DISABLE_RECOVERY="true"
    GRUB_ENABLE_BLSCFG=true
  2. GRUB_CMDLINE_LINUX の行でパラメーターの追加、編集、または削除を行います。
  3. GRUB2 設定ファイルを更新します。

    # grub2-mkconfig -o /boot/grub2/grub.cfg
  4. システムを再起動して、変更を有効にします。

その結果、ブートローダーが再設定され、指定したカーネルコマンドラインパラメーターが適用されます。

関連情報

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

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

前提条件

手順

  • パラメーターを追加するには、以下のコマンドを実行します。

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="<NEW_PARAMETER>"
  • パラメーターを削除するには、以下のコマンドを使用します。

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --remove-args="<PARAMETER_TO_REMOVE>"
注記

デフォルトでは、各カーネルブートエントリーに options パラメーターがあり、これは kernelopts 変数に設定されます。この変数は、/boot/grub2/grubenv 設定ファイルで定義されます。

重要

grubby ユーティリティーを使って特定のブートエントリーを修正すると、編集した kernelopts の内容は /boot/loader/entries/<RELEVANT_KERNEL_BOOT_ENTRY.conf> の関連カーネルブートエントリーに格納され、/boot/grub2/grubenv で設定した kernelopts の値が上書きされます。

関連情報

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

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

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

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

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

+ *sysctl コマンド * /proc/sys/ ディレクトリーにマウントした仮想ファイルシステム * /etc/sysctl.d/ ディレクトリー内の設定ファイル

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

表5.1 sysctl クラスの表

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

abi

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

crypto

暗号化インターフェース

debug

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

dev

デバイス固有の情報

fs

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

kernel

グローバルなチューニング可能なカーネル

net

チューニング可能なネットワーク

sunrpc

Sun Remote Procedure Call (NFS)

user

ユーザー名前空間の制限

vm

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

関連情報

  • sysctl の詳細は、sysctl(8) の man ページのを参照してください。
  • /etc/sysctl.d/ の詳細は、man ページの sysctl.d(5) を参照してください。

5.2. ランタイム時のカーネルパラメーターの設定

重要

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

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

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

前提条件

手順

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

    # sysctl -a
    注記

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

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

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

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

    注記

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

関連情報

  • sysctl の詳細は、man ページの sysctl(8) を参照してください。
  • カーネルパラメーターを永続的に変更するには、sysctl コマンドを使用して、/etc/sysctl.conf ファイルに値を書き込みするか、/etc/sysctl.d/ ディレクトリーの設定ファイルに手動で変更を行います。

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

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

前提条件

手順

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

    # sysctl -a

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

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

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

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

注記

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

関連情報

  • sysctl の詳細は、man ページの sysctl(8)sysctl.conf (5) を参照してください。
  • カーネルパラメーターに永続的な変更を行うための、/etc/sysctl.d/ ディレクトリーで設定ファイルを使用することについての情報は、/etc/sysctl.d/ で設定ファイルでカーネルパラメーターの調整セクションを参照してください。

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

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

前提条件

手順

  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 の詳細は、man ページの sysctl(8) を参照してください。
  • /etc/sysctl.d/ の詳細は、man ページの sysctl.d(5) を参照してください。

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

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

前提条件

手順

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

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

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

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

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

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

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

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

関連情報

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

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

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

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

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

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

関連情報

  • ソフトロックアップにまつわる技術的な理由、ログメッセージの例、その他の詳細は、ナレッジベースの記事「CPU ソフトロックアップ」を参照してください。

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

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

softlockup_panic

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

効果

整数

0

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

整数

1

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

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

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

nmi_watchdog

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

効果

0

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

1

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

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

watchdog_thresh

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

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

10 秒

2 * watchdog_thresh

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

関連情報

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

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

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

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

重要

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

関連情報

5.4. データベースサーバーのカーネルパラメーターの調整

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

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

データベースサーバーは、一定量のメインメモリーとデータベース (DB) アプリケーションがインストールされているハードウェアデバイスです。このデータベースアプリケーションは、通常、小さくて高価なメインメモリーから DB ファイル (データベース) にキャッシュされたデータを書き込む手段としてサービスを提供します。サービスは、ネットワーク上の複数のクライアントに提供されます。利用できるデータベースサーバーの数は、マシンのメインメモリーおよびストレージにより異なります。

Red Hat Enterprise Linux 8 は、以下のデータベースアプリケーションを提供します。

  • MariaDB 10.3
  • MySQL 8.0
  • PostgreSQL 10
  • PostgreSQL 9.6

5.4.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 秒単位で測定されます。

関連情報

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

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

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

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

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

関連情報

  • syslog の詳細は、man ページの syslog(2) を参照してください。
  • dmesg で起動ログメッセージを確認または制御する方法は、man ページの dmesg(1) を参照してください。

6.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. 値。起動時のコンソールのログレベルのデフォルト値を設定します。

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

注記

quietdebug などの特定のカーネルコマンドラインパラメーターは、デフォルトの kernel.printk 値を変更します。

関連情報

  • kernel.printk およびログレベルの詳細は、man ページの syslog(2) を参照してください。

第7章 kdump のインストールと設定

7.1. kdump とは

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

重要

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

7.2. kdump のインストール

多くの場合、kdump サービスは、新しい Red Hat Enterprise Linux インストールにデフォルトでインストールされ、アクティベートされます。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 カーネルが応答しなくなる可能性が高くなります。

関連情報

7.3. コマンドラインで kdump の設定

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

kdump 機能に予約されているメモリーは、システムの起動時には常に予約されています。メモリーの量は、システムの GRUB (Grand Unified Bootloader) 2 設定で指定します。以下の手順では、コマンドラインから 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 ユーティリティーを使用して、単一のエントリーのカーネルコマンドラインパラメーターを更新することもできます。

関連情報

  • crashkernel= オプションは、複数の方法で定義できます。「kdump メモリー要件」で説明されているガイドラインに従い、auto 値を指定すると、システムの合計メモリーに基づいた、予約メモリーの自動設定が可能になります。
  • ブートエントリー、kerneloptsgrub2-editenv および grubby での作業方法は、4章カーネルコマンドラインパラメーターの設定を参照してください。

7.3.2. kdump ターゲットの設定

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

前提条件

手順

コアダンプを保存するローカルディレクトリーを変更するには、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

関連情報

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

kdump は、コアコレクター として指定されたプログラムを使用して vmcore をキャプチャーします。現在、完全に対応している コアコレクターmakedumpfile ユーティリティーのみです。これにはいくつかの設定可能なオプションがあり、コレクションプロセスに影響します。たとえば、収集したデータのエクステントや、生成される vmcore を圧縮すべきかどうかなどです。

コアコレクター を有効にして設定するには、次の手順を実行します。

前提条件

  • kdump 要件 を満たす。

手順

  1. root で、/etc/kdump.conf 設定ファイルを編集し、#core_collector makedumpfile -l --message-level 1 -d 31 の行頭にあるハッシュ記号 ("#") を削除します。
  2. -c パラメーターを追加します。以下に例を示します。

    core_collector makedumpfile -c

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

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

    core_collector makedumpfile -d 17 -c

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

関連情報

  • 利用可能なオプションの完全な一覧は、makedumpfile(8) man ページを参照してください。

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

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

前提条件

  • kdump 要件 を満たす。

手順

  1. root で、/etc/kdump.conf 設定ファイルの #default shell の行頭にあるハッシュ記号 ("#") を削除します。
  2. 「対応しているデフォルトの障害応答」の説明どおり、値を希望のアクションに置き換えます。以下に例を示します。

    default poweroff

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

関連情報

  • systemd の詳細と一般的なサービスの設定は、Red Hat Enterprise Linux の「基本的なシステム設定」を参照してください。

7.4. Web コンソールで kdump の設定

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

前提条件

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

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

関連情報

7.5. サポートしている kdump の設定とダンプ出力先

7.5.1. kdump メモリー要件

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

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

$ uname -m

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

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

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

AMD64 と Intel 64 (x86_64)

1 GB から 64 GB

160 MB のメモリー

 

64 GB から 1 TB

256 MB のメモリー

 

1TB 以上

512 MB のメモリー

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

2 GB 以上

512 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)

4 GB から 64 GB

160 MB のメモリー

 

64 GB から 1 TB

256 MB のメモリー

 

1TB 以上

512 MB のメモリー

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

重要

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

関連情報

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

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

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

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

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

AMD64 と Intel 64 (x86_64)

2 GB

IBM Power Systems (ppc64le)

2 GB

IBM  Z (s390x)

4 GB

関連情報

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

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

表7.3 対応している kdump のダンプ出力先

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

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 が通常の起動にも使用されるため、実稼働環境のカーネルのインターフェース名も変更されます。

関連情報

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

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

表7.4 サポートしているフィルターレベル

オプション説明

1

ゼロページ

2

キャッシュページ

4

キャッシュプライベート

8

ユーザーページ

16

フリーページ

注記

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

関連情報

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

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

表7.5 サポートしているデフォルトの動作

オプション説明

dump_to_rootfs

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

reboot

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

halt

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

poweroff

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

shell

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

関連情報

7.5.6. 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 のサイズのページを使用します。

7.6. 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 ファイルが作成されます。

    注記

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

7.7. コアダンプの分析

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

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

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

手順

  1. 関連する baseos リポジトリーおよび appstream リポジトリーを有効にします。

    # subscription-manager repos --enable baseos repository
    # subscription-manager repos --enable appstream repository
  2. crash パッケージをインストールします。

    # yum install crash
  3. kernel-debuginfo パッケージをインストールします。

    # yum install kernel-debuginfo

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

関連情報

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

      例7.1 crash ユーティリティーの実行

      以下の例は、4.18.0-5.el8.x86_64 カーネルを使用して、2018 年 10 月 6 日 (14:05 PM) に作成されたコアダンプの分析を示しています。

      ...
      WARNING: kernel relocated [202MB]: patching 90160 gdb minimal_symbol values
      
            KERNEL: /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux
          DUMPFILE: /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore  [PARTIAL DUMP]
              CPUS: 2
              DATE: Sat Oct  6 14:05:16 2018
            UPTIME: 01:03:57
      LOAD AVERAGE: 0.00, 0.00, 0.00
             TASKS: 586
          NODENAME: localhost.localdomain
           RELEASE: 4.18.0-5.el8.x86_64
           VERSION: #1 SMP Wed Aug 29 11:51:55 UTC 2018
           MACHINE: x86_64  (2904 Mhz)
            MEMORY: 2.9 GB
             PANIC: "sysrq: SysRq : Trigger a crash"
               PID: 10635
           COMMAND: "bash"
              TASK: ffff8d6c84271800  [THREAD_INFO: ffff8d6c84271800]
               CPU: 1
             STATE: TASK_RUNNING (SYSRQ)
      
      crash>
  2. 対話型プロンプトを終了して crash を終了するには、crash または q を使用します。

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

    crash> exit
    ~]#
注記

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

7.7.3. crash ユーティリティーでのメッセージバッファー、バックトレース、およびその他のインジケーターの表示

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

メッセージバッファーの表示
  • カーネルメッセージバッファーを表示するには、以下の例で示されているように対話式プロンプトで log コマンドを実行します。

    例7.3 カーネルメッセージバッファーの表示

    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/ あります。

7.7.3.1. バックトレースの表示

  • カーネルスタックトレースを表示するには、bt コマンドを使用します。

    例7.4 カーネルスタックトレースの表示

    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 の使用についての詳細を表示します。

7.7.3.2. プロセスの状態表示

  • システム内のプロセスの状態を表示するには、ps コマンドを使用します。

    例7.5 システム内のプロセスの状態表示

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

7.7.3.3. 仮想メモリー情報の表示

  • 基本的な仮想メモリー情報を表示するには、対話式プロンプトで vm コマンドを入力します。

    例7.6 現在のコンテキストの仮想メモリー情報の表示

    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 の使用方法を表示します。

7.7.3.4. オープンファイルの表示

  • オープンファイルの情報を表示するには、files コマンドを実行します。

    例7.7 現在のコンテキストのオープンファイルについての情報の表示

    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 の使用方法を表示します。

7.7.4. Kernel Oops Analyzer の使用

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

前提条件

  • Red Hat Labs の手順に従って、oops メッセージを保護し、Kernel Oops Analyzer に入力します。

手順

  1. Kernel Oops Analyzer リンクに従って、ツールにアクセスします。
  2. 参照を押して、oops メッセージを参照します。

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

関連情報

  • kdump.conf(5) - 利用できるオプションの完全なドキュメンテーションを含む /etc/kdump.conf 設定ファイルの man ページ。
  • zipl.conf(5): /etc/zipl.conf 設定ファイルの man ページです。
  • zipl(8) - IBM System z 用の zipl ブートローダーユーティリティーの man ページ。
  • makedumpfile(8) - makedumpfile コアコレクターの man ページ。
  • kexec(8) — kexec の man ページ。
  • crash(8) — crash ユーティリティの man ページ。
  • /usr/share/doc/kexec-tools/kexec-kdump-howto.txtkdumpkexec インストールと使用の概要。
  • kexeckdump 設定の詳細は、『Red Hat ナレッジベース記事』を参照してください。
  • 対応している kdump ターゲットの詳細は、『Red Hat ナレッジベース記事』を参照してください。

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

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

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

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

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

警告

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

8.1. kpatch の制限

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rhel kpatch の概要

8.6. カーネルライブパッチの有効化

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

以下のセクションでは、指定のカーネルに対して、将来のすべての累積パッチの更新を受け取る方法を説明します。

警告

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

8.6.1. ライブパッチストリームへのサブスクライブ

この手順では、特定のライブパッチパッケージをインストールする方法を説明します。そうすることで、指定のカーネルのライブパッチストリームをサブスクライブし、今後のカーネルに対する累計なライブパッチ更新をすべて受けることができます。

警告

ライブパッチは累積的であるため、特定のカーネルにデプロイされている個々のパッチを選択できません。

前提条件

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

関連情報

  • kpatch コマンドラインユーティリティーの詳細は、man ページの kpatch(1) を参照してください。
  • Red Hat Enterprise Linux 8 のソフトウェアパッケージの詳細は、「基本的なシステム設定の構成」の関連のセクションを参照してください。

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

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

前提条件

手順

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

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

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

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

    # yum update "kpatch-patch*"
注記

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

関連情報

8.8. カーネルライブパッチの無効化

システム管理者が、Red Hat Enterprise Linux カーネルライブパッチソリューション関連の不足の悪影響に遭遇した場合は、このメカニズムを無効化する選択肢があります。以下のセクションでは、ライブパッチソリューションを無効にする方法を説明します。

重要

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

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

以下の手順は、ライブパッチパッケージを削除して、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:

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

関連情報

  • kpatch コマンドラインユーティリティーの詳細は、man ページの kpatch(1) を参照してください。
  • ソフトウェアパッケージの使用方法は、「基本的なシステム設定の構成」 の関連のセクションを参照してください。

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

以下の手順では、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:
    …​

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

関連情報

  • kpatch コマンドラインユーティリティーの詳細は、man ページの kpatch(1) を参照してください。

8.8.3. 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)

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

関連情報

  • kpatch コマンドラインユーティリティーの詳細は、man ページの kpatch(1) を参照してください。
  • systemd システムおよびサービスマネージャー、ユニット設定ファイル、その場所、および systemd ユニットタイプの完全なリストの詳細は、「基本的なシステム設定の構成」 の関連のセクションを参照してください。

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

システム管理者として、コントロールグループのカーネル機能を使用して制限を設定し、プロセスのハードウェアリソースの優先または分離を行い、システム上のアプリケーションが安定し、メモリーが不足しないようにします。

9.1. コントロールグループとは

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

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

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

9.1.1. コントロールグループ 1

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

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

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

9.1.2. コントロールグループ 2

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

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

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

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

警告

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

関連情報

  • リソースコントローラーの詳細は「What are kernel resource controllers」セクションおよび cgroups (7) man ページを参照してください。
  • cgroups の階層と cgroups バージョンの詳細は、cgroups(7) man ページを参照してください。

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

本セクションでは、Linux カーネルにおけるリソースコントローラーの概念を説明し、Red Hat Enterprise Linux 8 で、コントロールグループバージョン 1 (cgroups-v1) およびコントロールグループバージョン 2 (cgroups-v2) でサポートされるコントローラーを一覧表示します。

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

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

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

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

  • io - cgroups-v1blkio へのフォローアップ
  • memory - cgroups-v1メモリー へのフォローアップ
  • pids - cgroups-v1pids と同じ
  • RDMA - cgroups-v1rdma と同じ
  • cpu - cpu - cgroups-v1cpucpuacct へのフォローアップ。
重要

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

関連情報

  • 一般的なリソースコントローラーの詳細は、cgroups(7) man ページを参照してください。
  • 特定のリソースコントローラーの詳細は、/usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/ ディレクトリーのドキュメントを参照してください。
  • cgroups-v2 の詳細は、cgroups(7) man ページを参照してください。

9.3. 名前空間とは

このセクションでは、名前空間の概念と、制御グループおよびリソース管理へのつながりついて説明します。

名前空間は、/proc/self/ns/cgroup インターフェースを介して、分離したシステムリソースの仮想ビューを有効にするカーネル機能です。システムリソースからプロセスを分離することで、プロセスが対話できるものを指定および制御できます。

この目的は、グローバルな名前空間から cgroup への特権付きデータの漏えいを回避し、コンテナーマイグレーションなどの他の機能を有効にすることです。

次の名前空間を利用できます。

  • Mount

    • マウント名前空間は、ファイルシステムのマウントポイントを分離します。これにより各プロセスは明確なファイルシステム領域を持つことができ、その領域内で操作します。
  • UTS

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

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

    • プロセス ID
  • Network

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

    • ユーザーおよびグループ ID
  • Control groups

    • cgroup の分離

関連情報

  • 名前空間の詳細は、namespace(7) および cgroup_namespaces (7) manページを参照してください。
  • cgroups の詳細は、「コントロールグループとは」を参照してください。

9.4. 仮想ファイルシステムによるコントロールグループの使用

以下のセクションでは、/sys/fs/ 仮想ファイルシステムを使用した、コントロールグループ (cgroup) の作成、修正、および削除に関連するタスクの概要を説明します。

9.4.1. cgroups-v1 でアプリケーションのメモリー制限の設定

この手順では、/sys/fs/ 仮想ファイルシステムを使用して、コントロールグループバージョン 1 (cgroups-v1) でアプリケーションのメモリー制限を設定する方法を説明します。

前提条件

手順

  1. メモリーリソースコントローラーディレクトリーにサブディレクトリーを作成します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連情報



[1] Linux Control Group v2 - An Introduction, Devconf.cz 2019 presentation by Waiman Long
[2] Linux Control Group v2 - An Introduction, Devconf.cz 2019 presentation by Waiman Long

第10章 BPF コンパイラーコレクションでシステムパフォーマンスの分析

システム管理者として BPF コンパイラーコレクション (BCC) ライブラリーを使用して、Linux オペレーティングシステムのパフォーマンスを分析するツールを作成します。ただし、これはその他のインターフェースを介して取得するのは困難かもしれません。

重要

BCC ライブラリーは、AMD および Intel 64 ビットのアーキテクチャーでのみ完全に対応しています。他のすべてのアーキテクチャーでは、BCC はテクノロジープレビューのままです。詳細は「テクノロジープレビュー機能のサポート範囲」を参照してください。

10.1. BCC

BPF コンパイラーコレクション (BCC) は、eBPF (extended Berkeley Packet Filter) プログラムの作成を容易にするライブラリーです。これらの主なユーティリティーは、オーバーヘッドやセキュリティー上の問題が発生することなく、OS のパフォーマンスおよびネットワークパフォーマンスを分析するものです。

BCC により、ユーザーは eBPF の技術詳細を把握する必要がなくなり、事前に作成した eBPF プログラムを含む bcc-tools パッケージなど、多くの標準スタートポイントを利用できます。

注記

eBPF プログラムは、ディスク I/O、TCP 接続、プロセス作成などのイベントでトリガーされます。プログラムがカーネルのセーフ仮想マシンで実行するため、カーネルがクラッシュしたり、ループしたり、応答しなくなることはあまりありません。

関連情報

  • BCC の詳細は、/usr/share/doc/bcc/README.md ファイルを参照してください。

10.2. NFS のインストール

このセクションでは、BCC (BPF コンパイラーコレクション) ライブラリーを含む bcc-tools パッケージをインストールする方法を説明します。

手順

  1. bcc-tools をインストールします。

    # yum install bcc-tools

    インストールが完了すると、ツールは /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 ディレクトリーには、各ツールのドキュメントが含まれます。

10.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 などの非常に短期間に実行されるプログラムのプロセスを検出します。なお、ほとんどの監視ツールはそれらを登録しません。

    上記の結果は、親プロセス名 (ls)、プロセス ID (5076)、親プロセス ID (2931)、exec() システム呼び出しの戻り値 (0) を示しています。これは、プログラムコードを新規プロセスに読み込みます。最後に、出力は引数 (/usr/bin/ls --color=auto /usr/share/bcc/tools/doc/) で起動したプログラムの場所を表示します。

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 が開こうとしたファイルごとに出力行を出力します。

    上記の結果は、プロセス ID (PID)、プロセス名 (COMM)、およびファイル記述子 (FD) を表示します。open() が返す値は、開いているファイルを参照してください。最後に、出力にはエラー (ERR) のコラムと、open() が開こうとする場所 (PATH) が表示されます。

    コマンドが、存在しないファイルを読み込もうとすると、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
    ...

    この結果から、プロセス ID 9568 の、vda ディスクから 16,294 の読み取り操作が実行された dd プロセスがわかります。読み取り操作の合計は 14,440,636 KB に達し、平均 I/O 時間は 3.69 ms になりました。

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 は、ファイルシステムの問題の明確化に適しており、動作が予期せずに低速になります。

    T コラムは操作タイプ (Read/Write/Sync) を表し、OFF_KB は KB 内のファイルオフセットです。FILENAME は、プロセス (COMM) が読み取り、書き込み、または同期を試行するファイルです。

xfsslower の詳細、例、およびオプションについては、/usr/share/bcc/tools/doc/xfsslower_example.txt ファイルを参照してください。

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

第11章 カーネル整合性サブシステムによるセキュリティーの強化

カーネル整合性サブシステムのコンポーネントを利用することにより、システムの保護を強化できます。以下のセクションでは、関連するコンポーネントを紹介し、その構成に関するガイダンスを提供します。

11.1. カーネル整合性サブシステム

整合性サブシステムは、ローカルファイルの測定値を収集し、測定値を正しい値と比較し、さまざまなファイル整合性ポリシーを適用するカーネルの一部です。

カーネル整合性サブシステムは、2 つの主要なコンポーネントで構成されています。

  • 完全性測定アーキテクチャー (IMA)
  • 拡張検証モジュール (EVM)

また、IMA 評価、デジタル署名検証、監査測定ログ (監査サブシステム) など、IMA と EVM の両方に多数の機能拡張が存在します。

注記

監査サブシステムを明示的に有効にして、カーネル整合性サブシステム内から実行される操作を追跡できます。

カーネル整合性サブシステムは、TPM (Trusted Platform Module) を利用して、システムのセキュリティーをさらに強化できます。TPM は、コンピューターチップに適用される重要な暗号化機能に関する TCG (Trusted Computing Group) による仕様です。TPM は通常、CPU とマザーボード自体に組み込まれ、ハードウェアチップの保護された改ざん防止領域から暗号化機能を提供することにより、ソフトウェアベースの攻撃を防ぎます。TPM 機能の一部は次のとおりです。

  • 乱数ジェネレーター
  • 暗号化キーのジェネレーターと安全なストレージ
  • ハッシュジェネレーター
  • リモート認証

関連情報

11.2. 完全性測定アーキテクチャー

Integrity Measurement Architecture (IMA) は、カーネル整合性サブシステムのコンポーネントです。IMA は、ローカルファイルのコンテンツを維持することを目的としています。具体的には、IMA はアクセスされる前にファイルのハッシュを測定、保存、評価します。これにより、信頼できないデータの読み取りと実行が防止されます。これにより、IMA はシステムのセキュリティーを強化します。

11.3. 拡張検証モジュール

拡張検証モジュール (EVM) は、ファイルの拡張属性 (xattr) の変更を監視するカーネル整合性サブシステムのコンポーネントです。Integrity Measurement Architecture (IMA) を含む多くのセキュリティー指向のテクノロジーは、コンテンツハッシュなどの機密ファイル情報を拡張属性に保存します。EVM は、この拡張属性と特別なキーから別のハッシュを作成します。これはシステムの起動時に読み込まれます。結果のハッシュは、拡張属性が使用されるたびに検証されます。たとえば、IMA がファイルを評価する場合です。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.