Bonjour à tous,
Je suis confronté à ce même problème. J’ai une VM Debian avec un bureau (MATE).
Je vais donc réinstaller une VM sans bureau graphique, étant donné que cela semble résoudre le problème.
Cordialement,
Nathanaël HANNEBERT Services Généraux
[LOGOTHUND]
Cabinet LEFEUVRE 2 rue de Rieux 44018 NANTES Cedex 1
Maintenance : 02.51.72.94.73 Ligne interne : 473 Ligne directe : 02.23.44.25.74
www.lefeuvre-immobilier.comhttp://www.lefeuvre-immobilier.com/
[Wapt] Accès serveur apache souvent en rade [RESOLU] Latieule Joel joel.latieule at ac-montpellier.fr mailto:wapt%40lists.tranquil.it?Subject=Re%3A%20%5BWapt%5D%0A%20%3D%3Futf-8%3Fq%3FAcc%3DC3%3DA8s_serveur_apache_souvent_en_rade_%3D5BRES%3F%3D%0A%20%3D%3Futf-8%3Fq%3FOLU%3D5D%3F%3D&In-Reply-To=%3C55962679.3040309%40ac-montpellier.fr%3E Fri Jul 3 08:06:49 CEST 2015
* Previous message: [Wapt] Deploiment groupe de paquet Grp ActiveDirectory http://lists.tranquil.it/pipermail/wapt/2015-July/001068.html * Next message: [Wapt] Unable to get host http://lists.tranquil.it/pipermail/wapt/2015-July/001059.html * Messages sorted by: [ date ]http://lists.tranquil.it/pipermail/wapt/2015-July/date.html#1058 [ thread ]http://lists.tranquil.it/pipermail/wapt/2015-July/thread.html#1058 [ subject ]http://lists.tranquil.it/pipermail/wapt/2015-July/subject.html#1058 [ author ]http://lists.tranquil.it/pipermail/wapt/2015-July/author.html#1058
________________________________
Bonjour,
Après avoir supprimé tous les desktop le problème persistait. J'ai
refait une installation neuve sans aucun gestionnaire de bureau et
depuis ce problème est résolu. D'autres problèmes viennent d'apparaitre
mais je vais ouvrir un autre sujet.
Merci à tous pour vos réponses
Cordialement, Latieule Joël - TICE / Collège Jules Ferry de Narbonne
Le 30/06/2015 13:54, Latieule Joel a écrit :
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.ithttp://lists.tranquil.it/listinfo/wapt 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.frhttp://lists.tranquil.it/listinfo/wapt
<mailto:denis.cardon at tranquil-it-systems.frhttp://lists.tranquil.it/listinfo/wapt>> 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-debia...
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<http://lists.tranquil.it/listinfo/wapt>:/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<http://lists.tranquil.it/listinfo/wapt>:/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<http://lists.tranquil.it/listinfo/wapt> 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.ithttp://lists.tranquil.it/listinfo/wapt
<mailto:WAPT at lists.tranquil.ithttp://lists.tranquil.it/listinfo/wapt>
WAPT mailing list
WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt>
<mailto:WAPT at lists.tranquil.ithttp://lists.tranquil.it/listinfo/wapt>
WAPT mailing list
WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt>
<mailto:WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt>>
http://lists.tranquil.it/listinfo/wapt
WAPT mailing list
WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt> <mailto:WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt>>
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<http://lists.tranquil.it/listinfo/wapt> <mailto:WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt>>
http://lists.tranquil.it/listinfo/wapt
WAPT mailing list
WAPT at lists.tranquil.ithttp://lists.tranquil.it/listinfo/wapt
________________________________
* Previous message: [Wapt] Deploiment groupe de paquet Grp ActiveDirectory http://lists.tranquil.it/pipermail/wapt/2015-July/001068.html * Next message: [Wapt] Unable to get host http://lists.tranquil.it/pipermail/wapt/2015-July/001059.html * Messages sorted by: [ date ]http://lists.tranquil.it/pipermail/wapt/2015-July/date.html#1058 [ thread ]http://lists.tranquil.it/pipermail/wapt/2015-July/thread.html#1058 [ subject ]http://lists.tranquil.it/pipermail/wapt/2015-July/subject.html#1058 [ author ]http://lists.tranquil.it/pipermail/wapt/2015-July/author.html#1058
________________________________ More information about the WAPT mailing listhttp://lists.tranquil.it/listinfo/wapt