流程

1. 要更新内核，请输入以下命令：

   # yum update kernel

   此命令将内核以及所有依赖项更新至最新可用版本。

2. 重启您的系统以使更改生效。

流程

1. 选择您要载入的内核模块。

   模块位于 /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ 目录中。

2. 载入相关内核模块：

   # modprobe <MODULE_NAME>

   注意

   在输入内核模块的名称时，不要将 .ko.xz 扩展附加到名称的末尾。内核模块名称没有扩展名，它们对应的文件有。

3. （可选）验证载入了相关模块：

   $ lsmod | grep <MODULE_NAME>

   如果正确加载了模块，这个命令会显示相关的内核模块。例如：

   $ lsmod | grep serio_raw
   serio_raw              16384  0

流程

1. 输入 lsmod 命令并选择您要卸载的内核模块。

   如果内核模块有依赖项，请在卸载内核模块前卸载它们。有关识别带有依赖项的模块的详情，请参阅 列出当前载入的内核模块 和 内核模块依赖项。

2. 卸载相关内核模块：

   # modprobe -r <MODULE_NAME>

   在输入内核模块的名称时，不要将 .ko.xz 扩展附加到名称的末尾。内核模块名称没有扩展名，它们对应的文件有。

   警告

   当它们被正在运行的系统使用时，不要卸载这些内核模块。这样做可能会导致不稳定，或系统无法正常操作。

3. （可选）验证相关模块是否已卸载：

   $ lsmod | grep <MODULE_NAME>

   如果模块被成功卸载，这个命令不会显示任何输出。

流程

1. 选择您要在引导过程中载入的内核模块。

   模块位于 /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ 目录中。

2. 为模块创建配置文件：

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

   注意

   在输入内核模块的名称时，不要将 .ko.xz 扩展附加到名称的末尾。内核模块名称没有扩展名，它们对应的文件有。

3. 另外，重启后，验证载入了相关模块：

   $ lsmod | grep <MODULE_NAME>

   上面的示例命令应该成功并显示相关的内核模块。

流程

1. 使用 lsmod 命令列出载入到当前运行的内核中的模块：

   $ lsmod
   Module                  Size  Used by
   tls                   131072  0
   uinput                 20480  1
   snd_seq_dummy          16384  0
   snd_hrtimer            16384  1
   …

   在输出中，识别您要防止被加载的模块。

   • 或者，识别您要防止在 /lib/modules/<KERNEL-VERSION>/kernel/<SUBSYSTEM>/ 目录中加载的而未加载的内核模块，例如：

     $ ls /lib/modules/4.18.0-477.20.1.el8_8.x86_64/kernel/crypto/
     ansi_cprng.ko.xz        chacha20poly1305.ko.xz  md4.ko.xz               serpent_generic.ko.xz
     anubis.ko.xz            cmac.ko.xz…

2. 创建一个作为 denylist 的配置文件：

   # touch /etc/modprobe.d/denylist.conf

3. 在您选择的文本编辑器中，将您要从自动加载中排除的模块名称与使用 blacklist 配置命令列出的模块名称结合在一起，例如：

   # Prevents <KERNEL-MODULE-1> from being loaded
   blacklist <MODULE-NAME-1>
   install <MODULE-NAME-1> /bin/false
   
   # Prevents <KERNEL-MODULE-2> from being loaded
   blacklist <MODULE-NAME-2>
   install <MODULE-NAME-2> /bin/false
   …

   由于 blacklist 命令不会阻止将模块作为不在 denylist 中的另一个内核模块的依赖项加载，所以您还必须定义 install 行。在这种情况下，系统运行 /bin/false，而不是安装模块。以哈希符号开头的行是注释，可用来使文件更易读。

   注意

   在输入内核模块的名称时，不要将 .ko.xz 扩展附加到名称的末尾。内核模块名称没有扩展名，它们对应的文件有。

4. 在重建前，创建当前初始 RAM 磁盘镜像的一个备份副本：

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

   • 或者，创建初始 RAM 磁盘镜像的一个备份副本，该镜像对应于您要阻止内核模块自动载入的内核版本：

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

5. 生成一个新的初始 RAM 磁盘镜像以应用更改：

   # dracut -f -v

   • 如果您为系统当前使用的内核版本之外的版本构建初始 RAM 磁盘镜像，请指定目标 initramfs 和内核版本：

     # dracut -f -v /boot/initramfs-<TARGET-VERSION>.img <CORRESPONDING-TARGET-KERNEL-VERSION>

6. 重启系统：

   $ reboot

流程

1. 创建包含以下内容的 /root/testmodule/test.c 文件：

   #include <linux/module.h>
   #include <linux/kernel.h>
   
   int init_module(void)
       { printk("Hello World\n This is a test\n"); return 0; }
   
   void cleanup_module(void)
       { printk("Good Bye World"); }

   test.c 文件是一个源文件，其向内核模块提供主要功能。出于组织需要，该文件已创建在专用的 /root/testmodule/ 目录中。在模块编译后，/root/testmodule/ 目录将包含多个文件。

   test.c 文件包含来自系统库的文件：

   • 示例代码中的 printk（） 函数需要 linux/kernel.h 头文件。

   • linux/module.h 文件包含可在用 C 编程语言编写的多个源文件之间共享的函数声明和宏定义。

     接下来按照 init_module（） 和 cleanup_module（） 函数来启动和结束内核日志记录函数 printk（），其将打印文本。

2. 使用以下内容创建 /root/testmodule/Makefile 文件。

   obj-m := test.o

   Makefile 包含编译器必须生成一个具体名为 test.o 的对象文件的指令。obj-m 指令指定生成的 test.ko 文件将编译为可加载的内核模块。或者，obj-y 指令会指示将 test.ko 构建为一个内置内核模块。

3. 编译内核模块。

   # make -C /lib/modules/$(uname -r)/build M=/root/testmodule modules
   make: Entering directory '/usr/src/kernels/4.18.0-305.el8.x86_64'
     CC [M]  /root/testmodule/test.o
     Building modules, stage 2.
     MODPOST 1 modules
   WARNING: modpost: missing MODULE_LICENSE() in /root/testmodule/test.o
   see include/linux/module.h for more information
     CC      /root/testmodule/test.mod.o
     LD [M]  /root/testmodule/test.ko
   make: Leaving directory '/usr/src/kernels/4.18.0-305.el8.x86_64'

   编译器将它们链接成最终内核模块(test.ko)之前，会为每个源文件(test.c)创建一个对象文件(test.c)来作为中间步骤。

   成功编译后，/root/testmodule/ 包含与编译的自定义内核模块相关的其他文件。已编译的模块本身由 test.ko 文件表示。

验证

1. 可选：检查 /root/testmodule/ 目录的内容：

   # ls -l /root/testmodule/
   total 152
   -rw-r—​r--. 1 root root    16 Jul 26 08:19 Makefile
   -rw-r—​r--. 1 root root    25 Jul 26 08:20 modules.order
   -rw-r—​r--. 1 root root     0 Jul 26 08:20 Module.symvers
   -rw-r—​r--. 1 root root   224 Jul 26 08:18 test.c
   -rw-r—​r--. 1 root root 62176 Jul 26 08:20 test.ko
   -rw-r—​r--. 1 root root    25 Jul 26 08:20 test.mod
   -rw-r—​r--. 1 root root   849 Jul 26 08:20 test.mod.c
   -rw-r—​r--. 1 root root 50936 Jul 26 08:20 test.mod.o
   -rw-r—​r--. 1 root root 12912 Jul 26 08:20 test.o

2. 将内核模块复制到 /lib/modules/$(uname -r)/ 目录中：

   # cp /root/testmodule/test.ko /lib/modules/$(uname -r)/

3. 更新模块依赖项列表：

   # depmod -a

4. 载入内核模块：

   # modprobe -v test
   insmod /lib/modules/4.18.0-305.el8.x86_64/test.ko

5. 验证内核模块是否成功载入：

   # lsmod | grep test
   test                   16384  0

6. 从内核环缓冲中读取最新的消息：

   # dmesg
   [74422.545004] Hello World
                   This is a test

流程

1. 将您的公钥导出到 sb_cert.cer 文件中：

   # certutil -d /etc/pki/pesign \
              -n 'Custom Secure Boot key' \
              -Lr \
              > sb_cert.cer

2. 将您的公钥导入到 MOK 列表中：

   # mokutil --import sb_cert.cer

3. 输入此 MOK 注册请求的新密码。

4. 重启机器。

   shim 引导装载程序会注意到待处理的 MOK 密钥注册请求，并启动 MokManager.efi，以使您从 UEFI 控制台完成注册。

5. 选择 Enroll MOK，在提示时输入之前与此请求关联的密码，并确认注册。

   您的公钥已添加到 MOK 列表中，这是永久的。

   密钥位于 MOK 列表中后，它将会在启用 UEFI 安全引导时自动将其传播到此列表上的 .platform 密钥环中。

流程

1. 将您的公钥导出到 sb_cert.cer 文件中：

   # certutil -d /etc/pki/pesign \
              -n 'Custom Secure Boot key' \
              -Lr \
              > sb_cert.cer

2. 从 NSS 数据库中提取密钥作为 PKCS #12 文件：

   # pk12util -o sb_cert.p12 \
              -n 'Custom Secure Boot key' \
              -d /etc/pki/pesign

3. 当上一命令提示您时，输入加密了私钥的新密码。

4. 导出未加密的私钥：

   # openssl pkcs12 \
            -in sb_cert.p12 \
            -out sb_cert.priv \
            -nocerts \
            -nodes

   重要

   请谨慎处理未加密的私钥。

5. 为内核模块签名。以下命令将签名直接附加到内核模块文件中的 ELF 镜像中：

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

验证

1. 显示关于内核模块签名的信息：

   # modinfo my_module.ko | grep signer
     signer:         Your Name Key

   检查签名中是否列出了您在生成过程中输入的名称。

   注意

   附加的签名不包含在 ELF 镜像部分，不是 ELF 镜像的一个正式部分。因此，readelf 等工具无法在内核模块上显示签名。

2. 载入模块：

   # insmod my_module.ko

3. 删除（未加载）模块：

   # modprobe -r my_module.ko

流程

1. 验证您的公钥是否在系统密钥环中：

   # keyctl list %:.platform

2. 将内核模块复制到您想要的内核的 extra/ 目录中：

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

3. 更新模块依赖项列表：

   # depmod -a

4. 载入内核模块：

   # modprobe -v my_module

5. 另外，要在引导时载入模块，将其添加到 /etc/modules-loaded.d/my_module.conf 文件中：

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

流程

1. 当显示 GRUB 2 引导菜单时，选择要启动的内核，然后按 e 键编辑内核参数。
2. 通过向下引动光标来找到内核命令行。在 64 位 IBM Power 系列和基于 x86-64 BIOS 的系统上内核命令行以 linux 开头，或在 UEFI 系统上以 linuxefi 开头。

3. 将光标移至行尾。

   注意

   按 Ctrl+a 跳到行首，按 Ctrl+e 跳到行尾。在某些系统上，Home 和 End 键也可能会正常工作。

4. 根据需要编辑内核参数。例如，要在紧急模式下运行系统，请在 linux 行的末尾添加 emergency 参数：

   linux   ($root)/vmlinuz-4.18.0-348.12.2.el8_5.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet emergency

   要启用系统消息，请删除 rhgb 和 quiet 参数。

5. 按 Ctrl+x 来使用选定的内核和修改的命令行参数启动。

流程

1. 将下面两行添加到 /etc/default/grub 文件中：

   GRUB_TERMINAL="serial"
   GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"

   第一行将禁用图形终端。GRUB_TERMINAL 键覆盖 GRUB_TERMINAL_INPUT 和 GRUB_TERMINAL_OUTPUT 键的值。

   第二行调整了波特率(--speed)，奇偶校验和其他值以适合您的环境和硬件。请注意，对于以下日志文件等任务，最好使用更高的波特率，如 115200。

2. 更新 GRUB 配置文件。

   • 在基于 BIOS 的机器上：

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

   • 在基于 UEFI 的机器上：

     # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

3. 重启系统以使更改生效。

流程

1. 列出所有参数及其值。

   # sysctl -a

   注意

   # sysctl -a 命令显示内核参数，可在运行时和系统启动时调整。

2. 要临时配置一个参数，请输入：

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

   上面的示例命令在系统运行时更改了参数值。更改将立即生效，无需重新启动。

   注意

   在系统重启后，所在的改变会返回到默认状态。

流程

1. 列出所有参数。

   # sysctl -a

   该命令显示所有可在运行时配置的内核参数。

2. 永久配置一个参数：

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

   示例命令会更改可调值，并将其写入 /etc/sysctl.conf 文件，该文件会覆盖内核参数的默认值。更改会立即并永久生效，无需重启。

流程

1. 在 /etc/sysctl.d/ 中创建一个新配置文件。

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

2. 包括内核参数，一行一个。

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

3. 保存配置文件。

4. 重启机器以使更改生效。

   • 或者，要在不重启的情况下应用更改，请输入：

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

     该命令允许您从之前创建的配置文件中读取值。

流程

1. 确定您要配置的内核参数。

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

   命令返回的可写入文件可以用来配置内核。具有只读权限的文件提供了对当前设置的反馈。

2. 为内核参数分配一个目标值。

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

   命令进行配置更改，这些更改将在系统重启后消失。

3. （可选）验证新设置的内核参数的值。

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

流程

1. 在 GRUB 引导屏幕上，按 e 键进行编辑。

2. 在 linux 行末尾添加以下参数：

   systemd.unit=rescue.target

   

3. 按 Ctrl+x 引导至救援模式。

   

流程

1. 在 GRUB 引导屏幕上，按 e 键进行编辑。

2. 在 linux 行末尾添加以下参数：

   systemd.unit=emergency.target

   

3. 按 Ctrl+x 引导至紧急模式。

   

流程

1. 在 GRUB 引导屏幕上，按 e 键进行编辑。

2. 在 linux 行末尾添加以下参数：

   systemd.debug-shell

   

3. （可选）添加 debug 选项。

   注意

   向内核命令行添加 debug 选项会增加日志消息的数量。对于 systemd，内核命令行选项 debug 现在是 systemd.log_level=debug 的快捷方式。

4. 按 Ctrl+x 启动到 debug shell。

流程

1. 按 Ctrl+Alt+F9 连接到 debug shell。

   如果您使用虚拟机，发送此组合键需要虚拟化应用程序的支持。例如，如果使用 虚拟机管理器，请从菜单中选择 Send Key → Ctrl+Alt+F9。

2. debug shell 不需要身份验证，因此您可以在 TTY9 上看到类似如下的提示：

流程

1. 从安装源引导主机。

2. 在安装介质的引导菜单中，选择 Troubleshooting 选项。

   

3. 在 Troubleshooting 菜单中选择 Rescue a Red Hat Enterprise Linux system 选项。

   

4. 在 Rescue 菜单中，选择 1 ，并按 Enter 键继续。

   

5. 按如下所示更改文件系统 root ：

   sh-4.4# chroot /mnt/sysimage

   

6. 输入 passwd 命令，并按照命令行上显示的指令更改 root 密码。

   

7. 删除 autorelable 文件，以防止耗时的磁盘的 SELinux 重新标记：

   sh-4.4# rm -f /.autorelabel

8. 输入 exit 命令退出 chroot 环境。
9. 再次输入 exit 命令，以恢复初始化并完成系统启动。

流程

1. 启动系统，并在 GRUB 引导屏幕上按 e 键进行编辑。

2. 在 linux 行末尾添加 rd.break 参数：

   

3. 按 Ctrl+x 使用更改的参数引导系统。

   

4. 将文件系统重新挂载为可写。

   switch_root:/# mount -o remount,rw /sysroot

5. 更改文件系统的 root。

   switch_root:/# chroot /sysroot

6. 输入 passwd 命令，并按照命令行上显示的说明进行操作。

   

7. 在下次系统引导时重新标记所有文件。

   sh-4.4# touch /.autorelabel

8. 重新将文件系统挂载为 只读 ：

   sh-4.4# mount -o remount,ro /

9. 输入 exit 命令退出 chroot 环境。

10. 再次输入 exit 命令，以恢复初始化并完成系统启动。

    注意

    SELinux 重新标记过程可能需要很长时间。系统会在进程完成后自动重启。

流程

1. 将来自默认内核的所有内核参数复制到这个新的内核条目。

   # grubby --add-kernel=new_kernel --title="entry_title" --initrd="new_initrd" --copy-default

2. 获取可用的引导条目的列表。

   # ls -l /boot/loader/entries/*
   -rw-r--r--. 1 root root 408 May 27 06:18 /boot/loader/entries/67db13ba8cdb420794ef3ee0a8313205-0-rescue.conf
   -rw-r--r--. 1 root root 536 Jun 30 07:53 /boot/loader/entries/67db13ba8cdb420794ef3ee0a8313205-4.18.0-372.9.1.el8.x86_64.conf
   -rw-r--r--  1 root root 336 Aug 15 15:12 /boot/loader/entries/d88fa2c7ff574ae782ec8c4288de4e85-4.18.0-193.el8.x86_64.conf

3. 创建一个新的引导条目。例如，对于 4.18.0-193.el8.x86_64 内核，请按如下所示运行命令：

   # grubby --grub2 --add-kernel=/boot/vmlinuz-4.18.0-193.el8.x86_64 --title="Red Hat Enterprise 8 Test" --initrd=/boot/initramfs-4.18.0-193.el8.x86_64.img --copy-default

流程

1. 在 /etc/default/grub 文件中设置 GRUB_TIMEOUT_STYLE 选项，如下所示：

   GRUB_TIMEOUT_STYLE=hidden

2. 重建 grub.cfg 文件以使更改生效。

   • 在基于 BIOS 的机器上，输入：

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

   • 在基于 UEFI 的机器上，输入：

     # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

3. 按 Esc 键，以显示启动时可引导内核的列表。

流程

1. 通过将其索引传给 grub2-set-default 命令，来指定默认载入哪个操作系统或内核。例如：

   # grubby --set-default-index=1
   The default is /boot/loader/entries/d5151aa93c444ac89e78347a1504d6c6-4.18.0-348.el8.x86_64.conf with index 1 and kernel /boot/vmlinuz-4.18.0-348.el8.x86_64

   GRUB 支持将数字值用作 /boot/grub2/grubenv 中 saved_entry 指令的密钥，以更改载入操作系统的默认顺序。

   注意

   索引计数从零开始；因此，在上例中，GRUB 加载第二个条目。在下一个安装的内核中，索引值将被覆盖。

   注意

   您还可以使用 grubby 查找内核的索引。如需更多信息，请参阅 查看内核的 GRUB 菜单条目。

2. 可选 ：强制系统总是使用特定的菜单条目：

   1. 列出可用的菜单条目：

      # grubby --info=ALL

   2. 使用菜单条目名称或列表中的菜单条目的位置号来作为 /etc/default/grub 文件中 GRUB_DEFAULT 指令的密钥。例如：

      GRUB_DEFAULT=example-gnu-linux

3. 重建 grub.cfg 文件以使更改生效。

   • 在基于 BIOS 的机器上，输入：

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

   • 在基于 UEFI 的机器上，输入：

     # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

流程

1. 使用 device 参数发布 grub2-install 命令。例如：如果 sda 是您的设备：

   # grub2-install /dev/sda

2. 重启您的系统以使更改生效。

   # reboot

流程

1. 输入 grub2-efi 和 shim 引导装载程序文件发布 yum reinstall 命令。

   # yum reinstall grub2-efi shim

2. 重启您的系统以使更改生效。

   # reboot

流程

1. 删除配置文件。

   # rm /etc/grub.d/*
   # rm /etc/sysconfig/grub

2. 重新安装软件包。

   • 在基于 BIOS 的机器上，输入：

     # yum reinstall grub2-tools

   • 在基于 UEFI 的机器上，输入：

     # yum reinstall grub2-efi shim grub2-tools

3. 重建 grub.cfg 文件以使更改生效。

   • 在基于 BIOS 的机器上，输入：

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

   • 在基于 UEFI 的机器上，输入：

     # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

4. 按照 重新安装 GRUB 流程来在 /boot/ 分区上恢复 GRUB。

流程

1. 以 root 用户身份发出 grub2-setpassword 命令。

   # grub2-setpassword

2. 输入用户的密码，然后按 Enter 键确认密码。

   Enter password:
   Confirm the password:

流程

1. 打开您要修改 /boot/loader/entries/ 目录中的引导条目的引导加载程序规范(BLS)文件。
2. 找到以 grub_users 开头的行。此参数向 menuentry 传递额外的参数。

3. 将 grub_users 属性设置为除超级用户之外的、允许启动条目的用户名，默认情况下，此用户为 root 。下面是一个配置文件示例：

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

4. 保存并关闭 BLS 文件。

1. value.控制台日志级别，定义打印到控制台的消息的最低优先级。
2. value.消息没有显式附加日志级别的默认日志级别。
3. value.为控制台日志级别设置最低的日志级别配置。

4. value.在引导时为控制台日志级别设置默认值。

   以上每个值都定义了处理错误消息的不同规则。

流程

1. 进入 Kdump 字段。

2. 如果尚未启用，请启用 kdump。

   

3. 定义为 kdump 保留多少内存。

   

流程

1. 检查是否在系统上安装了 kdump ：

   # rpm -q kexec-tools

   如果安装了该软件包，输出：

   kexec-tools-2.0.17-11.el8.x86_64

   如果没有安装该软件包，输出：

   package kexec-tools is not installed

2. 通过以下方法安装 kdump 和其他必要的软件包：

   # dnf install kexec-tools

流程

1. 准备 crashkernel= 选项。

   • 例如：要保留 128 MB 内存，请使用：

     crashkernel=128M

   • 或者，您可以根据安装的内存总量将保留内存量设置为变量。变量中的内存保留语法为 crashkernel=<range1>:<size1>,<range2>:<size2>。例如：

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

     如果系统内存总量为 512 MB 和 2 GB，则命令保留 64 MB 内存。如果内存量超过 2 GB，则内存保留为 128 MB。

   • 保留内存的偏移。

     有些系统需要保留具有特定固定偏移量的内存，因为 crashkernel 保留在早期发生，您可能需要为特殊用途保留更多内存。当您定义了一个偏移时，保留的内存将从这个偏移位置开始。要偏移保留的内存，请使用以下语法：

     crashkernel=128M@16M

     在这个示例中，kdump 从 16 MB 开始保留 128 MB 内存（物理地址 0x01000000）。如果将偏移参数设置为 0 或完全省略，kdump 会自动偏移保留内存。在设置变量内存保留时，也可以使用此语法。在这种情况下，偏移总是指定最后一个。例如：

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

2. 将 crashkernel= 选项应用到引导装载程序配置：

   # grubby --update-kernel=ALL --args="crashkernel=<value>"

   将 <value> 替换为您在上一步中准备的 crashkernel= 选项的值。

流程

1. 以 root 用户身份，编辑 /etc/kdump.conf 配置文件并从 #core_collector makedumpfile -l --message-level 1 -d 31 的开头删除 hash 符号("#")。
2. 要启用崩溃转储文件压缩，请执行：

流程

1. 以 root 用户身份，从 /etc/kdump.conf 配置文件的 #failure_action 行的开头删除 hash 符号("#")。

2. 将值替换为所需操作。

   failure_action poweroff

流程

1. 在启用了 kdump 的情况下重启系统。

2. 检查 kdump 是否处于活跃状态。

   # systemctl is-active kdump
   active

3. 强制内核崩溃。

   echo c > /proc/sysrq-trigger

   警告

   该命令可使内核崩溃，如果需要的话，会重启内核。

   在内核重启时，address-YYYY-MM-DD-HH:MM:SS/vmcore 文件会在您在 /etc/kdump.conf 文件中指定的位置（默认为 /var/crash/）创建。

流程

1. 向所有安装的内核添加 crashkernel=auto 命令行参数：

   # grubby --update-kernel=ALL --args="crashkernel=auto"

2. 启用 kdump 服务。

   # systemctl enable --now kdump.service

流程

1. 列出安装在机器上的内核。

   # ls -a /boot/vmlinuz-*
   /boot/vmlinuz-0-rescue-2930657cd0dc43c2b75db480e5e5b4a9 /boot/vmlinuz-4.18.0-330.el8.x86_64 /boot/vmlinuz-4.18.0-330.rt7.111.el8.x86_64

2. 向系统的 Grand Unified Bootloader (GRUB)配置文件添加特定的 kdump 内核。

   例如：

   # grubby --update-kernel=vmlinuz-4.18.0-330.el8.x86_64 --args="crashkernel=auto"

3. 启用 kdump 服务。

   # systemctl enable --now kdump.service

流程

1. 要在当前会话中停止 kdump 服务：

   # systemctl stop kdump.service

2. 要禁用 kdump 服务：

   # systemctl disable kdump.service

流程

1. 在 web 控制台中，打开 Kernel Dump 选项卡，并通过将 Kernel crash dump 开关设置为 on 来启动 kdump 服务。
2. 在命令行中配置 kdump 内存使用量。

3. 在 Kernel Dump 选项卡中，转至 Crash dump location，再单击包含转储位置路径的链接。

   

4. 指定保存 vmcore 转储文件的目标目录：

   • 对于本地文件系统，从下拉菜单中选择 Local Filesystem。

     

   • 对于使用 SSH 协议的远程系统，从下拉菜单中选择 Remote over SSH ，并指定以下字段：

     • 在 Server 字段中，输入远程服务器的地址
     • 在 ssh key 字段中，输入 ssh 密钥位置
     • 在 Directory 字段中，输入目标目录

   • 对于使用 NFS 协议的远程系统，从下拉菜单中选择 Remote over NFS ，并指定以下字段：

     • 在 Server 字段中，输入远程服务器的地址
     • 在 Export 字段中，输入 NFS 服务器的共享文件夹的位置

     • 在 Directory 字段中，输入目标目录

       注意

       您可以选择 Compression 复选框来减小 vmcore 文件的大小。

验证

1. 单击 Test configuration。

   

2. 在 Test kdump settings 下点 Crash system。

   警告

   当您启动系统崩溃时，内核的操作将停止，并导致系统崩溃，并有数据丢失。

流程

1. 编辑 '/etc/kdump.conf 文件并添加 final_action 参数。

   final_action <reboot | halt | poweroff>

2. 重启 kdump 服务：

   kdumpctl restart

流程

1. 安装和配置 kdump。

2. 启用 fadump=on 内核选项：

   # grubby --update-kernel=ALL --args="fadump=on"

3. （可选）如果要指定保留引导内存而不是使用默认值，启用 crashkernel=xxM 选项，其中 xx 是所需的内存量（以 MB 为单位）：

   # grubby --update-kernel=ALL --args="crashkernel=xxM fadump=on"

   重要

   在指定引导选项时，请在执行前测试所有引导选项。如果 kdump 内核无法引导，请逐渐增加 crashkernel= 参数中指定的值来设置适当的值。

流程

1. 在 /etc/sysctl.conf 文件中添加或编辑以下行，以确保 sadump 的 kdump 按预期启动：

   kernel.panic=0
   kernel.unknown_nmi_panic=1

   警告

   特别是，请确保在 kdump 后系统不会重启。如果系统在 kdump 无法保存 vmcore 文件后重启，则无法调用 sadump。

2. 适当地将 /etc/kdump.conf 中的 failure_action 参数设置为 halt 或 shell。

   failure_action shell

流程

1. 启用相关的软件仓库：

   # subscription-manager repos --enable baseos repository

   # subscription-manager repos --enable appstream repository

   # subscription-manager repos --enable rhel-8-for-x86_64-baseos-debug-rpms

2. 安装 crash 软件包：

   # yum install crash

3. 安装 kernel-debuginfo 软件包：

   # yum install kernel-debuginfo

   软件包与正在运行的内核对应，并提供转储分析所需的数据。

流程

1. 要启动 crash 工具程序，需要将两个必要的参数传递给该命令：

   • debug-info（解压缩的 vmlinuz 镜像），如 /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux，通过特定的 kernel-debuginfo 软件包提供。

   • 实际 vmcore 文件，如 /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

     生成的 crash 命令类似如下：

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

     使用 kdump 捕获的相同 <kernel> 版本。

     例 20.1. 运行 crash 工具

     以下示例演示了使用 4.18.0-5.el8.x86_64 内核分析在 2018 年 10 月 6 日下午 14:05 时创建的内核转储。

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

2. 要退出交互式提示符并终止 crash，请键入 exit 或 q。

   例 20.2. 退出 crash 工具

   crash> exit
   ~]#

流程

1. 访问内核 Oops 分析器工具.

2. 要诊断内核崩溃问题，请上传 vmcore 中生成的内核oops 日志。

   • 或者，您也可以通过提供文本消息或 vmcore-dmesg.txt 作为输入来诊断内核崩溃问题。

     
3. 点 DETECT，基于 makedumpfile 中的信息与已知解决方案比较 oops 消息。

流程

1. 验证 kdump 服务是否已启用并活跃：

   # systemctl is-enabled kdump.service && systemctl is-active kdump.service
   enabled
   active

   如果没有启用并运行 kdump，请设置所有必要的配置，并验证是否已启用 kdump 服务。

2. 使用 早期 kdump 功能重建引导内核的 initramfs 镜像：

   # dracut -f --add earlykdump

3. 添加 rd.earlykdump 内核命令行参数：

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="rd.earlykdump"

4. 重启系统以反应更改

   # reboot

1. 内核补丁模块复制到 /var/lib/kpatch/ 目录中，并在下次引导时由 systemd 注册以重新应用到内核。
2. kpatch 模块被加载到正在运行的内核中，新的功能会注册到 ftrace 机制中，带有指向新代码内存中位置的指针。
3. 当内核访问补丁的功能时，它将由 ftrace 机制重定向，该机制绕过原始功能并将内核重定向到功能补丁版本。

流程

1. 另外，还可检查您的内核版本：

   # uname -r
   4.18.0-94.el8.x86_64

2. 搜索与内核版本对应的实时补丁软件包：

   # yum search $(uname -r)

3. 安装实时补丁（live patching）软件包：

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

   以上命令只为特定内核安装并应用最新的实时补丁。

   如果实时补丁软件包的版本是 1-1 或更高版本，则软件包将包含补丁模块。在这种情况下，内核会在安装 live patching 软件包期间自动修补。

   内核补丁模块也安装到 /var/lib/kpatch/ 目录中，供 systemd 系统和服务管理器以后重启时载入。

   注意

   当给定内核没有可用的实时补丁时，将安装空的实时补丁软件包。空的 live patching 软件包会有一个 0-0 的 kpatch_version-kpatch_release，如 kpatch-patch-4_18_0-94-0-0.el8.x86_64.rpm。空 RPM 安装会将系统订阅到以后为给定内核提供的所有实时补丁。

流程

1. （可选）检查所有安装的内核和您当前运行的内核：

   # yum list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64         4.18.0-240.10.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   kernel-core.x86_64         4.18.0-240.15.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   ...
   
   # uname -r
   4.18.0-240.10.1.el8_3.x86_64

2. 安装 kpatch-dnf 插件：

   # yum install kpatch-dnf

3. 启用自动订阅内核实时补丁：

   # yum kpatch auto
   Updating Subscription Management repositories.
   Last metadata expiration check: 19:10:26 ago on Wed 10 Mar 2021 04:08:06 PM CET.
   Dependencies resolved.
   ==================================================
    Package                             Architecture
   ==================================================
   Installing:
    kpatch-patch-4_18_0-240_10_1        x86_64
    kpatch-patch-4_18_0-240_15_1        x86_64
   
   Transaction Summary
   ===================================================
   Install  2 Packages
   …​

   这个命令订阅所有当前安装的内核，以接收内核实时补丁。命令还会为所有安装的内核安装并应用最新的累积实时补丁（如果有）。

   将来，当您更新内核时，将在新的内核安装过程中自动安装实时补丁。

   内核补丁模块也安装到 /var/lib/kpatch/ 目录中，供 systemd 系统和服务管理器以后重启时载入。

   注意

   当给定内核没有可用的实时补丁时，将安装空的实时补丁软件包。一个空的实时打补丁软件包将有一个 0-0 的 kpatch_version-kpatch_release，如 kpatch-patch-4_18_0-240-0-0.el8.x86_64.rpm。空的 RPM 安装会向后给定内核的所有实时补丁订阅系统。

流程

1. （可选）检查所有安装的内核和您当前运行的内核：

   # yum list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64         4.18.0-240.10.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   kernel-core.x86_64         4.18.0-240.15.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   ...
   
   # uname -r
   4.18.0-240.10.1.el8_3.x86_64

2. 禁用向内核实时补丁的自动订阅：

   # yum kpatch manual
   Updating Subscription Management repositories.

流程

1. 选择实时补丁软件包。

   # yum list installed | grep kpatch-patch
   kpatch-patch-4_18_0-94.x86_64        1-1.el8        @@commandline
   …​

   上面的输出示例列出了您安装的实时补丁软件包。

2. 删除实时补丁软件包。

   # yum remove kpatch-patch-4_18_0-94.x86_64

   删除实时补丁软件包后，内核将保持补丁，直到下次重启为止，但内核补丁模块会从磁盘中删除。将来重启时，对应的内核将不再被修补。

3. 重启您的系统。

4. 验证实时补丁软件包是否已删除。

   # yum list installed | grep kpatch-patch

   如果软件包已被成功删除，命令不会显示任何输出。

5. （可选）验证内核实时补丁解决方案是否已禁用。

   # kpatch list
   Loaded patch modules:

   示例输出显示内核没有补丁，实时补丁解决方案没有激活，因为目前没有加载补丁模块。

流程

1. 选择内核补丁模块：

   # kpatch list
   Loaded patch modules:
   kpatch_4_18_0_94_1_1 [enabled]
   
   Installed patch modules:
   kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)
   …​

2. 卸载所选的内核补丁模块。

   # kpatch uninstall kpatch_4_18_0_94_1_1
   uninstalling kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

   • 请注意，卸载的内核补丁模块仍然被加载：

     # kpatch list
     Loaded patch modules:
     kpatch_4_18_0_94_1_1 [enabled]
     
     Installed patch modules:
     <NO_RESULT>

     卸载所选模块后，内核将保持补丁，直到下次重启为止，但已从磁盘中删除内核补丁模块。

3. 重启您的系统。

4. （可选）验证内核补丁模块是否已卸载。

   # kpatch list
   Loaded patch modules:
   …​

   以上输出示例显示没有加载或已安装的内核补丁模块，因此没有修补内核，且内核实时补丁解决方案未激活。

流程

1. 验证 kpatch.service 是否已启用。

   # systemctl is-enabled kpatch.service
   enabled

2. 禁用 kpatch.service。

   # systemctl disable kpatch.service
   Removed /etc/systemd/system/multi-user.target.wants/kpatch.service.

   • 请注意，应用的内核补丁模块仍然被载入：

     # kpatch list
     Loaded patch modules:
     kpatch_4_18_0_94_1_1 [enabled]
     
     Installed patch modules:
     kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

3. 重启您的系统。

4. （可选）验证 kpatch.service 的状态。

   # systemctl status kpatch.service
   ● kpatch.service - "Apply kpatch kernel patches"
      Loaded: loaded (/usr/lib/systemd/system/kpatch.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

   示例输出测试 kpatch.service 已被禁用且没有在运行。因此，内核实时修补解决方案不活跃。

5. 验证内核补丁模块是否已卸载。

   # kpatch list
   Loaded patch modules:
   <NO_RESULT>
   
   Installed patch modules:
   kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

   上面的示例输出显示内核补丁模块仍处于安装状态，但没有修补内核。

流程

1. 识别您要限制 CPU 消耗的应用程序的进程 ID (PID)：

   # top
   top - 11:34:09 up 11 min,  1 user,  load average: 0.51, 0.27, 0.22
   Tasks: 267 total,   3 running, 264 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 49.0 us,  3.3 sy,  0.0 ni, 47.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
   MiB Mem :   1826.8 total,    303.4 free,   1046.8 used,    476.5 buff/cache
   MiB Swap:   1536.0 total,   1396.0 free,    140.0 used.    616.4 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    6955 root      20   0  228440   1752   1472 R  99.3   0.1   0:32.71 sha1sum
    5760 jdoe      20   0 3603868 205188  64196 S   3.7  11.0   0:17.19 gnome-shell
    6448 jdoe      20   0  743648  30640  19488 S   0.7   1.6   0:02.73 gnome-terminal-
       1 root      20   0  245300   6568   4116 S   0.3   0.4   0:01.87 systemd
     505 root      20   0       0      0      0 I   0.3   0.0   0:00.75 kworker/u4:4-events_unbound
   ...

   这个 top 程序的示例输出显示，带有 PID 6955 的应用程序 sha1sum 使用大量 CPU 资源。

2. 在 cpu 资源控制器目录中创建子目录：

   # mkdir /sys/fs/cgroup/cpu/Example/

   此目录代表控制组，您可以在其中放置特定进程并将某些 CPU 限制应用到进程。同时，目录中将创建多个 cgroups-v1 接口文件和 cpu 控制器特定文件。

3. 可选 ：检查新创建的控制组群：

   # ll /sys/fs/cgroup/cpu/Example/
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.procs
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.stat
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.shares
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpu.stat
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 notify_on_release
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 tasks

   这个示例输出显示文件，如 cpuacct.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 文件表示以微秒为单位（这里表示为"us"）的时段，用于控制组对 CPU 资源的访问权限应重新分配的频率。上限为 1 000 000 微秒，下限为 1 000 微秒。

   • cpu.cfs_quota_us 文件表示以微秒为单位的总时间量，控制组中的所有进程都可以在一个期间（如 cpu.cfs_period_us 定义）。当控制组中的进程在单个期间内使用配额指定的所有时间时，在周期的其余部分内，它们将节流，并且不允许在下一个期间运行。较低限制为 1 000 微秒。

     上面的示例命令设定 CPU 时间限值，使得 Example 控制组中的所有进程仅能每 1 秒（ cpu.cfs_quota_us 定义）每 1 秒（由 cpu.cfs_period_us 定义）运行 0.2 秒。

5. 可选 ：验证限制：

   # cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us
   1000000
   200000

6. 将应用程序的 PID 添加到 Example 控制组群中：

   # echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs

   此命令可确保特定应用成为 Example 控制组的成员，因此不超过为 Example 控制组配置的 CPU 限值。PID 应该代表系统中的一个已存在的进程。这里的 PID 6955 分配给进程 sha1sum /dev/zero & amp;，用于说明 cpu 控制器的用例。

验证

1. 验证应用程序是否在指定的控制组群中运行：

   # cat /proc/6955/cgroup
   12:cpuset:/
   11:hugetlb:/
   10:net_cls,net_prio:/
   9:memory:/user.slice/user-1000.slice/user@1000.service
   8:devices:/user.slice
   7:blkio:/
   6:freezer:/
   5:rdma:/
   4:pids:/user.slice/user-1000.slice/user@1000.service
   3:perf_event:/
   2:cpu,cpuacct:/Example
   1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service

   此示例输出显示所需应用程序的进程在 Example 控制组中运行，后者将 CPU 限制应用到应用程序的进程。

2. 确定节流应用程序的当前 CPU 消耗：

   # top
   top - 12:28:42 up  1:06,  1 user,  load average: 1.02, 1.02, 1.00
   Tasks: 266 total,   6 running, 260 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 11.0 us,  1.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.2 st
   MiB Mem :   1826.8 total,    287.1 free,   1054.4 used,    485.3 buff/cache
   MiB Swap:   1536.0 total,   1396.7 free,    139.2 used.    608.3 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    6955 root      20   0  228440   1752   1472 R  20.6   0.1  47:11.43 sha1sum
    5760 jdoe      20   0 3604956 208832  65316 R   2.3  11.2   0:43.50 gnome-shell
    6448 jdoe      20   0  743836  31736  19488 S   0.7   1.7   0:08.25 gnome-terminal-
     505 root      20   0       0      0      0 I   0.3   0.0   0:03.39 kworker/u4:4-events_unbound
    4217 root      20   0   74192   1612   1320 S   0.3   0.1   0:01.19 spice-vdagentd
   ...

   请注意，PID 6955 的 CPU 消耗从 99% 减少到 20%。

流程

1. 识别您要限制其 CPU 消耗的应用程序的进程 ID(PID)：

   # top
   Tasks: 104 total,   3 running, 101 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 17.6 us, 81.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.8 hi,  0.0 si,  0.0 st
   MiB Mem :   3737.4 total,   3312.7 free,    133.3 used,    291.4 buff/cache
   MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3376.1 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     34578 root      20   0   18720   1756   1468 R  99.0   0.0   0:31.09 sha1sum
     34579 root      20   0   18720   1772   1480 R  99.0   0.0   0:30.54 sha1sum
         1 root      20   0  186192  13940   9500 S   0.0   0.4   0:01.60 systemd
         2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthreadd
         3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp
         4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par_gp
   ...

   示例输出显示 PID 34578 和 34579（ sha1sum的两个说明性应用程序）消耗了大量资源，即 CPU。这两个应用程序都是用于演示 cgroups-v2 功能的应用示例。

2. 验证 /sys/fs/cgroup/cgroup.controllers 文件中是否提供了 cpu 和 cpuset 控制器：

   # cat /sys/fs/cgroup/cgroup.controllers
   cpuset cpu io memory hugetlb pids rdma

3. 启用与 CPU 相关的控制器：

   # echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control
   # echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_control

   这些命令为 /sys/fs/cgroup/ 根控制组的直接子组启用了 cpu 和 cpuset 控制器。子组 是您可以指定进程，并根据您的标准对每个进程应用控制检查的地方。

   用户可以在任意级别读取 cgroup.subtree_control 文件的内容，以了解即时子组中哪些控制器可用于启用。

   注意

   默认情况下，根控制组中的 /sys/fs/cgroup/cgroup.subtree_control 文件包含 memory 和 pids 控制器。

4. 创建 /sys/fs/cgroup/Example/ 目录：

   # mkdir /sys/fs/cgroup/Example/

   /sys/fs/cgroup/Example/ 目录定义了一个子组。此外，上一步为这个子组启用了 cpu 和 cpuset 控制器。

   创建 /sys/fs/cgroup/Example/ 目录时，一些 cgroups-v2 接口文件以及 cpu 和 cpuset 特定于控制器的文件也会在目录中自动创建。/sys/fs/cgroup/Example/ 目录还包含 memory 和 pids 控制器的特定于控制器的文件。

5. 可选，检查新创建的子控制组：

   # ll /sys/fs/cgroup/Example/
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.controllers
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.events
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.freeze
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.max.depth
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.max.descendants
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.procs
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.stat
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.subtree_control
   …​
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpuset.cpus
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cpuset.cpus.effective
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpuset.cpus.partition
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpuset.mems
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cpuset.mems.effective
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cpu.stat
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpu.weight
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpu.weight.nice
   …​
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 memory.events.local
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.high
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.low
   …​
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.current
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.events
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 pids.max

   示例输出显示 cpuset.cpus 和 cpu.max 等文件。这些文件特定于 cpuset 和 cpu 控制器。使用 /sys/fs/cgroup/cgroup.subtree_control 文件，为根的（/sys/fs/cgroup/)直接子控制组 手动启用 cpuset 和 cpu 控制器。

   目录还包含通用 cgroup 控制接口文件，如 cgroup.procs 或 cgroup.controllers，它们对所有控制组都通用，无论启用的控制器是什么。

   memory.high 和 pids.max 等文件与 memory 和pids 控制器有关，它们位于根控制组中(/sys/fs/cgroup/)，默认情况下总是启用的。

   默认情况下，新创建的子组继承了对系统所有 CPU 和内存资源的访问权限，没有任何限制。

6. 启用 /sys/fs/cgroup/Example/ 中与 CPU 相关的控制器，以获取仅与 CPU 相关的控制器：

   # echo "+cpu" >> /sys/fs/cgroup/Example/cgroup.subtree_control
   # echo "+cpuset" >> /sys/fs/cgroup/Example/cgroup.subtree_control

   这些命令确保直接子控制组将 只能 有与控制 CPU 时间相关的控制器，而不是 memory 或 pids 控制器。

7. 创建 /sys/fs/cgroup/Example/tasks/ 目录：

   # mkdir /sys/fs/cgroup/Example/tasks/

   /sys/fs/cgroup/Example/tasks/ 目录定义了一个子组，以及只与 cpu 和 cpuset 控制器相关的文件。

8. 另外，还可检查其他子控制组：

   # ll /sys/fs/cgroup/Example/tasks
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.controllers
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.events
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.freeze
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.depth
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.descendants
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.procs
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.stat
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.subtree_control
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.threads
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.type
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.max
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.pressure
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.effective
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.partition
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems.effective
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpu.stat
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight.nice
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 io.pressure
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 memory.pressure

9. 确保您要控制 CPU 时间的进程在同一 CPU 上竞争：

   # echo "1" > /sys/fs/cgroup/Example/tasks/cpuset.cpus

   以上命令可确保您将放在 Example/tasks 子控制组中的进程在同一 CPU 上竞争。此设置对于要激活的 cpu 控制器非常重要。

   重要

   cpu 控制器只有在相关子控制组至少有 2 个在单个 CPU 上竞争时间的进程时，才会被激活 。

验证步骤

1. 可选：确保为直接子 cgroups 启用了与 CPU 相关的控制器：

   # cat /sys/fs/cgroup/cgroup.subtree_control /sys/fs/cgroup/Example/cgroup.subtree_control
   cpuset cpu memory pids
   cpuset cpu

2. 可选：确保您要控制 CPU 时间的进程在同一 CPU 上竞争：

   # cat /sys/fs/cgroup/Example/tasks/cpuset.cpus
   1

流程

1. 配置 CPU 带宽以在控制组群内实现资源限制：

   # echo "200000 1000000" > /sys/fs/cgroup/Example/tasks/cpu.max

   第一个值是允许的时间配额（以微秒为单位），用于子组中的所有进程可以在一段时间内运行。第二个值指定时间段的长度。

   在一段时间内，当控制组中的进程共同耗尽此配额指定的时间时，它们会在该时间段的剩余时间内节流，并且直到下一个时间段才允许运行。

   此命令设置 CPU 时间分布控制，以便 /sys/fs/cgroup/Example/tasks 子组中的所有进程每 1 秒只能在 CPU 上运行 0.2 秒。也就是说，每秒的五分之一。

2. 另外，验证时间配额：

   # cat /sys/fs/cgroup/Example/tasks/cpu.max
   200000 1000000

3. 将应用的 PID 添加到 Example/tasks 子组中：

   # echo "34578" > /sys/fs/cgroup/Example/tasks/cgroup.procs
   # echo "34579" > /sys/fs/cgroup/Example/tasks/cgroup.procs

   示例命令确保所需的应用程序成为 Example/tasks 子组的成员，并且不超过为此子组配置的 CPU 时间分布。

验证步骤

1. 验证应用程序是否在指定的控制组群中运行：

   # cat /proc/34578/cgroup /proc/34579/cgroup
   0::/Example/tasks
   0::/Example/tasks

   上面的输出显示了在 Example/tasks 子组中运行的指定应用程序的进程。

2. 检查节流应用程序的当前 CPU 消耗：

   # top
   top - 11:13:53 up 23:10,  1 user,  load average: 0.26, 1.33, 1.66
   Tasks: 104 total,   3 running, 101 sleeping,   0 stopped,   0 zombie
   %Cpu(s):  3.0 us,  7.0 sy,  0.0 ni, 89.5 id,  0.0 wa,  0.2 hi,  0.2 si,  0.2 st
   MiB Mem :   3737.4 total,   3312.6 free,    133.4 used,    291.4 buff/cache
   MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3376.0 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     34578 root      20   0   18720   1756   1468 R  10.0   0.0  37:36.13 sha1sum
     34579 root      20   0   18720   1772   1480 R  10.0   0.0  37:41.22 sha1sum
         1 root      20   0  186192  13940   9500 S   0.0   0.4   0:01.60 systemd
         2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthreadd
         3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp
         4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par_gp
   ...

   请注意，PID 34578 和 PID 34579 的 CPU 消耗已减少到 10%。Example/tasks 子组将其进程控制到 CPU 时间的 20%。由于控制组中有 2 个进程，因此每个进程可以使用 10% 的 CPU 时间。

流程

1. 配置所需的 CPU 权重以便在控制组群内实现资源限制：

   # echo "150" > /sys/fs/cgroup/Example/g1/cpu.weight
   # echo "100" > /sys/fs/cgroup/Example/g2/cpu.weight
   # echo "50" > /sys/fs/cgroup/Example/g3/cpu.weight

2. 将应用程序的 PID 添加到 g1、g2 和 g3 子组中：

   # echo "33373" > /sys/fs/cgroup/Example/g1/cgroup.procs
   # echo "33374" > /sys/fs/cgroup/Example/g2/cgroup.procs
   # echo "33377" > /sys/fs/cgroup/Example/g3/cgroup.procs

   示例命令可确保所需的应用程序成为 Example/g*/ 子 cgroup 的成员，并按照这些 cgroup 配置获取发布的 CPU 时间。

   已运行进程的子 cgroup (g1, g2, g3) 的权重在父 cgroup（Example）级别上相加。然后，根据对应的权重按比例分布 CPU 资源。

   因此，当所有进程同时运行时，内核会根据相应的 cgroup 的 cpu.weight 文件为每个进程按比例分配 CPU 时间：

   子 cgroup	cpu.weight 文件	CPU 时间分配
   g1	150	~50% (150/300)
   g2	100	~33% (100/300)
   g3	50	~16% (50/300)

   cpu.weight 控制器文件的值不是一个百分比。

   如果一个进程停止运行，使 cgroup g2 没有运行进程，则计算将省略 cgroup g2，仅计算 cgroup g1 和 g3 的帐户权重：

   子 cgroup	cpu.weight 文件	CPU 时间分配
   g1	150	~75% (150/200)
   g3	50	~25% (50/200)

   重要

   如果子 cgroup 有多个正在运行的进程，则分配给相应 cgroup 的 CPU 时间将平均分配给该 cgroup 的成员进程。

验证

1. 验证应用程序是否运行在指定的控制组中：

   # cat /proc/33373/cgroup /proc/33374/cgroup /proc/33377/cgroup
   0::/Example/g1
   0::/Example/g2
   0::/Example/g3

   命令输出显示了运行在 Example/g*/ 子 cgroup 中指定的应用程序的进程。

2. 检查节流应用程序的当前 CPU 消耗：

   # top
   top - 05:17:18 up 1 day, 18:25,  1 user,  load average: 3.03, 3.03, 3.00
   Tasks:  95 total,   4 running,  91 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 18.1 us, 81.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st
   MiB Mem :   3737.0 total,   3233.7 free,    132.8 used,    370.5 buff/cache
   MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3373.1 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     33373 root      20   0   18720   1748   1460 R  49.5   0.0 415:05.87 sha1sum
     33374 root      20   0   18720   1756   1464 R  32.9   0.0 412:58.33 sha1sum
     33377 root      20   0   18720   1860   1568 R  16.3   0.0 411:03.12 sha1sum
       760 root      20   0  416620  28540  15296 S   0.3   0.7   0:10.23 tuned
         1 root      20   0  186328  14108   9484 S   0.0   0.4   0:02.00 systemd
         2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthread
   ...

   注意

   为了更清楚地说明，我们强制所有示例进程运行在单个 CPU 上。当在多个 CPU 上使用时，CPU 权重也会应用同样的原则。

   注意 PID 33373、PID 33374 和 PID 33377 的 CPU 资源会根据您分配给相应子 cgroup 的权重 150、100、50 进行分配。权重对应于每个应用程序分配的 CPU 时间的大约 50%、33% 和 16%。

流程

1. 要限制服务的内存用量，请修改 /usr/lib/systemd/system/example.service 文件，如下所示：

   …​
   [Service]
   MemoryMax=1500K
   …​

   以上配置对在控制组中执行的进程的最大内存消耗设定了限制，example.service 是该控制组中的一部分。

   注意

   使用后缀 K、M、G 或 T 将 Kilobyte、Megabyte、Gigabyte 或 Terabyte 识别为一个测量单位。

2. 重新载入所有单元配置文件：

   # systemctl daemon-reload

3. 重启服务：

   # systemctl restart example.service

4. 重启系统。

5. （可选）检查更改是否生效：

   # cat /sys/fs/cgroup/memory/system.slice/example.service/memory.limit_in_bytes
   1536000

   示例输出显示内存消耗被限制在大约 1,500 KB。

   注意

   memory.limit_in_bytes 文件将内存限制存储为 4096 字节的倍数 - 一个内核页面大小，专用于 AMD64 和 Intel 64。实际的字节数量取决于 CPU 构架。