Red Hat Training
A Red Hat training course is available for RHEL 8
カーネルの管理、監視、および更新
Red Hat Enterprise Linux 8 上で Linux カーネルを管理するためのガイド
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
Red Hat ドキュメントへのフィードバック (英語のみ)
当社のドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
特定の文章に関するコメントの送信
- Multi-page HTML 形式でドキュメントを表示し、ページが完全にロードされてから右上隅に Feedback ボタンが表示されていることを確認します。
- カーソルを使用して、コメントを追加するテキスト部分を強調表示します。
- 強調表示されたテキストの近くに表示される Add Feedback ボタンをクリックします。
- フィードバックを追加し、Submit をクリックします。
Bugzilla からのフィードバック送信 (アカウントが必要)
- Bugzilla の Web サイトにログインします。
- Version メニューから正しいバージョンを選択します。
- Summary フィールドにわかりやすいタイトルを入力します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- Submit Bug をクリックします。
第1章 Linux カーネル
Linux カーネルと、Red Hat が提供および管理する Linux カーネル RPM パッケージ (Red Hat カーネル) について学びます。Red Hat カーネルを最新の状態に保ちます。これにより、オペレーティングシステムに最新のバグ修正、パフォーマンス強化、およびパッチがすべて適用され、新しいハードウェアとの互換性が保たれます。
1.1. カーネルとは
カーネルは Linux オペレーティングシステムのコア部分で、システムリソースを管理し、ハードウェアアプリケーションおよびソフトウェアアプリケーション間のインターフェイスを確立します。Red Hat カーネルは、アップストリームの Linux メインラインカーネルをベースにしたカスタムカーネルです。Red Hat のエンジニアは、安定性と、最新のテクノロジーおよびハードウェアとの互換性に重点を置き、さらなる開発と強化を行っています。
Red Hat が新しいカーネルバージョンをリリースする前に、カーネルは厳格な品質保証テストをクリアしなければなりません。
Red Hat カーネルは RPM 形式でパッケージ化されているため、yum パッケージマネージャーにより簡単にアップグレードおよび検証できます。
Red Hat によってコンパイルされていないカーネルは、Red Hat ではサポートされていません。
1.2. RPM パッケージ
RPM パッケージは、他のファイルとそのメタデータ (システムが必要とするファイルに関する情報) を含むファイルです。
特に、RPM パッケージは cpio
アーカイブで設定されています。
cpio
アーカイブには以下が含まれます。
- ファイル
RPM ヘッダー (パッケージのメタデータ)
rpm
パッケージマネージャーはこのメタデータを使用して依存関係、ファイルのインストール先、およびその他の情報を決定します。
RPM パッケージの種類
RPM パッケージには 2 つの種類があります。いずれも、同じファイル形式とツールを使用しますが、コンテンツが異なるため、目的が異なります。
ソース RPM (SRPM)
SRPM には、ソースコードと SPEC ファイルが含まれます。これには、ソースコードをバイナリー RPM にビルドする方法が書かれています。必要に応じて、ソースコードへのパッチも含まれます。
バイナリー RPM
バイナリー RPM には、ソースおよびパッチから構築されたバイナリーが含まれます。
1.3. 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-devel
—kernel
パッケージに対して、モジュールを構築するのに十分なカーネルヘッダーと makefiles を含んでいます。 -
kernel-abi-stablelists
— RHEL カーネル ABI に関連する情報が含まれています。これには、強化を支援するための外部 Linux カーネルモジュールおよびyum
プラグインで必要なカーネルシンボルの一覧が含まれます。 -
kernel-headers
— Linux カーネルと、ユーザー空間ライブラリーおよびプログラムとの間のインターフェイスを指定する C ヘッダーファイルが含まれます。ヘッダーファイルは、ほとんどの標準プログラムを構築するのに必要な構造と定数を定義します。
1.4. カーネルパッケージの内容の表示
rpm
コマンドを使用してインストールせずに、カーネルパッケージとそのサブパッケージの内容を表示します。
前提条件
-
使用している CPU アーキテクチャー用の
kernel
、kernel-core
、kernel-modules
、kernel-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 …
関連情報
-
rpm(8)
man ページ - RPM パッケージ
1.5. カーネルの更新
yum パッケージマネージャーを使用してカーネルを更新します。
手順
カーネルを更新するには、次のコマンドを入力します。
# yum update kernel
このコマンドは、カーネルと、利用可能な最新バージョンへのすべての依存関係を更新します。
- システムを再起動して、変更を有効にします。
RHEL 7 から RHEL 8 にアップグレードする場合は、RHEL 7 から RHEL 8 へのアップグレード ドキュメントの関連のセクションを参照してください。
関連情報
1.6. 特定のカーネルバージョンのインストール
yum パッケージマネージャーを使用して新しいカーネルをインストールします。
手順
特定のカーネルバージョンをインストールするには、次のコマンドを実行します。
# yum install kernel-{version}
第2章 カーネルモジュールの管理
カーネルモジュール、それらの情報を表示する方法、およびカーネルモジュールを使用して基本的な管理タスクを実行する方法について学びます。
2.1. モジュールの紹介
Red Hat Enterprise Linux カーネルは、システムを再起動しなくても、カーネルモジュールと呼ばれる追加機能で拡張できます。Red Hat Enterprise Linux 8 では、カーネルモジュールは追加のカーネルコードで、圧縮された <KERNEL_MODULE_NAME>.ko.xz
オブジェクトファイルに組み込まれています。
カーネルモジュールにより有効になっている最も一般的な機能は、以下のとおりです。
- 新しいハードウェアへのサポートを強化するデバイスドライバー
-
GFS2
やNFS
などのファイルシステムのサポート - システムコール
最新のシステムでは、必要に応じて自動的にカーネルモジュールが読み込まれます。ただし、場合によっては、モジュールを手動でロードまたはアンロードする必要があります。
モジュールは、カーネル自体と同様に、必要に応じてその動作をカスタマイズするパラメーターを受けることができます。
ツールでは、現在実行しているモジュール、カーネルに読み込みできるモジュール、モジュールが受け入れるパラメーターを調べることができます。このツールは、実行中のカーネルに、カーネルモジュールのロードおよびアンロードを行うためのメカニズムを提供します。
2.2. カーネルモジュールの依存関係
特定のカーネルモジュールは、複数の他のカーネルモジュールに依存する場合があります。/lib/modules/<KERNEL_VERSION>/modules.dep
ファイルには、各カーネルバージョンに対するカーネルモジュールの依存関係の完全な一覧が含まれます。
depmod
依存関係ファイルは、kmod
パッケージの一部である depmod
プログラムにより生成されます。kmod
によるユーティリティーの多くは、操作を実行する際にモジュールの依存関係を考慮に入れるため、手動 で依存関係を追跡する必要はほとんどありません。
カーネルモジュールのコードは、制限のないモードのカーネルスペースで実行されます。そのため、読み込むモジュールに注意してください。
weak-modules
depmod
に加えて、Red Hat Enterprise Linux は、同じく kmod
パッケージに同梱されている weak-modules
スクリプトを提供します。weak-modules
は、どのモジュールがインストールされたカーネルと kABI 互換であるかを決定します。モジュールカーネルの互換性をチェックしている間、weak-modules
はモジュールシンボルの依存関係を、それらがビルドされたカーネルの上位リリースから下位リリースへと処理します。これは、weak-modules
がビルド対象のカーネルリリースとは無関係に各モジュールを処理することを意味します。
関連情報
-
modules.dep (5)
man ページ -
depmod (8)
man ページ - Red Hat Enterprise Linux に同梱されている weak-modules スクリプトの目的は何ですか?
- カーネルアプリケーションバイナリーインターフェイス (kABI) とは何ですか?
2.3. インストール済みカーネルモジュールの一覧表示
grubby --info=ALL
コマンドは、!BLS
インストールおよび BLS
インストールにインストールされたカーネルのインデックスリストを表示します。
手順
以下のコマンドを使用して、インストールされているカーネルを一覧表示します。
# 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)
上記の例では、GRUB メニューから grubby-8.40-17 のインストール済みカーネルの一覧を表示します。
2.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 ページ
2.5. インストール済みカーネルの一覧表示
grubby
ユーティリティーを使用して、システムにインストールされているすべてのカーネルを一覧表示します。
前提条件
- root 権限がある。
手順
インストールされているすべてのカーネルを一覧表示するには、次のコマンドを実行します。
# grubby --info=ALL | grep ^kernel kernel="/boot/vmlinuz-4.18.0-305.10.2.el8_4.x86_64" kernel="/boot/vmlinuz-4.18.0-240.el8.x86_64" kernel="/boot/vmlinuz-0-rescue-41eb2e172d7244698abda79a51778f1b"
この出力には、インストールしたすべてのカーネルのパスと、各バージョンが表示されます。
関連情報
2.6. カーネルのデフォルトとしての設定
grubby
コマンドラインツールと GRUB を使用して、特定のカーネルをデフォルトとして設定します。
手順
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/
ディレクトリーに手動で追加すると、インデックス値が変更される可能性があります。
2.7. モジュール情報の表示
modinfo
コマンドを使用して、指定したカーネルモジュールに関する詳細情報を表示します。
前提条件
-
kmod
パッケージがインストールされている。
手順
カーネルモジュールの情報を表示するには、以下を実行します。
$ modinfo <KERNEL_MODULE_NAME>
以下に例を示します。
$ 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
読み込まれているかどうかに関わらず、利用可能なすべてのモジュールの情報を照会できます。
parm
エントリーは、ユーザーがモジュールに設定できるパラメーターと、期待される値のタイプを示します。注記カーネルモジュールの名前を入力する際には、
.ko.xz
拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。
関連情報
-
modinfo(8)
の man ページ
2.8. システムランタイム時のカーネルモジュールの読み込み
Linux カーネルの機能を拡張する最適な方法は、カーネルモジュールを読み込むことです。modprobe
コマンドを使用して、カーネルモジュールを検出し、現在実行しているカーネルに読み込みます。
前提条件
- root 権限
-
kmod
パッケージがインストールされている。 - 関連のカーネルモジュールが読み込まれていない。これを確認するには、読み込まれているカーネルモジュール を一覧表示します。
手順
読み込むカーネルモジュールを選択します。
モジュールは
/lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/
ディレクトリーにあります。関連するカーネルモジュールを読み込みます。
# modprobe <MODULE_NAME>
注記カーネルモジュールの名前を入力する際には、
.ko.xz
拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。必要に応じて、関連モジュールが読み込まれたことを確認します。
$ lsmod | grep <MODULE_NAME>
モジュールが正しく読み込まれた場合、このコマンドは関連するカーネルモジュールを表示します。以下に例を示します。
$ lsmod | grep serio_raw serio_raw 16384 0
この手順で説明されている変更は、システムを再起動は維持されません。システムの再起動後にも設定を維持するようにカーネルモジュールを読み込む方法は、Loading kernel modules automatically at system boot time を参照してください。
関連情報
-
modprobe(8)
の man ページ
2.9. システムランタイム時のカーネルモジュールのアンロード
時折、実行中のカーネルから特定のカーネルモジュールをアンロードする必要性に駆られることがあります。modprobe
コマンドを使用して、現在読み込まれているカーネルから、システムの実行時にカーネルモジュールを見つけてアンロードします。
前提条件
- root 権限
-
kmod
パッケージがインストールされている。
手順
lsmod
コマンドを実行して、アンロードするカーネルモジュールを選択します。カーネルモジュールに依存関係がある場合は、カーネルモジュールをアンロードする前に、これらをアンロードします。依存関係のあるモジュールを特定する方法は、Listing currently loaded kernel modules および Kernel module dependencies を参照してください。
関連するカーネルモジュールをアンロードします。
# modprobe -r <MODULE_NAME>
カーネルモジュールの名前を入力する際には、
.ko.xz
拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。警告実行中のシステムで使用される場合は、カーネルモジュールをアンロードしないでください。これを行うと、システムが不安定になったり、動作しなくなったりすることがあります。
必要に応じて、関連モジュールがアンロードされたことを確認します。
$ lsmod | grep <MODULE_NAME>
モジュールが正常にアンロードされた場合、このコマンドは出力を表示しません。
この手順を終了すると、システムの起動時に自動的に読み込まれるように定義したカーネルモジュールは、システムを再起動してもアンロードされません。この結果を追跡する方法は、Preventing kernel modules from being automatically loaded at system boot time を参照してください。
関連情報
-
modprobe(8)
の man ページ
2.10. 起動プロセスの初期段階でのカーネルモジュールのアンロード
特定の状況では、起動プロセスの初期段階でカーネルモジュールのアンロードが必要になります。たとえば、カーネルモジュールにコードが含まれているとシステムが応答しなくなり、ユーザーがステージに到達して不正なカーネルモジュールを永続的に無効にすることができません。その場合は、ブートローダーを使用して、カーネルモジュールの読み込みを一時的にブロックできます。
この手順で説明されている変更は、システムを再起動すると維持されません。起動プロセス時にカーネルモジュールが自動的に読み込まれないように、denylist にカーネルモジュールを追加する方法は、Preventing kernel modules from being automatically loaded at system boot time を参照してください。
前提条件
- なんらかの理由で読み込みを阻止したい、読み込み可能なカーネルモジュールがある。
手順
ブートシーケンスが続行する前に、関連するブートローダーエントリーを編集して、必要なカーネルモジュールをアンロードします。
- カーソルキーを使用して、関連するブートローダーエントリーを強調表示します。
e を押して、登録内容を確定します。
図2.1 カーネルブートメニュー
- カーソルキーを使用して、linux で始まる行に移動します。
modprobe.blacklist=module_name
を行末に追加します。図2.2 カーネルブートエントリー
serio_raw
カーネルモジュールは、起動プロセスの初期段階でアンロードする不正なモジュールを示しています。- 変更した設定を使用して起動する場合は、CTRL+x キーを押します。
検証
システムが完全に起動したら、関連するカーネルモジュールが読み込まれていないことを確認します。
# lsmod | grep serio_raw
関連情報
2.11. システムの起動時に自動的にカーネルモジュールを読み込む
ブートプロセス中に自動的に読み込まれるようにカーネルモジュールを設定します。
前提条件
- root 権限
-
kmod
パッケージがインストールされている。
手順
起動プロセス中に読み込むカーネルモジュールを選択します。
モジュールは
/lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/
ディレクトリーにあります。モジュールの設定ファイルを作成します。
# echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf
注記カーネルモジュールの名前を入力する際には、
.ko.xz
拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。必要に応じて、関連モジュールが読み込まれたことを確認します。
$ lsmod | grep <MODULE_NAME>
上記のコマンド例は成功し、関連するカーネルモジュールを表示します。
この手順で説明している変更は、システムを再起動しても持続されます。
関連情報
-
modules-load.d(5)
の man ページ
2.12. システムの起動時にカーネルモジュールが自動的にロードされないようにする
システムの起動プロセス中にカーネルモジュールが自動的に読み込まれないように拒否リストに追加します。
前提条件
- root 権限
-
kmod
パッケージがインストールされている。 - 拒否リストに指定したカーネルモジュールが現在のシステム設定に重要でないことを確認する。
手順
拒否リストに追加するカーネルモジュールを選択します。
$ 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>/
ディレクトリーにあります。
拒否リスト用の設定ファイルを作成します。
# 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
拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。再構築を行う前に、現在の初期 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)
変更を反映するために新しい初期 ramdisk イメージを生成します。
# dracut -f -v
現在起動しているものとは異なるカーネルバージョンの初期 ramdisk イメージを構築する場合は、ターゲット
initramfs
とカーネルバージョンの両方を指定します。# dracut -f -v /boot/initramfs-<TARGET_VERSION>.img <CORRESPONDING_TARGET_KERNEL_VERSION>
システムを再起動します。
$ reboot
この手順で説明している変更は、システムを再起動しても持続されます。主要なカーネルモジュールを拒否リストに誤って追加した場合には、システムが不安定になったり、稼働しなくなったりする可能性があります。
関連情報
- カーネルモジュールが自動的に読み込まれないようにするには ?
-
dracut(8)
の man ページ
2.13. カスタムカーネルモジュールのコンパイル
ハードウェアおよびソフトウェアレベルで、さまざまな設定による要求に応じて、サンプリングカーネルモジュールを構築できます。
前提条件
-
kernel-devel
パッケージ、gcc
パッケージ、およびelfutils-libelf-devel
パッケージをインストールしている。 - root 権限がある。
-
カスタムカーネルモジュールをコンパイルする
/root/testmodule/
ディレクトリーを作成している。
手順
以下の内容で
/root/testmodule/test.c
を作成します。#include <linux/module.h> #include <linux/kernel.h> int init_module(void) { printk("Hello World\n This is a test\n"); return 0; } void cleanup_module(void) { printk("Good Bye World"); }
test.c
ファイルは、カーネルモジュールに主な機能を提供するソースファイルです。このファイルは、組織的な目的で、専用の/root/testmodule/
ディレクトリーに作成されています。モジュールをコンパイルすると、/root/testmodule/
ディレクトリーには複数のファイルが含まれます。test.c
ファイルには、システムライブラリーから次のものが含まれます。-
サンプルコードの
printk()
機能には、linux/kernel.h
ヘッダーファイルが必要です。 linux/module.h
ファイルには、C 言語で記述した複数のソースファイルで共有する関数宣言とマクロ定義が含まれています。次に、
init_module()
関数およびcleanup_module()
関数に従い、テキストを出力するカーネルログ機能printk()
を起動および終了します。
-
サンプルコードの
以下の内容で
/root/testmodule/Makefile
を作成します。obj-m := test.o
Makefile には、コンパイラーが、
test.o
という名前のオブジェクトファイルを作成する必要がある指示が含まれています。obj-m
ディレクティブは、生成されるtest.ko
ファイルを、読み込み可能なカーネルモジュールとしてコンパイルすることを指定します。もしくは、obj-y
ディレクティブは、組み込みカーネルモジュールとしてtest.ko
をビルドするように指示します。カーネルモジュールをコンパイルします。
# make -C /lib/modules/$(uname -r)/build M=/root/testmodule modules make: Entering directory '/usr/src/kernels/4.18.0-305.el8.x86_64' CC [M] /root/testmodule/test.o Building modules, stage 2. MODPOST 1 modules WARNING: modpost: missing MODULE_LICENSE() in /root/testmodule/test.o see include/linux/module.h for more information CC /root/testmodule/test.mod.o LD [M] /root/testmodule/test.ko make: Leaving directory '/usr/src/kernels/4.18.0-305.el8.x86_64'
コンパイラーは、各ソースファイル (
test.c
) のオブジェクトファイル (test.o
) を中間手順として作成してから、それらを最終カーネルモジュール (test.ko
) にリンクします。コンパイルが成功すると、
/root/testmodule/
には、コンパイル済みカスタムカーネルモジュールに関連する追加ファイルが含まれます。コンパイル済みモジュール自身は、test.ko
ファイルで表されます。
検証
必要に応じて、
/root/testmodule/
ディレクトリーのコンテンツを確認します。# ls -l /root/testmodule/ total 152 -rw-r—r--. 1 root root 16 Jul 26 08:19 Makefile -rw-r—r--. 1 root root 25 Jul 26 08:20 modules.order -rw-r—r--. 1 root root 0 Jul 26 08:20 Module.symvers -rw-r—r--. 1 root root 224 Jul 26 08:18 test.c -rw-r—r--. 1 root root 62176 Jul 26 08:20 test.ko -rw-r—r--. 1 root root 25 Jul 26 08:20 test.mod -rw-r—r--. 1 root root 849 Jul 26 08:20 test.mod.c -rw-r—r--. 1 root root 50936 Jul 26 08:20 test.mod.o -rw-r—r--. 1 root root 12912 Jul 26 08:20 test.o
カーネルモジュールを
/lib/modules/$(uname -r)/
ディレクトリーにコピーします。# cp /root/testmodule/test.ko /lib/modules/$(uname -r)/
モジュールの依存関係の一覧を更新します。
# depmod -a
カーネルモジュールを読み込みます。
# modprobe -v test insmod /lib/modules/4.18.0-305.el8.x86_64/test.ko
カーネルモジュールが正常に読み込まれたことを確認します。
# lsmod | grep test test 16384 0
カーネルリングバッファーから最新のメッセージを読み込みます。
# dmesg [74422.545004] Hello World This is a test
関連情報
第3章 セキュアブート用のカーネルモジュールの署名
署名付きカーネルモジュールを使用して、システムのセキュリティーを強化できます。セキュアブートが有効になっている UEFI ベースのビルドシステムで RHEL 8 で使用する、非公開でビルドされたカーネルモジュールに自己署名し、カーネルモジュールをデプロイするターゲットシステムに公開鍵をインポートするための利用可能なオプションの詳細を確認してください。
セキュアブートが有効な場合は、UEFI オペレーティングシステムのブートローダー、Red Hat Enterprise Linux のカーネル、およびすべてのカーネルモジュールを秘密鍵で署名し、対応する公開鍵で認証する必要があります。それらが署名・認証されてなければ、システムは起動プロセスを終了できません。
RHEL 8 ディストリビューションには、以下が含まれます。
- 署名付きブートローダー
- 署名付きカーネル
- 署名付きカーネルモジュール
また、署名された第 1 ステージのブートローダーと署名されたカーネルには、組み込み Red Hat 公開鍵が含まれています。この署名済みの実行可能なバイナリーおよび組み込み鍵により、RHEL 8 は UEFI セキュアブートに対応するシステムで、UEFI ファームウェアが提供する Microsoft UEFI セキュアブート認証局の鍵を使用してインストール、起動、実行できます。すべての UEFI ベースのシステムにセキュアブートのサポートが含まれているわけではないことに注意してください。
前提条件
外部でビルドされたカーネルモジュールに署名できるようにするには、次の表にリストされているユーティリティーをビルドシステムにインストールします。
表3.1 必要なユーティリティー
ユーティリティー | 提供するパッケージ | 使用対象 | 目的 |
---|---|---|---|
|
| ビルドシステム | 公開および秘密 X.509 鍵のペアを生成 |
|
| ビルドシステム | 秘密鍵でカーネルモジュールに署名するために使用する実行ファイル |
|
| ターゲットシステム | 公開鍵を手動で登録する際に使用するオプションのユーティリティー |
|
| ターゲットシステム | システムキーリングへの公開鍵の表示時に使用するオプションのユーティリティー |
カーネルモジュールを構築、署名するビルドシステムは、UEFI セキュアブートを有効にする必要がなく、UEFI ベースのシステムである必要すらありません。
3.1. UEFI セキュアブートとは
Unified Extensible Firmware Interface (UEFI) セキュアブート技術を使用すると、システムブートローダーが暗号化キーで署名されるようにできます。ファームウェアに含まれる公開鍵のデータベースは、署名キーを承認します。次のステージのブートローダーおよびカーネルで署名を検証できます。これにより、信頼できる鍵で署名されていないカーネルスペースコードが実行されないようにすることができます。
UEFI セキュアブートは、以下のようにファームウェアから署名済みドライバーおよびカーネルモジュールへの信頼チェーンを確立します。
-
UEFI 秘密鍵が
shim
第 1 ステージブートローダーに署名し、それを公開鍵が認証します。認証局 (CA) は公開鍵に署名します。CA はファームウェアのデータベースに保存されます。 -
shim.efi
には、GRUB ブートローダーおよびカーネルを認証する Red Hat 公開鍵 Red Hat セキュアブート (CA キー 1) が含まれます。 - カーネルには、ドライバーおよびモジュールを認証する公開鍵が含まれます。
セキュアブートは、UEFI 仕様のブートパス検証コンポーネントです。この仕様は、以下を定義します。
- 揮発性ではないストレージでの暗号で保護された UEFI 変数用のプログラミングインターフェイス
- UEFI 変数での信頼できる X.509 ルート証明書の保存
- ブートローダーやドライバーなどの UEFI アプリケーションの検証
- 既知の問題のある証明書およびアプリケーションハッシュを無効にする手順
UEFI セキュアブートは、第 2 ステージブートローダーのインストールや削除を妨ぎません。また、このような変更のユーザーによる明示的な確認を必要としません。署名は、ブートローダーのインストールや更新時ではなく、起動時に検証されます。したがって、UEFI セキュアブートはブートパスの操作を停止しません。これは、不正な変更の検出に役立ちます。
システムによる信頼済みの鍵で署名されている限り、ブートローダーまたはカーネルは動作します。
3.2. UEFI セキュアブートのサポート
RHEL 8 は、Unified Extensible Firmware Interface (UEFI) のセキュアブート機能をサポートします。つまり、UEFI セキュアブートが有効なマシンに RHEL 8 をインストールして実行できます。これらのシステムでは、読み込まれたすべてのドライバーに信頼できる鍵で署名する必要があります。そうでないと、システムはドライバーを受け入れません。Red Hat は、該当する Red Hat キーで署名および認証されたドライバーを提供します。
外部ビルドのドライバーを読み込む場合は、それらにも署名する必要があります。
UEFI セキュアブートによる制限
- システムは、カーネルモードコードの署名が適切に認証された後にのみ、コードを実行します。
- GRUB モジュールの署名および検証を行うインフラストラクチャーがないため、GRUB モジュールの読み込みは無効です。モジュールの読み込みを許可すると、セキュアブートが定義するセキュリティー境界内で信頼できないコードが実行されることになります。
- Red Hat は、RHEL 8 でサポートされるすべてのモジュールが含まれる署名済み GRUB バイナリーを提供します。
関連情報
3.3. 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
に読み込まれます。 - カーネルの再構築なしでキーセットを拡張することはできません。
表3.2 カーネルモジュールの読み込み認証要件
モジュールの署名 | 公開鍵ありおよび署名が有効 | UEFI セキュアブートの状態 | sig_enforce | モジュールの読み込み | カーネルの汚染 |
---|---|---|---|---|---|
署名なし | - | 有効でない | 有効でない | 成功 | はい |
有効でない | 有効 | 失敗 | - | ||
有効 | - | 失敗 | - | ||
署名あり | いいえ | 有効でない | 有効でない | 成功 | はい |
有効でない | 有効 | 失敗 | - | ||
有効 | - | 失敗 | - | ||
署名あり | はい | 有効でない | 有効でない | 成功 | いいえ |
有効でない | 有効 | 成功 | いいえ | ||
有効 | - | 成功 | いいえ |
3.4. 公開鍵のソース
カーネルは、起動時に X.509 キーを永続キーストアから以下のキーリングに読み込みます。
-
システムキーリング (
.builtin_trusted_keys
) -
.platform
キーリング -
システムの
.blacklist
キーリング
表3.3 システムキーリングのソース
X.509 鍵のソース | ユーザーによるキーの追加 | UEFI セキュアブートの状態 | ブート中に読み込まれる鍵 |
---|---|---|---|
カーネルに埋め込み | いいえ | - |
|
UEFI セキュアブート "db" | 限定的 | 有効でない | いいえ |
有効 |
| ||
| いいえ | 有効でない | いいえ |
有効 |
| ||
Machine Owner Key (MOK) リスト | はい | 有効でない | いいえ |
有効 |
|
.builtin_trusted_keys
:
- 起動時に構築されるキーリング
- 信頼できる公開鍵が含まれる
-
鍵を表示するには
root
権限が必要
.platform
:
- 起動時に構築されるキーリング
- サードパーティーのプラットフォームプロバイダーからの鍵とカスタム公開鍵が含まれる
-
鍵を表示するには
root
権限が必要
.blacklist
- 無効な X.509 鍵を使用したキーリング
-
公開鍵が
.builtin_trusted_keys
にある場合でも.blacklist
からの鍵で署名されたモジュールは認証に失敗する
UEFI セキュアブート db:
- 署名データベース
- UEFI アプリケーション、UEFI ドライバー、およびブートローダーの鍵 (ハッシュ) を格納する
- この鍵はマシンで読み込むことができる
UEFI セキュアブート dbx:
- 無効な署名データベース
- 鍵が読み込まれないようにする
-
このデータベースからの無効な鍵は
.blacklist
キーリングに追加される
3.5. 公開鍵と秘密鍵の生成
セキュアブートを有効化したシステム上でカーネルモジュールを使用する作業を正常に行うには、公開および秘密 X.509 鍵ペアを生成する必要があります。後で秘密鍵を使用してカーネルモジュールに署名します。セキュアブートで署名済みモジュールを検証するには、適切な公開鍵を Machine Owner Key (MOK) に追加する必要があります。
このキーペア生成のパラメーターの一部は、設定ファイルで指定するのが最適です。
手順
キーペア生成のパラメーターで設定ファイルを作成します。
# 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
X.509 公開鍵と秘密鍵のペアを以下の例のように作成します。
# openssl req -x509 -new -nodes -utf8 -sha256 -days 36500 \ -batch -config configuration_file.config -outform DER \ -out my_signing_key_pub.der \ -keyout my_signing_key.priv
公開鍵は
my_signing_key_pub.der
ファイルに書き込まれます。この秘密鍵はmy_signing_key.priv
ファイルに書き込まれます。重要RHEL 8 では、鍵ペアの有効期限は重要ではありません。鍵の有効期限はありませんが、カーネルモジュールは署名鍵の有効期間内に署名することがセキュリティー上、推奨されます。ただし、
sign-file
ユーティリティーは警告を発せず、鍵は有効期限に関係なく使用できます。必要に応じて、以下の例のように公開鍵の有効期限を確認できます。
# 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
- カーネルモジュールを認証、読み込むすべてのシステムに公開鍵を登録します。
強力なセキュリティー対策とアクセスポリシーを適用して、秘密鍵の内容を保護します。悪用すれば、この鍵は、一致する公開鍵で認証されるシステムのセキュリティーに危害を与えるために使用できます。
関連情報
-
openssl(1)
の man ページ - RHEL Security Guide
- 公開鍵を MOK リストに追加することでターゲットシステムで公開鍵を登録する手順
3.6. システムキーリングの出力例
keyutils
パッケージからの keyctl
ユーティリティーを使用して、システムのキーリングの鍵に関する情報を表示できます。
以下は、UEFI セキュアブートが有効になっている RHEL 8 システムからの .builtin_trusted_keys
、.platform
および .blacklist
キーリングの出力例 (簡略版) です。
前提条件
- root 権限がある。
-
keyutils
パッケージからkeyctl
ユーティリティーをインストールしている。
# 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 | egrep 'integrity.*cert'
[1.512966] integrity: Loading X.509 certificate: UEFI:db
[1.513027] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a929023...
[1.513028] integrity: Loading X.509 certificate: UEFI:db
[1.513057] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309...
[1.513298] integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
[1.513549] integrity: Loaded X.509 cert 'Red Hat Secure Boot CA 5: cc6fa5e72868ba494e93...
関連情報
-
keyctl(1)
、dmesg(1)
の man ページ
3.7. 公開鍵を 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.efi
、MokManager.efi
、grubx64.efi
および mokutil
ユーティリティーでサポートされています。
MOK 鍵の登録は、各ターゲットシステムの UEFI システムコンソールでユーザーが物理的に手動で対応する必要があります。それにもかかわらず、MOK 機能は、新規生成された鍵ペアのテストとこれで署名されたカーネルモジュールのテストにおいて便利な方法を提供します。
手順
公開鍵を MOK リストに追加するようリクエストします。
# mokutil --import my_signing_key_pub.der
この MOK 登録リクエストに関するパスワードの入力と確認が求められます。
マシンを再起動します。
この MOK 鍵登録リクエストは
shim.efi
が発見し、MokManager.efi
を起動して UEFI コンソールからの登録が完了できるようになります。MOK の登録を選択し、登録を求められたら、この要求に以前関連付けたパスワードを入力します。
公開鍵が MOK リストに永続的に追加されます。
鍵が MOK リストに追加されると、UEFI セキュアブートが有効な場合にこの鍵がシステムのキーリングに自動的に伝播され、その後のブートが可能になります。
システムでカーネルモジュールの認証を実現するために、ファクトリーファームウェアイメージで公開鍵を UEFI セキュアブート鍵データベースに組み入れるようシステムベンダーに要求することを検討します。
3.8. 秘密鍵を使用したカーネルモジュールの署名
UEFI セキュアブートメカニズムが有効になっている場合は、秘密キーを使用してカーネルモジュールに署名し、セキュリティーを強化できます。
前提条件
- 公開鍵と秘密鍵のペアを生成し、公開鍵の有効期限を確認している。詳細は 公開鍵と秘密鍵の生成 を参照してください。
- ターゲットシステムに公開鍵を登録している。詳細は 公開鍵を MOK リストに追加することでターゲットシステムで公開鍵を登録する手順 を参照してください。
- ELF イメージ形式で署名できるカーネルモジュールがある。
手順
パラメーターを指定して
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 でカーネルモジュールに署名することはできません。
関連情報
3.9. 署名付きカーネルモジュールの読み込み
公開鍵がシステムキーリング (.builtin_trusted_keys
) および MOK リストに登録されると、modprobe
コマンドを使用して各カーネルモジュールに秘密鍵で署名されたカーネルモジュールを読み込むことができます。
前提条件
- 公開鍵と秘密鍵のペアを生成している。詳細は 公開鍵と秘密鍵の生成 を参照してください。
- 公開鍵をシステムのキーリングに登録している。詳細は 公開鍵を MOK リストに追加することでターゲットシステムで公開鍵を登録する手順 を参照してください。
- 秘密鍵でカーネルモジュールに署名している。詳細は 秘密鍵を使用したカーネルモジュールの署名 を参照してください。
手順
公開鍵がシステムキーリング上にあることを確認します。
# keyctl list %:.platform
/lib/modules/$(uname -r)/extra/
ディレクトリーを作成するkernel-modules-extra
パッケージをインストールします。# yum -y install kernel-modules-extra
任意のカーネルの
/extra/
ディレクトリーにカーネルモジュールをコピーします。# cp my_module.ko /lib/modules/$(uname -r)/extra/
モジュールの依存関係の一覧を更新します。
# depmod -a
カーネルモジュールを読み込み、正常にロードされたことを確認します。
# modprobe -v my_module # lsmod | grep my_module
必要に応じて、起動時にモジュールを読み込むには、
/etc/modules-loaded.d/my_module.conf
ファイルに追加します。# echo "my_module" > /etc/modules-load.d/my_module.conf
関連情報
第4章 Configuring kernel command-line parameters
カーネルコマンドラインパラメーターは、システムの起動時に Red Hat Enterprise Linux カーネルの特定の側面の動作を変更する手段のひとつです。システム管理者は、システムの起動時に設定されるオプションを完全に制御できます。特定のカーネルの動作はシステムの起動時にのみ設定できるため、このような変更を行う方法を理解することが管理スキルの鍵となります。
カーネルコマンドラインパラメーターを変更することで、システムの動作が変更するオプションは、システムに悪影響を及ぼす可能性があります。したがって、実稼働環境にデプロイする前に変更をテストする必要があります。詳細なガイダンスは、Red Hat サポートまでご連絡ください。
4.1. カーネルコマンドラインパラメーターの概要
カーネルコマンドラインパラメーターは、以下のシステムの起動時間設定に使用されます。
- Red Hat Enterprise Linux カーネル
- 初期 RAM ディスク
- ユーザー領域機能
カーネルの起動時間パラメーターは、デフォルト値を上書きしたり、特定のハードウェア設定にするために使用されます。
デフォルトでは、GRUB ブートローダーを使用するシステムのカーネルコマンドラインパラメーターは、カーネルブートエントリーごとに /boot/grub2/grubenv
ファイルの kernelopts
変数で定義されます。
IBM Z では、zipl
ブートローダーは環境変数に対応していないため、カーネルコマンドラインパラメーターはブートエントリー設定ファイルに保存されます。したがって、kernelopts
環境変数は使用できません。
関連情報
-
kernel-command-line(7)
、bootparam(7)
、およびdracut.cmdline (7)
の man ページ - How to install and boot custom kernels in Red Hat Enterprise Linux 8
4.2. grubby とは
grubby
は、ブートローダーの設定ファイルを操作するためのユーティリティーです。
grubby
を使用して、デフォルトのブートエントリーを変更したり、GRUB2 メニューエントリーから引数を追加または削除したりすることもできます。
関連情報
-
grubby(8)
の man ページ
4.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
ファイルで定義されます。
4.4. すべてのブートエントリーでカーネルコマンドラインパラメーターの変更
システム上のすべてのブートエントリーのカーネルコマンドラインパラメーターを変更します。
前提条件
-
gruby
ユーティリティーがシステムにインストールされていることを確認してください。 -
zipl
ユーティリティーが IBM Z システムにインストールされていることを確認してください。
手順
パラメーターを追加するには、以下を行います。
# grubby --update-kernel=ALL --args="<NEW_PARAMETER>"
GRUB ブートローダーを使用するシステムの場合は、
/boot/grub2/grubenv
のkernelopts
変数に新しいカーネルパラメーターを追加して、ファイルを更新します。zIPL ブートローダーを使用する IBM Z では、新しいカーネルパラメーターを各
/boot/loader/entries/<ENTRY>.conf
ファイルに追加します。-
IBM Z で、起動メニューを更新するオプションを指定せずに
zipl
コマンドを実行します。
-
IBM Z で、起動メニューを更新するオプションを指定せずに
パラメーターを削除するには、次のコマンドを実行します。
# grubby --update-kernel=ALL --remove-args="<PARAMETER_TO_REMOVE>"
-
IBM Z で、起動メニューを更新するオプションを指定せずに
zipl
コマンドを実行します。
-
IBM Z で、起動メニューを更新するオプションを指定せずに
カーネルパッケージの更新ごとに、設定したカーネルオプションを新しいカーネルに反映させます。
# grub2-mkconfig -o /etc/grub2.cfg
重要新しくインストールされたカーネルは、以前に設定されたカーネルからカーネルコマンドラインパラメーターを継承しません。新しくインストールされたカーネルで
grub2-mkconfig
コマンドを実行して、必要なパラメーターを新しいカーネルに反映させる必要があります。
関連情報
- カーネルコマンドラインパラメーターの概要
-
grubby(8)
およびzipl(8)
の man ページ - grubby ツール
4.5. 1 つのブートエントリーでカーネルコマンドラインパラメーターの変更
システム上の単一のブートエントリーのカーネルコマンドラインパラメーターを変更します。
前提条件
-
grubby
ユーティリティーおよびzipl
ユーティリティーがシステムにインストールされている。
手順
パラメーターを追加するには、以下を行います。
# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="<NEW_PARAMETER>"
-
IBM Z で、起動メニューを更新するオプションを指定せずに
zipl
コマンドを実行します。
-
IBM Z で、起動メニューを更新するオプションを指定せずに
パラメーターを削除するには、以下のコマンドを使用します。
# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --remove-args="<PARAMETER_TO_REMOVE>"
-
IBM Z で、起動メニューを更新するオプションを指定せずに
zipl
コマンドを実行します。
-
IBM Z で、起動メニューを更新するオプションを指定せずに
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
ファイルに保存します。
関連情報
- カーネルコマンドラインパラメーターの概要
-
grubby(8)
およびzipl(8)
の man ページ - grubby ツール
4.6. 起動時の一時的なカーネルコマンドラインパラメーターの変更
1 回の起動プロセス中にのみカーネルパラメーターを変更することで、カーネルメニューエントリーを一時的に変更します。
手順
- GRUB 2 ブートメニューが表示されたら起動するカーネルを選択し、e キーを押してカーネルパラメーターを編集します。
-
カーソルを下に移動してカーネルコマンドラインを見つけます。カーネルコマンドラインは、64 ビット IBM Power シリーズおよび x86-64 BIOS ベースのシステムの場合は
linux
で始まり、UEFI システムの場合はlinuxefi
で始まります。 カーソルを行の最後に移動します。
注記行の最初に移動するには Ctrl+a を押します。行の最後に移動するには Ctrl+e を押します。システムによっては、Home キーおよび End キーも機能する場合があります。
必要に応じてカーネルパラメーターを編集します。たとえば、緊急モードでシステムを実行するには、
linux
行の最後に emergency パラメーターを追加します。linux ($root)/vmlinuz-4.18.0-348.12.2.el8_5.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet emergency
システムメッセージを有効にするには、
rhgb
およびquiet
パラメーターを削除します。- Ctrl+x を押して、選択したカーネルと変更したコマンドラインパラメーターで起動します。
Esc キーを押すと、コマンドラインの編集を終了し、ユーザーの加えた変更をすべて破棄します。
この手順は単一ブートにのみ適用され、変更は永続的に行われません。
4.7. シリアルコンソール接続を有効にする GRUB 設定
シリアルコンソールは、ネットワークがダウンしている場合にヘッドレスサーバーまたは埋め込みシステムに接続する際に便利です。あるいは、セキュリティールールを回避し、別のシステムへのログインアクセスを取得する必要がある場合などです。
シリアルコンソール接続を使用するように、デフォルトの GRUB 設定の一部を設定する必要があります。
前提条件
- root 権限がある。
手順
/etc/default/grub
ファイルに以下の 2 つの行を追加します。GRUB_TERMINAL="serial" GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"
最初の行は、グラフィカルターミナルを無効にします。
GRUB_TERMINAL
キーは、GRUB_TERMINAL_INPUT
およびGRUB_TERMINAL_OUTPUT
の値を上書きします。2 行目は、ボーレート (
--speed
)、パリティー、および他の値を使用中の環境とハードウェアに適合するように調整します。以下のログファイルのようなタスクには、115200 のように非常に高いボーレートが推奨されます。GRUB 設定ファイルを更新します。
BIOS ベースのマシンの場合:
# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI ベースのマシンの場合:
# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
- システムを再起動して、変更を有効にします。
第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(8)
およびsysctl.d(5)
の man ページ
5.2. sysctl でカーネルパラメーターの一時的な設定
sysctl
コマンドを使用して、実行時に一時的にカーネルパラメーターを設定します。このコマンドは、調整可能パラメーターの一覧表示およびフィルターリングにも便利です。
前提条件
- root 権限
手順
すべてのパラメーターとその値をリストします。
# sysctl -a
注記# sysctl -a
コマンドは、ランタイム時およびシステムの起動時に調整できるカーネルパラメーターを表示します。パラメーターを一時的に設定するには、次のように入力します。
# sysctl <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
上記のサンプルコマンドは、システムの実行中にパラメーター値を変更します。この変更は、再起動なしですぐに適用されます。
注記変更は、システムの再起動後にデフォルトに戻ります。
関連情報
-
sysctl(8)
の man ページ - sysctl でカーネルパラメーターを永続的に設定
- /etc/sysctl.d/ の設定ファイルでカーネルパラメーターの調整
5.3. sysctl でカーネルパラメーターを永続的に設定
sysctl
コマンドを使用して、カーネルパラメーターを永続的に設定します。
前提条件
- root 権限
手順
すべてのパラメーターをリストします。
# sysctl -a
このコマンドは、ランタイム時に設定できるカーネルパラメーターをすべて表示します。
パラメーターを永続的に設定すします。
# sysctl -w <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE> >> /etc/sysctl.conf
サンプルコマンドは、調整可能な値を変更して、
/etc/sysctl.conf
ファイルに書き込みます。これにより、カーネルパラメーターのデフォルト値が上書きされます。変更は、再起動なしで即座に永続的に反映されます。
カーネルパラメーターを永続的に変更するには、/etc/sysctl.d/
ディレクトリーの設定ファイルに手動で変更を行ってください。
関連情報
-
sysctl(8)
およびsysctl.conf(5)
の man ページ - /etc/sysctl.d/ の設定ファイルでカーネルパラメーターの調整
5.4. /etc/sysctl.d/ の設定ファイルでカーネルパラメーターの調整
/etc/sysctl.d/
ディレクトリーの設定ファイルを手動で変更して、カーネルパラメーターを永続的に設定します。
前提条件
- root 権限
手順
/etc/sysctl.d/
に新しい設定ファイルを作成します。# vim /etc/sysctl.d/<some_file.conf>
カーネルパラメーターを 1 行に 1 つずつ含めます。
<TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
<TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
- 設定ファイルを作成します。
システムを再起動して、変更を有効にします。
また、再起動せずに変更を適用するには、以下を実行します。
# sysctl -p /etc/sysctl.d/<some_file.conf>
このコマンドにより、以前に作成した設定ファイルから値を読み取ることができます。
関連情報
-
sysctl(8)
、sysctl.d(5)
の man ページ
5.5. /proc/sys/ でカーネルパラメーターの一時的な設定
/proc/sys/
仮想ファイルシステムディレクトリー内のファイルを使用して、一時的にカーネルパラメーターを設定します。
前提条件
- root 権限
手順
設定するカーネルパラメーターを特定します。
# ls -l /proc/sys/<TUNABLE_CLASS>/
コマンドが返した書き込み可能なファイルは、カーネルの設定に使用できます。読み取り専用権限を持つユーザーは、現在の設定についてフィードバックを提供します。
カーネルパラメーターにターゲットの値を割り当てます。
# echo <TARGET_VALUE> > /proc/sys/<TUNABLE_CLASS>/<PARAMETER>
このコマンドでは、システムが再起動すると設定変更が消えます。
必要に応じて、新しく設定した設定したカーネルパラメーターの値を確認します。
# cat /proc/sys/<TUNABLE_CLASS>/<PARAMETER>
第6章 GRUB メニューを一時的に変更する
GRUB メニューエントリーを変更したり、現在のブートにのみ適用される引数をカーネルに渡したりできます。ブートローダーメニューで選択したメニューエントリーでは、次のことができます。
- e キーを押して、メニューエントリーエディターインターフェイスを表示します。
- 変更を破棄し、Esc キーを押して標準メニューインターフェイスを再読み込みします。
- c キーを押してコマンドラインインターフェイスをロードします。
- 関連する GRUB コマンドを入力し、Enter キーを押して入力します。
- Tab キーを押して、コンテキストに基づいてコマンドを完了します。
- Ctrl+a キーの組み合わせを押して、行の先頭に移動します。
- Ctrl+e キーの組み合わせを押して、行末に移動します。
次の手順では、1 回の起動プロセス中に GRUB メニューを変更する方法について説明します。
6.1. GRUB について
GRUB は GNU GRand Unified Bootloader
の略です。GRUB を使用すると、システムの起動時にロードするオペレーティングシステムまたはカーネルを選択できます。また、カーネルに引数を渡すこともできます。
GRUB で起動する場合は、メニューインターフェイスまたはコマンドラインインターフェイス (GRUB command shell
) のいずれかを使用できます。システムを起動すると、メニューインターフェイスが表示されます。

c キーを押すと、コマンドラインインターフェイスに切り替えることができます。

exit と入力して Enter キーを押すと、メニューインターフェイスに戻ることができます。
GRUB BLS ファイル
ブートローダーメニューエントリーは、ブートローダー仕様 (BLS
) ファイルとして定義されます。このファイル形式は、ブートローダー設定ファイルを操作することなく、ドロップインディレクトリー内の各ブートオプションのブートローダー設定を管理します。grubby
ユーティリティーは、これらの BLS
ファイルを編集できます。
GRUB 設定ファイル
/boot/grub2/grub.cfg
設定ファイルは、メニューエントリーを定義しません。
関連情報
6.2. ブートローダー仕様の概要
BootLoader Specification (BLS) は、ブートローダー設定ファイルを操作せずに、ドロップインディレクトリーの各起動オプションのブートローダー設定を管理するスキームとファイル形式を定義します。前述の方法とは異なり、各ブートエントリーはドロップインディレクトリーの個別の設定ファイルで表されるようになりました。ドロップインディレクトリーは、設定ファイルを編集または再生成せずに設定を拡張します。BLS は、ブートメニューエントリーのこの概念を拡張します。
BLS を使用すると、ディレクトリー内の個々のブートエントリーファイルを追加、削除、または編集して、ブートローダーメニューのオプションを管理できます。これにより、カーネルのインストールプロセスがはるかに簡素化され、異なるアーキテクチャーの間でこのプロセスの一貫性を保つことができます。
grubby
ツールは、BLS に関するシンラッパースクリプトで、同じ grubby
引数およびオプションをサポートします。dracut
を実行して、初期 ramdisk イメージを作成します。この設定では、コアブートローダーの設定ファイルは静的で、カーネルのインストール後に変更されません。
RHEL 8 では、同じブートローダーがすべてのアーキテクチャーで使用されているわけではないため、RHEL 8 には特に該当します。GRUB は、64 ビット ARM などのほとんどのアーキテクチャーに使用されますが、Open Power Abstraction Layer (OPAL) を使用する IBM Power Systems のリトルエンディアンバリアントは Petitboot
を使用し、IBM Z アーキテクチャーは zipl
を使用します。
関連情報
- 「grubby とは」
- 「ブートエントリーとは」
-
grubby(8)
man ページ
6.3. レスキューモードでの起動
レスキューモードは、便利なシングルユーザー環境を提供し、通常の起動プロセスを完了できない状況においてシステムの修復を可能にします。レスキューモードでは、システムはすべてのローカルファイルシステムをマウントし、いくつかの重要なシステムサービスを開始しようとします。ただし、ネットワークインターフェイスをアクティブにしたり、より多くのユーザーが同時にシステムにログインしたりすることはできません。
手順
- GRUB ブート画面で、e キーを押して編集します。
Linux
行の末尾に次のパラメーターを追加します。systemd.unit=rescue.target
Ctrl+x を押して、レスキューモードで起動します。
6.4. 緊急モードでの起動
緊急モードは、可能な限り最小限の環境を提供し、システムがレスキューモードに入れない状態でもシステムの修復を可能にします。
緊急モードでは、システムは次のことを行います。
-
root
ファイルシステムを読み取り専用にマウントします - いくつかの重要なサービスを開始します
ただし、システムは次のことを 行いません。
- 他のローカルファイルシステムのマウントを試みる
- ネットワークインターフェイスをアクティブにする
手順
- GRUB ブート画面で、e キーを押して編集します。
Linux
行の末尾に次のパラメーターを追加します。systemd.unit=emergency.target
Ctrl+x を押して緊急モードで起動します。
6.5. デバッグシェルのブート
systemd
デバッグシェルは、起動プロセスの非常に早い段階でシェルを提供します。デバッグシェルに入ったら、systemctl list-jobs
や systemctl list-units
などの systemctl
コマンドを使用して、systemd
関連の起動問題の原因を検索できます。
手順
- GRUB ブート画面で、e キーを押して編集します。
Linux
行の末尾に次のパラメーターを追加します。systemd.debug-shell
必要に応じて、
デバッグ
オプションを追加します。注記カーネルコマンドラインに
debug
オプションを追加すると、ログメッセージの数が増加します。systemd
では、カーネルコマンドラインオプションのdebug
が、systemd.log_level=debug
のショートカットになりました。- Ctrl+x を押して、デバッグシェルを起動します。
デバッグシェルを使用するには認証が必要ないため、デバッグシェルを永続的に有効にすることにはセキュリティー上のリスクがあります。デバッグシェルは、デバッグセッションが終了したときに無効にしてください。
6.6. デバッグシェルへの接続
起動プロセス中に、systemd-debug-generator
は TTY9 でデバッグシェルを設定します。
前提条件
- デバッグシェルが正常に起動しました。デバッグシェルのブート を参照してください。
手順
Ctrl+Alt+F9 を押してデバッグシェルに接続します。
仮想マシンを使用している場合は、このキーの組み合わせを送信するには、仮想化アプリケーションからのサポートが必要です。たとえば、Virtual Machine Manager を使用している場合は、メニューから Send Key →
Ctrl+Alt+F9
を選択します。- デバッグシェルは認証を必要としないため、TTY9 で次のようなプロンプトが表示されます。
sh-4.4#
検証手順
以下のようなコマンドを入力します。
sh-4.4# systemctl status $$
- デフォルトのシェルに戻るには、ブートが成功した場合に Ctrl+Alt+F1 を押します。
関連情報
-
systemd-debug-generator(8)
man ページ
6.7. インストールディスクを使用した root パスワードのリセット
root
パスワードを忘れた場合や紛失した場合は、リセットできます。
手順
- インストールソースからホストを起動します。
インストールメディアのブートメニューで、
トラブルシューティング
を選択します。トラブルシューティング メニューで
Red Hat Enterprise Linux システムのレスキュー
オプションを選択します。Rescue メニューで
1
を選択し、Enter キーを押して続行します。以下のようにファイルシステム
root
を変更します。sh-4.4# chroot /mnt/sysimage
passwd
コマンドを入力し、コマンドラインに表示される指示にしたがってroot
パスワードを変更します。時間がかかるディスクの SELinux の再ラベルを防ぐために、
autorelable
ファイルを削除します。sh-4.4# rm -f /.autorelabel
-
exit
コマンドを入力して、chroot
環境を終了します。 -
exit
コマンドを再び実行して初期化を再開し、システム起動を完了します。
6.8. rd.break を使用した root パスワードのリセット
root
パスワードを忘れた場合や紛失した場合は、リセットできます。
手順
- システムを起動し、GRUB ブート画面で e キーを押して編集を行います。
Linux
行の末尾にrd.break
パラメーターを追加します。Ctrl+x を押して変更したパラメーターでシステムを起動します。
ファイルシステムを書き込み可能で再マウントします。
switch_root:/# mount -o remount,rw /sysroot
ファイルシステムの
root
を変更します。switch_root:/# chroot /sysroot
passwd
コマンドを入力し、コマンドラインに表示される指示に従います。次回のシステム起動時にすべてのファイルにラベルを付け直します。
sh-4.4# touch /.autorelabel
ファイルシステムを 読み取り専用 で再マウントします。
sh-4.4# mount -o remount,ro /
-
exit
コマンドを入力して、chroot
環境を終了します。 exit
コマンドを再び実行して初期化を再開し、システム起動を完了します。注記SELinux の再ラベル付けプロセスには時間がかかる場合があります。プロセスが完了すると、システムが自動的に再起動します。
enforcing=0
オプションを追加すると、時間のかかる SELinux の再ラベル付けプロセスを省略できます。
手順
linux
行の最後にrd.break
パラメーターを追加するときは、enforcing=0
も追加します。rd.break enforcing=0
/etc/shadow
ファイルの SELinux セキュリティーコンテキストを復元します。# restorecon /etc/shadow
SELinux ポリシーの適用をオンに戻し、オンになっていることを確認します。
# setenforce 1 # getenforce Enforcing
手順 3 で enforcing=0
オプションを追加した場合は、手順 8 で touch /.autorelabel
コマンドの入力を省略できることに注意してください。
6.9. 関連情報
-
/usr/share/doc/grub2-common
ディレクトリー。 -
info grub2
コマンド。
第7章 GRUB ブートローダーに永続的な変更を加える
grubby
ツールを使用して、GRUB で永続的な変更を行います。
7.1. 前提条件
- システムに RHEL が正常にインストールされました。
- root 権限がある。
7.2. デフォルトのカーネルの一覧表示
デフォルトのカーネルを一覧表示すると、デフォルトのカーネルのファイル名およびインデックス番号を見つけて、GRUB ブートローダーに永続的な変更を加えることができます。
手順
- デフォルトのカーネルのファイル名を確認するには、次のように入力します。
# grubby --default-kernel
/boot/vmlinuz-4.18.0-372.9.1.el8.x86_64
- デフォルトのカーネルのインデックス番号を調べるには、次のように入力します。
# grubby --default-index
0
7.3. カーネルの GRUB メニューエントリーの表示
すべてのカーネルメニューエントリーを一覧表示するか、特定のカーネルの GRUB メニューエントリーを表示できます。
手順
すべてのカーネルメニューエントリーを一覧表示するには、次のように入力します。
# grubby --info=ALL index=0 kernel="/boot/vmlinuz-4.18.0-372.9.1.el8.x86_64" args="ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet $tuned_params zswap.enabled=1" root="/dev/mapper/rhel-root" initrd="/boot/initramfs-4.18.0-372.9.1.el8.x86_64.img $tuned_initrd" title="Red Hat Enterprise Linux (4.18.0-372.9.1.el8.x86_64) 8.6 (Ootpa)" id="67db13ba8cdb420794ef3ee0a8313205-4.18.0-372.9.1.el8.x86_64" index=1 kernel="/boot/vmlinuz-0-rescue-67db13ba8cdb420794ef3ee0a8313205" args="ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet" root="/dev/mapper/rhel-root" initrd="/boot/initramfs-0-rescue-67db13ba8cdb420794ef3ee0a8313205.img" title="Red Hat Enterprise Linux (0-rescue-67db13ba8cdb420794ef3ee0a8313205) 8.6 (Ootpa)" id="67db13ba8cdb420794ef3ee0a8313205-0-rescue"
特定のカーネルの GRUB メニューエントリーを表示するには、次のように入力します。
# grubby --info /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64 grubby --info /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64 index=0 kernel="/boot/vmlinuz-4.18.0-372.9.1.el8.x86_64" args="ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet $tuned_params zswap.enabled=1" root="/dev/mapper/rhel-root" initrd="/boot/initramfs-4.18.0-372.9.1.el8.x86_64.img $tuned_initrd" title="Red Hat Enterprise Linux (4.18.0-372.9.1.el8.x86_64) 8.6 (Ootpa)" id="67db13ba8cdb420794ef3ee0a8313205-4.18.0-372.9.1.el8.x86_64"
タブ補完を試行して /boot
ディレクトリー内の利用可能なカーネルを確認します。
7.4. カーネル引数の編集
既存のカーネル引数の値を変更できます。たとえば、仮想コンソール (画面) のフォントとサイズを変更できます。
手順
仮想コンソールのフォントを、サイズが
32
のlatarcyrheb-sun
に変更します。# grubby --args=vconsole.font=latarcyrheb-sun32 --update-kernel /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64
7.5. GRUB メニューエントリーに対する引数の追加および削除
GRUB メニューから引数を追加、削除、または同時に追加および削除できます。
手順
GRUB メニューエントリーに引数を追加するには、
--update-kernel
オプションを--args
と組み合わせて使用します。たとえば、次のコマンドはシリアルコンソールを追加します。# grubby --args=console=ttyS0,115200 --update-kernel /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64
コンソールの引数は行末に付けられ、新しいコンソールは他の設定済みコンソールよりも優先されます。
GRUB メニューエントリーから引数を削除するには、
--update-kernel
オプションを--remove-args
と組み合わせて使用します。以下に例を示します。# grubby --remove-args="rhgb quiet" --update-kernel /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64
このコマンドは、Red Hat グラフィカルブート引数を削除し、詳細モードであるログメッセージを有効にします。
引数を同時に追加および削除するには、次のように入力します。
# grubby --remove-args="rhgb quiet" --args=console=ttyS0,115200 --update-kernel /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64
検証手順
行った永続的な変更を確認するには、次のように入力します。
# grubby --info /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64 index=0 kernel="/boot/vmlinuz-4.18.0-372.9.1.el8.x86_64" args="ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap $tuned_params zswap.enabled=1 console=ttyS0,115200" root="/dev/mapper/rhel-root" initrd="/boot/initramfs-4.18.0-372.9.1.el8.x86_64.img $tuned_initrd" title="Red Hat Enterprise Linux (4.18.0-372.9.1.el8.x86_64) 8.6 (Ootpa)" id="67db13ba8cdb420794ef3ee0a8313205-4.18.0-372.9.1.el8.x86_64"
7.6. 新しいブートエントリーの追加
ブートローダーメニューエントリーに新しいブートエントリーを追加できます。
手順
すべてのカーネル引数をデフォルトカーネルからこの新しいカーネルエントリーにコピーします。
# grubby --add-kernel=new_kernel --title="entry_title" --initrd="new_initrd" --copy-default
利用可能なブートエントリーの一覧を取得します。
# ls -l /boot/loader/entries/* -rw-r--r--. 1 root root 408 May 27 06:18 /boot/loader/entries/67db13ba8cdb420794ef3ee0a8313205-0-rescue.conf -rw-r--r--. 1 root root 536 Jun 30 07:53 /boot/loader/entries/67db13ba8cdb420794ef3ee0a8313205-4.18.0-372.9.1.el8.x86_64.conf -rw-r--r-- 1 root root 336 Aug 15 15:12 /boot/loader/entries/d88fa2c7ff574ae782ec8c4288de4e85-4.18.0-193.el8.x86_64.conf
新たなブートエントリーを作成します。たとえば、4.18.0-193.el8.x86_64 カーネルの場合は、次のようにコマンドを発行します。
# grubby --grub2 --add-kernel=/boot/vmlinuz-4.18.0-193.el8.x86_64 --title="Red Hat Enterprise 8 Test" --initrd=/boot/initramfs-4.18.0-193.el8.x86_64.img --copy-default
検証
新しく追加されたブートエントリーが、使用可能なブートエントリーの一覧に表示されていることを確認します。
# ls -l /boot/loader/entries/* -rw-r--r--. 1 root root 408 May 27 06:18 /boot/loader/entries/67db13ba8cdb420794ef3ee0a8313205-0-rescue.conf -rw-r--r--. 1 root root 536 Jun 30 07:53 /boot/loader/entries/67db13ba8cdb420794ef3ee0a8313205-4.18.0-372.9.1.el8.x86_64.conf -rw-r--r-- 1 root root 287 Aug 16 15:17 /boot/loader/entries/d88fa2c7ff574ae782ec8c4288de4e85-4.18.0-193.el8.x86_64.0~custom.conf -rw-r--r-- 1 root root 287 Aug 16 15:29 /boot/loader/entries/d88fa2c7ff574ae782ec8c4288de4e85-4.18.0-193.el8.x86_64.conf
7.7. grubby でデフォルトのブートエントリーを変更する
grubby
ツールを使用すると、デフォルトのブートエントリーを変更できます。
手順
- デフォルトのカーネルとして指定されたカーネルに永続的な変更を加えるには、次のように入力します。
# grubby --set-default /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64
The default is /boot/loader/entries/67db13ba8cdb420794ef3ee0a8313205-4.18.0-372.9.1.el8.x86_64.conf with index 0 and kernel /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64
7.8. 同じ引数を使用したすべてのカーネルメニューの更新
すべてのカーネルメニューエントリーに同じカーネルブート引数を追加できます。
手順
すべてのカーネルメニューエントリーに同じカーネルブート引数を追加するには、
--update-kernel=ALL
パラメーターをアタッチします。たとえば、次のコマンドはシリアルコンソールをすべてのカーネルに追加します。# grubby --update-kernel=ALL --args=console=ttyS0,115200
注記--update-kernel
パラメーターには、DEFAULT
またはカーネルインデックス番号のコンマ区切りリストも指定できます。
7.9. 関連情報
-
/usr/share/doc/grub2-common
ディレクトリー。 -
info grub2
コマンド。
第8章 カスタマイズされたブートメニューの構築
特定のエントリーを含むブートメニューを作成したり、エントリーの順序を変更したりできます。このようなタスクには、GRUB、grubby
、および Boot Loader Specification (BLS
) ファイルを使用できます。
次のセクションでは、GRUB と grubby
を使用してブートメニューの基本的なカスタマイズを行う方法について説明します。
8.1. GRUB 設定ファイル
BIOS ベースのマシンでは /boot/grub2/grub.cfg
であり、UEFI ベースのマシンでは /boot/efi/EFI/redhat/grub.cfg
であるブートローダー設定ファイルについて学びます。
GRUB スクリプトはユーザーのコンピューターを検索して、スクリプトが見つけたオペレーティングシステムに基づくブートメニューを構築します。最新のシステムブートオプションを反映させるために、カーネルが更新されるか新規カーネルが追加されると、ブートメニューは自動的に再構築されます。
GRUB は、一連のスクリプトを使用してメニューを構築します。これらは /etc/grub.d/
ディレクトリーにあります。このスクリプトは /etc/grub.d/ ディレクトリーに格納されており、以下のファイルが含まれます。
-
00_header
:/etc/default/grub
ファイルから GRUB 設定を読み込みます。 -
01_users
:user.cfg
ファイルから root パスワードを読み取ります。 -
10_linux
: Red Hat Enterprise Linux のデフォルトのパーティションでカーネルを見つけます。 -
30_os-prober
。別のパーティションで見つかったオペレーティングシステム用にエントリーを構築します。 -
40_custom
: 追加のメニューエントリー作成に使用可能なテンプレートです。
GRUB はスクリプトを /etc/grub.d/
ディレクトリーからアルファベット順に読み取るため、スクリプトの名前を変更して、特定のメニューエントリーの起動順序を変更できます。
8.2. 起動可能なカーネルのリストを非表示にする
システムの起動時に GRUB が起動可能なカーネルのリストを表示しないようにすることができます。
手順
/etc/default/grub
ファイルでGRUB_TIMEOUT_STYLE
オプションを次のように設定します。GRUB_TIMEOUT_STYLE=hidden
変更を有効にするために
grub.cfg
ファイルを再ビルドします。BIOS ベースのマシンで、次のように入力します。
# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI ベースのマシンでは、次のように入力します。
# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
- 起動時に Esc キーを押すと、起動可能なカーネルのリストが表示されます。
/etc/default/grub
ファイルで GRUB_TIMEOUT
を 0 に設定して、起動可能なカーネルのリストを非表示にしないでください。このように設定すると、システムが常にデフォルトのメニューエントリーで直ちに起動し、デフォルトのカーネルが起動に失敗した場合に、以前のカーネルを起動することができなくなります。
8.3. GRUB 設定ファイルを使用してデフォルトのブートエントリーを変更する
デフォルトのカーネルパッケージタイプを指定して、デフォルトのブートエントリーを変更できます。
手順
grub2-set-default
コマンドにインデックスを渡して、デフォルトでロードするオペレーティングシステムまたはカーネルを指定します。以下に例を示します。# grubby --set-default-index=1 The default is /boot/loader/entries/d5151aa93c444ac89e78347a1504d6c6-4.18.0-348.el8.x86_64.conf with index 1 and kernel /boot/vmlinuz-4.18.0-348.el8.x86_64
GRUB は、
/boot/grub2/grubenv
のsaved_entry
ディレクティブのキーとして数値を使用して、オペレーティングシステムがロードされるデフォルトの順序を変更することをサポートしています。注記インデックスカウントはゼロから始まります。したがって、前の例では、GRUB は 2 番目のエントリーをロードします。次にインストールされたカーネルで、インデックス値は上書きされます。
注記grubby
を使用して、カーネルのインデックスを見つけることもできます。詳細は、カーネルの GRUB メニューエントリーの表示 を参照してください。オプション: システムが常に特定のメニューエントリーを使用するように強制します。
利用可能なメニューエントリーを一覧表示します。
# grubby --info=ALL
/etc/default/grub
ファイルのGRUB_DEFAULT
ディレクティブのキーとして、メニューエントリー名またはリスト内のメニューエントリーの位置番号を使用します。以下に例を示します。GRUB_DEFAULT=example-gnu-linux
変更を有効にするために
grub.cfg
ファイルを再ビルドします。BIOS ベースのマシンで、次のように入力します。
# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI ベースのマシンでは、次のように入力します。
# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
第9章 GRUB の再インストール
GRUB ブートローダーの誤ったインストールやファイルの欠如、システムの破損などで引き起こされる特定の問題を解決するには、GRUB の再インストールが便利な方法となる場合があります。不足しているファイルを復元し、ブート情報を更新することで、この問題を解決できます。
GRUB を再インストールする理由は次のとおりです。
- GRUB ブートローダーのアップグレード。
- 別のドライブにブート情報を追加する。
- インストールされているオペレーティングシステムを制御するには、GRUB ブートローダーが必要です。ただし、一部のオペレーティングシステムには独自のブートローダーがインストールされており、GRUB を再インストールすると、目的のオペレーティングシステムに制御が戻ります。
GRUB は、ファイルが破損していない場合にのみファイルを復元します。
9.1. BIOS ベースマシンへの GRUB の再インストール
grub2-install
コマンドを使用して GRUB を再インストールできます。
grub2-install
コマンドを既存のブートデバイスで実行すると、既存の GRUB が上書きされ、新しい GRUB がインストールされます。そのため、grub2-install
コマンドを発行する前に、インストール中にシステムがデータの破損やブートクラッシュを引き起こさないようにしてください。
手順
device 引数を指定して
grub2-install
コマンドを発行します。たとえば、sda
がデバイスの場合は、以下のようになります。# grub2-install /dev/sda
システムを再起動して、変更を有効にします。
# reboot
関連情報
-
grub-install(1)
man ページ
9.2. UEFI ベースマシンへの GRUB の再インストール
yum uninstall
コマンドを使用して、GRUB を再インストールできます。
yum reinstall
コマンドを発行する前に、インストール中にシステムがデータの破損やブートクラッシュを引き起こしていないことを確認してください。
手順
grub2-efi
およびshim
ブートローダーファイルを使用してyum reinstall
コマンドを実行します。# yum reinstall grub2-efi shim
システムを再起動して、変更を有効にします。
# reboot
9.3. GRUB のリセット
GRUB をリセットすると、すべての GRUB 設定ファイルとシステム設定が完全に削除され、ブートローダーが再インストールされます。すべての構成設定をデフォルト値にリセットして、破損したファイルや不適切な設定によって引き起こされた障害を修正できます。
次の手順では、ユーザーが行ったすべてのカスタマイズを削除します。
手順
設定ファイルを削除します。
# rm /etc/grub.d/* # rm /etc/sysconfig/grub
パッケージを再インストールします。
BIOS ベースのマシンで、次のように入力します。
# yum reinstall grub2-tools
UEFI ベースのマシンでは、次のように入力します。
# yum reinstall grub2-efi shim grub2-tools
変更を有効にするために
grub.cfg
ファイルを再ビルドします。BIOS ベースのマシンで、次のように入力します。
# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI ベースのマシンでは、次のように入力します。
# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
-
GRUB の再インストール 手順に従って、
/boot/
パーティションに GRUB を復元します。
第10章 GRUB をパスワードで保護する
GRUB をパスワードで保護するには、次の 2 つの方法があります。
- メニューエントリーの修正にはパスワードが必要ですが、既存のメニューエントリーの起動には必要ありません。
- メニューエントリーを変更したり、既存のメニューエントリーを起動するには、パスワードが必要です。
10.1. メニューエントリーを変更するためだけにパスワード保護を設定する
GRUB メニューエントリーを変更するためのパスワード認証をサポートするように GRUB を設定できます。この手順では、ハッシュ形式のパスワードを含む /boot/grub2/user.cfg
ファイルを作成します。
grub2-setpassword
コマンドを使用してパスワードを設定すると、権限のない修正からメニューエントリーは保護されますが、権限のない起動からは保護されません。
手順
root で
grub2-setpassword
コマンドを実行します。# grub2-setpassword
ユーザーのパスワードを入力し、Enter キーを押してパスワードを確認します。
Enter password: Confirm the password:
root ユーザーは、/boot/grub2/grub.cfg
ファイルで定義され、パスワードが変更されます。したがって、ブート中にブートエントリーを変更するには、root ユーザー名とパスワードが必要です。
10.2. メニューエントリーの変更および起動のためのパスワード保護の設定
GRUB を設定して、メニューエントリーが不正に変更されたり、不正に起動されたりするのを防ぐことができます。
GRUB パスワードを忘れると、再設定したエントリーを起動できなくなります。
手順
-
/boot/loader/entries/
ディレクトリーから、変更するブートエントリーのブートローダー仕様 (BLS
) ファイルを開きます。 -
grub_users
で始まる行を見つけます。このパラメーターは追加の引数をmenuentry
に渡します。 grub_users
属性を、スーパーユーザー以外にエントリーを起動できるユーザー名に設定します。デフォルトでは、このユーザーはroot
です。サンプル設定ファイルは次のとおりです。title Red Hat Enterprise Linux (4.18.0-221.el8.x86_64) 8.3 (Ootpa) version 4.18.0-221.el8.x86_64 linux /vmlinuz-4.18.0-221.el8.x86_64 initrd /initramfs-4.18.0-221.el8.x86_64.img $tuned_initrd options $kernelopts $tuned_params id rhel-20200625210904-4.18.0-221.el8.x86_64 grub_users root grub_arg --unrestricted grub_class kernel
-
BLS
ファイルを保存して閉じます。
すべてのメニューエントリーを起動から保護したい場合は、grub_users
属性を直接設定できます。たとえば、root がユーザーの場合は、以下を行います。
# grub2-editenv - set grub_users="root"
第11章 仮想化環境でカーネルパニックのパラメーターを無効のままにする
RHEL 8 に仮想化環境を設定する場合、仮想化環境は、システムパニックを必要としない誤ったソフトロックアップを発生させる可能性があるため、カーネルパラメーター softlockup_panic
および nmi_watchdog
を有効にしないでください。
以下のセクションで、このアドバイスの背後にある理由を見つけてください。
11.1. ソフトロックアップとは
ソフトロックアップは、通常、タスクが再スケジュールされずに CPU のカーネル領域で実行しているときにバグによって生じる状況です。また、このタスクは、その他のタスクがその特定の CPU で実行することを許可しません。これにより、警告が、システムコンソールを介してユーザーに表示されます。この問題は、ソフトロックアップの発生 (fire) とも呼ばれます。
関連情報
11.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
このパラメーターをゼロに設定すると、ロックアップ検出を無効にします。
11.3. 仮想化環境で誤ったソフトロックアップ
ソフトロックアップとは で説明されている物理ホストでのソフトロックアップの発生は、通常、カーネルまたはハードウェアのバグを示しています。仮想化環境のゲストオペレーティングシステムで同じ現象が発生すると、誤った警告が表示される場合があります。
ホストの負荷が重い場合や、メモリーなどの特定リソースに対する競合が多い場合は、通常、ソフトロックアップが誤って発生します。これは、ホストが 20 秒よりも長い期間、ゲストの CPU をスケジュールすることが原因となる場合があります。その後、再度、ホストで実行するようにゲスト CPU がスケジュールされると、タイマーにより発生する 時間ジャンプ が発生します。タイマーには、ウォッチドッグの hrtimer
も含まれます。これにより、ゲスト CPU のソフトロックアップを報告できます。
仮想化環境でのソフトロックアップは誤りである可能性があるため、ゲスト CPU でソフトロックアップが報告されたときにシステムパニックを発生させるカーネルパラメーターは有効にしないでください。
ゲストのソフトロックアップについて理解するには、ホストがゲストをタスクとしてスケジュールしてから、ゲストが独自のタスクをスケジュールしていることを理解することが重要になります。
第12章 データベースサーバーのカーネルパラメーターの調整
特定のデータベースアプリケーションのパフォーマンスに影響を与える可能性のあるカーネルパラメーターのセットには、様々なものがあります。データベースサーバーとデータベースの効率的な運用を確保するには、それぞれのカーネルパラメーターを適切に設定します。
12.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 以降で利用できます。
12.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 秒単位で測定されます。
第13章 カーネルロギングの使用
ログファイルは、システム (カーネル、サービス、および実行中のアプリケーションなど) に関するメッセージが含まれるファイルです。Red Hat Enterprise Linux におけるロギングシステムは、組み込みの syslog プロトコルに基づいています。さまざまなユーティリティーがこのシステムを使用してイベントを記録し、ログファイルにまとめます。このファイルは、オペレーティングシステムの監査や問題のトラブルシューティングに役に立ちます。
13.1. カーネルリングバッファーとは
コンソールは、システムの起動プロセス時に、システム起動の初期段階に関する重要な情報を多数提供します。先に出力されたメッセージが失われないように、カーネルではリングバッファーと呼ばれるものが使用されています。このバッファーは、カーネルコード内の printk()
関数により生成されるブートメッセージなど、すべてのメッセージを格納します。次に、カーネルリングバッファーからのメッセージは、syslog
サービスなどの永続ストレージのログファイルに読み込まれ、保存されます。
上記のバッファーは、固定サイズの循環データ構造であり、カーネルにハードコーディングされています。ユーザーは、dmesg
コマンドまたは /var/log/boot.log
ファイル介して、カーネルリングバッファーに保存されているデータを表示できます。リングバッファーが満杯になると、新しいデータにより古いデータが上書きされます。
関連情報
-
syslog(2)
およびdmesg(1)
の man ページ
13.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 つの値は、以下を定義します。
- 値。コンソールログレベル。コンソールに出力されるメッセージの最低優先度を定義します。
- 値。明示的なログレベルが付いていないメッセージのデフォルトのログレベル。
- 値。コンソールのログレベルに、可能な限り低いログレベル設定を設定します。
値。起動時のコンソールのログレベルのデフォルト値を設定します。
上記の各値は、エラーメッセージを処理するさまざまなルールを定義します。
デフォルトの 7 4 1 7 printk
値を使用することで、カーネルアクティビティーのデバッグを改善できます。ただし、シリアルコンソールと組み合わせると、この printk
設定が原因で、集中的な I/O バーストが発生して、RHEL システムが一時的に応答しなくなる可能性があります。通常 4 4 1 7 に printk
値を設定するとこのような状況を回避できますが、代わりに追加のデバッグ情報が失われてしまいます。
また、quiet
、debug
などの特定のカーネルコマンドラインパラメーターにより、デフォルトの kernel.printk
値が変更される点に注意してください。
関連情報
-
syslog(2)
の man ページ
第14章 kdump のインストール
Red Hat Enterprise Linux の新規インストールでは、デフォルトで kdump
サービスがインストールされ有効になっています。kdump
について、およびデフォルトで有効になっていない場合に kdump
をインストールする方法を説明します。
14.1. kdump とは
kdump
は、クラッシュダンプのメカニズムを提供するサービスです。このサービスでは、分析用にシステムメモリーの内容を保存できます。kdump
は kexec
システムコールを使用し、再起動することなく 2 番目のカーネル (キャプチャーカーネル) で起動し、クラッシュしたカーネルメモリー (クラッシュダンプ またはvmcore) の内容をキャプチャーして、ファイルへ保存します。この第 2 のカーネルは、システムメモリーの予約部分に収納されています。
カーネルクラッシュダンプは、システム障害 (重大なバグ) 時に利用できる唯一の情報になります。したがって、ミッションクリティカルな環境では、kdump
を稼働させることが重要です。Red Hat は、システム管理者が通常のカーネル更新サイクルで kexec-tools
を定期的に更新してテストすることをお勧めします。これは、新しいカーネル機能が実装されている場合に特に重要です。
kdump
は、マシンにインストールされているすべてのカーネルに対して、または指定したカーネルに対してのみ有効にできます。これは、マシンで複数のカーネルが使用されており、その一部が安定しており、クラッシュの心配がない場合に役立ちます。
kdump
をインストールすると、デフォルトの /etc/kdump.conf
が作成されます。このファイルには、既定の最小限の kdump
設定が含まれます。このファイルを編集して、kdump
設定をカスタマイズできますが、必須ではありません。
14.2. Anaconda を使用した kdump のインストール
Anaconda インストーラーでは、対話式インストール時に kdump
設定用のグラフィカルインターフェイス画面が表示されます。インストーラー画面のタイトルは KDUMP で、メインの インストールの概要 画面から利用できます。kdump
を有効にして、必要な量のメモリーを予約できます。
手順
-
Kdump
項目に移動します。 kdump
が有効になっていない場合は有効にします。kdump
に予約するメモリーの量を定義します。
14.3. コマンドラインで kdump のインストール
カスタムの Kickstart インストールなどの一部のインストールオプションでは、デフォルトで kdump
がインストールまたは有効化されない場合があります。この場合は、以下の手順を行ってください。
前提条件
- アクティブな RHEL サブスクリプション
- kexec-tools パッケージ
-
kdump
設定とターゲットの要件をすべて満たしている。詳細は 対応している kdump 設定とターゲット を参照してください。
手順
kdump
がシステムにインストールされているかどうかを確認します。# rpm -q kexec-tools
このパッケージがインストールされている場合は以下を出力します。
kexec-tools-2.0.17-11.el8.x86_64
このパッケージがインストールされていない場合は以下を出力します
package kexec-tools is not installed
kdump
および必要なパッケージをインストールします。# dnf install kexec-tools
kernel-3.10.0-693.el7 以降、kdump
では Intel IOMMU
ドライバーがサポートされています。以前のバージョン (kernel-3.10.0-514[.XYZ].el7 以前) では、Intel IOMMU
のサポートを無効にすることが推奨されています。無効にしないと、キャプチャーカーネルが応答しなくなる可能性が高くなります。
第15章 コマンドラインで kdump の設定
kdump
環境を計画して構築します。
15.1. kdump サイズの見積もり
kdump
環境の計画および構築を行う際に、クラッシュダンプファイルに必要な領域を把握しておくことが重要です。
makedumpfile --mem-usage
コマンドは、クラッシュダンプファイルに必要な領域を推定し、メモリー使用量に関するレポートを生成します。このレポートは、ダンプレベルと、除外して問題ないページを判断するのに役立ちます。
手順
次のコマンドを実行して、メモリー使用量に関するレポートを生成します。
# 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
は、必要なメモリーをページ単位で報告します。つまり、カーネルページサイズを元に、使用するメモリーのサイズを計算する必要があります。
デフォルトでは、RHEL カーネルは、AMD64 および Intel 64 の CPU アーキテクチャーで 4KB のサイズのページを使用し、IBM POWER アーキテクチャーで 64KB のサイズのページを使用します。
15.2. メモリー使用量の設定
kdump
用メモリーは、システムの起動時に予約されます。メモリーサイズは、システムの GRUB (Grand Unified Bootloader) 設定で設定されます。メモリーサイズは、設定ファイルで指定された crashkernel=
オプションの値と、システムの物理メモリーのサイズにより異なります。
crashkernel=
オプションは、複数の方法で定義できます。crashkernel=
値を指定するか、auto
オプションを設定できます。crashkernel=auto
パラメーターは、システムの物理メモリーの合計量に基づいて、メモリーを自動的に予約します。これを設定すると、カーネルは、キャプチャーカーネルに必要な適切な量のメモリーを自動的に予約します。これにより、OOM (Out-of-Memory) エラーの回避に役立ちます。
kdump
の自動メモリー割り当ては、システムのハードウェアアーキテクチャーと利用可能なメモリーサイズによって異なります。
たとえば、AMD64 および Intel 64 の場合には、crashkernel=auto
パラメーターは、利用可能なメモリーが 1GB を超える場合にのみ機能します。64 ビット ARM アーキテクチャーおよび IBM Power Systems では、2GB 以上の使用可能なメモリーが必要です。
システムに、自動割り当ての最小メモリーしきい値より少ないメモリーしかない場合は、手動で予約メモリーの量を設定できます。
前提条件
- root 権限
-
kdump
設定とターゲットの要件をすべて満たしている。詳細は 対応している kdump 設定とターゲット を参照してください。
手順
crashkernel=
オプションを準備してください。たとえば、128 MB のメモリーを予約するには、以下を使用します。
crashkernel=128M
または、インストールされているメモリーの合計量に応じて、予約メモリーサイズを変数に設定できます。変数へのメモリー予約の構文は
crashkernel=<range1>:<size1>,<range2>:<size2>
です。以下に例を示します。crashkernel=512M-2G:64M,2G-:128M
上記の例では、システムメモリーの合計量が 512 MB から 2 GB の場合は、64 MB のメモリーを予約します。メモリーの合計容量が 2 GB を超える場合は、128 MB が予約されます。
予約済みメモリーのオフセット。
crashkernel
予約は非常に早いため、特定の固定オフセットでメモリーを予約する必要があるシステムもあります。また、特別な用途にいくつかの領域を予約したいシステムもあります。オフセットが設定されると、予約メモリーはそこから開始されます。予約メモリーをオフセットするには、以下の構文を使用します。crashkernel=128M@16M
この例では、
kdump
は 16 MB (物理アドレス0x01000000
) から始まる 128 MB のメモリーを予約します。オフセットパラメーターが 0 に設定されている場合、または完全に省略されている場合、kdump
は自動的に予約メモリーをオフセットします。変数のメモリー予約を設定する場合は、この構文を使用することもできます。その場合、オフセットは常に最後に指定されます。以下に例を示します。crashkernel=512M-2G:64M,2G-:128M@16M
crashkernel=
オプションをブートローダー設定に適用します。# grubby --update-kernel=ALL --args="crashkernel=<value>"
<value>
を、前のステップで準備したcrashkernel=
オプションの値に置き換えます。
15.3. kdump ターゲットの設定
クラッシュダンプは通常、ローカルファイルシステムにファイルとして保存され、デバイスに直接書き込まれます。または、NFS
プロトコルまたは SSH
プロトコルを使用して、ネットワーク経由でクラッシュダンプを送信するように設定できます。クラッシュダンプファイルを保存するオプションは、一度に 1 つだけ設定できます。デフォルトの動作では、ローカルファイルシステムの /var/crash/
ディレクトリーに保存されます。
前提条件
-
root
権限 -
kdump
設定とターゲットの要件をすべて満たしている。詳細は 対応している kdump 設定とターゲット を参照してください。
手順
ローカルファイルシステムの
/var/crash/
ディレクトリーにクラッシュダンプファイルを保存するには、/etc/kdump.conf
ファイルを変更して、パスを指定します。path /var/crash
path /var/crash
オプションは、kdump
がクラッシュダンプファイルを保存するファイルシステムへのパスを表します。/etc/kdump.conf
ファイルでダンプターゲットを指定すると、path
は指定されたダンプ出力先に対する相対パスになります。ダンプターゲットが
/etc/kdump.conf
ファイルで指定されていない場合には、path
はルートディレクトリーからの絶対パスになります。現在のシステムにマウントされている内容に応じて、ダンプターゲットと調整されたダンプパスが自動的に適用されます。
kdump
は、ダンプターゲットが /var/crash
にマウントされ、オプションの path
が /etc/kdump.conf
ファイルの /var/crash
として設定されている場合に、クラッシュダンプファイルを /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
設定ファイルを変更します。-
#path /var/crash
の行頭にあるハッシュ記号 ("#") を削除します。 値を対象のディレクトリーパスに置き換えます。以下に例を示します。
path /usr/local/cores
重要RHEL 8 では、
kdump
systemd サービスの開始時に、path
ディレクティブを使用して kdump ターゲットとして定義されたディレクトリーが存在している必要があります。存在していないと、サービスが失敗します。この動作は、サービスの起動時にディレクトリーが存在しなかった場合は自動的に作成されていた RHEL の以前のリリースとは異なります。
-
別のパーティションにファイルを書き込むには、
root
で、以下のように/etc/kdump.conf
設定ファイルを編集します。必要に応じて
#ext4
の行頭にあるハッシュ記号 ("#") を削除します。-
デバイス名 (
#ext4 /dev/vg/lv_kdump
行) -
ファイルシステムラベル (
#0ext4 LABEL=/boot
行) -
UUID (
#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
の行)
-
デバイス名 (
ファイルシステムタイプと、デバイス名、ラベル、UUID を希望の値に変更します。以下に例を示します。
ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
重要LABEL=
またはUUID=
を使用してストレージデバイスを指定することが推奨されます。/dev/sda3
などのディスクデバイス名は、再起動しても一貫性は保証されません。重要IBM Z ハードウェア上の Direct Access Storage Device (DASD) にダンプする場合、処理を行う前に
/etc/dasd.conf
でダンプデバイスが正しく指定されている必要があります。
クラッシュダンプを直接書き込むには、
/etc/kdump.conf
設定ファイルを修正します。-
#raw /dev/vg/lv_kdump
の行頭にあるハッシュ記号 ("#") を削除します。 値を対象のデバイス名に置き換えます。以下に例を示します。
raw /dev/sdb1
-
NFS
を使用してリモートマシンにクラッシュダンプを保存するには、/etc/kdump.conf
設定ファイルを編集します。-
#nfs my.server.com:/export/tmp
の行頭にあるハッシュ記号 ("#") を削除します。 値を、正しいホスト名およびディレクトリーパスに置き換えます。以下に例を示します。
nfs penguin.example.com:/export/cores
-
SSH
を使用してリモートマシンにクラッシュダンプを保存するには、/etc/kdump.conf
設定ファイルを編集します。-
#ssh user@my.server.com
の行頭にあるハッシュ記号 ("#") を削除します。 - 値を正しいユーザー名およびホスト名に置き換えます。
SSH
キーを設定に含めます。-
#sshkey /root/.ssh/kdump_id_rsa
の行頭にあるハッシュ記号 ("#") を削除します。 値を、ダンプ先のサーバー上の正しいキーの場所に変更します。以下に例を示します。
ssh john@penguin.example.com sshkey /root/.ssh/mykey
-
-
15.4. kdump コアコレクターの設定
kdump
では、core_collector
を使用してクラッシュダンプイメージをキャプチャーします。RHEL では、makedumpfile
ユーティリティーがデフォルトのコアコレクターです。これは、以下に示すプロセスによりダンプファイルを縮小するのに役立ちます。
- クラッシュダンプファイルのサイズを圧縮し、さまざまなダンプレベルを使用して必要なページのみをコピーする
- 不要なクラッシュダンプページを除外する
- クラッシュダンプに含めるページタイプをフィルターリングする
構文
core_collector makedumpfile -l --message-level 1 -d 31
オプション
-
-c
、-l
、または-p
:zlib
(-c
オプションの場合)、lzo
(-l
オプションの場合)、またはsnappy
(-p
オプションの場合) のいずれかを使用して、ページごとに圧縮ダンプファイルの形式を指定します。 -
-d
(dump_level)
: ページを除外して、ダンプファイルにコピーされないようにします。 -
--message-level
: メッセージタイプを指定します。このオプションでmessage_level
を指定すると、出力の表示量を制限できます。たとえば、message_level
で 7 を指定すると、一般的なメッセージとエラーメッセージを出力します。message_level
の最大値は 31 です。
前提条件
-
root
権限。 -
kdump
設定とターゲットの要件をすべて満たしている。詳細は 対応している kdump 設定とターゲット を参照してください。
手順
-
root
で、/etc/kdump.conf
設定ファイルを編集し、#core_collector makedumpfile -l --message-level 1 -d 31
の行頭にあるハッシュ記号 ("#") を削除します。 - クラッシュダンプファイルの圧縮を有効にするには、以下のコマンドを実行します。
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 ページ。 - kdump 設定ファイル
15.5. kdump のデフォルト障害応答の設定
デフォルトでは、設定したターゲットの場所で kdump
がクラッシュダンプファイルの作成に失敗すると、システムが再起動し、ダンプがプロセス内で失われます。この場合は、以下の手順を実施します。
前提条件
- root 権限
-
kdump
設定とターゲットの要件をすべて満たしている。詳細は 対応している kdump 設定とターゲット を参照してください。
手順
-
root
で、/etc/kdump.conf
設定ファイルの#failure_action
の行頭にあるハッシュ記号 ("#") を削除します。 値を任意のアクションに置き換えます。
failure_action poweroff
関連情報
15.6. kdump の設定ファイル
kdump
カーネルの設定ファイルは /etc/sysconfig/kdump
です。このファイルは、kdump
カーネルコマンドラインパラメーターを制御します。ほとんどの設定では、デフォルトオプションを使用します。ただし、シナリオによっては、kdump
カーネルの動作を制御するために特定のパラメーターを変更する必要があります。たとえば、kdump
kernel コマンドラインを追加するように変更すると、詳細なデバッグ出力が得られます。
本セクションでは、kdump
の KDUMP_COMMANDLINE_REMOVE
オプションおよび KDUMP_COMMANDLINE_APPEND
オプションの変更方法を説明します。追加の設定オプションの詳細は、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
カーネルの場合は、mce
、cgroup
、numa
、hest_disable
などの特定のモジュールを無効にすると、カーネルエラーを防ぐのに役立ちます。これらのモジュールは、kdump
用に予約されているカーネルメモリーの大部分を消費したり、kdump
カーネルの起動に失敗する可能性があります。例
kdump
カーネルコマンドラインでメモリーcgroup
を無効にするには、以下のコマンドを実行します。KDUMP_COMMANDLINE_APPEND="cgroup_disable=memory"
関連情報
-
Documentation/admin-guide/kernel-parameters.txt
ファイル -
/etc/sysconfig/kdump
ファイル
15.7. kdump 設定のテスト
マシンが実稼働に入る前に、クラッシュダンププロセスが機能し、有効であることをテストできます。
以下のコマンドでは、カーネルがクラッシュします。以下の手順に従う場合は、注意を払ってください。アクティブな実稼働システムで、不注意に使用しないでください。
手順
-
kdump
を有効にしてシステムを再起動します。 kdump
が動作していることを確認します。# systemctl is-active kdump active
Linux カーネルを強制的にクラッシュさせます。
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger
警告上記のコマンドによりカーネルがクラッシュし、再起動が必要になります。
もう一度起動すると、
/etc/kdump.conf
ファイルで指定した場所 (デフォルトでは/var/crash/
) にaddress-YYYY-MM-DD-HH:MM:SS/vmcore
ファイルが作成されます。注記このアクションで、設定の妥当性が確認されます。また、このアクションを使用して、一般的な作業負荷でクラッシュダンプの完了にかかる時間を記録することもできます。
関連情報
第16章 kdump の有効化
インストールされているすべてのカーネルまたは特定のカーネルに対して kdump
サービスを有効にして開始します。
16.1. インストールされているすべてのカーネルでの kdump の有効化
マシンにインストールされているすべてのカーネルに対して、kdump
を有効にして起動できます。
前提条件
- 管理者権限
手順
インストールしたすべてのカーネルに
crashkernel=auto
コマンドラインパラメーターを追加します。# grubby --update-kernel=ALL --args="crashkernel=auto"
kdump
を有効にします。# systemctl enable --now kdump.service
検証
kdump
が実行されていることを確認します。# systemctl status kdump.service ○ kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled) Active: active (live)
16.2. 特定のインストール済みカーネルでの kdump の有効化
マシン上の特定カーネルに対して、kdump
を有効にできます。
前提条件
- 管理者権限
手順
マシンにインストールされているカーネルを一覧表示します。
# ls -a /boot/vmlinuz-* /boot/vmlinuz-0-rescue-2930657cd0dc43c2b75db480e5e5b4a9 /boot/vmlinuz-4.18.0-330.el8.x86_64 /boot/vmlinuz-4.18.0-330.rt7.111.el8.x86_64
特定の
kdump
カーネルを、システムの GRUB (Grand Unified Bootloader) 設定ファイルに追加します。以下に例を示します。
# grubby --update-kernel=vmlinuz-4.18.0-330.el8.x86_64 --args="crashkernel=auto"
kdump
を有効にします。# systemctl enable --now kdump.service
検証
kdump
が実行されていることを確認します。# systemctl status kdump.service ○ kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled) Active: active (live)
16.3. kdump サービスの無効化
システムの起動時に kdump
を無効にするには、以下の手順を行います。
前提条件
-
kdump
設定とターゲットの要件をすべて満たしている。詳細は 対応している kdump 設定とターゲット を参照してください。 -
kdump
のインストール用のオプションがすべて、要件に応じて設定されている。詳しくは kdump のインストール を参照してください。
手順
現在のセッションで
kdump
を停止するには、以下のコマンドを実行します。# systemctl stop kdump.service
kdump
を無効にするには、以下を行います。# systemctl disable kdump.service
kptr_restrict=1
を設定することが推奨されます。これにより、Kernel Address Space Layout (KASLR) が有効かどうかにかかわらず、kdumpctl
はクラッシュカーネルを読み込みます。
トラブルシューティングの手順
kptr_restrict
が (1) に設定されておらず、KASLR が有効になっている場合は、/proc/kcore
ファイルの内容がすべてゼロとして生成されます。したがって、kdumpctl
サービスは /proc/kcore
にアクセスしてクラッシュカーネルを読み込むことができません。
この問題を回避するために、kptr_restrict=1
の設定を推奨する警告メッセージが /usr/share/doc/kexec-tools/kexec-kdump-howto.txt
ファイルに表示されます。
kdumpctl
サービスが必ずクラッシュカーネルを読み込むように、kernel.kptr_restrict=1
が sysctl.conf
ファイルに含まれていることを確認します。
関連情報
- RHEL の 基本的なシステム設定の設定
第17章 Web コンソールで kdump の設定
RHEL 8 Web コンソールで kdump
設定を指定してテストします。
Web コンソールは、RHEL 8 のデフォルトインストールの一部で、システムの起動時に kdump
を有効または無効にします。さらには、kdump
に予約メモリーを設定したり、非圧縮または圧縮の形式で vmcore の保存場所を選択したりすることもできます。
17.1. Web コンソールで kdump メモリーの使用量およびターゲットの場所を設定
以下の手順では、RHEL Web コンソールインターフェイスの Kernel Dump
タブを使用して、kdump
カーネルに予約されているメモリー容量を設定する方法を示しています。この手順では、vmcore
ダンプファイルのターゲットの場所を指定する方法と、設定をテストする方法を説明します。
手順
-
Kernel Dump
タブを開き、kdump
サービスを開始します。 -
コマンドラインで
kdump
のメモリー使用量を設定します。 クラッシュダンプの場所
オプションの横にあるリンクをクリックします。ドロップダウンメニューから
ローカルファイルシステム
を選択し、ダンプを保存するディレクトリーを指定します。または、ドロップダウンから
SSH 経由のリモート
オプションを選択し、SSH プロトコルを使用して、vmcore をリモートマシンに送信します。Server
、ssh key
、Directory
の各フィールドに、リモートマシンのアドレス、ssh キーの場所、およびターゲットディレクトリーを入力します。または、ドロップダウンから
NFS 経由のリモート
オプションを選択し、マウント
フィールドに入力して、NFS プロトコルを使用して vmcore をリモートマシンに送信することもできます。注記圧縮
チェックボックスにチェックマークを入れ、vmcore ファイルのサイズを小さくします。
カーネルをクラッシュして、設定をテストします。
-
Test configuration
をクリックします。 Test kdump settings フィールドで、
Crash system
をクリックします。警告この手順では、カーネルの実行を中断し、システムクラッシュやデータの損失が発生します。
-
17.2. 関連情報
第18章 サポートしている kdump の設定とダンプ出力先
18.1. kdump メモリー要件
kdump
でカーネルクラッシュのダンプをキャプチャーして分析のため保存するには、キャプチャーカーネル用にシステムメモリーの一部を永続的に予約しておく必要があります。予約されている場合、システムメモリーのこの部分はメインカーネルでは使用できません。
メモリー要件は、特定のシステムパラメーターによって異なります。主な要因は、システムのハードウェアアーキテクチャーです。正確なマシンアーキテクチャー (Intel 64 や AMD64 (x86_64) など) を調べ、それを標準出力に出力するには、以下のコマンドを使用します。
$ uname -m
次の表には、利用可能な最新バージョンで kdump
のメモリーサイズを自動的に予約する最小メモリー要件一覧が含まれます。システムのアーキテクチャーと利用可能な物理メモリーの合計に応じて、サイズが変更されます。
表18.1 kdump 用に必要な最小予約メモリー
アーキテクチャー | 使用可能なメモリー | 最小予約メモリー |
---|---|---|
AMD64 と Intel 64 ( | 1 GB から 4 GB | 160 MB のメモリー |
4 GB から 64 GB | 192 MB のメモリー | |
64 GB から 1 TB | 256 MB のメモリー | |
1TB 以上 | 512 MB のメモリー | |
64 ビット ARM アーキテクチャー ( | 2 GB 以上 | 448 MB のメモリー |
IBM Power Systems ( | 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 ( | 1 GB から 4 GB | 160 MB のメモリー |
4 GB から 64 GB | 192 MB のメモリー | |
64 GB から 1 TB | 256 MB のメモリー | |
1TB 以上 | 512 MB のメモリー |
多くのシステムでは、kdump
は必要なメモリー量を予測して、自動的に予約できます。この動作はデフォルトで有効になっていますが、利用可能な合計メモリーサイズが一定以上搭載されているシステムに限られます。この自動割り当て動作に必要なメモリーサイズはシステムのアーキテクチャーによって異なります。
システムのメモリー合計量に基づく予約メモリーの自動設定は、ベストエフォート予測です。実際に必要なメモリーは、I/O デバイスなどの他の要素により異なる場合があります。メモリーが十分でない場合は、カーネルパニックが発生したときにデバッグカーネルがキャプチャーカーネルとして起動できなくなる可能性があります。この問題を回避するには、クラッシュカーネルメモリーを十分なサイズにします。
18.2. メモリー自動予約の最小しきい値
一部のシステムでは、ブートローダー設定ファイルで crashkernel=auto
パラメーターを使用するか、グラフィカル設定ユーティリティーでこのオプションを有効にすることで、kdump
用のメモリーを自動的に割り当てることができます。ただし、この自動予約が機能するには、合計メモリーの特定量のメモリーを利用できる必要があります。必要な容量は、システムのアーキテクチャーによって異なります。
次の表は、自動メモリー割り当てのしきい値の一覧です。システムのメモリーが指定のしきい値よりも小さい場合は、メモリーを手動で設定する必要があります。
表18.2 自動メモリー予約に必要な最小メモリーサイズ
アーキテクチャー | 必要なメモリー |
---|---|
AMD64 と Intel 64 ( | 2 GB |
IBM Power Systems ( | 2 GB |
IBM Z ( | 4 GB |
18.3. サポートしている kdump のダンプ出力先
カーネルクラッシュがキャプチャされたら、vmcore ダンプファイルはデバイスに直接書き込むか、ローカルファイルシステム上でファイルとして保存されるか、ネットワークで送信されます。以下の表に、現在対応のダンプ出力先、または kdump
が明示的に対応していないダンプ出力先の完全な一覧を示します。
タイプ | 対応しているダンプ出力先 | 対応していないダンプ出力先 |
---|---|---|
Raw デバイス | ローカルで添付されたすべての raw ディスクとパーティション | |
ローカルファイルシステム |
直接接続されているディスクドライブ、ハードウェア RAID 論理ドライブ、LVM デバイス、 |
|
リモートディレクトリー |
|
|
ハードウェアおよびソフトウェアイニシエーター上で |
| マルチパスベースのストレージ |
| ||
| ||
| ||
ワイヤレスネットワークインターフェイスを使ってアクセスするリモートディレクトリー |
fadump
(firmware assisted dump) を使用して vmcore を取得し、SSH プロトコルまたは NFS プロトコルを使用してリモートマシンに保存すると、ネットワークインターフェイスの名前が kdump-<interface-name>
に変更になります。名前変更は、<interface-name>
が *eth#
、net#
などのように一般的な場合に発生します。この問題は、初期 RAM ディスク (initrd
) の vmcore 取得スクリプトが、ネットワークインターフェイス名に接尾辞 kdump- を追加して、永続的な名前付けを保護するために発生します。同じ initrd
が通常の起動にも使用されるため、実稼働環境のカーネルのインターフェイス名も変更されます。
関連情報
18.4. 対応している kdump のフィルターレベル
ダンプファイルのサイズを縮小するために、kdump
は makedumpfile
コアコレクターを使用してデータを圧縮し、必要に応じて不要な情報を省略します。以下の表に、makedumpfile
ユーティリティーで現在対応しているフィルターレベルの完全な一覧を示します。
オプション | 説明 |
---|---|
| ゼロページ |
| キャッシュページ |
| キャッシュプライベート |
| ユーザーページ |
| フリーページ |
makedumpfile
コマンドは、透過的な大規模ページおよび hugetlbfs ページの削除に対応しています。これらのタイプの hugepages User Page の両方を考えて、-8
レベルを使用して削除します。
関連情報
18.5. 対応しているデフォルトの障害応答
デフォルトでは、kdump
がコアダンプを作成できない場合、オペレーティングシステムが再起動します。ただし、コアダンプをプライマリーターゲットに保存できない場合は、kdump
が別の操作を実行するように設定できます。次の表は、現在対応しているすべてのデフォルトアクションの一覧です。
オプション | 説明 |
---|---|
| root ファイルシステムにコアダンプの保存を試行します。ネットワーク上のダンプ出力先と併用する場合に特に便利なオプションです。ネットワーク上のダンプ出力先にアクセスできない場合、ローカルにコアダンプを保存するよう kdump の設定を行います。システムは、後で再起動します。 |
| システムを再起動します。コアダンプは失われます。 |
| システムを停止します。コアダンプは失われます。 |
| システムの電源を切ります。コアダンプは失われます。 |
| initramfs 内から shell セッションを実行して、ユーザーが手動でコアダンプを記録できるようにします。 |
|
|
関連情報
18.6. final_action パラメーターの使用
final_action
パラメーターを使用すると、kdump
の成功後、または、 shell
または dump_to_rootfs
を使用した無効な failure_response
メカニズムの完了時に、reboot
、halt
および poweroff
アクションなど、特定の操作を追加で使用できます。final_action
オプションを指定しない場合には、この値はデフォルトで reboot
になります。
手順
/etc/kdump.conf
ファイルを編集し、final_action
パラメーターを追加します。final_action <reboot | halt | poweroff>
kdump
サービスを再起動します。kdumpctl restart
第19章 ファームウェア支援ダンプの仕組み
ファームウェア支援ダンプ (fadump) は、IBM POWER システムの kdump
メカニズムの代わりに提供されるダンプ取得メカニズムです。kexec
および kdump
のメカニズムは、AMD64 および Intel 64 システムでコアダンプを取得する際に役立ちます。ただし、最小システムやメインフレームコンピューターなどの一部のハードウェアでは、オンボードファームウェアを活用してメモリー領域を分離して、クラッシュ分析に重要なデータが誤って上書きされないようにします。本セクションでは、fadump
メカニズムと RHEL との統合方法を説明します。fadump
ユーティリティーは、IBM POWER システムで拡張されたダンプ機能に対して最適化されています。
19.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-dump
が proc
ファイルシステム (procfs
) で利用できるようにします。fadump-aware kdump
スクリプトでは、保存された vmcore
があるかを確認してから、システムの再起動を正常に完了させます。
19.2. ファームウェア支援ダンプメカニズムの有効化
IBM POWER システムのクラッシュダンプ機能は、ファームウェア支援ダンプ (fadump) メカニズムを有効にすることで強化できます。
手順
-
kdump
のインストールと設定 fadump=on
カーネルオプションを有効にします。# grubby --update-kernel=ALL --args="fadump=on"
(オプション) デフォルトを使用する代わりに、予約済みのブートメモリーを指定する場合は、
crashkernel=xxM
オプションを有効にします。ここで、xx
は必要なメモリーの量 (メガバイト単位) です。# grubby --update-kernel=ALL --args="crashkernel=xxM fadump=on"
重要Red Hat は、すべての起動オプションを実行する前に、起動オプションをすべてテストすることを推奨します。クラッシュカーネルから起動時に Out of Memory (OOM) エラーが発生する場合は、クラッシュカーネルが正常に起動できるまで
crashkernel=
引数で指定する値を増やします。この場合は、トライアンドエラーが必要になることがあります。
19.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 でダンプツールを使用するための一連のドキュメントも用意しています。
19.4. Fujitsu PRIMEQUEST システムにおける sadump の使用
Fujitsu sadump
メカニズムは、kdump
が正常に完了しないイベントで fallback
ダンプキャプチャーを提供するように設計されています。sadump
メカニズムは、システムの ManageMent Board (MMB) インターフェイスから手動で呼び出します。MMB を使用して、Intel 64 サーバーまたは AMD 64 サーバーのように kdump
を設定し、sadump
の有効化手順を追加で実施します。
手順
sadump
に対してkdump
が予想どおりに起動するように/etc/sysctl.conf
ファイルで以下の行を追加または編集します。kernel.panic=0 kernel.unknown_nmi_panic=1
警告特に、
kdump
の後にシステムが再起動しないようにする必要があります。kdump
がvmcore
ファイルの保存失敗後にシステムを再起動すると、sadump
を呼び出すことができません。/etc/kdump.conf
のfailure_action
パラメーターをhalt
またはshell
として適切に設定します。failure_action shell
関連情報
- FUJITSU Server PRIMEQUEST 2000 Series インストールマニュアル
第20章 コアダンプの分析
システムクラッシュの原因を確認するには、crash ユーティリティーを使用します。これにより、GDB (GNU Debugger) と非常によく似たインタラクティブなプロンプトを利用できます。このユーティリティーでは、kdump
、netdump
、diskdump
、または xendump
によって作成されたコアダンプ、実行中の Linux システムなどをインタラクティブに分析できます。または、Kernel Oops Analyzer または Kdump Helper ツールを使用する選択肢もあります。
20.1. crash ユーティリティーのインストール
crash ツールをインストールして、コア分析スイートを取得します。
手順
関連するリポジトリーを有効にします。
# subscription-manager repos --enable baseos repository
# subscription-manager repos --enable appstream repository
# subscription-manager repos --enable rhel-8-for-x86_64-baseos-debug-rpms
crash
パッケージをインストールします。# yum install crash
kernel-debuginfo
パッケージをインストールします。# yum install kernel-debuginfo
パッケージは実行中のカーネルに対応し、ダンプ分析に必要なデータを提供します。
関連情報
20.2. crash ユーティリティーの終了
システムクラッシュの原因を分析するため、crash
ユーティリティーを起動します。
前提条件
-
現在実行しているカーネルを特定します (
4.18.0-5.el8.x86_64
など)。
手順
crash
ユーティリティーを起動するには、2 つの必要なパラメーターをコマンドに渡す必要があります。-
debug-info (圧縮解除された vmlinuz イメージ) (特定の
kernel-debuginfo
パッケージに含まれる/usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux
など) 実際の vmcore ファイル。
/var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore
その結果の
crash
コマンドの以下のようになります。# crash /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore
kdump
で取得したのと同じ <kernel> のバージョンを使用します。例20.1 crash ユーティリティーの実行
以下の例は、4.18.0-5.el8.x86_64 カーネルを使用して、2018 年 10 月 6 日 (14:05 PM) に作成されたコアダンプの分析を示しています。
... WARNING: kernel relocated [202MB]: patching 90160 gdb minimal_symbol values KERNEL: /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux DUMPFILE: /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore [PARTIAL DUMP] CPUS: 2 DATE: Sat Oct 6 14:05:16 2018 UPTIME: 01:03:57 LOAD AVERAGE: 0.00, 0.00, 0.00 TASKS: 586 NODENAME: localhost.localdomain RELEASE: 4.18.0-5.el8.x86_64 VERSION: #1 SMP Wed Aug 29 11:51:55 UTC 2018 MACHINE: x86_64 (2904 Mhz) MEMORY: 2.9 GB PANIC: "sysrq: SysRq : Trigger a crash" PID: 10635 COMMAND: "bash" TASK: ffff8d6c84271800 [THREAD_INFO: ffff8d6c84271800] CPU: 1 STATE: TASK_RUNNING (SYSRQ) crash>
-
debug-info (圧縮解除された vmlinuz イメージ) (特定の
対話型プロンプトを終了して
crash
を終了するには、crash
またはq
を使用します。例20.2 crash ユーティリティーの終了
crash> exit ~]#
crash
コマンドは、ライブシステムをデバッグする強力なツールとして使用することもできます。ただし、システムを破損しないように注意してください。
関連情報
20.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 bashps <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/0files <pid>
を実行して、選択した 1 つのプロセスによって開かれたファイルを表示するか、help files
を実行して、files
の使用方法を表示します。-
オープンファイルの情報を表示するには、
20.4. Kernel Oops Analyzer の使用
Kernel Oops Analyzer ツールでは、ナレッジベースの既知の問題で oops メッセージを比較することでクラッシュダンプを分析します。
前提条件
- oops メッセージのセキュリティーを保護し、Kernel Oops Analyzer にフィードしている。
手順
- Kernel Oops Analyzer ツールにアクセスします。
カーネルクラッシュの問題を診断するには、
vmcore
に生成されたカーネルの oops ログをアップロードします。テキストメッセージまたは
vmcore-dmesg.txt
を入力として指定して、カーネルクラッシュの問題を診断することも可能です。
-
DETECT
をクリックして、makedumpfile
からの情報に基づいて既知のソリューションと oops メッセージを比較します。
関連情報
20.5. Kdump Helper ツール
Kdump ヘルパーツールは、提供された情報を使用して kdump
を設定するのに役立ちます。Kdump Helper は、ユーザーの設定に基づいて設定スクリプトを生成します。サーバーでスクリプトを開始して実行すると、kdump
サービスが設定されます。
関連情報
第21章 early kdump を使用した起動時間クラッシュの取得
システム管理者は、kdump
サービスの early kdump
サポートを使用して、起動プロセスの初期段階でクラッシュカーネルの vmcore ファイルを取得できます。本セクションは、early kdump
の概要、設定方法、およびこのメカニズムのステータスを確認する方法を説明します。
21.1. early kdump の概要
kdump
サービスが起動していないと、起動段階でカーネルがクラッシュし、クラッシュしたカーネルメモリーの内容を取得して保存できません。そのため、トラブルシューティングの重要な情報は失われます。
この問題を対処するために、RHEL 8 では、early kdump
機能が kdump
サービスの一部として導入されました。
21.2. early kdump の有効化
本セクションでは、early kdump
機能を有効にして、起動初期のカーネルクラッシュに関する情報が失われるリスクをなくす方法を説明します。
前提条件
- アクティブな RHEL サブスクリプション。
-
システムの CPU アーキテクチャー用の
kexec-tools
パッケージを含むリポジトリー -
kdump
の設定とターゲットの要件を満たしている
手順
kdump
サービスが有効でアクティブであることを確認します。# systemctl is-enabled kdump.service && systemctl is-active kdump.service enabled active
kdump
が有効ではなく、実行されていない場合は、必要な設定をすべて設定し、kdump
サービスが有効化されていることを確認します。起動カーネルの
initramfs
イメージを、early kdump
機能で再構築します。# dracut -f --add earlykdump
rd.earlykdump
カーネルコマンドラインパラメーターを追加します。# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="rd.earlykdump"
システムを再起動して、変更を反映させます。
# reboot
検証手順
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
関連情報
-
/usr/share/doc/kexec-tools/early-kdump-howto.txt
ファイル - What is early kdump support and how do I configure it?
- kdump の有効化
第22章 カーネルライブパッチでパッチの適用
Red Hat Enterprise Linux カーネルのライブパッチソリューションを使用して、システムの再起動またはプロセスの再起動を行わずに、実行中のカーネルにパッチを当てることができます。
このソリューションでは、システム管理者は以下を行うことができます。
- 重大なセキュリティーパッチをカーネルに即座に適用することが可能。
- 長時間実行しているタスクの完了、ユーザーのログオフ、スケジュールダウンタイムを待つ必要がない。
- システムのアップタイムをより制御し、セキュリティーや安定性を犠牲にしない。
重要な、重要なすべての CVE は、カーネルライブパッチソリューションで解決されるわけではありません。この目的は、セキュリティー関連パッチに必要な再起動を減らすことであり、完全になくすことではありません。ライブパッチの範囲の詳細は、RHEL 7 はライブカーネルパッチ (kpatch) をサポートしていますか ? を参照してください。
カーネルのライブマイグレーションパッチと、その他のカーネルサブコンポーネントとの間に、いくらか非互換性が存在します。カーネルのライブパッチを使用する前に、kpatch の制限 を慎重に確認してください。
22.1. kpatch の制限
-
kpatch
機能は、汎用のカーネルアップグレードメカニズムではありません。システムをすぐに再起動できない場合など、単純なセキュリティーおよびバグ修正の更新を適用する場合に使用します。 -
パッチの読み込み中または読み込み後は、
SystemTap
ツールまたはkprobe
ツールを使用しないでください。このようなプローブが削除されるまでは、パッチが適用できなくなる可能性があります。
22.2. サードパーティーのライブパッチサポート
kpatch
ユーティリティーは、Red Hat リポジトリー提供の RPM モジュールを含む、Red Hat がサポートする唯一のカーネルライブパッチユーティリティーです。Red Hat は、Red Hat 提供でないライブカーネルパッチはサポートしません。
サードパーティーのライブパッチで発生する問題に対応する必要がある場合、Red Hat では、原因発見を必要とする調査のアウトセットで、ライブパッチベンダーにケースを開くことを奨していますこれにより、ベンダーが許可すれば、ソースコードの供給が可能になり、Red Hat サポートに調査を依頼する前に、サポート組織への原因追及を支援することがになります。
サードパーティーのライブパッチを実行しているシステムの場合、Red Hat は、Red Hat が同梱し、サポートしているソフトウェアの複製を求める権利を有します。これが可能でない場合、Red Hat は、同じ動作が発生するかどうかを確認するために、ライブパッチを適用せずに、お使いのテスト環境で同じようなシステムとワークロードの展開を求めます。
サードパーティーソフトウェアサポートポリシーの詳細は、Red Hat グローバルサポートサービスは、サードパーティーのソフトウェア、ドライバー、そして認定されていないハードウェアおよびハイパーバイザー、もしくはゲストのオペレーティングシステムについてどのようなサポートを提供していますか ? を参照してください。
22.3. カーネルライブパッチへのアクセス
ライブのカーネルパッチ機能は、RPM パッケージとして提供されるカーネルモジュール (kmod
) として実装されます。
すべてのお客様は、通常のチャンネルから提供されるカーネルライブパッチにアクセスできます。ただし、延長サポートサービスにサブスクライブしていないお客様は、次のマイナーリリースが利用可能になると、現行のマイナーリリースに対する新しいパッチへのアクセスを失うことになります。たとえば、標準のサブスクリプションを購入しているお客様は、RHEL 8.3 カーネルがリリースされるまで RHEL 8.2 カーネルのライブパッチのみを行うことができます。
22.4. カーネルライブパッチのコンポーネント
カーネルのライブパッチのコンポーネントは、以下のようになります。
- カーネルパッチモジュール
- カーネルライブパッチの配信メカニズム
- パッチが適用されるカーネル用に構築したカーネルモジュール。
- パッチモジュールには、カーネルに必要な修正のコードが含まれます。
-
パッチモジュールは、
kpatch
カーネルサブシステムで登録し、置き換えられるオリジナル機能の情報を提供します。また、置換される機能に一致するポインターも含まれます。カーネルパッチモジュールは RPM として提供されます。 -
命名規則は、
kpatch_<kernel version>_<kpatch version>_<kpatch release>
です。名前の kernel version 部分の ドット は、アンダースコア に置き換えます。
kpatch
ユーティリティー- パッチモジュールを管理するためのコマンドラインユーティリティー。
kpatch
サービス-
multiuser.target
で必要なsystemd
サービス。このターゲットは、システムの起動時にカーネルパッチをロードします。 kpatch-dnf
パッケージ- RPM パッケージ形式で配信される DNF プラグイン。このプラグインは、カーネルライブパッチへの自動サブスクリプションを管理します。
22.5. カーネルライブパッチの仕組み
kpatch
カーネルパッチソリューションは、livepatch
カーネルサブシステムを使用して、古い機能の出力先を新しい機能に変更します。ライブカーネルパッチがシステムに適用されると、以下が発生します。
-
カーネルパッチモジュールは、
/var/lib/kpatch/
ディレクトリーにコピーされ、次回の起動時にsystemd
を介して、カーネルへの再適用として登録されます。 -
実行中のカーネルに kpatch モジュールがロードされ、新しいコードのメモリー内の場所を指定するポインターを使用して、新しい機能が
ftrace
メカニズムに登録されます。 -
パッチが当てられた機能にカーネルがアクセスすると、
ftrace
メカニズムにリダイレクトされます。これにより、元々の機能は回避され、パッチを当てたバージョンの機能にカーネルをリダイレクトします。
図22.1 カーネルライブパッチの仕組み

22.6. 現在インストールされているカーネルをライブパッチストリームにサブスクライブする手順
カーネルパッチモジュールは RPM パッケージに含まれ、パッチが適用されたカーネルバージョンに固有のものとなります。各 RPM パッケージは、徐々に蓄積されていきます。
以下の手順では、指定のカーネルに対して、今後の累積パッチ更新をすべてサブスクライブする方法を説明します。ライブパッチは累積的であるため、特定のカーネルにデプロイされている個々のパッチを選択できません。
Red Hat は、Red Hat がサポートするシステムに適用されたサードパーティーのライブパッチをサポートしません。
前提条件
- root 権限
手順
必要に応じて、カーネルバージョンを確認します。
# uname -r 4.18.0-94.el8.x86_64
カーネルのバージョンに一致するライブパッチパッケージを検索します。
# yum search $(uname -r)
ライブパッチパッケージをインストールします。
# 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 のインストールを行うと、指定のカーネルの将来のすべてのライブパッチにシステムがサブスクライブされます。必要に応じて、カーネルがパッチを当てていることを確認します。
# 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(1)
の man ページ - RHEL の 基本的なシステム設定の設定
22.7. ライブパッチストリームに新しいカーネルを自動的にサブスクライブする手順
kpatch-dnf
YUM プラグインを使用して、カーネルパッチモジュール (別称 カーネルライブパッチ) が提供する修正にシステムをサブスクライブできます。このプラグインは、現在システムが使用するカーネルと、今後インストールされる カーネルの 自動 サブスクリプションを有効にします。
前提条件
- root 権限がある。
手順
必要に応じて、インストール済みの全カーネルと、現在実行中のカーネルを確認します。
# 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
kpatch-dnf
プラグインをインストールします。# yum install kpatch-dnf
カーネルライブパッチの自動サブスクリプションを有効にします。
# 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 のインストールを行うと、指定のカーネルの将来のすべてのライブパッチにシステムがサブスクライブされます。
検証手順
インストールされているすべてのカーネルにパッチが当てられていることを確認します。
# 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.rpm
とkpatch-patch-4_18_0-240_15_1-0-1.rpm
パッケージそれぞれからの修正が適用されたことが分かります。
関連情報
-
kpatch(1)
およびdnf-kpatch(8)
の man ページ - RHEL の 基本的なシステム設定の設定
22.8. ライブパッチストリームへの自動サブスクリプションの無効化
カーネルパッチモジュールが提供する修正にシステムをサブスクライブする場合、サブスクリプションは 自動的 です。この機能 (したがって、kpatch-patch
パッケージの自動インストール) を無効にできます。
前提条件
- root 権限がある。
手順
必要に応じて、インストール済みの全カーネルと、現在実行中のカーネルを確認します。
# 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
カーネルライブパッチへの自動サブスクリプションを無効にします。
# yum kpatch manual Updating Subscription Management repositories.
検証手順
成功した出力を確認できます。
# yum kpatch status ... Updating Subscription Management repositories. Last metadata expiration check: 0:30:41 ago on Tue Jun 14 15:59:26 2022. Kpatch update setting: manual
関連情報
-
kpatch(1)
およびdnf-kpatch(8)
の man ページ
22.9. カーネルパッチモジュールの更新
カーネルパッチモジュールが配信され、RPM パッケージを通じて適用されているため、累計のカーネルパッチモジュール更新は、他の RPM パッケージの更新と似ています。
前提条件
- 現在インストールされているカーネルをライブパッチストリームにサブスクライブする手順 に従って、システムがライブパッチストリームにサブスクライブされている。
手順
現在のカーネルの新しい累積バージョンを更新します。
# yum update "kpatch-patch = $(uname -r)"
上記のコマンドは、現在実行中のカーネルに利用可能な更新を自動的にインストールし、適用します。これには、新たにリリースされた累計なライブパッチが含まれます。
もしくは、インストールしたすべてのカーネルパッチモジュールを更新します。
# yum update "kpatch-patch"
システムが同じカーネルで再起動すると、kpatch.service
systemd サービスにより、カーネルが自動的に再適用されます。
関連情報
- RHEL の 基本的なシステム設定の設定
22.10. ライブパッチパッケージの削除
ライブパッチパッケージを削除して、Red Hat Enterprise Linux カーネルライブパッチソリューションを無効にします。
前提条件
- root 権限
- ライブパッチパッケージがインストールされている。
手順
ライブパッチパッケージを選択します。
# yum list installed | grep kpatch-patch kpatch-patch-4_18_0-94.x86_64 1-1.el8 @@commandline …
上記の出力例は、インストールしたライブパッチパッケージを一覧表示します。
ライブパッチパッケージを削除します。
# yum remove kpatch-patch-4_18_0-94.x86_64
ライブパッチパッケージが削除されると、カーネルは次回の再起動までパッチが当てられたままになりますが、カーネルパッチモジュールはディスクから削除されます。今後の再起動では、対応するカーネルにはパッチが適用されなくなります。
- システムを再起動します。
ライブパッチパッケージが削除されたことを確認します。
# yum list installed | grep kpatch-patch
パッケージが正常に削除された場合、このコマンドでは何も出力されません。
必要に応じて、カーネルのライブパッチソリューションが無効になっていることを確認します。
# kpatch list Loaded patch modules:
この出力例では、現在読み込まれているパッチモジュールがないため、カーネルにパッチが適用されておらず、ライブパッチソリューションがアクティブでないことが示されています。
現在、Red Hat はシステムの再起動なしで、ライブパッチを元に戻すことはサポートしていません。ご不明な点がございましたら、サポートチームまでお問い合わせください。
関連情報
-
kpatch(1)
の man ページ - RHEL の 基本的なシステム設定の設定
22.11. カーネルパッチモジュールのアンインストール
Red Hat Enterprise Linux カーネルライブパッチソリューションが、以降の起動時にカーネルパッチモジュールを適用しないようにします。
前提条件
- root 権限
- ライブパッチパッケージがインストールされている。
- カーネルパッチモジュールがインストールされ、ロードされている。
手順
カーネルパッチモジュールを選択します。
# 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 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>
選択したモジュールをアンインストールすると、カーネルは次回の再起動までパッチが当てられますが、カーネルパッチモジュールはディスクから削除されます。
- システムを再起動します。
必要に応じて、カーネルパッチモジュールがアンインストールされていることを確認します。
# kpatch list Loaded patch modules: …
上記の出力例では、ロードまたはインストールされたカーネルパッチモジュールが表示されていません。したがって、カーネルにパッチが適用されておらず、カーネルのライブパッチソリューションはアクティブではありません。
現在、Red Hat はシステムの再起動なしで、ライブパッチを元に戻すことはサポートしていません。ご不明な点がございましたら、サポートチームまでお問い合わせください。
関連情報
-
kpatch(1)
の man ページ
22.12. kpatch.service の無効化
Red Hat Enterprise Linux カーネルライブパッチソリューションが、以降の起動時にすべてのカーネルパッチモジュールをグローバルに適用しないようにします。
前提条件
- root 権限
- ライブパッチパッケージがインストールされている。
- カーネルパッチモジュールがインストールされ、ロードされている。
手順
kpatch.service
が有効化されていることを確認します。# systemctl is-enabled kpatch.service enabled
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)
- システムを再起動します。
必要に応じて、
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
が無効になっており、実行されていないことを証明しています。したがって、カーネルのライブパッチソリューションはアクティブではありません。カーネルパッチモジュールがアンロードされたことを確認します。
# 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 はシステムの再起動なしで、ライブパッチを元に戻すことはサポートしていません。ご不明な点がございましたら、サポートチームまでお問い合わせください。
関連情報
-
kpatch(1)
の man ページ - RHEL の 基本的なシステム設定の設定
第23章 zswap を使用したシステムパフォーマンスの向上
zswap
カーネル機能を有効にすることで、システムパフォーマンスを向上させることができます。
23.1. zswap とは
zswap
は、スワップページ用の圧縮 RAM キャッシュを提供するカーネル機能であり、システムパフォーマンスの向上につながる可能性があります。
このメカニズムは以下のように機能します。zswap
は、スワップアウトされているプロセスにあるページを取得し、動的に割り当てられた RAM ベースのメモリープールへの圧縮を試みます。プールが満杯になると、あるいは RAM を使い果たすと、zswap
はページを LRU (最後に利用してから最も時間が経過しているもの) ベースで圧縮されたキャッシュからバッキングスワップデバイスにエビクトします。ページをスワップキャッシュに展開した後、zswap
はプール内の圧縮バージョンを解放します。
zswap
の利点- 大幅な I/O の削減
- ワークロードパフォーマンスの大幅な向上
Red Hat Enterprise Linux 8 では、zswap
はデフォルトで有効です。
関連情報
23.2. ランタイム時の zswap の有効化
sysfs
インターフェイスを使用して、システムの実行時に zswap
機能を有効にできます。
前提条件
- root 権限がある。
手順
zswap
を有効にします。# echo 1 > /sys/module/zswap/parameters/enabled
検証手順
zswap
が有効になっていることを確認します。# grep -r . /sys/kernel/debug/zswap duplicate_entry:0 pool_limit_hit:13422200 pool_total_size:6184960 (pool size in total in pages) reject_alloc_fail:5 reject_compress_poor:0 reject_kmemcache_fail:0 reject_reclaim_fail:13422200 stored_pages:4251 (pool size after compression) written_back_pages:0
23.3. zswap の永続的な有効化
zswap.enabled=1
カーネルコマンドラインパラメーターを指定して、zswap
機能を永続的に有効にできます。
前提条件
- root 権限がある。
-
grubby
ユーティリティーまたはzipl
ユーティリティーがシステムにインストールされている。
手順
zswap
を永続的に有効にします。# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="zswap.enabled=1"
- システムを再起動して、変更を有効にします。
検証手順
zswap
が有効になっていることを確認します。# cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-372.9.1.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 zswap.enabled=1
第24章 アプリケーションの制限の設定
コントロールグループ (cgroup
) のカーネル機能を使用して、プロセスのハードウェアリソースの制限や優先順位を設定したりまたは分離できます。これにより、アプリケーションのリソース使用状況をより詳細に制御して、効率的に使用できます。
24.1. コントロールグループについて
コントロールグループは、プロセスを階層的に順序付けされた cgroups
グループに編成できる Linux カーネル機能です。階層 (コントロールグループツリー) は、cgroups
仮想ファイルシステムに構造を提供して定義されます。デフォルトでは /sys/fs/cgroup
ディレクトリーにマウントされます。systemd
システムとサービスマネージャーは、cgroups
を利用して、それが管理するすべてのユニットとサービスを組織化します。または、/sys/fs/cgroup/
ディレクトリーでサブディレクトリーを作成および削除することにより、cgroups
階層を手動で管理できます。
リソースコントローラー (カーネルコンポーネント) は、これらのプロセスのシステムリソース (CPU 時間、メモリー、ネットワーク帯域幅、各種組み合わせなど) を制限、優先順位付け、または割り当てることで cgroup
内のプロセスの動作を変更します。
cgroups
に追加された値はプロセスアグリゲーションで、アプリケーションとユーザー間のハードウェアリソースの分割を可能にします。その結果、ユーザー環境の全体的な効率、安定性、およびセキュリティーが向上します。
- コントロールグループ 1
コントロールグループバージョン 1 (
cgroups-v1
) はリソースごとのコントローラー階層を提供します。これは、CPU、メモリー、I/O などの各リソースに、独自のコントロールグループ階層があることを意味します。あるコントローラーが、各リソースの管理において別のものと連携できるように、別のコントロールグループ階層を組み合わせることができます。ただし、2 つのコントローラーは異なるプロセス階層に属する可能性があり、適切な調整はできません。cgroups-v1
コントローラーは、長期間に渡って開発されているため、制御ファイルの動作と命名は均一ではありません。- コントロールグループ 2
階層の柔軟性から生じるコントローラー連携の問題は、control groups version 2 の発展につながっていました。
Control groups version 2 (
cgroups-v2
) では、すべてのリソースコントロールがマウントされることに対して単一のコントロールグループ階層を指定します。コントロールファイルの動作と命名は、さまざまなコントローラーにおいて一貫性があります。
注記cgroups-v2
は、RHEL 8.2 以降のバージョンで完全にサポートされています。詳細は Control Group v2 is now fully supported in RHEL 8 を参照してください。
このサブセクションは、Devconf.cz 2019 プレゼンテーションにを基にしています。[1]
関連情報
- Linux カーネルリソースコントローラーとは
-
cgroups(7)
の man ページ - コントロールグループ内の systemd のロール
24.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-v1
のblkio
へのフォローアップ -
memory
-cgroups-v1
のメモリー
へのフォローアップ -
pids
-cgroups-v1
のpids
と同じ -
RDMA
-cgroups-v1
のrdma
と同じ -
cpu - cpu
-cgroups-v1
のcpu
とcpuacct
へのフォローアップ -
cpuset
- コア機能 (cpus{,.effective}
,mems{,.effective}
) のみを新しいパーティション機能でサポートします。 -
perf_event
- サポートは継承され、明示的な制御ファイルはありません。perf
コマンドにv2 cgroup
をパラメーターとして指定でき、対象のcgroup
内のタスクすべてがプロファイリングされます。
リソースコントローラーは、cgroups-v1
階層または cgroups-v 2
階層のいずれかで使用できますが、両方を同時に使用することはできません。
関連情報
-
cgroups(7)
の man ページ -
/usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/
ディレクトリー内のドキュメント (kernel-doc
パッケージをインストールした後)。
24.3. namespace とは
名前空間は、ソフトウェアオブジェクトを整理および特定するための最も重要な方法の 1 つです。
名前空間は、グローバルシステムリソース (マウントポイント、ネットワークデバイス、ホスト名など) を抽象化してラップすることで、グローバルリソースごとに分離されたインスタンスを含む対象の名前空間にプロセスを表示させることができます。名前空間を使用する最も一般的なテクノロジーの 1 つとしてコンテナーが挙げられます。
特定のグローバルリソースへの変更は、その名前空間のプロセスにのみ表示され、残りのシステムまたは他の名前空間には影響しません。
プロセスがどの名前空間に所属するかを確認するには、/proc/<PID>/ns/
ディレクトリーのシンボリックリンクを確認します。
以下の表は、分離されるサポート対象の名前空間およびリソースを示しています。
名前空間 | 分離 |
---|---|
Mount | マウントポイント |
UTS | ホスト名および NIS ドメイン名 |
IPC | System V IPC、POSIX メッセージキュー |
PID | プロセス ID |
Network | ネットワークデバイス、スタック、ポートなど。 |
User | ユーザーおよびグループ ID |
Control groups | コントロールグループの root ディレクトリー |
関連情報
-
namespaces(7)
およびcgroup_namespaces(7)
man ページ - コントロールグループについて
24.4. cgroups-v1 を使用したアプリケーションへの CPU 制限の設定
アプリケーションが CPU 時間を過剰に消費すると、環境の全体的な健全性に悪影響を及ぼす可能性があります。/sys/fs/
仮想ファイルシステムを使用して、コントロールグループバージョン 1 (cgroups-v1
) を使用してアプリケーションへの CPU 制限を設定します。
前提条件
- root 権限がある。
- 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) ...
手順
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 リソースを大量に消費することを示しています。cpu
リソースコントローラーディレクトリーにサブディレクトリーを作成します。# mkdir /sys/fs/cgroup/cpu/Example/
上記のディレクトリーは、特定のプロセスを配置でき、特定の CPU 制限をプロセスに適用できるコントロールグループです。同時に、一部の
cgroups-v1
インターフェイスファイルとcpu
コントローラー固有のファイルがディレクトリーに作成されます。必要に応じて、新しく作成されたコントロールグループを確認します。
# ll /sys/fs/cgroup/cpu/Example/ -rw-r—r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children -rw-r—r--. 1 root root 0 Mar 11 11:42 cgroup.procs -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.stat -rw-r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user -rw-r—r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us -rw-r—r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us -rw-r—r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us -rw-r—r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us -rw-r—r--. 1 root root 0 Mar 11 11:42 cpu.shares -r—r—r--. 1 root root 0 Mar 11 11:42 cpu.stat -rw-r—r--. 1 root root 0 Mar 11 11:42 notify_on_release -rw-r—r--. 1 root root 0 Mar 11 11:42 tasks
この出力例は、特定の設定や制限を表す
cpuacct.usage
、cpu.cfs._period_us
などのファイルを示しています。これは、Example
コントロールグループのプロセスに設定できます。各ファイル名の前に、そのファイルが属するコントロールグループコントローラーの名前が接頭辞として追加されることに注意してください。デフォルトでは、新しく作成されたコントロールグループは、システムの CPU リソース全体へのアクセスを制限なしで継承します。
コントロールグループの 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
に定義されている) 実行できるようにしています。必要に応じて、制限を確認します。
# cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us 1000000 200000
アプリケーションの 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
コントローラーの使用例を示すために使用されました。アプリケーションが指定のコントロールグループで実行されていることを確認します。
# 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 制限が適用されることを示しています。スロットルしたアプリケーションの現在の 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% に減少していることに注意してください。
cpu.cfs_period_us
および cpu.cfs_quota_us
に対応する cgroups-v2
は、cpu.max
ファイルです。cpu.max
ファイルは、cpu
コントローラーから入手できます。
関連情報
- コントロールグループについて
- Linux カーネルリソースコントローラーとは
-
cgroups(7)
、sysfs(5)
の man ページ
第25章 cgroups-v2 を使用したアプリケーションへの CPU 時間配分の制御
一部のアプリケーションが CPU 時間を多く使用し過ぎて、環境全体の健全性に悪影響を与える場合があります。アプリケーションを コントロールグループバージョン 2 (cgroups-v2
) に配置し、それらのコントロールグループの CPU 制限を設定できます。その結果、アプリケーションの CPU 消費を調整できます。
ユーザーには、コントロールグループに割り当てられる CPU 時間の配分を調整する方法が 2 つあります。
25.1. cgroups-v2 のマウント
RHEL 8 は、システムの起動プロセス中に、デフォルトで cgroup-v1
仮想ファイルシステムをマウントします。cgroup-v2
機能を使用してアプリケーションのリソースを制限するには、システムを手動で設定します。
前提条件
- root 権限がある。
手順
systemd
システムおよびサービスマネージャーによるシステムブート中に、デフォルトでcgroups-v2
をマウントするようにシステムを設定します。# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=1"
これにより、必要なカーネルコマンドラインパラメーターが現在のブートエントリーに追加されます。
systemd.unified_cgroup_hierarchy=1
パラメーターをすべてのカーネルブートエントリーに追加するには、次の手順に従います。# grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1"
- システムを再起動して、変更を有効にします。
検証手順
必要に応じて、
cgroups-v2
ファイルシステムがマウントされていることを確認します。# mount -l | grep cgroup cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate)
cgroups-v2
ファイルシステムが/sys/fs/cgroup/
ディレクトリーに正常にマウントされました。必要に応じて、
/sys/fs/cgroup/
ディレクトリーの内容を確認します。# ll /sys/fs/cgroup/ -r—r—r--. 1 root root 0 Apr 29 12:03 cgroup.controllers -rw-r—r--. 1 root root 0 Apr 29 12:03 cgroup.max.depth -rw-r—r--. 1 root root 0 Apr 29 12:03 cgroup.max.descendants -rw-r—r--. 1 root root 0 Apr 29 12:03 cgroup.procs -r—r—r--. 1 root root 0 Apr 29 12:03 cgroup.stat -rw-r—r--. 1 root root 0 Apr 29 12:18 cgroup.subtree_control -rw-r—r--. 1 root root 0 Apr 29 12:03 cgroup.threads -rw-r—r--. 1 root root 0 Apr 29 12:03 cpu.pressure -r—r—r--. 1 root root 0 Apr 29 12:03 cpuset.cpus.effective -r—r—r--. 1 root root 0 Apr 29 12:03 cpuset.mems.effective -r—r—r--. 1 root root 0 Apr 29 12:03 cpu.stat drwxr-xr-x. 2 root root 0 Apr 29 12:03 init.scope -rw-r—r--. 1 root root 0 Apr 29 12:03 io.pressure -r—r—r--. 1 root root 0 Apr 29 12:03 io.stat -rw-r—r--. 1 root root 0 Apr 29 12:03 memory.pressure -r—r—r--. 1 root root 0 Apr 29 12:03 memory.stat drwxr-xr-x. 69 root root 0 Apr 29 12:03 system.slice drwxr-xr-x. 3 root root 0 Apr 29 12:18 user.slice
/sys/fs/cgroup/
ディレクトリーはルートコントロールグループとも呼ばれ、デフォルトでは、インターフェイスファイル (cgroup
で始まる) と、cpuset.cpus.effective
などのコントローラー固有のファイルが含まれます。さらに、/sys/fs/cgroup/init.scope
、/sys/fs/cgroup/system.slice
、および/sys/fs/cgroup/user.slice
など、systemd
に関連するディレクトリーがいくつかあります。
関連情報
- コントロールグループについて
- Linux カーネルリソースコントローラーとは
-
cgroups(7)
、sysfs(5)
の man ページ
25.2. CPU 時間配分のための cgroup の準備
アプリケーションの CPU 消費を制御するには、特定の CPU コントローラーを有効にして専用のコントロールグループを作成する必要があります。cgroup
ファイルの組織的な明確さを維持するために、/sys/fs/cgroup/
ルートコントロールグループ内に少なくとも 2 つのレベルのサブコントロールグループを作成することが推奨されます。
前提条件
- 制御するプロセスの PID を把握している。
- root 権限がある。
-
cgroups-v2
ファイルシステムをマウントしている。
手順
CPU 消費を制限するアプリケーションのプロセス ID (PID) を特定します。
# top Tasks: 104 total, 3 running, 101 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.6 us, 81.6 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.8 hi, 0.0 si, 0.0 st MiB Mem : 3737.4 total, 3312.7 free, 133.3 used, 291.4 buff/cache MiB Swap: 4060.0 total, 4060.0 free, 0.0 used. 3376.1 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 34578 root 20 0 18720 1756 1468 R 99.0 0.0 0:31.09 sha1sum 34579 root 20 0 18720 1772 1480 R 99.0 0.0 0:30.54 sha1sum 1 root 20 0 186192 13940 9500 S 0.0 0.4 0:01.60 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp ...
この出力例は、
PID 34578
および34579
(sha1sum
の 2 つのアプリケーションとして識別) が多くのリソース (具体的には CPU) を消費していることを示しています。いずれもcgroups-v2
機能の管理に使用するアプリケーションの例です。cpu
およびcpuset
コントローラーが/sys/fs/cgroup/cgroup.controllers
ファイルで利用可能であることを確認します。# cat /sys/fs/cgroup/cgroup.controllers cpuset cpu io memory hugetlb pids rdma
CPU 関連のコントローラーを有効にします。
# echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control # echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_control
これらのコマンドにより、
/sys/fs/cgroup/
ルートコントロールグループ直下のサブグループに対してcpu
およびcpuset
コントローラーが有効になります。サブグループ で指定した各プロセスに対して、基準に基づいてコントロールチェックを適用できます。ユーザーは任意のレベルの
cgroup.subtree_control
ファイルの内容を読み取り、直下のサブグループで有効にするコントローラーについて把握することができます。注記デフォルトでは、ルートコントロールグループの
/sys/fs/cgroup/cgroup.subtree_control
ファイルにはmemory
とpids
コントローラーが含まれます。/sys/fs/cgroup/Example/
ディレクトリーを作成します。# mkdir /sys/fs/cgroup/Example/
/sys/fs/cgroup/Example/
ディレクトリーはサブグループを定義します。また、前の手順では、このサブグループのcpu
コントローラーおよびcpuset
コントローラーを有効にしました。/sys/fs/cgroup/Example/
ディレクトリーを作成すると、cgroups-v2
インターフェイスファイルとcpu
およびcpuset
のコントローラー固有のファイルがディレクトリーに自動的に作成されます。/sys/fs/cgroup/Example/
ディレクトリーには、memory
およびpids
コントローラー用のコントローラー固有のファイルも含まれます。必要に応じて、新たに作成されたサブコントロールグループを確認します。
# ll /sys/fs/cgroup/Example/ -r—r—r--. 1 root root 0 Jun 1 10:33 cgroup.controllers -r—r—r--. 1 root root 0 Jun 1 10:33 cgroup.events -rw-r—r--. 1 root root 0 Jun 1 10:33 cgroup.freeze -rw-r—r--. 1 root root 0 Jun 1 10:33 cgroup.max.depth -rw-r—r--. 1 root root 0 Jun 1 10:33 cgroup.max.descendants -rw-r—r--. 1 root root 0 Jun 1 10:33 cgroup.procs -r—r—r--. 1 root root 0 Jun 1 10:33 cgroup.stat -rw-r—r--. 1 root root 0 Jun 1 10:33 cgroup.subtree_control … -rw-r—r--. 1 root root 0 Jun 1 10:33 cpuset.cpus -r—r—r--. 1 root root 0 Jun 1 10:33 cpuset.cpus.effective -rw-r—r--. 1 root root 0 Jun 1 10:33 cpuset.cpus.partition -rw-r—r--. 1 root root 0 Jun 1 10:33 cpuset.mems -r—r—r--. 1 root root 0 Jun 1 10:33 cpuset.mems.effective -r—r—r--. 1 root root 0 Jun 1 10:33 cpu.stat -rw-r—r--. 1 root root 0 Jun 1 10:33 cpu.weight -rw-r—r--. 1 root root 0 Jun 1 10:33 cpu.weight.nice … -r—r—r--. 1 root root 0 Jun 1 10:33 memory.events.local -rw-r—r--. 1 root root 0 Jun 1 10:33 memory.high -rw-r—r--. 1 root root 0 Jun 1 10:33 memory.low … -r—r—r--. 1 root root 0 Jun 1 10:33 pids.current -r—r—r--. 1 root root 0 Jun 1 10:33 pids.events -rw-r—r--. 1 root root 0 Jun 1 10:33 pids.max
出力例には、
cpuset.cpus
やcpu.max
などのファイルが表示されます。これらのファイルは、cpuset
コントローラーおよびcpu
コントローラーに固有のものです。cpuset
およびcpu
コントローラーは、/sys/fs/cgroup/cgroup.subtree_control
ファイルを使用して、ルート (/sys/fs/cgroup/
) の直下のサブコントローラーグループに対して手動で有効にされます。ディレクトリーには
cgroup.procs
またはcgroup.controllers
などの一般的なcgroup
コントロールインターフェイスファイルがありますが、これは有効なコントローラーに関係なく、すべてのコントロールグループに共通のものです。memory.high
およびpids.max
などのファイルは、memory
およびpids
コントローラーに関連し、ルートコントロールグループ (/sys/fs/cgroup/
) にあり、常にデフォルトで有効になります。デフォルトでは、新しく作成されたサブグループは、制限なしで、システムのすべての CPU およびメモリーリソースへのアクセスを継承します。
/sys/fs/cgroup/Example/
の CPU 関連のコントローラーを有効にし、CPU にのみ関連するコントローラーを取得します。# echo "+cpu" >> /sys/fs/cgroup/Example/cgroup.subtree_control # echo "+cpuset" >> /sys/fs/cgroup/Example/cgroup.subtree_control
これらのコマンドにより、直下のサブコントロールグループに、(
memory
またはpids
コントローラーではなく) CPU 時間の配分の調整に関係するコントローラー だけが設定されるようになります。/sys/fs/cgroup/Example/tasks/
ディレクトリーを作成します。# mkdir /sys/fs/cgroup/Example/tasks/
/sys/fs/cgroup/Example/tasks/
ディレクトリーは、cpu
およびcpuset
コントローラーにのみ関連するファイルを持つサブグループを定義します。必要に応じて、別のサブコントロールグループを確認します。
# ll /sys/fs/cgroup/Example/tasks -r—r—r--. 1 root root 0 Jun 1 11:45 cgroup.controllers -r—r—r--. 1 root root 0 Jun 1 11:45 cgroup.events -rw-r—r--. 1 root root 0 Jun 1 11:45 cgroup.freeze -rw-r—r--. 1 root root 0 Jun 1 11:45 cgroup.max.depth -rw-r—r--. 1 root root 0 Jun 1 11:45 cgroup.max.descendants -rw-r—r--. 1 root root 0 Jun 1 11:45 cgroup.procs -r—r—r--. 1 root root 0 Jun 1 11:45 cgroup.stat -rw-r—r--. 1 root root 0 Jun 1 11:45 cgroup.subtree_control -rw-r—r--. 1 root root 0 Jun 1 11:45 cgroup.threads -rw-r—r--. 1 root root 0 Jun 1 11:45 cgroup.type -rw-r—r--. 1 root root 0 Jun 1 11:45 cpu.max -rw-r—r--. 1 root root 0 Jun 1 11:45 cpu.pressure -rw-r—r--. 1 root root 0 Jun 1 11:45 cpuset.cpus -r—r—r--. 1 root root 0 Jun 1 11:45 cpuset.cpus.effective -rw-r—r--. 1 root root 0 Jun 1 11:45 cpuset.cpus.partition -rw-r—r--. 1 root root 0 Jun 1 11:45 cpuset.mems -r—r—r--. 1 root root 0 Jun 1 11:45 cpuset.mems.effective -r—r—r--. 1 root root 0 Jun 1 11:45 cpu.stat -rw-r—r--. 1 root root 0 Jun 1 11:45 cpu.weight -rw-r—r--. 1 root root 0 Jun 1 11:45 cpu.weight.nice -rw-r—r--. 1 root root 0 Jun 1 11:45 io.pressure -rw-r—r--. 1 root root 0 Jun 1 11:45 memory.pressure
CPU 時間を制御するプロセスが同じ CPU で競合していることを確認します。
# echo "1" > /sys/fs/cgroup/Example/tasks/cpuset.cpus
上記のコマンドは、
Example/tasks
サブコントロールグループに配置されるプロセスが同じ CPU 上で競合するようにします。この設定は、cpu
コントローラーをアクティベートするのに重要です。重要cpu
コントローラーは、該当のサブコントロールグループに、同じ CPU の CPU 時間を取り合うプロセスが 2 つ以上ある場合にのみ、有効になります。
検証手順
必要に応じて、CPU 関連のコントローラーが直下のサブ cgroups に対して有効になっていることを確認します。
# cat /sys/fs/cgroup/cgroup.subtree_control /sys/fs/cgroup/Example/cgroup.subtree_control cpuset cpu memory pids cpuset cpu
オプション:CPU 時間を制御するプロセスが同じ CPU で競合していることを確認します。
# cat /sys/fs/cgroup/Example/tasks/cpuset.cpus 1
関連情報
- コントロールグループについて
- Linux カーネルリソースコントローラーとは
- cgroups-v2 のマウント
-
cgroups(7)
、sysfs(5)
の man ページ
25.3. CPU 帯域幅の調整によるアプリケーションへの CPU 時間配分の制御
特定の cgroup ツリーの下にあるアプリケーションへの CPU 時間の配分を調整するには、cpu
コントローラーの関連ファイルに値を割り当てる必要があります。
前提条件
- root 権限がある。
- CPU 時間の配分を制御する 2 つ以上のアプリケーションがある。
- CPU 時間配分のための cgroup の準備 に記載するように、該当するアプリケーションが同じ CPU の CPU 時間を取り合っていることを確認している。
-
cgroups-v2 のマウント で説明されているように、
cgroups-v2
ファイルシステムをマウントしている。 -
CPU 時間配分のための cgroup の準備 で説明されているのと同様に、親コントロールグループとサブコントロールグループの両方に、
cpu
およびcpuset
コントローラーを有効にしている。 以下の例のように、
/sys/fs/cgroup/
ルートコントロールグループ内に 2 つのレベルの サブコントロールグループ を作成していること。… ├── Example │ ├── tasks …
手順
コントロールグループ内のリソース制限を実現するために CPU 帯域幅を設定します。
# echo "200000 1000000" > /sys/fs/cgroup/Example/tasks/cpu.max
最初の値は、一定の期間にサブグループにある全プロセスをまとめて実行できる許容される時間クォータ (マイクロ秒単位) です。2 番目の値は期間の長さを指定します。
一期間中にコントロールグループ内のプロセスが全体としてこのクォータで指定した時間を使い切ってしまうと、残りの時間がスロットルされて、次の期間まで実行できなくなります。
このコマンドは、
/sys/fs/cgroup/Example/tasks
サブグループの全プロセスが 1 秒ごとに 0.2 秒間のみ CPU で実行されるように、CPU 時間の配分の制御を設定します。つまり、毎秒 5 分の 1 です。必要に応じて、時間クォータを確認します。
# cat /sys/fs/cgroup/Example/tasks/cpu.max 200000 1000000
アプリケーションの PID を
Example/tasks
サブグループに追加します。# echo "34578" > /sys/fs/cgroup/Example/tasks/cgroup.procs # echo "34579" > /sys/fs/cgroup/Example/tasks/cgroup.procs
上記のコマンド例は、目的のアプリケーションが
Example/tasks
サブグループのメンバーになり、このサブグループに設定された CPU 時間の配分を超えないようにします。
検証手順
アプリケーションが指定のコントロールグループで実行されていることを確認します。
# cat /proc/34578/cgroup /proc/34579/cgroup 0::/Example/tasks 0::/Example/tasks
上記の出力は、
Example/tasks
サブグループで実行される指定されたアプリケーションのプロセスを示しています。スロットリングされたアプリケーションの現在の CPU 使用率を確認します。
# top top - 11:13:53 up 23:10, 1 user, load average: 0.26, 1.33, 1.66 Tasks: 104 total, 3 running, 101 sleeping, 0 stopped, 0 zombie %Cpu(s): 3.0 us, 7.0 sy, 0.0 ni, 89.5 id, 0.0 wa, 0.2 hi, 0.2 si, 0.2 st MiB Mem : 3737.4 total, 3312.6 free, 133.4 used, 291.4 buff/cache MiB Swap: 4060.0 total, 4060.0 free, 0.0 used. 3376.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 34578 root 20 0 18720 1756 1468 R 10.0 0.0 37:36.13 sha1sum 34579 root 20 0 18720 1772 1480 R 10.0 0.0 37:41.22 sha1sum 1 root 20 0 186192 13940 9500 S 0.0 0.4 0:01.60 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp ...
PID 34578
およびPID 34579
の CPU 使用率が 10% に減少していることが分かります。Example/tasks
サブグループは、そのプロセスをまとめて 20% の CPU 時間に調整します。コントロールグループにプロセスが 2 つあるため、各プロセスは CPU 時間の 10% を使用できます。
関連情報
- コントロールグループについて
- Linux カーネルリソースコントローラーとは
- cgroups-v2 のマウント
- CPU 時間配分のための cgroup の準備
-
cgroups(7)
、sysfs(5)
の man ページ
25.4. CPU の重みの調整によるアプリケーションへの CPU 時間配分の制御
特定の cgroup ツリーの下にあるアプリケーションへの CPU 時間の配分を調整するには、cpu
コントローラーの関連ファイルに値を割り当てる必要があります。
前提条件
- root 権限がある。
- CPU 時間の配分を制御するアプリケーションがある。
- CPU 時間配分のための cgroup の準備 に記載するように、該当するアプリケーションが同じ CPU の CPU 時間を取り合っていることを確認している。
-
cgroups-v2 のマウント で説明されているように、
cgroups-v2
ファイルシステムをマウントしている。 次の例のように、
/sys/fs/cgroup/
root control group 内に、child control groups グループの 2 階層を作成しました。… ├── Example │ ├── g1 │ ├── g2 │ └── g3 …
-
CPU 時間配分のための cgroup の準備 で説明されているのと同様に、親コントロールグループとサブコントロールグループに、
cpu
およびcpuset
コントローラーを有効にしている。
手順
コントロールグループ内のリソース制限を実現するために、希望する CPU の重みを設定します。
# echo "150" > /sys/fs/cgroup/Example/g1/cpu.weight # echo "100" > /sys/fs/cgroup/Example/g2/cpu.weight # echo "50" > /sys/fs/cgroup/Example/g3/cpu.weight
アプリケーションの PID を
g1
、g2
、およびg3
サブグループに追加します。# echo "33373" > /sys/fs/cgroup/Example/g1/cgroup.procs # echo "33374" > /sys/fs/cgroup/Example/g2/cgroup.procs # echo "33377" > /sys/fs/cgroup/Example/g3/cgroup.procs
上記のコマンドの例は、目的のアプリケーションが
Example/g*/
子 cgroup のメンバーになり、それらの cgroup の設定に従って CPU 時間を分散させることを保証します。実行中のプロセスを持つサブ cgroups(
g1
、g2
、g3
) の重みは、親 cgroup のレベルで合算されます (例
)。その後、CPU リソースはそれぞれの重みに基づいて相対的に配分されます。その結果、すべてのプロセスが同時に実行されると、カーネルはそれぞれの cgroup の
cpu.weight
ファイルに基づいて、それぞれのプロセスに比例配分の CPU 時間を割り当てます。サブ cgroup cpu.weight
ファイルCPU 時間の割り当て g1
150
~ 50% (150/300)
g2
100
~ 33% (100/300)
g3
50
~ 16% (50/300)
cpu.weight
コントローラーファイルの値はパーセンテージではありません。1 つのプロセスが実行を停止し、cgroup
g2
が実行中のプロセスのない状態になると、計算では cgroupg2
が省略され、cgroupsg1
およびg3
の重みだけが考慮されます。サブ cgroup cpu.weight
ファイルCPU 時間の割り当て g1
150
~ 75% (150/200)
g3
50
~ 25% (50/200)
重要サブ cgroup に複数の実行中のプロセスがある場合は、それぞれの cgroup に割り当てられる CPU 時間は、その cgroup のメンバープロセスに均等に配分されます。
検証
アプリケーションが指定のコントロールグループで実行されていることを確認します。
# cat /proc/33373/cgroup /proc/33374/cgroup /proc/33377/cgroup 0::/Example/g1 0::/Example/g2 0::/Example/g3
コマンド出力は、
Example/g*/
サブ cgroups で実行される指定されたアプリケーションのプロセスを示しています。スロットリングされたアプリケーションの現在の CPU 使用率を確認します。
# top top - 05:17:18 up 1 day, 18:25, 1 user, load average: 3.03, 3.03, 3.00 Tasks: 95 total, 4 running, 91 sleeping, 0 stopped, 0 zombie %Cpu(s): 18.1 us, 81.6 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st MiB Mem : 3737.0 total, 3233.7 free, 132.8 used, 370.5 buff/cache MiB Swap: 4060.0 total, 4060.0 free, 0.0 used. 3373.1 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 33373 root 20 0 18720 1748 1460 R 49.5 0.0 415:05.87 sha1sum 33374 root 20 0 18720 1756 1464 R 32.9 0.0 412:58.33 sha1sum 33377 root 20 0 18720 1860 1568 R 16.3 0.0 411:03.12 sha1sum 760 root 20 0 416620 28540 15296 S 0.3 0.7 0:10.23 tuned 1 root 20 0 186328 14108 9484 S 0.0 0.4 0:02.00 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthread ...
注記わかりやすくするために、すべてのサンプルプロセスを単一の CPU で実行するように強制しました。CPU の重みは、複数の CPU で使用される場合にも同じ原則を適用します。
PID 33373
、PID 33374
、およびPID 33377
の CPU リソースは、対応するサブ cgroups に割り当てた重み 150、100、50 に基づいて割り当てられたことが分かります。重みは、各アプリケーションの CPU 時間の約 50%、33%、および 16% の配分に対応します。
関連情報
- コントロールグループについて
- Linux カーネルリソースコントローラーとは
- cgroups-v2 のマウント
- CPU 時間配分のための cgroup の準備
- Resource Distribution Models
-
cgroups(7)
、sysfs(5)
の man ページ
第26章 systemd によるコントロールグループバージョン 1 の使用
cgroup
は、systemd
システムとサービスマネージャー、およびそれらが提供するユーティリティーを使用して管理できます。これは、cgroups
管理の推奨される方法でもあります。
26.1. コントロールグループバージョン 1 における systemd のロール
RHEL 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 …
上記の例では、サービスおよびスコープにプロセスが含まれており、独自のプロセスを含まないスライスに置かれていることを示しています。
関連情報
- Red Hat Enterprise Linux の 基本的なシステム設定の設定
- Linux カーネルリソースコントローラーとは
-
systemd.resource-control(5)
、cgroups(7)
,fork()
、fork(2)
man ページ
26.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
オプションを使用すると、プロセスの終了後もサービスが実行し続けます。
関連情報
- コントロールグループについて
- コントロールグループ内の systemd のロール
- RHEL の 基本的なシステム設定の設定
-
systemd-run (1)
の man ページ
26.3. 永続的なコントロールグループの作成
永続的なコントロールグループをサービスに割り当てるには、そのユニット設定ファイルを編集する必要があります。この設定はシステム再起動後も保存されるので、これを使用して自動的に起動されたサービスを管理できます。
手順
永続的なコントロールグループを作成するには、次のコマンドを実行します。
# systemctl enable <name>.service
上記のコマンドは、ユニット設定ファイルを自動的に
/usr/lib/systemd/system/
ディレクトリーに作成し、デフォルトで<name>.service
をsystem.slice
ユニットに割り当てます。
関連情報
- コントロールグループについて
- コントロールグループ内の systemd のロール
- RHEL の 基本的なシステム設定の設定
-
systemd-run(1)
の man ページ
26.4. コマンドラインでのメモリーリソース制御の設定
プロセスのグループのハードウェアリソースに対するアクセス権限を設定して優先順位を付け、制御する方法の 1 つとして、コマンドラインインターフェイスでコマンドを実行する方法があります。
手順
サービスのメモリー使用量を制限するには、以下を実行します。
# systemctl set-property example.service MemoryMax=1500K
このコマンドは、
example.service
サービスが所属するコントロールグループで実行されるプロセスに対して、1,500 KB のメモリー制限を割り当てます。この設定バリアントのMemoryMax
パラメーターは/etc/systemd/system.control/example.service.d/50-MemoryMax.conf
ファイルで定義され、/sys/fs/cgroup/memory/system.slice/example.service/memory.limit_in_bytes
ファイルの値を制御します。必要に応じて、サービスのメモリー使用量を一時的に制限するには、以下を実行します。
# systemctl set-property --runtime example.service MemoryMax=1500K
このコマンドは、メモリー制限を
example.service
サービスに即座に割り当てます。MemoryMax
パラメーターは、次回起動時まで/run/systemd/system.control/example.service.d/50-MemoryMax.conf
ファイルで定義されます。再起動すると、/run/systemd/system.control/
ディレクトリー全体とMemoryMax
が削除されます。
50-MemoryMax.conf
ファイルは、メモリー制限を 4096 バイトの倍数 (AMD64 および Intel 64 に固有のカーネルページサイズ) として保存します。実際のバイト数は、CPU アーキテクチャーによって異なります。
関連情報
- コントロールグループについて
- Linux カーネルリソースコントローラーとは
-
systemd.resource-control(5)
とcgroups(7)
man ページ - コントロールグループ内の systemd のロール
26.5. ユニットファイルを使用したメモリーリソース制御の設定
各永続的なユニットは systemd
システムおよびサービスマネージャーによって監視され、/usr/lib/systemd/system/
ディレクトリーにユニット設定ファイルがあります。永続的なユニットのリソース制御設定を変更するには、そのユニット設定ファイルをテキストエディターまたはコマンドラインインターフェイスで手動で変更します。
プロセスのグループのハードウェアリソースに対するアクセス権限を設定して優先順位を付け、制御する方法の 1 つとして、ユニットファイルを手動で変更する方法があります。
手順
サービスのメモリー使用量を制限するには、以下のように
/usr/lib/systemd/system/example.service
ファイルを変更します。… [Service] MemoryMax=1500K …
上記の設定では、(
example.service
が含まれる) コントロールグループで実行されるプロセスの最大メモリー消費量に制限があります。注記測定単位のキロバイト、メガバイト、ギガバイト、またはテラバイトを指定するには、接尾辞 K、M、G、または T を使用します。
すべてのユニット設定ファイルを再読み込みします。
# systemctl daemon-reload
サービスを再起動します。
# systemctl restart example.service
- システムを再起動します。
必要に応じて、変更が反映されたことを確認します。
# cat /sys/fs/cgroup/memory/system.slice/example.service/memory.limit_in_bytes 1536000
この出力例では、メモリー消費量が約 1,500 KB に制限されていることを示しています。
注記memory.limit_in_bytes
ファイルは、メモリー制限を 4096 バイトの倍数 (AMD64 および Intel 64 に固有のカーネルページサイズ) として保存します。実際のバイト数は、CPU アーキテクチャーによって異なります。
関連情報
- コントロールグループについて
- Linux カーネルリソースコントローラーとは
-
systemd.resource-control(5)
、cgroups(7)
man ページ - RHEL の 基本的なシステム設定の設定
- コントロールグループ内の systemd のロール
26.6. 一時的なコントロールグループの削除
systemd
システムおよびサービスマネージャーを使用して、プロセスのグループのハードウェアリソースへのアクセスを制限して優先順位を付け、制御する必要がなくなった場合に、一時的なコントロールグループ (cgroup
) を削除できます。
一時的な cgroups
は、サービスまたはスコープユニットに含まれる全プロセスが完了すると、自動的に解放されます、
手順
すべてのプロセスでサービスユニットを停止するには、以下のコマンドを実行します。
# systemctl stop name.service
ユニットプロセスを 1 つ以上終了するには、以下を実行します。
# systemctl kill name.service --kill-who=PID,... --signal=<signal>
上記のコマンドは、
--kill-who
オプションを使用して、終了するコントロールグループからプロセスを選択します。複数のプロセスを同時に強制終了するには、PID のコンマ区切りの一覧を指定します。--signal
オプションは、指定されたプロセスに送信する POSIX シグナルのタイプを決定します。デフォルトのシグナルは SIGTERM です。
関連情報
- コントロールグループについて
- Linux カーネルリソースコントローラーとは
-
systemd.resource-control(5)
、cgroups(7)
man ページ - コントロールグループ内の systemd のロール
- RHEL の 基本的なシステム設定の設定
26.7. 永続的なコントロールグループの削除
systemd
システムおよびサービスマネージャーを使用して、プロセスのグループのハードウェアリソースへのアクセスを制限して優先順位を付け、制御する必要がなくなった場合に、永続的なコントロールグループおよび永続コントロールグループ (cgroup
) を削除できます。
永続的な cgroups
は、サービスまたはスコープユニットが停止または無効化されてその設定ファイルが削除されると解放されます。
手順
サービスユニットを停止します。
# systemctl stop <name>.service
サービスユニットを無効にします。
# systemctl disable <name>.service
関連するユニット設定ファイルを削除します。
# rm /usr/lib/systemd/system/<name>.service
すべてのユニット設定ファイルを再度読み込み、変更を有効にします。
# systemctl daemon-reload
関連情報
- コントロールグループについて
- Linux カーネルリソースコントローラーとは
-
systemd.resource-control(5)
、cgroups(7)
、systemd.kill(5)
man ページ - コントロールグループ内の systemd のロール
- RHEL の 基本的なシステム設定の設定
26.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
オプションでは、サービス および スライス などのユニットタイプのコンマ区切りの一覧、または 読み込み済み、マスク済み などのユニットの読み込み状態が必要です。
関連情報
- RHEL の 基本的なシステム設定の設定
-
systemd.resource-control(5)
、systemd.exec(5)
のマニュアルページ
26.9. systemd コントロールグループ階層の表示
制御グループ (cgroups
) の階層と、特定の cgroups
で実行しているプロセスを表示します。
手順
systemd-cgls
コマンドを使用して、システム上のcgroups
階層全体を表示します。# 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 で形成される最も高いレベルです。systemd-cgls <resource_controller>
コマンドを使用して、リソースコントローラーによってフィルター処理されたcgroups
階層を表示します。# 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 …
上記のコマンドの出力例では、選択したコントローラーと対話するサービスの一覧を表示します。
systemctl status <system_unit>
コマンドを使用して、特定のユニットとcgroups
階層のその部分に関する詳細情報を表示します。# 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
関連情報
- Linux カーネルリソースコントローラーとは
-
systemd.resource-control(5)
、cgroups(7)
man ページ
26.10. リソースコントローラーの表示
どのプロセスがどのリソースコントローラーを使用しているかを調べます。
手順
プロセスが対話するリソースコントローラーを表示し、
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)
の man ページ -
/usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/
ディレクトリーのドキュメント
26.11. リソース消費の監視
現在実行中のコントロールグループ (cgroups
) とそのリソース消費のリストをリアルタイムで表示します。
手順
systemd-cgtop
コマンドを使用して、現在実行中のcgroups
の動的アカウントを表示します。# systemd-cgtop Control Group Tasks %CPU Memory Input/s Output/s / 607 29.8 1.5G - - /system.slice 125 - 428.7M - - /system.slice/ModemManager.service 3 - 8.6M - - /system.slice/NetworkManager.service 3 - 12.8M - - /system.slice/accounts-daemon.service 3 - 1.8M - - /system.slice/boot.mount - - 48.0K - - /system.slice/chronyd.service 1 - 2.0M - - /system.slice/cockpit.socket - - 1.3M - - /system.slice/colord.service 3 - 3.5M - - /system.slice/crond.service 1 - 1.8M - - /system.slice/cups.service 1 - 3.1M - - /system.slice/dev-hugepages.mount - - 244.0K - - /system.slice/dev-mapper-rhel\x2dswap.swap - - 912.0K - - /system.slice/dev-mqueue.mount - - 48.0K - - /system.slice/example.service 2 - 2.0M - - /system.slice/firewalld.service 2 - 28.8M - - ...
この出力例では、現在実行中の
cgroups
が、リソースの使用状況 (CPU、メモリー、ディスク I/O 負荷) 別に表示されています。デフォルトでは 1 秒ごとに一覧が更新されます。そのため、コントロールグループごとに、実際のリソースの使用状況について動的な見解が得られるようになります。
関連情報
-
systemd-cgtop(1)
manual page
第27章 systemd での cgroups バージョン 2 を使用するリソース管理の設定
systemd は主に、サービスの管理と監視を行い、適切なサービスが適切なタイミングで、起動プロセス中に正しい順番に起動されるようにします。サービスの実行時には、スムーズに実行して基盤のハードウェアプラットフォームを最適に使用する必要があります。したがって、systemd には、リソース管理ポリシーの定義や、さまざまなオプションを調整する機能もあるので、サービスのパフォーマンスが改善されます。
27.1. 前提条件
- Linux cgroup サブシステムの基本知識。
27.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 でこのリソースのタイプとして、リアルタイムの予算などが例として挙げられます。
27.3. systemd を使用した CPU リソースの割り当て
systemd
が管理するシステムでは、各システムサービスは対象の cgroup
で起動します。CPU cgroup
コントローラーのサポートを有効にすると、システムはプロセスごとのディストリビューションではなく、CPU リソースのサービス対応ディストリビューションを使用します。サービス対応ディストリビューションでは、サービスを設定するプロセスの数にかかわらず、システムで実行中の他の全サービスと比較して、ほぼ同じ CPU 時間を受け取ります。
特定のサービスで多くの CPU リソースが必要な場合は、サービスの CPU 時間割り当てポリシーを変更することでリソースを付与できます。
手順
systemd
の使用時に CPU 時間割り当てポリシーオプションを設定するには、以下を実行します。
選択したサービスで、CPU 時間割り当てポリシーオプションに割り当てた値を確認します。
$ systemctl show --property <CPU time allocation policy option> <service name>
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>
27.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 ページを参照してください。
27.5. systemd を使用したメモリーリソースの割り当て
systemd
を使用してメモリーリソースを割り当てるには、任意のメモリー設定オプション (MemoryMin
、MemoryLow
、MemoryHigh
、MemoryMax
、MemorySwapMax
) を使用します。
手順
systemd
の使用時にメモリー割り当て設定オプションを指定するには、以下を実行します。
選択したサービスで、メモリー割り当て設定オプションに割り当てた値を確認します。
$ systemctl show --property <memory allocation configuration option> <service name>
root
として、メモリー割り当ての設定オプションで必要な値を設定します。# systemctl set-property <service name> <memory allocation configuration option>=<value>
cgroup
プロパティーは、プロパティーの設定直後に適用されます。したがって、このサービスを再起動する必要はありません。
検証手順
サービスのメモリー割り当て設定オプションの必要な値が正常に変更されたかどうかを確認するには、次のように入力します。
$ systemctl show --property <memory allocation configuration option> <service name>
27.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
の値を減らして、メモリーの耐性を高めます。
27.7. systemd を使用した I/O 帯域幅の設定
RHEL 8 で特定のサービスのパフォーマンスを改善するには、systemd
を使用してそのサービスに I/O 帯域幅リソースを割り当てることができます。
これには、以下の I/O 設定オプションを使用できます。
- IOWeight
- IODeviceWeight
- IOReadBandwidthMax
- IOWriteBandwidthMax
- IOReadIOPSMax
- IOWriteIOPSMax
手順
systemd
を使用して I/O 帯域幅設定オプション を設定するには、以下を実行します。
選択したサービスで、I/O 帯域幅設定オプションに割り当てた値を確認します。
$ systemctl show --property <I/O bandwidth configuration option> <service name>
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>
27.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
などです。IOReadBandwidthMax
、IOWriteBandwidthMax
デバイスまたはマウントポイントごとの絶対帯域幅を設定します。
たとえば、
IOWriteBandwith=/var/log 5M
などです。注記systemd は、ファイルシステムからデバイスの変換を自動的に処理します。
IOReadIOPSMax
、IOWriteIOPSMax
- 1 つ前のオプションと同様: Input/Output Operations Per second (IOPS) の絶対帯域幅を設定します。
加重ベースのオプションは、ブロックデバイスが CFQ I/O スケジューラーを使用している場合にのみサポートされます。デバイスが Multi-Queue Block I/O キューメカニズムを使用する場合は、オプションのサポートはありません。
27.9. systemd を使用した CPUSET コントローラーの設定
systemd
リソース管理 API により、ユーザーはサービスが使用できる CPU および NUMA ノードのセットに制限を設定できます。この制限により、プロセスによって使用されるシステムリソースへのアクセスを制限します。要求された設定は cpuset.cpus
および cpuset.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
第28章 systemd を使用した CPU のアフィニティーおよび NUMA ポリシーの設定
CPU 管理、メモリー管理、および I/O 帯域幅オプションで、利用可能なリソースを分割します。
28.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 アフィニティーマスクを設定するには以下を実行します。
選択したサービスで
CPUAffinity
ユニットファイルオプションの値を確認します。$ systemctl show --property <CPU affinity configuration option> <service name>
root として、アフィニティーマスクとして使用する CPU 範囲の
CPUAffinity
ユニットファイルで必要な値を設定します。# systemctl set-property <service name> CPUAffinity=<value>
サービスを再起動して変更を適用します。
# systemctl restart <service name>
manager configuration オプションを使用して特定の systemd サービスの CPU アフィニティーマスクを設定するには、以下を実行します。
/etc/systemd/system.conf
ファイルを編集します。# vi /etc/systemd/system.conf
-
CPUAffinity=
オプションを検索して、CPU 数を設定します。 - 編集したファイルを保存し、サーバーを再起動して変更を適用します。
28.2. systemd を使用した NUMA ポリシーの設定
Non-Uniform Memory Access (NUMA) は、コンピューターメモリーのサブシステム設計で、この設計ではメモリーのアクセス時間は、プロセッサーからの物理メモリーの場所により異なります。
CPU に近いメモリーは、別の CPU のローカルにあるメモリーや、一連の CPU 間で共有されているメモリーと比べ、レイテンシーが低くなっています (外部メモリー)。
Linux カーネルでは、NUMA ポリシーを使用して、カーネルがプロセス用に物理メモリーを割り当てる場所 (例: NUMA ノード) を制御します。
systemd
は、サービスのメモリー割り当てポリシーを制御するためのユニットファイルオプション NUMAPolicy
および NUMAMask
を提供します。
手順
NUMAPolicy
ユニットファイル オプションで NUMA メモリーポリシーを設定するには以下を実行します。
選択したサービスで
NUMAPolicy
ユニットファイルオプションの値を確認します。$ systemctl show --property <NUMA policy configuration option> <service name>
root として、
NUMAPolicy
ユニットファイルオプションに必要なポリシータイプを設定します。# systemctl set-property <service name> NUMAPolicy=<value>
サービスを再起動して変更を適用します。
# systemctl restart <service name>
manager configuration オプションを使用してグローバルな NUMAPolicy
を設定するには、次のようにします。
-
/etc/systemd/system.conf
ファイルでNUMAPolicy
オプションを検索します。 - ポリシータイプを編集してファイルを保存します。
systemd
設定をリロードします。# systemd daemon-reload
- サーバーを再起動します。
bind
などの厳密な NUMA ポリシーを設定する場合は、CPUAffinity=
ユニットファイルオプションも適切に設定されていることを確認してください。
関連情報
- systemd の NUMA ポリシー設定オプション
-
systemd.resource-control(5)
、systemd.exec(5)
、set_mempolicy(2)
のマニュアルページ
28.3. systemd の NUMA ポリシー設定オプション
Systemd で以下のオプションを指定して、NUMA ポリシーを設定します。
NUMAPolicy
実行したプロセスの NUMA メモリーポリシーを制御します。以下のポリシー種別を使用できます。
- default
- preferred
- bind
- interleave
- local
NUMAMask
選択した NUMA ポリシーに関連付けられた NUMA ノード一覧を制御します。
NUMAmask
オプションは、以下のポリシーに指定する必要はありません。- default
- local
優先ポリシーの場合、この一覧で指定できるのは単一の NUMA ノードのみです。
関連情報
-
systemd.resource-control(5)
、systemd.exec(5)
、およびset_mempolicy(2)
の man ページ - systemd を使用した NUMA の設定
第29章 BPF コンパイラーコレクションでシステムパフォーマンスの分析
システム管理者として BPF コンパイラーコレクション (BCC) ライブラリーで Linux オペレーティングシステムのパフォーマンスを分析するツールを作成します。ただし、他のインターフェイス経由での取得は困難な場合があります。
29.1. BCC の概要
BPF コンパイラーコレクション (BCC) は、eBPF (extended Berkeley Packet Filter) プログラムの作成を容易にするライブラリーです。この主なユーティリティーは、オーバーヘッドやセキュリティー上の問題が発生することなく、OS のパフォーマンスおよびネットワークパフォーマンスを分析するものです。
BCC により、ユーザーは eBPF の技術詳細を把握する必要がなくなり、事前に作成した eBPF プログラムを含む bcc-tools
パッケージなど、多くの標準スタートポイントを利用できます。
eBPF プログラムは、ディスク I/O、TCP 接続、プロセス作成などのイベントでトリガーされます。プログラムがカーネルのセーフ仮想マシンで実行するため、カーネルがクラッシュしたり、ループしたり、応答しなくなることはあまりありません。
29.2. bcc-tools パッケージのインストール
bcc-tools
パッケージをインストールします。これにより、依存関係として BPF Compiler Collection (BCC) ライブラリーもインストールされます。
手順
bcc-tools
をインストールします。#
yum install bcc-tools
BCC ツールは、
/usr/share/bcc/tools/
ディレクトリーにインストールされます。必要に応じて、ツールを検証します。
#
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
ディレクトリーには、各ツールのドキュメントが含まれます。
29.3. bcc-tools でパフォーマンスの分析
BPF Compiler Collection (BCC) ライブラリーから事前に作成された特定のプログラムを使用して、システムパフォーマンスをイベントごとに効率的かつ安全に分析します。BCC ライブラリーで事前作成されたプログラムセットは、追加プログラム作成の例として使用できます。
前提条件
- bcc-tools パッケージがインストールされている
- root 権限
execsnoop を使用したシステムプロセスの検証
1 つの端末で
execsnoop
プログラムを実行します。# /usr/share/bcc/tools/execsnoop
たとえば、別のターミナルで次のように実行します。
$ ls /usr/share/bcc/tools/doc/
これにより、
ls
コマンドの短命プロセスが作成されます。execsnoop
を実行している端末は、以下のような出力を表示します。PCOMM PID PPID RET ARGS ls 8382 8287 0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/ ...
execsnoop
プログラムは、新しいプロセスごとに出力行を出力するため、システムリソースを消費します。また、ls
などの非常に短期間に実行されるプログラムのプロセスを検出します。なお、ほとんどの監視ツールはそれらを登録しません。execsnoop
出力には以下のフィールドが表示されます。-
PCOMM - 親プロセス名。(
ls
) -
PID - プロセス ID(
8382
) -
ppid: 親プロセス ID。(
8287
) -
RET -
exec()
のシステム呼び出しの戻り値 (0
)。プログラムコードを新規プロセスに読み込みます。 - ARGS - 引数を使用して開始したプログラムの場所。
-
PCOMM - 親プロセス名。(
execsnoop
の詳細、例、およびオプションを確認するには、/usr/share/bcc/tools/doc/execsnoop_example.txt
ファイルを参照してください。
exec()
の詳細は、exec(3)
man ページを参照してください。
opensnoop を使用した、コマンドにより開かれるファイルの追跡
1 つのターミナルで
opensnoop
プログラムを実行します。# /usr/share/bcc/tools/opensnoop -n uname
上記の出力では、
uname
コマンドのプロセスによってのみ開かれるファイルの内容が出力されます。別のターミナルで、次のように実行します。
$ uname
上記のコマンドは、特定のファイルを開きます。このファイルは次のステップでキャプチャーされます。
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
は、適切に動作しないアプリケーションの特定に役立ちます。
-
PID - プロセス ID(
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 秒ごとに出力画面が更新されます。
別の端末で、たとえば次のように実行します。
# dd if=/dev/vda of=/dev/zero
上記のコマンドは、ローカルのハードディスクデバイスからコンテンツを読み込み、出力を
/dev/zero
ファイルに書き込みます。この手順では、biotop
を示す特定の I/O トラフィックを生成します。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)
-
PID - プロセス ID(
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 よりも低速な操作を表示します。別のターミナルで、たとえば次のように入力します。
$ vim text
上記のコマンドは、
vim
エディターでテキストファイルを作成し、XFS ファイルシステムと特定の対話を開始します。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 - 読み取り、書き込み、または同期するファイルです。
-
COMM - プロセス名。(
xfsslower
の詳細、例、およびオプションについては、/usr/share/bcc/tools/doc/xfsslower_example.txt
ファイルを参照してください。
fsync
の詳細は、fsync(2)
の man ページを参照してください。
第30章 カーネル整合性サブシステムによるセキュリティーの強化
カーネル整合性サブシステムのコンポーネントを使用して、システムの保護を強化できます。関連するコンポーネントとその設定の詳細をご覧ください。
30.1. カーネル整合性サブシステム
整合性サブシステムは、全体的なシステムデータの整合性を維持するロールを担うカーネルの一部です。このサブシステムは、特定のシステムの状態を構築時と同じに保つのに役立ち、特定のシステムファイルに対する望ましくない変更を防ぎます。
カーネル整合性サブシステムは、2 つの主要なコンポーネントで設定されています。
- Integrity Measurement Architecture (IMA)
- ファイルが実行されるか開かれるたびに、暗号学的にハッシュするか、暗号化キーで署名することにより、ファイルの内容を測定します。キーは、カーネルキーリングサブシステムに格納されます。
- 測定された値をカーネルのメモリー領域に置くと、システムのユーザーが変更を加えることができなくなります。
- ローカルおよびリモートのユーザーが測定値を検証できるようにします。
- カーネルメモリー内の測定リストに以前に格納された値に対して、ファイルの現在の内容をローカルで検証します。この拡張機能は、現在の措置と以前の措置が一致しない場合に、特定のファイルに対して操作を実行することを禁止します。
- Extended Verification Module (EVM)
- IMA 測定値や SELinux 属性など、システムセキュリティーに関連するファイルの拡張属性 (xattr とも呼ばれます) を保護します。コンポーネントは、対応する値を暗号的にハッシュするか、暗号鍵で署名します。キーは、カーネルキーリングサブシステムに格納されます。
カーネル整合性サブシステムは、TPM (Trusted Platform Module) を利用して、システムのセキュリティーをさらに強化できます。TPM は、重要な暗号化機能についての TNC (Trusted Computing Group) による仕様です。TPM は通常、プラットフォームのマザーボードに接続されている専用のハードウェアとして構築され、ハードウェアチップの改ざん防止の保護領域から暗号化機能を提供することでソフトウェアベースの攻撃を防ぎます。TPM 機能には、以下の機能が含まれます。
- 乱数ジェネレーター
- 暗号化キーのジェネレーターと安全なストレージ
- ハッシュジェネレーター
- リモート認証
30.2. Integrity Measurement Architecture
Integrity Measurement Architecture (IMA) は、カーネル整合性サブシステムのコンポーネントです。IMA は、ローカルファイルのコンテンツを維持することを目的としています。具体的には、IMA はアクセスされる前にファイルのハッシュを測定、保存、評価します。これにより、信頼できないデータの読み取りと実行が防止されます。これにより、デジタル署名付きの IMA を使用することで、システムのセキュリティーが強化され、測定データの偽造が防止されます。このシナリオでは、攻撃者が元の署名キーを所有していないことを前提としています。
30.3. Extended Verification Module
Extended Verification Module (EVM) は、ファイルの拡張属性 (xattr) の変更を監視するカーネル整合性サブシステムに属するコンポーネントです。セキュリティー指向のテクノロジーの多くは、コンテンツハッシュや署名などの機密ファイル情報をファイルの拡張属性に格納します。EVM はさらに一歩進んで、これらの拡張属性をハッシュまたは署名します。結果のデータは、拡張属性が使用されるたびに検証されます。たとえば、IMA がファイルを評価する場合です。
30.4. 信頼できる鍵および暗号化された鍵
信頼できる鍵 および 暗号化鍵 は、システムセキュリティーを強化する上で重要な要素です。
信頼できる鍵と暗号化された鍵は、カーネルキーリングサービスを使用するカーネルが生成する可変長の対称鍵です。キーの整合性を検証できます。つまり、実行中のシステムの整合性を検証および確認するために、Extended Verification Module (EVM) などでキーを使用できます。ユーザーレベルのプログラムがアクセス可能なのは、暗号化された ブロブ の形式での鍵のみです。
信頼できる鍵は、鍵の作成と暗号化 (保護) の両方に使用される Trusted Platform Module (TPM) チップというハードウェアコンポーネントを必要とします。TPM は、プライマリー storage root key と呼ばれるキーを使用してキーを保護します。
Red Hat Enterprise Linux 8 は、TPM 1.2 と TPM 2.0 の両方をサポートしています。詳細は、Trusted Platform Module (TPM) は Red Hat でサポートされていますか? を参照してください。
TPM 2.0 チップが有効になっていることを確認できます。
$ cat /sys/class/tpm/tpm0/tpm_version_major
2
また、マシンファームウェアの設定を使用して TPM 2.0 チップを有効にし、TPM 2.0 デバイスを管理することもできます。
さらに、ユーザーは TPM の platform configuration register (PCR) 値の特定セットで信頼できる鍵を保護できます。PCR には、ファームウェア、ブートローダー、およびオペレーティングシステムを反映する整合性管理値のセットが含まれます。つまり、PCR で保護された鍵は、暗号化を行った同じシステム上にある TPM でしか復号できません。ただし、PCR で保護された信頼できる鍵が読み込まれると (キーリングに追加されると)、新しいカーネルなどを起動できるように、関連する PCR 値が検証され、新しい (または今後の) PCR 値に更新されます。1 つの鍵を複数のブロブとして保存することもできますが、それぞれ PCR 値が異なります。
暗号化鍵は、カーネルの AES (Advanced Encryption Standard) を使用するため、TPM を必要としないので、信頼できる鍵よりも高速になります。暗号化鍵は、カーネルが生成した乱数を使用して作成され、ユーザー空間のブロブへのエクスポート時に マスターキー により暗号化されます。
マスターキーは信頼できる鍵か、ユーザーキーのいずれかです。マスターキーが信頼されていない場合には、暗号化鍵のセキュリティーは、暗号化に使用されたユーザーキーと同じように保護されます。
30.5. 信頼できる鍵での作業
keyctl
ユーティリティーを使用して、信頼できるキーを作成、エクスポート、ロード、または更新して、システムのセキュリティーを向上させることができます。
前提条件
-
64 ビット ARM アーキテクチャーおよび IBM Z の場合は、
信頼できる
カーネルモジュールを読み込む必要があります。カーネルモジュールの管理 を参照してください。 - Trusted Platform Module (TPM) を有効にしてアクティブにする必要があります。カーネル整合性サブシステム および 信頼できる鍵および暗号化鍵 を参照してください。
Red Hat Enterprise Linux 8 は、TPM 1.2 と TPM 2.0 の両方をサポートしています。TPM 1.2 を使用する場合は、ステップ 1 をスキップして、ステップ 2 で # keyctl add trusted <NAME> "new <KEY_LENGTH>" <KEYRING> 構文を使用します。
# keyctl add trusted kmk "new 32" @u
手順
たとえば、81000001 の永続ハンドルを持つ SHA-256 プライマリーストレージキーを使用して 2048 ビット RSA を作成します。
tss2
パッケージの使用:# TPM_DEVICE=/dev/tpm0 tsscreateprimary -hi o -st Handle 80000000 # TPM_DEVICE=/dev/tpm0 tssevictcontrol -hi o -ho 80000000 -hp 81000001
tpm2-tools
パッケージの使用:# tpm2_createprimary --key-algorithm=rsa2048 --key-context=key.ctxt name-alg: value: sha256 raw: 0xb … sym-keybits: 128 rsa: xxxxxx… # tpm2_evictcontrol -c key.ctxt 0x81000001 persistentHandle: 0x81000001 action: persisted
keyctl add trusted <NAME> "new <KEY_LENGTH> keyhandle=<PERSISTENT-HANDLE> [options]" <KEYRING> の構文で TPM 2.0 を使用して、信頼できるキーを作成します。この例では、永続ハンドルは 81000001 です。
# keyctl add trusted kmk "new 32 keyhandle=0x81000001" @u 642500861
このコマンドは、
kmk
という名前の信頼できる鍵を32
バイト (256 ビット) の長さで作成し、ユーザーキーリング (@u
) に配置します。鍵の長さは 32 から 128 バイト (256 から 1024 ビット) です。カーネルキーリングの現在の構造を一覧表示します。
# keyctl show Session Keyring -3 --alswrv 500 500 keyring: ses 97833714 --alswrv 500 -1 \ keyring: uid.1000 642500861 --alswrv 500 500 \ trusted: kmk
ユーザー空間のブロブに鍵をエクスポートします。
# keyctl pipe 642500861 > kmk.blob
このコマンドは、
pipe
サブコマンドとkmk
のシリアル番号を使用します。ユーザー空間のブロブから信頼できる鍵を読み込み、ブロブを引数として
add
サブコマンドを使用します。# keyctl add trusted kmk "load `cat kmk.blob`" @u 268728824
keyctl add encrypted <NAME> "new [FORMAT] <KEY_TYPE>:<PRIMARY_KEY_NAME> <KEY_LENGTH>" <KEYRING> という構文に基づいて、TPM で保護された信頼されたキーに基づく安全な暗号化キーを作成します。
# keyctl add encrypted encr-key "new trusted:kmk 32" @u 159771175
このコマンドは、前の手順で生成した TPM で保護された信頼できる鍵 (
kmk
) を、暗号化鍵を生成する プライマリーキー として使用します。
関連情報
-
keyctl(1)
の man ページ - 信頼できる鍵および暗号化された鍵
- Kernel Key Retention Service
- カーネル整合性サブシステム
30.6. 暗号化鍵での作業
Trusted Platform Module (TPM) が利用できないシステムでは、暗号化された鍵を管理してシステムのセキュリティーを向上させることができます。
前提条件
-
64 ビット ARM アーキテクチャーおよび IBM Z の場合は、
encrypted-keys
カーネルモジュールを読み込む必要があります。カーネルモジュールを読み込む方法は、Managing kernel modules を参照してください。
手順
無作為な数列を使用してユーザーキーを生成します。
# keyctl add user kmk-user "$(dd if=/dev/urandom bs=1 count=32 2>/dev/null)" @u 427069434
このコマンドは、
kmk-user
という名前のユーザーキーを生成し、プライマリーキー として動作させ、このユーザーキーを使用して実際の暗号化鍵を保護します。前の手順で取得したプライマリーキーを使用して、暗号化鍵を生成します。
# keyctl add encrypted encr-key "new user:kmk-user 32" @u 1012412758
必要に応じて、指定したユーザーキーリングにあるすべての鍵を一覧表示します。
# keyctl list @u 2 keys in keyring: 427069434: --alswrv 1000 1000 user: kmk-user 1012412758: --alswrv 1000 1000 encrypted: encr-key
暗号化鍵が信頼できるプライマリーキーで保護されていない場合には、ユーザーのプライマリーキー (乱数キー) を使用して暗号化した場合のセキュリティーと同程度でしかない点に注意してください。そのため、プライマリーユーザーキーはできるだけ安全に、システムの起動プロセスの早い段階で読み込む必要があります。
関連情報
-
keyctl(1)
の man ページ - Kernel Key Retention Service
30.7. Integrity Measurement Architecture および Extended Verification Module の有効化
整合性測定アーキテクチャー (IMA) および拡張検証モジュール (EVM) は、カーネル整合性サブシステムに属し、さまざまな方法でシステムセキュリティーを強化します。オペレーティングシステムのセキュリティーを向上させるために、IMA と EVM を有効にして設定できます。
前提条件
Secure Boot 機能を一時的に無効にしている。
注記Secure Boot 機能を有効にすると、
ima_appraise=fix
は機能しません。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)
手順
以下のカーネルコマンドラインパラメーターを追加します。
# 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) 測定ポリシーと評価手順を使用するようになります。評価部分は、以前の測定と現在の測定が一致しないファイルへのアクセスを禁止します。- 再起動して変更を適用します。
必要に応じて、パラメーターがカーネルコマンドラインに追加されていることを確認します。
# 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
カーネルマスターキーを作成して、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 行目にあります。kmk
鍵をもとに暗号化された EVM 鍵を作成します。# keyctl add encrypted evm-key "new user:kmk 64" @u 641780271
kmk
を使用して 64 バイトの long 型ユーザーキー (evm-key
) を生成してユーザー (@u
) のキーリングに配置します。鍵のシリアル番号は、前の出力の 2 行目にあります。重要ユーザーキーの名前は evm-key (EVM サブシステムが想定して使用している名前) にする必要があります。
エクスポートする鍵のディレクトリーを作成します。
# mkdir -p /etc/keys/
kmk
鍵を検索し、その値をファイルにエクスポートします。# keyctl pipe $(keyctl search @u user kmk) > /etc/keys/kmk
このコマンドは、カーネルマスターキー (
kmk
) の非暗号化値を、以前に定義した場所 (/etc/keys/
) にあるファイルに配置します。ユーザーキー
evm-key
を検索し、その値をファイルにエクスポートします。# keyctl pipe $(keyctl search @u encrypted evm-key) > /etc/keys/evm-key
このコマンドは、ユーザーの
evm-key
鍵の暗号化値を、任意の場所にあるファイルに追加します。evm-key
は、すでにカーネルのマスターキーにより暗号化されています。必要に応じて、新規作成されたキーを表示します。
# 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 # ls -l /etc/keys/ total 8 -rw-r--r--. 1 root root 246 Jun 24 12:44 evm-key -rw-r--r--. 1 root root 32 Jun 24 12:43 kmk
同様の出力が表示されるはずです。
EVM をアクティベートします。
# echo 1 > /sys/kernel/security/evm
システム全体の再ラベル付け
# find / -fstype xfs -type f -uid 0 -exec head -n 1 '{}' >/dev/null \;
重要この手順を省略すると、IMA および EVM を有効にした後に、システム上のほとんどのファイルにアクセスできなくなる場合があります。
検証手順
次のように入力して、EVM が初期化されたことを確認できます。
# dmesg | tail -1 […] evm: key initialized
システムが再起動されると、キーはキーリングから削除されます。このような場合、すでにエクスポートされている kmk
および evm-key
キーをインポートできます。
手順
ユーザー
kmk
キーを追加します (ステップ 7 で/etc/keys/kmk
ファイルに既にエクスポートされています)。# keyctl add user kmk "$(cat /etc/keys/kmk)" @u 451342217 # keyctl show Session Keyring 695566911 --alswrv 0 0 keyring: ses 58982213 --alswrv 0 65534 \ keyring: uid.0 451342217 --alswrv 0 0 \ user: kmk
ユーザーの
evm-key
キーをインポートします (手順 8 で既に/etc/keys/evm-key
ファイルにエクスポートされています)。# keyctl add encrypted evm-key "load $(cat /etc/keys/evm-key)" @u 924537557 # keyctl show Session Keyring 695566911 --alswrv 0 0 keyring: ses 58982213 --alswrv 0 65534 \ keyring: uid.0 451342217 --alswrv 0 0 \ user: kmk 924537557 --alswrv 0 0 \_ encrypted: evm-key
30.8. Integrity Measurement Architecture によるファイルのハッシュの収集
Integrity Measurement Architecture (IMA) の最初の操作段階は、Measurement フェーズです。ここでは、ファイルのハッシュを作成し、それらをファイルの拡張属性 (xattrs) として保存することができます。ファイルハッシュを作成して検査できます。
前提条件
- Integrity Measurement Architecture (IMA) と Extended Verification Module (EVM) を Enabling integrity measurement architecture and extended verification module で説明されているように有効化する。
ima-evm-utils
、attr
、およびkeyutils
パッケージがすでにインストールされていることを確認する。# dnf 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!
手順
テストファイルを作成します。
# echo <Test_text> > test_file
IMA と EVM は、
test_file
サンプルファイルにハッシュ値が割り当てられ、その拡張属性として格納されていることを確認します。ファイルの拡張属性を検証します。
# 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.evm
でevmctl
ユーティリティーを使用して、RSA ベースのデジタル署名またはハッシュベースのメッセージ認証コード (HMAC-SHA1) を生成できます。前の操作を正常に実行するには、カーネルキーリングに保存されている有効な信頼できるキーまたは暗号化されたキーが必要です。この設定により、拡張属性に対するオフラインの改ざん攻撃が防止されます。
第31章 Ansible ロールを使用したカーネルパラメーターの永続的な設定
Red Hat Ansible の詳しい知識がある経験のあるユーザーは、kernel_settings
ロールを使用して、複数のクライアントにカーネルパラメーターを一度に設定することができます。この解決策は以下のとおりです。
- 効率的な入力設定を持つ使いやすいインターフェイスを提供します。
- すべてのカーネルパラメーターを 1 か所で保持します。
コントロールマシンから kernel_settings
ロールを実行すると、カーネルパラメーターはすぐに管理システムに適用され、再起動後も維持されます。
RHEL チャネルで提供される RHEL システムロールは、デフォルトの App Stream リポジトリーの RPM パッケージとして RHEL のお客様が利用できることに注意してください。RHEL システムロールは、Ansible Automation Hub を介して Ansible サブスクリプションを使用しているお客様のコレクションとしても利用できます。
31.1. カーネル設定ロールの概要
RHEL システムロールは、複数のシステムをリモートで管理する、一貫した設定インターフェイスを提供する一連のロールです。
kernel_settings
システムロールを使用して、カーネルの自動設定に RHEL システムロールが導入されました。rhel-system-roles
パッケージには、このシステムロールと参考ドキュメントも含まれます。
カーネルパラメーターを自動的に 1 つ以上のシステムに適用するには、Playbook で選択したロール変数を 1 つ以上使用して、kernel_settings
ロールを使用します。Playbook は人間が判読でき、YAML 形式で記述される 1 つ以上のプレイの一覧です。
インベントリーファイルを使用して、Ansible が 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
関連情報
-
/usr/share/doc/rhel-system-roles/kernel_settings/
ディレクトリーのREADME.md
ファイルおよびREADME.html
ファイル - Playbook の使用
- インベントリーの構築方法
31.2. kernel_settings
ロールを使用した選択したカーネルパラメーターの適用
以下の手順に従って、Ansible Playbook を準備および適用し、複数の管理システムで永続化の影響でカーネルパラメーターをリモートに設定します。
前提条件
-
root
権限がある。 -
RHEL サブスクリプションの資格を取得して、
ansible-core
およびrhel-system-roles
パッケージをコントロールマシンにインストールしている。 - 管理対象ホストのインベントリーが制御マシンに存在し、Ansible から接続できる。
RHEL 8.0-8.5 では、別の Ansible リポジトリーへのアクセス権を指定されており、Ansible をベースにする自動化用の Ansible Engine 2.9 が含まれています。Ansible Engine には、 ansible
、ansible-playbook
などのコマンドラインユーティリティー、docker
や podman
などのコネクター、プラグインとモジュールすべてが含まれています。Ansible Engine を入手してインストールする方法については、Red Hat Ansible Engine をダウンロードしてインストールする方法 を参照してください。
RHEL 8.6 および 9.0 では、Ansible Core (ansible-core
RPM として提供) が導入されました。これには、Ansible コマンドラインユーティリティー、コマンド、および組み込みの Ansible プラグインセットが少し含まれています。App Stream リポジトリーには、ansible-core
が含まれていますが、サポートの範囲が限定されています。詳細は、RHEL 9App Stream に含まれている ansible-core パッケージのサポート範囲 を確認してください。
手順
必要に応じて、図の目的で
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 をより効果的に実行できます。設定ファイルを作成して、Ansible 操作のデフォルトと特権昇格を設定します。
新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。
# vi /home/jdoe/<ansible_project_name>/ansible.cfg
以下の内容をファイルに挿入します。
[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
に自動的に切り替わります。
kernel_settings
ロールを使用する Ansible Playbook を作成します。新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。
# vi /home/jdoe/<ansible_project_name>/kernel-roles.yml
このファイルは Playbook を表し、通常は、
inventory
ファイルから選択した特定の管理対象ホストに対して実行される、プレイ とも呼ばれるタスクの順序付きリストが含まれます。以下の内容をファイルに挿入します。
--- - hosts: testingservers name: "Configure kernel settings" roles: - rhel-system-roles.kernel_settings 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
name
キーは任意です。任意の文字列をラベルとしてプレイに関連付け、プレイの対象を特定します。プレイのhosts
キーは、プレイを実行するホストを指定します。このキーの値または値は、管理対象ホストの個別名またはinventory
ファイルで定義されているホストのグループとして指定できます。vars
セクションは、設定する必要がある、選択したカーネルパラメーター名および値が含まれる変数の一覧を表します。roles
キーは、vars
セクションで説明されているパラメーターおよび値を設定するシステムロールを指定します。注記必要に応じて、Playbook のカーネルパラメーターとその値を変更することができます。
必要に応じて、プレイ内の構文が正しいことを確認します。
# ansible-playbook --syntax-check kernel-roles.yml playbook: kernel-roles.yml
以下の例では、Playbook の検証が成功したことを示しています。
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 が Playbook を実行する前に、パスワードの入力を求められます。これにより、管理対象ホストのユーザーが
root
に切り替わります。これは、カーネルパラメーターの設定に必要です。recap セクションは、すべての管理対象ホストのプレイが正常に終了したこと (
failed=0
)、および 4 つのカーネルパラメーターが適用されたこと (changed=4
) を示しています。- 管理対象ホストを再起動して、影響を受けるカーネルパラメーターをチェックし、変更が適用され、再起動後も維持されていることを確認します。
関連情報
- RHEL System Roles を使用するための制御ノードと管理対象ノードの準備
-
/usr/share/doc/rhel-system-roles/kernel_settings/
ディレクトリーのREADME.html
ファイルおよびREADME.md
ファイル - インベントリーの構築
- Ansible の設定
- Playbook の使用
- 変数の使用
- ロール
第32章 高度なエラー報告の使用
Advanced Error Reporting
(AER
) を使用すると、Peripheral Component Interconnect Express
(PCIe
) デバイスのエラーイベントの通知を受け取ります。RHEL はデフォルトでこのカーネル機能を有効にし、報告されたエラーをカーネルログに収集します。さらに、rasdaemon
プログラムを使用すると、これらのエラーが解析され、データベースに保存されます。
32.1. AER の概要
Advanced Error Reporting
(AER
) は、Peripheral Component Interconnect Express
(PCIe
) デバイスの拡張エラーレポートを提供するカーネル機能です。AER
カーネルドライバーは、次の目的で PCIe
AER
機能をサポートするルートポートを接続します。
- 包括的なエラー情報を収集する
- エラーをユーザーに報告する
- エラー回復アクションを実行する
AER
がエラーをキャプチャすると、error メッセージがコンソールに送信されます。修復可能なエラーの場合、コンソール出力は 警告 です。
例32.1 AER 出力の例
Feb 5 15:41:33 hostname kernel: pcieport 10003:00:00.0: AER: Corrected error received: id=ae00 Feb 5 15:41:33 hostname kernel: pcieport 10003:00:00.0: AER: Multiple Corrected error received: id=ae00 Feb 5 15:41:33 hostname kernel: pcieport 10003:00:00.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0000(Receiver ID) Feb 5 15:41:33 hostname kernel: pcieport 10003:00:00.0: device [8086:2030] error status/mask=000000c0/00002000 Feb 5 15:41:33 hostname kernel: pcieport 10003:00:00.0: [ 6] Bad TLP Feb 5 15:41:33 hostname kernel: pcieport 10003:00:00.0: [ 7] Bad DLLP Feb 5 15:41:33 hostname kernel: pcieport 10003:00:00.0: AER: Multiple Corrected error received: id=ae00 Feb 5 15:41:33 hostname kernel: pcieport 10003:00:00.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0000(Receiver ID) Feb 5 15:41:33 hostname kernel: pcieport 10003:00:00.0: device [8086:2030] error status/mask=00000040/00002000
32.2. AER メッセージの収集および表示
AER メッセージを収集して表示するには、rasdaemon
プログラムを使用します。
手順
rasdaemon
パッケージをインストールします。# yum install rasdaemon
rasdaemon
サービスを有効にして開始します。# systemctl enable --now rasdaemon Created symlink /etc/systemd/system/multi-user.target.wants/rasdaemon.service → /usr/lib/systemd/system/rasdaemon.service.
ras-mc-ctl
コマンドを発行します。# ras-mc-ctl --summary # ras-mc-ctl --errors
このコマンドは、ログに記録されたエラーの概要を表示するか (
--summary
オプション)、エラーデータベースに保存されているエラーを表示します (--errors
オプション)。
関連情報
-
rasdaemon(8)
man ページ -
ras-mc-ctl(8)
man ページ