# 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:

1. Bearbeiten der Konfigurationsdatei(en)
2. Neustart des betreffenden Dienstes
3. 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.