abrt를 이용한 Application Crash디버깅
Linux System
이번 글에서 다룰 내용은 abrt를 이용한 애플리케이션 디버깅 입니다. 애플리케이션 크래시 정보를 수집하기 위해 abrt 설정을 어떻게 변경해야 하는지, 그리고 크래시 정보를 어떻게 활용할 수 있을지에 대해 간단하게 살펴 보겠습니다.
abrt란?
abrt는 Automated Bug Reporting Tool의 약자이며 RHEL 계열의 리눅스 서버에 기본으로 설치되는 데몬 입니다. man 페이지를 볼까요?
abrtd is a daemon that watches for application crashes. When a crash occurs, it collects the problem data (core file, application’s command line etc.) and takes action according to the type of application that crashed and according to the configuration in the abrt.conf config file. There are plugins for various actions: for example to report the crash to Bugzilla, to mail the report, or to transfer the report via FTP or SCP. See the manual pages for the respective plugins.
네.. 그렇습니다.
abrt는 데몬의 형태로 띄워져서 애플리케이션에서 발생하는 크래쉬를 감지하고, 감지했을 경우 필요한 정보들을 수집해서 저장합니다.
그리고 이 정보들을 통해서 작성한 애플리케이션에 어떤 버그가 있는지를 확인할 수 있습니다.
하지만 기본 설정을 그대로 쓴다면 애플리케이션 크래쉬가 발생했을 때 아래와 같은 메세지를 보실 수 있으실 겁니다.
Aug 9 10:07:14 server abrt-server[31796]: Saved Python crash dump of pid 30911 to /var/spool/abrt/pyhook-2015-08-09-10:07:14-30911
Aug 9 10:07:14 server abrtd: Directory 'pyhook-2015-08-09-10:07:14-30911' creation detected
Aug 9 10:07:14 server abrtd: Executable '/usr/local/nagios_worker/nagios_worker.py' doesn't belong to any package and ProcessUnpackaged is set to 'no'
Aug 9 10:07:14 server abrtd: 'post-create' on '/var/spool/abrt/pyhook-2015-08-09-10:07:14-30911' exited with 1
Aug 9 10:07:14 server abrtd: Deleting problem directory '/var/spool/abrt/pyhook-2015-08-09-10:07:14-30911'
크래쉬를 감지하고 관련된 정보를 저장했으나, 어떤 이유에서인지 정보를 다시 삭제 합니다. 왜 그럴까요? 그 해답 역시 메세지에 있습니다.
doesn't belong to any package and ProcessUnpackaged is set to 'no'
바로 이부분, 크래쉬가 발생한 애플리케이션이 설치되어 있는 패키지에 포함되지 않았기 때문에 삭제가 되는 것 입니다.
그럼 설정 파일을 한 번 볼까요? 우리가 보려는 설정 파일은 /etc/abrt/abrt-action-save-package-data.conf 입니다.
/etc/abrt/abrt-action-save-package-data.conf아마 위 스크린샷 그대로 되어 있을텐데요, ProcessUnpackaged 부분의 설정이 바뀌어야 합니다. OpenGPGCheck 도 바뀌어야 하구요. 서버에서 운영되는 애플리케이션들은 패키지화 된 애플리케이션들도 있지만, 직접 개발해서 운영하는 애플리케이션들은 대부분 패키지화 되지 않고 실행 파일과 라이브러리들로 구성되어 있는 경우도 많기 때문 입니다.
그래서 두 값을 아래와 같이 수정 합니다.
OpenGPGCheck = no
ProcessUnpackaged = yes
그리고 abrtd를 재시작 해 줍니다. 이제 abrt가 모든 애플리케이션의 크래시 정보를 수집할 준비가 끝났습니다.
backtrace 파일을 통한 분석
애플리케이션에서 크래시가 발생하면 /var/spool/abrt 디렉터리 밑에 크래시가 발생한 시간 정보와 함께 디렉터리가 생성 됩니다.
/var/spool/abrt제가 만든 파이썬 스크립트가 2015-08-19 03:42:50에 크래시가 발생했군요. 해당 디렉터리로 들어 갑니다. 많은 파일들이 있지만 backtrace 파일만 보면 됩니다.
backtrace 파일네.. 저 시간에 Input/Output error가 발생했고 이 예외처리를 하지 못해서 결국 스크립트가 죽어 버렸네요. (backtrace 파일의 내용을 가지고 원인을 찾는 건 구글의 도움을 받으면 됩니다.)
그래서 이번엔 스크립트 안에 파일 I/O가 일어나는 부분에 try except 구문을 추가해서 예외 발생 시에도 죽지 않도록 수정 했습니다.
그리고 시간이 좀 지나니.. 또 크래시가 발생 했습니다. 역시 이번에도 backtrace 파일을 살펴 봅니다.
backtrace 두번째 파일아.. 이번엔 POST method를 통한 REST API 호출 하는 과정에서 커넥션 타임 아웃에 대한 예외 처리를 하지 못했네요.. 저 부분도 예외 처리 구문을 추가 했습니다.
간단하게 abrt 설정과 실제 크래시가 발생한 스크립트의 내용을 참고해 가면서 설명을 드렸는데요, 보시면 아시겠지만 꽤 유용한 정보를 볼 수 있습니다.
어디서 문제가 발생했는지 충분히 찾을 수 있을 만큼의 정보가 주어지기 때문에 abrt를 활용하면 개발한 애플리케이션의 어느 부분에 문제가 발생했는지를 손쉽게 찾아볼 수 있습니다.
기본 설정으로 사용하게 되면 이런 좋은 기능을 사용할 수 없으니 꼭 변경하셔서 사용하시기 바랍니다.
