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