리눅스 시스템을 운영하다 보면  시스템 Hang-up에 대한  문제점을 많이 들어나게 됩니다. 물론  리눅스 시스템 
자체의 문제점이라고 보다는 특정 운영 프로세스에 대해서 인터럽트 또는 스케쥴이 정상적으로 진행되지 못했을때 나타는 문제점에 대해서 간략해 소개해 보고자 합니다.

갑자기 시스템  로그에서 출력하게된 /var/log/message 의 시스템 로그.

kernel: INFO: task startup.sh:9902 blocked for more than 120 seconds.
 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this messag
 kernel: startup.sh    D 0000000000000008     0  9902   7811 0x00000004
 kernel: ffff880828f17ce8 0000000000000082 ffff88081c2aeaa0 ffff88081c2aeaa0
 kernel: ffff88081c2aeaa0 ffffea00378c0d98 ffff88081c2aeaa0 0000010100001e60
 kernel: ffff88081c2af058 ffff880828f17fd8 000000000000fb88 ffff88081c2af058
 kernel: Call Trace:
 kernel: [<ffffffffa00accf0>] ? ext4_file_open+0x0/0x130 [ext4]
 kernel: [<ffffffff814eae85>] schedule_timeout+0x215/0x2e0
 kernel: [<ffffffff81174234>] ? nameidata_to_filp+0x54/0x70
 kernel: [<ffffffff81268d39>] ? cpumask_next_and+0x29/0x50
 kernel: [<ffffffff814eab03>] wait_for_common+0x123/0x180
 kernel: [<ffffffff8105fa40>] ? default_wake_function+0x0/0x20
 kernel: [<ffffffff814eac1d>] wait_for_completion+0x1d/0x20
 kernel: [<ffffffff8106155c>] sched_exec+0xdc/0xe0
 kernel: [<ffffffff8117ee90>] do_execve+0xe0/0x2c0
 kernel: [<ffffffff810095ea>] sys_execve+0x4a/0x80
 kernel: [<ffffffff8100b4ca>] stub_execve+0x6a/0xc0

[예상 문제점 1]
시스템 로그에서 나타난  kernel:INFO: task 의 메세지를 나타내는 의미는 현재 운영하고자 하는 startup.sh 
스크립트에 대해서  120초 (2분 default) 동안 khungtaskd  쓰레드에서 D-state 상태를 감지하여  call trace 
를 호출하게 되는  상황으로 예측할 수 있습니다. 

[예상 문제점2]
시스템의 성능저하 특히 레드햇의 보고서에 의하면 디스크의 heavy I/O 로 나타나는 문제점으로 
예측될수 있습니다. 

[예상 문제점 2]
운영되고 있는 Application에 대해서 "D-state" (Uninterruptible sleep) 모드가 120초 동안 지속되었을때
예측될수 있는 문제로  해당 프로세스가 정상적으로 스케쥴링이 일어나지 않았을 때도 나타나게 됩니다

[ D-state 원인분석을 위해서는 ? ]
위와같은 문제점에 대해서 접근할수 있는 기본적인 방법에 대해서는  정확한 문제점을  파악하기 위해서는  커널의 덤프를 이용하여 core를 분석하는 것이 가장 정확할수 있습니다. core를 분석하기 위한 방법론에 대해서는 다음 
블로깅을 통하여 소개하도록 하겠습니다. 

# echo 1 > /proc/sys/kernel/hung_task_panic

위와 같이  kernel core를  생성하기 위해 설정을 진행한 후 동일한 현생이 발생되어 core가 생성이 되면 문제가
되는 운영 프로세스의 D-state 문점에 대해서 분석이 가능합니다. 

[ hung_task_timeout을 Disable 시켜라]
기본적인 Work-Arround에 대해서는  아래와 같이 hung_task_timeout 부분에 대해서 Disable 시켜주는 것을 권장하고 있습니다. 

#  echo 0 > /proc/sys/kernel/hung_task_timeout_secs

위와 같이  커널에서 Hang Time OUt 을 체크하는 부분에 대해서 Disable 시켜준 후에는  call trace 여부가 지속적으로 발생되는지  모니터링이 필요합니다. 만약  해당 프로세스에 대해서  Uninterrupt sleep이 지속적으로 발생한다면 커널 업데이트 또한 고려해야 합니다.



출처: http://ssambback.tistory.com/entry/서버가-응답이-없어요INfotask-processpid-lock-for-more-than-120-seconds [Rehoboth.. 이곳에서 부터]

출처: http://ssambback.tistory.com/entry/서버가-응답이-없어요INfotask-processpid-lock-for-more-than-120-seconds [Rehoboth.. 이곳에서 부터]

Mar 24 11:19:15 grep-r kernel: You need to implement a remote task_setrlimit in your security module and call it directly from this functionWARNING: at security/security.c:51 security_o
ps_task_setrlimit()
Mar 24 11:19:15 grep-r kernel: 
Mar 24 11:19:15 grep-r kernel: Call Trace:
Mar 24 11:19:15 grep-r kernel: [<ffffffff8012f05b>] security_ops_task_setrlimit+0x87/0x96
Mar 24 11:19:15 grep-r kernel: [<ffffffff8009dc2f>] do_prlimit+0xd7/0x1d2
Mar 24 11:19:15 grep-r kernel: [<ffffffff8009ed78>] sys_setrlimit+0x36/0x43
Mar 24 11:19:15 grep-r kernel: [<ffffffff8005d116>] system_call+0x7e/0x83
Mar 24 11:19:15 grep-r kernel:

###############################

https://www.redhat.com/archives/rhelv5-list/2013-January/msg00009.html


이거 콜 트레이스는 무시해도됨


kill -9 $(ps -ef | grep "error\/warning check" | awk '{print $2}')

+ Recent posts