WaptServer stürzt unter Debian unerwartet ab
Veröffentlicht: 21. März 2017 - 09:33 Uhr
Hallo zusammen,
Ich teste Wapt nun seit etwa einer Woche auf einer Debian-VM, die ich kürzlich eigens dafür installiert habe. Alles funktioniert einwandfrei, aber der Wapt-Server stoppt immer wieder unerwartet und ich muss ihn mit `/etc/init.d/waptserver restart` (oder `/etc/waptserver start`) neu starten.
Ich habe die Protokolldatei überprüft, aber sie enthielt nicht viele Informationen. Ich habe das Protokoll am Ende dieses Beitrags angehängt. Ich musste den Dienst um 7:35 Uhr und dann erneut um 8:11 Uhr neu starten. Manchmal funktioniert alles den ganzen Tag über einwandfrei und stoppt dann abends. Manchmal muss ich den Dienst auch dreimal im Laufe des Tages neu starten (wenn ich bemerke, dass er nicht mehr läuft; ich nutze ihn nicht ständig). Ich habe die Energiespareinstellungen überprüft und deaktiviert. Ich habe die VM mehrmals neu gestartet, um dies zu überprüfen, aber es hat sich nichts geändert. Der Dienst startet korrekt mit der Maschine und stoppt dann nach einer Weile.
Ich gebe zu, dass meine Linux-Kenntnisse eher begrenzt sind und ich daher nicht weiß, wo ich die Ursache für den Prozessabbruch finden kann. Hat jemand eine Idee, wo ich suchen könnte?
Zur Information: Die VM verfügt über 2 Kerne, 1 GB RAM und 80 GB Festplattenspeicher. Ich denke, das reicht aus, um die Verteilung auf 30-35 Client-Workstations zu gewährleisten (derzeit sind nur 15 Workstations angeschlossen)
Vielen Dank im Voraus für Ihre Hilfe.
Ich teste Wapt nun seit etwa einer Woche auf einer Debian-VM, die ich kürzlich eigens dafür installiert habe. Alles funktioniert einwandfrei, aber der Wapt-Server stoppt immer wieder unerwartet und ich muss ihn mit `/etc/init.d/waptserver restart` (oder `/etc/waptserver start`) neu starten.
Ich habe die Protokolldatei überprüft, aber sie enthielt nicht viele Informationen. Ich habe das Protokoll am Ende dieses Beitrags angehängt. Ich musste den Dienst um 7:35 Uhr und dann erneut um 8:11 Uhr neu starten. Manchmal funktioniert alles den ganzen Tag über einwandfrei und stoppt dann abends. Manchmal muss ich den Dienst auch dreimal im Laufe des Tages neu starten (wenn ich bemerke, dass er nicht mehr läuft; ich nutze ihn nicht ständig). Ich habe die Energiespareinstellungen überprüft und deaktiviert. Ich habe die VM mehrmals neu gestartet, um dies zu überprüfen, aber es hat sich nichts geändert. Der Dienst startet korrekt mit der Maschine und stoppt dann nach einer Weile.
Ich gebe zu, dass meine Linux-Kenntnisse eher begrenzt sind und ich daher nicht weiß, wo ich die Ursache für den Prozessabbruch finden kann. Hat jemand eine Idee, wo ich suchen könnte?
Zur Information: Die VM verfügt über 2 Kerne, 1 GB RAM und 80 GB Festplattenspeicher. Ich denke, das reicht aus, um die Verteilung auf 30-35 Client-Workstations zu gewährleisten (derzeit sind nur 15 Workstations angeschlossen)
Vielen Dank im Voraus für Ihre Hilfe.
Code: Alle auswählen
*** 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)
, da Sie sonst Ihren neuen öffentlichen Schlüssel auf all Ihren Rechnern erneut bereitstellen müssen!