(운영 체제: Debian 변형.)
좀비 상태의 프로세스입니다. PPid프로세스 에 속합니다 gvim. 내용 /proc/[pid]/wchan은do_exit,
/comm은 아래와 같이 sh비어 /cmdline있습니다 ./status
이것이 버그일까요 gvim? Wikipedia 항목에서좀비 프로세스프로그램이 자발적으로 호출을 거부할 수 있다고 읽었 wait으나 이는
gvim상당한 시간 동안 유휴 상태인 세션에 대한 것입니다. 프로세스 를 종료했지만 gvim좀비가 여전히 주변에 숨어 있습니다. 이는 운영 체제 버그를 나타냅니까?
다시 Wikipedia에서:
좀비 프로세스는 일반적으로 상위 프로그램이 더 이상 실행되지 않는 경우 운영 체제의 버그를 나타냅니다.
init버려진 프로세스는 얼마나 자주 수집되나요? gvim사망한 지 최소 60분이 지났지만 여전히 남아 있습니다.
반면에 그럴 수도 sh있고 아닐 수도 있지 않을까 gvim?
이것/status 문서SigQ상태가 0입니다.
$ 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의 버그라면 놀라지 않을 것입니다. 그러나 프로그램이 단순히 작동하지 않는 한 나는 그것을 무시할 것입니다.
좀비/죽은 프로세스는 일반적으로 상위 프로세스가 수신을 시작하기 전에 하위 프로세스가 종료될 때 발생합니다. 자식이 만족스럽게 종료되더라도 종료 상태를 수신할 프로그램이 주변에 없기 때문에 "지속"하므로 좀비가 됩니다. 좀비의 또 다른 원인은 대규모 프로세스 트리가 붕괴되는 경우입니다. 아마도 누군가가 트리에서 하나 이상의 프로세스를 종료하려고 시도했기 때문일 수 있습니다.
좀비는 실제로 누군가가 관심을 가질 경우를 대비하여 제대로 종료되지 않은 프로세스에 대한 종료 상태 및 기타 정보를 운영 체제가 유지하는 방법입니다. 프로세스 테이블의 항목과 별도로 좀비 프로세스는 리소스를 점유하지 않습니다(즉, 메모리나 CPU를 점유하지 않습니다).
IMHO, Wikipedia는 수확되지 않은 좀비가 생성된 기본 프로세스를 종료한 후에도 남아 있으면 운영 체제 버그를 의미한다고 주장할 때 틀렸거나 적어도 쉽게 오해할 수 있습니다. 좀비가 부모의 죽음 이후에도 살아남는 것은 드문 일이 아니며, 이 경우 init입양됩니다(PID 1). init결국에는 수확될 수 있지만 일부 좀비(init에 의해 채택된 좀비라도)는 재부팅할 때까지 남아 있을 가능성이 높습니다. 프로세스 테이블을 가득 채울 만큼 좀비 프로세스가 많지 않은 한 문제가 되는 경우는 거의 없습니다.
물론, 좀비는 일반적으로 뭔가 잘못되었다는 것을 의미합니다. 즉, 프로그램이 생성한 서브루틴이 상위 프로그램이 예상하기 전에 종료되었음을 의미합니다. 그러나 문제가 운영 체제일 필요는 없습니다. 물론 이는 운영 체제 구성 요소로 인해 발생할 수 있습니다. 누락되거나 잘못 구성된 사운드 서버로 인해 프로그램의 사운드를 처리해야 하는 하위 프로세스가 즉시 종료되어 좀비처럼 남겨집니다.
답변4
언제나 그렇듯이 상황에 따라 다릅니다. 대부분의 모니터링 도구는 특정 개수 이상의 좀비 프로세스를 발견하면 노란색이나 빨간색으로 변합니다.
따라서 기본적으로 - 예 - 이는 일반적으로 문제의 증상입니다.
그러나 일부 프로그램은 "정상적인" 작업의 일부로 좀비 프로세스를 생성하는 것을 보았습니다. 해당 최상위 API가 "quit/exit" 명령을 사용하여 호출되면(여기서 상위 프로세스에 대해 말하는 것이 아닙니다) 이러한 좀비 프로세스는 사라집니다.
따라서 이러한 경우 애플리케이션은 이러한 좀비를 처리하는(그리고 아마도 필요할 수도 있는) 것처럼 보입니다. 따라서 모니터링하려면 이러한 애플리케이션을 실행하는 서버에서 예외를 정의해야 합니다.
다른 경우에는 좀비 프로세스가 짧은 시간 내에 사라지므로 좀비 프로세스가 비영구적인 시스템 상태를 가질 수 있습니다.
귀하의 경우: gvim완료되면 좀비가 남아 있지 않아야 합니다. 따라서 아마도 버그일 것입니다.