<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
<br>
Le 09/06/2015 13:11, Latieule Joel a écrit :<br>
</div>
<blockquote cite="mid:5576C9C8.8090900@ac-montpellier.fr"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Bonjour,<br>
<br>
<br>
Avez vous des informations complémentaire concernant mon problème
? Autrement je pensai faire une tache pour redémarrer le serveur
wapt chaque matin<br>
<br>
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 ?<br>
<br>
</blockquote>
En gros, sauvegarder /var/www (pour les paquets wapt, et la config
des postes wapt-host) et /var/lib/mongodb<br>
Sur votre nouveau serveur, faire la post-install puis remettre ces 2
répertoires.<br>
Par ailleurs, évidemment toujours bien garder en lieu sûr votre clé
de signature privée .pem<br>
<br>
<blockquote cite="mid:5576C9C8.8090900@ac-montpellier.fr"
type="cite">
<pre class="moz-signature" cols="72">Cordialement, Latieule Joël - TICE / Collège Jules Ferry de Narbonne</pre>
<div class="moz-cite-prefix">Le 02/06/2015 09:07, Latieule Joel a
écrit :<br>
</div>
<blockquote cite="mid:556D5648.3080109@ac-montpellier.fr"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
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<br>
<br>
<br>
Les commandes pour l'espaces disque et ram montre qu'il reste de
la marge<br>
<br>
root@srv-omv:/home/administrateur# df -h<br>
<i><small>Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur<br>
/dev/sda1 46G 7,3G 37G 17% /<br>
udev 10M 0 10M 0% /dev<br>
tmpfs 1,6G 8,8M 1,6G 1% /run<br>
tmpfs 3,9G 88K 3,9G 1% /dev/shm<br>
tmpfs 5,0M 0 5,0M 0% /run/lock<br>
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup<br>
tmpfs 798M 20K 798M 1% /run/user/1000</small></i><br>
<br>
<br>
root@srv-omv:/home/administrateur# free -m<br>
<i><small> total used free shared
buffers cached<br>
Mem: 7975 1354 6620 11
76 496<br>
-/+ buffers/cache: 782 7193<br>
Swap: 16321 0 16321</small></i><br>
<br>
<br>
Pour le fichier /var/log/waptserver.log en effet il était
incomplet : <br>
<small><i>*** Starting uWSGI 2.0.7-debian (64bit) on [Tue Jun 2
07:35:01 2015] ***</i><i><br>
</i><i>compiled with version: 4.9.1 on 25 October 2014
19:17:54</i><i><br>
</i><i>os: Linux-3.16.0-4-amd64 #1 SMP Debian
3.16.7-ckt9-3~deb8u1 (2015-04-24)</i><i><br>
</i><i>nodename: srv-omv</i><i><br>
</i><i>machine: x86_64</i><i><br>
</i><i>clock source: unix</i><i><br>
</i><i>pcre jit disabled</i><i><br>
</i><i>detected number of CPU cores: 4</i><i><br>
</i><i>current working directory: /</i><i><br>
</i><i>writing pidfile to /var/run/waptserver.pid</i><i><br>
</i><i>detected binary path: /usr/bin/uwsgi-core</i><i><br>
</i><i>setgid() to 33</i><i><br>
</i><i>setuid() to 118</i><i><br>
</i><i>your processes number limit is 31835</i><i><br>
</i><i>your memory page size is 4096 bytes</i><i><br>
</i><i>detected max file descriptor number: 1024</i><i><br>
</i><i>lock engine: pthread robust mutexes</i><i><br>
</i><i>thunder lock: disabled (you can enable it with
--thunder-lock)</i><i><br>
</i><i>uwsgi socket 0 bound to TCP address 127.0.0.1:8080 fd 3</i><i><br>
</i><i>Python version: 2.7.9 (default, Mar 1 2015, 13:01:26)
[GCC 4.9.2]</i><i><br>
</i><i>Python main interpreter initialized at 0x1cb06d0</i><i><br>
</i><i>python threads support enabled</i><i><br>
</i><i>your server socket listen backlog is limited to 100
connections</i><i><br>
</i><i>your mercy for graceful operations on workers is 60
seconds</i><i><br>
</i><i>mapped 1237056 bytes (1208 KB) for 16 cores</i><i><br>
</i><i>*** Operational MODE: preforking ***</i><i><br>
</i><i>WSGI app 0 (mountpoint='') ready in 0 seconds on
interpreter 0x1cb06d0 pid: 5068 (default app)</i><i><br>
</i><i>*** uWSGI is running in multiple interpreter mode ***</i><i><br>
</i><i>spawned uWSGI master process (pid: 5068)</i><i><br>
</i><i>spawned uWSGI worker 1 (pid: 5090, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 2 (pid: 5091, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 3 (pid: 5092, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 4 (pid: 5093, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 5 (pid: 5094, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 6 (pid: 5095, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 7 (pid: 5096, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 8 (pid: 5097, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 9 (pid: 5098, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 10 (pid: 5099, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 11 (pid: 5100, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 12 (pid: 5101, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 13 (pid: 5102, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 14 (pid: 5103, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 15 (pid: 5104, cores: 1)</i><i><br>
</i><i>spawned uWSGI worker 16 (pid: 5105, cores: 1)</i><i><br>
</i><i>...brutally killing workers...</i></small><br>
<i><small>*** Starting uWSGI 2.0.7-debian (64bit) on [Tue Jun 2
08:41:02 2015] ***<br>
compiled with version: 4.9.1 on 25 October 2014 19:17:54<br>
os: Linux-3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
(2015-04-24)<br>
nodename: srv-omv<br>
machine: x86_64<br>
clock source: unix<br>
pcre jit disabled<br>
detected number of CPU cores: 4<br>
current working directory: /home/administrateur<br>
writing pidfile to /var/run/waptserver.pid<br>
detected binary path: /usr/bin/uwsgi-core<br>
setgid() to 33<br>
setuid() to 118<br>
your processes number limit is 31835<br>
your memory page size is 4096 bytes<br>
detected max file descriptor number: 65536<br>
lock engine: pthread robust mutexes<br>
thunder lock: disabled (you can enable it with
--thunder-lock)<br>
uwsgi socket 0 bound to TCP address 127.0.0.1:8080 fd 3<br>
Python version: 2.7.9 (default, Mar 1 2015, 13:01:26) [GCC
4.9.2]<br>
Python main interpreter initialized at 0xe4de90<br>
python threads support enabled<br>
your server socket listen backlog is limited to 100
connections<br>
your mercy for graceful operations on workers is 60 seconds<br>
mapped 1237056 bytes (1208 KB) for 16 cores<br>
*** Operational MODE: preforking ***<br>
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter
0xe4de90 pid: 5185 (default app)<br>
*** uWSGI is running in multiple interpreter mode ***<br>
spawned uWSGI master process (pid: 5185)<br>
spawned uWSGI worker 1 (pid: 5190, cores: 1)<br>
spawned uWSGI worker 2 (pid: 5191, cores: 1)<br>
spawned uWSGI worker 3 (pid: 5192, cores: 1)<br>
spawned uWSGI worker 4 (pid: 5193, cores: 1)<br>
spawned uWSGI worker 5 (pid: 5194, cores: 1)<br>
spawned uWSGI worker 6 (pid: 5195, cores: 1)<br>
spawned uWSGI worker 7 (pid: 5196, cores: 1)<br>
spawned uWSGI worker 8 (pid: 5197, cores: 1)<br>
spawned uWSGI worker 9 (pid: 5198, cores: 1)<br>
spawned uWSGI worker 10 (pid: 5199, cores: 1)<br>
spawned uWSGI worker 11 (pid: 5200, cores: 1)<br>
spawned uWSGI worker 12 (pid: 5201, cores: 1)<br>
spawned uWSGI worker 13 (pid: 5202, cores: 1)<br>
spawned uWSGI worker 14 (pid: 5203, cores: 1)<br>
spawned uWSGI worker 15 (pid: 5204, cores: 1)<br>
spawned uWSGI worker 16 (pid: 5205, cores: 1)<br>
invalid HTTP request size (max 4096)...skip<br>
[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$<br>
[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$<br>
[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$<br>
[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$<br>
[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$<br>
[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$<br>
[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$<br>
SIGINT/SIGQUIT received...killing workers...<br>
worker 1 buried after 1 seconds<br>
worker 2 buried after 1 seconds<br>
worker 3 buried after 1 seconds<br>
worker 4 buried after 1 seconds<br>
worker 5 buried after 1 seconds<br>
worker 6 buried after 1 seconds<br>
worker 7 buried after 1 seconds<br>
worker 8 buried after 1 seconds<br>
worker 9 buried after 1 seconds<br>
worker 10 buried after 1 seconds<br>
worker 11 buried after 1 seconds<br>
worker 11 buried after 1 seconds<br>
worker 12 buried after 1 seconds<br>
worker 13 buried after 1 seconds<br>
worker 14 buried after 1 seconds<br>
worker 15 buried after 1 seconds<br>
worker 16 buried after 1 seconds<br>
goodbye to uWSGI.<br>
*** Starting uWSGI 2.0.7-debian (64bit) on [Tue Jun 2
08:45:21 2015] ***<br>
compiled with version: 4.9.1 on 25 October 2014 19:17:54<br>
os: Linux-3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
(2015-04-24)<br>
nodename: srv-omv<br>
machine: x86_64<br>
clock source: unix<br>
pcre jit disabled<br>
detected number of CPU cores: 4<br>
current working directory: /home/administrateur<br>
writing pidfile to /var/run/waptserver.pid<br>
detected binary path: /usr/bin/uwsgi-core<br>
setgid() to 33<br>
setuid() to 118<br>
your processes number limit is 31835<br>
your memory page size is 4096 bytes<br>
detected max file descriptor number: 65536<br>
lock engine: pthread robust mutexes<br>
thunder lock: disabled (you can enable it with
--thunder-lock)<br>
uwsgi socket 0 bound to TCP address 127.0.0.1:8080 fd 3<br>
Python version: 2.7.9 (default, Mar 1 2015, 13:01:26) [GCC
4.9.2]<br>
Python main interpreter initialized at 0x970e90<br>
python threads support enabled<br>
your server socket listen backlog is limited to 100
connections<br>
your mercy for graceful operations on workers is 60 seconds<br>
mapped 1237056 bytes (1208 KB) for 16 cores<br>
*** Operational MODE: preforking ***<br>
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter
0x970e90 pid: 5291 (default app)<br>
*** uWSGI is running in multiple interpreter mode ***<br>
spawned uWSGI master process (pid: 5291)<br>
spawned uWSGI worker 1 (pid: 5296, cores: 1)<br>
spawned uWSGI worker 2 (pid: 5297, cores: 1)<br>
spawned uWSGI worker 3 (pid: 5298, cores: 1)<br>
spawned uWSGI worker 4 (pid: 5299, cores: 1)<br>
spawned uWSGI worker 5 (pid: 5300, cores: 1)<br>
spawned uWSGI worker 6 (pid: 5301, cores: 1)<br>
spawned uWSGI worker 7 (pid: 5302, cores: 1)<br>
spawned uWSGI worker 8 (pid: 5303, cores: 1)<br>
spawned uWSGI worker 9 (pid: 5304, cores: 1)<br>
spawned uWSGI worker 10 (pid: 5305, cores: 1)<br>
spawned uWSGI worker 11 (pid: 5306, cores: 1)<br>
spawned uWSGI worker 12 (pid: 5307, cores: 1)<br>
spawned uWSGI worker 13 (pid: 5308, cores: 1)<br>
spawned uWSGI worker 14 (pid: 5309, cores: 1)<br>
spawned uWSGI worker 15 (pid: 5310, cores: 1)<br>
spawned uWSGI worker 16 (pid: 5311, cores: 1)<br>
invalid HTTP request size (max 4096)...skip<br>
[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 $<br>
[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 $<br>
[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$<br>
[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$<br>
[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$<br>
[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 $<br>
[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 $<br>
[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$<br>
[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$<br>
[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 $<br>
[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$<br>
[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$<br>
[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$<br>
[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$<br>
[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$<br>
[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$<br>
[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 $<br>
[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$<br>
[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$<br>
[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$<br>
[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$<br>
[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 $</small></i><br>
<br>
<pre class="moz-signature" cols="72">Cordialement, Latieule Joël - TICE / Collège Jules Ferry de Narbonne</pre>
<div class="moz-cite-prefix">Le 01/06/2015 17:28, Denis Cardon a
écrit :<br>
</div>
<blockquote cite="mid:556C7A09.8070603@tranquil-it-systems.fr"
type="cite">Bonjour Joël, <br>
<br>
<blockquote type="cite">Je suis en train de tester Wapt sur un
serveur tout neuf et à par le <br>
système et ses mise à jour, strictement aucuns services ou
applications <br>
n'ont été ajouté (sauf Wapt). Voici quelques informations
que je peut <br>
trouver : <br>
<br>
* Système : Debian 8.0 "Jessie" <br>
* RAM : 8 Go <br>
* Processeur : Intel Xeon / 3,8 Ghz quatre cœur <br>
* WAPT : 1.2.3 <br>
</blockquote>
<br>
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. <br>
<br>
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. <br>
<br>
<blockquote type="cite">Pour obtenir les autres informations,
quelle commande ou quel fichiers <br>
doit je ouvrir ? <br>
<br>
<br>
Ici le détail du fichier */var/log/waptserver.log* <br>
</blockquote>
> / <br>
> *** Starting uWSGI 2.0.7-debian (64bit) on [Mon Jun 1
07:35:03 2015] *** <br>
> compiled with version: 4.9.1 on 25 October 2014 19:17:54
<br>
> os: Linux-3.16.0-4-amd64 #1 SMP Debian
3.16.7-ckt9-3~deb8u1 (2015-04-24) <br>
> nodename: srv-omv <br>
> machine: x86_64 <br>
> clock source: unix <br>
> pcre jit disabled <br>
> detected number of CPU cores: 4 <br>
> current working directory: / <br>
> writing pidfile to /var/run/waptserver.pid <br>
> detected binary path: /usr/bin/uwsgi-core <br>
> setgid() to 33 <br>
> setuid() to 118 <br>
> your processes number limit is 31835 <br>
> your memory page size is 4096 bytes <br>
> detected max file descriptor number: 1024 <br>
> lock engine: pthread robust mutexes <br>
> thunder lock: disabled (you can enable it with
--thunder-lock) <br>
> uwsgi socket 0 bound to TCP address 127.0.0.1:8080 fd 3/
<br>
<br>
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'à : <br>
... <br>
spawned uWSGI worker 15 (pid: 13581, cores: 1) <br>
spawned uWSGI worker 16 (pid: 13582, cores: 1) <br>
[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) <br>
<br>
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? <br>
<br>
Quand vous avez à relancer le serveur, est ce que vous avez
tous les processus présents : <br>
* 1 process /usr/bin/mongod --config /etc/mongodb.conf <br>
* 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 <br>
<br>
Est ce que vous pourriez vérifier la mémoire au moment du
problème : <br>
free -m <br>
<br>
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)? <br>
df -h <br>
<br>
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. <br>
/etc/init.d/waptserver restart <br>
<br>
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) <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://10.111.15.2">http://10.111.15.2</a> <br>
<br>
Lors du blocage du serveur python, est ce que vous pourriez
vérifier si il y a toujours des connexions en cours, par
exemple : <br>
<br>
[<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:root@srvwapt.tranq">root@srvwapt.tranq</a>
mongodb]# netstat -tapn | grep 8080 <br>
tcp 0 0 127.0.0.1:8080 0.0.0.0:*
LISTEN 5762/uwsgi-core <br>
tcp 0 0 127.0.0.1:8080 127.0.0.1:39525
TIME_WAIT - <br>
tcp 1 0 127.0.0.1:39527 127.0.0.1:8080
CLOSE_WAIT 13336/apache2 <br>
tcp 0 0 127.0.0.1:8080 127.0.0.1:39526
TIME_WAIT - <br>
tcp 1 0 127.0.0.1:34114 127.0.0.1:8080
CLOSE_WAIT 13337/apache2 <br>
tcp 1 0 127.0.0.1:39372 127.0.0.1:8080
CLOSE_WAIT 13336/apache2 <br>
tcp 1 0 127.0.0.1:37259 127.0.0.1:8080
CLOSE_WAIT 13337/apache2 <br>
tcp 1 0 127.0.0.1:37269 127.0.0.1:8080
CLOSE_WAIT 13337/apache2 <br>
tcp 1 0 127.0.0.1:37227 127.0.0.1:8080
CLOSE_WAIT 13336/apache2 <br>
tcp 1 0 127.0.0.1:33772 127.0.0.1:8080
CLOSE_WAIT 13336/apache2 <br>
tcp 0 0 127.0.0.1:39207 127.0.0.1:8080
CLOSE_WAIT 13336/apache2 <br>
tcp 0 0 127.0.0.1:39202 127.0.0.1:8080
CLOSE_WAIT 13337/apache2 <br>
tcp 0 0 127.0.0.1:8080 127.0.0.1:39527
FIN_WAIT2 - <br>
<br>
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 <br>
/etc/init.d/waptserver stop <br>
python /opt/wapt/waptserver/waptserver.py <br>
<br>
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à? <br>
<br>
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...
<br>
<br>
Cordialement, <br>
<br>
Denis Cardon <br>
<br>
<br>
<blockquote type="cite"> <br>
<br>
<br>
<br>
<br>
Cordialement, Latieule Joël - TICE / Collège Jules Ferry de
Narbonne <br>
<br>
Le 29/05/2015 17:13, Denis Cardon a écrit : <br>
<blockquote type="cite">Bonjour, <br>
<br>
<blockquote type="cite">Je constate que chaque matin mon
serveur WAPT est en panne et je doit <br>
relancer la machine pour que tout refonctionne. J'ai
installé WAPT sur <br>
une débian et la console de gestion ou <br>
la page http du serveur ne répond plus. Voici l'erreur
que je <br>
rencontre : <br>
<br>
<br>
Service Unavailable <br>
<br>
The server is temporarily unable to service your request
due to <br>
maintenance downtime or capacity problems. Please try
again later. <br>
<br>
------------------------------------------------------------------------
<br>
Apache/2.4.10 (Debian) Server at 10.111.15.2 Port 80 <br>
</blockquote>
<br>
le message indique que le serveur Apache n'arrive pas à
récupérer une <br>
réponse du serveur uwsgi-python. C'est un peu succinct
pour <br>
diagnostiquer un problème... Histoire de ne pas avoir à
jouer à madame <br>
soleil, il faudrait avoir quelques informations
complémentaires : <br>
<br>
combien de RAM avec vous sur cette machine? Est ce qu'il y
a d'autres <br>
choses services qui tournent en parallèle? Est ce qu'il y
a des <br>
oomkiller dans la sortie de dmesg? Est ce qu'il y a des
process uwsgi <br>
qui tourne encore quand le serveur ne répond plus? Est ce
que process <br>
mongodb est toujours là? Quelle est la version du serveur
wapt <br>
installé? Est ce qu'il y a des messages pertinents dans le
fichier de <br>
log /var/log/waptserver.log? etc. <br>
<br>
Cordialement, <br>
<br>
Denis Cardon <br>
<br>
<blockquote type="cite"> <br>
<br>
<br>
<br>
_______________________________________________ <br>
WAPT mailing list <br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:WAPT@lists.tranquil.it">WAPT@lists.tranquil.it</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.tranquil.it/listinfo/wapt">http://lists.tranquil.it/listinfo/wapt</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
WAPT mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:WAPT@lists.tranquil.it">WAPT@lists.tranquil.it</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.tranquil.it/listinfo/wapt">http://lists.tranquil.it/listinfo/wapt</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
WAPT mailing list
<a class="moz-txt-link-abbreviated" href="mailto:WAPT@lists.tranquil.it">WAPT@lists.tranquil.it</a>
<a class="moz-txt-link-freetext" href="http://lists.tranquil.it/listinfo/wapt">http://lists.tranquil.it/listinfo/wapt</a>
</pre>
</blockquote>
<br>
</body>
</html>