Skills/mY Technutz 2018.02.22 13:27

와.. 대박... 일이 엄청나게 들어와..

공격적으로 오라클 리눅스를 장사하면 내가 쓰일만한 일이 있긴 하구나 하면서도

일이 이렇게 많아지면 개빡쳐서 아무것도 하기 싫어지는 현자타임같은게 온다는..

무튼, 요즘 핫하게 밀려들어오는 업무량 덕에 코어분석 일도 숭풍숭풍 막 쳐 들어오는..

이번에는 레드햇 커널 즉, Oracle Linux 에서 Cmompatibility 를 위해 제공하는

Redhat Compatible Kernel ( RHCK ) 와 관련된 커널 덤프 분석을 해주시겠다.

Technical Preview 이기 때문에 해당 부분에 대한 코드는

ASSERTCMP(op->state, ==, FSCACHE_OP_ST_DEAD);

로 수정되는 식으로 상황을 정리하는 코드가 추가된 것 같다.
( 수정된 코드 다운받거나 찾기 귀찮다! 바쁘다. 점심안에 써야한다 글을. )

물론 픽스는 해당 fscache 모듈을 사용하지 않도록 하거나,

( cachefilesd 데몬을 Disable 한다. )

ELSA-2017-0307 또는 ELSA-2017-0817 ( RHSA-2017-0817 대응) 에서 권고하는

kernel-2.6.32-696.el6 이후의 최신 버젼으로 업그레이드 하거나

6.8 GA kernel-2.6.32-642.el6 이하 커널로 다운그레이드 하면 된다고

Redhat 에서 이야기 하는 것 같다.

사실 개인생각으로는 커널 업그레이드를 해봤자 동일할것 같긴 해서

구지 필요하지 않다면 Cachefilesd 를 Off 하는게 더 좋을것 같다고 생각된다.

mount option 에서 fsc 가 생겼는데 이게 없으면 자동으로 fscache 가 활성화 된다고 하는 것 같다.

레드햇 이슈라 명확하게 솔루션 코드가 확인되지 않는 상태라 잘 모르겠으나

분석 방법이랑 워크어라운드 기입되 있음 이미 난 충분히 세계를 위해 기여한거시다...

'Skills > mY Technutz' 카테고리의 다른 글

Kernel Dump Analysis #17  (0) 2019.04.04
libfc: Update rport reference counting bug - 1368175  (0) 2018.03.29
Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
Kernel Crash dump Analysis - #13  (0) 2017.12.20
posted by mirr

댓글을 달아 주세요

Skills/System 2017.04.03 17:44

흥미있는 버그를 발견했다.. 물론 알려진 버그인데,

분석하는 과정을 개인적으로 업데이트하고 공유한다.

이슈는 엑사데이타에서 사용하는 UEK2 (2.6.39-400.264.1) 커널의 crash 이다.

이는 사실상 Async/Direct IO 상태로 사용시 ext4 의 io end 처리 구조체 및 펑션에서

더블프리가 될 수 있는 버그로 알려져있으며 패치가 나와있다.

Fixed -> UEK2 2.6.39-400.277.1


posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2014.03.12 15:47

Kernel Crash 분석 업데이트 하나 더.


일이.... 있긴있는데, 분석하기 좀 집중안되는 놈이라 다른짓 하고 있음..


(우선순위가 이게 더 높기에 하고 있는거다. 절대 우선순위 무시하는법 없다... )


백업용도로 사용하는 몇개 서버군들중 두대의 서버가 비 동시적 시간에 Crash 되어


리붓되었다는 것이 배경...



사실, 이 과정만 보아서는 igxbe 드라이버가 Invalid data 를 넘겨주었기 때문인지,

애초에 Kernel 에서 skb allocation 에 논리적 이슈가 있었던 것인지 알 수 없으나,


어찌되었든, 둘다 커널에 포함되어 제공되는 Internal 부분이고,


Shipped driver 이며, allocation 이슈이기 때문에,


커널 Defect 로 판단되어 업그레이드나 픽스가 필요 한 상황...


(실제로 UEK2 커널의 sk_buff allocation 부분을 보면, memory allocation 체크하는 부분이

더 간결하게 정리되어 있다. )


게다가 역시나 이녀석도 UEK R1 인지라.... UEK Release 2 로 업그레이드를


하라는 것으로 가이드 할 수 밖에 없었다..........


이번엔 좀 더 Advanced crash 사용법을 보여준것 같아서.....


별로 뿌듯하진 않은데, 어차피 알아듣는 사람은 안알랴줌에도 스스로  깨우칠 것이고,


깨우치려 들지 않는 자는 알랴줌에도 깨우치지 못할 것이기에....


"밥줄" 좀 품....막 confidential 위반이라고 머라카면,

( 아... UEK 소스라인이 문제되려나? 근데 별반 차이 없는데 Vanila 커널이랑 ㅋ )


"옴마~? 앙대욤"



2014/01/06 - [Skills/System] - Kernel dump analysis about the bug called as "devide by zero"

2012/01/01 - [Skills/mY Technutz] - Kernel Dump Analysis #10



'Skills > mY Technutz' 카테고리의 다른 글

Kexec/Kdump 의 제약사항에 대해서  (4) 2016.01.14
Patch of Egypt timezone data - Urgent  (0) 2014.06.18
Kernel Dump Analysis - #11  (0) 2014.03.12
HAL 데몬 사용하기 (Simple)  (0) 2012.04.03
Enhanced Using Sar data collector  (1) 2012.03.18
Kernel Dump Analysis #10  (2) 2012.01.01
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2010.05.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.05.08 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.05.08 16:38
아직 해결된건 아닌데, 실재로 리포팅 된건 3월달 인것 같다..

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

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

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

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



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

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

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

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

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

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

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

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

posted by mirr

댓글을 달아 주세요

Skills/System 2009.12.16 19:51
http://mirr.springnote.com/pages/3300377
일단 분석중에 다시 다른 문제들이 생겼는데,

코어덤프내용과 추후에 생겨난 문제는 성질이 서로 달랐다.

먼저 메시지부터 스크린샷으로 보내줬었고,

64기가짜리 coredump 였기때문에 분석에 시간이 걸렸었기때문이다.

메모리 부분을 의심 한 뒤에 코어분석을 해봤더니 스토리지 관련 이슈도 있는것 같았다.

어쨋든 R 사에서 온 답변을 보자면
안녕하세요.

현재 계속 발생되는 상황으로 보아서는 사용하시는 시스템의 메모리에 문제가 있는것으로 보입니다.
설치 미디어를 이용해서 부팅하시면 메뉴중에 memtest가 있습니다.
이것을 이용해서 전체 메모리를 점검할 필요가 있겠습니다. 메모리에 대한 검사를 마치신 후에는
(상당히 오랜 시간이 걸립니다) 파일시스템도 점검해주시기 바랍니다.
또는 하드웨어 업체에서 제공하는 진단툴이 있으면 그것으로 테스트를 하셔도 됩니다.

감사합니다

라네요?? (자랑질??)

저번에 분석했었을땐 경험의 부족으로 인해 헛다리짚은 분석 결과를 내었었는데,

이번엔 동일한 답변을 받아 왠지 뿌듯하달까........

이로써 벌써 네가지의 케이스 완료.

( 모아논 vcore 덤프는 많은데 분석하기가 귀찮다..... )
posted by mirr

댓글을 달아 주세요

Skills/System 2009.05.05 02:15
아직 계속 정리중이지만 ( case by 부분 )

일단 crash 라는 커널덤프 분석도구의 강력함을 소개하기 위해 포스팅....

실제 문서는 스프링노트에 있다..... 커널 코어덤프 분석... 그 빡씨디 빡씬 세계 흑....

Kernel Crash Dump Analysis


'Skills > System' 카테고리의 다른 글

효율적 데이타베이스관리를 위한 MySQL 세미나..  (0) 2009.06.17
VMware Essential Plus 구축..  (0) 2009.06.17
커널 코어덤프 분석하기...  (0) 2009.05.05
advise path 메시지 로그  (0) 2009.04.22
CentOS 5.3 Released..  (0) 2009.04.01
QLogic HBA 2460 카드 Failover  (0) 2008.11.01
posted by mirr

댓글을 달아 주세요