Troubleshooting ApacheJeżeli wiadomo, że instalacja Apache jest uszkodzona, ale nie wiadomo w jaki sposób, to szukanie błędów należy rozpocząć od przeglądania plików dziennika (logów). Apache zazwyczaj zakłada kilka takich plików i wszystkie znajdują się wewnątrz katalogu /var/log/apache2/. Niektóre z nich mogą na danym systemie nie istnieć - zależy to od zainstalowanych modułów.
Zawartość tego pliku to lista wszystkich zapytań jakie otrzymał dany serwer. O ile domyślna konfiguracja nie została zmieniona, to będzie on zapisany w ogólnym formacie dziennika.
Jak widać, ten plik może zawierać bardzo wiele wpisów, zależnie od dyrektywy ErrorLevel w httpd.conf. Jest w nim zapisane czy Apache poprawnie wystartował, jakie wystąpiły błędy i tak dalej. W uproszczeniu zapisuje on wszystkie nietypowe sytuacje. Jeżeli coś nie działa to właśnie ten plik powinno się sprawdzić najpierw.
Ten plik zawiera wpis dla każdego wykonania skryptu przy pomocy CGI oraz suexec. Jeżeli jakiś skrypt nie współpracuje z suexec to właśnie ten plik powinno się sprawdzić najpierw, gdyż zazwyczaj będzie on zawierał wiersz z wypisaną przyczyną, dla której odmówiono współpracy. 2. Zainstalowany moduł nie działa! Samo zainstalowanie modułu nie wystarcza - musi on zostać wyraźnie włączony. Jest tak, aby łatwiej było włączać i wyłączać moduły, dzięki czemu łatwiej jest znaleźć te, które sprawiają problemy oraz łatwiej jest je testować oraz wyłączać. Kiedy moduł zostanie zainstalowany, powinien pojawić się komunikat podobny do tego:
Opis ten mówi wprost co należy zrobić, aby uruchomić dany moduł. W razie braku wiadomości jest jeszcze inny sposób sprawdzenia, co należy dodać do APACHE2_OPTS w /etc/conf.d/apache2: sprawdzenie pliku konfiguracyjnego zainstalowanego przez moduł. Powinien on się znajdować w /etc/apache2/modules.d/. Należy w nim odnaleźć wiersz w którym znajduje się IfDefine:
Blok IfDefine jest wykonywany kiedy doda się -D LAYOUT do /etc/conf.d/apache2. LAYOUT jest tylko przykładem. Kilka opcji które można dodać do APACHE2_OPTS jest zdefiniowanych w domyślnej konfiguracji. Ich szczegółowy opis można znaleźć w pliku /etc/conf.d/apache2. Dokumentacja wszystkich wbudowanych modułów znajduje się w dokumentacji Apache 2.0. 3. Apache zwraca tylko puste strony lub zwraca błąd "naruszenie ochrony pamięci" (segfault) Najczęściej dzieje się tak po aktualizacji, gdy złamana została binarna kompatybilnośćw APR (co może zdarzyć się z wielu przyczyn). Aby to naprawić konieczne będzie przebudowanie stosu narzędzi Apache:
Lokaliwozanie uszkodzonego modułu Jeśli po wykonaniu powyższych instrukcji problem nadal występuje, to winowajcą jest prawdopodobnie jeden z zainstalowanych modułów dodatkowych. Najpierw wyłączamy wszystkie moduły i restartujemy Apache.
Jeżeli Apache przestaje segfaultować oraz wysyłać puste strony to można być pewnym, że problemem był jeden z modułów dodatkowych. Aby sprawdzić który z nich, dodajemy je z powrotem, po jednym, za każdym razem całkowicie restartując Apache. Jeżeli Apache przestanie działać po dodaniu konkretnego modułu, to wiadomo, że to właśnie on sprawiał problemy. Czasem zwyczajne przebudowanie modułu rozwiąże kłopoty. Jeżeli po przebudowaniu modułu i zrestartowaniu Apache nadal występują te same problemy, to należy zgłosić błąd wymieniający konkretną wersję i aktualizację modułu oraz wspomnieć o tym, czy segfaultuje. Najpierw należy poszukać już zgłoszonych błędów! 4. Serwer nie przetwarza skryptów PHP lub CGI, zamiast tego wyświetla ich kod W większości przypadków sytuacja, kiedy apache wyświetla kod skryptu zamiast go uruchomić, mimo włączenia odpowiednich modułów w pliku /etc/conf.d/apache2, jest spowodowana problemem ze starym cache po stronie przeglądarki. Często problem pojawia się, gdy łączymy się z serwerem poprzez jego nazwę DNS, a znika, gdy wybierzemy jego numer IP. W takim wypadku niemal na pewno jest to problem z cache. Ten problem można rozwiązać czyszcząc cache przeglądarki. 5. configure: error: changes in the environment can compromise the build Jeśli zdarza się taki błąd, to prawdopodobnie w CFLAGS w /etc/make.conf znajdują się zbędne spacje. Poprawka jest prosta - należy usunąć dodatkowe spacje:
6. Address already in use: make_sock: could not bind to address 0.0.0.0:443 Taki błąd zdarza się podczas startu i jest wywołany przez istnienie w konfiguracji kilku wzajemnie niekompatybilnych dyrektyw Listen. Rozwiązaniem tego problemu powinno być wyszukanie w konfiguracji Listen oraz naprawienie każdego wystąpienia.
Poszukujemy konfliktów między tym, do czego próbuje dowiązać się Apache. Na przykład, jeżeli w httpd.conf znajduje się wpis Listen 80, a w innym pliku można znaleźć Listen 10.0.0.15:80, to serwer nie będzie w stanie wystartować. Dzieje się tak ponieważ Apache najpierw dowiązuje się do portu 80 na wszystkich adresach IP dostępnych na komputerze, a następnie do portu 80 na adresie 10.0.0.15, co nie udaje się, gdyż jest on już wykorzystany. Zalecaną konfiguracją jest umieszczenie pojedynczej dyrektywy Listen 80 (tak jest w domyślnym httpd.conf) tak, aby dowiązać się na wszystkich adresach do standardowego portu HTTP, a następnie dla każdego VirtualHost z SSL stworzyć oddzielną bezwzględną dyrektywę Listen (na przykład Listen 10.0.0.15:443). 7. Po aktualizacji do apache-2.0.54-r13 domyślne vhosty (SSL i nie-SSL) już nie działają W aktualizacji do apache-2.0.54-r13 dodano dwie nowe dyrektywy aby poprawić błąd 100624. Nowe dyrektywy to -D DEFAULT_VHOST dla aktywacji domyślnego vhosta oraz -D SSL_DEFAULT_VHOST dla aktywacji wersji z SSL. Obydwie muszą zostać dodane do APACHE2_OPTS w /etc/conf.d/apache2 jeżeli Apache ma się zachowywać tak, jak dawniej. Jeżeli żadna z powyższych rad nie pomogła w rozwiązaniu problemu lub jeśli występuje potrzeba zadania innych pytań, zawsze można skorzystać z kanału #gentoo-apache na irc.freenode.net. Można też zgłosić błąd na Bugzilli Gentoo. Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike. |
|