Beenden und Neustarten

Einleitung

Um den Apache zu stoppen oder neu zu starten, m�ssen Sie ein Signal an den laufenden httpd-Prozess senden. Es gibt zwei M�glichkeiten, diese Signale zu senden. Zum einen k�nnen Sie den Unix-Befehl kill verwenden, um den Prozessen direkt Signale zu senden. Sie werden feststellen, dass auf Ihrem System mehrere httpd-Programme laufen. Sie sollten jedoch nicht jedem dieser Prozesse ein Signal senden, sondern nur dem Elternprozess, dessen PID im PidFile steht. Das hei�t, Sie sollten es niemals n�tig haben, einem anderen Prozess, als dem Elternprozess, ein Signal zu senden. Es gibt drei Signale, die Sie an den Elternprozess senden k�nnen: TERM, HUP und USR1, die nachfolgend beschrieben werden.

Um dem Elternprozess ein Signal zu senden, verwenden Sie einen Befehl wie z.B.:

Die zweite Methode, dem httpd-Prozess zu signalisieren, ist die Verwendung der -k-Befehlszeilenoptionen stop, restart, graceful und graceful-stop, wie unten beschrieben. Dies sind Argumente des httpd-Programms, es wird jedoch empfohlen, sie unter Verwendung des Steuerskripts apache2ctl zu senden, welches diese an httpd durchreicht.

Nachdem Sie httpd signalisiert haben, k�nnen Sie dessen Fortschritt beobachten, indem Sie eingeben:

Passen Sie diese Beispiele entsprechend Ihren ServerRoot- und PidFile-Einstellungen an.

Beenden

Signal: TERM

apache2ctl -k stop

Das Senden des TERM- oder stop-Signals an den Elternprozess veranlasst diesen, sofort zu versuchen, alle seine Kindprozesse zu beenden. Es kann einige Sekunden dauern, bis alle Kindprozesse komplett beendet sind. Danach beendet sich der Elternprozess selbst. Alle gerade bearbeiteten Anfragen werden abgebrochen. Es werden keine weiteren Anfragen mehr bedient.

Unterbrechungsfreier Neustart

Signal: USR1

apache2ctl -k graceful

Das USR1- oder graceful-Signal veranlasst den Elternprozess, die Kinder anzuweisen, sich nach Abschlu� ihrer momentanen bearbeiteten Anfrage zu beenden (oder sich sofort zu beenden, wenn sie gerade keine Anfrage bedienen). Der Elternprozess liest seine Konfigurationsdateien erneut ein und �ffnet seine Logdateien neu. Wenn ein Kindprozess stirbt, ersetzt der Elternprozess ihn durch ein Kind der neuen Konfigurations-Generation. Dieses beginnt sofort damit, neue Anfragen zu bedienen.

Der Code ist daf�r ausgelegt, stets die MPM-Direktiven zur Prozesssteuerung zu beachten, so dass die Anzahl der Prozesse und Threads, die zur Bedienung der Clients bereitstehen, w�hrend des Neustarts auf die entsprechenden Werte gesetzt werden. Weiterhin wird StartServers auf folgende Art und Weise interpretiert: Wenn nach einer Sekunde nicht mindestens StartServers neue Kindprozesse erstellt wurden, dann werden, um den Durchsatz zu beschleunigen, entsprechend weitere erstellt. Auf diese Weise versucht der Code sowohl die Anzahl der Kinder entsprechend der Serverlast anzupassen als auch Ihre W�nsche hinsichtlich des Parameters StartServers zu ber�cksichtigen.

Benutzer von mod_status werden feststellen, dass die Serverstatistiken nicht auf Null zur�ckgesetzt werden, wenn ein USR1 gesendet wurde. Der Code wurde so geschrieben, dass sowohl die Zeit minimiert wird, in der der Server nicht in der Lage ist, neue Anfragen zu bedienen (diese werden vom Betriebssystem in eine Warteschlange gestellt, so dass sie auf keinen Fall verloren gehen) als auch Ihre Parameter zur Feinabstimmung ber�cksichtigt werden. Um dies zu erreichen, muss die Statustabelle (Scoreboard), die dazu verwendet wird, alle Kinder �ber mehrere Generationen zu verfolgen, erhalten bleiben.

Das Statusmodul benutzt au�erdem ein G, um diejenigen Kinder zu kennzeichen, die noch immer Anfragen bedienen, welche gestartet wurden, bevor ein unterbrechungsfreier Neustart veranla�t wurde.

Derzeit gibt es keine M�glichkeit f�r ein Log-Rotationsskript, das USR1 verwendet, sicher festzustellen, dass alle Kinder, die in ein vor dem Neustart ge�ffnetes Log schreiben, beendet sind. Wir schlagen vor, dass Sie nach dem Senden des Signals USR1 eine angemessene Zeitspanne warten, bevor Sie das alte Log anfassen. Wenn beispielsweise die meisten Ihrer Zugriffe bei Benutzern mit niedriger Bandbreite weniger als 10 Minuten f�r eine vollst�ndige Antwort ben�tigen, dann k�nnten Sie 15 Minuten warten, bevor Sie auf das alte Log zugreifen.

Neustarten

Signal: HUP

apache2ctl -k restart

Das Senden des Signals HUP oder restart veranla�t den Elternprozess, wie bei TERM alle seine Kinder zu beenden. Der Elternprozess beendet sich jedoch nicht. Er liest seine Konfigurationsdateien neu ein und �ffnet alle Logdateien erneut. Dann erzeugt er einen neuen Satz Kindprozesse und setzt die Bedienung von Zugriffen fort.

Benutzer von mod_status werden feststellen, dass die Serverstatistiken auf Null gesetzt werden, wenn ein HUP gesendet wurde.

R�cksichtsvolles Beenden

Signal: WINCH

apache2ctl -k gracefull stop

Das WINCH- oder graceful-stop-Signal veranlasst den Elternprozess, die Kinder anzuweisen, sich nach Abschlu� ihrer momentan bearbeiteten Anfrage zu beenden (oder sich sofort zu beenden, wenn sie gerade nichts bedienen). Der Elternprozess entfernt dann sein PidFile und stellt das Lauschen auf allen Ports ein. Er l�uft weiter und beobachtet alle Kindprozesse, die noch Anfragen bearbeiten. Sobald alle Kindprozesse fertig sind und beendet haben oder die mit GracefulShutdownTimeout definierte Zeit�berschreitung erreicht wurde, beendet sich der Elternprozess ebenfalls. Jedem verbliebenen Kindprozess wird beim Erreichen der Zeit�berschreitung das TERM-Signal gesendet, um diesen zum Beenden zu zwingen.

Ein TERM-Signal beendet den Elternprozess und alle Kindprozesse unverz�glich, wenn sie sich im "graceful"-Status (Anm.d.�.: w�rtl. "gn�diger" Status) befinden. Da jedoch das PidFiledann schon gel�scht ist, werden Sie dieses Signal nicht mehr mit apache2ctl oder httpd senden k�nnen.

Anhang: Signale und Wettlaufsituationen

Vor der Version 1.2b9 des Apache existierten verschiedene Wettlaufsituationen (Anm.d.�.: engl.: race conditions), die den Neustart und die Signale beeinflu�t haben (einfach gesagt, eine Wettlaufstituation ist ein zeitabh�ngiges Problem - wenn etwas zum falschen Zeitpunkt oder in der falschen Reihenfolge geschieht, kommt es zu nicht erw�nschten Ergebnissen. Geschehen die gleichen Dinge zur rechten Zeit, ist alles in Ordnung). Bei Architekturen mit dem "richtigen" (Anm.d.�.: im Sinne von "geeignet") Funktionsumfang haben wir so viele eliminiert wie wir nur konnten. Dennoch sollte beachtet werden, dass noch immer Wettlaufsituationen auf bestimmten Architekturen existieren.

Bei Architekturen, die ein ScoreBoardFile auf Platte verwenden, kann die Statustabelle besch�digt werden. Das kann zu "bind: Address already in use" ("bind: Adresse wird bereits verwendet", nach einem HUP) oder "long lost child came home!" ("Der verlorene Sohn ist heimgekehrt", nach einem USR1) f�hren. Ersteres ist ein schwerer Fehler, w�rend letzteres lediglich bewirkt, dass der Server einen Eintrag in der Statustabelle verliert. So kann es ratsam sein, unterbrechungsfreie Neustarts zusammen mit einem gelegentlichen harten Neustart zu verwenden. Diese Probleme lassen sich nur sehr schwer umgehen, aber gl�cklicherweise ben�tigen die meisten Architekturen keine Statustabelle in Form einer Datei. Bitte lesen Sie f�r Architekturen, die sie ben�tigen, die Dokumentation zu ScoreBoardFile.

Alle Architekturen haben in jedem Kindprozess eine kleine Wettlaufsituation, welche die zweite und nachfolgende Anfragen einer persistenten HTTP-Verbindung (KeepAlive) umfa�t. Der Prozess kann nach dem Lesen der Anfragezeile aber vor dem Lesen der Anfrage-Header enden. Es existiert eine Korrektur, die f�r 1.2 zu sp�t kam. Theoretisch sollte das kein Problem darstellen, da der KeepAlive-Client derartige Ereignisse aufgrund von Netzwerk-Latenzzeiten und Auszeiten des Servers erwarten sollte. In der Praxis scheint keiner von beiden beeinflu�t zu werden -- in einem Testfall wurde der Server zwanzig mal pro Sekunde neu gestartet, w�hrend Clients das Angebot abgegrast haben, ohne kaputte Bilder oder leere Dokumente zu erhalten.