1 votes

Apache22 sur FreeBSD - Démarre, ne répond pas aux requêtes

J'exécute Apache 2.2.17 avec le MPM peruser sur FreeBSD 8.2-RC1 sur l'EC2 d'Amazon (donc XEN). Il a été installé à partir des ports.

Mon problème est que, bien qu'Apache soit en cours d'exécution, qu'il écoute et accepte les connexions, il ne répond pas aux connexions et ne les affiche pas dans le journal.

Si je me connecte au port sur lequel il écoute et que je tape une requête HTTP :

GET / HTTP/1.1
Host: asdfasdf

J'ai appuyé sur la touche entrée plusieurs fois, et ça reste là... Rien. Pas de réponse non plus en demandant avec un navigateur. Il ne semble pas y avoir quelque chose d'utile dans le journal des erreurs :

[Sun Jan 09 16:56:24 2011] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
[Sun Jan 09 16:56:25 2011] [notice] Digest: generating secret for digest authentication ...
[Sun Jan 09 16:56:25 2011] [notice] Digest: done
[Sun Jan 09 16:56:25 2011] [notice] Apache/2.2.17 (FreeBSD) mod_ssl/2.2.17 

Le journal des accès reste vide :

root:/var/log# wc httpd-access.log 
       0       0       0 httpd-access.log
root:/var/log#

J'ai essayé avec accf_http et accf_data activés et désactivés, et avec la configuration de base et ma configuration personnalisée. J'ai également essayé de désinstaller apache22-peruser-mpm et d'installer directement apache22... Toujours pas de chance. J'ai essayé de supprimer toutes les lignes LoadModule de httpd.conf et de réactiver celles qui étaient nécessaires pour analyser la configuration. Je me suis retrouvé avec seulement les modules suivants chargés :

root:/usr/local/etc/apache22# /usr/local/sbin/apachectl -M
Loaded Modules:
 core_module (static)
 mpm_peruser_module (static)
 http_module (static)
 so_module (static)
 authz_host_module (shared)
 log_config_module (shared)
 alias_module (shared)
Syntax OK
root:/usr/local/etc/apache22#

Mêmes résultats.

Apache es définitivement ce qui écoute sur le port 80 :

root:/usr/local/etc/apache22# sockstat -4 | grep httpd
root     httpd      43789 3  tcp4 6 *:80                  *:*
root     httpd      43789 4  tcp4   *:*                   *:*
root:/usr/local/etc/apache22#

Et je sais qu'il ne s'agit pas d'un problème de pare-feu car rien ne tourne localement, et la connexion de la boîte locale à 127.0.0.1:80 donne le même résultat.

Est-ce que quelqu'un a une idée de ce qui se passe ? Pourquoi il fait ça ? J'ai épuisé toutes mes compétences en matière de débogage. :/

Merci pour toute suggestion !

EDIT : Selon la suggestion de Phil Hollenback, j'ai lancé une trace sur les appels système. Voici ce que j'ai trouvé avec ktrace et truss.

48443 httpd    CALL  select(0,0,0,0,0xbf7feab4)
48443 httpd    RET   select 0
48443 httpd    CALL  gettimeofday(0xbf7feae4,0)
48443 httpd    RET   gettimeofday 0
48443 httpd    CALL  wait4(0xffffffff,0xbf7fea98,WNOHANG|WUNTRACED,0)
48443 httpd    RET   wait4 -1 errno 10 No child processes
48443 httpd    CALL  select(0,0,0,0,0xbf7feab4)
48443 httpd    RET   select 0
48443 httpd    CALL  gettimeofday(0xbf7feae4,0)
48443 httpd    RET   gettimeofday 0
48443 httpd    CALL  wait4(0xffffffff,0xbf7fea98,WNOHANG|WUNTRACED,0)
48443 httpd    RET   wait4 -1 errno 10 No child processes
48443 httpd    CALL  select(0,0,0,0,0xbf7feab4)

La même chose répétée encore et encore. (Ce sont les dernières lignes.) Ce qui semble se passer, c'est qu'il va jusqu'à la sélection, s'arrête un moment, renvoie 0, puis réessaie. Je ne sais pas si c'est un comportement normal, mais cela me semble correct car on dirait qu'il ne fait qu'interroger le socket ?

Ce qui m'inquiète, c'est que l'attente renvoie une erreur indiquant que le processus n'existe pas. La sortie de truss (avec lequel j'ai démarré le processus, en obtenant la configuration initiale) montre un appel à fork() qui semble revenir correctement (renvoie un PID, pas d'erreur).

Au cas où ça aiderait, la sortie de truss : http://nucleardog.com/apache-truss.txt (Mis à jour pour httpd -X .)

J'ai effectivement établi une connexion pendant cette exécution - select ne semble jamais renvoyer une nouvelle connexion ? A

Je pense que c'est peut-être plus un problème de FreeBSD que d'Apache, car il semble qu'Apache ne reçoive jamais la requête :/.

Des idées (supplémentaires) ?

EDIT 2 : Cela semble être un problème avec quelque chose dans FreeBSD, étant donné qu'Apache ne semble jamais recevoir la demande de connexion. J'ai posté un message sur les forums FreeBSD (forums.freebsd.org/showthread.php?p=118612) pour voir si je peux y trouver de l'aide. Merci à tous pour votre temps !

1voto

RyanBrady Points 1903

Essayez ce qui suit :

  1. pstree | less pour trouver le pid du processus apache maître
  2. strace -p <pid> -f pour observer les appels système du processus de l'étape 1.
  3. connectez-vous à apache avec telnet ou un navigateur web.

Vous pouvez avoir besoin d'installer pstree et strace à partir des ports freebsd. Vous devriez voir une sortie défilante de strace qui enregistre les appels système (ouvertures de fichiers, etc.) générés par le processus apache en cours d'exécution. Cela devrait vous donner un indice pour savoir si apache est réellement en cours d'exécution et ne produit pas de sortie pour une raison quelconque.

Cette page sur débogage d'apache contient les informations ci-dessus ainsi que d'autres conseils de dépannage que vous pouvez utiliser.

Vous mentionnez également votre journal d'accès mais pas votre journal d'erreurs, l'avez-vous consulté ? Il pourrait contenir des informations de diagnostic supplémentaires.

EDIT : Duh, vous avez dit que vous avez regardé le journal des erreurs, désolé. De plus, truss est l'outil de suivi des appels par défaut de freebsd, pas strace. Utiliser truss est une meilleure réponse puisque vous n'avez pas à le compiler à partir des ports comme strace.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X