Skills/mY Technutz 2014. 3. 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/System 2014. 1. 6. 14:17

자 막간을 이용해 간만에 kernel core dump 분석 들어간다...

사실 요즘 대박대박 대박사건으로 여러 사이트에서 터지고 있는 문제라,

뭐 보안이 필요한 부분인것도 아니고, patch 가 어차피 나와있으므로
( kspice 를 이용한 hot fix 이긴 하지만..)

과감하게 공개해 본다....



현재 Fixed kernel 버젼은 V2.6.32-400.34.1 이며, 아직 QA/Release ready 이다.

어렵다.. 아무튼, 해당 패치는 나와 있는 상태이지만, 릴리즈 된 각 커널마다,
또한 장비상황등등 마다 재발 가능성은 언제든지 있는 부분이기 때문에,
최신 official released kernel 로 업데이트 한후, ksplice 를 통한
추가적인 hot fix 를 적용해야 한다는 점!


ksplice 를 이용하면 커널에 대한 official release 가 나와있지 않은 상태에서,
리붓 없이 수정된 kernel space 로 교체, 사용이 가능하다.. 쯔앙!


끝. 짧고 간단하며, 일이 있는 상태에서도 이정도 글은 뭐.. 가능하다 ㅠㅠ
비슷한 이슈 보이는 Oracle Linux UEK 커널 사용자는 업데이트 꼭 하도록 하자.


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


posted by mirr

댓글을 달아 주세요

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

댓글을 달아 주세요

Skills/System 2010. 3. 5. 01:15
본 글은 스스로에게 어디까지 기술력을 보유해야 한다고 생각하는 건지 자문하는 글로써,
정리되지 않던 글들은 다시 정리하여 공개합니다. 문제가 되는 부분들은 언제든지 얘기해 주십시오.

어느정도 진행되는 동안 R 사의 GSS 에서는 고객의 의문사항들을 어느정도 답변 해 주고 있던 상태..

고객의 심도있던 Thread 와 메모리의 상관관계, VM split 모델에 대한 심도깊은 관계 (spilt 등 )

최대 스레드 값을 계산 할 수 있는 공식, Lowmempage 부족의 의미, Lowmem 부족상태에서

swap 이 사용되지 않는 경우, cache memory  와 swap 의 관계, 메모리 관리 ( linux-mm ) 알고리즘,

2.4 커널과 2.6 커널의 차이점 ( 나름 상세하게 - 메모리 관리에서부터 쭈~~~욱 )

paging 매카니즘 등등... 거의 세미나수준으로이지 않나 싶게..

GSS 에서는 나에게 전화로 혹시 세미나하는거냐고 매우 지원하는데 깊은 심도로 인해 어려움이 있었다고

난이도와 난감함을 우스개소리로 했을 정도.....ㅠㅠ

엔지니어레벨에서는 이해를 하겠으나 설명하기는 난감한 상황 발생...

어찌됐든 현재는 장애 재현이 강제로는 발생하지 않는 상황에 돌입하여버린것이다.

이 문제를 해결하기 위하여 우리는 고객에게 각종 리눅스 인터널적인 매카니즘 및 알고리즘들과,

OS 의 문제가 아님을 판명하려 노력해야 했다. ( 머리터지는줄 알았.... )

이런 이슈들로 인해 물론 나역시 많은걸 보고 배우며 생각하게 되긴 했는데,

이과정을 겪으면서 이상적으로 자문하게 되는 부분은

과연 SE 가 해결해 줄 수 있어야 하는 범위는 어디까지 인것일까? 라는 것...

고객은 Oops 커널이나, 커널 디버깅 모드를 설정하거나, 또는 빌드를 새로 하더라도,

커널 내부 메시지들을 로그 찍어 적극적인 해결을 요구하는 상황도 있을 수 있고...
( R 사에서는 커널이 수정되거나 개별 빌드하게 되면 지원이 중단된다 )

RHEL3 의 EOS 가 올 10월로 정해진 마당에, 계속 지원하는 엔지니어로써는 솔직히 환장할 일인 것이다.

인터널에 대해 궁금해 하면 할 수록 이해하고 설명하기가 더 힘들다는 점 역시 어디까지 공부해야하는지...휴~

과연 SE 로써, 커널의 상세 매카니즘들에 완벽하게 알 고 있어야 할 필요가 있을까? 라는 생각이

주를 이뤘던 나였기에 더더욱 자문하게 되는 부분....

Lowmem 영역에 DMA 가 포함되는 그 이유까지 알아야 할 필요가 있을까?

Lowmem pagetable 이 0 일 경우 Highmem pagetable 을 이용한다 정도까지면 되지,

어떻게 얼마나 매핑이 되는지 과연 심각하게 파고 들어야만 하는 것인가??

1G/3G 스플릿에 적용받는 커널은 일반커널과, SMP 이고, 64 비트의 경우 스플릿이 없으며,

Hugemem 커널의 경우 4/4G split 를 알 정도면 되는 것인가?

왜 그렇게 되는건지는 몰라도 되는가??

VM 끼리 연결이 어떻게 되는지는..??

Stack 사이즈와 Threads 의 관계만 알면 되지, 왜 Stack size 가 Threads 와 관계를 갖는 건지

알아야 하지 않는가 ????

내 생각엔 모두 'No' 였다. 알아두면 좋지만 꼭 알아야 할 필요는 없다고 생각했다.

SA ( system architect ) 가 아니라 engineer 이지 않는가? 엔지니어의 최대 목적은,

적절한 효율을 낼 수 있는 것이라고 생각한다.

장애에 대한 대비를 항시 하고, 예측하며, 발생시에는 원인분석에 걸리는 시간을 계산하여,

적절하고 효율적인 대처를 통해 장애 처리를 하여 서비스를 재개시키고, 장애가 재현되지 않도록

하는 것이 SE 라고 생각한다.

고로 장애 발생시에는 가상화이므로, 멀쩡한 VM 에서 클론을 후다닥 떠서 서비스를 재개한뒤 (가상화의 장점!)

원인분석을 위해, 장애가 있던 VM 을 가지고 실제 서비스와 비슷한 상태를 만들어 놓고,

발생되는 정상적인 core dump 를 분석요청 하는 것 정도까지가,

실제 엔지니어레벨에서 충분한 지원범위 였지 않았나 싶은데..또 그것도 정하기가 애매하다는....

가상화 환경이니만큼 시스템 장애시 복구 및 관리 혹은 deploy 가 수월하니,

구글이나 다른 서비스업체들에서 하듯이 동일 시스템을 바로 박아넣어 동작시키면 되는것이라곤 생각되는데..

엔지니어는 서비스가 열심히 돌아가게 해주는게 본분이라면

그럼 SA 까지 바라본다면 어떻게 해야하는거지????

결론은 끝이 없이 나오지 않겠지만........고민되는 부분이다 정말...

리눅스의 커널은 방대하고 심오하다. 커널의 개발자들도 각 매카니즘의 동작 원리를 파악하고,

남에게 설명해 주기에는 더 어렵고도 더 어려운 일인것 같다.

무엇보다 누가 그 깊은 부분들을 다 이해할 수 있을까??

나도 최근 커널공부를 위해 여러가지 준비중인 상태에서도 이해가 잘 안가는 부분들이 많은데....

시스템 엔지니어로써의 가장 필요한 마인드가 무엇인지 생각해 볼 필요가 있었다...

난 어디까지 가야 하는건가?? 어디까지 가려고 하는 건가??


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. 5. 5. 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

댓글을 달아 주세요