[Wapt] Accès serveur apache souvent en rade

Latieule Joel joel.latieule at ac-montpellier.fr
Thu Jun 11 14:39:53 CEST 2015


Oui j'ai simplement fait l'installation de Jessie et fait les mises à 
jour avant de faire l'installation de wapt. C'est vraiment étrange, ça 
ressemble à une mise en veille des services plus qu'à un plantage.

Je vais refaire l'installation d'ici peut si je n'arrive pas à trouver 
de solution mais j'aurai préféré trouver la cause.


Cordialement, Latieule Joël - TICE / Collège Jules Ferry de Narbonne

Le 10/06/2015 08:57, Yann DAVID a écrit :
> 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
>>
>
>



More information about the WAPT mailing list