일반적으로 리눅스에서 NMI 신호를 받게 되는 경우에는 크가 두가지 경우로 나타낼수 
있습니다. 

첫번째 : 커널에서 NMI_WATCHDOG을 활성화 했을 경우.. 
두번째 : 자체 하드웨어에서 NMI_WATCHDOG 신호를 사용하게 되는 경우 

일반적으로 하드웨어에서 발생시킨 NMI 신호의 경우 불특정 부하가 발생하거나, 하드웨어
자체적인 이상이 발생했을 경우 NMI Interrupt 신호를 발생시키게 되는데, 간혹 펌웨어나 
BIOS상에서 버그로 인해서 강제적으로 시스템을 재부팅 시키는 경우가, 발생하는 경우가 
있는데, know-issue 이기는 하지만 일반적으로 운영할때 발생할수 있는 상황이여서 정리해 봅니다. 


1. 커널 패닉 원인 (Root Cause)

HP DL380 G8 장비에서 자동으로 Rebooting 되는 원인으로는 HP DL380 G8 장비에서
발생된 NMI 신호를 커널 수신하여 NMI watchdog 메세지와 함께 커널 Panic을 발생.

NMI의 신호의 경우 커널에서 NMI_WATCHDOG=0 처리를 하지 않아도 HP 서버는  NMI Handler 기능을 가지고 있기 때문에 하드웨어 자체적으로 인터럽트 신호를 주기적으로
보내 시스템의 이상 여부를 확인하게 됨


2. vmcore Kernel Panic trace

Red Hat으로 Escallation 된 vmcore를 trace 한결과 아래아 같이 HP IML로 인한 NMI로 인해 커널 패닉이 발생되었음을 확인가능. 

crash> sys 

 KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux

    DUMPFILE: /var/crash/vmcore  [PARTIAL DUMP]
        CPUS: 12
        DATE: Tue Mar 11 11:26:52 2014
      UPTIME: 14 days, 21:28:40
LOAD AVERAGE: 0.20, 0.21, 0.18
       TASKS: 585
    NODENAME: mzeus02
     RELEASE: 2.6.32-358.6.2.el6.x86_64
     VERSION: #1 SMP Tue May 14 15:48:21 EDT 2013
     MACHINE: x86_64  (2892 Mhz)
      MEMORY: 24 GB
       PANIC: "Kernel panic - not syncing: An NMI occurred, please see the Integrated Management Log for details


또한 커널에서 FIFO 스택에 대한 Back trace 에서도  아래와 같이 hpwdt_pretimeout에
대한 Status를 확인

즉 NMI 신호에 대해서 선점하지 못하고 대기하고 있다가 일정 시점에서 NMI Interrupt 신호를 받지 못하면 시스템을 Hangup으로 간주하여 강제로 재부팅을 하게 되고 현재 설정된 kdump 구성으로 인해서 vmcore를 발생. 

crash> bt -t

PID: 0      TASK: ffffffff81a8d020  CPU: 0   COMMAND: "swapper"
              START: crash_kexec at ffffffff810c0dd2
  [ffff880036607d30] crash_kexec at ffffffff810c0dd2
  [ffff880036607db0] show_trace at ffffffff8100f275
  [ffff880036607db8] do_kimage_alloc at ffffffff810c0e5f
  [ffff880036607e00] schedule at ffffffff8150d47f
  [ffff880036607e30] arch_prepare_kprobe at ffffffff81513056
  [ffff880036607e80] hpwdt_pretimeout at ffffffffa01054cd [hpwdt]
  [ffff880036607e90] trampoline_handler at ffffffff81511b99
  [ffff880036607ea0] opt_pre_handler at ffffffff81513685
  [ffff880036607ee0] opt_pre_handler at ffffffff815136ea
  [ffff880036607ef0] srcu_init_notifier_head at ffffffff8109cc1e
  [ffff880036607f20] oops_begin at ffffffff815112c1
  [ffff880036607f50] do_general_protection at ffffffff81510c10
    [exception RIP: format_decode+837]
    RIP: ffffffff8127f585  RSP: ffff880036603c98  RFLAGS: 00000046
    RAX: ffffffff817e8e72  RBX: ffffffff81eacf29  RCX: 0000000000000000
    RDX: 0000000000000078  RSI: ffff880036603ce8  RDI: ffffffff817e8e71
    RBP: ffff880036603c98   R8: 0000000000000078   R9: ffffffff81a01e58
    R10: 0000000000000000  R11: 0000000000000001  R12: ffffffff817e8e71
    R13: ffffffff817e8e71  R14: ffff880036603e08  R15: ffffffff81ead300
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
--- <NMI exception stack> ---
  [ffff880036607000] format_decode at ffffffff8127f585
  [ffff880036603ca0] vsnprintf at ffffffff81280e34
  [ffff880036603d08] default_wake_function at ffffffff81063322
  [ffff880036603d40] simple_strtoll at ffffffff81281451
  [ffff880036603d60] vprintk at ffffffff8106f0b6
  [ffff880036603d88] __wake_up at ffffffff81055ab3
  [ffff880036603db8] delayed_work_timer_fn at ffffffff810912e0
  [ffff880036603dc8] insert_work at ffffffff81090d8d
  [ffff880036603e00] schedule at ffffffff8150d581
  [ffff880036603e60] dmar_set_interrupt at ffffffff812ad9d0
  [ffff880036603e78] __rcu_process_callbacks at ffffffff810e6f94
  [ffff880036603ed0] handle_IRQ_event at ffffffff810e1720
  [ffff880036603ed8] __do_softirq at ffffffff8107700f
  [ffff880036603f20] handle_fasteoi_irq at ffffffff810e3e6e
  [ffff880036603f60] handle_irq at ffffffff8100de89


- 조치 사항 - 

금번 발생된 HP DL380 G8에서 시스템에 강제로 재부팅 되는 이슈는 Know-issue  
아래의 링크는 RHEL6.4 기반에서 운영되는 HP 장비에서 발생된  "PANIC: "Kernel panic - not syncing: An NMI occurred, please see the Integrated Management Log for details"

이슈와 관련해서  HP 장비에 대한 FIrmware 및 BIOS 업그레이드를 권장하고 있음
아래의 문서에 댓글로 달려 있는 코멘트를  참조했을 때 HP DL580 G7과 HP DL380 G8이 동일한 문제를 나타내고 있음.  

< 관려 이슈 문서>

https://access.redhat.com/site/solutions/442193


신고

難攻不落(난공불락) 리눅스 및 오픈소스 인프라 세미나  강사진이 모드 섭외가  됐습니다..

모든 분들께서 흔쾌히 허락해 주시고 자발적으로 자신이 가지고 있는

오픈소스 기술과 노하우를 나누겠다고 해주신 분도 계십니다..이자리를 빌어서 

다시한번 감사의 말씀을 드립니다....모든 분들께서 IT에서 소히 "고수"로 불리시는

분들이여서 (저빼고..ㅜㅜ) 많은 것들을 공유하고 나눌수 있지 않을까 기대해봅니다 


1. Linux kernel core 분석 방법론 

   - 강사: 이미르 (한국 오라클 GSS)

2. zinst 패키지 기반의 리눅스 중앙관리 시스템

    - 강사 : 양지욱 과장 (GS샵) 

3. Percona를 이용한 클러스터 구축 (가제목) 

   - 강사 : 이동현 차장 (오픈소스 컨설팅) 

4. GlusterFS를 이용한  NAS 솔루

    - 강사 : 이호성 차장 (오픈소스 컨설팅, 한국리눅스 사용자 그룹 운영자) 

5. Linux RBAC with LDAP 

    - 강사 : 송상준 부장 (서진 디엔에스) 

신고
  1. 김정석 2014.02.27 18:56 신고

    세미나 신청은 어디에 하면 되나요

  2. 프르딩딩 2014.03.11 19:20 신고

    조만간 접수 페이지 만들어서 진행할 예정이에요..^^ 조금만 기다려 주세요..

안녕하세요 한국 리눅스 사용자 그룹을 운영하고 있는 오픈소스 컨설팅의 이호성 (Tommy Lee) 입니다, 날씨도 선선히 풀리고 있는 것 같고 봄이 오는 느낌도 들고, 여러모로 계절이 바뀌고 있다는 느낌이 들어서 4계절이 뚜렷한 나라에 사는 것도 나쁘지 않다는 생각이 드는 요즘입니다..^^ 

제가 한국 리눅스 사용자 그룹을 오픈하게 된것은 오픈소스를 접근하는 방법에 있어서는 상황에 따라서 여러가지  차원으로 접근하게 되는데 하나의 솔루션 으로써 적용되는 것도 의미가 있지만, 한개인 또는 기업에게 오픈소스를 통해서 원천 기술 또는 기반 기술을 슬득하고 서로 공유하고자 하는데 그 의미를 
두고 미약하지만 열심히 나누고 공유하려 노력하고 있습니다.(뭐..나름의 철학입니다 마는..ㅋㅋ) 

그렇게 미약한 시작이기는 하지만 참 많은 분들께서 함께 공유해주시고 의견주셔서 이제 오프라인 세미나를 통해서 좀더 많은 것들을 나누고자 하는 시도를 해볼까 합니다.. 

예정된 일정은 이렇습니다. 

일정 : 4월12일 또는 19일 (토요일
- 정확한 일정은 survey monkey를 통해서 설문을 받아 보도록 하겠습니다. 
- 설문을 통해서 정해진 날짜를 세미나 2주전에 공지하도록 하겠습니다.

장소 : 강남 토즈 타워 (예정) 
- 현재 오픈소스 커뮤니티 모임의 지원을 통한 장소섭외가 가능하지도 알아보는 중입니다. 
- 장소 또한 결정되면 별도 공지하도록 하겠습니다.

대략적인 아젠다는 아래를 참조해 주시구요... 

혹시 내가 오픈소스를 통해서 경험했던 것들을 나누고자 하시는 분들께서는 한국 리눅스 사용자 
그룹에 댓글로 남겨 주시거나 제 블로그 댓글에 남겨주시면 별도로 연락 드리도록 하겠습니다. 

현재까지 확정된 세미나 주제와 아젠다는 아래와 같습니다. 


難攻不落(난공불락) 리눅스 및 오픈소스 인프라 세미나

1. Linux kernel core 분석 방법론 

   - 강사: 이미르 (한국 오라클 GSS)

2. zinst 패키지 기반의 리눅스 중앙관리 시스템

    - 강사 : 양지욱 과장 (GS샵) 


3. Percona를 이용한 클러스터 구축 (가제목) 

   - 강사 : 이동현 차장 (오픈소스 컨설팅) 

4. GlusterFS를 이용한  NAS 솔루션

    - 강사 : 이호성 차장 (오픈소스 컨설팅, 한국리눅스 사용자 그룹 운영자) 

5. Linux Rdac with LDAP 

   
 - 강사 : 송장준 부장 (서진 디엔에스) 


6. z/VM를 이용한 zLInux 이야기

   - 강사 : 장혁수 차장 (Aimacy)


難攻不落(난공불락) 

난공불락 이라는 말은 공격하지 쉽지 않고 함락하기 어려운 성을 일컫는 말입니다. 또한 심지가 

곧아서 웬만한 유혹에는 힘들리지 않는 강직한 성격을 가진 사람들을 비유해서 일컫는 말이기도 하죠..

모든 오픈소스는 커뮤티니와의 연계성이 가장 중요하다고 봅니다..


오픈소스는 한 개인이 또는 어느 한조직이 독자적으로 넘어설수 있는 그 무엇이 아닙니다.. 다같이 

나누고 공유했을 때 오픈소스를 통한 원천기술 확보 내지는 기술력 내재화 라는 목적을 이룰수 

있을꺼라는 나름의 오픈소스 철학을 담아봤습니다.. 


그리고 이전 배고픈 시절부터 리눅스나 오픈소스를 끝까지 포기하지 않고 "삽질" 신공을 단련해온 

강직한 리눅서들과 개발자들의 강직함으로 표현하고 싶었습니다.. 

신고
  1. jerryp 2014.02.12 15:48 신고

    그래서... 언제한다는겁니까? ^^ 완전 기대기대!

  2. 프르딩딩 2014.02.21 14:17 신고

    일단 아젠다 정리좀 하구요 조만간 곧..진행할 예정입니다.^^

  3. hiboss1 2014.02.21 18:08 신고

    정말 기대가 되네요...

Quick Guide

https://sites.google.com/site/fagonas/li/spacewalk/spacewalk-quick-guide

신고

. 프로그램 에러 시그널들 (SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGABRT) - 매우 중요 ★★★★★

다음의 시그널들은 심각한 프로그램의 에러가 운영체제나 컴퓨터 자체에 의해 검출되었을 때 발생 된다. 
일반적으로, 이들 시그널 모두는 당신의 프로그램이 심각하게 깨져있고, 에러가 포함된 그 실행을 계속할 아무런 방법이 없음을 지적한다.


어 떤 프로그램들은 프로그램의 에러 시그널로 인해서 종료되기전에 그들을 깨끗하게 처리한다. 예를 들어, 터미널 입력의 반향을 끈(tnun off) 프로그램들은 다시 반향을 켤 목적으로 프로그램 에러 시그널들을 처리할 것이다. 핸들러는 시그널을 위한 디폴트 동작을 정하고 그 동작을 함으로써 끝날 것이다. 만일 프로그램이 시그널 핸들러를 가지지 않았다면, 프로그램은 그 시그널로 인해서 종료될 것이다.

SIGFPE 시그널은 심각한 산술적 에러를 보고한다. 그 이름이 "floating-point exception"에서 유래된것이라 할지라도, 이 시그널은 실제로는 모든 산술적 에러들에 작용한다. 만일 어떤 프로그램이 어떤 위치에 정수 데이터를 저장하고 그 데이터에 플로팅-포인트 명령을 사용한다면, 이것은 그 프로세서가 데이터를 플로팅-포인트 수로써 인식할 수 없기 때문에 종종 "유용하지 않은 연산"의 원인이 된다.

SIGILL 시그널의 이름은 "비합법적인 명령(illegal instruction)"에서 유래되었다
그것은 쓸모없거나 특권이 부여된 명령어를 실행하려 했다는 의미이다. 
오직 유용한 명령어만이 발생된 C 컴파일러에서, SIGILL은 전형적으로 실행 가능 파일이 훼손되었거나, 당신이 데이터를 실행하려 시도했다는 것을 지적한다. 

후자의 상황이 발생되는 일반적 상황으로는 함수를 위한 포인터가 있을 것이라고 예상된 곳에서 유용하지 않은 오브젝트를 파싱하거나, 자동 배열의 끝을 넘어서 기록을 하고( 또는 자동 변수를 위한 포인터와 유사한 문제들) 스택 프레임의 반환 어드레스 처럼 스택에서 
다른 데이터의 훼손과 같은 문제들이 있다.

SIGSEGV 시그널은 할당된 메모리의 범위를 벗어나는곳에서 읽거나, 쓰기를 시도할 때 발생 된다. 
(실제로, 그 시그널들은 프로그램이 충분한 영역을 할당받지 못할 때 시스템 메모리 보호 메커니즘에 의해서 발생한다.) 

그 이름은 "segmentation violation"의 약자이다. 
SIGSEGV 상황이 발생되는 가장 일반적인 방법은 비참조 되는 널( defeferencing a null) 이나 초기화되지 않은 포인터에 의한 것이다. 

널 포인터는 주소 0으로 참조되고, 대부분의 운영체제는 이 주소가 정확하게 유용하지 않음을 확실히
하기 때문에
비참조 널 포인터는 SIGSEGV가 발생될 것이다. 
(어떤 운영체제는 주소가 0인 메모리도 유용하고, 비참조 널 포인터는 그들 시스템상에서는 시그널을 발생하지 않는다.) 
비초기화된 포인터에서는, 유용하지 않거나, 유용하더라도 임의의 주소들을 갖게된다. 
SIGSEGV 상황이 얻어지는 다른 일반적 방법은 배열에 포인터를 사용했을 때 그 배열의 끝을 체크하기를 실패했을 때이다. 

SIGBUS 시그널은 유용하지 않은 포인터가 비참조되었을 때 발생 된다. 
SIGSEGV 처럼, 이 시그널은 초기화되지 않은 포인터를 비참조 한 것의 결과이다. 
두 시그널의 차이점은 SIGSEGV는 유용한 메모리에서 유용하지못한 억세스를 지적하고, 
SIGBUS는 유용하지못한 주소를 억세스 하는 것을 지적한다. 
특별하게, SIGBUS 시그널은 4개로 나누어지지 않은 주소에 4-단어 정수로 참조하는것처럼, 
부적당한 포인터가 비참조 됨으로써 발생한다. 
(각종 시스템은 주소 정렬은 위한 자신만의 필요조건을 갖는다.) 이 시그널의 이름은 "bus error"의 약자이다.

SIGABRT 시그널은 프로그램 그 자체와 abort가 호출되었음을 보고함으로써 발생되는 에러를 지적한다.

2. 종료 시그널 (SIGHUP, SIGINT, SIGQUIT, SIGTERM, SIGKILL) - 중요 ★★★★

이들 시그널들은 이런 저런 방법으로 프로세스를 종료함을 알리기위해 사용된다. 
그들은 완전히 다른 목적을 위해 사용되기 때문에 다른 이름을 가졌고, 프로그램은 그들은 다르게 취급하기를 원할 것이다.
이들 시그널들은 처리하기 위한 이유는 보통 당신의 프로그램이 실제로 종료되기전에 적당하게 처리할 수 있도록 하기 위한 것이다. 
예를 들어, 당신은 상황정보를 저장하고, 임시 파일들을 지우고, 이전의 터미널 모드를 반환하기를 원할수도 있다. 
그와 같이 핸들러(handler)는 발생된 시그널을 위한 디폴트 동작을 지정하고 그리고 그 시그널을 다시 발생시킴으로써 종료할 것이다. 
이것은 만일 프로그램이 핸들러를 가지지 않았더라도, 그 시그널로 인해서 프로그램이 종료될 것이다.

SIGHUP ("hang-up") 시그널은 사용자 터미널의 단절을 보고하기 위해 사용되어지는데, 
아마도 네트웍이나 전화선 연결이 끊어졌기 때문이다. 

SIGINT("program interrupt") 시그널은 사용자가 INTR 문자를 (보통 C-c)을 입력했을 때 보내어진다. 

SIGQUIT 시 그널은 다른 키_QUIT 문자, 보통 C-\_에 의해서 제어된다는 것을 제외하고는 SIGINT와 유사하고, 그 프로세스가 종료 될 때 프로그램 에러 시그널처럼 코어 파일을 작성한다. 당신은 사용자에 의해 "검출된" 프로그램 에러 상황으로 이들을 생각할 수 있다. 

SIGTERM 시그널은 프로그램을 종료하는데 사용하는 포괄적인 시그널이다. SIGKILL과 달리, 이 신호는 블록되어진고, 처리되어지고 무시되어질 수 있다.

SIGKILL 시그널은 즉각적인 프로그램 종료를 일으키기 위해서 사용되어진다. 이 시그널은 처리되거나, 무시되거나 할 수 없고, 그 결과는 항상 치명적이 된다. 이 시그널은 블록하는것도 불가능하다. 

3. 알람 시그널 (SIGALRM, SIGVTALRM, SIGPROF) - 알아도 그만.. 몰라도 그만..  ^^;;

그들 시그널은 타이머의 경과를 지적하는데 사용되어진다. 
그들 시그널을 위한 디폴트 동작은 프로그램을 종료를 일으키는 것이다. 
이 디폴트 동작은 거의 유용하지 않다. 
그 들 시그널을 사용하는 대부분의 방법은 어느 경우에 맞는 핸들러 함수들을 요구하는 것이다.

SIGALRM 시그널은 전형적으로 실제또는 클럭 시간을 계산한 타이머의 경과를 지적한다. 
예를 들어 alarm 함수에의해 사용되어진다. 

SIGVTALRM 시그널은 전형적으로 현재 프로세스에 의해 사용된 CPU시간을 계산하는 타이머의 경과를 지적한다. 
그 이름은 "virtual time alarm"의 약자이다.

SIGPROF 시그널은 현재의 프로세스에 의해 사용된 CPU 시간과, 
프로세스를 대신하여 시스템에의해 사용된 CPU시간의 둘을 계산한 타이머의 경과를 지적하는데 사용된다. 
타이머가 자원의 프로파일링을 위한 도구로써 사용되어지므로, 시그널의 이름이 SIGPROF이다.

4. 비동기 입/출력 시그널 (SIGIO, SIGURG)

이 절에 설명된 시그널들은 비동기 입/출력 도구들과 함께 사용되어진다. 
당신은 어떤 특정한 파일 기술자가 그들 시그널을 발생시키도록 하기 위해서 fcntl을 호출함으로써 명백한 동작을 취하도록 해야한다.

SIGIO 시그널은 파일기술자가 입력 또는 출력을 수행할 준비가 되어있을 때 보내어진다. 
대부분의 운영체제에서, 터미널과 소켓만이 SIGIO를 발생시킬 수 있다. 
보통의 파일들을 포함한 다른 종류들은 당신이 그들에게 요청했을지라도 SIGIO신호를 발생시키지 않는다.

SIGURG 시그널은 소켓에 도착한 데이터가 "긴급"하거나 범위를 벗어 났을 때 보내어진다.

5. 작업 제어 시그널 (SIGCHLD, SIGCONT, SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) - 중요 ★★★★

이들 시그널은 작업 제어를 지원하기 위해서 사용되어진다. 
만일 당신의 시스템이 작업 제어를 지원하지 않는다면 시그널들은 발생되어지거나, 처리될 수는 없지만 매크로들은 정의되어있다. 
당신이 실제로 작업이 어떻게 제어되는지를 이해할 수 없다면 그들 시그널을 그대로 방치할 것이다.

SIGCHLD 시그널은 자식 프로세스들중의 하나라도 종료되거나 멈출 때마다 부모 프로세스에게 보내어진다. 
이 시그널을 위한 디폴트 동작은 그것을 무시하는 것이다. 

당신은 프로세스가 계속되도록 하기 위해서 SIGCONT 신호를 보낼 것이다.
SIGCONT 시그널을 위한 디폴트 동작은 만일 그 프로세스가 멈추었다면 그 프로세스를 계속하도록 만드는 것이고 
그렇지 않다면 그것을 무시하는 것이다. 
대부분의 프로그램에서는 SIGCONT를 처리할 아무런 이유가 없다. 
그들은 전에 멈추었었음을 인식함이 없이 계속 실행되고 있다고 가정한다. 

SIGSTOP 시그널은 프로세스를 멈춘다. 그것은 처리되거나, 무시되거나 블록될 수 없다.

SIGTSTP 시그널은 상호 작용하는 멈춤 신호이다. SIGSTOP와는 달리 이 신호는 처리되거나 무시되어질 수 있다. 
당신의 프로그램에서 프로세스가 멈추었을 때 파일이나 시스템 테이블을 안전한 상황으로 만들어놓을 특별한 필요가 있다면 
이 신호를 처리할 수 있다.

한 프로세스가 배경 작업으로써 실행되고 있는 동안 사용자의 터미널로부터 읽을 수 없다. 
배경 작업에 속한 어느 프로세스가 터미널로부터 읽으려 시도할 때, 그 작업에 속한 모든 프로세스는 SIGTTIN 신호를 받는다. 
이 시그널을 위한 디폴트 동작은 그 프로세스를 멈추는 것이다. 

SIGTTOU 시그널은 배경 작업에 속한 프로세스가 터미널에 출력하려 시도하거나 그 터미널 모드를 설정하려 시도할 때 발생 된다. 
다시 말하면 디폴트 동작은 그 프로세스를 멈추는 것이다. 
프로세스가 멈추어있을 동안, SIGKILL 시그널과 SIGCONT시그널을 제외하고는 어느 다른 시그널들은 배달되어질 수 없다.

SIGKILL 시그널은 항상 프로세스의 종료를 유발하고 블록되거나 무시될 수 없다. 
당신이 SIGCONT 시그널을 무시하거나 블록할 수 있지만, 그것은 만일 그 프로세스가 멈추어져있다면 프로세스가 계속되도록 한다. 
프로세스에게 보낸 SIGCONT 시그널은 아직 미해결인채로 남아있는 멈춤 시그널을 프로세스가 버리도록 한다. 
이와 비슷하게, 어떤 프로세스에서 아직 미해결인채로 남아있는 SIGCONT 시그널은 멈춤 시그널이 도착했을 때 버려진다. 
고아가 되어버린 프로세스 그룹에 있는 한 프로세스에게 SIGTSTP, SIGTTIN, 또는 SIGTTOU 시그널을 보내면 그것은 처리되지도 않고, 
그 프로세스는 멈추어 지지도 않는다. 
그것을 계속할 아무런 방법이 없는 부당하게 되어버린 프로세스를 멈추게 하라. 
운영체제에 의존하지 말고당신이 무언가를 사용해서 멈추게 하라. 어떤 시스템은 아무런 일도 하지 않을 것이다. 
다른 시스템들은 대신에 SIGKILL 또는 SIGHUP와 같은 시그널들을 배달할 것이다. 

6. 잡다한 시그널 (SIGUSR1 ~ SIGUSR22)

그들 시그널은 다양한 다른 상활들을 보고하기 위해서 사용되어진다. 이들의 디폴트 동작은 프로세스가 종료되도록 하는 것이다.

SIGPIPE 시그널은 읽는 프로세스가 없는 상황에서의 PIPE에 대한 쓰기시 발생한다.

SIGUSR1 과 SIGUSR22 시그널들은 당신이 원하는 어떤 방법을 사용하지 못하도록 한다. 그들은 프로세스간 통신을 위해서 유용하다. 

그들 시그널을 보통 심각하기 때문에 당신은 그 시그널을 받은 프로그램에서 그들은 위한 시그널 처리를 해야할 것이다.

신고

아래의 내용은  HP C7000 BL460c 장비에서 vmcore를 생성하기 위한 구성 조건입니다

vmcore를 생성하기 위한 조건으로 장비별로 특성을 가지는 경우도 생기는듯 합니다. 드라이버를

업데이트 한다든지 Firmware를 올린다든지.. 이부분에 있어서는 하드웨어 벤더사의 의견도

중요합니다.


RHEL 6.4 X86_64

HP C7000 BL460c

 

이슈사항

OS 설치 후 기존의 kdump 설정대로 진행하였을 경우 테스트 결과 kdump가 실행되지 않고 hang 상태를 유지하고 있었습니다.

1. kdump 테스트시 error message 발생

           NMI: IOCK error (debug interrupt?)

 

해결방법

1. HPSA 드라이버 최신 업데이트

           HPSA version:        3.4.4-125

 

2. HP에서 권장하는 kernel 파라미터 설정 (reboot 해야 적용)

/etc/sysctl.conf

           kernel.sysrq = 1

           kernel.panic = 10

           kernel.panic_on_oops = 1

           kernel.unknown_nmi_panic = 1

           kernel.panic_on_unrecovered_nmi = 1

           kernel.panic_on_io_nmi = 1

          

 

/etc/grub.conf (intel_iommu=on intel_iommu=off로 변경 nmi_watchdog=1 추가)

title Red Hat Enterprise Linux (2.6.32-358.el6.x86_64)

           root (hd0,0)

           kernel /tboot.gz logging=vga,serial,memory

           module /vmlinuz-2.6.32-358.el6.x86_64 ro root=/dev/mapper/vg00-LogVol01 intel_iommu=off rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg00/LogVol00 rd_NO_MD rd_LVM_LV=vg00/LogVol01 SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM nmi_watchdog=1 rhgb quiet

           module /initramfs-2.6.32-358.el6.x86_64.img

 

3. kdump.conf 설정

           path /var/crash

           core_collector makedumpfile -c --message-level 1 -d 31

 

4. kdump 버전

           kexec-tools-2.0.0-258.el6.x86_64

 

5. 참고사항

ilo를 사용하는 환경에서 "# echo c > /proc/sysrq-triger" kdump 생성 테스트하면 생성되지 않는 문제가 있다고 합니다.

서버에 monitor 를 직접 연결하시고 kdump 생성 테스트 해야합니다.


6. BSSAPDB, BSSAPAP kdump 생성 안되는 이유

           - /var/crash 영역이 multipath device(mpatha)로 인식이 되어있었고, kdump initrd(ramdisk) 에서는 multipath module

             인식을 하지 못하여 /var/crash 영역을 mount 하지 못해 dump 파일이 생성이 되지 않았습니다.

           - 이 부분을 해결 하기 위해서 아래와 같은 절차로 진행을 하였습니다.

 

6.1 /etc/multipath.conf 파일 수정

           - /etc/multipath.conf 파일을 /root 영역으로 move

           - OS 영역 디스크 wwid 로 식별하여 blacklist 등록

           - OS initramfs 재생성후 reboot

           - reboot 완료 후 /root/multiipath.conf 파일을 /etc/multipath.conf 로 원복

           - multipathd 데몬 재시작

           - 기존에 있던 kdump initrd(kdump ramdisk) 백업

           - kdump initrd(kdump ramdisk) 재생성

           - echo "c" > /proc/sysrq-trigger 명령어로 테스트

           - /var/crash/var/crash/127.0.0.1(Time) 폴더에 생성 확인


신고

자아~ Red Hat이 CentOS 커뮤니트 프로젝트를 인수했습니다, CentOS를 개발했던 모든 Main Contributor들은
모두 레드햇에 Join되었고..지속적으로 CentOS에 대한 개발을 진행한다고
합니다..

지만 여기서 아주 재미 있는 대목이 있네요.이전에 Red Hat이 전통적으로 Source를 배포하는 방식을 바꿨습니다. SRPM이 아닌 GIT Repository를 이용한다는 군요..

Red Hat의 의견은 Git Repository를 이용한 소스 배포 방식이  CentOS와 Oracle에게 도움이 될거라고 합니다. 또한 CentOS의 프로젝트는 GlusterFS, Ovirt, OpenStack, OpenShift등 클라우드 인프라에 요구되는 오픈소스
프로젝트와 Pair로 빠르게 움직일 텐데..

기사에 나와있는데로 개발 로드맵상Fedora는 너무 빠르고 RHEL은 새로운 Project에 Pair로 움직이기에는 
너무 긴 Roadmap을 가지고 있으니 적절하게 엔터프라이즈 환경에 필요한 프로젝트를  Pair로 움직일수 있는 프로젝트 기반이 필요했고..그걸 CentOS로 결정한 것이군요.. 

그렇다면 여기서 생각해 볼 필요가 있는 부분이 있겠죠.. 


1. GIT Repository 방법으로 소스를 배포하는 방법 

레드햇은 전통적인 Source 배포 방법의 SRPM이 아닌 Git Repository를 이용해서 배포한다고 발표했습니다. 
전통적으로 레드햇 Clone을 지향해온 CentOS와 Oracle Linux의 경우 도움이 될까요?? 

CentOS나 Oracle Linux의 경우 분명 RHEL의 Patch 기간이나 Minor Release 기간 그리고 새로운 Major 버젼의 Linux Platform에 따라서 영향을 받고 플랫폼을 내놓았는데 이렇게 된다면 분명 두 Enterprise 배포판의 개발 Roadmap에 치명적인 영향을 미치게 된다는 것을 예상할수 있습니다. 


2.
버젼 Release.. 

Red Hat은 Fedora와 RHEL의 개발 기간에 차이로 인해서 Cloud Computing 환경을 위한 오픈소스 
프로젝트를 Pair로 개발될수 있는 중간계 프로젝트로 CentOS를 선택했습니다. 여기서 주목해서 봐야할 부분은 CentOS Main Contributor에 의도입니다. 

CentOS 6.5 was released in December – what's on tap for the next release? How will the new partnership affect that?

In spite of the fact that I work for Red Hat now, I'm not privy to their release schedules. So over the next few months the board will publish our own road map. The mainline, the core, will stay as it is. But the variants will be able to set up their own road maps (based on their own release schedule).

[참조]
https://www.linux.com/news/featured-blogs/200-libby-clark/757524-centos-project-leader-karanbir-singh-opens-up-on-red-hat-deal/

즉 레드햇에 Join 된 Main contributor인 Karanbir Singh는 더이상 Release 스케쥴에 관여하지 않겠다는 입장을
밝혔습니다..Core 프로젝트의 경우는 그래도 Release 스케쥴이 Publish 되겠지만 몇몇
의 프로젝트들의 경우에는 자체적인 Release Roadmap를 set up 한다고 합니다..

그밖에 다른 Core 프로젝트 들이라고 하는 것이 어떤 것인지는 참조 링크를 잘 보시면 이해하실수 있을듯 합니다. 
이 상황이라면 분명 CentOS에 대한 Release 스케쥴 또한 어느 선에서는 분명 영향을 받을 거라는예상은 누구나
할수 있지 않을까 합니다.. 

여기서 오라클의 반응이 참 재미있네요... 

[참조]
https://blogs.oracle.com/linux/entry/oracle_linux_free_as_in

Fortunately, no matter what future CentOS faces in Red Hat’s hands, Oracle Linux offers all users a single distribution for development, testing, and deployment, for free or with a paid support subscription. Oracle does not require customers to buy a subscription for every server running Oracle Linux (or any server running Oracle Linux). If a customer wants to pay for support for production systems only, that’s the customer's choice. The Oracle model is simple, economical, and well suited to environments with rapidly changing needs.

Oracle is focused on providing what we have since day one – a fast, reliable Linux distribution that is completely compatible with Red Hat Enterprise Linux, coupled with enterprise class support, indemnity, and flexible support policies. If you are CentOS user, or a Red Hat user, why not download and try Oracle Linux today? You have nothing to lose after all, it’s free!

즉 오라클은 RedHat과 CentOS의 Join에도  변함없이 무료 또는 유료 서브 스크립션과 함께 개발, 테스트, 배포를 위한
단일 배포판을 제공한다는 것을 강조하고 있습니다...오라클 입장에서는 레드햇의 이런 행보가 신경쓰이겠죠.. 

생각이 다르기는 하겠지만 저는 이런 Red Hat의 행보에 대한 의미는  리눅스 프로젝트 부분에 있어서 주도 (Leading)
하겠다는 전략적인 의미와 함께 CentOS 프로젝트를 Join 하면서 Oracle 리눅스를 동시에 힘들게 하고자 하는 숨은 
의도 또한 내포하고 있지 않을까라는 예상을 해봅니다.. 

솔직히 CentOS의 운명도 걱정되기는 합니다.. 

[참조 링크]
http://lwn.net/Articles/579551/


신고

http://en.linuxreviews.org/NTP_-_Howto_make_the_clock_show_the_correct_time

신고

글러스터 구성하다가 아래와 같이 대용량 디스크에서 파티셔닝 하다가 나타나는 문제점에 대해서는

잘 정리되어 있는 문서입니다...

=======================================================================================

참조 : http://blog.seabow.pe.kr/?p=2132

Linux 에서 fdisk -l 을 하게되면
Partition “X” does not end on cylinder boundary. 라는 문구를 볼 수 있다.

ex)

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          26      204800   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              26         287     2097152   83  Linux

왜 위와 같은 문구를 출력 하는 것일까?

파티셔닝 작업에서는 LBA (Logical Block Addressing)기반으로 파티셔닝을 한다.
그러나 fdisk -l 상에서는 CHS (Cylinder/Head/Sector)기반으로 결과를 보여 줌으로써 위와 같은 메시지가 출력되는 것 이다.

이를 회피하는 방법?
$ sfdisk -uS -l /dev/Device

Disk /dev/sda: 9726 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0

Device Boot    Start       End   #sectors  Id  System
/dev/sda1   *        63    409662     409600  83  Linux
/dev/sda2        409663   4603966    4194304  83  Linux
/dev/sda3       4603967 156248189  151644223  8e  Linux LVM
/dev/sda4             0         -          0   0  Empty

참고 자료 :

Link 1 : http://prefetch.net/blog/index.php/2009/09/12/why-partition-x-does-now-end-on-cylinder-boundary-warnings-dont-matter/

Link 2 : http://www.symantec.com/business/support/index?page=content&id=TECH164072

Link 3 : http://www.novell.com/support/kb/doc.php?id=7005639

신고

출처 : http://www.packetinside.com

네트워크 상에서 많이 쓰는 도구중에 하나가 PING 이 아닐까 생각합니다. 네트워크가 안된다면 일단 PING 을 통해서 확인을 시도해 보니까 말이죠. 네트워크에 PING 이 있다면, 디스크에는 IO Latency 를 확인해 볼 수 있는 IOPING 이 있습니다. 세부 정보는 다음 경로에서 확인할 수 있습니다.


https://code.google.com/p/ioping/

다운 받아보면 아주 간단하게 구성되어 있습니다.

# ls
ioping.1  ioping.c  ioping.spec  Makefile

Makefile 이 이미 존재하므로 바로 make 를 해주면 컴파일이 됩니다.

# make
cc -std=c99 -g -Wall -Wextra -pedantic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DVERSION=\"0.6\" -c -o ioping.o ioping.c
cc -o ioping ioping.o -std=c99 -g -Wall -Wextra -pedantic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -lm

실행해 보면 아래와 같은 도움말을 볼 수 있습니다.

# ./ioping
 Usage: ioping [-LCDRq] [-c count] [-w deadline] [-p period] [-i interval]
               [-s size] [-S wsize] [-o offset] device|file|directory
        ioping -h | -v

      -c <count>      stop after <count> requests
      -w <deadline>   stop after <deadline>
      -p <period>     print raw statistics for every <period> requests
      -i <interval>   interval between requests (1s)
      -s <size>       request size (4k)
      -S <wsize>      working set size (1m)
      -o <offset>     in file offset
      -L              use sequential operations (includes -s 256k)
      -C              use cached I/O
      -D              use direct I/O
      -R              seek rate test (same as -q -i 0 -w 3 -S 64m)
      -q              suppress human-readable output
      -h              display this message and exit
      -v              display version and exit


따로 메뉴얼이 없어도 대략 어떤 의미인지가 추정이 됩니다. 그만큼 사용법이 간단하다는 의미가 되겠죠.

# ./ioping /dev/sda6 
4096 bytes from /dev/sda6 (device 309.1 Gb): request=1 time=14.5 ms
4096 bytes from /dev/sda6 (device 309.1 Gb): request=2 time=5.3 ms
4096 bytes from /dev/sda6 (device 309.1 Gb): request=3 time=9.3 ms
4096 bytes from /dev/sda6 (device 309.1 Gb): request=4 time=7.5 ms
4096 bytes from /dev/sda6 (device 309.1 Gb): request=5 time=6.3 ms
4096 bytes from /dev/sda6 (device 309.1 Gb): request=6 time=9.0 ms
^C
--- /dev/sda6 (device 309.1 Gb) ioping statistics ---
6 requests completed in 5645.3 ms, 116 iops, 0.5 mb/s
min/avg/max/mdev = 5.3/8.6/14.5/3.0 ms

실행해 보면 ping 에서 보던 것과 유사하게 출력이 됩니다. 더 이상 다른 설명은 안 드려도 될것 같네요. :-)
IO latency 를 실시간으로 확인할 필요가 있으신 분들은 참고하시기 바랍니다.

=============

덧붙여서 Ubuntu 사용자는 apt-get install ioping 하면 우분투 리포지터리 에서 제공하는 ioping을 어렵지 

않게 설치할수 있네요.. 

신고

+ Recent posts