나는 이 작업을 시도하는 프로세스 관리자를 많이 보았습니다. 프로세스를 종료하려면 SIGTERM만 사용해야 한다는 것이 내 이해였습니다. 프로세스 자체를 정리하는 데 알 수 없는 시간이 걸릴 수 있습니다. 느린 시스템에서는 몇 분이 걸릴 수 있습니다. 나는 항상 유일한 해결책은 인내심을 갖고 프로그램이 정리되고 정상적으로 종료될 때까지 기다리는 것이라고 생각했습니다. 프로세스가 SIGTERM을 포착하지 못하는 경우 이는 버그이므로 소프트웨어 관리자에게 보고해야 합니다.
나는 docker와 같은 인기 있는 도구도 이 작업을 수행하는 것을 보았습니다.
사용법: docker stop [OPTIONS] CONTAINER [CONTAINER...]
실행 중인 컨테이너를 중지합니다(SIGTERM을 보낸 다음 유예 기간 후에 SIGKILL을 보냅니다).
이것이 나쁜 습관입니까? 제가 궁금한 점 중 하나는 SystemV 스타일 초기화 시스템에서 종료 절차가 어떻게 작동하는지입니다. 일부 맨페이지와 기타 질문을 살펴봤지만 명확한 답변을 찾을 수 없습니다. 나는 각 init 서비스(용어?)가 실행 수준의 변경을 확인하고 init 스크립트에 정의된 대로 적절한 "중지" 기능을 실행한다고 추측합니다. 이 작업을 하나씩 수행하여 각 서비스가 제대로 종료되는지 확인합니까? init 스크립트로 처리되지 않는 프로세스는 어떻게 되나요? SIGKILL하기 전에 사용되는 유예 기간을 막연하게 언급하는 일부 질문을 보았지만 누군가가 자세히 설명하거나 적어도 올바른 방향을 알려줄 수 있기를 바랐습니다. :)
누군가 이것이 systemd에서 어떻게 작동하는지 더 자세히 알아내도록 도와줄 수 있다면 기꺼이 연구하고 자세히 알아볼 것입니다. 맨페이지를 살펴봤지만 여기에서도 확실한 내용을 찾을 수 없습니다.
답변1
케이크를 먹거나 먹을 수 있습니다. 프로그램은 SIGTERM에 반응하는 데 필요한(또는 원하는) 시간을 갖고 싶어합니다. 시스템(프로그램 관리자)이 종료되기를 원합니다. 시스템이 영원히 기다리는 경우 프로그램이 응답하지 않음으로써(프로그램이 악의적이거나 버그가 있기 때문에) 시스템 종료를 가로챌 수 있습니다.
일반적인 종료 순서에서 각 데몬은 데몬 작성자나 패키지 작성자가 제공하는 init 스크립트(원하는 경우 종료 스크립트라고 부름)를 통해 종료됩니다. 데몬에 따라 init 스크립트는 단지 신호만 보낼 수도 있고 좀 더 제어된 종료를 수행할 수도 있습니다(예: 소켓에 기록). init 스크립트는 데몬이 만족스럽게 종료되었음을 보고할 때까지 기다리거나 강제로 종료할 수 있습니다. Init 스크립트는 루트로 실행됩니다( su권한이 낮은 사용자로서 작업의 일부를 수행하기 위해 호출할 수 있음 ). 그들은 협조적이어야 하므로 시스템을 영원히 정지 상태로 두는 것이 허용됩니다.
초기화 스크립트가 작업을 완료하면 모든 서비스가 종료되어야 합니다. 나머지 프로세스는 중요하지 않거나 오작동하는 것으로 간주됩니다. 따라서 이 단계에서 나머지 프로세스는 종료하라는 지시를 받고(SIGTERM) 유예 기간(완전히 종료할 수 있는 마지막 기회 제공) 후에 시스템은 종료되어 나머지 프로세스가 강제로 종료됩니다(SIGKILL).
init 스크립트를 일반적인 체포 절차(영장 발부, 경고 외침 등)로 생각하십시오. 법을 준수하는 데몬은 이 시점에서 종료되어야 하지만, 데몬에는 절차를 지연시킬 수 있는 변호사(init 스크립트)가 있습니다. 원하다. 정상적인 프로세스가 완료되면 나머지 데몬은 적대적인 것으로 간주됩니다. 시스템은 경고 사격(SIGTERM)을 발사한 후 지연 후 SIGKILL에 사격합니다.