4.8. Dämonen, Signale und Stoppen von Prozessen

Wenn Sie einen Editor benutzen, können Sie ihn leicht bedienen und Dateien laden, weil der Editor dafür Vorsorge getroffen hat und auf einem Terminal läuft. Manche Programme erwarten keine Eingaben von einem Benutzer und lösen sich bei erster Gelegenheit von ihrem Terminal. Ein Webserver zum Beispiel antwortet auf Web-Anfragen und nicht auf Benutzereingaben. Mail-Server sind ein weiteres Beispiel für diesen Typ von Anwendungen.

Diese Programme sind als Dämonen bekannt. Der Begriff Dämon stammt aus der griechischen Mythologie und bezeichnet ein Wesen, das weder gut noch böse ist und welches unsichtbar nützliche Aufgaben verrichtet. Deshalb ist das BSD Maskottchen dieser fröhlich aussehende Dämon mit Turnschuhen und Dreizack.

Programme, die als Dämon laufen, werden entsprechend einer Konvention mit einem d am Ende benannt. BIND steht beispielsweise für Berkeley Internet Name Domain, das tatsächlich laufende Programm heißt aber named. Der Apache Webserver wird httpd genannt und der Druckerspool-Dämon heißt lpd. Dies ist allerdings nur eine Konvention. Der Dämon der Anwendung sendmail heißt beispielsweise sendmail und nicht maild.

Eine Möglichkeit mit einem Dämon oder einem laufenden Prozess zu kommunizieren, ist über das Versenden von Signalen mittels kill(1). Es gibt eine Reihe von verschiedenen Signalen. Manche haben eine feste Bedeutung, während andere in der Dokumentation der Anwendung beschrieben sind. Ein Benutzer kann ein Signal nur an einen Prozess senden, welcher ihm gehört. Wird versucht ein Signal an einen Prozess eines anderen Benutzers zu senden, resultiert dies in einem Zugriffsfehler mangels fehlender Berechtigungen. Die Ausnahme ist der root-Benutzer, welcher jedem Prozess Signale senden kann.

FreeBSD kann auch ein Signal an einen Prozess senden. Wenn eine Anwendung schlecht geschrieben ist und auf Speicher zugreift, auf den sie nicht zugreifen soll, so sendet FreeBSD dem Prozess das Segmentation Violation Signal (SIGSEGV). Wenn eine Anwendung den alarm(3) Systemaufruf benutzt hat, um nach einiger Zeit benachrichtigt zu werden, bekommt sie das Alarm Signal (SIGALRM) gesendet.

Zwei Signale können benutzt werden, um einen Prozess zu stoppen: SIGTERM und SIGKILL. SIGTERM fordert den Prozess höflich zum Beenden auf. Der Prozess kann das Signal abfangen und hat dann Gelegenheit Logdateien zu schließen und die Aktion, die er durchführte, abzuschließen. In manchen Situationen kann der Prozess SIGTERM ignorieren, wenn er eine Aktion durchführt, die nicht unterbrochen werden darf.

SIGKILL kann von keinem Prozess ignoriert werden. Das Signal lässt sich mit Mich interessiert nicht, was du gerade machst, hör sofort auf damit! umschreiben. Wird einem Prozess SIGKILL geschickt, dann wird FreeBSD diesen sofort beenden[2].

Andere häufig verwendete Signale sind SIGHUP, SIGUSR1 und SIGUSR2. Diese Signale sind für allgemeine Zwecke vorgesehen und verschiedene Anwendungen werden unterschiedlich auf diese Signale reagieren.

Ändern Sie beispielsweise die Konfiguration eines Webservers, so muss dieser angewiesen werden, seine Konfiguration neu zu lesen. Ein Neustart von httpd würde dazu führen, dass der Server für kurze Zeit nicht erreichbar ist. Senden Sie dem Dämon stattdessen das SIGHUP-Signal. Es sei erwähnt, dass verschiedene Dämonen sich anders verhalten. Lesen Sie bitte die Dokumentation des entsprechenden Dämonen um zu überprüfen, ob der Dämon bei einem SIGHUP die gewünschten Ergebnisse erzielt.

Prozedur 4.1. Verschicken von Signalen

Das folgende Beispiel zeigt, wie Sie inetd(8) ein Signal schicken. Die Konfigurationsdatei von inetd ist /etc/inetd.conf. Diese Konfigurationsdatei liest inetd ein, wenn er SIGHUP empfängt.

  1. Suchen Sie mit pgrep(1) die Prozess-ID des Prozesses, dem Sie ein Signal schicken wollen. In diesem Beispiel ist die PID von inetd(8) 198:

    % pgrep -l inetd
    198 inetd -wW
  2. Benutzen Sie kill(1), um ein Signal zu senden. Da inetd(8) dem Benutzer root gehört, müssen Sie zuerst mit su(1) root werden:

    % su
    Password:
    # /bin/kill -s HUP 198

    kill(1) wird, wie andere UNIX® Kommandos auch, keine Ausgabe erzeugen, wenn das Kommando erfolgreich war. Wenn Sie versuchen, einem Prozess, der nicht Ihnen gehört, ein Signal zu senden, dann werden Sie die Meldung kill: PID: Operation not permitted sehen. Ein Tippfehler bei der Eingabe der PID führt dazu, dass das Signal an einen falschen Prozess gesendet wird, was zu negativen Ergebnissen führen kann, oder das Signal wird an eine PID gesendet die derzeit nicht in Gebrauch ist, was zu dem Fehler kill: PID: No such process führt.

    Warum sollte man /bin/kill benutzen?:

    Viele Shells stellen kill als internes Kommando zur Verfügung, das heißt die Shell sendet das Signal direkt, anstatt /bin/kill zu starten. Beachten Sie, dass die unterschiedlichen Shells eine andere Syntax benutzen, um die Namen der Signale anzugeben. Anstatt jede Syntax zu lernen, kann es einfacher sein, /bin/kill ... direkt aufzurufen.

Beim Versenden von anderen Signalen, ersetzen Sie TERM oder KILL in der Kommandozeile mit dem entsprechenden Signal.

Wichtig:

Das zufällige Beenden eines Prozesses kann gravierende Auswirkungen haben. Insbesondere init(8), mit der PID 1, ist ein Spezialfall. /bin/kill -s KILL 1 ist ein schneller, jedoch nicht empfohlener Weg, das System herunterzufahren. Überprüfen Sie die Argumente von kill(1) immer zweimal bevor Sie Return drücken.



[2] Es gibt Fälle, in denen ein Prozess nicht unterbrochen werden kann. Wenn ein Prozess zum Beispiel eine Datei von einem anderen Rechner auf dem Netzwerk liest und dieser Rechner nicht erreichbar ist, dann ist der Prozess nicht zu unterbrechen. Wenn der Prozess den Lesezugriff nach einem Timeout von typischerweise zwei Minuten aufgibt, dann wird er beendet.

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.

Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.