Apache Fehlersuche
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 |
# emerge -aCv '=www-servers/apache-2*'
# emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'
# emerge -av '=www-servers/apache-2*'
$ 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
# 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 |
APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"
APACHE2_OPTS=""
|
Befehlsauflistung 3.3: Apache neu starten |
# /etc/init.d/apache2 stop
# 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 |
CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"
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 |
# cd /etc/apache2/
# 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.
Die Inhalte dieses Dokuments sind unter der Creative Commons -
Namensnennung / Weitergabe Lizenz lizenziert.
|