Cannot fork: Cannot allocate memory | BlockingInformParent

[KernSani]

Freezemon killt blocking calls nicht, d.h. bei mehreren kurz aufeinander folgenden Freezes, könnte es eng werden. Ich baue das heute abend mal um... Einen kontinuierlichen Speicheranstieg kann ich mir dadurch aber nicht erklären...


Kurz, weil mobil...

[CoolTux]

Freezemon killt blocking calls nicht, d.h. bei mehreren kurz aufeinander folgenden Freezes, könnte es eng werden. Ich baue das heute abend mal um... Einen kontinuierlichen Speicheranstieg kann ich mir dadurch aber nicht erklären...


Kurz, weil mobil...

Ich denke da eher an apptime, aber vielleicht in Verbindung mit freezemon.

[KernSani]

Ich denke da eher an apptime, aber vielleicht in Verbindung mit freezemon.

Das klingt für mich auch irgendwie logischer, aber man weiss ja nie.

Übrigens: Freezemon verwendet blocking calls um das Log zu schreiben - kein Log keine blocking calls - vielleicht kann das ja maljemand ausprobieren (Attribut fm_logFile löschen)

[binford6000]

Mit (wieder) aktiviertem freezemon bleibt der Speicher seit etwa 2 Stunden gleich.
@KernSani: Attribut fm_logFile ist bei mir gesetzt. Lösche es jetzt mal und beobachte weiter...
VG Sebastian

[binford6000]

Hallo Zusammen,
der aktuelle Stand bei mir:

• freezemon inactive: Speicherverbrauch nimmt stetig zu -> cannot allocate...
• freezemon gelöscht + Neustart wg. apptime: Speicherverbrauch bleibt gleich.
• freezemon active mit fm_logFile: Speicherverbrauch bleibt gleich.
• freezemon active ohne fm_logFile: Speicherverbrauch bleibt gleich.

Die obigen Angaben beziehen sich jeweils auf ein Zeitfenster von etwa 4 Stunden.
Im Fehlerfall war aber bei mir bereits nach zwei Stunden der Speicher voll und die Meldungen "cannot allocate" kamen im Log.

Kann denn ein "unsachgemäßes" deaktivieren von freezemon die Ursache gewesen sein?
Ich hatte im Nachgang festgestellt, dass zusätzlich zu set inactive auch noch attr disable 1 gesetzt war...

Haben andere Betroffene auch freezemon ausprobiert oder im Einsatz?

VG Sebastian

[Rewe2000]

Hallo Sebastian,

da ich ja auch die Probleme hatte, bis ich apptime und Freezemon gelöscht hatte, aktiviere ich die beiden Programme bei mir zum Test auch noch mal und werde dann berichten. Hast du Perfmon während der Zeit ohne Freezemon installiert gehabt?

Bei mir war immer entweder Perfmon (ohne apptime) oder Freezemon (mit apptime) aktiv.

Kannst du mir nochmal angeben welchen Speicher (frei oder verwendet) du genau beachtest, ich hab da immer noch meine Probleme damit https://forum.fhem.de/index.php/topic,84372.msg789076.html#msg789076

Nachtrag:
Ich hatte immer die vom Entwickler KernSani vorgeschlagenen SVG Charts eingerichtet, hast du die auch aktiv?
Nach diesem Beitrag habe ich es eingerichtet: https://forum.fhem.de/index.php/topic,83909.msg762539.html#msg762539

Nachtrag 2:
Mir ist noch eingefallen, ich habe in der Zeit vor oder nach dem Fehler sysmon mit etlichen SVG_Charts installiert. Leider kann ich mich nicht mehr erinnern ob es vor oder schon nach dem Entfernen von freezemon war.

Gruß Reinhard

[KernSani]

@Sebastian: Auch wenn Freezemon deaktiviert ist, bleibt apptime aktiv. Hast du mal apptime ohne Freezemon probiert?


Kurz, weil mobil...

[Brice]

Haben andere Betroffene auch freezemon ausprobiert oder im Einsatz?

Ja, wie hier berichtet.

Freezemon werde ich morgen wieder aktivieren und das Verhalten überwachen. Ich bezweifle aber, dass es ausschließlich am Modul freezemon liegt, da

• ein zweites System mit freezemon den Fehler nicht hat. Hier ist freezemon seit 20.03.2018 nur auf inaktiv gesetzt
• nach Durchsicht aller fhem.cfg zurück bis zum 23.02.2018 freezemon aktiv war, der Fehler aber erst am 14.03.2018 erstmalig auftrat

Allerdings habe ich keine Aufzeichnungen darüber, wann ich das Modul upgedatet hatte.

[binford6000]

Hallo Reinhard, Oli, Brice,

Kannst du mir nochmal angeben welchen Speicher (frei oder verwendet) du genau beachtest, ich hab da immer noch meine Probleme damit https://forum.fhem.de/index.php/topic,84372.msg789076.html#msg789076

Ich überwache den Speicher aus sysmon, mit userReading wie von Brice beschrieben. Zusätzlich noch den freien Speicher fürs das Chart:

Code Auswählen Erweitern

ram_used {if (ReadingsVal($name,'ram','0')  =~ m/Used:\s(.*)\sMB,/) {return $1;}},
ram_free {if (ReadingsVal($name,'ram','0')  =~ m/Free:\s(.*)\sMB/) {return $1;}}

Ich hatte immer die vom Entwickler KernSani vorgeschlagenen SVG Charts eingerichtet, hast du die auch aktiv?

Hatte ich kurz im Einsatz, dann wieder gelöscht.

@Sebastian: Auch wenn Freezemon deaktiviert ist, bleibt apptime aktiv. Hast du mal apptime ohne Freezemon probiert?

Nein hatte ich nicht. Das werde ich als nächstes mal testen! Bin auch wie Brice der Meinung, dass es nicht (nur) an freezemon liegen kann...

VG Sebastian

[KernSani]

Ich fürchte möglicherweise ist doch Freezemon (mit) Schuld... allerdings nur ein inaktiver Freezemon. Das logging der verbose 5 Meldungen wird beim deaktivieren von Freezemon nicht abgeschaltet. D.h. es werden fleissig weiter Logmeldungen gesammelt, aber - da Freezemon inaktiv ist - nicht mehr gelöscht.

Ich habe das gefixt und eingecheckt. 

[binford6000]

Ich fürchte möglicherweise ist doch Freezemon (mit) Schuld... allerdings nur ein inaktiver Freezemon.

Das deckt sich ja mit meinen Beobachtungen 

[Brice]

Bei meinem zweiten System (siehe Signatur) ist freezemon.pm seit dem 12.03.2018 auf inaktiv gesetzt.

Code Auswählen Erweitern

define myFreezemon freezemon
attr myFreezemon room System
define FileLog_freezemon FileLog /media/usbstick/log/FileLog_freezemon-%Y-%m.log myFreezemon
attr FileLog_freezemon room System
define SVG_FileLog_freezemon SVG FileLog_freezemon:myFreezemon:CURRENT
attr SVG_FileLog_freezemon captionPos left
attr SVG_FileLog_freezemon plotReplace TL={"Freezes today: ".$data{max1}." - Longest Freeze ".sprintf("%.2f ",$data{max2}) }
attr SVG_FileLog_freezemon room System
define SVG_FileLog_freezemon_day SVG FileLog_freezemon:myFreezemon_day:CURRENT
attr SVG_FileLog_freezemon_day captionPos left
attr SVG_FileLog_freezemon_day fixedrange month
attr SVG_FileLog_freezemon_day plotReplace TL={"Max Freezes: ".$data{max1}." - Max Freezetime ".sprintf("%.2f ",$data{max2}) }
attr SVG_FileLog_freezemon_day room System

Hat auch keine Logeinträge seitdem...

Code Auswählen Erweitern

2018-03-12_07:45:10 myFreezemon inactive
2018-03-12_07:44:02 myFreezemon ftDay: 0
2018-03-12_07:44:02 myFreezemon fcDay: 0
2018-03-12_07:44:02 myFreezemon ftDayLast: 61344.122
2018-03-12_07:44:02 myFreezemon fcDayLast: 3
2018-03-12_07:43:13 myFreezemon freezeDevice: FRITZBOX_Readout_Start(N/A) TelegramBot_RestartPolling(Telegram_RPi2

Code Auswählen Erweitern

98_freezemon.pm     16411 2018-03-14 22:22:14Z KernSani

[KernSani]

Das Problem tritt nur beim inaktiv setzen im laufenden Betrieb auf. Nach einem FHEM-Neustart sammelt ein inaktiver Freezemon keine Meldungen mehr... Ich schau mir das aber nochmal genau an, ob da nicht doch noch was im Hintergrund schlummert.



Kurz, weil mobil...

[binford6000]

Das Problem tritt nur beim inaktiv setzen im laufenden Betrieb auf. Nach einem FHEM-Neustart sammelt ein inaktiver Freezemon keine Meldungen mehr... Ich schau mir das aber nochmal genau an, ob da nicht doch noch was im Hintergrund schlummert.

Vielleicht auch in Verbindung mit einem - eigentlich überflüssigen - disable 1?
Mit apptime alleine bleibt der Speicherverbrauch übrigens seit etwa einer Stunde gleich...
VG Sebastian

[Jens_B]

Also bei meinem raspi 3 liegt es nicht an freezemon. Ich habe das device ,,myfreeezemon" komplett gelöscht und trotzdem ist der speicherverbrauch kontinuierlich angestiegen.
Seitdem restart von fhem vor 14 Studnen von 161 auf 217 MB.

Gruß
Jens