[Wapt] Accès serveur apache souvent en rade

Mon Jun 1 17:28:09 CEST 2015

Bonjour Joël,

> Je suis en train de tester Wapt sur un serveur tout neuf et à par le
> système et ses mise à jour, strictement aucuns services ou applications
> n'ont été ajouté (sauf Wapt). Voici quelques informations que je peut
> trouver :
>
>   * Système : Debian 8.0 "Jessie"
>   * RAM : 8 Go
>   * Processeur : Intel Xeon / 3,8 Ghz quatre cœur
>   * WAPT : 1.2.3

merci beaucoup pour ces détails. En effet, je pense que l'on peut 
écarter le problème lié à la RAM... On a déjà eu ce soucis qui avait été 
remonté sur la mailing list avec des serveurs à 256Mo de RAM, je voulais 
donc être sûr. Normalement ça devrait pouvoir tourner très bien sur une 
machine avec 1Go de RAM.

Le développement se fait actuellement sur la version Debian Jessie, donc 
on teste régulièrement wapt sur cette version. Après c'est vrai que l'on 
a principalement des déploiements en production sous Wheezy, la Jessie 
étant sortie que très récemment.

> Pour obtenir les autres informations, quelle commande ou quel fichiers
> doit je ouvrir ?
>
>
> Ici le détail du fichier */var/log/waptserver.log*
 > /
 > *** Starting uWSGI 2.0.7-debian (64bit) on [Mon Jun  1 07:35:03 2015] ***
 > compiled with version: 4.9.1 on 25 October 2014 19:17:54
 > os: Linux-3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)
 > nodename: srv-omv
 > machine: x86_64
 > clock source: unix
 > pcre jit disabled
 > detected number of CPU cores: 4
 > current working directory: /
 > writing pidfile to /var/run/waptserver.pid
 > detected binary path: /usr/bin/uwsgi-core
 > setgid() to 33
 > setuid() to 118
 > your processes number limit is 31835
 > your memory page size is 4096 bytes
 > detected max file descriptor number: 1024
 > lock engine: pthread robust mutexes
 > thunder lock: disabled (you can enable it with --thunder-lock)
 > uwsgi socket 0 bound to TCP address 127.0.0.1:8080 fd 3/

le log ne nous dit rien d'intéressant à part que le serveur à bien 
démarré... Est ce qu'il n'y a pas d'autre choses après? Est ce qu'il ne 
va pas jusqu'à :
  ...
  spawned uWSGI worker 15 (pid: 13581, cores: 1)
  spawned uWSGI worker 16 (pid: 13582, cores: 1)
  [pid: 13582|app: 0|req: 1/1] 127.0.0.1 () {38 vars in 529 bytes} [Mon 
Jun  1 07:07:23 2015] GET /Packages => generated 233 bytes in 5342 msecs 
(HTTP/1.1 404) 2 headers in 72 bytes (1 switches on core 0)

Est ce que vous pourriez vérifier dans ce fichier waptserver.log au 
moment du problème d'accès si il y a des stack trace avec des exceptions 
python?

Quand vous avez à relancer le serveur, est ce que vous avez tous les 
processus présents :
* 1 process /usr/bin/mongod --config /etc/mongodb.conf
* 16 process /usr/bin/uwsgi-core -d /var/log/waptserver.log --pidfile 
/var/run/waptserver.pid --ini /opt/wapt/waptserver/waptserver.ini --uid 
wapt --gid www-data --plugin http,python

Est ce que vous pourriez vérifier la mémoire au moment du problème :
  free -m

Juste pour vérifier, est ce qu'il y a suffisamment d'espace disque (le 
mongodb a tendance à consommer plusieurs centaines de Mo d'espace disque)?
  df -h

Lors du prochain problème, est ce que vous pourriez essayer de relancer 
d'abord le serveur wapt plutôt que de relancer toute la machine pour 
voir si ça résoud le problème.
  /etc/init.d/waptserver restart

Après vous pouvez vous reconnecter à l'adresse (il faudra éventuellement 
le relancer deux fois la requête http pour ré-initialiser le pool de 
connexion du ProxyPassReverse)
  http://10.111.15.2

Lors du blocage du serveur python, est ce que vous pourriez vérifier si 
il y a toujours des connexions en cours, par exemple :

[root at srvwapt.tranq mongodb]# netstat -tapn | grep 8080
tcp        0      0 127.0.0.1:8080          0.0.0.0:* 
LISTEN      5762/uwsgi-core
tcp        0      0 127.0.0.1:8080          127.0.0.1:39525 
TIME_WAIT   -
tcp        1      0 127.0.0.1:39527         127.0.0.1:8080 
CLOSE_WAIT  13336/apache2
tcp        0      0 127.0.0.1:8080          127.0.0.1:39526 
TIME_WAIT   -
tcp        1      0 127.0.0.1:34114         127.0.0.1:8080 
CLOSE_WAIT  13337/apache2
tcp        1      0 127.0.0.1:39372         127.0.0.1:8080 
CLOSE_WAIT  13336/apache2
tcp        1      0 127.0.0.1:37259         127.0.0.1:8080 
CLOSE_WAIT  13337/apache2
tcp        1      0 127.0.0.1:37269         127.0.0.1:8080 
CLOSE_WAIT  13337/apache2
tcp        1      0 127.0.0.1:37227         127.0.0.1:8080 
CLOSE_WAIT  13336/apache2
tcp        1      0 127.0.0.1:33772         127.0.0.1:8080 
CLOSE_WAIT  13336/apache2
tcp        0      0 127.0.0.1:39207         127.0.0.1:8080 
CLOSE_WAIT  13336/apache2
tcp        0      0 127.0.0.1:39202         127.0.0.1:8080 
CLOSE_WAIT  13337/apache2
tcp        0      0 127.0.0.1:8080          127.0.0.1:39527 
FIN_WAIT2   -

Pour voir si c'est un soucis avec le wrapper uwsgi, vous pouvez aussi 
essayer de lancer le serveur python sans uwsgi avec les commandes
  /etc/init.d/waptserver stop
  python /opt/wapt/waptserver/waptserver.py

Pour écarter des problèmes systèmes, est ce que vous pourriez vérifier 
avec la commande dmesg si il n'y aurai pas quelque chose d'intéressant 
de ce côté là?

J'ai jeté un coup d'oeil au logrotate du serveur wapt (le process qui 
fait tourner les logs pour éviter qu'ils deviennent trop gros). Il lance 
un redémarrage après la rotation des log à 6h du matin. Donc si vous 
n'avez que ce que vous mentionner dans le fichier de log, c'est que 
c'est tout ce qu'il y avait après le restart du uwsgi par le logrotate...

Cordialement,

Denis Cardon

>
>
>
>
>
> Cordialement, Latieule Joël - TICE / Collège Jules Ferry de Narbonne
>
> Le 29/05/2015 17:13, Denis Cardon a écrit :
>> Bonjour,
>>
>>> Je constate que chaque matin mon serveur WAPT est en panne et je doit
>>> relancer la machine pour que tout refonctionne. J'ai installé WAPT sur
>>> une débian et la console de gestion ou
>>> la page http du serveur ne répond plus. Voici l'erreur que je
>>> rencontre :
>>>
>>>
>>>   Service Unavailable
>>>
>>> The server is temporarily unable to service your request due to
>>> maintenance downtime or capacity problems. Please try again later.
>>>
>>> ------------------------------------------------------------------------
>>> Apache/2.4.10 (Debian) Server at 10.111.15.2 Port 80
>>
>> le message indique que le serveur Apache n'arrive pas à récupérer une
>> réponse du serveur uwsgi-python. C'est un peu succinct pour
>> diagnostiquer un problème... Histoire de ne pas avoir à jouer à madame
>> soleil, il faudrait avoir quelques informations complémentaires :
>>
>> combien de RAM avec vous sur cette machine? Est ce qu'il y a d'autres
>> choses services qui tournent en parallèle? Est ce qu'il y a des
>> oomkiller dans la sortie de dmesg? Est ce qu'il y a des process uwsgi
>> qui tourne encore quand le serveur ne répond plus? Est ce que process
>> mongodb est toujours là? Quelle est la version du serveur wapt
>> installé? Est ce qu'il y a des messages pertinents dans le fichier de
>> log /var/log/waptserver.log? etc.
>>
>> Cordialement,
>>
>> Denis Cardon
>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> WAPT mailing list
>>> WAPT at lists.tranquil.it
>>> http://lists.tranquil.it/listinfo/wapt
>>>
>>
>

-- 
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, bâtiment A
12 avenue Jules Verne
44230 Saint Sébastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr