4.8. Dämonen, Signale und Stoppen von Prozessen
Zurück | Kapitel 4. Grundlagen des UNIX Betriebssystems | Weiter

## 4.8. Dämonen, Signale und Stoppen von Prozessen

Wenn Sie einen Editor starten, können Sie ihn leicht bedienen und Dateien laden. Sie können das, 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 Web-Server zum Beispiel verbringt den ganzen Tag damit, auf Anfragen zu antworten und erwartet keine Eingaben von Ihnen. Programme, die E-Mail von einem Ort zu einem anderen Ort transportieren sind ein weiteres Beispiel für diesen Typ von Anwendungen.

Wir nennen diese Programme Dämonen. Dämonen stammen aus der griechischen Mythologie und waren weder gut noch böse. Sie waren kleine dienstbare Geister, die meistens nützliche Sachen für die Menschheit vollbrachten. Ähnlich wie heutzutage Web-Server und Mail-Server nützliche Dienste verrichten. Seit langer Zeit ist daher 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, der Druckerspool-Dämon heißt `lpd` usw. Dies ist allerdings eine Konvention und keine unumstößliche Regel: Der Dämon der Anwendung sendmail heißt `sendmail` und nicht `maild`, wie Sie vielleicht gedacht hatten.

Manchmal müssen Sie mit einem Dämon kommunizieren. Dazu verwenden Sie Signale. Sie können mit einem Dämonen oder jedem anderen laufenden Prozess kommunizieren, indem Sie diesem ein Signal schicken. Sie können verschiedene Signale verschicken – manche haben eine festgelegte Bedeutung, andere werden von der Anwendung interpretiert. Die Dokumentation zur fraglichen Anwendung wird erklären, wie die Anwendung Signale interpretiert. Sie können nur Signale zu Prozessen senden, die Ihnen gehören. Normale Benutzer haben nicht die Berechtigung, Prozessen anderer Benutzer mit kill(1) oder kill(2) Signale zu schicken. Der Benutzer `root` darf jedem Prozess Signale schicken.

In manchen Fällen wird FreeBSD Signale 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 Prozesse zu stoppen: `SIGTERM` und `SIGKILL`. Mit `SIGTERM` fordern Sie den Prozess höflich zum Beenden auf. Der Prozess kann das Signal abfangen und merken, dass er sich beenden soll. Er hat dann Gelegenheit Logdateien zu schließen und die Aktion, die er vor der Aufforderung sich zu beenden durchführte, abzuschließen. Er kann sogar `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. Wenn Sie einem Prozess `SIGKILL` schicken, dann wird FreeBSD diesen sofort beenden[4].

Andere Signale, die Sie vielleicht verschicken wollen, sind `SIGHUP`, `SIGUSR1` und `SIGUSR2`. Diese Signale sind für allgemeine Zwecke vorgesehen und verschiedene Anwendungen werden unterschiedlich auf diese Signale reagieren.

Nehmen wir an, Sie haben die Konfiguration Ihres Webservers verändert und möchten dies dem Server mitteilen. Sie könnten den Server natürlich stoppen und `httpd` wieder starten. Die Folge wäre eine kurze Zeit, in der der Server nicht erreichbar ist. Die meisten Dämonen lesen Ihre Konfigurationsdatei beim Empfang eines `SIGHUP` neu ein. Da es keinen Standard gibt, der vorschreibt, wie auf diese Signale zu reagieren ist, lesen Sie bitte die Dokumentation zu dem in Frage kommenden Dämon.

Mit kill(1) können Sie, wie unten gezeigt, Signale verschicken.

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 ein `SIGHUP` empfängt.

1. Suchen Sie die Prozess-ID des Prozesses, dem Sie ein Signal schicken wollen. Benutzen Sie dazu ps(1) und grep(1). Mit grep(1) können Sie in einer Ausgabe nach einem String suchen. Da inetd(8) unter dem Benutzer `root` läuft und Sie das Kommando als normaler Benutzer absetzen, müssen Sie ps(1) mit `ax` aufrufen:

   `%` `ps -ax | grep inetd` 198 ?? IWs 0:00.00 inetd -wW

   Die Prozess-ID von inetd(8) ist 198. In einigen Fällen werden Sie auch das `grep inetd` Kommando in der Ausgabe sehen. Dies hat damit zu tun, wie ps(1) die Liste der laufenden Prozesse untersucht.

2. Senden Sie das Signal mit kill(1). Da inetd(8) unter dem Benutzer `root` läuft, müssen Sie zuerst mit su(1) `root` werden:

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

   kill(1) wird, wie andere Kommandos von UNIX® Systemen 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. Wenn Sie sich bei der Eingabe der PID vertippen, werden Sie das Signal dem falschen Prozess schicken, was schlecht sein kann. Wenn Sie Glück haben, existiert der Prozess nicht und Sie werden mit der Ausgabe kill: `PID`: No such process belohnt.

   ### Warum soll ich `/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. Das kann nützlich sein, aber die unterschiedlichen Shells benutzen eine verschiedene Syntax, um die Namen der Signale anzugeben. Anstatt jede Syntax zu lernen, kann es einfacher sein, `/bin/kill `...`` direkt aufzurufen.

Andere Signale senden Sie auf die gleiche Weise, ersetzen Sie nur `TERM` oder `KILL` entsprechend.

### Wichtig:

Es kann gravierende Auswirkungen haben, wenn Sie zufällig Prozesse beenden. Insbesondere init(8) mit der Prozess-ID ist ein Spezialfall. Mit `/bin/kill -s KILL 1` können Sie Ihr System schnell herunterfahren. Überprüfen Sie die Argumente von kill(1) immer zweimal bevor Sie Return drücken.

[4] Das stimmt nicht ganz: Es gibt Fälle, in denen ein Prozess nicht unterbrochen werden kann. Wenn der Prozesss zum Beispiel eine Datei von einem anderen Rechner auf dem Netzwerk liest und dieser Rechner aus irgendwelchen Gründen nicht erreichbar ist (ausgeschaltet, oder ein Netzwerkfehler), dann ist der Prozess nicht zu unterbrechen. Wenn der Prozess den Lesezugriff nach einem Timeout von typischerweise zwei Minuten aufgibt, dann wir er beendet.

Zurück | Nach oben | Weiter
4.7. Prozesse | Zum Anfang | 4.9. Shells

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>.