Red Hat Enterprise Linux 8 カーネルの管理、監視、 …...kernel-core - コア機能に必要な最小数のカーネルモジュールが含まれます。このサブパッケー

Red Hat Enterprise Linux 8

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

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

Last Updated: 2020-08-18

Red Hat Enterprise Linux 8 カーネルの管理、監視、および更新

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

法律上の通知法律上の通知

Copyright © 2020 Red Hat, Inc.

The text of and illustrations in this document are licensed by Red Hat under a Creative CommonsAttribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA isavailable athttp://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you mustprovide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift,Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United Statesand other countries.

Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.

Java ® is a registered trademark of Oracle and/or its affiliates.

XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United Statesand/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union andother countries.

Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by theofficial Joyent Node.js open source or commercial project.

The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marksor trademarks/service marks of the OpenStack Foundation, in the United States and othercountries and are used with the OpenStack Foundation's permission. We are not affiliated with,endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

概要概要

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

目次目次

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

第第1章章 LINUX カーネルカーネル RPM1.1. RPM とは1.2. LINUX カーネル RPM パッケージの概要1.3. カーネルパッケージの内容の表示

第第2章章 YUM を使用したカーネルの更新を使用したカーネルの更新2.1. カーネルの概要2.2. YUM とは2.3. カーネルの更新2.4. カーネルのインストール

第第3章章カーネルモジュールの管理カーネルモジュールの管理3.1. モジュールの紹介3.2. ブートローダー仕様の概要3.3. カーネルモジュールの依存関係3.4. 現在読み込み済みカーネルモジュールの一覧表示3.5. インストール済みカーネルの一覧表示3.6. カーネルをデフォルトとして設定3.7. モジュール情報の表示3.8. システムランタイム時のカーネルモジュールの読み込み3.9. システムランタイム時のカーネルモジュールのアンロード3.10. システムの起動時に自動的にカーネルモジュールを読み込む3.11. システムの起動時にカーネルモジュールが自動的にロードされないようにする3.12. セキュアブート用のカーネルモジュールの署名

第第4章章カーネルコマンドラインパラメーターの設定カーネルコマンドラインパラメーターの設定4.1. カーネルコマンドラインパラメーターの概要4.2. GRUBBY とは4.3. ブートエントリーとは4.4. カーネルコマンドラインパラメーターの設定

第第5章章ランタイム時のカーネルパラメーターの設定ランタイム時のカーネルパラメーターの設定5.1. カーネルパラメーターとは5.2. ランタイム時のカーネルパラメーターの設定5.3. 仮想化環境でカーネルパニックのパラメーターを無効のままにする5.4. データベースサーバーのカーネルパラメーターの調整

第第6章章カーネルロギングの使用カーネルロギングの使用6.1. カーネルリングバッファーとは6.2. ログレベルおよびカーネルロギングにおける PRINTK の役割

第第7章章 KDUMP のインストールと設定のインストールと設定7.1. KDUMP とは7.2. KDUMP のインストール7.3. コマンドラインで KDUMP の設定7.4. WEB コンソールで KDUMP の設定7.5. サポートしている KDUMP の設定とダンプ出力先7.6. KDUMP 設定のテスト7.7. KEXEC を使用したカーネルの再起動7.8. KDUMP 用のカーネルドライバーのブラックリスト登録7.9. 暗号化されたディスクがあるシステムで KDUMP の実行

4

5556

88889

1010101111

1212131415161719

2828282929

3232333638

414141

43434344505257585960

目次目次

1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.10. コアダンプの分析7.11. EARLY KDUMP を使用した起動時間クラッシュの取得7.12. 関連情報

第第8章章カーネルライブパッチでパッチの適用カーネルライブパッチでパッチの適用8.1. KPATCH の制限8.2. サードパーティーのライブパッチサポート8.3. カーネルライブパッチへのアクセス8.4. カーネルライブパッチのコンポーネント8.5. カーネルライブパッチの仕組み8.6. カーネルライブパッチの有効化8.7. カーネルパッチモジュールの更新8.8. カーネルライブパッチの無効化

第第9章章アプリケーションの制限の設定アプリケーションの制限の設定9.1. コントロールグループについて9.2. LINUX カーネルリソースコントローラーとは9.3. 仮想ファイルシステムによるコントロールグループの使用9.4. コントロールグループバージョン 1 における SYSTEMD の役割9.5. SYSTEMD でコントロールグループバージョン 1 の使用9.6. コントロールグループバージョン 1 に関する情報の取得9.7. 名前空間とは

第第10章章 BPF コンパイラーコレクションでシステムパフォーマンスの分析コンパイラーコレクションでシステムパフォーマンスの分析10.1. BCC の概要10.2. BCC-TOOLS パッケージのインストール10.3. BCC-TOOLS でパフォーマンスの分析

第第11章章カーネル整合性サブシステムによるセキュリティーの強化カーネル整合性サブシステムによるセキュリティーの強化11.1. カーネル整合性サブシステム11.2. 完全性測定アーキテクチャー11.3. 拡張検証モジュール11.4. 信頼できる鍵および暗号化された鍵11.5. 整合性測定アーキテクチャーおよび拡張検証モジュールの有効化11.6. 整合性測定アーキテクチャーでファイルハッシュの収集11.7. 関連情報

616668

696969707070717373

78787980889095

100

101101101102

106106107107107110113114

Red Hat Enterprise Linux 8 カーネルの管理、監視、および更新カーネルの管理、監視、および更新

2

目次目次

3

RED HAT ドキュメントへのフィードバック (英語のみ)ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。

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

1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端にFeedback ボタンがあることを確認してください。

2. マウスカーソルで、コメントを追加する部分を強調表示します。

3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。

4. 表示される手順に従ってください。

より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

1. Bugzilla の Web サイトにアクセスします。

2. Component で Documentation を選択します。

3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。

4. Submit Bug をクリックします。


4

https://bugzilla.redhat.com/enter_bug.cgi?product=Red Hat Enterprise Linux 8

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

1.1. RPM とは

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

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

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

ファイル

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

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

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

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

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

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

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

kernel-modules - その他のカーネルモジュールが含まれます。

kernel-modules-extra - まれなハードウェアのカーネルモジュールが含まれます。

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

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

kernel-debug - カーネル診断用に有効なデバッグオプションが多数含まれるカーネルが含まれます。ただし、パフォーマンスが犠牲になります。

kernel-tools - Linux カーネルを操作するツールやサポートドキュメントが含まれます。

kernel-devel - kernel パッケージに対してモジュールを構築するのに十分なカーネルヘッダー

第第1章章 LINUX カーネルカーネル RPM

5

kernel-devel - kernel パッケージに対してモジュールを構築するのに十分なカーネルヘッダーと makefiles が含まれます。

kernel-abi-whitelists - Red Hat Enterprise Linux カーネル ABI に関連する情報が含まれています。これには、強化を支援するための外部 Linux カーネルモジュールおよび yum プラグインで必要なカーネルシンボルの一覧が含まれます。

kernel-headers - Linux カーネルとユーザー空間ライブラリーおよびプログラム間のインターフェースを指定する C ヘッダーファイルが含まれます。ヘッダーファイルは、ほとんどの標準プログラムを構築するのに必要な構造と定数を定義します。

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

次の手順では、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…


6

kernel-modules-extra のモジュールを一覧表示します。

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

関連情報関連情報

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

RPM パッケージパッケージの概要

第第1章章 LINUX カーネルカーネル RPM

7

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/packaging_and_distributing_software/index#rpm-packages_packaging-software

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

2.1. カーネルの概要

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

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

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

警告警告

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

2.2. YUM とは

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


yum の詳細は、「基本的なシステム設定の構成」「基本的なシステム設定の構成」の関連のセクションを参照してください。

2.3. カーネルの更新

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

手順手順

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

# yum update kernel

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

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

注記注記


8

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#introduction-to-yum-functionality

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#installing-software-with-yum

注記注記

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

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

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

手順手順

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

# yum install kernel-{version}


利用可能なカーネルの一覧は、「「Red Hat Code Browser」」を参照してください。

特定のカーネルバージョンのリリース日の一覧は、この記事この記事を参照してください。

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

9

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/upgrading_from_rhel_7_to_rhel_8/index

https://access.redhat.com/labs/rhcb/

https://access.redhat.com/articles/3078

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

3.1. モジュールの紹介

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

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

新しいハードウェアへのサポートを強化するデバイスドライバー

GFS2 や NFSなどのファイルシステムのサポート

システムコール

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

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

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

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

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

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

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

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


grubby ユーティリティーの詳細は、「grubby とは」を参照してください。

ブートエントリーの詳細は、「ブートエントリーの概要」を参照してください。


10

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

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

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

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

警告警告

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


/lib/modules/<KERNEL_VERSION>/modules.dep の詳細は、modules.dep(5) の man ページを参照してください。

depmod の概要やオプションの詳細は、man ページの depmod(8) を参照してください。

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

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


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

手順手順

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

$ lsmod

Module Size Used byfuse 126976 3uinput 20480 1xt_CHECKSUM 16384 1ipt_MASQUERADE 16384 1xt_conntrack 16384 1ipt_REJECT 16384 1nft_counter 16384 16nf_nat_tftp 16384 0nf_conntrack_tftp 16384 1 nf_nat_tftp

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

11

tun 49152 1bridge 192512 0stp 16384 1 bridgellc 16384 2 bridge,stpnf_tables_set 32768 5nft_fib_inet 16384 1…

上記の例:

最初の列は、現在読み込まれているモジュールの名前名前を示します。

次のコラムは、モジュールごとのメモリーメモリー容量をキロバイト単位で表示します。

最後のコラムは、数字と、オプションで特定のモジュールに依存依存するモジュール名を表示します。


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

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

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

手順手順

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

# grubby --info=ALL | grep title

以下の出力は、カーネルの起動エントリーを表示します。kernel フィールドは、カーネルパスを表示します。

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)

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

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

手順手順

grubby ツールを使用して、カーネルをデフォルトとして設定ツールを使用して、カーネルをデフォルトとして設定

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


12

# grubby --set-default $kernel_path

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

注記注記

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

id 引数を使用したカーネルのデフォルト設定引数を使用したカーネルのデフォルト設定

id 引数を使用してブートエントリーの一覧を表示し、希望するカーネルをデフォルトとして設定します。

# grubby --info ALL | grep id# grubby --set-default /boot/vmlinuz-<version>.<architecture>

注記注記

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

次回の起動時のみのデフォルトカーネルの設定次回の起動時のみのデフォルトカーネルの設定

次のコマンドを実行して、grub2-reboot コマンドを使用して、次回の再起動にのみデフォルトのカーネルを設定します。

# grub2-reboot <index|title|id>

警告警告

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

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

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



手順手順


13

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

$ modinfo <KERNEL_MODULE_NAME>

For example:$ modinfo virtio_net

filename: /lib/modules/4.18.0-94.el8.x86_64/kernel/drivers/net/virtio_net.ko.xzlicense: GPLdescription: Virtio network driverrhelversion: 8.1srcversion: 2E9345B281A898A91319773alias: virtio:d00000001v*depends: net_failoverintree: Yname: virtio_netvermagic: 4.18.0-94.el8.x86_64 SMP mod_unload modversions… parm: napi_weight:intparm: csum:boolparm: gso:boolparm: napi_tx:bool

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

注記注記

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


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

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

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


root 権限


関連のカーネルモジュールが読み込まれていない。これを確認するには、ロードしているカーネルモジュールを一覧表示します。

手順手順


14

1. 読み込むカーネルモジュールを選択します。モジュールは /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ ディレクトリーにあります。

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

# modprobe <MODULE_NAME>

注記注記


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

$ lsmod | grep <MODULE_NAME>

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

$ lsmod | grep serio_rawserio_raw 16384 0

重要重要

この手順で説明されている変更は、システムを再起動は維持されません維持されません。


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

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

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


root 権限


手順手順

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

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


15

# modprobe -r <MODULE_NAME>


警告警告

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

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


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

重要重要

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


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

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

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


root 権限


手順手順

1. 起動プロセス中に読み込むカーネルモジュールを選択します。モジュールは /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ ディレクトリーにあります。

2. モジュールの設定ファイルを作成します。

# echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf

注記注記


16

注記注記


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


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

重要重要

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


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

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

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


root 権限


ブラックリストに指定したカーネルモジュールが現在のシステム設定に重要でないことを確認します。

手順手順

1. ブラックリストに登録するカーネルモジュールを選択します。

$ lsmod

Module Size Used byfuse 126976 3xt_CHECKSUM 16384 1ipt_MASQUERADE 16384 1uinput 20480 1xt_conntrack 16384 1…

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

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


17

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

2. ブラックリスト設定ファイルを作成します。

# vim /etc/modprobe.d/blacklist.conf

# Blacklists <KERNEL_MODULE_1> blacklist <MODULE_NAME_1> install <MODULE_NAME_1> /bin/false

# Blacklists <KERNEL_MODULE_2> blacklist <MODULE_NAME_2> install <MODULE_NAME_2> /bin/false

# Blacklists <KERNEL_MODULE_n> blacklist <MODULE_NAME_n> install <MODULE_NAME_n> /bin/false …

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

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

注記注記


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

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

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

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

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

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

# dracut -f -v


18

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

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

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

$ reboot

重要重要

この手順で説明している変更は、システムを再起動しても持続されます持続されます。主要なカーネルモジュールを正しくブラックリストに指定しないと、システムが不安定になったり、システムが動作しなくなったりすることがあります。


dracut ユーティリティの詳細は dracut(8) man ページを参照してください。

3.12. セキュアブート用のカーネルモジュールの署名

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

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

1. カーネルモジュールを認証する

2. 公開鍵と秘密鍵を生成する

3. ターゲットシステムに公開鍵をする

4. 秘密鍵でカーネルモジュールに署名する

5. 署名付きカーネルモジュールを読み込み

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

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

署名付きブートローダー

署名付きカーネル

署名付きカーネルモジュール

さらに、署名された第 1 段階のブートローダーと署名されたカーネルには、組み込みのRed Hat公開鍵が含まれます。この署名済みの実行可能なバイナリーおよび組み込み鍵により、RHEL 8 は UEFI セ


19

キュアブートに対応するシステムで、UEFI ファームウェアが提供する Microsoft UEFI セキュアブート認証局の鍵を使用してインストール、起動、および実行できます。すべての UEFI ベースのシステムにセキュアブートのサポートが含まれているわけではないことに注意してください。


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

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

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

openssl openssl ビルドシステム公開および秘密の X.509鍵のペアを生成します。

sign-file kernel-devel ビルドシステム秘密鍵でカーネルモジュールに署名するために使用する実行ファイル

mokutil mokutil ターゲットシステム公開鍵を手動で登録する際に使用する任意のユーティリティー

keyctl keyutils ターゲットシステムシステムキーリングに公開鍵を表示する際に使用するオプションのユーティリティー

注記注記

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

3.12.1. X.509 鍵でカーネルモジュールの認証

RHEL 8 では、カーネルモジュールが読み込まれると、カーネルのシステムキーリング上の公開 X.509鍵を使用してモジュールの署名を確認します。ただし、カーネルのシステムのブラックリストキーリングにある鍵は除外されます。以下のセクションでは、キー/キーリングのソースの概要、システム内のさまざまなソースから読み込んだキ鍵の例を説明します。また、ユーザーは、カーネルモジュールの認証に何が必要かを確認できます。

3.12.1.1. 認証要件認証要件

本セクションでは、UEFI セキュアブート機能が有効なシステムでカーネルモジュールを読み込むために必要な条件を説明します。

UEFI セキュアブートが有効な場合、または module.sig_enforce カーネルパラメーターが指定されている場合は、システムのキーリングの鍵を使用して認証された署名済みカーネルモジュールのみを読み込むことができます。また、公開鍵は、システムのブラックリストキーリングに置くことができません。

UEFI セキュアブートが無効で module.sig_enforce カーネルパラメーターが指定されていない場合


20

UEFI セキュアブートが無効で module.sig_enforce カーネルパラメーターが指定されていない場合は、公開鍵を使用せずに、未署名のカーネルモジュールおよび署名済みカーネルモジュールを読み込むことができます。これは、以下の表で説明されています。

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

署名されたモ署名されたモジュールジュール

公開鍵があり公開鍵があり署名が有効署名が有効

UEFI セキュアセキュアブートの状態ブートの状態

sig_enforce モジュールのモジュールの読み込み読み込み

カーネルの汚カーネルの汚染染

署名なし - 無効無効成功はい

無効有効失敗 -

有効 - 失敗 -

署名ありいいえ無効無効成功はい

無効有効失敗 -

有効 - 失敗 -

署名ありはい無効無効成功いいえ

無効有効成功いいえ

有効 - 成功いいえ

3.12.1.2. 公開鍵のソース公開鍵のソース

カーネルは、システムの起動時に、次の表に示すように、システムキーリング、または一連の永続的なキーストアのシステムブラックリストキーリングに X.509 キーを読み込みます。

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

X.509 鍵のソース鍵のソース鍵の追加に関するユー鍵の追加に関するユーザー機能ザー機能

UEFI セキュアブートのセキュアブートの状態状態

ブート中に読み込まれるブート中に読み込まれる鍵鍵

カーネルへの埋め込みいいえ - .system_keyring

UEFI セキュアブート「db」

限定的無効いいえ

有効 .system_keyring

UEFI セキュアブート「dbx」

限定的無効いいえ


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

いいえ無効いいえ


21


MOK (Machine OwnerKey) 一覧

はい無効いいえ


X.509 鍵のソース鍵のソース鍵の追加に関するユー鍵の追加に関するユーザー機能ザー機能

UEFI セキュアブートのセキュアブートの状態状態

ブート中に読み込まれるブート中に読み込まれる鍵鍵

システムが UEFI ベースでない場合、または UEFI セキュアブートが有効になっていない場合は、カーネルに組み込まれた鍵のみがシステムのキーリングに読み込まれます。この場合、カーネルを再構築せずにその鍵セットを拡張する機能はありません。

システムのブラックリストキーリングは、無効にされた X.509 鍵の一覧です。ブラックリストの鍵でモジュールが署名されていると、公開鍵がシステムのキーリングにあったとしても、モジュールは認証に失敗します。

keyctl ユーティリティーを使用して、システムのキーリングの鍵に関する情報を表示できます。以下は、UEFI セキュアブートが有効でない RHEL 8 システムからの短い出力例です。

# keyctl list %:.system_keyring3 keys in keyring:...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87......asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b......asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...

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

# keyctl list %:.system_keyring6 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...

上記の出力では、UEFI セキュアブートの「db」鍵と Red Hat Secure Boot (CA key 1) (shim.efi ブートローダーに組み込まれています) の 2 つが追加されました。UEFI セキュアブート関連のソースを使用して鍵を識別するカーネルコンソールメッセージを検索することもできます。これには、UEFI セキュアブート db、組み込み shim、および MOK の一覧が含まれます。

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

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

セキュアブートが有効なシステムでカーネルモジュールを使用する作業を正常に行うには、公開鍵および秘密鍵の X.509 ペアを生成する必要があります。後で秘密鍵を使用してカーネルモジュールに署名し


22

ます。セキュアブートで署名済みモジュールを検証するには、対応する公開鍵を MOK (Machine OwnerKey) に追加する必要があります。

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

手順手順

1. キーペア生成のパラメーターで設定ファイルを作成します。

# cat << EOF > configuration_file.config[ req ]default_bits = 4096distinguished_name = req_distinguished_nameprompt = nostring_mask = utf8onlyx509_extensions = myexts

[ req_distinguished_name ]O = OrganizationCN = Organization signing keyemailAddress = E-mail address

[ myexts ]basicConstraints=critical,CA:FALSEkeyUsage=digitalSignaturesubjectKeyIdentifier=hashauthorityKeyIdentifier=keyidEOF

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

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

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

RHEL 8 では、鍵のペアの有効性の日付。キーの有効期限はありませんが、カーネルモジュールはその署名キーの有効期間内に署名する必要があります。たとえば、2019 でのみ有効な鍵は、2019 で署名されたカーネルモジュールをその鍵で認証するために使用できます。ただし、ユーザーはこの鍵を使用して 2020 でカーネルモジュールに署名することはできません。

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

# openssl x509 -inform der -text -noout -in <my_signing_key_pub.der>

Validity Not Before: Feb 14 16:34:37 2019 GMT Not After : Feb 11 16:34:37 2029 GMT

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


23

警告警告

強力なセキュリティー対策とアクセスポリシーを適用して、秘密鍵の内容を保護します。この鍵を誤って使用すると、対応する公開鍵で認証されたシステムを危険にさらす場合があります。


公開鍵をターゲットシステムに登録する方法は、「MOK の一覧に公開鍵を手動で追加」を参照してください。

3.12.2. ターゲットシステムで公開鍵の登録

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

3.12.2.1. 公開鍵を含むファクトリーファームウェアイメージ公開鍵を含むファクトリーファームウェアイメージ

システムでカーネルモジュールの認証を容易にするには、ファクトリーファームウェアイメージで公開鍵を UEFI セキュアブート鍵データベースに組み入れるようにシステムベンダーに要求することを考慮してください。

3.12.2.2. MOK の一覧に公開鍵を手動で追加の一覧に公開鍵を手動で追加

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

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

手順手順

1. 公開鍵の MOK の一覧への追加を要求します。

# mokutil --import my_signing_key_pub.der

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

2. マシンを再起動します。保留中の MOK 鍵登録要求は shim.efi により検出され、MokManager.efi を起動して UEFI コンソールからの登録が完了できるようになります。


24

3. このリクエストに関連付けたパスワードを入力し、登録を確認します。公開鍵が MOK の一覧に追加されます。これは永続的です。

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

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

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


公開鍵と秘密鍵のペアを生成し、公開鍵の有効期限を確認している。詳細は「公開鍵と秘密鍵の生成」を参照してください。

ターゲットシステムに公開鍵を登録している。詳細は「ターゲットシステムで公開鍵の登録」を参照してください。

カーネルモジュールが署名できる。

手順手順

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

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

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

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

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

重要重要

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



25

カーネルモジュールの情報を取得するために modinfo を使用する方法は、「モジュール情報の表示」を参照してください。

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

公開鍵が登録されてシステムキーリングにある場合は、mokutil コマンドを使用して公開鍵を MOK の一覧に追加します。次に、秘密鍵を使用して適切なカーネルモジュールに署名します。最後に、以下のセクションで説明されているようにmodprobe コマンドを使用して、署名済みカーネルモジュールを手動で読み込みます。


公開鍵と秘密鍵のペアを生成している。詳細は「公開鍵と秘密鍵の生成」を参照してください。

公開鍵をシステムのキーリングに登録している。詳細は「MOK の一覧に公開鍵を手動で追加」を参照してください。

手順手順

1. 必要に応じて、公開鍵の登録前にカーネルモジュールを読み込まないことを確認します。現在読み込み済みのカーネルモジュールの一覧を表示する方法は、「現在読み込み済みカーネルモジュールの一覧表示」を参照してください。

2. 現在のブートで、システムキーリングに追加されたキーを確認します。

# keyctl list %:.system_keyring

公開鍵はまだ登録されていないため、このコマンドの出力には表示されません。

3. 公開鍵の登録を要求します。

# mokutil --import my_signing_key_pub.der

4. 再起動して、UEFI コンソールでの登録を完了します。

# reboot

5. システムキーリングの鍵を再度確認します。

# keyctl list %:.system_keyring

6. カーネルモジュールを、希望のカーネルの /extra/ ディレクトリーにコピーします。

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

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

# depmod -a

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


26

# modprobe -v my_module# lsmod | grep my_module

a. 必要に応じて、システムの起動時にモジュールを読み込むには、そのモジュールを /etc/modules-loaded.d/my_module.conf ファイルに追加します。

# echo "my_module" > /etc/modules-load.d/my_module.conf


カーネルモジュールの読み込みの詳細は、3章カーネルモジュールの管理の関連セクションを参照してください。


27

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

重要重要

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

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

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

Red Hat Enterprise Linux カーネル

初期 RAM ディスク

ユーザー領域機能

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

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

注記注記

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


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

kernelopts 変数の詳細は、ナレッジベースの記事「How to install and boot custom kernels inRed Hat Enterprise Linux 8」を参照してください。

4.2. GRUBBY とは

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

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

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


28


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_64linux /vmlinuz-4.18.0-74.el8.x86_64initrd /initramfs-4.18.0-74.el8.x86_64.img $tuned_initrdoptions $kernelopts $tuned_paramsid rhel-20190227183418-4.18.0-74.el8.x86_64grub_users $grub_usersgrub_arg --unrestrictedgrub_class kernel

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


kernelopts 変数の詳細は、ナレッジベースの記事「How to install and boot custom kernels in Red HatEnterprise Linux 8」を参照してください。

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

ブートプロセスの初期段階からシステムの動作を調整するには、特定のカーネルコマンドラインパラメーターを設定する必要があります。

本セクションでは、さまざまな CPU アーキテクチャーでカーネルコマンドラインパラメーターを変更する方法を説明します。

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

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


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

手順手順

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

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

29


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

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

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

IBM Z で、起動メニューを更新するオプションを指定せずに zipl コマンドを実行します。

パラメーターを削除するには、次のコマンドを実行します。

# grubby --update-kernel=ALL --remove-args="<PARAMETER_TO_REMOVE>"



カーネルコマンドラインパラメーターの詳細は、「カーネルコマンドラインパラメーターの概要」を参照してください。

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

grubby のその他の使用例は、「「grubby ツール」ツール」を参照してください。

zipl ユーティリティーの詳細は、man ページの zipl(8) を参照してください。

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

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


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

手順手順

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

# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="<NEW_PARAMETER>"


パラメーターを削除するには、以下のコマンドを使用します。

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


注記注記


30

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-working_with_the_grub_2_boot_loader#sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool

注記注記

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

grubby のその他の使用例は、「「grubby ツール」ツール」を参照してください。

zipl ユーティリティーの詳細は、man ページの zipl(8) を参照してください。

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

31

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-working_with_the_grub_2_boot_loader#sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool

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

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

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

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

+ * sysctl コマンド

+ * /proc/sys/ ディレクトリーにマウントされている仮想ファイルシステム

+ * /etc/sysctl.d/ ディレクトリー内の設定ファイル

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

表表5.1 sysctl クラスの表クラスの表

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

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

crypto 暗号化インターフェース

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

dev デバイス固有の情報

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

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

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

sunrpc Sun Remote Procedure Call (NFS)

user ユーザー名前空間の制限

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


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


32

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

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

重要重要

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

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

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


カーネルパラメーターの概要

root 権限

手順手順

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

# sysctl -a

注記注記

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

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

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

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

注記注記

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


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

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

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

33

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

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



root 権限

手順手順

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

# sysctl -a

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

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

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

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

注記注記

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


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

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

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

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



root 権限

手順手順

1. /etc/sysctl.d/ に新しい設定ファイルを作成します。


34

# vim /etc/sysctl.d/<some_file.conf>

2. 以下のように、1 行ごとにカーネルパラメーターを含めます。

<TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE><TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

3. 設定を保存します。


また、再起動せずに変更を適用するには、以下を実行します。

# sysctl -p /etc/sysctl.d/<some_file.conf>

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


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

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

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

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



root 権限

手順手順

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

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

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

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

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

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

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

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



35


カーネルパラメーターを永続的に変更するには、sysctl コマンドを使用するか、/etc/sysctl.d/ディレクトリーの設定ファイルに手動で変更を行います。

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

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

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

ソフトロックアップの原因

ソフトロックアップ時にシステムの動作を制御するカーネルパラメーターの説明

仮想化環境でソフトロックがどのように発生するかの説明

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

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


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

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

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

softlockup_panic

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

型型値値効果効果

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

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

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

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

nmi_watchdog

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


36

https://access.redhat.com/ja/articles/1263343

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

値値効果効果

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

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

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

watchdog_thresh

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

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

10 秒 2 * watchdog_thresh

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


nmi_watchdog および softlockup_panic の詳細は、「「Softlockup detector and hardlockupdetector」」を参照してください。

watchdog_thresh の詳細は、「「Kernel sysctl」」を参照してください。

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

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

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

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

重要重要

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


37

https://www.kernel.org/doc/Documentation/lockup-watchdogs.txt

https://www.kernel.org/doc/Documentation/sysctl/kernel.txt


ソフトロックアップの定義とその機能にまつわる技術は、「ソフトロックアップとは」を参照してください。

RHEL 8 仮想化環境のコンポーネントとその相互作用は、「「RHEL 8 仮想マシンコンポーネント仮想マシンコンポーネントおよびその相互作用」およびその相互作用」を参照してください。

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

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

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

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

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

MariaDB 10.3

MySQL 8.0

PostgreSQL 10

PostgreSQL 9.6

PostgreSQL 12 - RHEL 8.1.1 以降で利用できます。

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

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

fs.aio-max-nr

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

注記注記

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

fs.file-max

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


38

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/configuring_and_managing_virtualization/index#rhel-8-virtual-machine-components-and-their-interaction_virt-overview

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


39


ダーティーデータのライトバック、その機能、および関連するカーネルパラメーターの説明は、「ダーティページのライトバックはどのように機能しますか「ダーティページのライトバックはどのように機能しますか?」」を参照してください。


40

https://access.redhat.com/ja/articles/2389021

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

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

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

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


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

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

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

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

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

0 - カーネルの緊急事態。システムが利用できません。

1 - カーネルアラート。すぐに対処する必要があります。

2 - 重大な問題があると見なされるカーネルの状態。

3 - 一般的なカーネルのエラー状態。

4 - 一般的なカーネルの警告状態。

5 - 正常だが重大な状態のカーネル通知。

6 - カーネル情報メッセージ。

7 - カーネルのデバッグレベルメッセージ。

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

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

41

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

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

1. 値。コンソールログレベル。コンソールに出力されるメッセージの最低優先度を定義します。

2. 値。明示的なログレベルが付いていないメッセージのデフォルトのログレベル。

3. 値。コンソールのログレベルに、可能な限り低いログレベル設定を設定します。

4. 値。起動時のコンソールのログレベルのデフォルト値を設定します。上記の各値は、エラーメッセージを処理するさまざまなルールを定義します。

注記注記

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


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


42

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

7.1. KDUMP とは

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

重要重要

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

7.2. KDUMP のインストール

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

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


アクティブな Red Hat Enterprise Linux サブスクリプション

システムの CPU アーキテクチャー用の kexec-tools パッケージを含むリポジトリー

kdump の要件を満たしている。

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

43

手順手順

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

$ rpm -q kexec-tools

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

kexec-tools-2.0.17-11.el8.x86_64

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

package kexec-tools is not installed

2. kdump および必要なパッケージをインストールします。

# yum install kexec-tools

重要重要

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


kdump のメモリー要件の詳細は、「kdump メモリー要件」を参照してください。

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

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

kdump 機能に予約されているメモリーは、システムの起動時には常に予約されています。メモリーの量は、システムの GRUB (Grand Unified Bootloader) 2 設定で指定します。以下の手順では、コマンドラインから kdump に予約したメモリーの設定方法を説明します。



手順手順

1. root パーミッションで /etc/default/grub ファイルを編集します。

2. crashkernel= オプションを必要な値に設定します。たとえば、128 MB のメモリーを予約するには、以下を使用します。

crashkernel=128M

または、インストールされているメモリーの合計量に応じて、予約メモリーサイズを変数に設


44

または、インストールされているメモリーの合計量に応じて、予約メモリーサイズを変数に設定できます。変数へのメモリー予約の構文は crashkernel=<range1>:<size1>,<range2>:<size2> です。以下に例を示します。

crashkernel=512M-2G:64M,2G-:128M

上記の例では、システムメモリーの合計が 512 MB 以上 2 GB 未満の場合、64 MB のメモリーを予約します。メモリー合計サイズが 2 GB を超える場合は、128 MB が kdump 用に予約されます。

予約済みメモリーのオフセット。crashkernel 予約は非常に早いため、特定の固定オフセットでメモリーを予約する必要があるシステムもあります。また、特別な用途にいくつかの領域を予約したいシステムもあります。オフセットが設定されると、予約メモリーはそこから開始されます。予約メモリーをオフセットするには、以下の構文を使用します。

crashkernel=128M@16M

上記の例は、kdump が 16 MB (物理アドレス 0x01000000) から始まる 128 MB のメモリーを予約していることを示しています。オフセットパラメーターが 0 に設定されている場合、または完全に省略されている場合、kdump は自動的に予約メモリーをオフセットします。上記のように、変数メモリー予約を設定する場合にもこの構文を使用します。この場合、オフセットは常に最後に指定されます (例: crashkernel=512M-2G:64M,2G-:128 _M@16 _M)。

3. 以下のコマンドを使用して、GRUB2 設定ファイルを更新します。

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

注記注記

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


crashkernel= オプションは、複数の方法で定義できます。「kdump メモリー要件」で説明されているガイドラインに従い、auto 値を指定すると、システムの合計メモリーに基づいた、予約メモリーの自動設定が可能になります。

ブートエントリー、kernelopts、grub2-editenv および grubby での作業方法は、4章カーネルコマンドラインパラメーターの設定を参照してください。

7.3.2. kdump ターゲットの設定

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



45


手順手順

vmcore ファイルをローカルファイルシステムの /var/crash/ ディレクトリーに保存するには、次を行います。

/etc/kdump.conf ファイルを編集し、パスを指定します。

path /var/crash

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

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

警告警告

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

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

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

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

1. #path /var/crash の行頭にあるハッシュ記号 ("#") を削除します。

2. 値を対象のディレクトリーパスに置き換えます。以下に例を示します。

path /usr/local/cores

重要重要


46

重要重要

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

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

1. 必要に応じて #ext4 の行頭にあるハッシュ記号 ("#") を削除します。

デバイス名 (#ext4 /dev/vg/lv_kdump 行）

ファイルシステムラベル (#0ext4 LABEL=/boot 行)

UUID (#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937 の行)

2. ファイルシステムタイプと、デバイス名、ラベル、UUID を希望の値に変更します。以下に例を示します。

ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937

重要重要

LABEL= UUID= を使用してストレージデバイスを指定することが推奨されます。/dev/sda3 などのディスクデバイス名は、再起動しても一貫性は保証されません。

重要重要

IBM Z ハードウェア上の Direct Access Storage Device (DASD) にダンプする場合、処理を行う前に /etc/dasd.conf でダンプデバイスが正しく指定されている必要があります。

ダンプをデバイスに直接書き込むには、以下を行います。

1. #raw /dev/vg/lv_kdump の行頭にあるハッシュ記号 ("#") を削除します。

2. 値を対象のデバイス名に置き換えます。以下に例を示します。

raw /dev/sdb1

NFS プロトコルを使用して、リモートのマシンにダンプを保存するには、以下を行います。

1. #nfs my.server.com:/export/tmp の行頭にあるハッシュ記号 ("#") を削除します。

2. 値を、正しいホスト名およびディレクトリーパスに置き換えます。以下に例を示します。

nfs penguin.example.com:/export/cores

SSH プロトコルを使用してリモートマシンにダンプを保存するには、以下を行います。


47

1. #ssh [email protected] の行頭にあるハッシュ記号 ("#") を削除します。

2. 値を正しいユーザー名およびホスト名に置き換えます。

3. SSH キーを設定に含めます。

#sshkey /root/.ssh/kdump_id_rsa の行頭にあるハッシュ記号 ("#") を削除します。

値を、ダンプ先のサーバー上で正しいキーの場所に変更します。以下に例を示します。

ssh [email protected] /root/.ssh/mykey


対応しているダンプ出力先と非対応のダンプ出力先のタイプ別一覧は「サポートしているkdump のダンプ出力先」を参照してください。

SSH サーバーを構成し、キーベースの認証を設定する方法は、Red Hat Enterprise Linux の「基「基本的なシステム設定の構成」本的なシステム設定の構成」を参照してください。

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

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

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



手順手順

1. root で、/etc/kdump.conf 設定ファイルを編集し、#core_collector makedumpfile -l --message-level 1 -d 31 の行頭にあるハッシュ記号 ("#") を削除します。

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

core_collector makedumpfile -c

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

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

core_collector makedumpfile -d 17 -c

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


48

mailto:[email protected]

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#sec-SSH


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

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

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



手順手順

1. root で、/etc/kdump.conf 設定ファイルの #default shell の行頭にあるハッシュ記号 ("#") を削除します。

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

default poweroff

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

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


kdump 要件を満たしている。

すべての設定がニーズに応じて設定されている。

手順手順

1. kdump サービスを有効にするには、以下のコマンドを実行します。

# systemctl enable kdump.service

これにより、multi-user.target のサービスが有効になります。

2. 現行セッションでサービスを開始するには、以下のコマンドを使用します。

# systemctl start kdump.service

3. kdump サービスを停止するには、以下のコマンドを実行します。

# systemctl stop kdump.service

4. kdump サービスを無効にするには、以下のコマンドを実行します。

# systemctl disable kdump.service


49

警告警告

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

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

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

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

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

sysctl.conf ファイルにおけるカーネルの kptr_restrict=1。


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

7.4. WEB コンソールで KDUMP の設定

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


詳細は『『Red Hat Enterprise Linux Web コンソール』コンソール』を参照してください。

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

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


Web コンソールコンソールの操作概要

手順手順

1. Kernel Dump タブを開き、kdump サービスを開始します。


50

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#managing-services-with-systemd

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/managing_systems_using_the_rhel_8_web_console/index#getting-started-with-the-rhel-8-web-console_system-management-using-the-RHEL-8-web-console

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/managing_systems_using_the_rhel_8_web_console/index

2. コマンドラインコマンドラインで kdump のメモリー使用量を設定します。

3. クラッシュダンプの場所クラッシュダンプの場所オプションの横にあるリンクをクリックします。

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

または、ドロップダウンから SSH 経由のリモート経由のリモートオプションを選択し、SSH プロトコルを使用して、vmcore をリモートマシンに送信します。Server、ssh key、Directory の各フィールドに、リモートマシンのアドレス、ssh キーの場所、およびターゲットディレクトリーを入力します。

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

注記注記

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

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


51

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/index#configuring-kdump-memory-usage_configuring-kdump-on-the-command-line

警告警告

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


現在対応している kdump のターゲットの完全リストは、「対応している「対応している kdump のダンプ出力のダンプ出力先」先」を参照してください。

SSH サーバーを設定し、鍵ベースの認証を設定する方法は、「「2 台のシステム間で台のシステム間で OpenSSHを使用した安全な通信の使用」を使用した安全な通信の使用」を参照してください。

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

7.5.1. kdump メモリー要件

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

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

$ uname -m

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

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

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

AMD64 と Intel 64 (x86_64) 1 GB から 64 GB 160 MB のメモリー


52

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/index#supported-kdump-targets_supported-kdump-configurations-and-targets

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/securing_networks/using-secure-communications-between-two-systems-with-openssh_securing-networks

64 GB から 1 TB 256 MB のメモリー

1TB 以上 512 MB のメモリー

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

2 GB 以上 512 MB のメモリー

IBM Power Systems (ppc64le) 2 GB から 4 GB 384 MB のメモリー

4 GB から 16 GB 512 MB のメモリー

16 GB から 64 GB 1 GB のメモリー

64 GB から 128 GB 2 GB のメモリー

128 GB 以上 4 GB のメモリー

IBM Z (s390x) 4 GB から 64 GB 160 MB のメモリー

64 GB から 1 TB 256 MB のメモリー

1TB 以上 512 MB のメモリー

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

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

重要重要

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


コマンドラインでメモリー設定を変更する方法は、「メモリー使用量の設定」を参照してください。

Web コンソールから予約済みメモリーの量を設定する方法は、「Web コンソールで kdump メモリーの使用量およびターゲットの場所を設定」を参照してください。

Red Hat Enterprise Linux のさまざまなテクノロジー機能と制限は、テクノロジー機能と制限のテクノロジー機能と制限の表表を参照してください。

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


53

https://access.redhat.com/articles/rhel-limits

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

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

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

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

AMD64 と Intel 64 (x86_64) 2 GB

IBM Power Systems (ppc64le) 2 GB

IBM Z (s390x) 4 GB


コマンドラインでこれらの設定を手動で変更する方法は、「メモリー使用量の設定」を参照してください。

Web コンソールを介して予約メモリーの量を手動で変更する方法は、「Web コンソールでkdump メモリーの使用量およびターゲットの場所を設定」を参照してください。

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

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

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

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

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

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

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

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

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


54

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

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

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

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

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

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

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

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

重要重要

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


コマンドラインでターゲットタイプを設定する方法は、「kdump ターゲットの設定」を参照してください。

Web コンソールからターゲットを設定する方法は、「Web コンソールで kdump メモリーの使用量およびターゲットの場所を設定」を参照してください。

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

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

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


55

オプションオプション説明説明

1 ゼロページ

2 キャッシュページ

4 キャッシュプライベート

8 ユーザーページ

16 フリーページ

注記注記

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


コマンドラインでコアコレクターを設定する方法は、「コアコレクターの設定」を参照してください。

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

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

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


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

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

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

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


56

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



コマンドラインでデフォルトの失敗応答を設定する方法の詳細は、「kdump のデフォルト障害応答の設定」を参照してください。

7.5.6. kdumpサイズの見積もり

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

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

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

TYPE PAGES EXCLUDABLE DESCRIPTION----------------------------------------------------------------------ZERO 501635 yes Pages filled with zeroCACHE 51657 yes Cache pagesCACHE_PRIVATE 5442 yes Cache pages + privateUSER 16301 yes User process pagesFREE 77738211 yes Free pagesKERN_DATA 1333192 no Dumpable kernel data

重要重要

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

7.6. KDUMP 設定のテスト

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


57

警告警告

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

手順手順

1. kdump を有効にしてシステムを再起動します。

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

~]# systemctl is-active kdumpactive

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

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

警告警告

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

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

注記注記

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

7.7. KEXEC を使用したカーネルの再起動

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

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

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

手順手順


58

手順手順

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

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

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


# reboot

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

警告警告

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

7.8. KDUMP 用のカーネルドライバーのブラックリスト登録

kdump 用のカーネルドライバーのブラックリスト登録は、目的のカーネルドライバーが読み込まれないようにするメカニズムです。カーネルドライバーをブラックリストに登録すると、oom killer またはその他のクラッシュカーネルの失敗を防ぐことができます。

カーネルドライバーをブラックリストに指定するには、/etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_APPEND= 変数を更新し、以下のブラックリストオプションのいずれかを指定できます。

rd.driver.blacklist=<modules>

modprobe.blacklist=<modules>

/etc/sysconfig/kdump ファイルでドライバーをブラックリストに登録すると、kdump initramfs がブラックリストに指定したモジュールを読み込まなくなります。

以下の手順では、クラッシュカーネルの失敗を防ぐために、カーネルドライバーをブラックリストに登録する方法を説明します。

手順手順

1. ブラックリストに登録するカーネルモジュールを選択します。

$ lsmod

Module Size Used byfuse 126976 3


59

xt_CHECKSUM 16384 1ipt_MASQUERADE 16384 1uinput 20480 1xt_conntrack 16384 1

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

2. 以下のように /etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_APPEND= 行を更新します。

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

3. また、以下のように /etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_APPEND=行を更新することもできます。

KDUMP_COMMANDLINE_APPEND="modprobe.blacklist=emcp modprobe.blacklist=bnx2fc modprobe.blacklist=libfcoe modprobe.blacklist=fcoe"

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

$ systemctl restart kdump


oom killer に関する詳細情報は、「Crash kernel goes out of memory because of huge numberof FC LUN's」を参照してください。

モジュールのブラックリストオプションに関する dracut.cmdline の man ページ。

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

論理ボリュームマネージャー (LVM) ツールで暗号化されたパーティションを実行する場合は、システムには利用可能なメモリーが一定量必要になります。システムが必要なメモリー量を下回ると、cryptsetup ユーティリティーがパーティションのマウントに失敗します。その結果、vmcore ファイルをローカルの kdump ターゲットの場所 (LVM および有効な暗号化) にキャプチャーすると、次のカーネルで失敗します (カーネルのキャプチャー) で失敗します。

この手順では、crashkernel= の値を増やして、リモートの kdump ターゲットを使用するか鍵導出関数(KDF) を使用して kdump メカニズムを実行する方法を説明します。

手順手順

以下のいずれかの手順を実行して kdump メカニズムを実行します。

kdump を実行するには、以下のいずれかを定義します。

リモートの kdump ターゲットを設定します。

暗号化されていないパーティションにダンプを定義します。

crashkernel= 値を必要なレベルに指定します。

鍵導出関数 (KDF) を使用して、追加の鍵スロットを追加します。


60

https://access.redhat.com/solutions/2986581

1. cryptsetup luksAddKey --pbkdf pbkdf2 /dev/vda2

2. cryptsetup config --key-slot 1 --priority prefer /dev/vda2

3. cryptsetup luksDump /dev/vda2

暗号化されたパーティションのデフォルトの KDF を使用すると、大量のメモリーを消費する可能性があります。OOM (Out of Memory) エラーメッセージに遭遇しても、このパスワードは第 2 のカーネルで手動で指定する必要があります。

警告警告

複数の鍵が暗号化されたボリュームを復号できるため、追加の鍵スロットを追加するとセキュリティーに影響を与える可能性があります。これは、ボリュームに潜在的なリスクを引き起こす可能性があります。

7.10. コアダンプの分析

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

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

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

手順手順

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

# subscription-manager repos --enable baseos repository

# subscription-manager repos --enable appstream repository

2. crash パッケージをインストールします。

# yum install crash

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

# yum install kernel-debuginfo

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


subscription-manager ユーティリティーを使用してリポジトリーを操作する方法は、『基本『基本


61

https://access.redhat.com/labs/kdumphelper/

https://access.redhat.com/labs/kerneloopsanalyzer/

subscription-manager ユーティリティーを使用してリポジトリーを操作する方法は、『基本『基本的なシステム設定の構成』的なシステム設定の構成』を参照してください。

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

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


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

手順手順

1. crash ユーティリティーを起動するには、2 つの必要なパラメーターをコマンドに渡す必要があります。

debug-info (圧縮解除された vmlinuz イメージ) (特定の kernel-debuginfo パッケージに含まれる /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux など）

実際の vmcore ファイル。/var/crash/127.0.0.1-2018-10-06-14:05:33/vmcoreその結果の crash コマンドの以下のようになります。

# crash /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

kdump で取得したのと同じ <kernel> のバージョンを使用します。

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

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

...WARNING: kernel relocated [202MB]: patching 90160 gdb minimal_symbol values

KERNEL: /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux DUMPFILE: /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore [PARTIAL DUMP] CPUS: 2 DATE: Sat Oct 6 14:05:16 2018 UPTIME: 01:03:57LOAD 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


62

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#sec-Installation-Basic-Tasks

STATE: TASK_RUNNING (SYSRQ)

crash>

2. 対話型プロンプトを終了して crash を終了するには、crash または q を使用します。

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

crash> exit~]#

注記注記

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

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

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

メッセージバッファーの表示メッセージバッファーの表示

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

crash> log... several lines omitted ...EIP: 0060:[<c068124f>] EFLAGS: 00010096 CPU: 2EIP is at sysrq_handle_crash+0xf/0x20EAX: 00000063 EBX: 00000063 ECX: c09e1c8c EDX: 00000000ESI: c0a09ca0 EDI: 00000286 EBP: 00000000 ESP: ef4dbf24 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068Process 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 ef4dbfb4Call 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/0xbCode: 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 83EIP: [<c068124f>] sysrq_handle_crash+0xf/0x20 SS:ESP 0068:ef4dbf24CR2: 0000000000000000


63

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

注記注記

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

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

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

crash> btPID: 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


64

5567 1 2 ef427560 IN 0.0 12876 784 auditd 5587 5132 0 f196d030 IN 0.0 11064 3184 sshd> 5591 5587 2 f196d560 RU 0.0 5084 1648 bash

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

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

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

crash> vmPID: 5591 TASK: f196d560 CPU: 2 COMMAND: "bash" MM PGD RSS TOTAL_VMf19b5900 ef9c6000 1648k 5084k VMA START END FLAGS FILEf1bb0310 242000 260000 8000875 /lib/ld-2.12.sof26af0b8 260000 261000 8100871 /lib/ld-2.12.soefbc275c 261000 262000 8100873 /lib/ld-2.12.soefbc2a18 268000 3ed000 8000075 /lib/libc-2.12.soefbc23d8 3ed000 3ee000 8000070 /lib/libc-2.12.soefbc2888 3ee000 3f0000 8100071 /lib/libc-2.12.soefbc2cd4 3f0000 3f1000 8100073 /lib/libc-2.12.soefbc243c 3f1000 3f4000 100073efbc28ec 3f6000 3f9000 8000075 /lib/libdl-2.12.soefbc2568 3f9000 3fa000 8100071 /lib/libdl-2.12.soefbc2f2c 3fa000 3fb000 8100073 /lib/libdl-2.12.sof26af888 7e6000 7fc000 8000075 /lib/libtinfo.so.5.7f26aff2c 7fc000 7ff000 8100073 /lib/libtinfo.so.5.7efbc211c d83000 d8f000 8000075 /lib/libnss_files-2.12.soefbc2504 d8f000 d90000 8100071 /lib/libnss_files-2.12.soefbc2950 d90000 d91000 8100073 /lib/libnss_files-2.12.sof26afe00 edc000 edd000 4040075f1bb0a18 8047000 8118000 8001875 /bin/bashf1bb01e4 8118000 811d000 8101873 /bin/bashf1bb0c70 811d000 8122000 100073f26afae0 9fd9000 9ffa000 100073... several lines omitted ...

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

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

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

crash> filesPID: 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


65

2 f734f640 eedc2c6c eecd6048 CHR /pts/0 10 f734f640 eedc2c6c eecd6048 CHR /pts/0255 f734f640 eedc2c6c eecd6048 CHR /pts/0

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

7.10.4. Kernel Oops Analyzer の使用

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


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

手順手順

1. Kernel Oops Analyzer リンクに従って、ツールにアクセスします。

2. 参照参照を押して、oops メッセージを参照します。

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

7.11. EARLY KDUMP を使用した起動時間クラッシュの取得

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

7.11.1. early kdump の概要

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

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


66

https://access.redhat.com/labs/kerneloopsanalyzer/#instruction

https://access.redhat.com/labs/kerneloopsanalyzer/

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


early kdump およびその使用方法の詳細は、/usr/share/doc/kexec-tools/early-kdump-howto.txt ファイルと、「What is early kdump support and how do I configure it?」を参照してください。

kdump サービスの詳細は、「kdump とは」を参照してください。

7.11.2. early kdump の有効化

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


アクティブな Red Hat Enterprise Linux サブスクリプション

システムの CPU アーキテクチャー用の kexec-tools パッケージを含むリポジトリー


手順手順

1. kdump サービスが有効でアクティブであることを確認します。

# systemctl is-enabled kdump.service && systemctl is-active kdump.serviceenabledactive

kdump が有効ではなく、実行している場合は、「kdump サービスの有効化および無効化」を参照してください。

2. 起動カーネルの initramfs イメージを、early kdump 機能で再構築します。

dracut -f --add earlykdump

3. rd.earlykdump カーネルコマンドラインパラメーターを追加します。

grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="rd.earlykdump"

4. 再起動します。

5. 必要に応じて、rd.earlykdump が正常に追加され、early kdump 機能が有効になっていることを確認します。

# cat /proc/cmdlineBOOT_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


67


# journalctl -x | grep early-kdumpMar 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


early kdump の有効化に関する詳細は、/usr/share/doc/kexec-tools/early-kdump-howto.txtファイルおよび「What is early kdump support and how do I configure it?」を参照してください。

7.12. 関連情報

次のセクションでは、クラッシュ情報の取得に関連する詳細情報を説明します。

kdump.conf(5) - 利用できるオプションの完全なドキュメンテーションを含む /etc/kdump.conf設定ファイルの man ページ。

zipl.conf(5): /etc/zipl.conf 設定ファイルの man ページです。

zipl(8) - IBM System z 用の zipl ブートローダーユーティリティーの man ページ。

makedumpfile(8) - makedumpfile コアコレクターの man ページ。

kexec(8) — kexec の man ページ。

crash(8) — crash ユーティリティの man ページ。

/usr/share/doc/kexec-tools/kexec-kdump-howto.txt —kdump と kexec インストールと使用の概要。

kexec と kdump 設定の詳細は、『『Red Hat ナレッジベース記事』ナレッジベース記事』を参照してください。

対応している kdump ターゲットの詳細は、『『Red Hat ナレッジベース記事』ナレッジベース記事』を参照してください。


68


https://access.redhat.com/site/solutions/6038

https://access.redhat.com/site/solutions/223773

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

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

重大なセキュリティーパッチをカーネルに即座に適用することが可能。

長時間実行しているタスクの完了、ユーザーのログオフ、スケジュールダウンタイムを待つ必要がない。

システムのアップタイムをより制御し、セキュリティーや安定性を犠牲にしない。

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

警告警告

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

8.1. KPATCH の制限

kpatch 機能は、汎用のカーネルアップグレードメカニズムではありません。システムをすぐに再起動できない場合など、単純なセキュリティーおよびバグ修正の更新を適用する場合に使用します。

パッチの読み込み中または読み込み後は、SystemTap ツールまたは kprobe ツールを使用しないでください。このようなプローブが削除されるまでは、パッチが適用できなくなる可能性があります。

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

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

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

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

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

69

https://access.redhat.com/ja/solutions/2852611

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

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

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

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

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

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

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

カーネルライブパッチの配信メカニズム

パッチが適用されるカーネル用に構築したカーネルモジュール。

パッチモジュールには、カーネルに必要な修正のコードが含まれます。

パッチモジュールは、kpatch カーネルサブシステムで登録し、置き換えられるオリジナル機能の情報を提供します。また、置換される機能に一致するポインターも含まれます。カーネルパッチモジュールは RPM として提供されます。

命名規則は、kpatch_<kernel version>_<kpatch version>_<kpatch release> です。名前の「kernel version」の部分のピリオドピリオドおよびハイフンハイフンがアンダースコアアンダースコアに置き換えられています。

kpatch ユーティリティーユーティリティー

パッチモジュールを管理するためのコマンドラインユーティリティー。

kpatch サービスサービス

multiuser.target で必要な systemd サービス。このターゲットは、システムの起動時にカーネルパッチをロードします。

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

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

1. カーネルパッチモジュールは、/var/lib/kpatch/ ディレクトリーにコピーされ、次回の起動時に systemd を介して、カーネルへの再適用として登録されます。

2. 実行中のカーネルに kpatch モジュールがロードされ、新しいコードのメモリー内の場所を指定するポインターを使用して、新しい機能が ftrace メカニズムに登録されます。


70


3. パッチが当てられた機能にカーネルがアクセスすると、ftrace メカニズムにリダイレクトされます。これにより、元々の機能は回避され、パッチを当てたバージョンの機能にカーネルをリダイレクトします。

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

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

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

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

警告警告

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

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

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


71

警告警告

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


root 権限

手順手順

1. 必要に応じて、カーネルバージョンを確認します。

# uname -r4.18.0-94.el8.x86_64

2. カーネルのバージョンに一致するライブパッチパッケージを検索します。

# yum search $(uname -r)

3. ライブパッチパッケージをインストールします。

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

上記のコマンドでは、特定カーネルにのみに最新の累積パッチをインストールし、適用します。

パッケージのバージョンが 1-1 以上であれば、ライブパッチパッケージには、パッチモジュールが含まれます。この場合、ライブパッチパッケージのインストール時に、カーネルにパッチが自動的に適用されます。

カーネルパッチモジュールは、今後の再起動時に systemd システムおよびサービスマネージャーにより読み込まれる /var/lib/kpatch/ ディレクトリーにもインストールされます。

注記注記

指定のカーネルに利用可能なライブパッチがない場合は、空のライブパッチパッケージがインストールされます。空のライブパッチパッケージには、kpatch_version-kpatch_release 0-0 (例: kpatch-patch-4_18_0-94-0-0.el8.x86_64.rpm) が含まれます。空の RPM のインストールを行うと、指定のカーネルの将来のすべてのライブパッチにシステムがサブスクライブされます。

4. 必要に応じて、カーネルがパッチを当てていることを確認します。

# kpatch listLoaded patch modules:kpatch_4_18_0_94_1_1 [enabled]


72

Installed patch modules:kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)…

この出力は、カーネルパッチモジュールがカーネルに読み込まれていることを示しています。つまり、カーネルは現在、kpatch-patch-4_18_0-94-1-1.el8.x86_64.rpm パッケージの最新の修正でパッチが当てられています。


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

Red Hat Enterprise Linux 8 のソフトウェアパッケージをインストールする方法は、「基本的な「基本的なシステム設定の構成」システム設定の構成」の関連セクションを参照してください。

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

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


「ライブパッチストリームへのサブスクライブ」で説明されているように、システムがライブパッチストリームにサブスクライブされています。

手順手順

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

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

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

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

# yum update "kpatch-patch*"

注記注記

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


ソフトウェアパッケージの更新の詳細情報は、Red Hat Enterprise Linux 8 での「基本的なシス「基本的なシステム設定を構成」テム設定を構成」を参照してください。

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

システム管理者が、Red Hat Enterprise Linux カーネルライブパッチソリューション関連の不足の悪影響


73

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#installing-software-packages_managing-software-packages

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#updating-software-packages_managing-software-packages

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

重要重要

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

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

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


root 権限

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

手順手順

1. ライブパッチパッケージを選択します。

# yum list installed | grep kpatch-patchkpatch-patch-4_18_0-94.x86_64 1-1.el8 @@commandline…

上記の出力例は、インストールしたライブパッチパッケージを一覧表示します。

2. ライブパッチパッケージを削除します。

# yum remove kpatch-patch-4_18_0-94.x86_64

ライブパッチパッケージが削除されると、カーネルは次回の再起動までパッチが当てられたままになりますが、カーネルパッチモジュールはディスクから削除されます。次回の再起動後に、この一致するカーネルにはパッチが適用されません。


4. ライブパッチパッケージが削除されたことを確認します。

# yum list installed | grep kpatch-patch

パッケージが正常に削除された場合、このコマンドでは何も出力されません。

5. 必要に応じて、カーネルのライブパッチソリューションが無効になっていることを確認します。

# kpatch listLoaded patch modules:

この出力例では、現在読み込まれているパッチモジュールがないため、カーネルにパッチが適


74

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



RHEL 8 でソフトウェアパッケージを削除する方法は、「基本的なシステム設定の構成」「基本的なシステム設定の構成」の関連セクションを参照してください。

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

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


root 権限


カーネルパッチモジュールがインストールされ、ロードされている。

手順手順

1. カーネルパッチモジュールを選択します。


Installed patch modules:kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)…

2. 選択したカーネルパッチモジュールをアンインストールします。

# kpatch uninstall kpatch_4_18_0_94_1_1uninstalling kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

アンインストールしたカーネルモジュールが読み込まれていることに注意してください。


Installed patch modules:<NO_RESULT>

選択したモジュールをアンインストールすると、カーネルは次回の再起動までパッチが当てられますが、カーネルパッチモジュールはディスクから削除されます。



75

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#uninstalling-software-packages_managing-software-packages

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

# kpatch listLoaded patch modules:…

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



8.8.3. kpatch.service の無効化

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


root 権限


カーネルパッチモジュールがインストールされ、ロードされている。

手順手順

1. kpatch.service が有効化されていることを確認します。

# systemctl is-enabled kpatch.serviceenabled

2. kpatch.service を無効にします。

# systemctl disable kpatch.serviceRemoved /etc/systemd/system/multi-user.target.wants/kpatch.service.

適用されたカーネルモジュールが依然としてロードされていることに注意してください。


Installed patch modules:kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)


4. 必要に応じて、kpatch.service のステータスを確認します。

# systemctl status kpatch.service


76

● kpatch.service - "Apply kpatch kernel patches" Loaded: loaded (/usr/lib/systemd/system/kpatch.service; disabled; vendor preset: disabled) Active: inactive (dead)

この出力テストサンプルでは、kpatch.service が無効になっており、実行されていないことを証明しています。したがって、カーネルのライブパッチソリューションはアクティブではありません。

5. カーネルパッチモジュールがアンロードされたことを確認します。

# kpatch listLoaded patch modules:<NO_RESULT>

Installed patch modules:kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

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



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


77

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#managing-services-with-systemd_configuring-basic-system-settings

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

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

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

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

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

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

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

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

階層の柔軟性から生じるコントローラー連携の問題は、control groups version 2 の発展につながっていました。Control groups version 2 (cgroups-v2) では、すべてのリソースコントロールがマウントされることに対して単一のコントロールグループ階層を指定します。

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

警告警告

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

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


78

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/8.1_release_notes/index#technology-preview_kernel


リソースコントローラーの詳細は、「Linux カーネルリソースコントローラーとは」セクションおよび man ページの cgroups(7) を参照してください。

cgroups の階層と cgroups バージョンの詳細は、cgroups(7) man ページを参照してください。

systemd および cgroups の連携に関する詳細は、「コントロールグループでの systemd の役割」を参照してください。

9.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 パフォーマンス監視およびレポートユーティリティーにより、監視するタス

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

79

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 - サポートは継承され、明示的な制御ファイルはありません。v2 cgroup をパラメーターとして指定し、その cgroup 内のすべてのタスクをプロファイルする perf コマンドを指定できます。

重要重要

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


一般的なリソースコントローラーの詳細は、cgroups(7) man ページを参照してください。

特定のリソースコントローラーの詳細は、/usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/ ディレクトリーのドキュメントを参照してください。

cgroups-v2 の詳細は、cgroups(7) man ページを参照してください。

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

コントロールグループコントロールグループ (cgroup) を使用して、プロセスのグループのハードウェアリソースへの制限、優先順位付け、またはアクセス制御を設定できます。これにより、アプリケーションのリソース使用状況をより効率的に使用するために詳細な制御が可能になります。以下のセクションでは、仮想ファイルシステムを使用したバージョン 1 とバージョン 2 の両方の cgroup の管理に関連するタスクの概要を説明します。

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

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


80


CPU 消費を制限するアプリケーション。

cgroups-v1 コントローラーがマウントされていることを確認します。

# mount -l | grep cgrouptmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpu,cpuacct)cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)...

手順手順

1. CPU 消費で制限する必要のあるアプリケーションのプロセス ID (PID) を特定します。

# toptop - 11:34:09 up 11 min, 1 user, load average: 0.51, 0.27, 0.22Tasks: 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 stMiB Mem : 1826.8 total, 303.4 free, 1046.8 used, 476.5 buff/cacheMiB Swap: 1536.0 total, 1396.0 free, 140.0 used. 616.4 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6955 root 20 0 228440 1752 1472 R 99.3 0.1 0:32.71 sha1sum 5760 jdoe 20 0 3603868 205188 64196 S 3.7 11.0 0:17.19 gnome-shell 6448 jdoe 20 0 743648 30640 19488 S 0.7 1.6 0:02.73 gnome-terminal- 1 root 20 0 245300 6568 4116 S 0.3 0.4 0:01.87 systemd 505 root 20 0 0 0 0 I 0.3 0.0 0:00.75 kworker/u4:4-events_unbound...

top プログラムの出力例は、PID 6955 (具体例のアプリケーション sha1sum) が CPU リソースを対象に消費することを示しています。

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

# mkdir /sys/fs/cgroup/cpu/Example/

上記のディレクトリーは、特定のプロセスを配置でき、特定の CPU 制限をプロセスに適用できるコントロールグループです。同時に、一部の cgroups-v1 インターフェースファイルと cpuコントローラー固有のファイルがディレクトリーに作成されます。

3. 必要に応じて、新しく作成されたコントロールグループを確認します。

# ll /sys/fs/cgroup/cpu/Example/-rw-r— r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children-rw-r— r--. 1 root root 0 Mar 11 11:42 cgroup.procs-r— r— r--. 1 root root 0 Mar 11 11:42 cpuacct.stat-rw-r— r--. 1 root root 0 Mar 11 11:42 cpuacct.usage


81

-r— r— r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all-r— r— r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu-r— r— r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys-r— r— r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user-r— r— r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys-r— r— r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user-rw-r— r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us-rw-r— r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us-rw-r— r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us-rw-r— r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us-rw-r— r--. 1 root root 0 Mar 11 11:42 cpu.shares-r— r— r--. 1 root root 0 Mar 11 11:42 cpu.stat-rw-r— r--. 1 root root 0 Mar 11 11:42 notify_on_release-rw-r— r--. 1 root root 0 Mar 11 11:42 tasks

この出力例は、特定の設定や制限を表す cpuacct.usage、cpu.cfs._period_us などのファイルを示しています。これは、Example コントロールグループのプロセスに設定できます。各ファイル名の前に、そのファイルが属するコントロールグループコントローラーの名前が付けられることに注意してください。

デフォルトでは、新しく作成されたコントロールグループは、システムの CPU リソース全体へのアクセスを制限なしで継承します。

4. コントロールグループの CPU 制限を設定します。

# echo "1000000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us# echo "200000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us

cpu.cfs_period_us ファイルは、制御グループの CPU リソースへのアクセスが再割り当てされる頻度について、マイクロ秒単位の期間 (ここでは「us」と表示されますが µs) を表します。上限は 1 秒で、下限は 1000 マイクロ秒です。

cpu.cfs_quota_us ファイルは、(cpu.cfs_period_us で定義されるように) コントロールグループのすべてのプロセスを 1 期間中に実行できる合計時間をマイクロ秒単位で表します。コントロールグループ内のプロセスが 1 つの期間中にクォータで指定されたすべての時間を使用して、残りの期間はスロットリングされ、次の期間まで実行することはできません。下限は1000 マイクロ秒です。

上記のコマンド例は、CPU 時間制限を設定して、Example コントロールグループでまとめられているすべてのプロセスは、1 秒ごと (cpu.cfs_period_us に定義されている) に、0.2 秒間だけ (cpu.cfs_quota_us に定義されている) 実行できるようにしています。

5. 必要に応じて、制限を確認します。

# cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us1000000200000

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

# echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs

or

# echo "6955" > /sys/fs/cgroup/cpu/Example/tasks


82

上記のコマンドは、目的のアプリケーションが Example コントロールグループのメンバーとなるようにします。したがって、Example コントロールグループに設定された CPU 制限を超えないようにします。PID は、システム内の既存のプロセスを表します。ここで PID 6955 は、プロセス sha1sum /dev/zero & に割り当てられ、cpu コントローラーの使用例を示すために使用されました。

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

# cat /proc/6955/cgroup12:cpuset:/11:hugetlb:/10:net_cls,net_prio:/9:memory:/user.slice/user-1000.slice/[email protected]:devices:/user.slice7:blkio:/6:freezer:/5:rdma:/4:pids:/user.slice/user-1000.slice/[email protected]:perf_event:/2:cpu,cpuacct:/Example1:name=systemd:/user.slice/user-1000.slice/[email protected]/gnome-terminal-server.service

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

8. スロットルアプリケーションの現在の CPU 使用率を特定します。

# toptop - 12:28:42 up 1:06, 1 user, load average: 1.02, 1.02, 1.00Tasks: 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 stMiB Mem : 1826.8 total, 287.1 free, 1054.4 used, 485.3 buff/cacheMiB 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% に減少していることに注意してください。


コントロールグループの概念は、「コントロールグループについて」を参照してください。

リソースコントローラーの詳細は、「Linux カーネルリソースコントローラーとは」セクション、および man ページの cgroups(7) を参照してください。

/sys/fs/ 仮想ファイルシステムの詳細は、man ページの sysfs(5) を参照してください。


83

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

アプリケーションは CPU 時間が多く使用されることがあり、環境全体の健全性に影響を与える可能性があります。コントロールグループのバージョンコントロールグループのバージョン 2 (cgroups-v2) を使用してアプリケーションへのCPU 制限を設定し、その消費量を制限します。


CPU 消費を制限するアプリケーション。

「コントロールグループについて」

手順手順

1. システム起動時に cgroups-v1 が自動的にマウントされないようにします。

# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="cgroup_no_v1=all"

コマンドは、カーネルコマンドラインパラメーターを現在のブートエントリーに追加します。cgroup_no_v1=all パラメーターは、cgroups-v1 が自動的にマウントされないようにします。

または、systemd.unified_cgroup_hierarchy=1 カーネルコマンドラインパラメーターを使用して、システム起動時にデフォルトで cgroups-v2 をマウントします。

注記注記

RHEL 8 は、cgroups-v1 と cgroups-v2 の両方に対応します。ただし、cgroups-v1 は、ブートプロセス時にデフォルトで有効になっており、マウントされます。


3. 必要に応じて、cgroups-v1 機能が無効になっていることを確認します。

# mount -l | grep cgrouptmpfs 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)

cgroups-v1 が正常に無効にされている場合は、出力に systemd に属するものを除き、「typecgroup」の参照は表示されません。

4. cgroups-v2 をファイルシステムの任意の場所にマウントします。

# mount -t cgroup2 none <MOUNT_POINT>

5. 必要に応じて、cgroups-v2 機能がマウントされていることを確認します。

# mount -l | grep cgroup2none on /cgroups-v2 type cgroup2 (rw,relatime,seclabel)

この出力例は、cgroups-v2 が /cgroups-v2/ ディレクトリーにマウントされていることを示し


84

この出力例は、cgroups-v2 が /cgroups-v2/ ディレクトリーにマウントされていることを示しています。

6. 必要に応じて、/cgroups-v2/ ディレクトリーの内容を確認します。

# ll /cgroups-v2/-r— r— r--. 1 root root 0 Mar 13 11:57 cgroup.controllers-rw-r— r--. 1 root root 0 Mar 13 11:57 cgroup.max.depth-rw-r— r--. 1 root root 0 Mar 13 11:57 cgroup.max.descendants-rw-r— r--. 1 root root 0 Mar 13 11:57 cgroup.procs-r— r— r--. 1 root root 0 Mar 13 11:57 cgroup.stat-rw-r— r--. 1 root root 0 Mar 13 11:58 cgroup.subtree_control-rw-r— r--. 1 root root 0 Mar 13 11:57 cgroup.threads-rw-r— r--. 1 root root 0 Mar 13 11:57 cpu.pressure-r— r— r--. 1 root root 0 Mar 13 11:57 cpuset.cpus.effective-r— r— r--. 1 root root 0 Mar 13 11:57 cpuset.mems.effective-rw-r— r--. 1 root root 0 Mar 13 11:57 io.pressure-rw-r— r--. 1 root root 0 Mar 13 11:57 memory.pressure

/cgroups-v2/ ディレクトリーには、root コントロールグループとも呼ばれるインターフェースファイル (cgroup で始まる) と、cpuset.cpus.effective などのコントローラー固有のファイルが含まれます。

7. CPU 消費で制限する必要のあるアプリケーションのプロセス ID (PID) を特定します。


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5473 root 20 0 228440 1740 1456 R 99.7 0.1 0:12.11 sha1sum 5439 root 20 0 222616 3420 3052 R 60.5 0.2 0:27.08 cpu_load_generator 2170 jdoe 20 0 3600716 209960 67548 S 0.3 11.2 1:18.50 gnome-shell 3051 root 20 0 274424 3976 3092 R 0.3 0.2 1:01.25 top 1 root 20 0 245448 10256 5448 S 0.0 0.5 0:02.52 systemd...

top プログラムの出力例は、PID 5473 および 5439 (具体例のアプリケーション sha1sum および cpu_load_generator) が CPU などの多くのリソースを消費することを示しています。いずれも cgroups-v2 機能の管理に使用するアプリケーションの例です。

8. CPU 関連のコントローラーを有効にします。

# echo "+cpu" > /cgroups-v2/cgroup.subtree_control# echo "+cpuset" > /cgroups-v2/cgroup.subtree_control

上記のコマンドは、root コントロールグループ /cgroups-v2/ の即時サブコントロールグループに cpu および cpuset コントローラーを有効にします。

9. 以前に作成した /cgroups-v2/ ディレクトリーにサブディレクトリーを作成します。

# mkdir /cgroups-v2/Example/


85

/cgroups-v2/Example/ ディレクトリーはサブコントロールグループを表します。このグループでは、特定のプロセスを配置でき、各種の CPU 制限をプロセスに適用できます。また、前の手順では、このサブ制御グループの cpu コントローラーおよび cpuset コントローラーを有効にしていました。

/cgroups-v2/Example/ の作成時に、cgroups-v2 インターフェースファイルと cpu および cpuset のコントローラー固有のファイルがディレクトリーに作成されます。

10. 必要に応じて、新しく作成されたコントロールグループを確認します。

# ll /cgroups-v2/Example/-r— r— r--. 1 root root 0 Mar 13 14:48 cgroup.controllers-r— r— r--. 1 root root 0 Mar 13 14:48 cgroup.events-rw-r— r--. 1 root root 0 Mar 13 14:48 cgroup.freeze-rw-r— r--. 1 root root 0 Mar 13 14:48 cgroup.max.depth-rw-r— r--. 1 root root 0 Mar 13 14:48 cgroup.max.descendants-rw-r— r--. 1 root root 0 Mar 13 14:48 cgroup.procs-r— r— r--. 1 root root 0 Mar 13 14:48 cgroup.stat-rw-r— r--. 1 root root 0 Mar 13 14:48 cgroup.subtree_control-rw-r— r--. 1 root root 0 Mar 13 14:48 cgroup.threads-rw-r— r--. 1 root root 0 Mar 13 14:48 cgroup.type-rw-r— r--. 1 root root 0 Mar 13 14:48 cpu.max-rw-r— r--. 1 root root 0 Mar 13 14:48 cpu.pressure-rw-r— r--. 1 root root 0 Mar 13 14:48 cpuset.cpus-r— r— r--. 1 root root 0 Mar 13 14:48 cpuset.cpus.effective-rw-r— r--. 1 root root 0 Mar 13 14:48 cpuset.cpus.partition-rw-r— r--. 1 root root 0 Mar 13 14:48 cpuset.mems-r— r— r--. 1 root root 0 Mar 13 14:48 cpuset.mems.effective-r— r— r--. 1 root root 0 Mar 13 14:48 cpu.stat-rw-r— r--. 1 root root 0 Mar 13 14:48 cpu.weight-rw-r— r--. 1 root root 0 Mar 13 14:48 cpu.weight.nice-rw-r— r--. 1 root root 0 Mar 13 14:48 io.pressure-rw-r— r--. 1 root root 0 Mar 13 14:48 memory.pressure

出力例には、cpuset.cpus や cpu.max などのファイルが表示されます。ファイルは、/cgroups-v2/cgroup.subtree_control ファイルを使用して、ルート (/cgroups-v2/) ダイレクト子コントロールグループに対して有効にした cpuset コントローラーおよび cpu コントローラーに固有のものです。また、cgroup.procs、cgroup.controllers などの一般的な cgroup コントロールインターフェースファイルは、有効なコントローラーに関係なく、すべてのコントロールグループに共通します。

デフォルトでは、新しく作成されたサブコントロールグループは、システムの CPU リソース全体へのアクセスを制限なしで継承します。

11. 同じ CPU 上の CPU 時間について、制限するプロセスを確認します。

# echo "1" > /cgroups-v2/Example/cpuset.cpus

上記のコマンドは、Example サブコントロールグループに置かれたプロセスを、同じ CPU で保護します。この設定は、cpu コントローラーをアクティベートするのに重要です。

重要重要


86

重要重要

cpu コントローラーは、関連するサブコントロールグループに 2 つ以上のプロセスがある場合にのみアクティベートされます。これは、1 つの CPU でしばらく有効になります。

12. コントロールグループの CPU 制限を設定します。

# echo "200000 1000000" > /cgroups-v2/Example/cpu.max

最初の値は、サブコントロールグループのすべてのプロセスが一定期間 (次の値で指定) に実行できる、許可される時間クォータ (マイクロ秒単位) です。シングルピリオドでは、コントロールグループのプロセスがこのクォータで指定されたすべての時間を完全に使い切ると、残りの期間はスロットリングされ、次の期間まで実行できなくなります。

コマンド例は、Example サブコントロールグループのすべてのプロセスが 1 秒あたり 0.2 秒のみ CPU で実行可能になるように CPU 時間制限を設定します。

13. 必要に応じて、制限を確認します。

# cat /cgroups-v2/Example/cpu.max200000 1000000

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

# echo "5473" > /cgroups-v2/Example/cgroup.procs# echo "5439" > /cgroups-v2/Example/cgroup.procs

上記のコマンド例は、アプリケーションが Example サブコントロールグループのメンバーであることを確認するため、Example サブコントロールグループに設定された CPU 制限を超えないようにします。

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

# cat /proc/5473/cgroup /proc/5439/cgroup1:name=systemd:/user.slice/user-1000.slice/[email protected]/gnome-terminal-server.service0::/Example1:name=systemd:/user.slice/user-1000.slice/[email protected]/gnome-terminal-server.service0::/Example

上記の出力例は、必要なアプリケーションのプロセスが Example サブコントロールグループで実行されることを示しています。

16. スロットルしたアプリケーションの現在の CPU 使用率を確認します。


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND


87

5439 root 20 0 222616 3420 3052 R 10.0 0.2 6:15.83 cpu_load_generator 5473 root 20 0 228440 1740 1456 R 10.0 0.1 9:20.65 sha1sum 2753 jdoe 20 0 743928 35328 20608 S 0.7 1.9 0:20.36 gnome-terminal- 2170 jdoe 20 0 3599688 208820 67552 S 0.3 11.2 1:33.06 gnome-shell 5934 root 20 0 274428 5064 4176 R 0.3 0.3 0:00.04 top ...

PID 5439 および PID 5473 の CPU 消費量が 10% に減少していることに注意してください。Example サブコントロールグループは、そのプロセスを CPU 時間の 20% に制限します。コントロールグループに 2 つのプロセスがあるため、各プロセスは CPU 時間の 10% を使用できます。



リソースコントローラーの詳細は、「Linux カーネルリソースコントローラーとは」セクション、および man ページの cgroups(7) を参照してください。

/sys/fs/ 仮想ファイルシステムの詳細は、man ページの sysfs(5) を参照してください。

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

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

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

systemd の 3 つのユニットタイプは、リソースを制御するために使用されます。

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

<name>.service

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

<name>.scope

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


88

<parent-name>.slice

parent-name.slice は parent.slice のサブスライスで、-.slice ルートスライスのサブスライスです。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 …

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


systemd、ユニットファイル、および systemd ユニットタイプの完全な一覧の詳細は、『基『基


89

systemd、ユニットファイル、および systemd ユニットタイプの完全な一覧の詳細は、『基『基本的なシステム設定の構成』本的なシステム設定の構成』の関連セクションを参照してください。

リソースコントローラーの詳細は、「カーネルリソースコントローラーとは」セクションと、man ページの systemd.resource-control(5) および cgroups(7) を参照してください。

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

9.5. SYSTEMD でコントロールグループバージョン 1 の使用

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

9.5.1. systemd によるコントロールグループバージョン 1 の作成

systemd システムおよびサービスマネージャーを使用して、一時的および永続的なコントロールグループ (cgroup) を作成し、プロセスのグループのハードウェアリソースへの制限、優先順位付け、または制御を設定できます。

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

一時的な 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>

コマンドは、一時的なサービスユニットを作成して開始し、そのユニットでカスタムコマンド


90

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/managing-services-with-systemd_configuring-basic-system-settings

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



コントロールグループの systemd ロールの詳細は、「コントロールグループバージョン 1 における systemd の役割」を参照してください。

systemd、ユニット設定ファイル、その場所、および systemd ユニットタイプの完全なリストの詳細は、「基本的なシステム設定の構成」「基本的なシステム設定の構成」の関連セクションを参照してください。

追加のオプションや例を含む systemd-run の詳細な説明は、man ページの systemd-run(1) を参照してください。

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

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

手順手順

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

# systemctl enable <name>.service

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





追加のオプションや例を含む systemd-run の詳細な説明は、man ページの systemd-run(1) を参照してください。

9.5.2. systemd によるコントロールグループバージョン 1 の変更

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

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

コマンドラインインターフェースでコマンドを実行する方法は、プロセスのグループのハードウェアリ


91

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/managing-services-with-systemd_configuring-basic-system-settings

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/managing-services-with-systemd_configuring-basic-system-settings

コマンドラインインターフェースでコマンドを実行する方法は、プロセスのグループのハードウェアリソースへのアクセスを設定、優先順位付け、制御する方法です。

手順手順

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

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

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

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

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

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

注記注記

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



リソースコントローラーの詳細は、「Linux カーネルリソースコントローラーとは」と、manページの systemd.resource-control(5) および cgroups(7) を参照してください。


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

ユニットファイルを手動で修正する方法は、プロセスのグループのハードウェアリソースへのアクセスを設定、優先順位付け、または制御する方法です。

手順手順

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

… [Service]MemoryLimit=1500K


92

…

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

注記注記

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

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

# systemctl daemon-reload

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

# systemctl restart example.service


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

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

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

注記注記

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






9.5.3. systemd によるコントロールグループバージョン 1 の削除

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


93

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#managing-services-with-systemd

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

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

手順手順

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

# systemctl stop <name>.service

ユニットプロセスを 1 つ以上終了するには、以下を実行します。

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

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






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

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

手順手順

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

# systemctl stop <name>.service

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

# systemctl disable <name>.service

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

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

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


94

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8-beta/html-single/configuring_basic_system_settings/index#managing-services-with-systemd

# systemctl daemon-reload






systemd でプロセスを強制終了する方法は、man ページの systemd.kill(5) を参照してください。

9.6. コントロールグループバージョン 1 に関する情報の取得

以下のセクションでは、コントロールグループ (cgroup) に関するさまざまな情報を表示する方法を説明します。

systemd ユニットの一覧表示およびステータスの表示

cgroups 階層の表示

リアルタイムでリソース消費の監視

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

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


コントロールグループ内の systemd の役割

手順手順

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

UNIT LOAD ACTIVE SUB DESCRIPTION… init.scope loaded active running System and Service Managersession-2.scope loaded active running Session 2 of user jdoeabrt-ccpp.service loaded active exited Install ABRT coredump hookabrt-oops.service loaded active running ABRT kernel log watcherabrt-vmcore.service loaded active exited Harvest vmcores for ABRTabrt-xorg.service loaded active running ABRT Xorg log watcher… -.slice loaded active active Root Slicemachine.slice loaded active active Virtual Machine and Container Slice system-getty.slice loaded active active


95

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8-beta/html-single/configuring_basic_system_settings/index#managing-services-with-systemd

system-getty.slicesystem-lvm2\x2dpvscan.slice loaded active active system-lvm2\x2dpvscan.slicesystem-sshd\x2dkeygen.slice loaded active active system-sshd\x2dkeygen.slicesystem-systemd\x2dhibernate\x2dresume.slice loaded active active system-systemd\x2dhibernate\x2dresume>system-user\x2druntime\x2ddir.slice loaded active active system-user\x2druntime\x2ddir.slicesystem.slice loaded active active System Sliceuser-1000.slice loaded active active User Slice of UID 1000user-42.slice loaded active active User Slice of UID 42user.slice loaded active active User and Session Slice…

UNIT - コントロールグループ階層内のユニットの位置も反映するユニットの名前です。リソース制御に関連するユニットは、スライススライス、スコープスコープ、およびサービスサービスです。

LOAD - ユニット設定ファイルが正しく読み込まれたかどうかを示します。ユニットファイルの読み込みに失敗した場合、フィールドには loaded ではなく error 状態が含まれます。他のユニットの読み込み状態は、stub、merged、および masked です。

ACTIVE - SUB を一般化した高レベルのアクティベーション状態。

SUB - 低レベルのユニットのアクティブ化状態。可能な値の範囲は、ユニットタイプによって異なります。

DESCRIPTION - ユニットのコンテンツおよび機能の説明。

非アクティブなユニットの一覧を表示するには、次のコマンドを実行します。

# systemctl --all

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

# systemctl --type service,masked

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


systemd、ユニットファイル、および systemd ユニットタイプの完全な一覧の詳細は、『基『基本的なシステム設定の構成』本的なシステム設定の構成』の関連セクションを参照してください。

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

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



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


96

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/managing-services-with-systemd_configuring-basic-system-settings

手順手順

システムの 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 階層全体を返します。

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

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

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

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

# systemctl status example.service● example.service - My example service Loaded: loaded (/usr/lib/systemd/system/example.service; enabled; vendor preset:


97

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 1Apr 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 2019Apr 16 12:12:40 redhat bash[17737]: The current time is Tue Apr 16 12:12:40 CEST 2019


リソースコントローラーの詳細は、「Linux カーネルリソースコントローラーとは」セクションと、man ページの systemd.resource-control(5) および cgroups(7) を参照してください。

9.6.3. リソースコントローラーの表示

以下の手順では、どのプロセスがどのリソースコントローラーを使用しているかを確認する方法を説明します。


「Linux カーネルリソースコントローラーとは」


手順手順

1. プロセスが対話するリソースコントローラーを表示するには、# cat proc/<PID>/cgroup コマンドを実行します。

# cat /proc/11269/cgroup12:freezer:/11:cpuset:/10:devices:/system.slice9:memory:/system.slice/example.service8:pids:/system.slice/example.service7: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 ユニットファイルの仕様で定義される適切なコントロールグループにプロセスが置かれているかどうかを判断できます。

注記注記


98

注記注記

デフォルトでは、デフォルトのリソースコントローラーがすべて自動的にマウントされるため、リソースコントローラーの一覧にある項目とその順序は、systemd が起動するすべてのユニットで同じになります。


一般的なリソースコントローラーの詳細は、man ページの cgroups(7) を参照してください。

特定のリソースコントローラーの詳細は、/usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/ ディレクトリーのドキュメントを参照してください。

9.6.4. リソース消費の監視

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



「Linux カーネルリソースコントローラーとは」

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

手順手順

1. 現在実行中の 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 秒ごとに一覧が更新されます。したがって、各コントロールグループの実際のリソース使用状況に対する動的な洞察を提供します。



99


リソース使用状況の動的モニタリングの詳細は、man ページの systemd-cgtop(1) を参照してください。

9.7. 名前空間とは

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

名前空間は、グローバルリソース (マウントポイント、ネットワークデバイス、ホスト名など) を抽象化してラップします。これにより、グローバルリソースの独自の分離インスタンスを持つ名前空間内のプロセスに表示されます。名前空間を使用する最も一般的なテクノロジーの 1 つはコンテナーです。

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

プロセスのメンバーであるネームスペースを確認するには、/proc/<PID>/ns/ ディレクトリーのシンボリックリンクを確認します。

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

名前空間名前空間分離分離

Mount マウントポイント

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

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

PID プロセス ID

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

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

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


名前空間の詳細は、namespace(7) および cgroup_namespaces (7) manページを参照してください。

cgroups の詳細は、「コントロールグループについて」を参照してください。

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


100

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

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

10.1. BCC の概要

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

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

注記注記

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


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

10.2. BCC-TOOLS パッケージのインストール

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


アクティブな Red Hat Enterprise Linux サブスクリプションサブスクリプション

bcc-tools パッケージを含む有効なリポジトリー有効なリポジトリー

yum パッケージマネージャーパッケージマネージャーの導入

更新済みのカーネル

手順手順

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

# yum install bcc-tools

インストールが完了すると、ツールは /usr/share/bcc/tools/ ディレクトリーに置かれます。

2. 必要に応じて、ツールを検証します。

# ll /usr/share/bcc/tools/

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

101

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#basics-registering-managing-subscriptions

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#basics-installing-software

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/index#installing-software-with-yum

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/updating-kernel-with-yum_managing-monitoring-and-updating-the-kernel#updating-the-kernel_updating-kernel-with-yum

...-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.cdrwxr-xr-x. 3 root root 8192 Mar 11 10:28 doc-rwxr-xr-x. 1 root root 7588 Dec 14 17:53 execsnoop-rwxr-xr-x. 1 root root 6373 Dec 14 17:53 ext4dist-rwxr-xr-x. 1 root root 10401 Dec 14 17:53 ext4slower...

上記の一覧にある doc ディレクトリーには、各ツールのドキュメントが含まれます。

10.3. BCC-TOOLS でパフォーマンスの分析

このセクションでは、BPF コンパイラーコレクション (BCC) ライブラリーから特定の事前作成されたプログラムを使用して、イベントごとにシステムパフォーマンスを効率的かつ安全に分析する方法を説明します。BCC ライブラリーで事前作成されたプログラムセットは、追加プログラム作成の例として使用できます。


BCC の概要

インストールされている BCC ライブラリー

root 権限

execsnoop を使用したシステムプロセスの検証を使用したシステムプロセスの検証

1. ある端末で execsnoop プログラムを実行します。

# /usr/share/bcc/tools/execsnoop

2. 別の端末で、以下のように実行します。

$ ls /usr/share/bcc/tools/doc/

これにより、ls コマンドの短命プロセスが作成されます。

3. execsnoop を実行しているターミナルは、以下のような出力を表示します。

PCOMM PID PPID RET ARGSls 8382 8287 0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/sed 8385 8383 0 /usr/bin/sed s/^ *[0-9]\+ *//...

execsnoop プログラムは、新しいプロセスごとに出力行を出力するため、システムリソースを消費します。また、ls などの非常に短期間に実行されるプログラムのプロセスを検出します。なお、ほとんどの監視ツールはそれらを登録しません。

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


102

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

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

opensnoop を使用した、コマンドにより開かれるファイルの追跡を使用した、コマンドにより開かれるファイルの追跡

1. ある端末で opensnoop プログラムを実行します。

# /usr/share/bcc/tools/opensnoop -n uname

上記の出力では、uname コマンドのプロセスによってのみ開かれるファイルの内容が出力されます。

2. 別の端末で、以下を実行します。

$ uname

上記のコマンドは、特定のファイルを開きます。このファイルは次のステップでキャプチャーされます。

3. opensnoop を実行しているターミナルは、以下のような出力を表示します。

PID COMM FD ERR PATH8596 uname 3 0 /etc/ld.so.cache8596 uname 3 0 /lib64/libc.so.68596 uname 3 0 /usr/lib/locale/locale-archive...

opensnoop プログラムは、システム全体で open() システム呼び出しを監視し、uname が開こうとしたファイルごとに出力行を出力します。

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

コマンドが、存在しないファイルを読み込もうとすると、FD コラムは -1 を返し、ERR コラムは関連するエラーに対応する値を出力します。その結果、opennoop は、適切に動作しないアプリケーションの特定に役立ちます。

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

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

ディスク上のディスク上の I/O 操作を調べるための操作を調べるための biotop の使用の使用

1. ある端末で biotop プログラムを実行します。

# /usr/share/bcc/tools/biotop 30

このコマンドにより、ディスク上で I/O 操作を実行する上位のプロセスを監視できます。この引数は、コマンドが 30 秒の概要を生成するようにします。

注記注記


103

注記注記

引数を指定しないと、デフォルトでは 1 秒ごとに出力画面が更新されます。

2. 別の端末では、以下のようになります。

# dd if=/dev/vda of=/dev/zero

上記のコマンドは、ローカルのハードディスクデバイスからコンテンツを読み込み、出力を /dev/zero ファイルに書き込みます。この手順では、biotop を示す特定の I/O トラフィックを生成します。

3. biotop を実行しているターミナルは、以下のような出力を表示します。

PID COMM D MAJ MIN DISK I/O Kbytes AVGms9568 dd R 252 0 vda 16294 14440636.0 3.6948 kswapd0 W 252 0 vda 1763 120696.0 1.657571 gnome-shell R 252 0 vda 834 83612.0 0.331891 gnome-shell R 252 0 vda 1379 19792.0 0.157515 Xorg R 252 0 vda 280 9940.0 0.287579 llvmpipe-1 R 252 0 vda 228 6928.0 0.199515 gnome-control-c R 252 0 vda 62 6444.0 0.438112 gnome-terminal- R 252 0 vda 67 2572.0 1.547807 gnome-software R 252 0 vda 31 2336.0 0.739578 awk R 252 0 vda 17 2228.0 0.667578 llvmpipe-0 R 252 0 vda 156 2204.0 0.079581 pgrep R 252 0 vda 58 1748.0 0.427531 InputThread R 252 0 vda 30 1200.0 0.487504 gdbus R 252 0 vda 3 1164.0 0.301983 llvmpipe-1 R 252 0 vda 39 724.0 0.081982 llvmpipe-0 R 252 0 vda 36 652.0 0.06...

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

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 よりも遅い操作のみが表示されます。

注記注記


104

注記注記

引数を指定しないと、xfsslower はデフォルトで 10 ms よりも低速な操作を表示します。

2. 別の端末で、たとえば以下を実行します。

$ vim text

上記のコマンドは、vim エディターでテキストファイルを作成し、XFS ファイルシステムと特定の対話を開始します。

3. xfsslower を実行している端末は、前の手順でファイルを保存した場合と同様の内容を示しています。

TIME COMM PID T BYTES OFF_KB LAT(ms) FILENAME13:07:14 b'bash' 4754 R 256 0 7.11 b'vim'13:07:14 b'vim' 4754 R 832 0 4.03 b'libgpm.so.2.1.0'13:07:14 b'vim' 4754 R 32 20 1.04 b'libgpm.so.2.1.0'13:07:14 b'vim' 4754 R 1982 0 2.30 b'vimrc'13:07:14 b'vim' 4754 R 1393 0 2.52 b'getscriptPlugin.vim'13:07:45 b'vim' 4754 S 0 0 6.71 b'text'13:07:45 b'pool' 2588 R 16 0 5.58 b'text'...

上記の各行はファイルシステム内の操作を表し、特定のしきい値よりも時間がかかります。xfsslower は、ファイルシステムの問題の明確化に適しており、動作が予期せずに低速になります。

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

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

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


105

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

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

整合性サブシステムは、システム全体のデータ整合性を維持する責任があるカーネルの一部です。このサブシステムを使用すると、特定のシステムの状態を、それが構築された時と同一の状態に保つのに役立ちます。これにより、ユーザーが特定のシステムファイルに望ましくない変更を行うことを防ぐことができます。

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

完全性測定アーキテクチャー完全性測定アーキテクチャー (IMA)

ファイルのコンテンツを実行または開くたびに測定します。カスタムポリシーを適用すると、この動作を変更できます。

測定された値をカーネルのメモリー領域に置くと、システムのユーザーが変更できなくなります。

ローカルおよびリモートで測定された値を検証できるようにします。

拡張検証モジュール拡張検証モジュール (EVM)

IMA 測定や SELinux 属性などのシステムのセキュリティーに関連するファイルの拡張属性(xattr とも呼ばれます) を、対応する値を暗号でハッシュ化して保護します。

IMA および EVM には、追加機能を提供する多くの機能拡張も含まれています。以下に例を示します。

IMA 評価評価

カーネルメモリー内の測定ファイルに保存されていた値に対して、現在のファイルの内容のローカル検証を提供します。この拡張機能は、現在と以前の測定が一致しない場合に、特定のファイルで操作が実行されるのを禁止します。

EVM デジタル署名デジタル署名

カーネルのキーリングに保存される暗号鍵により、デジタル署名を使用できるようにします。

注記注記

機能拡張は相互に補完し合いますが、相互に独立して設定して使用できます。

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


106

乱数ジェネレーター

暗号化キーのジェネレーターと安全なストレージ

ハッシュジェネレーター

リモート認証


カーネル整合性サブシステムの詳細は、公式のアップストリーム公式のアップストリーム wiki ページページを参照してください。

TPM の詳細は、「「Trusted Computing Group resources」」を参照してください。

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

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

11.3. 拡張検証モジュール

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

RHEL 8 は、evm-key キーリング下で特別な暗号化された鍵を受け入れます。この鍵は、カーネルキーリングに保持されるマスターキーマスターキーにより作成されています。

11.4. 信頼できる鍵および暗号化された鍵

以下のセクションでは、システムセキュリティーを強化する重要な部分として、信頼できる鍵と暗号化された鍵を紹介します。

信頼できる信頼できる鍵と暗号化された暗号化された鍵は、カーネルキーリングサービスを使用するカーネルが生成する可変長の対称鍵です。このタイプの鍵は、暗号化されていない形式ではユーザー空間に表示されないため、その整合性を検証できます。つまり、たとえば、拡張検証モジュール (EVM) で、実行中のシステムの整合性を検証および確認するのに使用できることを意味します。ユーザーレベルのプログラムは、暗号化されたブロブブロブの形式でのみ鍵にアクセスできます。

信頼できる鍵には、TPM (Trusted Platform Module) チップというハードウェアコンポーネントが必要です。これは、鍵の作成と暗号化 (保護) の両方に使用されます。TPM は、ストレージルートキーストレージルートキー(SRK) と呼ばれる 2048 ビットの RSA 鍵を使用して鍵を保護します。

注記注記

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

107

https://sourceforge.net/p/linux-ima/wiki/Home/

https://trustedcomputinggroup.org/resource/tpm-library-specification/

注記注記

TPM 1.2 仕様を使用するには、マシンファームウェアの設定、またはユーティリティーのtpm-tools パッケージの tpm_setactive コマンドを使用して、この仕様を有効にしてアクティブにします。また、TrouSers ソフトウェアスタックがインストールされ、tcsdデーモンを実行して TPM (専用のハードウェア) と通信する必要があります。tcsd デーモンは TrouSers スイートの一部で、trousers パッケージから入手できます。より新しい、後方互換性のない TPM 2.0 は、tpm2-tools ユーティリティーまたは ibm-tss ユーティリティーが専用ハードウェアへのアクセスを提供する別のソフトウェアスタックを使用します。

さらに、ユーザーは TPM の platform configuration register (PCR) 値の特定セットで信頼できる鍵を保護できます。PCR には、ファームウェア、ブートローダー、およびオペレーティングシステムを反映する整合性管理値のセットが含まれます。つまり、PCR で保護された鍵は、暗号化されているシステムと同じシステムにある TPM によってのみ復号できます。ただし、PCR で保護された信頼できる鍵が読み込まれると (キーリングに追加されると)、関連する PCR 値が検証され、新しい (または将来の) PCR値で更新されるため、たとえば新しいカーネルを起動できます。1 つの鍵を複数のブロブとして保存することもできますが、それぞれ PCR 値が異なります。

暗号化された鍵は、カーネルの AES (Advanced Encryption Standard) を使用するため、TPM を必要としません。これにより、信頼できる鍵よりも高速になります。暗号化された鍵は、カーネルが生成した乱数を使用して作成され、ユーザー空間のブロブにエクスポートされる際にマスターキーマスターキーにより暗号化されます。マスターキーは信頼できる鍵か、ユーザーキーのいずれかです。マスターキーが信頼されていない場合、暗号化された鍵のセキュリティーは、暗号化に使用されたユーザーキーと同じように保護されます。

11.4.1. 信頼できる鍵での作業

次のセクションでは、keyctl ユーティリティーを使用して信頼できる鍵を作成、エクスポート、読み込み、または更新して、システムセキュリティーを強化する方法を説明します。


64 ビット ARM アーキテクチャーおよび IBM Z の場合は、信頼できる信頼できるカーネルモジュールを読み込む必要があります。カーネルモジュールを読み込む方法は3章カーネルモジュールの管理を参照してください。

Trusted Platform Module (TPM) を有効にしてアクティブにする必要があります。TPM の詳細は、] and xref:trusted-and-encrypted-keys_enhancing-security-with-the-kernel-integrity-subsystem[を参照してください。

手順手順

1. TPM を使用して信頼できる鍵を作成するには、次のコマンドを実行します。

# keyctl add trusted <name> "new <key_length> [options]" <key_ring>

構文に基づいて、以下のようにサンプルコマンドを作成します。

# keyctl add trusted kmk "new 32" @u642500861

このコマンドは、kmk という名前の信頼できる鍵を 32 バイト (256 ビット) の長さで作成し、ユーザーキーリング (@u) に置きます。鍵の長さは 32 から 128 バイト (256 から 1024ビット) です。


108

2. カーネルキーリングの現在の構造を一覧表示するには、以下を実行します。

# keyctl showSession Keyring -3 --alswrv 500 500 keyring: ses 97833714 --alswrv 500 -1 \ keyring: uid.1000 642500861 --alswrv 500 500 \ trusted: kmk

3. ユーザー空間のブロブに鍵をエクスポートするには、次のコマンドを実行します。

# keyctl pipe 642500861 > kmk.blob

このコマンドは、pipe サブコマンドと kmk のシリアル番号を使用します。

4. ユーザー空間のブロブから信頼できる鍵を読み込むには、ブログを引数として add サブコマンドを使用します。

# keyctl add trusted kmk "load `cat kmk.blob`" @u268728824

5. TPM で保護された信頼できる鍵に基づいて、安全な暗号化された鍵を作成します。

# keyctl add encrypted <name> "new [format] <key_type>:<master_key_name> <keylength>" <key_ring>

構文に基づいて、すでに作成された信頼できる鍵を使用して暗号化された鍵を生成します。

# keyctl add encrypted encr-key "new trusted:kmk 32" @u159771175

このコマンドは、前の手順で生成した TPM で保護された信頼できる鍵 (kmk) を、暗号化された鍵を生成するマスターキーマスターキーとして使用します。


keyctl の使用方法は、man ページの keyctl(1) を参照してください。

信頼できる鍵および暗号化された鍵の詳細は、「信頼できる鍵および暗号化された鍵」を参照してください。

カーネルキーリングサービスの詳細は、アップストリームのカーネルドキュメントを参照してください。

TPM の詳細は、「カーネル整合性サブシステム」を参照してください。

11.4.2. 暗号化された鍵での作業

次のセクションでは、TPM (Trusted Platform Module) が利用できないシステムでシステムセキュリティーを強化するために暗号化された鍵を管理する方法を説明します。


64 ビット ARM アーキテクチャーおよび IBM Z の場合は、encrypted-keys カーネルモジュー


109

https://www.kernel.org/doc/html/v4.18/security/keys/core.html#

64 ビット ARM アーキテクチャーおよび IBM Z の場合は、encrypted-keys カーネルモジュールを読み込む必要があります。カーネルモジュールを読み込む方法は3章カーネルモジュールの管理を参照してください。

手順手順

1. 無作為に数列を使用してユーザーキーを生成します。

# keyctl add user kmk-user “dd if=/dev/urandom bs=1 count=32 2>/dev/null” @u427069434

このコマンドは、マスターキーマスターキーとして動作する kmk-user という名前のユーザーキーを生成し、実際の暗号化された鍵を保護するために使用されます。

2. 直前の手順のマスターキーを使用して、暗号化されたキーを生成します。

# keyctl add encrypted encr-key "new user:kmk-user 32" @u1012412758

3. 必要に応じて、指定したユーザーキーリングにあるすべての鍵を一覧表示します。

# keyctl list @u2 keys in keyring:427069434: --alswrv 1000 1000 user: kmk-user1012412758: --alswrv 1000 1000 encrypted: encr-key

重要重要

マスターの信頼できる鍵で保護されていない、暗号化された鍵のセキュリティーは、暗号化に使用されたユーザーマスターキー (乱数キー) と同じぐらい安全であることに注意してください。そのため、マスターユーザーキーはできるだけ安全に、システムの起動プロセスの早い段階で読み込む必要があります。


keyctl の使用方法は、man ページの keyctl(1) を参照してください。

カーネルキーリングサービスの詳細は、アップストリームのカーネルドキュメントを参照してください。

11.5. 整合性測定アーキテクチャーおよび拡張検証モジュールの有効化

整合性測定アーキテクチャー (IMA) および拡張検証モジュール (EVM) は、カーネル整合性サブシステムに属し、さまざまな方法でシステムセキュリティーを強化します。次のセクションでは、IMA およびEVM を有効にして設定し、オペレーティングシステムのセキュリティーを強化する方法を説明します。


securityfs ファイルシステムが /sys/kernel/security/ ディレクトリーにマウントされており、/sys/kernel/security/integrity/ima/ ディレクトリーが存在することを確認します。

# mount…


110

https://www.kernel.org/doc/html/v4.18/security/keys/core.html#

securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)…

systemd サービスマネージャーに、システムの起動時に IMA および EVM に対応するパッチがすでに適用されていることを確認します。

# dmesg | grep -i -e EVM -e IMA[ 0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet[ 0.000000] kvm-clock: cpu 0, msr 23601001, primary cpu clock[ 0.000000] Using crashkernel=auto, the size chosen is a best effort estimation.[ 0.000000] Kernel command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet[ 0.911527] ima: No TPM chip found, activating TPM-bypass![ 0.911538] ima: Allocated hash algorithm: sha1[ 0.911580] evm: Initialising EVM extended attributes:[ 0.911581] evm: security.selinux[ 0.911581] evm: security.ima[ 0.911582] evm: security.capability[ 0.911582] evm: HMAC attrs: 0x1[ 1.715151] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy)[ 3.824198] fbcon: qxldrmfb (fb0) is primary device[ 4.673457] PM: Image not found (code -22)[ 6.549966] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy)

手順手順

1. 以下のカーネルコマンドラインパラメーターを追加します。

# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="ima_policy=appraise_tcb ima_appraise=fix evm=fix"

このコマンドは、現在のブートエントリーの fix モードで IMA および EVM を有効にし、ユーザーが IMA 測定を収集し、更新できるようにします。

ima_policy=appraise_tcb カーネルコマンドラインパラメーターにより、カーネルは、デフォルトの TCB (Trusted Computing Base) 測定ポリシーと評価手順を使用するようになります。評価部分は、以前の測定と現在の測定が一致しないファイルへのアクセスを禁止します。

2. 再起動して変更を適用します。

3. 必要に応じて、パラメーターがカーネルコマンドラインに追加されていることを確認します。

# cat /proc/cmdlineBOOT_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


111

4. EVM 鍵を保護するカーネルマスターキーを作成します。

# keyctl add user kmk dd if=/dev/urandom bs=1 count=32 2> /dev/null @u748544121

カーネルマスターキー (kmk) は完全にカーネル領域メモリーに保持されます。カーネルマスターキーの kmk の 32 バイトの long 型の値は、 /dev/urandom ファイルの無作為バイトから生成され、ユーザー (@u) キーリングに置かれます。キーのシリアル番号は、前の出力の 2 行目にあります。

5. kmk 鍵に基づいて暗号化された EVM 鍵を作成します。

# keyctl add encrypted evm-key "new user:kmk 64" @u641780271

kmk を使用して 64 バイトの long 型ユーザーキー ( evm-key) を生成し、これをユーザー (@u)のキーリングに配置します。キーのシリアル番号は、前の出力の 2 行目にあります。

重要重要

ユーザーキーの名前は evm-key (EVM サブシステムが想定し、使用している名前) にする必要があります。

6. エクスポートする鍵のディレクトリーを作成します。

# mkdir -p /etc/keys/

7. kmk 鍵を検索し、その値をファイルにエクスポートします。

# keyctl pipe keyctl search @u user kmk > /etc/keys/kmk

このコマンドは、カーネルマスターキー (kmk) の非暗号化値を、以前に定義した場所のファイル (/etc/keys/) に置かれます。

8. ユーザーキー evm-key を検索し、その値をファイルにエクスポートします。

# keyctl pipe keyctl search @u encrypted evm-key > /etc/keys/evm-key

このコマンドは、ユーザーの evm-key 鍵の暗号化された値を、任意の場所のファイルに追加します。evm-key は、すでにカーネルのマスターキーにより暗号化されています。

9. 必要に応じて、新規作成されたキーを表示します。

# keyctl showSession Keyring974575405 --alswrv 0 0 keyring: ses 299489774 --alswrv 0 65534 \ keyring: uid.0 748544121 --alswrv 0 0 \ user: kmk641780271 --alswrv 0 0 \_ encrypted: evm-key

同様の出力が表示されるはずです。

10. EVM をアクティベートします。

# echo 1 > /sys/kernel/security/evm


112

11. 必要に応じて、EVM が初期化されていることを確認します。

# dmesg | tail -1[… ] evm: key initialized


カーネル整合性サブシステムの詳細は、「カーネル整合性サブシステム」を参照してください。

IMA (Integrity Measurement Architecture) の詳細は、「完全性測定アーキテクチャー」を参照してください。

拡張検証モジュールの詳細は、「拡張検証モジュール」を参照してください。

暗号化された鍵の作成方法は、「信頼できる鍵および暗号化された鍵」を参照してください。

11.6. 整合性測定アーキテクチャーでファイルハッシュの収集

整合性測定アーキテクチャー (IMA) の最初のレベルの操作は測定測定フェーズで、ファイルハッシュを作成し、これらのファイルの拡張属性 (xattrs) として保存します。次のセクションでは、ファイルのハッシュを作成および検査する方法を説明します。


「整合性測定アーキテクチャーおよび拡張検証モジュールの有効化」の説明に従って、整合性測定アーキテクチャー (IMA) および拡張検証モジュール (EVM) を有効にします。

ima-evm-utils、attr、および keyutils パッケージがすでにインストールされていることを確認します。

# yum install ima-evm-utils attr keyutilsUpdating Subscription Management repositories.This system is registered to Red Hat Subscription Management, but is not receiving updates. You can use subscription-manager to assign subscriptions.Last metadata expiration check: 0:58:22 ago on Fri 14 Feb 2020 09:58:23 AM CET.Package ima-evm-utils-1.1-5.el8.x86_64 is already installed.Package attr-2.4.48-3.el8.x86_64 is already installed.Package keyutils-1.5.10-7.el8.x86_64 is already installed.Dependencies resolved.Nothing to do.Complete!

手順手順

1. テストファイルを作成します。

# echo <Test_text> > test_file

IMA および EVM には、サンプルファイル test_file にハッシュ値が割り当てられ、拡張属性として保存されます。

2. ファイルの拡張属性を検証します。


113

# getfattr -m . -d test_file# file: test_filesecurity.evm=0sAnDIy4VPA0HArpPO/EqiutnNyBqlsecurity.ima=0sAQOEDeuUnWzwwKYk+n66h/vby3eDsecurity.selinux="unconfined_u:object_r:admin_home_t:s0"

上記の出力例では、SELinux、IMA ハッシュ値、および EVM ハッシュ値に関連する拡張属性を示しています。EVM は、security.evm 拡張属性をアクティブに追加し、ファイルのコンテンツの整合性に直接関連する security.ima などの他のファイルの xattrs に対するオフライン改ざんを検出します。security.evm フィールドの値は、evm-key ユーザーキーで生成された Hash-based Message Authentication Code (HMAC-SHA1) になります。


Red Hat Enterprise Linux 8 の一般的なセキュリティー概念の詳細は、『セキュリティー強『セキュリティー強化』化』の関連セクションを参照してください。

Integrity Measurement Architecture の詳細は、「完全性測定アーキテクチャー」を参照してください。

拡張検証モジュールの詳細は、「拡張検証モジュール」を参照してください。

11.7. 関連情報

Red Hat Enterprise Linux 8 の一般的なセキュリティー概念の詳細は、『セキュリティー強『セキュリティー強化』化』の関連セクションを参照してください。

IMA および EVM の詳細は、公式のアップストリーム公式のアップストリーム wiki ページページを参照してください。

「SELinux (Security-Enhanced Linux) の基本設定および高度な設定」では、SELinux の基本原則と、SELinux を Apache HTTP Server などのさまざまなサービスで設定および使用する方法を説明します。


114

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/security_hardening/index

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/security_hardening/index

https://sourceforge.net/p/linux-ima/wiki/Home/

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/using_selinux/index

Documents

Red Hat Enterprise Linux 8 カーネルの管理、監視、 …...kernel-core - コア機能に必要な最小数のカーネルモジュールが含まれます。このサブパッケー