절차

1. 사용 가능한 패키지 버전을 나열합니다.

   $ yum repoquery <package_name>

   예를 들어 사용 가능한 kernel-core 패키지 버전을 나열합니다.

   $ yum repoquery kernel-core
   kernel-core-0:4.18.0-147.0.2.el8_1.x86_64
   kernel-core-0:4.18.0-147.0.3.el8_1.x86_64
   kernel-core-0:4.18.0-147.3.1.el8_1.x86_64
   kernel-core-0:4.18.0-147.5.1.el8_1.x86_64
   kernel-core-0:4.18.0-147.8.1.el8_1.x86_64
   kernel-core-0:4.18.0-147.el8.x86_64
   …​

2. 패키지에 있는 파일 목록을 표시합니다.

   $ yum repoquery -l <package_name>

   예를 들어 kernel-core-0:5.14.0-162.23.1.el9_1.x86_64 패키지의 파일 목록을 표시합니다.

   $ yum repoquery -l kernel-core-0:4.18.0-147.8.1.el8_1.x86_64
   /boot/.vmlinuz-4.18.0-147.8.1.el8_1.x86_64.hmac
   /boot/System.map-4.18.0-147.8.1.el8_1.x86_64
   /boot/config-4.18.0-147.8.1.el8_1.x86_64
   /boot/initramfs-4.18.0-147.8.1.el8_1.x86_64.img
   /boot/symvers-4.18.0-147.8.1.el8_1.x86_64.gz
   /boot/vmlinuz-4.18.0-147.8.1.el8_1.x86_64
   /etc/ld.so.conf.d/kernel-4.18.0-147.8.1.el8_1.x86_64.conf
   /lib/modules
   /lib/modules/4.18.0-147.8.1.el8_1.x86_64
   ...

절차

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. 거부 목록 역할을 하는 구성 파일을 생성합니다.

   # 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 명령은 모듈이 거부 목록에 없는 다른 커널 모듈의 종속성으로 로드되지 않도록 하려면 설치 행도 정의해야 합니다. 이 경우 시스템은 모듈을 설치하는 대신 /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 디스크 이미지를 빌드하는 경우 target 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. kernel 모듈을 /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 목록에 있으면 이 키로 자동으로 .platform 키링으로 전파되고 UEFI Secure Boot가 활성화되면 후속 부팅이 수행됩니다.

절차

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 Series 및 x86-64 BIOS 기반 시스템에서 linux 로 시작하거나 UEFI 시스템에서 linuxefi 로 시작합니다.

3. 커서를 행 끝으로 이동합니다.

   참고

   Ctrla를 눌러 행의 시작 부분으로 건너뛰고 Ctrle를 눌러 행의 끝으로 건너뜁니다. 일부 시스템에서 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. Ctrlx를 눌러 선택한 커널과 수정된 명령행 매개 변수를 사용하여 부팅합니다.

절차

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 키의 값을 재정의합니다.

   두 번째 줄은 baud 속도(--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

   sample 명령은 튜닝 가능 항목을 변경하고 커널 매개 변수의 기본값을 재정의하는 /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 눌러 디버그 쉘로 부팅합니다.

절차

1. Ctrl+Alt+F9 를 눌러 디버그 쉘에 연결합니다.

   가상 머신에서 작업하는 경우 이 키 조합을 보내려면 가상화 애플리케이션의 지원이 필요합니다. 예를 들어 Virtual Machine Manager 를 사용하는 경우 메뉴에서 Send Key → Ctrl+Alt+F9 를 선택합니다.

2. 디버그 쉘에는 인증이 필요하지 않으므로 TTY9에서 다음과 유사한 프롬프트가 표시될 수 있습니다.

절차

1. 설치 소스에서 호스트를 부팅합니다.

2. 설치 미디어의 부팅 메뉴에서 문제 해결 옵션을 선택합니다.

   

3. 문제 해결 메뉴에서 Rescue a Red Hat Enterprise Linux 시스템 옵션을 선택합니다.

   

4. Rescue 메뉴에서 1 을 선택하고 Enter 키를 눌러 계속합니다.

   

5. 다음과 같이 파일 시스템 루트 를 변경합니다.

   sh-4.4# chroot /mnt/sysimage

   

6. passwd 명령을 입력하고 명령줄에 표시된 지침에 따라 root 암호를 변경합니다.

   

7. 자동 복구 가능 파일 을 제거하여 디스크의 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. 파일 시스템의 루트 를 변경합니다.

   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. kernelopts 변수의 커널 매개변수를 나열합니다.

   # grub2-editenv - list | grep kernelopts
   kernelopts=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

2. 커널 명령줄 매개 변수를 변경합니다. 매개변수를 추가, 제거 또는 수정할 수 있습니다. 예를 들어 debug 매개변수를 추가하려면 다음을 입력합니다.

   # grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) <debug>"

3. 선택 사항: 새로 추가된 매개변수가 kernelopts 에 추가되었는지 확인합니다.

   # grub2-editenv - list | grep kernelopts
   kernelopts=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 debug

4. 변경 사항을 적용하려면 시스템을 재부팅합니다.

절차

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 지시문의 키로 숫자 값을 사용하여 운영 체제가 로드되는 기본 순서를 변경할 수 있도록 지원합니다.

   참고

   인덱스 계산은 0부터 시작하므로 이전 예에서 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. grub2-setpassword 명령을 root로 실행합니다.

   # grub2-setpassword

2. 사용자의 암호를 입력하고 Enter 키를 눌러 암호를 확인합니다.

   Enter password:
   Confirm the password:

절차

1. /boot/loader/entries/ 디렉토리에서 수정할 부팅 항목에 대해BLS(BLS ) 파일을 엽니다.
2. grub_users 로 시작하는 행을 찾습니다. 이 매개변수는 메뉴 입력에 추가 인수를 전달합니다.

3. 기본적으로 이 사용자는 root 임을 수퍼유저 이외의 항목을 부팅할 수 있는 사용자 이름으로 grub_users 특성을 설정합니다. 다음은 샘플 구성 파일입니다.

   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. 값. 콘솔 로그 수준은 콘솔에 인쇄된 메시지의 우선 순위를 가장 낮은 우선 순위를 정의합니다.
2. 값. 명시적인 로그 수준이 연결되지 않은 메시지의 기본 로그 수준입니다.
3. 값. 콘솔 로그 레벨에 가능한 최저 로그 수준 구성을 설정합니다.

4. 값. 부팅 시 콘솔 로그 수준의 기본값을 설정합니다.

   위의 각 값은 오류 메시지를 처리하는 다른 규칙을 정의합니다.

절차

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= 옵션을 준비합니다.

   • 예를 들어 128MB의 메모리를 예약하려면 다음을 사용합니다.

     crashkernel=128M

   • 또는 설치된 메모리의 총 크기에 따라 예약된 메모리 양을 변수로 설정할 수 있습니다. 메모리 예약을 변수에 대한 구문은 crashkernel=<range1> :< size1>,< range2>:<size2> 입니다. 예를 들면 다음과 같습니다.

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

     총 시스템 메모리 양이 512MB와 2GB인 경우 명령은 64MB의 메모리를 예약합니다. 총 메모리 양이 2GB를 초과하는 경우 메모리 예약은 128MB입니다.

   • 예약된 메모리를 오프셋합니다.

     일부 시스템에서는 crashkernel 예약이 일찍 이루어지기 때문에 고정된 오프셋이 있는 메모리를 예약해야 하며, 특수 사용을 위해 더 많은 메모리를 예약해야 할 수도 있습니다. 오프셋을 정의할 때 예약된 메모리가 시작됩니다. 예약된 메모리를 오프셋하려면 다음 구문을 사용하십시오.

     crashkernel=128M@16M

     이 예에서 kdump 는 16MB(실제 주소 0x01000000)부터 128MB의 메모리를 예약합니다. offset 매개변수를 0으로 설정하거나 완전히 생략하면 kdump 가 예약된 메모리를 자동으로 오프셋합니다. 변수 메모리 예약을 설정할 때 이 구문을 사용할 수도 있습니다. 이 경우 오프셋은 항상 마지막으로 지정됩니다. 예를 들면 다음과 같습니다.

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

2. boot loader 구성에 crashkernel= 옵션을 적용합니다.

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

   & lt;value >를 이전 단계에서 준비한 crashkernel= 옵션의 값으로 바꿉니다.

절차

1. 루트 로서 /etc/kdump.conf 구성 파일을 편집하고 #core_collector makedumpfile -l --message-level 1 -d 31 부터 해시 기호("#")를 제거합니다.
2. 크래시 덤프 파일 압축을 활성화하려면 다음을 실행합니다.

절차

1. 루트 로서 /etc/kdump.conf 구성 파일의 #failure_action 행의 시작 부분에서 해시 기호("#")를 제거합니다.

2. 값을 원하는 작업으로 바꿉니다.

   failure_action poweroff

절차

1. kdump 가 활성화된 시스템을 재부팅합니다.

2. kdump 가 활성화되어 있는지 확인합니다.

   # systemctl is-active kdump
   active

3. 커널 충돌을 강제 적용합니다.

   echo c > /proc/sysrq-trigger

   주의

   명령을 사용하면 커널이 충돌하고 필요한 경우 커널을 재부팅합니다.

   커널 재부팅 시 주소-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. 시스템의 GRUB(G Grand Unified Bootloader) 구성 파일에 특정 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. 웹 콘솔에서 커널 덤프 탭을 열고 Kernel crash dump 스위치를 on으로 설정하여 kdump 서비스를 시작합니다.
2. 명령줄에서 kdump 메모리 사용량을 구성합니다.

3. 커널 덤프 탭에서 Crash dump 위치로 이동하여 덤프 위치 경로가 있는 링크를 클릭합니다.

   

4. vmcore 덤프 파일을 저장할 대상 디렉터리를 지정합니다.

   • 로컬 파일 시스템의 드롭다운 메뉴에서 로컬 파일 시스템을 선택합니다.

     

   • SSH 프로토콜을 사용하여 원격 시스템의 경우 드롭다운 메뉴에서 SSH를 통한 Remote 를 선택하고 다음 필드를 지정합니다.

     • 서버 필드에 원격 서버 주소를 입력합니다.
     • ssh 키 필드에 ssh 키 위치를 입력합니다.
     • 디렉터리 필드에 대상 디렉터리를 입력합니다.

   • NFS 프로토콜을 사용하여 원격 시스템의 경우 드롭다운 메뉴에서 Remote over NFS 를 선택하고 다음 필드를 지정합니다.

     • 서버 필드에 원격 서버 주소를 입력합니다.
     • 내보내기 필드에 NFS 서버의 공유 폴더 위치를 입력합니다.

     • 디렉터리 필드에 대상 디렉터리를 입력합니다.

       참고

       Compression 확인란을 선택하여 vmcore 파일의 크기를 줄일 수 있습니다.

검증

1. 테스트 구성 을 클릭합니다.

   

2. kdump 설정 테스트에서 Crash 시스템을 클릭합니다.

   주의

   시스템 충돌을 시작하면 커널의 작업이 중지되고 데이터 손실로 인해 시스템이 중단됩니다.

절차

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 는 메가바이트에 필요한 메모리 양입니다.

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

   중요

   부팅 구성 옵션을 지정할 때 실행하기 전에 모든 부팅 구성 옵션을 테스트합니다. kdump 커널을 부팅하지 못하면 crashkernel= 인수에 지정된 값을 점진적으로 늘려 적절한 값을 설정합니다.

절차

1. /etc/sysctl.conf 파일에서 다음 행을 추가하거나 편집하여 kdump가 expect ump 에서 예상대로 시작되도록 합니다.

   kernel.panic=0
   kernel.unknown_nmi_panic=1

   주의

   특히 kdump 후에 시스템이 재부팅되지 않도록 하십시오. kdump 가 vmcore 파일을 저장하지 못한 후 시스템이 재부팅되면 안 됩니다.

2. /etc/kdump.conf 에서 halt 또는 shell 으로 적절하게 failure_action 매개변수를 설정합니다.

   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 유틸리티를 시작하려면 명령에 두 개의 매개 변수를 전달해야 합니다.

   • 특정 kernel-debuginfo 패키지를 통해 제공되는 debug-info(예: /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux )

   • 실제 vmcore 파일(예: /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore)

     결과 crash 명령은 다음과 같습니다.

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

     kdump 에서 캡처한 동일한 <kernel> 버전을 사용합니다.

     예 20.1. crash 유틸리티 실행

     다음 예제에서는 4.18.0-5.el8.x86_64 커널을 사용하여 14:05 PM에 생성된 코어 덤프를 분석하는 방법을 보여줍니다.

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

2. 대화형 프롬프트를 종료하고 크래시 를 종료하려면 exit 또는 q 를 입력합니다.

   예 20.2. crash 유틸리티 종료

   crash> exit
   ~]#

절차

1. Kernel Oops Analyzer 툴 액세스.

2. 커널 충돌 문제를 진단하려면 vmcore 에 생성된 커널 oops 로그를 업로드합니다.

   • 또는 텍스트 메시지 또는 vmcore-dmesg.txt 를 입력으로 제공하여 커널 크래시 문제를 진단할 수도 있습니다.

     
3. DEœT (삭제)를 클릭하여 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. 라이브 패치 패키지를 설치합니다.

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

   위의 명령은 특정 커널에 대해서만 최신 누적 라이브 패치를 설치하고 적용합니다.

   라이브 패치 패키지 버전이 1-1 이상인 경우 패키지에 patch 모듈이 포함됩니다. 이 경우 라이브 패치 패키지를 설치하는 동안 커널이 자동으로 패치됩니다.

   커널 패치 모듈은 향후 재부팅 중에 systemd 시스템 및 서비스 관리자가 로드할 /var/lib/kpatch/ 디렉토리에도 설치됩니다.

   참고

   지정된 커널에 사용할 수 있는 라이브 패치가 없는 경우 빈 라이브 패치 패키지가 설치됩니다. 비어 있는 라이브 패치 패키지에는 kpatch_version-kpatch_release 가 0-0입니다(예: kpatch-patch-4_18_0-94-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
   …​

   이 명령은 현재 설치된 커널을 모두 서브스크립션하여 커널 라이브 패치를 수신합니다. 또한 명령은 설치된 모든 커널에 대해 최신 누적 라이브 패치를 설치하고 적용합니다.

   나중에 커널을 업데이트하면 새 커널 설치 프로세스 중에 라이브 패치가 자동으로 설치됩니다.

   커널 패치 모듈은 향후 재부팅 중에 systemd 시스템 및 서비스 관리자가 로드할 /var/lib/kpatch/ 디렉토리에도 설치됩니다.

   참고

   지정된 커널에 사용할 수 있는 라이브 패치가 없는 경우 빈 라이브 패치 패키지가 설치됩니다. 빈 라이브 패치 패키지에는 kpatch_version-kpatch_release 가 0-0입니다(예: kpatch-patch-4_18_0-240-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 소비에서 제한하려는 애플리케이션의 PID(프로세스 ID)를 식별합니다.

   # 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 와 같은 파일을 보여줍니다. 각 파일 이름 앞에는 자신이 속한 제어 그룹 컨트롤러의 이름이 접두어 있습니다.

   기본적으로 새로 생성된 제어 그룹은 제한 없이 시스템의 전체 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"로 표시되는 시간)를 나타냅니다. 상한은 1 000 마이크로초이며 더 낮은 제한은 1 000 마이크로초입니다.

   • cpu.cfs_quota_us 파일은 제어 그룹의 모든 프로세스가 하나의 기간(cpu. cfs_period_us에서 정의한 대로) 동안 실행되는 총 시간(마이크로초)을 나타냅니다. 단일 기간 동안 제어 그룹의 프로세스가 할당량에 의해 지정된 모든 시간을 사용하는 경우 나머지 기간 동안 제한되며 다음 기간까지 실행되지 않습니다. 낮은 제한은 1000 마이크로초입니다.

     위의 예제 명령은 CPU 시간 제한을 설정하여 Example 제어 그룹에서 집계된 모든 프로세스가 1초(cpu .cfs_quota_us로 정의됨)마다 0.2초(cpu.cfs_ period_us로 정의됨) 동안만 실행할 수 있습니다.

5. 선택 사항: 제한을 확인합니다.

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

6. Example 제어 그룹에 애플리케이션의 PID를 추가합니다.

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

   이 명령은 특정 애플리케이션이 Example 제어 그룹의 멤버가 되도록 하여 Example 제어 그룹에 구성된 CPU 제한을 초과하지 않습니다. PID는 시스템의 기존 프로세스를 나타냅니다. 여기서 PID 6955 는 cpu 컨트롤러의 사용 사례를 설명하는 데 사용되는 sha1sum /dev/zero & amp; 를 처리하도록 할당되었습니다.

검증

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 소비 애플리케이션의 PID(프로세스 ID)를 식별합니다.

   # 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 및 34 579 ( sha1sum의 설명 애플리케이션 2개)가 CPU라는 많은 리소스를 사용한다는 것을 알 수 있습니다. 두 애플리케이션 모두 cgroups-v2 기능 관리를 시연하는 데 사용되는 예제 애플리케이션입니다.

2. cpu 및 cpu set 컨트롤러를 /sys/fs/cgroup/cgroup.controllers 파일에서 사용할 수 있는지 확인합니다.

   # 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 파일의 내용을 읽고 즉시 하위 그룹에서 활성화에 사용할 수 있는 컨트롤러를 파악할 수 있습니다.

   참고

   기본적으로 root 제어 그룹의 /sys/fs/cgroup/cgroup.subtree_control 파일에는 메모리 및 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/ 디렉터리에는 메모리 및 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 컨트롤러에 따라 다릅니다. cpuset 및 cpu 컨트롤러는/sys/fs/cgroup/cgroup _control 파일을 사용하여 루트의(/ sys/fs/cgroup/cgroup_control) 직접 하위 제어 그룹에 대해 수동으로 활성화됩니다.

   디렉터리에는 활성화된 컨트롤러에 관계없이 모든 제어 그룹에 공통된 cgroup.procs 또는 cgroup.controllers 와 같은 일반적인 cgroup 제어 인터페이스 파일도 포함되어 있습니다.

   memory.high 및 pids. max 와 같은 파일은 루트 제어 그룹(/sys/fs/cgroup/)에 있으며 항상 기본적으로 활성화되는 메모리 및 pids 컨트롤러와 관련이 있습니다.

   기본적으로 새로 생성된 하위 그룹은 제한 없이 모든 시스템의 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 시간 배포를 규제하는 것과 관련된 컨트롤러 만 사용할 수 있습니다.

7. /sys/fs/cgroup/Example/tasks/ 디렉터리를 생성합니다.

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

   /sys/fs/cgroup/Example/tasks/ 디렉터리는 cpu 및 cpu set 컨트롤러에만 관련된 파일이 있는 하위 그룹을 정의합니다.

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 컨트롤러는 관련 하위 제어 그룹에 단일 CPU에서 시간을 위해 경쟁하는 최소 2개의 프로세스가 있는 경우에만 활성화됩니다.

검증 단계

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초마다 0.2초 동안만 CPU에서 실행될 수 있습니다. 즉, 1초의 5분의 1이 됩니다.

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 34 579 의 CPU 사용량이 10%로 감소했습니다. Example/tasks 하위 그룹은 프로세스를 전체적으로 CPU 시간의 20%로 조정합니다. 제어 그룹에는 두 개의 프로세스가 있으므로 각각 CPU 시간의 10%를 활용할 수 있습니다.

절차

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, g 2 및 g 3 하위 그룹에 추가합니다.

   # 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

   예제 명령을 사용하면 원하는 애플리케이션이 예제/g*/ 하위 cgroups의 멤버가 되고 해당 cgroups의 구성에 따라 CPU 시간이 배포됩니다.

   프로세스가 실행 중인 하위 cgroup(g1,g2, g3)의 가중치는 상위 cgroup(Example) 수준에서 요약됩니다. 그런 다음 CPU 리소스는 해당 가중치에 비례하여 배포됩니다.

   결과적으로 모든 프로세스가 동시에 실행되면 커널은 해당 cgroup의 cpu.weight 파일에 따라 각 CPU 시간을 비례합니다.

   하위 cgroup	cpu.weight file	CPU 시간 할당
   g1	150	~50% (150/300)
   g2	100	~33% (100/300)
   g3	50	~16% (50/300)

   cpu.weight 컨트롤러 파일의 값은 백분율이 아닙니다.

   한 프로세스가 중단되어 cgroup g2 에 실행 중인 프로세스가 없으면 계산에서는 cgroup g2 가 생략되고 cgroup g 1 및 g 3 의 가중치만 줄어듭니다:

   하위 cgroup	cpu.weight file	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 33 377 의 CPU 리소스가 해당 하위 cgroup에 할당된 가중치 150, 100, 50에 따라 할당되었습니다. 가중치는 각 애플리케이션의 CPU 시간을 약 50%, 33%, 16%에 해당합니다.

절차

1. 서비스의 메모리 사용량을 제한하려면 다음과 같이 /usr/lib/systemd/system/example.service 파일을 수정합니다.

   …​
   [Service]
   MemoryMax=1500K
   …​

   위의 구성에서는 제어 그룹에서 실행되는 프로세스의 최대 메모리 사용 제한( 예.service )을 배치합니다.

   참고

   K, M, G 또는 T 접미사를 사용하여 킬로바이트, 킬로바이트, 기가바이트 또는 테라바이트를 측정 단위로 식별합니다.

2. 모든 장치 구성 파일을 다시 로드합니다.

   # systemctl daemon-reload

3. 서비스를 다시 시작하십시오.

   # systemctl restart example.service

4. 시스템을 재부팅합니다.

5. 선택적으로 변경 사항이 적용되었는지 확인합니다.

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

   예제 출력에서는 메모리 사용량이 약 1,500KB로 제한되었음을 보여줍니다.

   참고

   memory.limit_in_bytes 파일은 메모리 제한을 AMD64 및 Intel 64에 고유한 4096바이트의 배수로 저장합니다. 실제 바이트 수는 CPU 아키텍처에 따라 다릅니다.