Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
25.3. ABRT 구성
문제 라이프사이클은 ABRT 의 이벤트에 의해 구동됩니다. 예를 들면 다음과 같습니다.
- 이벤트 #1 - problem-data 디렉터리가 생성됩니다.
- 이벤트 #2 - 문제 데이터가 분석됩니다.
- 이벤트 #3 - 문제는 Bugzilla에 보고됩니다.
문제가 감지될 때마다 ABRT 는 기존 문제 데이터와 이를 비교하고 동일한 문제가 이미 기록되었는지 확인합니다. 존재하는 경우 기존 문제 데이터가 업데이트되고 최근 (duplicate) 문제는 다시 기록되지 않습니다. ABRT 에서 문제를 인식하지 못하는 경우 problem-data 디렉터리 가 생성됩니다. 일반적으로 problem-data 디렉터리는 Analyzer,architecture,coredump,cmdline,실행 가능,커널,os_release,reason,time, uid 와 같은 파일로 구성됩니다.
backtrace 와 같은 기타 파일은 사용 중인 Analyzer 방법과 구성 설정에 따라 문제를 분석하는 동안 생성할 수 있습니다. 이러한 각 파일은 시스템과 문제 자체에 대한 특정 정보를 보유합니다. 예를 들어 커널 파일은 충돌한 커널 버전을 기록합니다.
problem-data 디렉터리가 생성되고 수집된 문제 데이터를 생성한 후 ABRT GUI 또는 명령줄에 대한 abrt-cli 유틸리티를 사용하여 문제를 처리할 수 있습니다. 기록된 문제 작업에 제공된 ABRT 도구에 대한 자세한 내용은 25.5절. “발견된 문제 처리” 를 참조하십시오.
25.3.1. 이벤트 구성
ABRT 이벤트는 플러그인 을 사용하여 실제 보고 작업을 수행합니다. 플러그인은 문제가 있는 디렉터리의 콘텐츠를 처리하기 위해 이벤트를 호출하는 압축 유틸리티입니다. 플러그인을 사용하면 ABRT 는 다양한 대상에 문제를 보고할 수 있으며 거의 모든 보고 대상에는 약간의 구성이 필요합니다. 예를 들어 Bugzilla에는 Bugzilla 서비스의 인스턴스를 가리키는 사용자 이름, 암호 및 URL 이 필요합니다.
일부 구성 세부 정보에는 기본값(예: Bugzilla URL)이 있을 수 있지만 다른 구성 세부 정보에는 적절한 기본값(예: 사용자 이름)은 사용할 수 없습니다. ABRT 는 /etc/libreport/events/ 또는 $HOME/ 디렉토리에서 각각 시스템 수준 또는 사용자별 설정의 구성 파일에서 이러한 설정을 찾습니다. 구성 파일에는 지시문과 값 쌍이 포함되어 있습니다.
. cache/abrt/events/
이러한 파일은 이벤트를 실행하고 problem-data 디렉토리를 처리하는 데 필요한 최소한의 파일입니다. gnome-abrt 및 abrt-cli 툴은 이러한 파일의 구성 데이터를 읽고 실행하는 이벤트에 전달합니다.
이벤트에 대한 추가 정보(예: 해당 설명, 이름, 환경 변수로 전달할 수 있는 매개변수 유형)는 /usr/share/libreport/events/ 디렉터리에 event_name.xml 파일에 저장됩니다. 이러한 파일은 gnome-abrt 와 abrt-cli 둘 다 사용자 인터페이스를 보다 쉽게 만드는 데 사용됩니다. 표준 설치를 수정하려는 경우가 아니면 이러한 파일을 편집하지 마십시오. 이 작업을 수행하려는 경우 수정할 파일을 /etc/libreport/events/ 디렉토리에 복사하고 새 파일을 수정합니다. 이러한 파일에는 다음 정보가 포함될 수 있습니다.
- 사용자에게 친숙한 이벤트 이름 및 설명(Bugzilla, Bugzilla에 보고서)
- 이벤트가 성공하는 데 필요한 problem-data 디렉터리의 항목 목록
- 보낼 기본 항목 및 필수 선택 사항입니다.
- GUI 에서 데이터 검토를 요청하는지 여부
- GUI 에서 적절한 구성 옵션을 빌드할 수 있도록 하는 구성 옵션, 유형(문자열, 부울 등), 기본값, 프롬프트 문자열 등이 있습니다.
예를 들어 report_Logger 이벤트는 출력 파일 이름을 매개 변수로 허용합니다. 각각의 event_name.xml 파일을 사용하여 ABRT GUI는 선택된 이벤트에 대해 지정할 수 있는 매개 변수를 결정하고 사용자가 이러한 매개변수에 대한 값을 설정할 수 있습니다. 값은 ABRT GUI에 의해 저장되고 이러한 이벤트의 후속 호출에 재사용됩니다. ABRT GUI는 GNOME 키 링 도구를 사용하여 구성 옵션을 저장하고 이벤트에 전달하여 텍스트 구성 파일의 데이터를 덮어씁니다.
그래픽 구성 창을 열려면 gnome-abrt 애플리케이션의 실행 중인 인스턴스 내에서 → → → → 선택합니다. 이 창에는 GUI 를 사용할 때 보고 프로세스 중에 선택할 수 있는 이벤트 목록이 표시됩니다. 구성 가능한 이벤트 중 하나를 선택하면 버튼을 클릭하고 해당 이벤트의 설정을 수정할 수 있습니다.
그림 25.1. ABRT 이벤트 구성
/etc/libreport/ 디렉토리 계층에 있는 모든 파일은 사용자가 읽을 수 있으며 전역 설정으로 사용해야 합니다. 따라서 사용자 이름, 암호 또는 기타 중요한 데이터를 저장하는 것이 좋습니다. 사용자별 설정( GUI 애플리케이션의 설정 및 $HOME 전용 소유자에 의해 읽기)은 GNOME 키링 에 안전하게 저장되거나, abrt-cli 와 함께 사용하기 위해 $HOME/.abrt/ 의 텍스트 구성 파일에 저장할 수 있습니다.
다음 표는 ABRT 의 표준 설치에 의해 제공되는 기본 분석, 수집 및 보고 이벤트의 선택을 보여줍니다. 표에는 각 이벤트 이름, 식별자, /etc/libreport/events.d/ 디렉터리의 구성 파일, 간단한 설명이 나열됩니다. 구성 파일은 이벤트 식별자를 사용하지만 ABRT GUI는 해당 이름을 사용하여 개별 이벤트를 참조합니다. 또한 GUI 를 사용하여 모든 이벤트를 설정할 수 있는 것은 아닙니다. 사용자 지정 이벤트를 정의하는 방법에 대한 자세한 내용은 25.3.2절. “사용자 지정 이벤트 생성” 을 참조하십시오.
표 25.1. 표준 ABRT 이벤트
| 이름 | 식별자 및 구성 파일 | 설명 |
|---|---|---|
| uReport | report_uReport | octetsReport를 FAF 서버에 업로드합니다. |
| mailx | report_Mailx
| Mailx 유틸리티를 통해 문제 보고서를 지정된 이메일 주소로 보냅니다. |
| Bugzilla | report_Bugzilla
| Bugzilla 버그 추적기의 지정된 설치에 문제를 보고합니다. |
| Red Hat 고객 지원 | report_RHTSupport
| Red Hat 기술 지원 시스템에 문제를 보고합니다. |
| C 또는 C++ Crash 분석 | analyze_CCpp
| 분석을 위해 코어 덤프를 원격 역추적 서버로 전송하거나 원격에 실패하는 경우 로컬 분석을 수행합니다. |
| 보고서 업로드기 | report_Uploader
|
문제 데이터가 있는 tarball( |
| VM 코어 분석 | analyze_VMcore
|
커널 oops의 문제 데이터에서 GDB (GNU 디버거)를 실행하고 커널의 |
| 로컬 GNU Debugger | analyze_LocalGDB
|
애플리케이션의 문제 데이터에서 GDB (GNU 디버거)를 실행하고 프로그램의 |
| .xsession-errors 수집 | analyze_xsession_errors
|
관련 행을 |
| logger | report_Logger
| 문제 보고서를 생성하여 지정된 로컬 파일에 저장합니다. |
| kerneloops.org | report_Kerneloops
| kerneloops.org의 oops 추적기에 커널 문제를 보냅니다. |
25.3.2. 사용자 지정 이벤트 생성
각 이벤트는 각 구성 파일에서 하나의 규칙 구조에 의해 정의됩니다. 구성 파일은 일반적으로 /etc/libreport/events.d/ 디렉터리에 저장됩니다. 이러한 구성 파일은 기본 구성 파일 /etc/libreport/report_event.conf 에 의해 로드됩니다. abrt는 /etc/libreport/events.d/ 에 포함된 스크립트를 실행하므로 기본 구성 파일을 편집할 필요가 없습니다. 이 파일은 쉘 메타 문자(예: *, $, ?)를 수락하고 해당 위치에 상대적으로 상대 경로를 해석합니다.
각 규칙은 공백이 아닌 문자로 시작하는 줄로 시작하며 공백 문자 또는 탭 문자로 시작하는 모든 후속 줄은 이 규칙의 일부로 간주됩니다. 각 규칙은 조건 부분인 두 부분, 즉 프로그램 부분으로 구성됩니다. 조건 부분에는 다음 형식 중 하나에 있는 조건이 포함됩니다.
- VAR=VAL
- VAR!=VAL
- VAL~=REGEX
다음과 같습니다.
-
VAR 은 EventsENT 키 단어의 이름이나 problem-data 디렉터리 요소의 이름(예:
실행 가능,패키지,호스트이름 등)입니다. - VAL 은 이벤트 또는 problem-data 요소의 이름입니다.
- REGEX 는 정규식입니다.
프로그램 부분은 프로그램 이름 및 쉘 해석 코드로 구성됩니다. 조건 부분의 모든 조건이 유효한 경우 프로그램 부분은 쉘에서 실행됩니다. 다음은 이벤트 예입니다.
EVENT=post-create date > /tmp/dt
echo $HOSTNAME uname -r
이 이벤트는 /tmp/dt 파일의 내용을 현재 날짜와 시간으로 덮어쓰고 표준 출력에서 시스템의 호스트 이름과 해당 커널 버전을 출력합니다.
다음은 실제로 사전 정의된 이벤트 중 하나인 더 복잡한 이벤트의 예입니다. 충돌 시 X11 라이브러리가 로드된 경우, abrt-ccpp 서비스가 사용된 문제의 문제 보고서에 관련 행을 ~/.xsession-errors 파일에 저장합니다.
EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=./libX11.
test -f ~/.xsession-errors || { echo "No ~/.xsession-errors"; exit 1; }
test -r ~/.xsession-errors || { echo "Can't read ~/.xsession-errors"; exit 1; }
executable=cat executable &&
base_executable=${executable##*/} &&
grep -F -e "$base_executable" ~/.xsession-errors | tail -999 >xsession_errors &&
echo "Element 'xsession_errors' saved"
가능한 이벤트 세트는 확정되지 않습니다. 시스템 관리자는 /etc/libreport/events.d/ 디렉토리에 필요에 따라 이벤트를 추가할 수 있습니다.
현재 다음 이벤트 이름에는 표준 ABRT 및 libreport 설치가 제공됩니다.
post-create-
이 이벤트는 새로 생성된 problem-data 디렉토리를 처리하기 위해
abrtd에 의해 실행됩니다.post-create이벤트가 실행되면abrtd는 새 문제 데이터가 이미 존재하는 문제 디렉터리 중 하나와 일치하는지 확인합니다. 이러한 문제 디렉터리가 있는 경우 업데이트되며 새 문제 데이터가 삭제됩니다.post-create이벤트 정의의 스크립트가 0이 아닌 값으로 종료되면abrtd는 프로세스를 종료하고 문제 데이터를 삭제합니다. notify,notify-dup-
알림이벤트는생성 후실행됩니다. 이벤트가 실행되면 사용자는 문제가 주의를 받을 자격이 있는지 확인할 수 있습니다. 동일한 문제의 중복 발생에 사용되는 경우를 제외하고 알림은 비슷합니다. analyze_name_suffix-
여기서 name_suffix 는 이벤트 이름의 교체 가능한 부분입니다. 이 이벤트는 수집된 데이터를 처리하는 데 사용됩니다. 예를 들어
analyze_LocalGDB이벤트는GDB(GNU Debugger) 유틸리티를 사용하여 애플리케이션의 코어 덤프를 처리하고 충돌의 역추적을 생성합니다. collect_name_suffix{blank}여기서 name_suffix 는 이벤트 이름의 조정 가능한 부분입니다. 이 이벤트는 문제에 대한 추가 정보를 수집하는 데 사용됩니다.
report_name_suffix{blank}여기서 name_suffix 는 이벤트 이름의 조정 가능한 부분입니다. 이 이벤트는 문제를 보고하는 데 사용됩니다.
25.3.3. 자동 보고 설정
ABRT 는 초기 익명 보고서 또는 감지된 문제 또는 사용자 상호 작용 없이 자동으로 감지된 문제 또는 충돌을 보내도록 구성할 수 있습니다. 자동 보고가 켜지면 일반적으로 충돌 보고 프로세스의 시작 부분에 전송되는 keepalivedReport라고 하는 자동 보고가 감지된 직후 전송됩니다. 이렇게 하면 동일한 충돌에 따라 중복 지원 케이스가 발생하지 않습니다. 자동 보고 기능을 활성화하려면 root 로 다음 명령을 실행합니다.
~]# abrt-auto-reporting enabled
위의 명령은 /etc/abrt/abrt.conf 구성 파일의 AutoreportingEnabled 지시문을 yes 로 설정합니다. 이 시스템 전체 설정은 시스템의 모든 사용자에게 적용됩니다. 이 옵션을 활성화하면 그래픽 데스크탑 환경에서 자동 보고도 활성화됩니다. ABRT GUI에서 자동 보고를 활성화하려면 문제 보고 구성 창에서 자동으로 uReport 옵션을 YES 로 전환합니다. 이 창을 열려면 gnome-abrt 애플리케이션의 실행 중인 인스턴스 내에서 → → → → 구성을 선택합니다. 애플리케이션을 시작하려면 → → → → → → 으로 이동합니다.
그림 25.2. ABRT 문제 보고 구성
충돌 탐지 시 ABRT 는 Red Hat의 ABRT 서버에 대한 기본 정보와 함께 octetsReport를 제출합니다. 서버는 문제를 알 수 있는지 여부를 확인하고, 알려진 경우 보고된 케이스의 URL 과 함께 문제에 대한 간단한 설명을 제공하거나 알 수 없는 경우 사용자에게 보고하도록 초대합니다.
octetsReport(microreport)는 문제를 나타내는 JSON 오브젝트(예: 바이너리 충돌 또는 커널 oops)입니다. 이러한 보고서는 짧고 머신에서 읽을 수 있는 완전한 익명이 되도록 설계되었으므로 자동화된 보고에 사용할 수 있습니다. octetsReports는 버그 발생을 추적할 수 있지만 일반적으로 엔지니어가 버그를 수정할 수 있는 충분한 정보를 제공하지 않습니다. 지원 케이스를 개설하려면 전체 버그 보고서가 필요합니다.
octetsReport를 전송하지 못하도록 자동 보고 기능의 기본 동작을 변경하려면 /etc/abrt/abrt.conf 구성 파일의 AutoreportingEvent 지시문 값을 수정하여 다른 ABRT 이벤트를 가리키도록 합니다. 표준 이벤트 개요는 표 25.1. “표준 ABRT 이벤트” 을 참조하십시오.
