'abrt'에 해당되는 글 3건

  1. 2010.05.27 :: ABRT 사용하기 (3)
  2. 2010.05.08 :: ABRT 의 크래쉬가 발생 될 경우...?
  3. 2010.05.08 :: Gnome-screensaver 2.28.3-1.fc12 Crash 문제..
Skills/mY Technutz 2010. 5. 27. 01:09
일전에 잠깐 소개했던 ABRT 에 대한 핸들링을 좀 간략하게 적어볼까 한다.

일차적으로 CLI 를 이용한 쉘에서의 분석이다.

일단 abrt 는 커널 2.6.30 이후부터 (정확하겐 모르겠다) 즉, RHEL6 에서 기본 크래쉬 관리 도구로 사용되는,

자동 버그 리포팅 툴이다.

이것은 큰 기능은 없지만, 어플리케이션 뿐만아닌, 커널 레벨의 모든 크래쉬를 감지,

코어파일을 생성하여 일련번호를 할당하여 관리할 수 있게 한다.

물론 이걸 이용해 분석도 할 수 있고, 간단하게 bugzilla 등에 리포팅 할 수 도 있다.

이것에 대한 얘기는 총 세개의 글로 나누어 설명할 예정이다.

abrt 의 사용을 위해서는 abrtd 라는 데몬이 실행되야 하며, 특정 커널 이후로는 필수 실행데몬이다.

cli (쉘) 에서의 명령어는 abrt-cli 로, 간단하게 몇가지 옵션위주로 설명하겠다.

[mirr@Mirr Document]$abrt-cli --get-list
0.
    UID        : 500
    UUID       : 7934db0508363522625da8ef236db612fa7af2d3
    Package    : gnome-terminal-2.28.2-1.fc12
    Executable : /usr/bin/gnome-terminal
    Crash Time : 2010년 04월 16일 (금) 오후 12시 14분 35초
    Crash Count: 1
1.
    UID        : 500
    UUID       : 4d66c3c61860827f892facad0e7e38e878ac97c5
    Package    : gnome-screensaver-2.28.3-1.fc12
    Executable : /usr/libexec/gnome-screensaver/slideshow
    Crash Time : 2010년 05월 02일 (일) 오후 09시 54분 24초
    Crash Count: 3
...................................
............중략 ...............

7.
    UID        : 500
    UUID       : 23ab4764de849a8166e74e0a1a51f5b7052d47e6
    Package    : abrt-gui-1.0.9-2.fc12
    Executable : /usr/bin/abrt-applet
    Crash Time : 2010년 05월 08일 (토) 오후 05시 41분 32초
    Crash Count: 1
8.
    UID        : 500
    UUID       : f5694f7625c378966ade0589333c19fd13f74e07
    Package    : compiz-0.8.2-24.fc12
    Executable : /usr/bin/compiz
    Crash Time : 2010년 05월 12일 (수) 오전 09시 09분 43초
    Crash Count: 1
9.
    UID        : 500
    UUID       : c90bebaca19d364eef0c133f742478731cf9f1a1
    Package    : twitux-0.69-4.fc12
    Executable : /usr/bin/twitux
    Crash Time : 2010년 05월 24일 (월) 오전 09시 38분 26초
    Crash Count: 1
10.
    UID        : 500
    UUID       : f04092400057d11de3876cce9246844aa663ee43
    Package    : firefox-3.5.9-2.fc12
    Executable : /usr/lib/firefox-3.5/firefox
    Crash Time : 2010년 05월 26일 (수) 오전 10시 04분 40초
    Crash Count: 1

보다시피 0번부터 발생되고, 감지된 모든 크래쉬를 쭉 나열해 준다.

유저레벨에서도 사용이 가능한점이 특징이다라고 할 수 있고,

루트의 경우 커널크래쉬 혹은 커널 워닝 레벨까지 보여준다 (와우~)

직관적이므로 설명이 깊이는 필요없을거라 생각하지만..

일단 프로그램이 실행된 UID, 그리고 프로그램 코어 발생을 구분해주는 UUID,

문제 유발 프로그램의 패키지, 실행파일, Crash 발생 시간, 그리고 Crash 횟수이다.

자 이제 리스트를 받았으면 내용을 봐야지..

[mirr@Mirr Document]$ abrt-cli --report `UUID` 또는 @Number`
>! crash '@0' is not in database
>! Can't find crash with id @0 in database

뭐 이런식으로 뜨면서 Stack Backtrace 장면이 펼쳐진다.

나오는건 중략하고 대략 vi 명령어 모드로 볼 수 있으며, 나오는건 역시 :q 나 :q! 를 사용하면 빠져나오고,

다음과 같이 버그 리포팅을 묻는다.

No changes were detected in the report.
Report using Bugzilla? [y/N]: n
Skipping...
Report using Logger? [y/N]: n
Skipping...
Crash reported via 0 plugins (0 errors)


매우 간단하지 않는가?

여기서 중요한건 코어에서 뽑을 수 있는 로그.. 즉, Backtrace 부분이 손쉽게 보여진다는 점으로,

이것들만 버그질라등에서 검색해도 많은 힌트를 얻을 수 있다.

버그질라에 보고하기 위해서는 계정이 필요하다.

이제 ABRT 를 이용하여, 손쉽게 버그를 핸들링 및 리포팅 하자.

두번째 장에서는 GUI 로 다뤄 볼 예정이다.

PS : 스프링놋흐에서 좀 더 자세히 작성될 예정이다.




posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply

    비밀댓글입니다

    2010.06.10 17:17
  2.  Addr  Edit/Del  Reply

    비밀댓글입니다

    2010.06.14 13:46
  3.  Addr  Edit/Del  Reply

    비밀댓글입니다

    2010.06.22 16:06

Skills/System 2010. 5. 8. 17:55
abrtd 를 Signal 6 로 죽여봤는데 안남는다.... ㅠㅠ

그러나 코어파일은 생성된다.

abrtd 에는 abrtd 라는 리포팅 수집 및 발송 데몬과, Xwindows Applet 기반으로 돌아가는

abrt-applet 이렇게 두가지로 구성되어 있다.

abrt-applet 을 죽이는 경우 abrtd 에 수집이 되고, 리포팅을 쉽게 보거나 받을 수 있다.

그러나 Signal 을 강제로 받은건지 아닌지는 알 수 없고 (당연한가 :P) 덤프가 떨어질 때의

Snapshot 과 같은 상태만 남는다.

결국 이것은 사용자입장에서 간단한 힌트정도만 될 뿐

결국 코어덤프를 통한 Running Trace 가 필요할 것 같다는것...

그래서 screensaver 버그가 쉽게 잡히지 않는것 같다 ( 실제 실행시키고 locked 시킨 뒤 확인해야하므로 )

간만에 이번 주말 버닝할 흥미로운 녀석 발견.... :)

posted by mirr

댓글을 달아 주세요

Skills/System 2010. 5. 8. 16:38
아직 해결된건 아닌데, 실재로 리포팅 된건 3월달 인것 같다..

벌써 약 두달간 핸들링 되면서 아직까지 패치가 나오지 않고 있다는게 좀 의아하긴 하지만,

일단 이것에 대해서 커널 및 프로그래밍 공부차원에서 핸들링 해 가기로 목표를 정했다.

( 내 노트북을 켜놓고 몇시간 지나면 Crash 가 되버린다... 커널 크래쉬는 아닌것 같은데 시스템이

lock 상태에서 벗어나질 못해 리부팅할 수 밖에 없다. 작업자료들 ㅠㅠ )



사실 좀 더 쓰려고 했는데 시스템콜 뒤지고, 예전 레퍼런스 책들 다 끄집어 내서 찾는 중에

시스템이 또 패닉났고 이것저것 KVM 으로 가상머신에서 야동을 받다가 nspluginwrapper 부분에서

firefox 가 뻗기 시작했고, 이걸 해결하기위해 커널에서 hangup 된 Task 의 timeout 을 기다리는 동안

해결되지 않아 완전 뻗은것 같은 상태가 되버려서 리부팅하느라 더이상 글쓰기가 싫어졌다.. ㅠㅠ

커널 스텍트레이스 보니, soft lockup 문제일것 같다....

앞으로 차근차근 커널 공부를 위해 하나씩 써 나갈테니 기대는 너무 하지 마시길... 쓸 시간없다 ㅠㅠ

초반이라 두서없지만 틈틈히 정리할것이다.

스크린세이버 문제는 임시방편으로 일단 고정그림으로 해놔보긴 했는데 어찌될지는 또 봐야지... :(

posted by mirr

댓글을 달아 주세요