Eine gute Erklärung für den Unterschied zwischen SIGKILL und SIGTERM (und warum Sie zuerst SIGTERM ausprobieren sollten)
Das Senden von Signalen an Prozesse mit kill auf einem Unix-System ist für die meisten Systemadministratoren kein neues Thema, aber ich wurde oft nach dem Unterschied zwischen kill und kill -9 gefragt.
Jedes Mal, wenn Sie kill für einen Prozess verwenden, senden Sie dem Prozess tatsächlich ein Signal (in fast allen Situationen - darauf werde ich bald eingehen). Standard C-Anwendungen verfügen über eine Header-Datei, die die Schritte enthält, die der Prozess ausführen sollte, wenn er ein bestimmtes Signal empfängt. Sie können eine vollständige Liste der verfügbaren Signale auf Ihrem System abrufen, indem Sie auf der Manpage nach Kill suchen.
Betrachten Sie einen Befehl wie diesen:
kill 2563
Dies würde ein Signal namens SIGTERM an den Prozess senden. Sobald der Prozess die Benachrichtigung erhalten hat, können einige verschiedene Dinge passieren:
- Der Vorgang wird möglicherweise sofort beendet
- Der Prozess kann nach einer kurzen Verzögerung nach dem Bereinigen der Ressourcen beendet werden
- Der Prozess läuft möglicherweise unbegrenzt weiter
Die Anwendung kann bestimmen, was sie tun möchte, sobald ein SIGTERM empfangen wurde. Während die meisten Anwendungen ihre Ressourcen bereinigen und stoppen, können einige nicht. Eine Anwendung kann so konfiguriert sein, dass sie beim Empfang eines SIGTERM etwas völlig anderes tut. Wenn sich die Anwendung in einem fehlerhaften Zustand befindet, z. B. auf Festplatten-E / A wartet, kann sie möglicherweise nicht auf das gesendete Signal reagieren.
Die meisten Systemadministratoren greifen normalerweise auf das abruptere Signal zurück, wenn eine Anwendung nicht auf ein SIGTERM reagiert:
kill -9 2563
Die -9 teilt dem Befehl kill mit, dass Sie das Signal Nr. 9 senden möchten, das SIGKILL heißt. Bei einem solchen Namen ist es offensichtlich, dass dieses Signal etwas mehr Gewicht hat.
Obwohl SIGKILL in derselben Signal-Header-Datei wie SIGTERM definiert ist, kann es vom Prozess nicht ignoriert werden. Tatsächlich wird der Prozess nicht einmal auf das SIGKILL-Signal aufmerksam gemacht, da das Signal direkt an den Kernel-Init geht. An diesem Punkt stoppt init den Prozess. Der Prozess erhält nie die Möglichkeit, das Signal zu erfassen und darauf zu reagieren.
In einigen Situationen kann der Kernel den Prozess jedoch möglicherweise nicht erfolgreich beenden. Wenn der Prozess auf Netzwerk- oder Festplatten-E / A wartet, kann der Kernel ihn nicht stoppen. Zombie-Prozesse und Prozesse, die sich in einem unterbrechungsfreien Schlaf befinden, können vom Kernel ebenfalls nicht gestoppt werden. Ein Neustart ist erforderlich, um diese Prozesse vom System zu löschen.
Wenn Sie killall (SIGTERM) an die Thunderbird-Prozesse gesendet haben, haben Sie diese Prozesse zum Stoppen aufgefordert. Einige dieser Prozesse funktionierten nicht richtig (wahrscheinlich, warum Sie sie zuerst beenden mussten), sodass sie nicht auf das SIGTERM-Signal reagieren konnten.