[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