Sorry, hab ich nicht probiert da ich mit IPSStudio visualisiere … und die Views können dann auch nicht mehr Connecten, entsprechende Meldung wird auf den Tabletts angezeigt.
Würden euch Log Files helfen?
Es passiert definitiv wenn das HM Device nach ein oder Umschalten der Pumpe durch das Hochlaufen der Leistungswerte ordentlich Werte sendet (wobei im im HM Device schon auf einmal pro Sekunde eingeschränkt habe)
Gruß Michael
Ich denke das Problem dank @syncmaster gefunden zu haben. Ich baue gerade einen RC3, der später kommt und das Problem hoffentlich löst.
paresy
Installiert … dann hoffen und beobachten wir mal
Sorry, hängt wieder
Bei mir ist die Lage wesentlich besser. Gestern hatte ich noch 3 Hänger alleine am Morgen. Seit dem Update läuft alles wieder wie am Schnürchen und in gewohnter Zuverlässigkeit.
@paresy Vielen Dank für Deine Hilfe und die schnelle Bereitstellung des Fixes!
Gruß Dirk
Du bist auf dem Pi unterwegs oder? Magst du Variante B dir geführten wenn das Problem wieder kommt? Debugging für Experten (Raspberry Pi, Linux, SymBox)
Und mir dann die GDB.TXT per PM schicken?
paresy
OK, Debugging gestartet …warten wir auf das Problem …
Hallo @micserver ,
ich bin da jetzt kein Fachmann. Wie ich aber verstanden habe ist es so, dass Du erst auf das Problem wartest. Wenn es dann da ist startest Du das Tool, dann kommt die Meldung, das irgend ein File nicht gefunden worden ist, Du drückst c + ENTER und lässt das Tool dann solange laufen bist das Tool automatisch stoppt und die Fehlerzeile ausgibt. Danach machst Du den Part mit dem Schreiben in den Textfile, den Du dann parsey als pm bereit stellst.
Das muss so nicht richtig sein - aber vielleicht doch ;).
Gruss Dirk
Nachträglich editiert und ergänzt:
Siehe dazu auch den Post von parsey hier
Das ist so nicht richtig, du startest den Debugger und darin Symcon, das hat micserver schon korrekt beschrieben ;-).
…seitdem der Debugger im Hintergrund lauert läuft alles einwandfrei… abwarten
Gruß Michael
Deswegen macht es manchmal Sinn IPS ohne Debugger zu starten. Und wenn das Problem da ist die Option B aus dem genannten Thema zu nutzen Mit Debugger passieren solch kuriose Fehler manchmal gar nicht oder viel seltener.
@syncmaster Deine Aussage ist somit nicht verkehrt. Ich hatte dir das quasi auch so versucht zu erklären
paresy
OK, das hatte ich tatsächlich anders verstanden … Debugger ist jetzt gestoppt, IPS service gestopped und neu gestartet …warten wir weiter…
Gruß Michael
So, Systemn ‚steht‘ wieder…
sudo service samcon status
Unit samcon.service could not be found.
pi@raspi-4-1:~ $ sudo service symcon status
● symcon.service - LSB: Kurze Beschreibung
Loaded: loaded (/etc/init.d/symcon; generated)
Active: active (exited) since Sat 2021-07-17 19:39:02 CEST; 1 day 2h ago
Docs: man:systemd-sysv-generator(8)
Process: 6987 ExecStart=/etc/init.d/symcon start (code=exited, status=0/SUCCESS)
Jul 17 19:39:01 raspi-4-1 systemd[1]: Starting LSB: Kurze Beschreibung…
Jul 17 19:39:02 raspi-4-1 symcon[6987]: IP-Symcon started with PID 6993
Jul 17 19:39:02 raspi-4-1 systemd[1]: Started LSB: Kurze Beschreibung.
Die PID ist also 6993 ???
sudo gdb --pid 6993
GNU gdb (Raspbian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type „show copying“ and „show warranty“ for details.
This GDB was configured as „arm-linux-gnueabihf“.
Type „show configuration“ for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type „help“.
Type „apropos word“ to search for commands related to „word“.
Attaching to process 6993
ptrace: Kein passender Prozess gefunden.
Also ist es nicht die PID ? Wie bekomme ich die raus?
sudo ps x | grep symcon bringt keine Ergebnis
… ???
Ich vermute laut der Zeile sollte es aktuell die 6987 sein. ein „pidof symcon“ sollte dir auch die korrekte Nummer verraten.
paresy
mit der 6987 hat der Debuggger auch nichts anfangen können, in htop konnte ich IPS auch nicht mehr ausmachen => wahrscheinlich hatte es das Zeitliche komplett gesegnet. Logfile wäre verfügbar)
Normalerweise ist die pid bei mir 3-stellig.
Wie dem auch sei, habe gestern neu gestartet (reboot) und mal direkt die pid (508) notiert … hoffen wir auf das nächste Vorkommen.
Gruß, Michael
So, gerade eben war wieder Schluss:
Der Prozess war einst mit PID 508 gestartet …die PID gibt es jetzt nicht mehr …
Komischerweise sagt der Service er sei aktiv:
Bleibt nur ein reboot … Ideen?
Gruß Michael
Steht da sonst, wenn er aktiv läuft, auch ein active (exited)?
Es wirkt so, als wenn er bei dir nicht hängen bleibt, wie bei den anderen, sondern wirklich abstürzt. D.h. deine erste Variante mit direkt über GDB starten wird besser sein. Also starte es über sudo gdb symcon
und dann ist wichtig, dass die SSH Session aktiv bleibt.
Kannst du mal dmesg
eintippen? Kommt da was mit OOM?
paresy
active exited steht immer dann wenn nach einem Reboot gestartet wurde. Eben habe ich den Dienst gestoppt (obwohl er keine PID mehr hatte), habe sudo apt update und uograde gemacht …Symcon ist wieder angelaufen.
Aktuell zeigt der Status:
…aber symcon läuft einwandfrei …
Output demeg folgt per PM