[Wapt] Accès serveur apache souvent en rade

Yann DAVID yann.david at ac-montpellier.fr
Wed Jun 10 08:57:22 CEST 2015


Le 09/06/2015 13:11, Latieule Joel a écrit :

> Si je repart sur une toute nouvelle installation de debian. Que doit je
> sauvegarder pour retrouver la liaison entre mes postes client et le
> serveur wapt ?

Salut Joël,
T'as rien fait d'autre que de dédier ta Debian à wapt ?

Sinon, j'ai justement refait une install de wapt sur Jessie y'a à peine 
48 heures (wapt tournait sous Win2003 jusque là).

Comme l'a dit Hubert,  j'ai recopié mes paquets (logiciels et host). La 
seule chose à ne pas faire pour éviter de recommencer à zéro, c'est de 
régénérer la paire de clés.
Pour ma part, j'ai pas copié mongodb, les machines sont en train de 
remonter toutes seules petit à petit.

Pour le moment ça roule.

> Cordialement, Latieule Joël - TICE / Collège Jules Ferry de Narbonne
>
> Le 02/06/2015 09:07, Latieule Joel a écrit :
>> Le redémarrage du service wapt permet de rétablir son fonctionnement
>> mais je n'ai pas trouver la commander pour lister les processus. En
>> pièce jointe vous trouverez la réponse complète de dmesg
>>
>>
>> Les commandes pour l'espaces disque et ram montre qu'il reste de la marge
>>
>> root at srv-omv:/home/administrateur# df -h
>> /Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
>> /dev/sda1           46G    7,3G   37G  17% /
>> udev                10M       0   10M   0% /dev
>> tmpfs              1,6G    8,8M  1,6G   1% /run
>> tmpfs              3,9G     88K  3,9G   1% /dev/shm
>> tmpfs              5,0M       0  5,0M   0% /run/lock
>> tmpfs              3,9G       0  3,9G   0% /sys/fs/cgroup
>> tmpfs              798M     20K  798M   1% /run/user/1000/
>>
>>
>> root at srv-omv:/home/administrateur# free -m
>> /             total       used       free     shared buffers     cached
>> Mem:          7975       1354       6620         11 76        496
>> -/+ buffers/cache:        782       7193
>> Swap:        16321          0      16321/
>>
>>
>> Pour le fichier /var/log/waptserver.log en effet il était incomplet :
>> /*** Starting uWSGI 2.0.7-debian (64bit) on [Tue Jun  2 07:35:01 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//
>> //Python version: 2.7.9 (default, Mar  1 2015, 13:01:26) [GCC 4.9.2]//
>> //Python main interpreter initialized at 0x1cb06d0//
>> //python threads support enabled//
>> //your server socket listen backlog is limited to 100 connections//
>> //your mercy for graceful operations on workers is 60 seconds//
>> //mapped 1237056 bytes (1208 KB) for 16 cores//
>> //*** Operational MODE: preforking ***//
>> //WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter
>> 0x1cb06d0 pid: 5068 (default app)//
>> //*** uWSGI is running in multiple interpreter mode ***//
>> //spawned uWSGI master process (pid: 5068)//
>> //spawned uWSGI worker 1 (pid: 5090, cores: 1)//
>> //spawned uWSGI worker 2 (pid: 5091, cores: 1)//
>> //spawned uWSGI worker 3 (pid: 5092, cores: 1)//
>> //spawned uWSGI worker 4 (pid: 5093, cores: 1)//
>> //spawned uWSGI worker 5 (pid: 5094, cores: 1)//
>> //spawned uWSGI worker 6 (pid: 5095, cores: 1)//
>> //spawned uWSGI worker 7 (pid: 5096, cores: 1)//
>> //spawned uWSGI worker 8 (pid: 5097, cores: 1)//
>> //spawned uWSGI worker 9 (pid: 5098, cores: 1)//
>> //spawned uWSGI worker 10 (pid: 5099, cores: 1)//
>> //spawned uWSGI worker 11 (pid: 5100, cores: 1)//
>> //spawned uWSGI worker 12 (pid: 5101, cores: 1)//
>> //spawned uWSGI worker 13 (pid: 5102, cores: 1)//
>> //spawned uWSGI worker 14 (pid: 5103, cores: 1)//
>> //spawned uWSGI worker 15 (pid: 5104, cores: 1)//
>> //spawned uWSGI worker 16 (pid: 5105, cores: 1)//
>> //...brutally killing workers.../
>> /*** Starting uWSGI 2.0.7-debian (64bit) on [Tue Jun  2 08:41:02 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: /home/administrateur
>> 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: 65536
>> 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
>> Python version: 2.7.9 (default, Mar  1 2015, 13:01:26)  [GCC 4.9.2]
>> Python main interpreter initialized at 0xe4de90
>> python threads support enabled
>> your server socket listen backlog is limited to 100 connections
>> your mercy for graceful operations on workers is 60 seconds
>> mapped 1237056 bytes (1208 KB) for 16 cores
>> *** Operational MODE: preforking ***
>> WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0xe4de90
>> pid: 5185 (default app)
>> *** uWSGI is running in multiple interpreter mode ***
>> spawned uWSGI master process (pid: 5185)
>> spawned uWSGI worker 1 (pid: 5190, cores: 1)
>> spawned uWSGI worker 2 (pid: 5191, cores: 1)
>> spawned uWSGI worker 3 (pid: 5192, cores: 1)
>> spawned uWSGI worker 4 (pid: 5193, cores: 1)
>> spawned uWSGI worker 5 (pid: 5194, cores: 1)
>> spawned uWSGI worker 6 (pid: 5195, cores: 1)
>> spawned uWSGI worker 7 (pid: 5196, cores: 1)
>> spawned uWSGI worker 8 (pid: 5197, cores: 1)
>> spawned uWSGI worker 9 (pid: 5198, cores: 1)
>> spawned uWSGI worker 10 (pid: 5199, cores: 1)
>> spawned uWSGI worker 11 (pid: 5200, cores: 1)
>> spawned uWSGI worker 12 (pid: 5201, cores: 1)
>> spawned uWSGI worker 13 (pid: 5202, cores: 1)
>> spawned uWSGI worker 14 (pid: 5203, cores: 1)
>> spawned uWSGI worker 15 (pid: 5204, cores: 1)
>> spawned uWSGI worker 16 (pid: 5205, cores: 1)
>> invalid HTTP request size (max 4096)...skip
>> [pid: 5204|app: 0|req: 1/1] 127.0.0.1 () {38 vars in 567 bytes} [Tue
>> Jun  2 08:42:15 2015] GET / => generated 6888 bytes in 458 msecs
>> (HTTP/1.1 200) 2 heade$
>> [pid: 5204|app: 0|req: 2/2] 127.0.0.1 () {44 vars in 765 bytes} [Tue
>> Jun  2 08:42:15 2015] GET /static/themes/tranquilit/style.css =>
>> generated 8443 bytes i$
>> [pid: 5198|app: 0|req: 1/3] 127.0.0.1 () {44 vars in 811 bytes} [Tue
>> Jun  2 08:42:15 2015] GET /static/themes/tranquilit/img/logo-tis.jpg
>> => generated 0 byt$
>> [pid: 5204|app: 0|req: 3/4] 127.0.0.1 () {44 vars in 808 bytes} [Tue
>> Jun  2 08:42:15 2015] GET /static/themes/tranquilit/img/contact.jpg =>
>> generated 0 byte$
>> [pid: 5193|app: 0|req: 1/5] 127.0.0.1 () {44 vars in 776 bytes} [Tue
>> Jun  2 08:42:15 2015] GET /static/themes/tranquilit/css/screen.css =>
>> generated 12613 b$
>> [pid: 5198|app: 0|req: 2/6] 127.0.0.1 () {44 vars in 776 bytes} [Tue
>> Jun  2 08:42:15 2015] GET /static/themes/tranquilit/css/buttons.css =>
>> generated 2104 b$
>> [pid: 5196|app: 0|req: 1/7] 127.0.0.1 () {44 vars in 800 bytes} [Tue
>> Jun  2 08:42:16 2015] GET /static/themes/tranquilit/img/bgd.png =>
>> generated 0 bytes in$
>> SIGINT/SIGQUIT received...killing workers...
>> worker 1 buried after 1 seconds
>> worker 2 buried after 1 seconds
>> worker 3 buried after 1 seconds
>> worker 4 buried after 1 seconds
>> worker 5 buried after 1 seconds
>> worker 6 buried after 1 seconds
>> worker 7 buried after 1 seconds
>> worker 8 buried after 1 seconds
>> worker 9 buried after 1 seconds
>> worker 10 buried after 1 seconds
>> worker 11 buried after 1 seconds
>> worker 11 buried after 1 seconds
>> worker 12 buried after 1 seconds
>> worker 13 buried after 1 seconds
>> worker 14 buried after 1 seconds
>> worker 15 buried after 1 seconds
>> worker 16 buried after 1 seconds
>> goodbye to uWSGI.
>> *** Starting uWSGI 2.0.7-debian (64bit) on [Tue Jun  2 08:45:21 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: /home/administrateur
>> 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: 65536
>> 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
>> Python version: 2.7.9 (default, Mar  1 2015, 13:01:26)  [GCC 4.9.2]
>> Python main interpreter initialized at 0x970e90
>> python threads support enabled
>> your server socket listen backlog is limited to 100 connections
>> your mercy for graceful operations on workers is 60 seconds
>> mapped 1237056 bytes (1208 KB) for 16 cores
>> *** Operational MODE: preforking ***
>> WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x970e90
>> pid: 5291 (default app)
>> *** uWSGI is running in multiple interpreter mode ***
>> spawned uWSGI master process (pid: 5291)
>> spawned uWSGI worker 1 (pid: 5296, cores: 1)
>> spawned uWSGI worker 2 (pid: 5297, cores: 1)
>> spawned uWSGI worker 3 (pid: 5298, cores: 1)
>> spawned uWSGI worker 4 (pid: 5299, cores: 1)
>> spawned uWSGI worker 5 (pid: 5300, cores: 1)
>> spawned uWSGI worker 6 (pid: 5301, cores: 1)
>> spawned uWSGI worker 7 (pid: 5302, cores: 1)
>> spawned uWSGI worker 8 (pid: 5303, cores: 1)
>> spawned uWSGI worker 9 (pid: 5304, cores: 1)
>> spawned uWSGI worker 10 (pid: 5305, cores: 1)
>> spawned uWSGI worker 11 (pid: 5306, cores: 1)
>> spawned uWSGI worker 12 (pid: 5307, cores: 1)
>> spawned uWSGI worker 13 (pid: 5308, cores: 1)
>> spawned uWSGI worker 14 (pid: 5309, cores: 1)
>> spawned uWSGI worker 15 (pid: 5310, cores: 1)
>> spawned uWSGI worker 16 (pid: 5311, cores: 1)
>> invalid HTTP request size (max 4096)...skip
>> [pid: 5299|app: 0|req: 1/1] 127.0.0.1 () {38 vars in 512 bytes} [Tue
>> Jun  2 08:50:00 2015] GET /Packages => generated 233 bytes in 4 msecs
>> (HTTP/1.1 404) 2 $
>> [pid: 5299|app: 0|req: 2/2] 127.0.0.1 () {38 vars in 512 bytes} [Tue
>> Jun  2 08:50:00 2015] GET /Packages => generated 233 bytes in 0 msecs
>> (HTTP/1.1 404) 2 $
>> [pid: 5299|app: 0|req: 3/3] 127.0.0.1 () {38 vars in 497 bytes} [Tue
>> Jun  2 08:50:00 2015] HEAD / => generated 0 bytes in 421 msecs
>> (HTTP/1.1 200) 2 headers$
>> [pid: 5299|app: 0|req: 4/4] 127.0.0.1 () {38 vars in 497 bytes} [Tue
>> Jun  2 08:50:03 2015] HEAD / => generated 0 bytes in 420 msecs
>> (HTTP/1.1 200) 2 headers$
>> [pid: 5299|app: 0|req: 5/5] 127.0.0.1 () {44 vars in 617 bytes} [Tue
>> Jun  2 08:50:03 2015] POST /update_host => generated 1240 bytes in 19
>> msecs (HTTP/1.1 2$
>> [pid: 5310|app: 0|req: 1/6] 127.0.0.1 () {38 vars in 511 bytes} [Tue
>> Jun  2 08:50:17 2015] GET /Packages => generated 233 bytes in 4 msecs
>> (HTTP/1.1 404) 2 $
>> [pid: 5310|app: 0|req: 2/7] 127.0.0.1 () {38 vars in 511 bytes} [Tue
>> Jun  2 08:50:17 2015] GET /Packages => generated 233 bytes in 0 msecs
>> (HTTP/1.1 404) 2 $
>> [pid: 5311|app: 0|req: 1/8] 127.0.0.1 () {38 vars in 496 bytes} [Tue
>> Jun  2 08:50:18 2015] HEAD / => generated 0 bytes in 429 msecs
>> (HTTP/1.1 200) 2 headers$
>> [pid: 5310|app: 0|req: 3/9] 127.0.0.1 () {38 vars in 496 bytes} [Tue
>> Jun  2 08:50:18 2015] HEAD / => generated 0 bytes in 428 msecs
>> (HTTP/1.1 200) 2 headers$
>> [pid: 5310|app: 0|req: 4/10] 127.0.0.1 () {44 vars in 616 bytes} [Tue
>> Jun  2 08:50:19 2015] POST /update_host => generated 1249 bytes in 30
>> msecs (HTTP/1.1 $
>> [pid: 5310|app: 0|req: 5/11] 127.0.0.1 () {38 vars in 511 bytes} [Tue
>> Jun  2 08:50:22 2015] GET /Packages => generated 233 bytes in 0 msecs
>> (HTTP/1.1 404) 2$
>> [pid: 5310|app: 0|req: 6/12] 127.0.0.1 () {38 vars in 511 bytes} [Tue
>> Jun  2 08:50:29 2015] GET /Packages => generated 233 bytes in 0 msecs
>> (HTTP/1.1 404) 2$
>> [pid: 5309|app: 0|req: 1/13] 127.0.0.1 () {38 vars in 511 bytes} [Tue
>> Jun  2 08:50:41 2015] GET /Packages => generated 233 bytes in 4 msecs
>> (HTTP/1.1 404) 2$
>> [pid: 5299|app: 0|req: 6/14] 127.0.0.1 () {38 vars in 496 bytes} [Tue
>> Jun  2 08:52:20 2015] HEAD / => generated 0 bytes in 388 msecs
>> (HTTP/1.1 200) 2 header$
>> [pid: 5299|app: 0|req: 7/15] 127.0.0.1 () {38 vars in 496 bytes} [Tue
>> Jun  2 08:52:20 2015] HEAD / => generated 0 bytes in 431 msecs
>> (HTTP/1.1 200) 2 header$
>> [pid: 5299|app: 0|req: 8/16] 127.0.0.1 () {38 vars in 496 bytes} [Tue
>> Jun  2 08:52:24 2015] HEAD / => generated 0 bytes in 413 msecs
>> (HTTP/1.1 200) 2 header$
>> [pid: 5299|app: 0|req: 9/17] 127.0.0.1 () {44 vars in 616 bytes} [Tue
>> Jun  2 08:52:25 2015] POST /update_host => generated 1264 bytes in 30
>> msecs (HTTP/1.1 $
>> [pid: 5311|app: 0|req: 2/18] 127.0.0.1 () {38 vars in 511 bytes} [Tue
>> Jun  2 08:52:35 2015] GET /Packages => generated 233 bytes in 1 msecs
>> (HTTP/1.1 404) 2$
>> [pid: 5311|app: 0|req: 3/19] 127.0.0.1 () {38 vars in 511 bytes} [Tue
>> Jun  2 08:52:36 2015] GET /Packages => generated 233 bytes in 0 msecs
>> (HTTP/1.1 404) 2$
>> [pid: 5311|app: 0|req: 4/20] 127.0.0.1 () {38 vars in 496 bytes} [Tue
>> Jun  2 08:52:36 2015] HEAD / => generated 0 bytes in 426 msecs
>> (HTTP/1.1 200) 2 header$
>> [pid: 5311|app: 0|req: 5/21] 127.0.0.1 () {38 vars in 496 bytes} [Tue
>> Jun  2 08:52:36 2015] HEAD / => generated 0 bytes in 392 msecs
>> (HTTP/1.1 200) 2 header$
>> [pid: 5311|app: 0|req: 6/22] 127.0.0.1 () {44 vars in 616 bytes} [Tue
>> Jun  2 08:52:37 2015] POST /update_host => generated 1264 bytes in 27
>> msecs (HTTP/1.1 $/
>>
>> Cordialement, Latieule Joël - TICE / Collège Jules Ferry de Narbonne
>> Le 01/06/2015 17:28, Denis Cardon a écrit :
>>> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> _______________________________________________
>> WAPT mailing list
>> WAPT at lists.tranquil.it
>> http://lists.tranquil.it/listinfo/wapt
>
>
>
> _______________________________________________
> WAPT mailing list
> WAPT at lists.tranquil.it
> http://lists.tranquil.it/listinfo/wapt
>


-- 
Yann DAVID
AED TICE
Collège Joseph Delteil - Limoux


More information about the WAPT mailing list