Gentoo Logo

Risoluzione dei problemi in Apache

Indice:

1.  Controllare i log

Se Apache non funziona in modo corretto, ma non si ha idea di come individuare la causa del problema, il primo indizio potrebbe trovarsi nei file di log.

Nel sistema si troverà un certo numero di log, tutti collocati in /var/log/apache2/. E' probabile che non si riscontreranno nel proprio sistema tutti i file di log elencati di seguito: la loro presenza dipende dai moduli che sono stati abilitati.

access_log e ssl_access_log

Codice 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

Questo file è un semplice elenco di tutti i file richiesti al server. A meno che non sia stata variata la configurazione predefinita, esso sarà nel formato CLF (Common Log Format):

Codice 1.2: Sintassi Common Log Format

remotehost rfc931 authuser [date] "request" status bytes
remotehost Nome host remoto o indirizzo IP.
rfc931 Il nome di login remoto dell'utente.
authuser Il nome utente con il quale l'utente si è autenticato.
[date] Data e ora della richiesta..
"request" La riga di richiesta esattamente come è arrivata dal client.
status Il codice di stato HTTP rispedito al client.
bytes La lunghezza del contenuto del documento trasferito.

error_log e ssl_error_log

Codice 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

Come si può vedere, questo file contiene molte informazioni, la cui quantità dipende dalla direttiva ErrorLevel contenuta nel file httpd.conf. Questo log dice se apache si è avviato correttamente, in quali errori è incorso, ... Generalmente viene elencata ogni situazione di errore. Se qualcosa non funziona correttamente, dovrebbe essere il primo file da controllare per ulteriori informazioni.

suexec_log

Codice 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

In questo file viene inserita una voce di log ogni qualvolta uno script viene eseguito tramite CGI o suexec. Se non si riesce a far funzionare degli script tramite suexec, questo è il log da controllare poiché le righe ivi contenute il più delle volte elencheranno i motivi della loro mancata esecuzione.

2.  Ho installato un modulo, ma non funziona!!!

La sola installazione del modulo non basta, bisogna attivarlo esplicitamente. Si usa questa modalità per rendere più facile l'attivazione e la disattivazione dei singoli moduli, a sua volta si semplifica l'individuazione di quelli che creano problemi, permettendo di testarli e disabilitarli facilmente.

Quando si installa un modulo, dovrebbe venire visualizzato un messaggio simile a questo:

Codice 2.1: Messaggio post-installazione da emerge

 *
 * 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
 *

Il messaggio è piuttosto chiaro. Dice esattamente cosa fare per abilitare questo modulo.

Se questo messaggio è andato perso, c'è un altro modo per scoprire cosa aggiungere a APACHE2_OPTS in /etc/conf.d/apache2: bisogna semplicemente controllare il file di configurazione installato dal modulo. Il file di configurazione del modulo dovrebbe trovarsi in /etc/apache2/modules.d/. Aprirlo e cercare una linea contenente la voce IfDefine:

Codice 2.2: Un estratto da 15_mod_layout.conf

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

Il blocco IfDefine viene eseguito dopo aver aggiunto -D LAYOUT a /etc/conf.d/apache2. LAYOUT è solamente un esempio.

Ci sono diverse opzioni, specificate nella configurazione predefinita e spiegate in modo dettagliato in /etc/conf.d/apache2, che si possono aggiungere ad APACHE2_OPTS.

È possibile trovate tutta la documentazione per i moduli incorporati nella Documentazione di Apache 2.0.

3.  Apache restituisce pagine di lunghezza nulla o va in segfault

Questo succede il più delle volte dopo un aggiornamento che guasta la compatibilità binaria nel pacchetto APR (e ciò può avvenire per vari motivi). Per correggere il problema, si deve ricompilare il tool stack di Apache:

Codice 3.1: Ricompilare il tool stack

(assicurarsi di eseguire le operazioni in quest'ordine, è molto importante!)

(per prima cosa, si deve rimuovere la versione correntemente installata di apache)
# emerge -aCv '=www-servers/apache-2*'

(poi bisogna ricompilare il tool stack)
# emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'

(Quindi si reinstalla apache)
# emerge -av '=www-servers/apache-2*'

(si controllano i pacchetti dipendenti da apache)
$ 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

(infine si ricompilano gli eventuali moduli installati)
# emerge -av '=dev-lang/php-5.2.4_p20070914-r2'
'=net-www/mod_layout-4.0.1.a-r1'

Determinare se un modulo aggiuntivo è bacato

Se si continua ad avere problemi anche dopo aver seguito le istruzioni precedenti, il colpevole è molto probabilmente uno dei moduli aggiuntivi installati.

Come prima cosa disabilitare tutti i moduli aggiuntivi, quindi riavviare Apache.

Codice 3.2: Disabilitare i moduli aggiuntivi

(modificare /etc/conf.d/apache2)

(prima della modifica)
APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"

(dopo la modifica)
APACHE2_OPTS=""

Codice 3.3: Riavviare Apache

# /etc/init.d/apache2 stop
(assicurarsi che apache sia completamente arrestato)
# ps -A
# /etc/init.d/apache2 start

Nota: Potrebbe essere necessario apportare delle piccole modifiche in qualche parte della propria configurazione se sono state aggiunte Directive fornite da questi moduli in posizioni che non si accertano se i moduli sono caricati. E' raccomandabile che le Directive come queste vengano posizionate in contenitori di test. Guardare uno qualsiasi dei file .conf in /etc/apache2/modules.d come esempio.

Se Apache smette di andare in segfault e restituire pagine vuote, allora si avrà la certezza che la causa è uno dei moduli aggiuntivi. Per scoprire quale, basta attivarne uno alla volta, riavviando completamente apache ogni volta.

Quando Apache smetterà di funzionare dopo aver aggiunto un modulo, si saprà che quel modulo è quello che crea problemi. Di solito, la sua ricompilazione risolverà il problema.

Se dopo la ricompilazione del modulo e il riavvio di apache, esso va in segfault o restituisce pagine vuote, è consigliabile aprire un bug report elencando la versione specifica e la revisione del modulo, menzionando che va in segfault. Assicurarsi prima, però, di cercare bug già aperti a riguardo!

4.  Il server Web non interpreta gli script PHP o CGI, restituendo invece il loro codice

Certe volte Apache sembra restituire il codice degli script PHP o CGI, invece di eseguirli e restituire il loro output. Se ciò succede anche con il modulo abilitato in /etc/conf.d/apache2 il problema può essere dovuto alla cache del browser, che andrà svuotata per risolvere questo inconveniente.

Questo problema qualche volta può anche essere notato solo quando si accede al server web usando il suo nome DNS ma non accedendoci usando il suo indirizzo IP. È un chiaro segnale che il problema è relativo alla cache.

Il problema può essere corretto pulendo la cache del browser web e di ogni eventuale proxy web, come squid o wwwoffle.

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

Se si ottiene questo errore, probabilmente è stato inserito qualche spazio di troppo nella variabile CFLAGS in /etc/make.conf. La correzione è semplice, basta rimuovere gli spazi in più:

Codice 5.1: Esempio di modifica a /etc/make.conf

(prima della modifica)
CFLAGS="-O2 -mcpu=pentium3 -march=pentium3  -pipe"

(dopo la modifica. notare la rimozione dello spazio)
CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"

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

Questo errore si presenta durante la fase di avvio ed è causata dalla presenza di direttive Listen multiple nella propria configurazione incompatibili tra di loro. Per risolvere questo problema, bisogna individuare, nel file di configurazione, le occorrenze di Listen e correggerle una ad una.

Codice 6.1: Trovare tutte le direttive Listen

(Assicurarsi di essere nella directory di configurazione)
# cd /etc/apache2/

(Elencare tutte le direttive)
# grep Listen httpd.conf vhosts.d/*.conf modules.d/*.conf

Bisogna individuare quali di queste creano dei conflitti all'interno di Apache. Per esempio, se c'è un Listen 80 in httpd.conf e c'è un Listen 10.0.0.15:80 in un altro file, Apache non riuscirà ad avviarsi. Questo perché Apache prima si associa alla porta 80 su tutti gli indirizzi IP della macchina, poi tenta di associarsi alla porta 80 dell'indirizzo IP 10.0.0.15 e fallisce, poiché la porta è già in uso.

Nella configurazione raccomandata deve esserci un singola direttiva Listen 80 (e si trova in modo predefinito in httpd.conf, così da legare apache alla porta standard HTTP su tutti gli indirizzi, poi per ogni VirtualHost SSL si avvierò una direttiva Listen assoluta separata (per esempio Listen 10.0.0.15:443).

7.  dopo l'aggiornamento ad apache-2.0.54-r13 il vhost predefinito (SSL and non-SSL) non funziona più

Con l'aggiornamento ad apache-2.0.54-r13, gli sono state aggiunte due nuove direttive per correggere il bug 100624.

Le nuove direttive sono -D DEFAULT_VHOST per attivare l'host virtuale predefinito e -D SSL_DEFAULT_VHOST per attivare l'host virtuale SSL. Entrambe devono essere aggiunte alla variabile APACHE2_OPTS in /etc/conf.d/apache2 per permettere ad Apache di funzionare come prima.

8.  Ottenere un aiuto

Se nessuno dei precedenti consigli è servito, o se si hanno altre domande da porre, entrare nel canale IRC degli sviluppatori Apache di Gentoo, #gentoo-apache su irc.freenode.net. Oppure aprire un bug report sul Bugzilla di Gentoo.



Stampa

Aggiornato il 29 novembre 2007

Oggetto: Questo documento tratta in modo esauriente diversi metodi per capire come riparare un'installazione di Apache che non funziona in modo corretto.

Michael Stewart
Autore

Elfyn McBratney
Collaboratore

Bryan Østergaard
Collaboratore

Benedikt Böhm
Collaboratore

Davide Cendron
Traduzione

Donate to support our development efforts.

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