Accès serveur apache souvent en rade
Bonsoir, 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
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@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
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 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/ 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@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
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@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@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
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@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@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@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@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
Bonjour, Avez vous des informations complémentaire concernant mon problème ? Autrement je pensai faire une tache pour redémarrer le serveur wapt chaque matin 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 ? 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@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@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@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@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
Le 09/06/2015 13:11, Latieule Joel a écrit :
Bonjour,
Avez vous des informations complémentaire concernant mon problème ? Autrement je pensai faire une tache pour redémarrer le serveur wapt chaque matin
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 ?
En gros, sauvegarder /var/www (pour les paquets wapt, et la config des postes wapt-host) et /var/lib/mongodb Sur votre nouveau serveur, faire la post-install puis remettre ces 2 répertoires. Par ailleurs, évidemment toujours bien garder en lieu sûr votre clé de signature privée .pem
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@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@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@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@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
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@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@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@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@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
-- Yann DAVID AED TICE Collège Joseph Delteil - Limoux
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. 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@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@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@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@lists.tranquil.it > http://lists.tranquil.it/listinfo/wapt >
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
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@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@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@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@lists.tranquil.it >> http://lists.tranquil.it/listinfo/wapt >> >
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@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
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@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@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@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@lists.tranquil.it >>> http://lists.tranquil.it/listinfo/wapt >>> >> >
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
Bonjour 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. 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@lists.tranquil.it] De la part de Latieule Joel Envoyé : lundi 22 juin 2015 21:47 À : Denis Cardon; wapt@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@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@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@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@lists.tranquil.it >>> http://lists.tranquil.it/listinfo/wapt >>> >> >
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
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@lists.tranquil.it] De la part de Latieule Joel Envoyé : lundi 22 juin 2015 21:47 À : Denis Cardon; wapt@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@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@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@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@lists.tranquil.it >>>> http://lists.tranquil.it/listinfo/wapt >>>> >>> >> >
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@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
Nop juste openssh ... -----Message d'origine----- De : Denis Cardon [mailto:denis.cardon@tranquil-it-systems.fr] Envoyé : mardi 23 juin 2015 15:55 À : LEMAIRE Philippe; Latieule Joel; wapt@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@lists.tranquil.it] De la part de Latieule Joel Envoyé : lundi 22 juin 2015 21:47 À : Denis Cardon; wapt@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@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@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@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@lists.tranquil.it >>>> http://lists.tranquil.it/listinfo/wapt >>>> >>> >> >
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@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
Bonjour la liste, une autre piste : tous les matins, le waptserver est relancé afin de procéder à la rotation des journaux. Dans le fichier /etc/init.d/waptserver, ligne 69, il y a ceci : local timeout=70 # 7 seconds loop Vous pouvez essayer de la modifier pour augmenter ce timeout, par exemple : local timeout=150 # 15 seconds loop Attention à la syntaxe et aux espaces. Pas sûr du tout que ce soit la cause réelle, que nous souhaiterions vraiment connaître, mais c'est une piste supplémentaire. HTH, -- Jérémie Courrèges-Anglas - Tranquil IT Systems http://www.tranquil-it-systems.fr - http://dev.tranquil.it
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@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@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@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@lists.tranquil.it >>>> http://lists.tranquil.it/listinfo/wapt >>>> >>> >> >
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
_______________________________________________ WAPT mailing list WAPT@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
Bonjour, Trop nul.. j’envoie ma réponse à Denis Cardon au lieu de la liste J'ai eu un problème similaire , c’était un manque de ram (256Mo) dans mon cas le passage à 512 a solutionné le problème Cordialement, Olivier LE GRAND Le 29/05/2015 16:37, Latieule Joel a écrit :
Bonsoir,
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
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
-- *Olivier LE GRAND | Administrateur réseaux* *Groupe Sacré Cœur* 2 rue Millet BP 90129 49101 ANGERS Cedex 02 Tél : 0241814206 olegrand@gsc49.com <mailto:olegrand@gsc49.com>
participants (7)
-
Denis Cardon -
Hubert TOUVET -
Jérémie Courrèges-Anglas -
Latieule Joel -
LEMAIRE Philippe -
Olivier Le Grand -
Yann DAVID