☰

Verhält sich SIGTERM ohne Signalhandler identisch wie SIGKILL?

tag-icon • tag-icon process signals
Verhält sich SIGTERM ohne Signalhandler identisch wie SIGKILL?

Die meisten Beschreibungen von SIGTERM und SIGKILL weisen darauf hin, dass SIGKILL,

Im Gegensatz zu SIGTERM und SIGINT kann [...] nicht abgefangen oder ignoriert werden [...] (Wikipedia)

Ist das der einzige Unterschied zwischen SIGTERM und SIGKILL? Insbesondere wenn ein Prozess keinen SIGTERM-Handler installiert, besteht dann überhaupt ein Unterschied zwischen dem Senden von SIGTERM oder SIGKILL an den Prozess?

Antwort1

In Ermangelung einer Signalkonfiguration sind SIGTERMund SIGKILLin der Praxis gleichwertig, zumindest aus der Sicht des beendeten Prozesses, ebenso wie die anderen Signale, deren Standardaktion darin besteht, einen Prozess zu beenden, einschließlich SIGUSR1und SIGUSR2. DaAbonnierenweist darauf hin, dass der übergeordnete Prozess über das Signal informiert wird, das den untergeordneten Prozess beendet hat (so kann Ihre Shell zwischen den Signalen unterscheiden undz.B„Beendet“ vs. „Benutzerdefiniertes Signal 1“).

Wie auf Wikipedia erwähnt, SIGKILLkann nicht abgefangen oder ignoriert werden, wohingegen SIGTERMkann; beachten Sie, dass dies bedeutet, dass ein Prozess keinen Handler installieren muss, um SIGTERMunwirksam zu sein, er kann ihn einfach blockieren oder ignorieren (siehesighold(), sigrelse()Undsigignore()).

POSIX als detaillierter Abschnitt über dieGrundprinzip der SignalverarbeitungDas Linuxsignal(7)Die Manpage dokumentiert Signale ebenfalls detailliert.

Antwort2

Ist das der einzige Unterschied zwischen SIGTERM und SIGKILL?

NEIN.

Ein großer Unterschied zwischen einem SIGKILLund einem ungefangenen SIGTERMist, dass ersteres auchaufwachenein gestoppter Prozess (so dass er sich sofort selbst zerstören könnte), während Letzteres erst nach einem Wirkung zeigt SIGCONT.

Einfaches Beispiel:

$ 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

Wenn Sie sicher sein möchten, dass Ihr TERM, HUP, INT, usw.-Signal irgendeine Wirkung hat, sollten Sie es mit einem CONTSignal koppeln (in beliebiger Reihenfolge).

Die Leute verstehen das vielleicht nicht so leicht, weil das killeingebaute Bash-Element so magisch ist -- wenn es mit einer Job-ID wie %oder %1(oder mit einer negierten PID) verwendet wird, die sich auf einen gestopptenArbeit, es wirddas alles selber machenhinter den Vorhängen:

/* 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)

verwandte Informationen