Hi!
Seit den letzten zwei 5.5er Updates stürzt mein Webfront 3-4 am Tag ab und ich verliere natürlich dann auch die Verbindungen mit IPSView. Ich bringe es dann nur durch deinen Neustarts des Symcon Diensts am Raspberry wieder ans Laufen.
In welchem Log kann ich rausfinden warum das passiert?
Am besten wäre es, wenn du dies hier startest: Debugging für Experten (Docker)
Denn es klingt so, als wenn der Dienst komplett Abstürzt. Nutzt du ggf. Streams bei dir im WebFront oder IPSView? Dort gibt es noch einen bekannten Absturz-Bug den ich suche.
paresy
Hi Paresy!
Danke erstmal für deine Antwort. Ja, ich habe zwei mjpeg Streams laufen und ich hatte einen rtsp. Diesen habe ich allerdings wieder deaktiviert weil ich ihn eh schon im Verdacht hatte.
Ich habe nun das Debug gdb am Laufen. Was muss ich nach dem nächsten Absturz machen?
Sobald er passiert im gdb Prompt „bt“ eintippen und mit Enter bestätigen. Danach mir die vollständige Aushabe hier einfügen.
paresy
So, jetzt ist es passiert. Der Symcon Dienst läuft noch, Webfront geht aber nicht mehr auf. IPS View Client am PC hat diesen Fehler gebracht:
Output gdb, ich hoffe das stimmt so:
(gdb) bt
#0 0x76d14704 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1 0x009c70dc in asio::detail::epoll_reactor::run(long, asio::detail::op_queue<asio::detail::scheduler_operation>&) ()
#2 0x0100fef8 in asio::detail::scheduler::do_run_one(asio::detail::conditionally_enabled_mutex::scoped_lock&, asio::detail::scheduler_thread_info&, std::error_code const&) ()
#3 0x0101025c in asio::detail::scheduler::run(std::error_code&) ()
#4 0x004917e4 in main ()
(gdb)
Ich mache jetzt wieder einen Symcon Service Restart, dann wirds wieder normal laufen.
Hm. War GDB in diesem Fall schon im Prompt? Oder hattest du CTRL+C drücken müssen? (Denn wenn ein Absturz passiert wäre, würde dort meisten was für Segmentation Fault oder ähnliches stehen müssen?)
Könntest du dann noch diese Teil von hier ausführen: https://www.symcon.de/forum/threads/27061-Debugging-für-Experten-(Raspberry-Pi-Linux-SymBox)
set logging on
thread apply all bt
set logging off
Evtl. verhakt sich bei dir der WebServer nur irgendwie und der Rest vom System läuft noch?
Nutzt du den neuen WebClient vom IPSStudio Professional neuerdings?
paresy
Hi Paresy!
Also es ist wirklich so das IPS weiterläuft und sich primär der Webserver ins Eck stellt. Das ist aber nicht immer so, IPS fiel auch schon komplett aus. Es scheint als würde es immer ziemlich genau alle 8-10h passieren. Ich konnte nun in ein Textfile loggen, schau es dir mal an ob da da war rausfinden kannst.
File liegt hier https://cloud.pesalnet.at/s/9dS8ZGweo6RzX2d
Alternativ kann ich dir auch mal Zugriff via SSH auf meinen Raspi einrichten, dann kannst du dir das gerne mal selber ansehen.
Hi Paresy!
Ich glaube ich habe etwas rausgefunden. Scheinbar stürzt der Webserver nur dann ab, wenn ich den IPSView Beta Client am iPad verwende. Nicht sofort, aber nach einiger Zeit. Ich habe den Client jetzt wieder auf die Stable Version umgestellt bzw. gar nicht verbunden, seitdem läuft alles ohne Absturz.
Am PC verwende ich übrigens auch den IPSView Beta Client, der dürfte aber keine Probleme verursachen!
Ah, dann passt dies zu einem Problem, welches mit bereits @seppm gemeldet hat. Da bin ich noch dran.
paresy
Okay, du gibst Bescheid wenn es gelöst ist?
Ja, bütte. Wär super wenn sich das löst!
Kannst auch gern wieder auf meine Maschine @paresy
Find das so top mit der Integration des IPS View ins Webfront.
Danke und Gruß
Sepp
Gesendet von iPhone mit Tapatalk
Wann kann man hier eigentlich mit einer Lösung rechnen? Dauert das länger? Ich kann praktisch IPS View in der Küche am iPad nicht mehr nutzen, da sonst regelmäßig der Server abstürzt. Blöderweise ist das DIE zentrale Stelle von wo aus alles bedient wird. Der WAF ist aktuell total im Keller 
Ich erwäge sonst direkt wieder einen Umstieg auf das Webfront und designe das mal durch damit ich hier wieder eine Funktion habe ohne Abstürze.
Hi hofimax,
aktuell tritt der Fehler beim sepp nicht mehr mehr auf und ich konnte ihn bei mir nicht nachstellen 
Könntest du den Fehler bei dir provozieren und mir einen GDB Stacktrace zuschicken wie hier beschrieben? Debugging für Experten (Raspberry Pi, Linux, SymBox)
Es reicht, wenn du es ohne Debugger laufen lässt und sobald das Problem da ist Option B ausführst.
paresy
Sorry für meine späte Antwort!
Konntest du das mit dem Log das ich dir hier am 25.12. gepostet habe noch nicht analysieren?
Ich stells sonst gerne nochmal nach!
Oh, das habe ich scheinbar komplett übersehen. Leider geht der Link nicht mehr. Könntest du dies noch einmal nachstellen?
paresy
Hattest du bei dem Trace das „thread apply all bt“ direkt am Anfang ausgeführt oder erst, wenn das Problem wirklich existent war? Denn ich kann dort aktuell kein Problem erkennen.
paresy
Irgendwas hatte ich da vermutlich falsch gemacht. Ich probiere das jetzt nochmal nachzustellen und melde mich dann wieder.
Dann hier nochmal ein Versuch. Wenn du wieder nichts findest, mache ich sicher mit gdb etwas falsch.
Ja, das sieht leider so aus. :rolleyes:
Magst du sonst - wenn das Problem wieder da ist - einfach kurz bei uns anrufen?
Du brauchst den Debugger nicht zu starten - ich attache ihn quasi erst dann, wenn der Fehlerfall da ist.
paresy