25.4. 소프트웨어 문제 탐지

abrt-ccpp 서비스는 자체 core-dump 처리기를 설치합니다. 이 핸들러는 커널의 core_ octets 변수의 기본값을 덮어씁니다. 그러면 C 및 C++ 충돌은 abrtd 에서 처리합니다. abrt-ccpp 서비스를 중지하면 이전에 지정된 core_octets 값이 복원 됩니다.

기본적으로 /proc/sys/kernel/ core _ octets 파일에는 코어 코어가 포함되어 있습니다. 즉, 커널이 충돌한 프로세스의 현재 디렉터리에 core. 접두사가 있는 파일을 생성합니다. abrt-ccpp 서비스는 core_hiera 파일을 덮어쓰고 다음 명령을 포함합니다.

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

이 명령은 코어 덤프를 abrt-hook-ccpp 프로그램으로 전달하여 ABRT의 덤프 위치에 저장하고 새 크래시의 abrtd 데몬을 알리는 것을 커널에 지시합니다. 또한 디버깅을 위해 /proc/PID/ 디렉터리(여기서 PID 는 충돌된 프로세스의 ID)에서 다음 파일을 저장합니다. map,limits,cgroup,status. 형식에 대한 설명과 이러한 파일의 의미는 proc(5)를 참조하십시오.

abrt-addon-python 패키지는 Python 애플리케이션에 대한 사용자 정의 예외 핸들러를 설치합니다. 그런 다음 Python 인터프리터는 /usr/lib64/python2.7/site-packages/ 에 설치된 abrt.pth 파일을 자동으로 가져옵니다. 그러면 abrt_exception_handler.py 가 자동으로 가져옵니다. 이렇게 하면 Socket API를 통해 처리되지 않은 예외를 abrtd 로 전달하는 사용자 정의 처리기를 사용하여 Python의 기본 sys.excepthook 가 재정의됩니다.

사이트별 모듈의 자동 가져오기를 비활성화하여 Python 애플리케이션을 실행할 때 ABRT 사용자 지정 예외 핸들러가 사용되지 않도록 하려면 -S 옵션을 Python 인터프리터에 전달합니다.

~]$ python -S file.py

위의 명령에서 file.py 를 사이트별 모듈을 사용하지 않고 실행하려는 Python 스크립트의 이름으로 바꿉니다.

rubygem-abrt 패키지는 프로그램이 종료될 때 실행되는 at_exit 기능을 사용하여 사용자 정의 핸들러를 등록합니다. 이를 통해 처리되지 않은 가능한 예외를 확인할 수 있습니다. 처리되지 않은 예외가 캡처될 때마다 ABRT 핸들러는 표준 ABRT 툴을 사용하여 Red Hat Bugzilla에 제출할 수 있는 버그 보고서를 준비합니다.

ABRT Java Connector는 예기치 않은 Java 예외를 abrtd 에 보고하는 JVM 에이전트입니다. 에이전트는 여러 JVMTI 이벤트 콜백을 등록하며 -agentlib 명령줄 매개 변수를 사용하여 JVM 에 로드해야 합니다. 등록된 콜백의 처리는 애플리케이션의 성능에 부정적인 영향을 미칩니다. 다음 명령을 사용하여 ABRT catch 예외를 Java 클래스로 가져옵니다.

~]$ java -agentlib:abrt-java-connector=abrt=on $MyClass -platform.jvmtiSupported true

위의 명령에서 $MyClass 를 테스트하려는 Java 클래스의 이름으로 바꿉니다. abrt=on 옵션을 커넥터에 전달하면 abrtd 에서 예외를 처리해야 합니다. 커넥터가 표준 출력에 예외를 출력하도록 하려면 이 옵션을 생략합니다.

abrt-xorg 서비스는 /var/log/Xorg .0.log파일에서 X.Org 서버 의 충돌에 대한 정보를 수집하고 처리합니다. 블랙리스트로 지정된 X.org 모듈이 로드되면 보고서가 생성되지 않습니다. 대신 적절한 설명을 사용하여 보고할 수 없는 파일이 problem-data 디렉터리에 생성됩니다. /etc/abrt/plugins/xorg.conf 파일에서 잘못된 모듈 목록을 찾을 수 있습니다. 독점형 그래픽 드라이버 모듈만 기본적으로 블랙리스트에 추가됩니다.

커널 로그 출력을 확인함으로써 ABRT 는 so- called kernel oopses - Linux 커널의 올바른 동작에서 치명적이지 않은 변동을 포착하고 처리할 수 있습니다. 이 기능은 abrt-oops 서비스에서 제공합니다.

ABRT 는 또한 abrt-vmcore 서비스를 사용하여 재부팅이 필요한 치명적이고 복구할 수 없는 오류인 커널 패닉을 감지하고 처리할 수 있습니다. 이 서비스는 vmcore 파일(커널 코어 덤프)이 /var/crash/ 디렉터리에 표시되는 경우에만 시작됩니다. core-dump 파일이 발견되면 abrt-vmcore 에서 /var/spool/abrt/ 디렉터리에 새 problem-data 디렉터리를 생성하고 core-dump 파일을 새로 생성된 problem-data 디렉터리에 복사합니다. /var/crash/ 디렉토리를 검색하면 서비스가 중지됩니다.

ABRT 가 커널 패닉을 감지하려면 시스템에서 kdump 서비스를 활성화해야 합니다. kdump 커널용으로 예약된 메모리 양을 올바르게 설정해야 합니다. system-config-kdump 그래픽 도구를 사용하거나 GRUB 2 메뉴의 커널 옵션 목록에 crashkernel 매개변수를 지정하여 설정할 수 있습니다. kdump 를 활성화 및 구성하는 방법에 대한 자세한 내용은 Red Hat Enterprise Linux 7 Kernel Crash Dump Guide 를 참조하십시오. GRUB 2 메뉴를 변경하는 방법에 대한 자세한 내용은 26장. Working with GRUB 2 를 참조하십시오.

abrt-pstoreoops 서비스를 사용하여 ABRT 는 커널 패닉에 대한 정보를 수집하고 처리할 수 있으며, 이는 pstore 를 지원하는 시스템에서 자동으로 마운트된 /sys/fs/pstore/ 디렉토리에 저장됩니다. 플랫폼 종속 pstore 인터페이스(영구 스토리지)는 시스템 재부팅 사이에 데이터를 저장하는 메커니즘을 제공하므로 커널 패닉 정보를 유지할 수 있습니다. 커널 크래시 덤프 파일이 /sys/fs/pstore/ 디렉터리에 표시되면 서비스가 자동으로 시작됩니다.