Die Ressource ist zur Zeit nicht verfügbar (seit 6.0)

bgersmann · 20. Oktober 2021 um 14:35

Mir ist gerade aufgefallen das seit einiger Zeit die Temperatur nicht mehr aktualisiert wird. Im log war ein Eintrag:

20.10.2021 13:44:35 | 00000 | ERROR | TimerPool | Die Ressource ist zur Zeit nicht verfügbar

Seit dem wurde kein Sensor mehr abgefragt, außer direkt danach der WSens…

Ein Etwas größerer ausschnitt:

Jemand eine Idee was das sein könnte?

„sudo reboot“ hing dann auch, die Console war über web erreichbar mit der Meldung „Server is shutting down…“ bis ich dann den Stecker gezogen habe.

Edit: Unter PHP Informationen war kein Timer Rot…

Tuxtom007 · 21. Oktober 2021 um 07:09

Auch beim Reboot werde alle Prozesse sauber beendet. Meine Vermutung - weil ich das selber schon hatte - das eine Script in IPS bei dir hängt und den IPS-Shutdown blochiert, somit uach den Reboot des Betriebssystem.

Ich bin bei mri dazu übergegegangen, IPS nicht mehr zu stoppen fürs Backups, das funktioniert bisher sehr gut und auch ein Recovery war problemlos möglich.

bgersmann · 21. Oktober 2021 um 07:15

Beim Backup habe ich das auch schon umgestellt, nun lief aber ja mitten am Tag die Timer um die Temperatur Sensoren abzufragen nicht mehr, deswegen dann der Reboot.

Ist halt etwas bescheiden wenn darüber die Stellantriebe angesteuert werden aber die Temperatur nicht aktualisiert wird.

Interessant wäre dann ja auch irgendwie rauszufinden welches Script es gewesen ist?

paresy · 21. Oktober 2021 um 07:18

Ich habe einen weiteren Kunden der genau das selbe Problem (vermutlich seit der 6.0) hat. Ich bin also dran - habe aber noch nicht viele Hinweise. Kannst du mir deinen /var/log/symcon Ordner mal zippen und per PM zukommen lassen?

Ich habe das neue Problem mal in ein neues Thema verschoben.

paresy

bgersmann · 21. Oktober 2021 um 07:31

Bin heute leider im Büro, mach ich dann heute Abend oder morgen Früh eben…

bgersmann · 23. November 2021 um 07:32

Hab den Fehler gerade zufällig wieder gesehen:

Leider funktioniert das Modul „Variablenüberwachung“ dann auch nicht mehr…

Habt ihr da schon etwas gefunden?

paresy · 23. November 2021 um 22:05

Leider noch nicht. Bisher habe ich auch keine neuen Hinweise was die Ursache sein könnten.

Könntest du dich aber mal auf die Box per SSH einloggen und folgendes ausführen?

ls /proc/$(pidof symcon)/task | wc -l

Steigt diese Zahl konstant, wenn du dies einfach mal eine Stunde/einen Tag später machst?

paresy

bgersmann · 24. November 2021 um 06:35

Hab es jetzt um 7:30 einmal ausgeführt, da war der Wert bei 77, jetzt um 7:33 bei 80… Ich werde es mal beobachten und dokumentieren.

Gibt es noch eine Möglichkeit das „extern“ zu überwachen? Da die Symcon meine Stellmotoren steuert, ist es etwas ärgerlich wenn es nachts ausfällt und es dann morgens Kalt oder Sehr Warm ist weil die Motoren in der Aktuellen Position hängen bleiben…

Und noch ne kleine Frage zu dem Befehl, die „pidof symcon“ muss ich nicht ersetzen?

bgersmann · 24. November 2021 um 10:16

Bisher schwankt der Wert zwischen 77 und 83…

BommelPommel · 24. November 2021 um 10:48

Bei mir schwankt es zwischen 105 und 109

paresy · 24. November 2021 um 22:02

Hier noch ein kleines Skript, dass ein paar mehr Kennzahlen ins Logfile wirft:

IPS_LogMessage("All-Threads", exec("ls -1d /proc/*/task/* | wc -l"));
IPS_LogMessage("Symcon-Threads", exec("ls /proc/$(pidof symcon)/task | wc -l"));
IPS_LogMessage("All-FDs", exec("lsof | wc -l"));
IPS_LogMessage("Symcon-FDs", exec("ls -l /proc/$(pidof symcon)/fd | wc -l"));

Sofern nicht vorhanden müsst ihr noch per sudo apt install lsof das notwendige Tool nach installieren.

Vielen Dank fürs Mithelfen - ich hoffe, dass wir der Sache endlich mal auf die Spur kommen.

bgersmann · 25. November 2021 um 06:05

Ok Skript ist erstellt und funktioniert, wünsche wie oft das ausgeführt werden soll?

Btw. wird es dann ja auch nicht mehr ausgeführt wenn der Fehler auftritt…

Der „ls /proc/$(pidof symcon)/task | wc -l“ Befehl gibt aktuell 85 aus, allerdings hab ich gestern die Steuerung ausersehen mal stromlos gemacht…

paresy · 25. November 2021 um 06:36

Tatsächlich wird es weiter ausgeführt. Es sind immer nur die internen Timer betroffen. Ereignisse laufen weiter.

paresy

bgersmann · 25. November 2021 um 06:41

Jetzt steh ich aufm Schlauch, also brauch ich an das Skript kein Ereignis hängen, damit es regelmäßig ausgeführt wird?

Oder die Ereignisse laufen weiter, aber Modul interne Timer nicht?

Dann würde mir aber noch ein Wunsch fehlen, wie oft das Skript ausgeführt werden soll?

BommelPommel · 25. November 2021 um 06:50

Doch vermute ich - interne Timer sind z.B. die Funktionen rund um das astromodul. So mein mein Verständnis.

paresy · 25. November 2021 um 11:07

Ich habe es woanders mit 30 Sekunden am Laufen.

paresy

paresy · 25. November 2021 um 21:46

Hm. Daran scheint es nicht zu liegen.

Könnte ihr einmal per SSH free ausführen und die Ausgabe hier kopieren, während das Problem aktuell ist (also bevor Ihr IP-Symcon neu startet?) Evtl. ist das ganze Problem ja ein „simples“ Speicherleck.

Wenn ich das richtig sehe betrifft es weiterhin nur Linux Systeme (also RPi, SymBox, Ubuntu)?

Fügt im Skript gerne noch diese Zeile hinzu:

IPS_LogMessage("Memory", round(Sys_GetMemoryInfo()["AVAILPHYSICAL"] / 1024 / 1024) . " MB");

paresy

bgersmann · 26. November 2021 um 06:13

Hab’s mal mit in das Skript eingebaut.

Bei mir ist es zumindest ein RPi 4 mit 2GB Ram.

BommelPommel · 27. November 2021 um 15:12

also auf der Symbox hatte ich gestern 300 MB und bin aktuell bei 217 MB. Auf ein Problem mit dem Speicher würde ich spontan nicht tippen.

paresy · 27. November 2021 um 19:27

Ist das Problem denn aufgetreten seither? Wenn es einen klaren Abwärtstrend gibt, dann passiert das Problem sobald es gegen 0 geht.

paresy