신호 처리기가 없으면 SIGTERM은 SIGKILL과 동일하게 동작합니까?

신호 처리기가 없으면 SIGTERM은 SIGKILL과 동일하게 동작합니까?

SIGTERM 및 SIGKILL에 대한 대부분의 설명은 SIGKILL,

SIGTERM 및 SIGINT와 달리 [...]는 포착하거나 무시할 수 없습니다. [...] (위키피디아)

이것이 SIGTERM과 SIGKILL의 유일한 차이점입니까? 특히 프로세스가 SIGTERM 핸들러를 설치하지 않은 경우 프로세스에 SIGTERM 또는 SIGKILL을 보내는 것 사이에 차이가 있습니까?

답변1

신호 구성이 없는 경우 SIGTERM및 을 SIGKILL포함하여 기본 동작이 프로세스를 종료하는 다른 신호와 마찬가지로 적어도 종료된 프로세스의 관점에서 실제로 동일합니다 . 처럼SIGUSR1SIGUSR2일까츄지적하면, 상위 프로세스는 하위 프로세스를 종료한 신호에 대한 정보를 받습니다(이것이 쉘이 신호를 구별하고 인쇄할 수 있는 방법입니다).예를 들어"종료됨" 및 "사용자 정의 신호 1").

Wikipedia에서 언급했듯이 SIGKILL잡히거나 무시될 수 없지만 SIGTERMcan; 이는 프로세스가 무효화되기 위해 핸들러를 설치할 필요가 없으며 SIGTERM간단히 차단하거나 무시할 수 있음을 의미합니다(참조:sighold(), sigrelse()그리고sigignore()).

POSIX에 대한 세부 섹션으로신호 처리의 근거. 리눅스signal(7)맨페이지에는 신호에 대한 자세한 내용도 문서화되어 있습니다.

답변2

이것이 SIGTERM과 SIGKILL의 유일한 차이점입니까?

아니요.

SIGKILLa 와 uncaught 의 큰 차이점은 SIGTERM전자도 마찬가지라는 것입니다.깨우다중지된 프로세스(즉시 자체적으로 파괴될 수 있음)인 반면 후자는 SIGCONT.

간단한 예:

$ sleep 1000 & sleep 1; kill -TSTP $!
[1] 6455

[1]+  Stopped                 sleep 1000
$ kill -TERM 6455
$ jobs
[1]+  Stopped                 sleep 1000
$ kill -CONT 6455
$ jobs
[1]+  Terminated              sleep 1000

TERM, , 등 HUPINT신호가 효과가 있는지 확인하려면 CONT순서에 상관없이 신호와 쌍을 이루어야 합니다.

bash kill내장의 마법 때문에 사람들은 이를 쉽게 이해하지 못할 수도 있습니다. 즉, 중지된 작업을 참조하는 작업 ID %또는 %1(또는 부정된 pid와 함께) 사용하는 경우입니다.직업, 그럴 것이다그 자체로 다 해커튼 뒤에:

/* Give PID SIGNAL.  This determines what job the pid belongs to (if any).
   If PID does belong to a job, and the job is stopped, then CONTinue the
   job after giving it SIGNAL.  Returns -1 on failure.  If GROUP is non-null,
   then kill the process group associated with PID. */
int
kill_pid (pid, sig, group)

관련 정보