Risoluzione dei problemi in Apache
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 |
# 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'
|
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 |
APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"
APACHE2_OPTS=""
|
Codice 3.3: Riavviare Apache |
# /etc/init.d/apache2 stop
# 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 |
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
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 |
# cd /etc/apache2/
# 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.
I contenuti di questo documento sono rilasciati sotto la licenza Creative
Commons - Attribution / Share Alike.
|