WaptServer crashes unexpectedly on Debian
Published: March 21, 2017 - 09:33
Hello everyone,
I've been testing Wapt for about a week now using a Debian VM I recently installed for this purpose. Everything works perfectly, but the Wapt server keeps stopping unexpectedly, and I have to restart it using /etc/init.d/waptserver restart (or start).
I checked the log file, but there wasn't much information. I've included the log at the end of this post. I had to restart the service at 7:35 AM and then again at 8:11 AM. Sometimes everything works fine for the day and then stops in the evening. Other times, I have to restart the service three times during the day (when I realize it's stopped running; I'm not constantly using it). I checked the sleep settings and disabled them. I restarted the VM several times to verify, but there was no change. The service starts correctly with the machine and then stops after a while.
I admit to having rather limited knowledge of Linux to know how to find the cause of the process stopping, does anyone have any idea where to look?
As additional information, the VM has 2 cores, 1GB of RAM and 80GB of HDD, I think that's enough to ensure distribution across 30-35 client workstations (currently only 15 workstations connected)?
Thank you in advance for your help.
I've been testing Wapt for about a week now using a Debian VM I recently installed for this purpose. Everything works perfectly, but the Wapt server keeps stopping unexpectedly, and I have to restart it using /etc/init.d/waptserver restart (or start).
I checked the log file, but there wasn't much information. I've included the log at the end of this post. I had to restart the service at 7:35 AM and then again at 8:11 AM. Sometimes everything works fine for the day and then stops in the evening. Other times, I have to restart the service three times during the day (when I realize it's stopped running; I'm not constantly using it). I checked the sleep settings and disabled them. I restarted the VM several times to verify, but there was no change. The service starts correctly with the machine and then stops after a while.
I admit to having rather limited knowledge of Linux to know how to find the cause of the process stopping, does anyone have any idea where to look?
As additional information, the VM has 2 cores, 1GB of RAM and 80GB of HDD, I think that's enough to ensure distribution across 30-35 client workstations (currently only 15 workstations connected)?
Thank you in advance for your help.
Code: Select all
*** 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)
, otherwise you will have to redeploy your new public key on all your machines!