WaptServer se bloquea inesperadamente en Debian
Publicado: 21 de marzo de 2017 - 09:33
Hola a todos,
Llevo una semana probando Wapt con una máquina virtual Debian que instalé recientemente. Todo funciona perfectamente, pero el servidor Wapt se detiene inesperadamente y tengo que reiniciarlo usando /etc/init.d/waptserver restart (o start).
Revisé el archivo de registro, pero no había mucha información. Incluyo el registro al final de esta publicación. Tuve que reiniciar el servicio a las 7:35 y luego a las 8:11. A veces todo funciona correctamente durante el día y luego se detiene por la noche. Otras veces, tengo que reiniciar el servicio tres veces durante el día (cuando me doy cuenta de que ha dejado de funcionar; no lo uso constantemente). Revisé la configuración de suspensión y la desactivé. Reinicié la máquina virtual varias veces para verificar, pero no hubo cambios. El servicio se inicia correctamente con la máquina y se detiene al cabo de un rato.
Admito que tengo conocimientos bastante limitados de Linux para saber cómo encontrar la causa de la detención del proceso, ¿alguien tiene alguna idea de dónde buscar?
Como información adicional, la VM tiene 2 núcleos, 1 GB de RAM y 80 GB de HDD, creo que es suficiente para garantizar la distribución entre 30-35 estaciones de trabajo cliente (actualmente solo hay 15 estaciones de trabajo conectadas)
Gracias de antemano por su ayuda.
Llevo una semana probando Wapt con una máquina virtual Debian que instalé recientemente. Todo funciona perfectamente, pero el servidor Wapt se detiene inesperadamente y tengo que reiniciarlo usando /etc/init.d/waptserver restart (o start).
Revisé el archivo de registro, pero no había mucha información. Incluyo el registro al final de esta publicación. Tuve que reiniciar el servicio a las 7:35 y luego a las 8:11. A veces todo funciona correctamente durante el día y luego se detiene por la noche. Otras veces, tengo que reiniciar el servicio tres veces durante el día (cuando me doy cuenta de que ha dejado de funcionar; no lo uso constantemente). Revisé la configuración de suspensión y la desactivé. Reinicié la máquina virtual varias veces para verificar, pero no hubo cambios. El servicio se inicia correctamente con la máquina y se detiene al cabo de un rato.
Admito que tengo conocimientos bastante limitados de Linux para saber cómo encontrar la causa de la detención del proceso, ¿alguien tiene alguna idea de dónde buscar?
Como información adicional, la VM tiene 2 núcleos, 1 GB de RAM y 80 GB de HDD, creo que es suficiente para garantizar la distribución entre 30-35 estaciones de trabajo cliente (actualmente solo hay 15 estaciones de trabajo conectadas)
Gracias de antemano por su ayuda.
Código: Seleccionar todo
*** Starting uWSGI 2.0.7-debian (64bit) on [Tue Mar 21 07:35:06 2017] ***
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.39-1+deb8u2 (2017-03-07)
nodename: serveur-wapt
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 2
current working directory: /
writing pidfile to /var/run/waptserver.pid
detected binary path: /usr/bin/uwsgi-core
setgid() to 33
setuid() to 117
your processes number limit is 3908
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, Jun 29 2016, 13:11:10) [GCC 4.9.2]
Python main interpreter initialized at 0xb4e6d0
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 3 seconds on interpreter 0xb4e6d0 pid: 21354 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 21354)
spawned uWSGI worker 1 (pid: 21379, cores: 1)
spawned uWSGI worker 2 (pid: 21380, cores: 1)
spawned uWSGI worker 3 (pid: 21381, cores: 1)
spawned uWSGI worker 4 (pid: 21382, cores: 1)
spawned uWSGI worker 5 (pid: 21383, cores: 1)
spawned uWSGI worker 6 (pid: 21384, cores: 1)
spawned uWSGI worker 7 (pid: 21385, cores: 1)
spawned uWSGI worker 8 (pid: 21386, cores: 1)
spawned uWSGI worker 9 (pid: 21387, cores: 1)
spawned uWSGI worker 10 (pid: 21388, cores: 1)
spawned uWSGI worker 11 (pid: 21389, cores: 1)
spawned uWSGI worker 12 (pid: 21390, cores: 1)
spawned uWSGI worker 13 (pid: 21391, cores: 1)
spawned uWSGI worker 14 (pid: 21392, cores: 1)
spawned uWSGI worker 15 (pid: 21393, cores: 1)
spawned uWSGI worker 16 (pid: 21394, cores: 1)
*** Starting uWSGI 2.0.7-debian (64bit) on [Tue Mar 21 08:11:00 2017] ***
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.39-1+deb8u2 (2017-03-07)
nodename: serveur-wapt
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 2
current working directory: /home/fabien
writing pidfile to /var/run/waptserver.pid
detected binary path: /usr/bin/uwsgi-core
setgid() to 33
setuid() to 117
your processes number limit is 3908
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, Jun 29 2016, 13:11:10) [GCC 4.9.2]
Python main interpreter initialized at 0x2596440
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 1 seconds on interpreter 0x2596440 pid: 21504 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 21504)
spawned uWSGI worker 1 (pid: 21509, cores: 1)
spawned uWSGI worker 2 (pid: 21510, cores: 1)
spawned uWSGI worker 3 (pid: 21511, cores: 1)
spawned uWSGI worker 4 (pid: 21512, cores: 1)
spawned uWSGI worker 5 (pid: 21513, cores: 1)
spawned uWSGI worker 6 (pid: 21514, cores: 1)
spawned uWSGI worker 7 (pid: 21515, cores: 1)
spawned uWSGI worker 8 (pid: 21516, cores: 1)
spawned uWSGI worker 9 (pid: 21517, cores: 1)
spawned uWSGI worker 10 (pid: 21518, cores: 1)
spawned uWSGI worker 11 (pid: 21519, cores: 1)
spawned uWSGI worker 12 (pid: 21520, cores: 1)
spawned uWSGI worker 13 (pid: 21521, cores: 1)
spawned uWSGI worker 14 (pid: 21522, cores: 1)
spawned uWSGI worker 15 (pid: 21523, cores: 1)
spawned uWSGI worker 16 (pid: 21524, cores: 1)
, de lo contrario tendrás que volver a implementar tu nueva clave pública en todas tus máquinas.