IP-Symcon auf Raspi 3B+ sporadische Abstürze auch bei V5.3

Wenn es das wäre, würde es reichen wenn du die I/O Instanz deaktivierst - denn dann sollte das Modul in dem Sinne „aus“ sein.

paresy

Danke.
Habe ich jetzt mal gemacht, mal sehen, was sich in nächster Zeit tut.

Gesendet von iPad mit Tapatalk

Schade, das war es auch nicht. Heute Nacht um 00:36 gab es den nächsten Crash.
Nun läuft der Debugger wieder.
Wenn ich das richtig gesehen habe, dann läuft Symcon bei Option A: IP-Symcon direkt über den Debugger starten, nicht als Service. Vielleicht ist deshalb nichts mehr abgestürzt, als ich diese getestet habe?
Habe nun Option B gewählt.
Ergebnisse folgen, wenn verfügbar

Es ist zum verzweifeln.
Ja, Symcon hat seinen Betrieb letzte Nacht wieder eingestellt (und wieder, richtig pünktlich, um 00:34).
Ja, der Debugger ist zu diesem Zeitpunkt gelaufen (Option B).
Und nein, es lassen sich keine Ergebnisse abrufen.
Smycon ist nicht „richtig“ abgestürzt, der Service lief noch jedoch war keinerlei Zugriff (z.B. über Konsole, FTP, SSH) auf Symcon mehr möglich.
[…]
[New Thread 0x8a7f8980 (LWP 31760)]
[Thread 0x8a7f8980 (LWP 31760) exited]
[New Thread 0x8a7f8980 (LWP 31853)]
[Thread 0x8a7f8980 (LWP 31853) exited]
[New Thread 0x8a7f8980 (LWP 31943)]
Jedoch kamen nach dieser Ausgabe einfach keine weiteren.
Und: der Debugger wurde nicht gestoppt und liess sich mit ^C Q nicht abbrechen und somit auch nicht zum gdb.txt-Erzeugen überreden.
Auch wurde kein Crashlog von Symcon angelegt.
Ich habe das Ganze nun noch einmal mit Option A gestartet und hoffe, dass sich vielleicht diesmal etwas ergibt. Übergens tauchen die im Forum angegebenen 2 SIGILL Fehler NICHT auf (trotz Rapsberry PI).

Ich verstehe nicht ganz wie man auf IP-Symcon per FTP/SSH zugreifen kann!? Kann es sein, dass dein ganzer Pi die Grätsche macht?

paresy

Moin,
ich muss hier mal ein paar Erfahrungswerte mit meinen Raspberrys los werden …
Die bei mir laufenden Himbeeren laufen alle klaglos, aber ich hatte (bevor ich die Soundausgabe auf Alexa verlegt habe) den mplayer mit installiert (im Vorführkoffer ist der auch noch aktiv). Bei diesen Systemen (mit „Zusatzsoftware“) muss ich nach einem Symcon-Update auch immer einen Reboot auslösen, erst dann ist Console und WebFront wieder erreichbar, obwohl es auch vorher (mit htop) als aktiv und laufend angezeigt wird. Wenn ich „nur“ die LCN-PCHK mit drauf habe geht das Update übrigens auch ohne reboot.

Vielleicht hilft’s ja …
Grüße, Uwe

Ich habe die Erfahrung gemacht, dass die Raspberrys am wenigsten Probleme machen wenn da nur IPS drauf läuft und ordentliche Speicherkarten bzw SSDs versendet werden.

Das war so natürlich Unsinn, dass ist mir vorhin auch schonm aufgefallen. Ich hatte beim Schreiben den Kopf wohl zu voll :o
FTP und SSH ist Quatsch. Nicht mehr erreichbar ist Symcon für die Konsole und meine IPS-View Clients (vermutlich auch das Webfront, nutze ich aber nicht).
Der „Rest“ des PI ist weiterhin gut per SSH und FTP erreichbar und die ebenfalls darauf laufende debmatic CCU versieht sehr zuverlässig ihren Dienst

Auch das werde ich mal testen.
Merkwürdigerweise lief die ganze Geschicht bei mir viele Monate klaglos, bis etwa Februar diesen Jahres.
Ich nutze Sandisk extreme 64GB SSDs, mit denen ich bisher gute Erfahrungen gemacht habe.

Und jetzt reichen meine Kenntnisse nicht mehr :confused:
ETS?
Und was würde ein Unterschied der Uhrzeit zwischen ETS und DCF bewirken?
Meine Uhrzeit wird vom PI geliefert, der sie stündlich von einem Zeitserver holt. Timezone ist dabei Berlin.

Hallo,

bei meiner IPS Installation PI war immer wieder durch Strom-Versorgung verursachte (unter voltage) die Ursache das System binarys und auch die symcon Binary selbst beschädigt wurden.

Ein neues setup und wiederherstellen der Sicherung hat für einige Monate geholfen.

Aktuell bin ich seit drei Monaten auf einen Ubuntu lxc Container und bis jetzt keinerlei solcher Probleme mehr.

Gesendet von meinem Mi 9T Pro mit Tapatalk

Vergiss meinen Beitrag oben. Der sollte in ein anderes Thema :slight_smile:

paresy

Ah, verstehe :slight_smile:

Ich habe übrigens mal etwas getestet.
Symcon ist vom PI4 auf einen PI3B umgezogen und lief als einziges PRogramm dort.
Auf den PI4 kam Raspberrrymatic.
Dann habe ich die vorher erstellten Backups von Symcon und debmatic jeweils eingespielt.
Was soll ich sagen? Es hat keine Stunde gedauert, da ist Symcon wieder ausgestiegen.

Smycon ist nicht „richtig“ abgestürzt, der Service lief noch jedoch war keinerlei Zugriff (z.B. über Konsole, FTP, SSH) auf Symcon mehr möglich.

(Gefühlt) genau das habe ich auf meinem Pi3 jetzt in den letzten ca. 5 Monaten zwei Mal gehabt.

Bei mir sah es dann so aus (Notizen aus der Erinnerung):
das im Log viele Socketfehler erscheinen aber offensichtlich keine oder nur sehr wenige Scripte verarbeitet werden,
die WFE werden nicht mehr aktualisiert;
IPS View zeigt an, dass die Verbindung zu IPS gestört ist,
der Pi per SSH und HTOP Symcon-Prozesse als „laufend“ anzeigt,
das Symcon beenden über sudo service symcon stop nicht mehr möglich ist (auch nach ewig warten nicht).
der Speicherverbrauch steigt vorher nicht an,

Ich hatte dann den Eindruck, dass IPS super zäh läuft …

Das erstemal war das die ganze Nacht so, bis ich es morgens merkte (IPS lief noch -zäh-).
Das zweitemal habe ich es Abends zufällig bemerkt als es grade vor 3 Min. passierte.

Erst ein sudo reboot löst das Problem SOFORT vollständig.

Bei mir sind aber die Abstände so groß, dass ich es nicht auf die Goldwaage legen will.
Aber irgend etwas passiert da…

Auf dem Pi läuft nur IPS (immer Beta)

Gruß
lueralba

Seit knapp 10 Jahren lief mein IP-Symcon V3.4 auf WIN7 Mini PC. Abstürze, ich sage mal keine.
Vor knapp 2 Jahren begann ich nun auf Raspi3+ umzuziehen. Die Script’s wurden im wesentlichen mit „copy und paste“ übernommen und nur die ID’s ersetzt.

Nach meinem 1. Beitrag in diesem Thema habe ich alles untersucht was nicht einer normalen Funktion von IP-Symcon entspricht.
Ich habe jeden Tag die Log’s kontrolliert und versucht alle Warnungen zu beseitigen.
Zuerst aber den Spezialschalter „LogfileVerbose“ deaktiviert, weil mein Logfile teilweise 240 MB angenommen hatte. Jetzt sind es nur noch max. ca. 16 MB.

Den nächsten Erfolg hatte ich nach dem ich unter Spezialschalter „Thread Count“ die Zahl angepasst habe.
Dazu bin ich auf Experten Ansicht - PHP-Informationen und habe die Füllung der Liste kontrolliert. Bei 10 -> 30 waren immer mal alle Zeilen gefüllt, also keine leere Zeile mehr, erst bei 40 blieben einige Zeilen immer leer.

Seit dem waren die Einträge im Log wegen: „failed to open stream: Zu viele offene Dateien“ um 99% reduziert.

Danach habe ich mich nach und nach allen Script Warnungen angenommen. Dabei musste ich feststellen, dass die Änderungen der PHP Versionen teilweise dafür verantwortlich sind. Beispiel: „A non-numeric value encountered“ uä.

Seit dem sind in der letzten Woche keine Abstürze mehr aufgetreten, obwohl bei mir 5 Server laufen die ständig Daten wie Strom, Gas, Heizungs-Temperaturen, Wemos-Solar-Daten, 2 Kameras, Wemos-Bewegungsmelder, paresys rpc mit 60 Variablen aller 10 sec. aktualisieren.

Zur Zeit konnte ich nur ein Problem im Log noch nicht klären:

33049__ 09.04.2020 07:48:13 | 22324 | MESSAGE | Server Socket | Einstellungen gespeichert
33050__ 9.04.2020 07:48:13 | 22324 | MESSAGE | Server Socket | Schließe Client Verbindung…
…………………. weitere 900 gleichartige Einträge mit der gleichen Zeit ….
33963__ 09.04.2020 07:48:13 | 22324 | MESSAGE | Server Socket | Schließe Client Verbindung…

Ich frage mich allerdings wann ich den Punkt erreiche, wo ich so viele Transaktionen habe das Symcon überläuft.
Und welche Sicherheit hat man bei Absturz, das IP-Symcon wieder richtig startet z.B. ala Homematic CCU1

tom2005