IP-Symcon unter Linux macht seit einigen Tagen Problem

Hallo,

wollte mal kurz zu meinen Erfahrungen / Beobachtungen meines IP-S unter Linux berichten.

Seit einigen Tagen, denke ca 1 - 2 Wochen macht mein IP-S Problem beim Neustart des Linux-System nach Updates, aber auch bei den nächtlichen Backups, wenn ich vorher IP-S stoppe.

IP-S fährt nicht runter, ich muss das System ( Ubuntu 22.x als Linux-Container auf Proxmox ) immer über den Proxmox-Server hat rebooten.
Gerade wenn nachts Backups laufen sollten, läuft IP-S morgen dann nicht mehr, weils es immer noch im „runterfahren“ hängt.

Den Grund dafür hab ich bisher noch nicht gefunden, was ich allesdings gemacht habe ist:

  • Archive aufräumen, Daten von nicht mehr vorhandene Variablen gelöscht
  • Etliche Jobs rausgeworfen, zb. die ganzen „pings“ zu meinen Systemen, da diese eine hohe DNS-Last verursachen
  • Logfiles durchsucht aber keinerlei Fehlermeldung zu den jeweiligen Zeiten zu finden.
  • Auto-Updates deaktiviert, die mache ich jetzt manuell, aber dann tritt das auch auf
  • beim Backupjob temp. den IP-S stopp rausgenommen, so das nur die Files weggeschrieben werden.

Hat jemand ähnlich Beobachtungen macht ?

Ich kann nur vermuten, das es mit einem Update von IP-S selber oder vom Ubuntu zusammen hängt, da ich sonst in den letzten Wochen keine Änderungen gemacht habe, weder am System selber noch an der restlichen Umgebung.

Ich schaue mir das mal weiter an.

Hi,

hab das gleiche Phänomen auch unter proxmox.

Wie bei dir, steht nichts auffälliges im log. Aber der unterschied zu deinem problem ist, das es bei mir nicht immer auftritt. Ich vermute es könnte an einem hängendem php-thread hängen. Bei meinem dev system läuft nämlich nicht wirklich viel im gegensatz zum live.

Vielleicht könnte symcon beim stoppen des services ein abbild der threads im log schreiben um zu sehen welches hängt?

Viele grüße

Mein Testsystem macht auch keine Probleme, da läuft auch fast nichts drauf und ich lasse da derzeit jede Nacht ein Update laufen mit abschliessendem Reboot - keine Aussetzen.

Aber gebe dir Recht, das verstärkt die Vermutung, das ein PHP-Thread hängt. Ich hatte heuet morgen die Meldung das zuviele PHP-Skripte laufen ( ähnlicher Wortlaut )

Evtl. kann man den Loglevel erhöhen, muss mich mal nachschauen.

EDIT: das sind die Einträge im log, wenn ich symcon stoppe, danach kommen weiterhin Daten von Geräten rein aber auch die Meldungen, das neue PHP-Scripte nicht gestartet werden können.

systemctl stop symcon

hängt aber im stop-Vorgang, das läuft nach einiger Zeit in einen Timeout mit den Meldungen im syslog ( zweites Feld )

12.03.2023 09:13:01 | 13721 | DEBUG   | ScriptEngine         | Ausgeführt von PHP-Modul ~ Aktion: Timer: Update ~ Dauer: 31 ms
12.03.2023 09:13:04 | 12143 | DEBUG   | VariableManager      | [Hardware\Homematic\Heizung\Arbeitszimmer\Thermostat\WEATHER\TEMPERATURE] = 20.6000000000
12.03.2023 09:13:04 | 22893 | DEBUG   | VariableManager      | [Hardware\Homematic\Heizung\Arbeitszimmer\Thermostat\WEATHER\HUMIDITY] = 38
12.03.2023 09:13:05 | 36258 | DEBUG   | ScriptEngine         | Ausführung von PHP-Modul ~ Aktion: ReceiveData
12.03.2023 09:13:05 | 30612 | DEBUG   | ScriptEngine         | Ausführung von PHP-Modul ~ Aktion: ReceiveData
12.03.2023 09:13:05 | 30612 | DEBUG   | ScriptEngine         | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 0 ms
12.03.2023 09:13:05 | 36258 | DEBUG   | ScriptEngine         | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
12.03.2023 09:13:07 | 23106 | DEBUG   | ScriptEngine         | Ausführung von PHP-Modul ~ Aktion: Timer: TriggerCalendarNotifications
12.03.2023 09:13:07 | 23106 | DEBUG   | ScriptEngine         | Ausgeführt von PHP-Modul ~ Aktion: Timer: TriggerCalendarNotifications ~ Dauer: 3 ms
12.03.2023 09:13:07 | 53070 | DEBUG   | VariableManager      | [Hardware\Homematic\Heizung\Flur - oben\Thermostat\WEATHER\TEMPERATURE] = 21.2000000000
12.03.2023 09:13:07 | 19797 | DEBUG   | VariableManager      | [Hardware\Homematic\Heizung\Flur - oben\Thermostat\WEATHER\HUMIDITY] = 37
12.03.2023 09:13:09 | 00000 | MESSAGE | Kernel               | Deinitialisiere...
12.03.2023 09:13:09 | 00000 | MESSAGE | ScriptEngine         | Warte auf Beendigung aller Skript-Threads...
12.03.2023 09:13:15 | 18563 | DEBUG   | VariableManager      | [Hardware\Homematic\Heizung\Bad\Thermostat\CLIMATECONTROL_REGULATOR\ADJUSTING_COMMAND] = 0
12.03.2023 09:13:15 | 23245 | DEBUG   | VariableManager      | [Hardware\Homematic\Heizung\Bad\Thermostat\CLIMATECONTROL_REGULATOR\ADJUSTING_DATA] = 0



12.03.2023 09:13:15 | 50860 | DEBUG   | VariableManager      | [Hardware\Homematic\Heizung\Bad\Stellantrieb\CLIMATECONTROL_VENT_DRIVE\VALVE_STATE] = 0
12.03.2023 09:13:15 | 48513 | ERROR   | EventManager         | Aktion konnte für Ereignis #48513 nicht ausgeführt werden: Skripte können nicht gestartet, sobald Abschaltung eingeleitet wurde
12.03.2023 09:13:15 | 36228 | DEBUG   | VariableManager      | [Hardware\Homematic\Heizung\Bad\Stellantrieb\CLIMATECONTROL_VENT_DRIVE\ERROR] = 0

syslog:

Mar 12 09:22:40 ipsymcon systemd[1]: Stopping LSB: Kurze Beschreibung...
Mar 12 09:25:01 ipsymcon CRON[41750]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Mar 12 09:27:40 ipsymcon systemd[1]: symcon.service: Stopping timed out. Terminating.
Mar 12 09:27:40 ipsymcon systemd[1]: symcon.service: Control process exited, code=killed, status=15/TERM
Mar 12 09:27:40 ipsymcon systemd[1]: symcon.service: Failed with result 'timeout'.
Mar 12 09:27:40 ipsymcon systemd[1]: symcon.service: Unit process 206 (symcon) remains running after unit stopped.
Mar 12 09:27:40 ipsymcon systemd[1]: symcon.service: Unit process 42067 (sleep) remains running after unit stopped.
Mar 12 09:27:40 ipsymcon systemd[1]: Stopped LSB: Kurze Beschreibung.
Mar 12 09:27:40 ipsymcon systemd[1]: symcon.service: Consumed 5min 35.080s CPU time.

Auch ich habe seit längerem gleiches Problem auf dem Raspi. Habe dann auch auf Proxmox/Unbuntu getestet, gleiches Ergebnis. Letzte Woche beim Update wieder dasselbe… (hatte ja auch bereits hier gepostet). Nun mache ich nachts das Backup online und keine Updates mehr …. Der Stresslevel ist mir zu hoch.

In meinem Thread dazu hatte Paresy bereits angedeutet, dass ein PHP-Thread hängen könnte, das zu finden, dazu reicht es bei mir nicht.

Gruß Michael

Genau - das wäre mein Ansatz um zu Prüfen was festhängst.

Generell würde ich die Backups einfach „Live“ ziehen. D.h. ohne Shutdown. Wenn ihr das täglich tut, dann ist die Wahrscheinlichkeit eines Inkonsistenten Backups sehr gering. Haltet einfach die letzten X Backups vor und dann könnt ihr im Zweifelsfall einen Tag zurück gehen, aber umgeht diese ganze Shutdown Problematik und natürlich die damit verbundene Downtime - auch wenn Sie im Normalfall nur kurz ist.

paresy

1 „Gefällt mir“

Das Backup ist ein Thema, das hab ich auch mittlerweile im Online-Modus, allerdings muss man ja hin und wieder mal den Linux-Container nach einem Update rebooten oder noch schlimme, den ganzen Proxmox-Node und wenn da 1 von 20 LXC rumzickt, der nicht runterfährt, blockiert das den Reboot des Proxmox.
Das nervt viel mehr

Ich bin mittlerweile sicher, das es ein PHP-Modul ist, was den Ärger verursacht, einige Sachen konnte ich schon eleminieren, die Probleme machten, waren aber bisher nicht die Ursache.

1 „Gefällt mir“

Hallo,

ich habe das was ganz unschönes gefunden, der Symcon Integrity-Check spuckt das unschöne Meldungen aus:

Jetzt muss ich nur noch rausfinden, der der böse Job das ist - weiss das jemand zufällig ?

Ich werde aber auch mal das Meldungs-Fenster offen lassen für längere Zeit - es reichten wenige Sekunden, wie bekomme ich aber nun raus, welche Job das ist ?

Das war ne super Idee, habe das Modul gleich auch mal installiert.
Folgendes Ergebnis:

Gruß Michael

Hi,

PB_UpdataData ist mein PontosBase Modul :scream:

Jetzt muss ich nur herausfinden warum du die „Error 405“ bekommst und wie ich verhindern kann, das der Thread da hängen bleibt

Viele Grüße

Hi Kris,

Oha und das tut mir leid :sleepy: … wenn du Infos brauchst, sag Bescheid.

Gruß Michael

Ich bin auch einen Schritt weiter und denke den Übeltäter gefunden zu haben, weil nach einem Neustart von IP-S passiert das:

14.03.2023 12:26:39 | 36258 | MESSAGE | DeconzGateway        | Erstelle...
14.03.2023 12:26:39 | 36258 | DEBUG   | ScriptEngine         | Ausführung von PHP-Modul ~ Aktion: Create
14.03.2023 12:26:39 | 36258 | DEBUG   | ScriptEngine         | Ausgeführt von PHP-Modul ~ Aktion: Create ~ Dauer: 0 ms
14.03.2023 12:26:39 | 36258 | DEBUG   | ScriptEngine         | Ausführung von PHP-Modul ~ Aktion: ApplyChanges

und dann erst mal längere Zeit ( ca. 15 min ) nichts mehr, das System hängt im Startprozess, die WebGUI meldet das auch.
Nach den 15 min läuft der Start und kurz danach ist auch die WebGUI verfügbar.

Da ich das DeconzGateway aber eh entsorgen will, hab ich das Modul über den Modulstore deinstalliert, sämtlichen damit verknüpften Lampen gelöscht und alle Objekte, Instanzen usw. die ich gefunden habe, auch gelöscht. Es sollte davon nichts mehr übrig sein.

Anschliessend wieder. restart IP-S

( Fortsetzung folgt, da hängt der derzeit nämlich )

Fortsetzung: Restart von IP-S war nicht erfolgreich, IP-S war offline nach einem „systemclt stop symcon“.
Maschine komplett rebootet - Start von IP-S. war sehr schnell erledigt, keine Hänger im Log zu sehen.

Jetzt stellt sich die große Frage(n):

  • warum brauch das DeconzModul solange zu starten ?
  • einer meiner RasPi mit dem Raspi II Modul ist derzeit nicht erreichbar ( darum fliegen die auch raus, die Teile nerven mich ständig mit Ausfällen ), da würde ich aber erwarten, das nach max. 2 Min das Modul bei starten abbricht mit Timeout
  • oder hat das Modul selber ein Problem - evtl. nach einem Update von Modul selber, von IP-S oder vom Ubuntu-OS

Fragen über Fragen.

Ich hab nun meine Backups wieder auf Offline-Backup umgestellt und auch die System-Updates mit Reboot aktiviert - spätestens dann zeigt sich, ob der Fehler weg.

probiere mal in der Shell vom Proxmox

pct stop <vmid>

auszuführen. Müsste klappen.

Ich habe ja auch schon vor längerer Zeit von dem Problem berichtet, manchmal läuft das stoppen von IPS durch manchmal nicht. Dann muss es entweder an mehreren Modulen liegen oder an IPS selber. Ich selber nutze kein PontoBase und kein Deconz Modul.

Ich hab den immer über Proxmox rebooten müssen, ging anders garnicht mehr

Nach dem ich das PHP-Modul rausgeworfen habe, funktionierte nun aber auch der reboot direkt auf dem OS wieder normal und innerhalb weniger Sekunden - wie gewohnt.

Ich vermute auch, das es hier eher ein IPS-Problem ist und nicht bei den Modulen zu suchen ist - evtl. die Kommunikationsschnittstelle dazwischen, aber dafür bin ich zuwenig Softwareentwickler.

Wenn du mal in dein /var/log/symcon/logfile.log schaust bei einem Neustart ob der dort auch an einer Stelle hängen bleibt.
Das war bei mir eindeutig.
Zudem sag man in den PHP Informationen einige rote Einträge, wo kurzzeit immer mal wieder das Script angezeigt wurde, das Meldungsfenster war nicht sonderlich hilfreich.

Ich hab das Problem auf meinem Test-Server ja nicht und der ist komplett gleich aufgesetzt vom OS her, hat die selbe IP-S version, nur sind da erheblich weniger Geräte, Instanzen usw. installiert, weil ich den nur zum testen von irgendwelchen Einstellungen usw. nutze.

Noch ein kleines Update:

  • PHP Liste ist sauber, keine hängenden Jobs
  • Meldungsliste ist sauber, nichts rotes mehr zu sehen
  • reboot des Containers geht fix innerhalb von wenigen Sekunden, so wie es sein soll.

Bleibt die große Frage im Raum:

  • was ist das für ein Problem, das scheinbar ja mehrere Module haben.

Hi…

Ich hatte (siehe hier) ein ähnliches Problem.
Eine Neuinstallation mit anschließendem Einspielen des Backups hat das Problem bei mir behoben.
Grund für das Problem konnte ich bis zum Schluss nicht rausfinden…

Viele Grüße
Jochen

es gibt schlichtweg kein Timeout - welches vom System vorgegeben ist - mehr. Früher war ein Timelimit von, lass mich nicht lügen, 60 sek. Das ist aufgehoben.

Dafür ist der Modulbauer verantwortlich ein Timeout festzulegen oder sorge zu tragen, das ein Modul kein Zombie wird

Hoffentlich wissen die das auch. :blush:

Hi,

Learning by doing. Ich bin bei meinem modul auch nicht davon ausgegangen das es zu einem problem wird :man_shrugging:

Wäre es vielleicht denkbar, ein systemtimeout von, sagen wir mal 6 stunden einzuführen?

Dann kann es zwar immer noch probleme beim reboot geben, aber wenigstens laufen nicht module amok…

Dazu noch einen neuen systeminstanzcode ähnlich zu 101, 102 etc um zu signalisieren, das die instanz zwar aktiv ist aber ein systemtimeout griff und deswegen ein thread gekillt wurde.

Optional dann ein gerätetyp namens listener o.ä. der aus dem timeout rausgenommen wird. Sozusagen für die profis :face_with_peeking_eye:

Viele grüße

Nein. Siehe Migration 6.0

Neu: max_execution_time in PHP auf 0 gesetzt, weil es Ursache für viele Abstürze war.
Quelle:
V5.5->V6.0 (Q3/2021) — IP-Symcon :: Automatisierungssoftware

Das ging, wie erst letztes schon geschrieben, noch nie.
Wenn er hängt war es das.
Michael

Hi,

ok, dann hatte ich das falsch in Erinnerung. Schade.

Viele Grüße