[Wapt] Accès serveur apache souvent en rade

LEMAIRE Philippe lemaire.philippe at lfay.com.vn
Tue Jun 23 10:56:45 CEST 2015


Nop juste openssh ...

-----Message d'origine-----
De : Denis Cardon [mailto:denis.cardon at tranquil-it-systems.fr] 
Envoyé : mardi 23 juin 2015 15:55
À : LEMAIRE Philippe; Latieule Joel; wapt at lists.tranquil.it
Objet : Re: [Wapt] Accès serveur apache souvent en rade

Bonjour Philippe,

> Je ne suis pas certain que le problème vienne de là.
> Mon installation est toute neuve (Ubuntu server 14.04 sur VM, 4Go de Ram ) et ne sert qu'à Wapt.

en fait la question est : est ce qu'il y a un bureau graphique installée sur cette machine (même si il n'est pas utilisé) ? Si il y a des outils qui font de la gestion d'énergie (qui viennent avec le desktop) ça peut poser des problèmes.

Cordialement,

Denis Cardon

> Et comme toi j'ai le même problème de déconnexion du serveur Wapt. Il faut que je fasse régulièrement un "service waptserveur restart" pour reprendre la main...
> Je n'ai pas encore eu le temps d'approfondir mes recherches, si quelqu'un a une piste ...
>
> Cordialement
> Philippe
>
> -----Message d'origine-----
> De : WAPT [mailto:wapt-bounces at lists.tranquil.it] De la part de 
> Latieule Joel Envoyé : lundi 22 juin 2015 21:47 À : Denis Cardon; 
> wapt at lists.tranquil.it Objet : Re: [Wapt] Accès serveur apache souvent 
> en rade
>
> Bonjour,
>
>
> 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?
>
> 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 fd 3// //Python version: 2.7.9 
>>>>>> (default, Mar  1 2015, 13:01:26) [GCC 4.9.2]// //Python main 
>>>>>> interpreter initialized at 0x1cb06d0// //python threads support 
>>>>>> enabled// //your server socket listen backlog is limited to 100 
>>>>>> connections// //your mercy for graceful operations on workers is
>>>>>> 60 seconds// //mapped 1237056 bytes (1208 KB) for 16 cores//
>>>>>> //*** Operational MODE: preforking ***// //WSGI app 0
>>>>>> (mountpoint='') ready in 0 seconds on interpreter
>>>>>> 0x1cb06d0 pid: 5068 (default app)//
>>>>>> //*** uWSGI is running in multiple interpreter mode ***// 
>>>>>> //spawned uWSGI master process (pid: 5068)// //spawned uWSGI 
>>>>>> worker 1 (pid: 5090, cores: 1)// //spawned uWSGI worker 2 (pid:
>>>>>> 5091, cores: 1)// //spawned uWSGI worker 3 (pid: 5092, cores: 
>>>>>> 1)// //spawned uWSGI worker 4 (pid: 5093, cores: 1)// //spawned 
>>>>>> uWSGI worker 5 (pid: 5094, cores: 1)// //spawned uWSGI worker 6 (pid:
>>>>>> 5095, cores: 1)// //spawned uWSGI worker 7 (pid: 5096, cores: 
>>>>>> 1)// //spawned uWSGI worker 8 (pid: 5097, cores: 1)// //spawned 
>>>>>> uWSGI worker 9 (pid: 5098, cores: 1)// //spawned uWSGI worker 10 (pid:
>>>>>> 5099, cores: 1)// //spawned uWSGI worker 11 (pid: 5100, cores:
>>>>>> 1)// //spawned uWSGI worker 12 (pid: 5101, cores: 1)// //spawned 
>>>>>> uWSGI worker 13 (pid: 5102, cores: 1)// //spawned uWSGI worker 14
>>>>>> (pid: 5103, cores: 1)// //spawned uWSGI worker 15 (pid: 5104,
>>>>>> cores: 1)// //spawned uWSGI worker 16 (pid: 5105, cores: 1)// 
>>>>>> //...brutally killing workers.../
>>>>>> /*** Starting uWSGI 2.0.7-debian (64bit) on [Tue Jun  2 08:41:02 
>>>>>> 2015] *** compiled with version: 4.9.1 on 25 October 2014 
>>>>>> 19:17:54
>>>>>> os: Linux-3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
>>>>>> (2015-04-24)
>>>>>> nodename: srv-omv
>>>>>> machine: x86_64
>>>>>> clock source: unix
>>>>>> pcre jit disabled
>>>>>> detected number of CPU cores: 4
>>>>>> current working directory: /home/administrateur writing pidfile 
>>>>>> to /var/run/waptserver.pid detected binary path: 
>>>>>> /usr/bin/uwsgi-core
>>>>>> setgid() to 33
>>>>>> setuid() to 118
>>>>>> your processes number limit is 31835 your memory page size is 
>>>>>> 4096 bytes detected max file descriptor number: 65536 lock engine:
>>>>>> pthread robust mutexes thunder lock: disabled (you can enable it 
>>>>>> with --thunder-lock) uwsgi socket 0 bound to TCP address
>>>>>> 127.0.0.1:8080 fd 3 Python version: 2.7.9 (default, Mar  1 2015,
>>>>>> 13:01:26) [GCC 4.9.2] Python main interpreter initialized at
>>>>>> 0xe4de90 python threads support enabled your server socket listen 
>>>>>> backlog is limited to 100 connections your mercy for graceful 
>>>>>> operations on workers is 60 seconds mapped 1237056 bytes (1208 
>>>>>> KB) for 16 cores
>>>>>> *** Operational MODE: preforking *** WSGI app 0 (mountpoint='') 
>>>>>> ready in 0 seconds on interpreter 0xe4de90
>>>>>> pid: 5185 (default app)
>>>>>> *** uWSGI is running in multiple interpreter mode *** spawned 
>>>>>> uWSGI master process (pid: 5185) spawned uWSGI worker 1 (pid:
>>>>>> 5190, cores: 1) spawned uWSGI worker 2 (pid: 5191, cores: 1) 
>>>>>> spawned uWSGI worker 3 (pid: 5192, cores: 1) spawned uWSGI worker
>>>>>> 4 (pid: 5193, cores: 1) spawned uWSGI worker 5 (pid: 5194, cores:
>>>>>> 1) spawned uWSGI worker 6 (pid: 5195, cores: 1) spawned uWSGI 
>>>>>> worker 7 (pid: 5196, cores: 1) spawned uWSGI worker 8 (pid: 5197,
>>>>>> cores: 1) spawned uWSGI worker 9 (pid: 5198, cores: 1) spawned 
>>>>>> uWSGI worker 10 (pid: 5199, cores: 1) spawned uWSGI worker 11
>>>>>> (pid: 5200, cores: 1) spawned uWSGI worker 12 (pid: 5201, cores:
>>>>>> 1) spawned uWSGI worker 13 (pid: 5202, cores: 1) spawned uWSGI 
>>>>>> worker 14 (pid: 5203, cores: 1) spawned uWSGI worker 15 (pid:
>>>>>> 5204, cores: 1) spawned uWSGI worker 16 (pid: 5205, cores: 1) 
>>>>>> invalid HTTP request size (max 4096)...skip
>>>>>> [pid: 5204|app: 0|req: 1/1] 127.0.0.1 () {38 vars in 567 bytes} 
>>>>>> [Tue Jun  2 08:42:15 2015] GET / => generated 6888 bytes in 458 
>>>>>> msecs
>>>>>> (HTTP/1.1 200) 2 heade$
>>>>>> [pid: 5204|app: 0|req: 2/2] 127.0.0.1 () {44 vars in 765 bytes} 
>>>>>> [Tue Jun  2 08:42:15 2015] GET 
>>>>>> /static/themes/tranquilit/style.css
>>>>>> => generated 8443 bytes i$
>>>>>> [pid: 5198|app: 0|req: 1/3] 127.0.0.1 () {44 vars in 811 bytes} 
>>>>>> [Tue Jun  2 08:42:15 2015] GET 
>>>>>> /static/themes/tranquilit/img/logo-tis.jpg
>>>>>> => generated 0 byt$
>>>>>> [pid: 5204|app: 0|req: 3/4] 127.0.0.1 () {44 vars in 808 bytes} 
>>>>>> [Tue Jun  2 08:42:15 2015] GET 
>>>>>> /static/themes/tranquilit/img/contact.jpg => generated 0 byte$
>>>>>> [pid: 5193|app: 0|req: 1/5] 127.0.0.1 () {44 vars in 776 bytes} 
>>>>>> [Tue Jun  2 08:42:15 2015] GET 
>>>>>> /static/themes/tranquilit/css/screen.css => generated 12613 b$
>>>>>> [pid: 5198|app: 0|req: 2/6] 127.0.0.1 () {44 vars in 776 bytes} 
>>>>>> [Tue Jun  2 08:42:15 2015] GET 
>>>>>> /static/themes/tranquilit/css/buttons.css => generated 2104 b$
>>>>>> [pid: 5196|app: 0|req: 1/7] 127.0.0.1 () {44 vars in 800 bytes} 
>>>>>> [Tue Jun  2 08:42:16 2015] GET 
>>>>>> /static/themes/tranquilit/img/bgd.png => generated 0 bytes in$ 
>>>>>> SIGINT/SIGQUIT received...killing workers...
>>>>>> worker 1 buried after 1 seconds
>>>>>> worker 2 buried after 1 seconds
>>>>>> worker 3 buried after 1 seconds
>>>>>> worker 4 buried after 1 seconds
>>>>>> worker 5 buried after 1 seconds
>>>>>> worker 6 buried after 1 seconds
>>>>>> worker 7 buried after 1 seconds
>>>>>> worker 8 buried after 1 seconds
>>>>>> worker 9 buried after 1 seconds
>>>>>> worker 10 buried after 1 seconds
>>>>>> worker 11 buried after 1 seconds
>>>>>> worker 11 buried after 1 seconds
>>>>>> worker 12 buried after 1 seconds
>>>>>> worker 13 buried after 1 seconds
>>>>>> worker 14 buried after 1 seconds
>>>>>> worker 15 buried after 1 seconds
>>>>>> worker 16 buried after 1 seconds
>>>>>> goodbye to uWSGI.
>>>>>> *** Starting uWSGI 2.0.7-debian (64bit) on [Tue Jun  2 08:45:21 
>>>>>> 2015] *** compiled with version: 4.9.1 on 25 October 2014 
>>>>>> 19:17:54
>>>>>> os: Linux-3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
>>>>>> (2015-04-24)
>>>>>> nodename: srv-omv
>>>>>> machine: x86_64
>>>>>> clock source: unix
>>>>>> pcre jit disabled
>>>>>> detected number of CPU cores: 4
>>>>>> current working directory: /home/administrateur writing pidfile 
>>>>>> to /var/run/waptserver.pid detected binary path: 
>>>>>> /usr/bin/uwsgi-core
>>>>>> setgid() to 33
>>>>>> setuid() to 118
>>>>>> your processes number limit is 31835 your memory page size is 
>>>>>> 4096 bytes detected max file descriptor number: 65536 lock engine:
>>>>>> pthread robust mutexes thunder lock: disabled (you can enable it 
>>>>>> with --thunder-lock) uwsgi socket 0 bound to TCP address
>>>>>> 127.0.0.1:8080 fd 3 Python version: 2.7.9 (default, Mar  1 2015,
>>>>>> 13:01:26) [GCC 4.9.2] Python main interpreter initialized at
>>>>>> 0x970e90 python threads support enabled your server socket listen 
>>>>>> backlog is limited to 100 connections your mercy for graceful 
>>>>>> operations on workers is 60 seconds mapped 1237056 bytes (1208 
>>>>>> KB) for 16 cores
>>>>>> *** Operational MODE: preforking *** WSGI app 0 (mountpoint='') 
>>>>>> ready in 0 seconds on interpreter 0x970e90
>>>>>> pid: 5291 (default app)
>>>>>> *** uWSGI is running in multiple interpreter mode *** spawned 
>>>>>> uWSGI master process (pid: 5291) spawned uWSGI worker 1 (pid:
>>>>>> 5296, cores: 1) spawned uWSGI worker 2 (pid: 5297, cores: 1) 
>>>>>> spawned uWSGI worker 3 (pid: 5298, cores: 1) spawned uWSGI worker
>>>>>> 4 (pid: 5299, cores: 1) spawned uWSGI worker 5 (pid: 5300, cores:
>>>>>> 1) spawned uWSGI worker 6 (pid: 5301, cores: 1) spawned uWSGI 
>>>>>> worker 7 (pid: 5302, cores: 1) spawned uWSGI worker 8 (pid: 5303,
>>>>>> cores: 1) spawned uWSGI worker 9 (pid: 5304, cores: 1) spawned 
>>>>>> uWSGI worker 10 (pid: 5305, cores: 1) spawned uWSGI worker 11
>>>>>> (pid: 5306, cores: 1) spawned uWSGI worker 12 (pid: 5307, cores:
>>>>>> 1) spawned uWSGI worker 13 (pid: 5308, cores: 1) spawned uWSGI 
>>>>>> worker 14 (pid: 5309, cores: 1) spawned uWSGI worker 15 (pid:
>>>>>> 5310, cores: 1) spawned uWSGI worker 16 (pid: 5311, cores: 1) 
>>>>>> invalid HTTP request size (max 4096)...skip
>>>>>> [pid: 5299|app: 0|req: 1/1] 127.0.0.1 () {38 vars in 512 bytes} 
>>>>>> [Tue Jun  2 08:50:00 2015] GET /Packages => generated 233 bytes 
>>>>>> in
>>>>>> 4 msecs
>>>>>> (HTTP/1.1 404) 2 $
>>>>>> [pid: 5299|app: 0|req: 2/2] 127.0.0.1 () {38 vars in 512 bytes} 
>>>>>> [Tue Jun  2 08:50:00 2015] GET /Packages => generated 233 bytes 
>>>>>> in
>>>>>> 0 msecs
>>>>>> (HTTP/1.1 404) 2 $
>>>>>> [pid: 5299|app: 0|req: 3/3] 127.0.0.1 () {38 vars in 497 bytes} 
>>>>>> [Tue Jun  2 08:50:00 2015] HEAD / => generated 0 bytes in 421 
>>>>>> msecs
>>>>>> (HTTP/1.1 200) 2 headers$
>>>>>> [pid: 5299|app: 0|req: 4/4] 127.0.0.1 () {38 vars in 497 bytes} 
>>>>>> [Tue Jun  2 08:50:03 2015] HEAD / => generated 0 bytes in 420 
>>>>>> msecs
>>>>>> (HTTP/1.1 200) 2 headers$
>>>>>> [pid: 5299|app: 0|req: 5/5] 127.0.0.1 () {44 vars in 617 bytes} 
>>>>>> [Tue Jun  2 08:50:03 2015] POST /update_host => generated 1240 
>>>>>> bytes in 19 msecs (HTTP/1.1 2$
>>>>>> [pid: 5310|app: 0|req: 1/6] 127.0.0.1 () {38 vars in 511 bytes} 
>>>>>> [Tue Jun  2 08:50:17 2015] GET /Packages => generated 233 bytes 
>>>>>> in
>>>>>> 4 msecs
>>>>>> (HTTP/1.1 404) 2 $
>>>>>> [pid: 5310|app: 0|req: 2/7] 127.0.0.1 () {38 vars in 511 bytes} 
>>>>>> [Tue Jun  2 08:50:17 2015] GET /Packages => generated 233 bytes 
>>>>>> in
>>>>>> 0 msecs
>>>>>> (HTTP/1.1 404) 2 $
>>>>>> [pid: 5311|app: 0|req: 1/8] 127.0.0.1 () {38 vars in 496 bytes} 
>>>>>> [Tue Jun  2 08:50:18 2015] HEAD / => generated 0 bytes in 429 
>>>>>> msecs
>>>>>> (HTTP/1.1 200) 2 headers$
>>>>>> [pid: 5310|app: 0|req: 3/9] 127.0.0.1 () {38 vars in 496 bytes} 
>>>>>> [Tue Jun  2 08:50:18 2015] HEAD / => generated 0 bytes in 428 
>>>>>> msecs
>>>>>> (HTTP/1.1 200) 2 headers$
>>>>>> [pid: 5310|app: 0|req: 4/10] 127.0.0.1 () {44 vars in 616 bytes} 
>>>>>> [Tue Jun  2 08:50:19 2015] POST /update_host => generated 1249 
>>>>>> bytes in 30 msecs (HTTP/1.1 $
>>>>>> [pid: 5310|app: 0|req: 5/11] 127.0.0.1 () {38 vars in 511 bytes} 
>>>>>> [Tue Jun  2 08:50:22 2015] GET /Packages => generated 233 bytes 
>>>>>> in
>>>>>> 0 msecs
>>>>>> (HTTP/1.1 404) 2$
>>>>>> [pid: 5310|app: 0|req: 6/12] 127.0.0.1 () {38 vars in 511 bytes} 
>>>>>> [Tue Jun  2 08:50:29 2015] GET /Packages => generated 233 bytes 
>>>>>> in
>>>>>> 0 msecs
>>>>>> (HTTP/1.1 404) 2$
>>>>>> [pid: 5309|app: 0|req: 1/13] 127.0.0.1 () {38 vars in 511 bytes} 
>>>>>> [Tue Jun  2 08:50:41 2015] GET /Packages => generated 233 bytes 
>>>>>> in
>>>>>> 4 msecs
>>>>>> (HTTP/1.1 404) 2$
>>>>>> [pid: 5299|app: 0|req: 6/14] 127.0.0.1 () {38 vars in 496 bytes} 
>>>>>> [Tue Jun  2 08:52:20 2015] HEAD / => generated 0 bytes in 388 
>>>>>> msecs
>>>>>> (HTTP/1.1 200) 2 header$
>>>>>> [pid: 5299|app: 0|req: 7/15] 127.0.0.1 () {38 vars in 496 bytes} 
>>>>>> [Tue Jun  2 08:52:20 2015] HEAD / => generated 0 bytes in 431 
>>>>>> msecs
>>>>>> (HTTP/1.1 200) 2 header$
>>>>>> [pid: 5299|app: 0|req: 8/16] 127.0.0.1 () {38 vars in 496 bytes} 
>>>>>> [Tue Jun  2 08:52:24 2015] HEAD / => generated 0 bytes in 413 
>>>>>> msecs
>>>>>> (HTTP/1.1 200) 2 header$
>>>>>> [pid: 5299|app: 0|req: 9/17] 127.0.0.1 () {44 vars in 616 bytes} 
>>>>>> [Tue Jun  2 08:52:25 2015] POST /update_host => generated 1264 
>>>>>> bytes in 30 msecs (HTTP/1.1 $
>>>>>> [pid: 5311|app: 0|req: 2/18] 127.0.0.1 () {38 vars in 511 bytes} 
>>>>>> [Tue Jun  2 08:52:35 2015] GET /Packages => generated 233 bytes 
>>>>>> in
>>>>>> 1 msecs
>>>>>> (HTTP/1.1 404) 2$
>>>>>> [pid: 5311|app: 0|req: 3/19] 127.0.0.1 () {38 vars in 511 bytes} 
>>>>>> [Tue Jun  2 08:52:36 2015] GET /Packages => generated 233 bytes 
>>>>>> in
>>>>>> 0 msecs
>>>>>> (HTTP/1.1 404) 2$
>>>>>> [pid: 5311|app: 0|req: 4/20] 127.0.0.1 () {38 vars in 496 bytes} 
>>>>>> [Tue Jun  2 08:52:36 2015] HEAD / => generated 0 bytes in 426 
>>>>>> msecs
>>>>>> (HTTP/1.1 200) 2 header$
>>>>>> [pid: 5311|app: 0|req: 5/21] 127.0.0.1 () {38 vars in 496 bytes} 
>>>>>> [Tue Jun  2 08:52:36 2015] HEAD / => generated 0 bytes in 392 
>>>>>> msecs
>>>>>> (HTTP/1.1 200) 2 header$
>>>>>> [pid: 5311|app: 0|req: 6/22] 127.0.0.1 () {44 vars in 616 bytes} 
>>>>>> [Tue Jun  2 08:52:37 2015] POST /update_host => generated 1264 
>>>>>> bytes in 27 msecs (HTTP/1.1 $/
>>>>>>
>>>>>> Cordialement, Latieule Joël - TICE / Collège Jules Ferry de 
>>>>>> Narbonne Le 01/06/2015 17:28, Denis Cardon a écrit :
>>>>>>> Bonjour Joël,
>>>>>>>
>>>>>>>> Je suis en train de tester Wapt sur un serveur tout neuf et à 
>>>>>>>> par le système et ses mise à jour, strictement aucuns services 
>>>>>>>> ou applications n'ont été ajouté (sauf Wapt). Voici quelques 
>>>>>>>> informations que je peut trouver :
>>>>>>>>
>>>>>>>>    * Système : Debian 8.0 "Jessie"
>>>>>>>>    * RAM : 8 Go
>>>>>>>>    * Processeur : Intel Xeon / 3,8 Ghz quatre cœur
>>>>>>>>    * WAPT : 1.2.3
>>>>>>>
>>>>>>> merci beaucoup pour ces détails. En effet, je pense que l'on 
>>>>>>> peut écarter le problème lié à la RAM... On a déjà eu ce soucis 
>>>>>>> qui avait été remonté sur la mailing list avec des serveurs à 
>>>>>>> 256Mo de RAM, je voulais donc être sûr. Normalement ça devrait 
>>>>>>> pouvoir tourner très bien sur une machine avec 1Go de RAM.
>>>>>>>
>>>>>>> Le développement se fait actuellement sur la version Debian 
>>>>>>> Jessie, donc on teste régulièrement wapt sur cette version. 
>>>>>>> Après c'est vrai que l'on a principalement des déploiements en 
>>>>>>> production sous Wheezy, la Jessie étant sortie que très 
>>>>>>> récemment.
>>>>>>>
>>>>>>>> Pour obtenir les autres informations, quelle commande ou quel 
>>>>>>>> fichiers doit je ouvrir ?
>>>>>>>>
>>>>>>>>
>>>>>>>> Ici le détail du fichier */var/log/waptserver.log* /
>>>>>>>> *** Starting uWSGI 2.0.7-debian (64bit) on [Mon Jun  1 07:35:03
>>>>>>> 2015] ***
>>>>>>>> compiled with version: 4.9.1 on 25 October 2014 19:17:54
>>>>>>>> os: Linux-3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
>>>>>>> (2015-04-24)
>>>>>>>> nodename: srv-omv
>>>>>>>> machine: x86_64
>>>>>>>> clock source: unix
>>>>>>>> pcre jit disabled
>>>>>>>> detected number of CPU cores: 4 current working directory: / 
>>>>>>>> writing pidfile to /var/run/waptserver.pid detected binary
>>>>>>>> path: /usr/bin/uwsgi-core
>>>>>>>> setgid() to 33
>>>>>>>> setuid() to 118
>>>>>>>> your processes number limit is 31835 your memory page size is
>>>>>>>> 4096 bytes detected max file descriptor number: 1024 lock
>>>>>>>> engine: pthread robust mutexes thunder lock: disabled (you can 
>>>>>>>> enable it with --thunder-lock) uwsgi socket 0 bound to TCP 
>>>>>>>> address 127.0.0.1:8080 fd 3/
>>>>>>>
>>>>>>> le log ne nous dit rien d'intéressant à part que le serveur à 
>>>>>>> bien démarré... Est ce qu'il n'y a pas d'autre choses après? Est 
>>>>>>> ce qu'il ne va pas jusqu'à :
>>>>>>>   ...
>>>>>>>   spawned uWSGI worker 15 (pid: 13581, cores: 1)  spawned uWSGI 
>>>>>>> worker 16 (pid: 13582, cores: 1)
>>>>>>>   [pid: 13582|app: 0|req: 1/1] 127.0.0.1 () {38 vars in 529 
>>>>>>> bytes} [Mon Jun  1 07:07:23 2015] GET /Packages => generated 233 
>>>>>>> bytes in
>>>>>>> 5342 msecs (HTTP/1.1 404) 2 headers in 72 bytes (1 switches on 
>>>>>>> core 0)
>>>>>>>
>>>>>>> Est ce que vous pourriez vérifier dans ce fichier waptserver.log 
>>>>>>> au moment du problème d'accès si il y a des stack trace avec des 
>>>>>>> exceptions python?
>>>>>>>
>>>>>>> Quand vous avez à relancer le serveur, est ce que vous avez tous 
>>>>>>> les processus présents :
>>>>>>> * 1 process /usr/bin/mongod --config /etc/mongodb.conf
>>>>>>> * 16 process /usr/bin/uwsgi-core -d /var/log/waptserver.log 
>>>>>>> --pidfile /var/run/waptserver.pid --ini 
>>>>>>> /opt/wapt/waptserver/waptserver.ini
>>>>>>> --uid wapt --gid www-data --plugin http,python
>>>>>>>
>>>>>>> Est ce que vous pourriez vérifier la mémoire au moment du problème :
>>>>>>>   free -m
>>>>>>>
>>>>>>> Juste pour vérifier, est ce qu'il y a suffisamment d'espace 
>>>>>>> disque (le mongodb a tendance à consommer plusieurs centaines de 
>>>>>>> Mo d'espace disque)?
>>>>>>>   df -h
>>>>>>>
>>>>>>> Lors du prochain problème, est ce que vous pourriez essayer de 
>>>>>>> relancer d'abord le serveur wapt plutôt que de relancer toute la 
>>>>>>> machine pour voir si ça résoud le problème.
>>>>>>>   /etc/init.d/waptserver restart
>>>>>>>
>>>>>>> Après vous pouvez vous reconnecter à l'adresse (il faudra 
>>>>>>> éventuellement le relancer deux fois la requête http pour 
>>>>>>> ré-initialiser le pool de connexion du ProxyPassReverse)
>>>>>>> http://10.111.15.2
>>>>>>>
>>>>>>> Lors du blocage du serveur python, est ce que vous pourriez 
>>>>>>> vérifier si il y a toujours des connexions en cours, par exemple :
>>>>>>>
>>>>>>> [root at srvwapt.tranq mongodb]# netstat -tapn | grep 8080
>>>>>>> tcp        0      0 127.0.0.1:8080          0.0.0.0:* LISTEN
>>>>>>> 5762/uwsgi-core
>>>>>>> tcp        0      0 127.0.0.1:8080 127.0.0.1:39525
>>>>>>> TIME_WAIT   -
>>>>>>> tcp        1      0 127.0.0.1:39527 127.0.0.1:8080
>>>>>>> CLOSE_WAIT  13336/apache2
>>>>>>> tcp        0      0 127.0.0.1:8080 127.0.0.1:39526
>>>>>>> TIME_WAIT   -
>>>>>>> tcp        1      0 127.0.0.1:34114 127.0.0.1:8080
>>>>>>> CLOSE_WAIT  13337/apache2
>>>>>>> tcp        1      0 127.0.0.1:39372 127.0.0.1:8080
>>>>>>> CLOSE_WAIT  13336/apache2
>>>>>>> tcp        1      0 127.0.0.1:37259 127.0.0.1:8080
>>>>>>> CLOSE_WAIT  13337/apache2
>>>>>>> tcp        1      0 127.0.0.1:37269 127.0.0.1:8080
>>>>>>> CLOSE_WAIT  13337/apache2
>>>>>>> tcp        1      0 127.0.0.1:37227 127.0.0.1:8080
>>>>>>> CLOSE_WAIT  13336/apache2
>>>>>>> tcp        1      0 127.0.0.1:33772 127.0.0.1:8080
>>>>>>> CLOSE_WAIT  13336/apache2
>>>>>>> tcp        0      0 127.0.0.1:39207 127.0.0.1:8080
>>>>>>> CLOSE_WAIT  13336/apache2
>>>>>>> tcp        0      0 127.0.0.1:39202 127.0.0.1:8080
>>>>>>> CLOSE_WAIT  13337/apache2
>>>>>>> tcp        0      0 127.0.0.1:8080 127.0.0.1:39527
>>>>>>> FIN_WAIT2   -
>>>>>>>
>>>>>>> Pour voir si c'est un soucis avec le wrapper uwsgi, vous pouvez 
>>>>>>> aussi essayer de lancer le serveur python sans uwsgi avec les 
>>>>>>> commandes  /etc/init.d/waptserver stop  python 
>>>>>>> /opt/wapt/waptserver/waptserver.py
>>>>>>>
>>>>>>> Pour écarter des problèmes systèmes, est ce que vous pourriez 
>>>>>>> vérifier avec la commande dmesg si il n'y aurai pas quelque 
>>>>>>> chose d'intéressant de ce côté là?
>>>>>>>
>>>>>>> J'ai jeté un coup d'oeil au logrotate du serveur wapt (le 
>>>>>>> process qui fait tourner les logs pour éviter qu'ils deviennent 
>>>>>>> trop gros). Il lance un redémarrage après la rotation des log à 
>>>>>>> 6h du matin.
>>>>>>> Donc si
>>>>>>> vous n'avez que ce que vous mentionner dans le fichier de log, 
>>>>>>> c'est que c'est tout ce qu'il y avait après le restart du uwsgi 
>>>>>>> par le logrotate...
>>>>>>>
>>>>>>> Cordialement,
>>>>>>>
>>>>>>> Denis Cardon
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Cordialement, Latieule Joël - TICE / Collège Jules Ferry de 
>>>>>>>> Narbonne
>>>>>>>>
>>>>>>>> Le 29/05/2015 17:13, Denis Cardon a écrit :
>>>>>>>>> Bonjour,
>>>>>>>>>
>>>>>>>>>> Je constate que chaque matin mon serveur WAPT est en panne et 
>>>>>>>>>> je doit relancer la machine pour que tout refonctionne. J'ai 
>>>>>>>>>> installé WAPT sur une débian et la console de gestion ou la 
>>>>>>>>>> page http du serveur ne répond plus. Voici l'erreur que je 
>>>>>>>>>> rencontre :
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    Service Unavailable
>>>>>>>>>>
>>>>>>>>>> The server is temporarily unable to service your request due 
>>>>>>>>>> to maintenance downtime or capacity problems. Please try 
>>>>>>>>>> again later.
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> ----------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Apache/2.4.10 (Debian) Server at 10.111.15.2 Port 80
>>>>>>>>>
>>>>>>>>> le message indique que le serveur Apache n'arrive pas à 
>>>>>>>>> récupérer une réponse du serveur uwsgi-python. C'est un peu 
>>>>>>>>> succinct pour diagnostiquer un problème... Histoire de ne pas 
>>>>>>>>> avoir à jouer à madame soleil, il faudrait avoir quelques 
>>>>>>>>> informations complémentaires :
>>>>>>>>>
>>>>>>>>> combien de RAM avec vous sur cette machine? Est ce qu'il y a 
>>>>>>>>> d'autres choses services qui tournent en parallèle? Est ce 
>>>>>>>>> qu'il y a des oomkiller dans la sortie de dmesg? Est ce qu'il 
>>>>>>>>> y a des process uwsgi qui tourne encore quand le serveur ne 
>>>>>>>>> répond plus? Est ce que process mongodb est toujours là? 
>>>>>>>>> Quelle est la version du serveur wapt installé? Est ce qu'il y 
>>>>>>>>> a des messages pertinents dans le fichier de log 
>>>>>>>>> /var/log/waptserver.log? etc.
>>>>>>>>>
>>>>>>>>> Cordialement,
>>>>>>>>>
>>>>>>>>> Denis Cardon
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> WAPT mailing list
>>>>>>>>>> WAPT at lists.tranquil.it
>>>>>>>>>> http://lists.tranquil.it/listinfo/wapt
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> WAPT mailing list
>>>>>> WAPT at lists.tranquil.it
>>>>>> http://lists.tranquil.it/listinfo/wapt
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> WAPT mailing list
>>>>> WAPT at lists.tranquil.it
>>>>> http://lists.tranquil.it/listinfo/wapt
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> WAPT mailing list
>>> WAPT at lists.tranquil.it
>>> http://lists.tranquil.it/listinfo/wapt
>>
>
> _______________________________________________
> WAPT mailing list
> WAPT at lists.tranquil.it
> http://lists.tranquil.it/listinfo/wapt
>

--
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
http://www.tranquil-it-systems.fr



More information about the WAPT mailing list