Der (Neu)Start eines Dienstes

Im weiteren Verlauf dieses Buches werden eine Reihe der wichtigsten Netzwerkdienste vorgestellt.
Zunächst folgt eine Beschreibung des wichtigsten Hintergrundprozesses - des inetd - , dessen Existenz für alle anderen Netzwerkdienste zwingend notwendig ist. Anschließend werden die Grundlagen des Remote Procedure Calls vorgestellt, der die Basis für die wichtigen Dienste Network File System und Network Information System u.a.m. bildet.

Das Einrichten eines jeden Dienstes gleicht einem Zyklus:

Bearbeiten der Konfigurationsdatei(en)

Neustart des betreffenden Dienstes

Test des Dienstes

Arbeitet die gewählte Konfiguration zufrieden stellend, ist man mit der Arbeit fertig. Bemerkt man einen Fehler, beginnt wieder beim 1. Schritt...

Der Windows-Umsteiger denkt bei Schritt 2 womöglich an einen Neustart des Systems, doch unter Unix beschreitet man andere Wege:

Die stets anwendbare Methode:
Die betreffenden Prozesse werden angewiesen, ihre Konfigurationsdateien neu einzulesen:
```
root@sonne> kill -HUP <Prozess-ID>
```
Im weiteren Verlauf des Buches werde ich immer diese Variante anwenden.

Die distributionsabhängige Methode:
Manche Dienste erfordern den Neustart mehrerer Prozesse und eventuell weitere Schritte. D.h. die Komplexität ihrer Administration ist teils enorm... Also verfasste man vielfach Shell-Skripte, die die entsprechenden Schritte automatisieren und damit die Konfiguration vereinfachen.

Wer dem Kapitel zur Systemadministration aufmerksam folgte, dem werden die Differenzen bei den unterschiedlichen Distributionen aufgefallen sein. So wird es auch nicht verwundern, dass nahzu jede Linux-Distribution eigene (und nur auf dieser einsetzbare) Skripte mit sich bringt.

Nicht nur, dass diese Skripte häufig in unterschiedlichen Verzeichnissen liegen (z.B. /usr/sbin/init.d bei SuSE; /etc/rc.d/init.d bei RedHat u.a.), sondern sie haben oftmals unterschiedliche Namen und - im schlimmsten Fall - unterschiedliche Funktionalitäten.

Werfen wir einen Blick auf den typischen Verzeichnisinhalt bei einem SuSE-System:
```
user@sonne> ls /sbin/init.d/
README      dhclient    kbd        pcmcia     rc5.d     single    ypclient
alsasound   dhcp        kerneld    pcnfsd     rc6.d     skeleton  yppasswdd
apache      dhcrelay    kudzu      powerfail  rcS.d     smb       ypserv
at          dummy       lpd        random     reboot    smbfs     ypxfrd
autofs      gpm         named      rc         route     sshd
boot        halt        network    rc0.d      routed    svgatext
boot.d      halt.local  nfs        rc1.d      rpc       syslog
boot.local  identd      nfsserver  rc2.d      rwhod     usb
boot.setup  inetd       nscd       rc3.d      sendmail  vmware
cron        init.d      ntopd      rc4.d      serial    xdm 
```
Anhand des Namens lässt sich vielfach auf den betreffenden Dienst schließen (die Auflistung enthält auch Verzeichnisse).

Und wie verwendet man diese Skripte?

Jedes Skript kann zumindest mit drei verschiedenen Argumenten aufgerufen werden (als Beispiel dient smb - die Samba-Dienste):
- Start eines Dienstes
```
root@sonne> smb start
```
- Anhalten eines Dienstes
```
root@sonne> smb stop
```
Darüber hinaus verstehen einige Skripte weitere Argumente:
- probe testet, ob seit dem letzten Neustart des Dienstes dessen Konfigurationsdatei(en) modifiziert wurde(n)
- reload wie restart
- restart Neustart eines Dienstes
- status zeigt Statusinformationen an (bei Samba z.B. die aktiven Verbindungen)

Auf den Punkt gebracht...: Sobald wir an irgendeiner Konfigurationsdatei irgendetwas ändern, muss der entsprechende Dienst neu gestartet werden. Im einfachsten Fall hilft ein Skript, dass mit der Option restart aufzurufen ist. Existiert kein geeignetes Skript, müssen die betreffenden Prozesse zum Einlesen ihrer Konfigurationsdateien mit Hilfe des Kommandos kill[all] gezwungen werden.