Gentoo Logo

Apache Fehlersuche

Inhalt:

1.  Überprüfen der Logs

Falls irgendwas mit Apache nicht so klappt wie es soll und sie keine Idee haben wo der Fehler liegt, sollten Sie zuerst in die Logs schauen. Dort finden Sie die ersten Hinweise.

Es gibt eine ganze Reihe von Logdateien für Apache. Alle Logdateien sind unter /var/log/apache2/ zu finden. Es sind nicht immer alle der im Folgenden beschriebenen Logdateien auf Ihrem Rechner zu finden, im Einzelnen hängt das davon ab welche Module aktiviert sind.

access_log und ssl_access_log

Befehlsauflistung 1.1: access_log

67.185.0.236 - - [18/Jun/2005:12:05:50 -0700] "GET / HTTP/1.0" 200 721
10.0.1.80 - - [18/Jun/2005:12:11:07 -0700] "GET /~jaspenelle/__journal1.jpg HTTP/1.1" 200 19079
66.239.233.163 - - [18/Jun/2005:12:15:06 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.0" 200 1661
67.185.60.155 - - [18/Jun/2005:12:18:48 -0700] "GET / HTTP/1.0" 200 721
67.185.0.236 - - [18/Jun/2005:12:25:39 -0700] "GET / HTTP/1.0" 200 721
10.0.1.80 - - [18/Jun/2005:12:28:04 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.1" 200 1661
10.0.1.80 - - [18/Jun/2005:12:28:46 -0700] "GET /~jaspenelle/avy7.png HTTP/1.1" 200 13066

Diese Datei ist einfach eine Auflistung jeder Datei die von Ihrem Server angefordert wurde. Sofern die Vorgabekonfiguration nicht geändert wurde, hat diese Datei das 'Common Log Format':

Befehlsauflistung 1.2: Common Log Format Syntax

remotehost rfc931 authuser [date] "request" status bytes
remotehost Name des entfernten Rechners oder seine IP Adresse
rfc931 Der Logname des Anwenders am zugreifenden Rechner
authuser Der Name des Anwenders, als der er sich authentifiziert hat
[date] Datum und Uhrzeit der Anfrage
"request" Die Anfrage selbst, genau so wie sie vom Client gesendet wurde
status Der HTTP-Statuswert der dem Client zurückgegeben wurde
bytes Die Länge des zurückgelieferten Dokumentes in Byte

error_log und ssl_error_log

Befehlsauflistung 1.3: error_log

[Mon Feb 07 23:33:18 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
[Mon Feb 07 23:33:18 2005] [notice] Digest: generating secret for digest authentication ...
[Mon Feb 07 23:33:18 2005] [notice] Digest: done
[Mon Feb 07 23:33:18 2005] [notice] Apache/2.0.52 (Gentoo/Linux) PHP/4.3.10 configured -- resuming normal operations
[Sat Jun 18 13:01:54 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
[Sat Jun 18 13:02:14 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
[Sat Jun 18 13:02:18 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
[Sat Jun 18 13:02:21 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
[Sat Jun 18 13:02:24 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico

Wie Sie sehen kann diese Datei jede Menge Einträge enthalten, abhängig von der Einstellung der ErrorLevel-Anweisung in Ihrer httpd.conf Konfigurationsdatei. Hier sehen Sie ob Apache problemlos starten konnte, welche Fehler auftraten uvm. Generell sehen Sie hier, was nicht funktioniert hat. Immer wenn es Probleme mit Apache gibt sollten Sie als erstes diese Datei für mehr Informationen überprüfen.

suexec_log

Befehlsauflistung 1.4: suexec_log

[2005-02-11 22:33:19]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
[2005-03-11 19:20:13]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
[2005-03-11 19:34:47]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi

Diese Datei enthält eine Logzeile für jeden Aufruf eines CGI-Skriptes, das 'suexec' verwendet. Falls ein CGI-Script (das 'suexec' verwendet) nicht so will wie es soll, ist diese Logdatei der erste Anlaufpunkt wo Sie nachgucken sollten. Hier werden Sie normalerweise einen Logeintrag finden, der angibt warum das Skript nicht gestartet werden konnte.

2.  Ich habe ein Modul installiert, aber das funktioniert nicht!!!

Ein Modul einfach nur zu installieren reicht nicht - Sie müssen es noch explizit aktivieren. Wir machen das, so dass es einfach ist ein einzelnes Modul ein- und auszuschalten. Dadurch lässt sich leichter herausfinden welches Modul ein Problem verursacht.

Wenn Sie ein Modul installieren wird eine Nachricht ähnlich wie diese angezeigt:

Befehlsauflistung 2.1: Nachricht von emerge nach der Installation

 *
 * To enable mod_layout, you need to edit your /etc/conf.d/apache2 file and
 * add '-D LAYOUT' to APACHE2_OPTS.
 *
 *
 * Configuration file installed as
 *     /etc/apache2/modules.d/15_mod_layout.conf
 * You may want to edit it before turning the module on in /etc/conf.d/apache2
 *

Das sollte ziemlich klar sein. Die Nachricht sagt Ihnen was Sie tun müssen, um dieses Modul zu aktivieren.

Falls Sie diese Nachricht übersehen haben, gibt es einen anderen Weg herauszufinden, was man zu APACHE2_OPTS in der Datei /etc/conf.d/apache2 hinzufügen muss: Gucken Sie sich einfach die Konfigurationsdatei an, die zusammen mit dem Modul installiert wurde. Diese Konfigurationsdatei sollte immer in /etc/apache2/modules.d/ installiert werden. Öffnen Sie die entsprechende Datei und suchen Sie nach einer Zeile mit IfDefine:

Befehlsauflistung 2.2: Ein Auszug aus 15_mod_layout.conf

<IfDefine LAYOUT>
  <IfModule !mod_layout.c>
    LoadModule layout_module    modules/mod_layout.so
  </IfModule>
</IfDefine>

Der IfDefine-Block wird ausgeführt wenn Sie -D LAYOUT in der Datei /etc/conf.d/apache2 hinzufügen. Das Schlüsselwort LAYOUT ist nur ein Beispiel.

Es gibt eine ganze Reihe von Optionen, die bei APACHE2_OPTS eingetragen werden können. Sie sind in der Vorgabekonfiguration angegeben und gut in /etc/conf.d/apache2 erklärt.

Dokumentation zu allen eingebauten Modulen findet man in der Apache 2.0 Dokumentation (Englisch) bzw. in .Apache 2.0 Dokumentation (Deutsch).

3.  Apache liefert Seiten mit Null Byte Länge oder verursacht einen Speicherzugriffsfehler

Das kann nach einem Upgrade vorkommen, da die Binärkompatibilität zu APR (Apache Portable Runtime) nicht mehr gegeben ist (und das kann wiederrum eine ganze Reihe von Gründen haben). Um das zu beheben sollten Sie die ganzen zu Apache gehörenden Werkzeuge (APR) neu aufbauen:

Befehlsauflistung 3.1: Neuaufbau der Apache Werkzeuge

(Führen sie das genau in dieser Reihenfolge aus, das ist sehr wichtig!)

(Zunächst müssen wir den derzeit installierten Apache entfernen)
# emerge -aCv '=www-servers/apache-2*'

(Dann bauen wir die Apache Werkzeuge neu auf)
# emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'

(Und schließlich wird Apache neu installiert)
# emerge -av '=www-servers/apache-2*'

(Feststellen, welche Pakete von Apache abhängen)
$ equery depends www-servers/apache
[ Searching for packages depending on www-servers/apache... ]
dev-php/phpsysinfo-2.3-r2
dev-php/phpsysinfo-2.1-r2
dev-lang/php-5.2.4_p20070914-r2
net-www/mod_layout-4.0.1a-r1
www-servers/gorg-0.5

(Abschliessend werden diese abhängigen Module neu aufgebaut)
# emerge -av '=dev-lang/php-5.2.4_p20070914-r2' '=net-www/mod_layout-4.0.1.a-r1'

Ein fehlerhaftes Add-On Modul identifizieren

Falls Sie, obwohl Sie den Anweisungen oben gefolgt sind, immer noch Probleme haben sollten, dann ist die Ursache meist bei einem der installierte Mdule zu suchen.

Beginnen Sie, indem Sie alle zusätzlichen Module deaktivieren und Apache neu starten.

Befehlsauflistung 3.2: Zusatzmodule deaktivieren

(editieren von /etc/conf.d/apache2)

(Vor der Änderung)
APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"

(Nach der Änderung)
APACHE2_OPTS=""

Befehlsauflistung 3.3: Apache neu starten

# /etc/init.d/apache2 stop
(Stellen Sie sicher, dass Apache vollständig beendet wurde)
# ps -A
# /etc/init.d/apache2 start

Notiz: Sie müssen gegebenenfalls kleine Änderungen an der Konfiguration vornehmen, falls Sie Directives an solchen Stellen verwenden, an denen nicht getestet wird ob das Modul geladen ist. Es wird empfohlen solche Directives in eine Testumgebung einzubetten. Beispiele von .conf-Dateien dazu gibt es in /etc/apache2/modules.d.

Wenn Apache nach dem Neustart nun keine Speicherzugriffsfehler oder leere Seiten produziert wissen Sie mit Sicherheit, dass es an einem der Zusatzmodule lag. Um herauszufinden, welches davon die Ursache ist, werden wir eins nach dem anderen wieder aktivieren. Dazu muss Apache jedesmal komplett neu gestartet werden.

Falls Apache nach der Aktivierung eines Moduls wieder Probleme macht, dann wissen Sie, dass dieses zuletzt aktivierte Modul die Probleme verursacht. Manchmal reicht es aus dieses Modul einfach neu zu bauen.

Falls nach einer Neuinstallation des Moduls immer noch Probleme wie Speicherzugriffsfehler oder leere Seiten auftreten, dann sollten Sie einen Fehlerbericht einreichen und zwar unter Angabe der Versions- und Revisionsnummer des betroffenen Moduls. Schauen Sie aber bitte vorher nach, ob zu diesem Fehler nicht bereits ein Bericht eingereicht wurde.

4.  Der Webserver führt PHP- oder CGI-Scripte nicht aus, sondern liefert den Quellcode der Scripte zurück

Manachmal scheint es so auszusehen, als ob Apache den PHP- oder CGI-Quellcode ausliefert anstatt dieses Script auszuführen. Wenn das vorkommt obwohl das Modul in /etc/conf.d/apache2 aktiviert ist, dann liegt das ziemlich wahrscheinlich am Zwischenspeicher (Cache) des Browsers. Ein Löschen des Caches sollte dieses Problem beheben.

Manchmal tritt dieses Problem dann auf, wenn man den Webserver über den DNS-Namen anspricht, nicht aber wenn man die IP-Adresse verwendet. Das weist sehr stark darauf hin, dass es sich hier um ein Cacheproblem handelt.

Dieses Problem kann behoben werden, indem man den Browsercache löscht, genauso den der dazwischenliegenden Proxies wie squid oder wwwoffle.

5.  configure: error: changes in the environment can compromise the build

Falls Sie diesen Fehler erhalten, haben Sie wahrscheinlich unnötige Leerzeichen in Ihren CFLAGS in der Datei /etc/make.conf. Die Lösung ist einfach; löschen Sie die überflüssigen Leerzeichen:

Befehlsauflistung 5.1: Beispiel von Änderungen an /etc/make.conf

(Vor der Änderung)
CFLAGS="-O2 -mcpu=pentium3 -march=pentium3  -pipe"

(Nach der Änderung - beachten Sie die verschwundenen Leerzeichen)

CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"

6.  Address already in use: make_sock: could not bind to address 0.0.0.0:443

Dieser Fehler tritt während des Starts auf und wird durch mehrere, zueinander inkompatible Listen Direktiven in der Konfiguration verursacht. Um das Problem zu beheben, suchen Sie mit 'grep' nach allen Listen Einträgen in der Konfiguration und korrigieren Sie jedes Auftreten.

Befehlsauflistung 6.1: Auffinden aller Listen Anweisungen

(Wechseln Sie zunächst in das Konfigurationsverzeichnis)
# cd /etc/apache2/

(Lassen Sie sich alle Listen Anweisungen anzeigen)
# grep Listen httpd.conf vhosts.d/*.conf modules.d/*.conf

Das, wonach Sie suchen müssen, sind zueinander inkompatible Apache-Anweisungen, sich an Ports zu binden. Falls es zum Beispiel eine Anweisung Listen 80 in httpd.conf gibt, und in einer anderen Datei eine Anweisung Listen 10.0.0.15:80 dann kann Apache nicht starten. Das liegt daran, dass sich Apache zunächst an Port 80 auf allen vorhandenen IP-Adressen bindet und später versucht nochmal Port 80 auf IP-Adresse 10.0.015 zu binden. Das schlägt fehl, weil der Port 80 bereits von der früheren Anweisung belegt wurde.

Die empfohlene Konfiguration ist, nur eine Listen 80 Anweisung zu verwenden (das ist die Vorgabe in httpd.conf). Dies ist die Vorgabe für den Standard-HTTP Port bei allen IP-Adressen. Erstellen Sie dann für jeden SSL Virtual Host eine eigene, absolute Listen Anweisung (wie z.B. Listen 10.0.0.15:443.

7.  Nach einem Upgrade auf apache-2.0.54-r13 arbeiten die Standard vhosts (sowohl SSL also auch nicht-SSL) nicht mehr

Mit dem Upgrade auf apache-2.0.54-r13 wurden zwei neue Direktiven eingeführt um den Fehler 100624 zu beheben.

Die neuen Anweisungen sind -D DEFAULT_VHOST um den standardmässig installierten Virtual Host zu aktivieren, sowie -D SSL_DEFAULT_VHOST für den standardmässig installierten SSL Virtual Host. Diese beiden Direktiven müssen zu der APACHE2_OPTS Variablen in der Datei /etc/conf.d/apache2 hinzugefügt werden, damit sich Apache verhält wie vor dem Upgrade.

8.  Weitere Hilfe

Falls Ihnen keiner der oben genannten Punkte geholfen hat oder falls Sie andere Fragen haben, sprechen Sie uns doch mal im IRC an. Wir sind meistens im Kanal #gentoo-apache auf dem Server irc.freenode.net zu finden. Oder Sie erstellen einen neuen Fehlerbericht auf Gentoos Bugzilla.



Drucken

Seite aktualisiert 29. November 2007

Zusammenfassung: Dieses Dokument beschreibt eine Reihe von Methoden, um Fehler der Apache- Installation zu beheben, falls mal etwas nicht richtig funktioniert.

Michael Stewart
Autor

Elfyn McBratney
Mitarbeiter

Bryan Østergaard
Mitarbeiter

Benedikt Böhm
Mitarbeiter

Ekki Plicht
Übersetzer

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.