Apache HTTP Server Version 2.2
Dieses Dokument umfasst das Beenden und Neustarten des Apache auf Unix-ähnlichen Systemen. Anwender von Windows NT, 2000 und XP sollten Betreiben des Apache als Dienst lesen, während hingegen Anwender von Windows 9x sowie ME Betreiben des Apache als Konsolenanwendung lesen sollten, um mehr Informationen zur Handhabung des Apache auf diesen Systemen zu erhalten.
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.:
kill -TERM `cat /usr/local/apache2/logs/httpd.pid`
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 apachectl
zu senden,
welches diese an httpd
durchreicht.
Nachdem Sie httpd
signalisiert haben, können Sie
dessen Fortschritt beobachten, indem Sie eingeben:
tail -f /usr/local/apache2/logs/error_log
Passen Sie diese Beispiele entsprechend Ihren ServerRoot
- und PidFile
-Einstellungen an.
apachectl -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.
apachectl -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.
-t
überprüfen
(siehe auch httpd
). Das garantiert
allerdings nicht, dass der Server korrekt starten wird. Um sowohl die
Syntax als auch die Semantik der Konfigurationsdateien zu prüfen,
können Sie versuchen, httpd
als nicht-root-Benutzer
zu starten. Wenn dabei keine Fehler auftreten, wird er versuchen, seine
Sockets und Logdateien zu öffnen und fehlschlagen, da er nicht root
ist (oder weil sich der gegenwärtig laufende httpd
bereits diese Ports gebunden hat). Wenn er aus einem anderen Grund
fehlschlägt, dann liegt wahrscheinlich ein Konfigurationsfehler vor.
Der Fehler sollte behoben werden, bevor der unterbrechungsfreie Neustart
angewiesen wird.apachectl -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.
apachectl -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
PidFile
dann schon gelöscht
ist, werden Sie dieses Signal nicht mehr mit apachectl
oder
httpd
senden können.
Das Signal graceful-stop
ermöglicht Ihnen den
Betrieb mehrerer identisch konfigurierter Instanzen von httpd
zur gleichen Zeit. Dies ist eine mächtige Funktionalität bei der
Aufrüstung des Apache. Sie kann jedoch bei einigen Konfigurationen
auch zur gegenseitigen Blockierung und zu Wettlaufsituationen
führen.
Es ist besonders darauf zu achten, dass auf Festplatte gespeicherte
Dateien wie Lockfile
und ScriptSock
die Server-PID enthalten und ohne
Probleme nebeneinander existieren müssen. Wann auch immer eine
Konfigurationsanweisung, ein Drittanbieter-Modul oder ein persistentes
CGI-Skript irgend eine Sperre oder eine Statusdatei auf Festplatte
speichert, muss besonders darauf geachtet werden, dass mehrere
gleichzeitig laufende Instanzen von httpd
sich nicht
gegenseitig die Dateien zerstören.
Sie sollten ebenfalls vorsichtig mit möglichen Wettlaufsituationen
sein, wie beispielsweise der Verwendung von weitergeleiteter
Protokollierung nach der Art von rotatelogs
. Mehrere
gleichzeitig laufende Instanzen von rotatelogs
, die
versuchen, die gleichen Protokolldateien zu rotieren, können sich
gegenseitig die Protokolldateien zerstören.
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.