SIGKILLing nach einer Schonfrist

SIGKILLing nach einer Schonfrist

Ich habe viele Prozessmanager gesehen, die das versuchen. Ich war der Meinung, dass man SIGTERM nur verwenden sollte, um einen Prozess zu beenden. Der Prozess kann eine unbekannte Zeit brauchen, um sich selbst zu bereinigen; auf einem langsamen System kann es Minuten dauern. Ich dachte immer, die einzige Lösung wäre, geduldig zu sein und zu warten, bis das Programm bereinigt und ordnungsgemäß beendet wird. Wenn der Prozess SIGTERMs nicht abfängt, handelt es sich um einen Fehler und sollte dem Software-Betreuer gemeldet werden.

Ich habe gesehen, dass beliebte Tools wie Docker ebenfalls versuchen, Folgendes zu tun:

Verwendung: Docker Stop [OPTIONEN] CONTAINER [CONTAINER...]

Stoppen Sie einen laufenden Container (Senden Sie SIGTERM und dann nach der Nachfrist SIGKILL).

Ist das eine schlechte Praxis? Mich würde auch interessieren, wie das Herunterfahren auf einem Init-System im SystemV-Stil funktioniert. Ich habe mir einige Manpages und andere Fragen angesehen, kann aber keine eindeutige Antwort finden. Ich vermute, dass jeder Init-Dienst (Terminologie?) die Änderung des Runlevels erkennt und die richtige „Stopp“-Funktion ausführt, wie im Init-Skript definiert. Tut er das nacheinander und stellt sicher, dass jeder Dienst ordnungsgemäß beendet wird? Was passiert mit Prozessen, die nicht von Init-Skripten verarbeitet werden? Ich habe in einigen Fragen vage die Verwendung einer Schonfrist erwähnt, bevor sie per SIGKILL beendet werden, aber ich hatte gehofft, dass jemand das näher erläutern oder mich zumindest in die richtige Richtung weisen könnte. :)

Wenn mir jemand helfen könnte, mehr darüber herauszufinden, wie das auch mit systemd funktioniert, würde ich gerne recherchieren und mehr herausfinden. Ich habe mir die Manpages angesehen, kann aber auch hier nichts Definitives finden.

Antwort1

Sie können Ihren Kuchen haben oder ihn essen. Das Programm möchte so viel Zeit haben, wie es braucht (oder will), um auf SIGTERM zu reagieren. Das System (Programmmanager) möchte in der Lage sein, sich zu beenden. Wenn das System ewig wartet, kann ein Programm das Herunterfahren des Systems kapern, indem es nie reagiert (entweder weil das Programm bösartig ist oder weil es fehlerhaft ist).

In einer normalen Herunterfahrsequenz wird jeder Daemon über ein Init-Skript (nennen Sie es Herunterfahrskript, wenn Sie möchten) beendet, das vom Autor oder Paketierer des Daemons bereitgestellt wird. Abhängig vom Daemon kann das Init-Skript ihm einfach ein Signal senden oder ein kontrollierteres Herunterfahren durchführen (z. B. durch Schreiben in einen Socket). Das Init-Skript kann warten, bis der Daemon meldet, dass er zufriedenstellend heruntergefahren ist, oder es kann ihn zwangsweise beenden. Init-Skripte werden als Root ausgeführt (sie können aufgerufen werden, suum einen Teil ihrer Aufgabe als Benutzer mit weniger Privilegien auszuführen); sie sollen kooperativ sein, daher dürfen sie das System für immer hängen lassen.

Sobald Init-Skripte ihre Arbeit beendet haben, sollten alle Dienste heruntergefahren werden. Alle verbleibenden Prozesse sollten entweder unwichtig oder fehlerhaft sein. In diesem Stadium werden die verbleibenden Prozesse angewiesen, heruntergefahren zu werden (SIGTERM). Nach einer Übergangsfrist (die ihnen eine letzte Chance zum sauberen Herunterfahren gibt) muss das System heruntergefahren werden, damit alle verbleibenden Prozesse zwangsweise beendet werden (SIGKILL).

Stellen Sie sich die Init-Skripte als normales Festnahmeverfahren vor – Haftbefehle vorzeigen, eine Warnung aussprechen usw. Ein gesetzestreuer Daemon sollte an dieser Stelle heruntergefahren werden, obwohl Daemonen Anwälte (die Init-Skripte) haben, die das Verfahren beliebig lange hinauszögern können. Sobald der normale Prozess abgeschlossen ist, werden die verbleibenden Daemons als feindlich eingestuft. Das System feuert einen Warnschuss ab (SIGTERM) und schießt dann nach einer Verzögerung auf SIGKILL.

verwandte Informationen