커널이 여전히 SIGKILL을 보내는 이유는 무엇입니까? [복사]

종료된 프로세스의 사용자 공간 부분은 SIGKILL이에 대해 전혀 알지 못합니다.커널이 모든 것을 처리한다. (이는 임시 파일, 공유 메모리 할당, 종료된 프로세스를 대신하여 다른 프로세스(예: X 서버)가 보유한 리소스 등 일부 리소스가 누출될 수 있음을 의미합니다.)

그러나 다른 프로세스가 종료된 프로세스가 어떻게 종료되었는지 알 수 있도록 신호는 여전히 전달되어야 합니다. 부모, 사용wait, 종료된 프로세스가 종료되었다는 정보를 얻게 됩니다 SIGKILL.

이것답변부분적으로 사실입니다. 프로세스를 종료하면 메모리를 해제하는 것 이상의 효과가 있습니다. 그러나 a는 SIGKILL어깨를 두드리거나 무언가를 하라는 요청이 아니며, 프로세스가 무시하거나 처리할 수 없는 몇 안 되는 신호 중 하나입니다. 즉, a는 SIGKILL항상 커널의 기본 핸들러에 의해 처리되며 대부분의 신호와 마찬가지로 이 기본 작업은 신호를 수신하는 프로세스를 종료하는 것입니다. 프로그램의 사용자 공간 부분은 신호를 보지도 않기 때문에 뭔가를 할 필요도 없고 협력할 필요도 없습니다. 따라서 프로그램은 신호를 받은 후에 악의로든 어떤 식으로든 오작동하지 않습니다 SIGKILL. 또는 일부 프로그래밍 오류로 인해. 대신 프로세스의 커널 측에서 신호를 처리하고 프로세스를 종료합니다. 따라서 어떤 면에서는 커널이 프로세스를 종료해야 한다고 커널의 다른 부분에 알려줌으로써 프로세스를 직접 종료합니다.

프로그래밍 관점에서 커널이 프로그램을 종료하려고 할 때(주로 리소스 부족, 특히 사용 가능한 RAM 부족으로 인해 발생) 프로세스가 종료되어야 할 때 이를 수행하는 코드를 복사하는 두 가지 가능성이 있습니다. 종료되거나 신호를 전달하는 함수를 호출하면 프로세스를 종료하는 데 필요한 모든 것이 처리된다는 것을 알 수 있습니다. 두 번째 접근 방식은 초기 노력을 줄일 뿐만 아니라 중복 코드를 유지 관리할 필요가 없으므로 장기적으로 작업량이 줄어듭니다.

다른 매우 좋은 답변을 완성하기 위해 신호 작동 방식에 대한 개요:

프로세스 실행은 사용자 공간 또는 커널 공간의 두 가지 모드에서 발생할 수 있습니다. 사용자 공간에서는 프로세스가 프로그램의 코드를 실행하고, 커널 공간에서는 프로세스가 커널의 코드를 실행합니다. 프로세스는 작업을 수행하기 위해 가능할 때마다 사용자 공간에서 실행되지만 때때로 실행 중에 프로세스를 생성할 때 커널 공간에 들어갑니다.시스템 호출(이는 파일 읽기와 같이 시스템 자체 하드웨어 또는 공유 리소스에 대한 권한 있는 작업에 필요하거나 실행 중에 중단되는 경우에 필요합니다.

신호는 두 가지 상황, 즉 프로세스가 시스템 호출을 완료한 후 사용자 공간으로 돌아올 때 또는 시스템 호출에서 깨어날 때 처리됩니다.방해받지 않는 수면실행을 재개합니다. 두 경우 모두 프로세스는 커널 공간에 상주합니다. 먼저, 커널은 프로세스에 보류 중인 신호가 있는지 확인하고 이에 대한 조치를 취합니다. 예를 들어, 신호에 대해 핸들러가 정의되면 프로세스가 사용자 공간으로 돌아올 때 이를 실행하게 됩니다. 본인 말대로 KILL 사건은 잡을 수 없다는 점에서 특별하다. 따라서 커널의 경우 실제로는 간단한 경우입니다. 사용자 공간으로의 복귀가 취소되고 프로세스가 즉시 종료됩니다. 즉, 사용자 공간에서 더 이상 코드를 실행하지 않고 메모리가 해제되며 상위 프로세스가 종료됩니다. 사망 등의 소식을 알립니다.

종료 시 프로세스는 프로세스 컨텍스트/환경에서 메모리 해제, 세마포어 해제, 파일 닫기 및 일부 통계와 같은 일부 정리 작업을 수행합니다. 커널이 이를 복제할 수 있지만 프로세스를 탭하여 자살하도록 요청하는 것이 더 쉽습니다.