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[1].
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.
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.
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.
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.
| [1] |
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 | Zum Anfang | Weiter |
| Prozesse | Nach oben | 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>.