Linux에서 좀비 프로세스를 종료하는 방법
게시 됨: 2022-01-29제대로 작성되지 않았거나 성능이 좋지 않은 프로그램은 Linux 컴퓨터 내부에 좀비 프로세스를 잠복하게 할 수 있습니다. 좀비가 어떻게 만들어지고 마지막으로 좀비를 눕힐 수 있는지 알아보십시오.
Linux에서 프로세스 상태가 작동하는 방식
물론 Linux는 컴퓨터에서 실행되는 모든 응용 프로그램과 데몬을 추적해야 합니다. 이를 수행하는 방법 중 하나는 프로세스 테이블을 유지 관리하는 것입니다. 이것은 커널 메모리의 구조 목록입니다. 각 프로세스에는 이에 대한 일부 정보가 포함된 이 목록의 항목이 있습니다.
각 프로세스 테이블 구조에는 그다지 많지 않습니다. 그들은 프로세스 ID, 몇 가지 다른 데이터 항목 및 해당 프로세스의 프로세스 제어 블록(PCB)에 대한 포인터를 보유합니다.
Linux가 각 프로세스에 대해 조회하거나 설정해야 하는 많은 세부 사항을 담고 있는 PCB입니다. PCB는 또한 프로세스가 생성되고 처리 시간이 주어질 때 업데이트되고 최종적으로 파괴됩니다.
Linux PCB에는 95개 이상의 필드가 있습니다. task_struct.h
라는 구조로 정의되어 있으며 700줄 이상입니다. PCB에는 다음 유형의 정보가 포함되어 있습니다.
- 프로세스 상태 : 상태는 아래에 설명되어 있습니다.
- 프로세스 번호 : 운영 체제 내에서 고유한 식별자입니다.
- 프로그램 카운터 : 다음에 이 프로세스가 CPU에 액세스할 수 있을 때 시스템은 이 주소를 사용하여 실행되어야 하는 프로세스의 다음 명령을 찾습니다.
- Registers : 이 프로세스에서 사용하는 CPU 레지스터의 목록입니다. 목록에는 누산기, 인덱스 레지스터 및 스택 포인터가 포함될 수 있습니다.
- 파일 목록 열기 : 이 프로세스와 관련된 파일입니다.
- CPU 스케줄링 정보 : 이 프로세스에 CPU 처리 시간이 얼마나 자주, 얼마나 오래 할당되는지 결정하는 데 사용됩니다. 프로세스의 우선 순위, 스케줄링 대기열에 대한 포인터 및 기타 스케줄링 매개변수는 PCB에 기록되어야 합니다.
- 메모리 관리 정보 : 프로세스 메모리의 시작 및 끝 주소, 메모리 페이지에 대한 포인터와 같이 이 프로세스가 사용하는 메모리에 대한 세부 정보입니다.
- I/O 상태 정보 : 프로세스에서 사용하는 모든 내부 또는 출력 장치.
"프로세스 상태"는 다음 중 하나일 수 있습니다.
- R: 실행 중이거나 실행 가능한 프로세스입니다. 실행 중이란 CPU 주기를 수신하고 실행 중임을 의미합니다. 실행 가능한 프로세스는 실행할 준비가 되어 있고 CPU 슬롯을 기다리고 있습니다.
- S: 잠자는 과정. 프로세스는 입력 또는 출력 작업과 같은 작업이 완료되거나 리소스를 사용할 수 있게 되기를 기다리고 있습니다.
- D: 프로세스가 중단되지 않는 절전 상태에 있습니다. 차단 시스템 호출을 사용 중이며 시스템 호출이 완료될 때까지 계속할 수 없습니다. "Sleep" 상태와 달리 이 상태의 프로세스는 시스템 호출이 완료되고 실행이 프로세스로 반환될 때까지 신호에 응답하지 않습니다.
- T:
SIGSTOP
신호를 수신하여 프로세스가 종료(중지)되었습니다.SIGKILL
또는SIGCONT
신호에만 응답하여 각각 프로세스를 종료하거나 계속하도록 지시합니다. 이것은 전경(fg
)에서 배경(bg)
작업으로 전환할 때 일어나는 일입니다. - Z: 좀비 프로세스입니다. 프로세스가 완료되면 그냥 사라지는 것이 아닙니다. 사용 중인 메모리를 해제하고 메모리에서 자신을 제거하지만 프로세스 테이블과 PCB의 항목은 그대로 유지됩니다. 상태는
EXIT_ZOMBIE
로 설정되고 부모 프로세스는 자식 프로세스가 완료되었음을 (SIGCHLD
신호에 의해) 알립니다.
Zombie 상태에서 부모 프로세스는 자식 프로세스가 생성될 때 wait()
함수 패밀리 중 하나를 호출합니다. 그런 다음 자식 프로세스의 상태 변경을 기다립니다. 자식 프로세스가 신호에 의해 중지, 계속 또는 종료되었습니까? 코드의 자연스러운 완성을 통해 실행되어 종료되었습니까?
상태 변경이 자식 프로세스의 실행이 중지되었음을 의미하는 경우 종료 코드를 읽습니다. 그런 다음 자식의 PCB가 파괴되고 프로세스 테이블의 항목이 제거됩니다. 이상적으로는 이 모든 일이 눈 깜짝할 사이에 일어나며 좀비 상태의 프로세스는 오랫동안 존재하지 않습니다.
관련: Linux에서 백그라운드 프로세스를 실행하고 제어하는 방법
Linux에서 좀비 프로세스가 발생하는 원인은 무엇입니까?
잘못 작성된 상위 프로세스는 하위 프로세스가 생성될 때 wait()
함수를 호출하지 않을 수 있습니다. 이것은 자식 프로세스의 상태 변경을 감시하는 것이 없으며 SIGCHLD
신호가 무시됨을 의미합니다. 또는 다른 응용 프로그램이 잘못된 프로그래밍이나 악의적인 의도로 인해 상위 프로세스의 실행에 영향을 미치고 있을 수 있습니다.
그러나 상위 프로세스가 하위 프로세스의 상태 변경을 감시하지 않는 경우 적절한 시스템 하우스키핑이 발생하지 않습니다. PCB와 프로세스 테이블의 항목은 자식 프로세스가 종료될 때 제거되지 않습니다. 그 결과 좀비 상태가 PCB에서 제거되지 않습니다.
좀비는 약간의 메모리를 사용하지만 일반적으로 문제를 일으키지 않습니다. 프로세스 테이블의 항목은 작지만 해제될 때까지 프로세스 ID를 재사용할 수 없습니다. 64비트 운영 체제에서는 PCB가 프로세스 테이블 항목보다 훨씬 크기 때문에 문제를 일으키지 않을 것입니다.
엄청난 수의 좀비가 다른 프로세스에 사용할 수 있는 메모리 양에 영향을 미칠 수 있습니다. 하지만 좀비가 그렇게 많다면 상위 애플리케이션이나 운영 체제 버그에 심각한 문제가 있는 것입니다.
좀비 프로세스를 제거하는 방법
이미 죽었기 때문에 좀비 프로세스를 죽일 수 없습니다. 메모리에서 제거되었기 때문에 신호에 응답하지 않습니다. SIGKILL
신호를 보낼 곳이 없습니다. SIGCHLD
신호를 부모 프로세스에 보내려고 시도할 수 있지만 자식 프로세스가 종료되었을 때 작동하지 않았다면 지금도 작동하지 않을 것입니다.
신뢰할 수 있는 유일한 솔루션은 상위 프로세스를 종료하는 것입니다. 종료되면 Linux 시스템에서 실행되는 첫 번째 프로세스인 init
프로세스가 자식 프로세스를 상속합니다(프로세스 ID는 1).
init
프로세스는 정기적으로 필요한 좀비 정리를 수행하므로 좀비를 죽이려면 좀비를 생성한 프로세스를 종료하기만 하면 됩니다. top
명령은 좀비가 있는지 확인하는 편리한 방법입니다.
다음을 입력합니다.
맨 위
이 시스템에는 8개의 좀비 프로세스가 있습니다. ps
명령을 사용하여 이를 egrep
에 파이프하여 나열할 수 있습니다. 다시 말하지만, 좀비 프로세스에는 "Z" 상태 플래그가 있으며 일반적으로 "결함"도 표시됩니다.
다음을 입력합니다.
추신 보조 | egrep "Z|없음"
좀비 프로세스가 나열됩니다.
이것은 top
을 앞뒤로 스크롤하는 것보다 좀비의 프로세스 ID를 발견하는 더 깔끔한 방법입니다. 또한 "badprg"라는 응용 프로그램이 이러한 좀비를 생성했음을 알 수 있습니다.
첫 번째 좀비의 프로세스 ID는 7641이지만 부모 프로세스의 프로세스 ID를 찾아야 합니다.
를 다시 사용하여 그렇게 할 수 있습니다. 출력 옵션( ps
-o
)을 사용하여 ps
에게 부모의 프로세스 ID만 표시하도록 지시한 다음 ppid=
플래그와 함께 전달합니다.
찾고자 하는 프로세스는 -p
(프로세스) 옵션을 사용하여 표시한 다음 좀비의 프로세스 ID를 전달합니다.
따라서 다음 명령을 입력하여 프로세스 7641에 대한 프로세스 정보를 조회하지만 상위 프로세스의 ID만 보고합니다.
추신 -o ppid= -p 7641
부모 프로세스 ID가 7636이라고 들었습니다. 이제 ps
를 다시 한 번 사용하여 이를 상호 참조할 수 있습니다.
우리는 이것이 이전의 상위 프로세스의 이름과 일치하는 것을 볼 수 있습니다. 상위 프로세스를 종료하려면 다음과 같이 kill 명령과 함께 SIGKILL 옵션을 사용하십시오.
죽이기 -SIGKILL 7636
상위 프로세스의 소유자에 따라 sudo
를 사용해야 할 수도 있습니다.
좀비는 무섭지 않다…
... 그들이 거대한 무리에 있지 않는 한. 몇 가지는 걱정할 필요가 없으며 간단한 재부팅으로 지워집니다.
그러나 응용 프로그램이나 프로세스가 항상 좀비를 생성한다는 사실을 알게 된다면 이를 살펴봐야 합니다. 조잡하게 작성된 프로그램일 가능성이 가장 높으며, 이 경우 하위 프로세스 후에 제대로 정리되는 업데이트된 버전이 있을 수 있습니다.