[Wapt] Accès serveur apache souvent en rade

Latieule Joel joel.latieule at ac-montpellier.fr
Tue Jun 30 13:54:14 CEST 2015


Je viens de dé-installer toute l'interface graphique et j'ai le bon 
vieux terminal comme écran.

Il me reste plus qu'à attendre quelques jours pour vérifier si le 
problème ce répète.




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

Le 23/06/2015 12:31, Denis Cardon a écrit :
> Bonjour Claude,
>
> (j'ai remis wapt at list.tranquil.it en copie)
>
>> Désinstallé le desktop pour éviter l'économie d'énergie ... Ca va un
>> petit peu loin et l'economie d'energie ne fonctionne pas de cette facon.
>> Jamais la gestion d'energie n'ira tuer vos processus pour ca. (Il mettra
>> l'interface réseau en veille, peut etre,
>
> c'est le genre de comportement dont je parle... Dans l'agent wapt sur 
> les postes client Windows, on gère la mise en veille et les up/down 
> d'interfaces réseau car c'est pas du tout transparent pour un process 
> daemon comme waptagent.exe.
>
> Mais sur le serveur wapt, on a rien fait de spécial pour gérer cela 
> car on part du principe que l'on est en machine virtuelle. Donc si on 
> a des up/down sur les interfaces réseaux, un suspend to disk/ram, des 
> sauts dans le temps NTP ou d'autres bizarreries, je ne garantie pas 
> que ça fonctionne.
>
> De plus, sur un serveur Linux, la tradition est de ne pas installer 
> d'interface graphique... Un bon vieux ssh et ça fait l'affaire.
>
> > mais n'occasionnera jamais cette erreur :
>> //...brutally killing workers.../ et /SIGINT/SIGQUIT received...killing
>> workers.../
>
> Uwsgi fait des messages qui peuvent sembler perturbant, mais c'est le 
> fonctionnement "normal", par exemple en lui envoyant un SIGQUIT (ce 
> que fait le script /etc/init.d/waptserver stop ligne 84) on obtient :
>
> Stopping waptserver: SIGINT/SIGQUIT received...killing workers...
> killing the spooler with pid 23446
> ........spooler (pid: 23446) annihilated
> 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 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.
> .waptserver.
>
> Mais c'est vrai que le "brutally" n'apparait pas normalement... Il 
> faudrait que Joël nous dise si ce message est apparut après une 
> relance manuelle du serveur ou non.
>
>> /Ces 2 messages indiquent que le process uwsgi recoit un sigint ou
>> sigquit ce qui arrive quand l'utilisateur presse Ctrl-C./
>
> Le process uwsgi est lancé par défaut en mode daemon par le script 
> d'init, on ne doit pas pouvoir lui envoyer un ctrl-C (sauf si on le 
> lance à la main en mode débug)...
>
>> /Pour pouvoir débugguer ce problème il faudrait : /
>> /
>> /
>> /Avoir les fichiers /var/log/messages et /var/log/syslog ainsi que
>> /var/log/kern.log/
>> /
>> /
>> /Quelque chose kill UWSGI et il faudrait savoir ce que c'est ;)/
>
> en effet, il faudrait avoir plus d'information, mais pour commencer, 
> je veux être sûr qu'il n'y a pas d'autres choses qui interagissent 
> avec les processus serveur. Il y a plus de 300 serveurs WAPT déployés 
> sous Linux et Windows, et ce comportement nous a été remonté que deux 
> fois sur la mailing list. Je veux donc d'abord écarter les problèmes 
> liés à la machine spécifiquement.
>
> Cordialement,
>
> Denis Cardon
>
>
>
>
>
>> /
>> /
>> /
>> /
>>
>>
>>
>> Le 23 juin 2015 10:57, Denis Cardon <denis.cardon at tranquil-it-systems.fr
>> <mailto:denis.cardon at tranquil-it-systems.fr>> a écrit :
>>
>>     Bonjour Joel,
>>
>>         Je me rend compte que j'ai oublié de répondre.
>>
>>         Le temps du test, j'ai installé debian avec le bureau Gnome. Il
>>         est en
>>         effet probable que la gestion de l'énergie pose problème. Que
>>         doit je
>>         modifier pour corriger ce problème?
>>
>>
>>     Il serait intéressant déjà de désinstaller les paquets desktop. Il y
>>     a une page sur stackexchange [1] qui suggère la ligne de commande
>>     suivante:
>>
>>     apt-get purge $(tasksel --task-packages desktop)
>>
>>     Cordialement,
>>
>>     Denis Cardon
>>
>>
>>     [1]
>> http://unix.stackexchange.com/questions/56316/can-i-uninstall-gui-from-debian
>>
>>
>>
>>
>>         Cordialement, Latieule Joël - TICE / Collège Jules Ferry de 
>> Narbonne
>>
>>         Le 11/06/2015 15:23, Denis Cardon a écrit :
>>
>>             Bonjour Joel,
>>
>>                 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.
>>
>>
>>             petite question juste pour être sûr, est ce que
>>             l'installation jessie
>>             est minimaliste (ie un prompt texte sur un fond noir) ou
>>             bien il y a
>>             un environnement graphique complet et les outils d'économie
>>             d'énergie
>>             qui vont avec?...
>>
>>             Pour faire l'installation serveur, le mieux c'est de faire
>>             l'installation en mode texte en décochant TOUTES les options
>>             sauf le
>>             serveur SSH que l'on conserve. Vu le matériel serveur, il ne
>>             devrait
>>             pas y avoir de mode économie d'énergie trop agressif sur les
>>             ports
>>             réseaux ou le reste du matériel, mais il vaut mieux ne rien
>>             installer
>>             d'inutile pour éviter que le serveur ne se comporte comme un
>>             desktop.
>>
>>             Après, ce qui est encore préférable, c'est d'installer une
>>             couche de
>>             virtualisation (par exemple XenServer ou consort), et
>>             d'installer le
>>             serveur WAPT en machine virtuelle.
>>
>>             Cordialement,
>>
>>             Denis Cardon
>>
>>
>>                 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 <http://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 <http://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 <http://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 
>> <http://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
>>                                 <http://127.0.0.1:8080>
>>                                 0.0.0.0:* LISTEN
>>                                 5762/uwsgi-core
>>                                 tcp        0      0 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080> 127.0.0.1:39525
>>                                 <http://127.0.0.1:39525>
>>                                 TIME_WAIT   -
>>                                 tcp        1      0 127.0.0.1:39527
>>                                 <http://127.0.0.1:39527> 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080>
>>                                 CLOSE_WAIT  13336/apache2
>>                                 tcp        0      0 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080> 127.0.0.1:39526
>>                                 <http://127.0.0.1:39526>
>>                                 TIME_WAIT   -
>>                                 tcp        1      0 127.0.0.1:34114
>>                                 <http://127.0.0.1:34114> 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080>
>>                                 CLOSE_WAIT  13337/apache2
>>                                 tcp        1      0 127.0.0.1:39372
>>                                 <http://127.0.0.1:39372> 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080>
>>                                 CLOSE_WAIT  13336/apache2
>>                                 tcp        1      0 127.0.0.1:37259
>>                                 <http://127.0.0.1:37259> 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080>
>>                                 CLOSE_WAIT  13337/apache2
>>                                 tcp        1      0 127.0.0.1:37269
>>                                 <http://127.0.0.1:37269> 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080>
>>                                 CLOSE_WAIT  13337/apache2
>>                                 tcp        1      0 127.0.0.1:37227
>>                                 <http://127.0.0.1:37227> 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080>
>>                                 CLOSE_WAIT  13336/apache2
>>                                 tcp        1      0 127.0.0.1:33772
>>                                 <http://127.0.0.1:33772> 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080>
>>                                 CLOSE_WAIT  13336/apache2
>>                                 tcp        0      0 127.0.0.1:39207
>>                                 <http://127.0.0.1:39207> 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080>
>>                                 CLOSE_WAIT  13336/apache2
>>                                 tcp        0      0 127.0.0.1:39202
>>                                 <http://127.0.0.1:39202> 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080>
>>                                 CLOSE_WAIT  13337/apache2
>>                                 tcp        0      0 127.0.0.1:8080
>>                                 <http://127.0.0.1:8080> 127.0.0.1:39527
>>                                 <http://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
>> <mailto:WAPT at lists.tranquil.it>
>> http://lists.tranquil.it/listinfo/wapt
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>                             WAPT mailing list
>>                             WAPT at lists.tranquil.it
>> <mailto:WAPT at lists.tranquil.it>
>> http://lists.tranquil.it/listinfo/wapt
>>
>>
>>
>>
>> _______________________________________________
>>                         WAPT mailing list
>>                         WAPT at lists.tranquil.it
>>                         <mailto:WAPT at lists.tranquil.it>
>>                         http://lists.tranquil.it/listinfo/wapt
>>
>>
>>
>>
>>                 _______________________________________________
>>                 WAPT mailing list
>>                 WAPT at lists.tranquil.it <mailto: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 <tel:%2B33%20%280%29%202.40.97.57.55>
>>     http://www.tranquil-it-systems.fr
>>
>>     _______________________________________________
>>     WAPT mailing list
>>     WAPT at lists.tranquil.it <mailto:WAPT at lists.tranquil.it>
>>     http://lists.tranquil.it/listinfo/wapt
>>
>>
>



More information about the WAPT mailing list