☰

지속적인 좀비 프로세스는 버그의 신호입니까?

tag-icon • tag-icon linux process
지속적인 좀비 프로세스는 버그의 신호입니까?

(OS: 데비안 변형.)

좀비 상태의 프로세스가 있습니다. 프로세스 PPid에 속해 있습니다 gvim. 의 내용 /proc/[pid]/wchan은do_exit, 및 는 비어 있습니다. /comm아래 에 표시됩니다.sh/cmdline/status

이것이 버그일까요 gvim? Wikipedia 항목에서좀비 프로세스프로그램이 자발적으로 통화를 거부할 수 있다고 읽었 wait는데 이는 gvim꽤 오랫동안 유휴 상태였던 세션에 대한 것입니다. 프로세스 를 종료했지만 gvim좀비는 여전히 주변에 숨어 있습니다. 이것이 OS 버그를 나타낼 수 있습니까?

다시 Wikipedia에서:

상위 프로그램이 더 이상 실행되지 않는 경우 좀비 프로세스는 일반적으로 운영 체제의 버그를 나타냅니다.

init그리고 버려진 프로세스를 얼마나 자주 수확합니까 ? gvim의 사망 이후 최소 60분이 지났지만 여전히 남아 있습니다.

반면에 그럴 수도 있고 sh아닐 수도 있나요 gvim?

그만큼/status 파일0의 상태 SigQ.

$ less /proc/30339/status
Name     : sh
State    : Z (zombie)
Tgid     : 30339
Pid      : 30339
PPid     : 29673
TracerPid:     0
Uid      :  1000    1000    1000    1000
Gid      :  1000    1000    1000    1000
FDSize   :     0
Groups   :     4 7 20 24 27 29 30 46 107 124 127 1000 
Threads  :     1
SigQ     : 0/30658
SigPnd   : 0000000000000000
ShdPnd   : 0000000000000000
SigBlk   : 0000000000000000
SigIgn   : 0000000000003001
SigCgt   : 0000000000010002
CapInh   : 0000000000000000
CapPrm   : 0000000000000000
CapEff   : 0000000000000000
CapBnd   : ffffffffffffffff
Cpus_allowed     :   3
Cpus_allowed_list:   0-1
Mems_allowed     :   1
Mems_allowed_list:   0
voluntary_ctxt_switches   :   2
nonvoluntary_ctxt_switches:   3

그것이 나의 아름다운 잠을 파괴한다는 것은 아니지만, 궁금합니다…

답변1

좀비를 보는 것은 좀비를 생성한 프로세스의 버그를 나타내는 경향이 있습니다. 해당 프로세스는 좀비를 제거(호출하여 wait)하거나 명시적으로 무시 SIGCLD(또는 SA_NOCLDWAIT플래그 설정)해야 합니다.

그러나 이것은 사소한 버그입니다. 좀비 프로세스는 프로세스 테이블의 항목만 소비하는데, 이는 무시할 수 있는 양의 리소스입니다. 프로세스가 수천 명의 좀비를 남겨둔 경우에만 문제가 심각해집니다.

좀비의 부모 프로세스를 종료하지 않았습니다. 그렇지 않으면 좀비가 사라졌을 것입니다. 프로세스 29673(좀비의 부모)은 여전히 ​​살아 있고 작동 중입니다(그러나 wait작동하지는 않음). 이는 Gvim이 아니라 일부 하위 프로세스이거나 Gvim 창을 닫았지만 프로그램이 계속 실행 중입니다. ps l 29673이 프로세스가 무엇인지 확인하려면 실행하세요 .

답변2

좀비 프로세스가 계속해서 발생한다면 확실히 뭔가 문제가 있다고 생각하는 경향이 있습니다. 좀비 프로세스가 발생합니다. 나는 일반적으로 직장과 집에서 유지 관리하는 다양한 시스템을 한 달에 몇 번씩 봅니다.

일반적으로 이러한 오류는 운영자 오류나 특정 소프트웨어 문제로 인해 발생할 수 있습니다. 일반적으로 재부팅하면 문제가 해결되며 일반적으로 한동안은 다시 발생하지 않습니다.

문제가 있는 경우 상위 프로세스 ID(PPID)에 연결하여 gdb문제를 확인하거나 종료하려고 시도할 수 있습니다.

$ gdb -p 100
(gdb) call waitpid(200, 0, 0)
(gdb) quit

당신이 그것을 할 수 있다면 나는 아래의 추가 리소스를 통해 이를 처리하는 다른 기술을 읽을 것입니다.

참고자료

답변3

gvim을 사용할 때마다 이런 일이 발생합니까? gvim은 좀비가 종료된 후 떠나는 것과 별도로 작동합니까? 실제 문제가 발생하지 않는 한 나는 이를 무시할 것입니다. 좀비는 시스템 리소스에 세금을 부과하지 않습니다. 그것이 gvim이나 아마도 gtk의 버그라면 놀라지 않을 것입니다. 그러나 프로그램이 전혀 작동하지 않는 한 나는 그것을 무시할 것입니다.

좀비/비활성 프로세스는 일반적으로 부모 프로세스가 수신을 시작하기 전에 자식 프로세스가 종료될 때 발생합니다. 만족스럽게 종료되었음에도 불구하고 종료 상태를 수신할 프로그램이 주변에 없었기 때문에 자식은 "머무르지 않고" 좀비가 됩니다. 좀비가 발생하는 또 다른 이유는 큰 프로세스 트리가 무너질 때일 수 있습니다. 아마도 누군가가 트리에서 하나 이상의 프로세스를 죽이려고 시도했기 때문일 수 있습니다.

좀비는 누군가가 관심을 가질 경우를 대비해 OS가 종료 상태와 제대로 종료되지 않은 프로세스에 대한 기타 정보를 유지하는 방법입니다. 프로세스 테이블의 항목 외에 좀비는 리소스(예: 메모리나 CPU)를 차지하지 않습니다.

IMHO WikiPedia는 잘못되었거나 적어도 오해하기 쉽습니다. 수확되지 않은 좀비가 종료에 의해 생성된 기본 프로세스 이후에 남아 있으면 OS에 오류가 있음을 의미합니다. 좀비가 부모로부터 살아남는 것은 드문 일이 아니며, 이 경우 init(PID 1)에 의해 입양됩니다. init결국 그것을 얻을 수도 있지만 일부 좀비는 - 심지어 init에 의해 채택된 좀비라도 - 재부팅할 때까지 남아 있을 수 있습니다. 프로세스 테이블을 가득 채울 정도로 많은 좀비가 있지 않는 한, 거의 문제가 되지 않습니다.

물론, 좀비는 종종 무언가 잘못되었음을 나타냅니다. 프로그램이 부모가 예상하기 전에 죽는 자식을 생성한다는 것입니다. 하지만 문제가 OS일 필요는 없습니다. 그래도 문제를 일으키는 것은 확실히 OS 구성 요소일 수 있습니다. 사운드 서버가 없거나 잘못 구성된 경우 프로그램의 사운드를 처리해야 하는 하위 프로세스가 즉시 종료되어 좀비로 남아 있게 됩니다.

답변4

언제나 그렇듯이 상황에 따라 다릅니다. 대부분의 모니터링 도구는 특정 개수 이상의 좀비 프로세스를 발견하면 노란색이나 빨간색으로 변합니다.

따라서 기본적으로 - 예 - 이는 일반적으로 문제의 징후입니다.

그러나 나는 "정상적인" 작업의 일부로 좀비 프로세스를 생성하는 프로그램을 본 적이 있습니다. 이러한 좀비 프로세스는 해당 최상위 API(여기서는 상위 프로세스라고 말하지 않음)가 "quit/exit" 명령으로 호출될 때 사라졌습니다.

따라서 이러한 경우에는 애플리케이션이 이러한 좀비를 처리(그리고 아마도 필요할 수도 있음)한 것으로 보입니다. 따라서 모니터링을 위해 이러한 애플리케이션이 실행되는 서버에 예외를 정의해야 했습니다.

다른 경우에는 좀비가 잠시 후에 사라졌습니다. 따라서 좀비 프로세스를 사용하면 특정 비지속적 시스템 상태를 가질 수 있습니다.

귀하의 경우: gvim완료되면 좀비가 남지 않아야 하므로 아마도 버그일 것입니다.

관련 정보