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

_______________________________________________
WAPT mailing list
WAPT@lists.tranquil.it
http://lists.tranquil.it/listinfo/wapt