Cannot fork: Cannot allocate memory | BlockingInformParent

[Eistee]

Ich habe es inzwischen aufgegeben fehlerhafte Module zu suchen. Hab mir ein DOIF erstellt welches bei der Meldung "Cannot fork: Cannot allocate memory" ein sudo reboot macht. In der Regel funktioniert FHEM eh nicht mehr zuverlässig wenn diese Meldung nach 3-4 Tagen auftaucht. So hab ich nun Ruhe.

LG Alina

[HomeAuto_User]

Die Lösung mit einem DOIF ist ein WorkaRound und als Notlösung zu sehen.

Ich erachte so eine Lösung nicht als Beseitigung. Wir vertagen nur das Problem und kehren es somit vom Tisch.

Ich selbst als Betroffener versuche soeben mit Indizien weiter zu kommen.


Gesendet von iPhone mit Tapatalk Pro

[Jens_B]

Ich habe es inzwischen aufgegeben fehlerhafte Module zu suchen. Hab mir ein DOIF erstellt welches bei der Meldung "Cannot fork: Cannot allocate memory" ein sudo reboot macht. In der Regel funktioniert FHEM eh nicht mehr zuverlässig wenn diese Meldung nach 3-4 Tagen auftaucht. So hab ich nun Ruhe.

LG Alina

Bei mir hat es immer gereicht, nur fhem neu zu starten. Seitdem ich auf "buster" geupdatet habe sind die Probleme aber verschwunden.

[der-Lolo]

Ist eigentlich jemand mit FHEM im Docker Container betroffen..?
Ich überlege zu wechseln...

[kadettilac89]

Ist eigentlich jemand mit FHEM im Docker Container betroffen..?
Ich überlege zu wechseln...

Docker ist schon auf Buster. Ich habe keine Probleme. Aber auch als das Docker Image basierend auf Stretch keine großen Probleme gehabt.

Vergleich hinkt ein wenig. Bevor ich auf stärkere Hardware und Docker ging, hatte ich alle 2 Tage über notify einen Reboot wegen dem "cannot allocate memory" Eintrag im Logfile.

Letzten 7 Tage mal als Grafik angehängt. Den ersten Tag in der Grafik kannst ignorieren, das war etwas anderes.

[Eistee]

Bei mir reicht es nicht FHEM mit "shutdown restart" neu zu starten. Was ich herausbekommen habe ist das Aufrufe die nicht blockierend sind irgendwann nicht mehr funktionieren. Scheinbar sind da Aufrufe von Funktionen dabei die hängen bleiben und auch nicht von einem Timeout abgebrochen werden. Die Anzahl dieser nicht blockierenden Funktionen (non blocking call) ist aber scheinbar begrenzt. Aber da steck ich nicht tief genug in FHEM drin um zu beurteilen wie das genau funktioniert. Ich hab nur das Gefühl das man in FHEM ein altes Problem der blockierenden Aufrufe nun verlagert hat ohne es zu beheben. FHEM blockiert nun nicht mehr aber es läuft dann auch irgendwann nicht mehr.

[HomeAuto_User]

Gibt es die Möglichkeit, irgendwie die Aufrufe der Perl Funktionen / Aufrufe abzurufen auf dem System?

Definitiv ist es was in Perl, was man leider nur unter dem Speicherfresser FHEM via htop lokalisieren kann.

Diverse Module welche angesprochen wurde, habe ich ausgegrenzt / deaktiviert und der ,,Fresser" ist immer noch da, ggf nur zeitlich mehr verzögert.

Man müsste ,,die Prozesse hinter FHEM" in htop auflisten können aber soweit stecke ich nicht drin.


Gesendet von iPhone mit Tapatalk Pro

[Nestor]

I'm currently experiencing a mem. increase of about 8Mb per day. My Fhem starts at 140Mb and after a month it's around 380Mb. This is running on a system with 8Gb RAM and I update every couple of weeks so it was not really noticeable.

fhemdebug memusage after start

Code Auswählen Erweitern


   1. defs                            3214940
   2. defs::global                     711156
   3. defs::global::helper             709869
   4. defs::global::helper::bm         709540
   5. modules                          611696


fhemdebug memusage after 12 hours

Code Auswählen Erweitern


   1. defs                            5315401
   2. defs::global                    2786627
   3. defs::global::helper            2785212
   4. defs::global::helper::bm        2784883
   5. modules                          614219


It appears defs::global::helper::bm keeps increasing, let's investigate.

Code Auswählen Erweitern

./telnet_client localhost 7072 '{ TimeNow() ." ". int keys %{$main::defs{global}->{helper}->{bm}} }'
2019-07-30 10:41:56 2123
2019-07-30 10:43:06 2126
2019-07-30 10:49:05 2144
2019-07-30 10:55:13 2162
2019-07-30 10:57:25 2168


Dumper is set with:

Code Auswählen Erweitern

use Data::Dumper;
$Data::Dumper::Terse = 1;
$Data::Dumper::Sortkeys = 1;
$Data::Dumper::Maxdepth = 1;

Code Auswählen Erweitern

./telnet_client localhost 7072 '{ Dumper($main::defs{global}->{helper}->{bm}) }' | cut -d ';' -f 1 - | uniq -c | sort -nr | head -n5
   2064   'tmr-RESIDENTStk_DurationTimer
     29   'tmr-RandomTimer_Exec
      7   'tmr-statistics_PeriodChange
      6   'tmr-WeekdayTimer_Update
      5   'tmr-sleep_WakeUpFn


Code Auswählen Erweitern

./telnet_client localhost 7072 '{ Dumper($main::defs{global}->{helper}->{bm}) }' | cut -d ';' -f 1 - | uniq -c | sort -nr | head -n5
   2070   'tmr-RESIDENTStk_DurationTimer
     29   'tmr-RandomTimer_Exec
      7   'tmr-statistics_PeriodChange
      6   'tmr-WeekdayTimer_Update
      5   'tmr-sleep_WakeUpFn

Code Auswählen Erweitern

./telnet_client localhost 7072 '{ Dumper($main::defs{global}->{helper}->{bm}) }' | cut -d ';' -f 1 - | uniq -c | sort -nr | head -n5
   2091   'tmr-RESIDENTStk_DurationTimer
     29   'tmr-RandomTimer_Exec
      7   'tmr-statistics_PeriodChange
      6   'tmr-WeekdayTimer_Update
      5   'tmr-sleep_WakeUpFn


It seems tmr-RESIDENTStk_DurationTimer does not get cleaned up.

Edit:
%defs{global}->{helper}->{bm} is created by 98_apptime so the leak must be there.
https://forum.fhem.de/index.php/topic,102657.0.html

[peter_w]

Ich habe es inzwischen aufgegeben fehlerhafte Module zu suchen. Hab mir ein DOIF erstellt welches bei der Meldung

Hallo Alina,
könntest du bitte mal das DOIF vorstellen mit dem du das machst. Ich würde mein Problem gerne auf die gleiche Art Lösen. Vielen Dank.
Peter

[MadMax-FHEM]

Dazu braucht es kein DOIF...
...ein simples Notify reicht (und wurde auch schon mehrfach gepostet), hier die raw definition eines Beispiels:

Code Auswählen Erweitern


defmod nCannotForkRestart notify global:CANNOT_FORK shutdown restart


Gruß, Joachim

[peter_w]

Super, danke für dass du es trotzdem nochmal gepostet hast.

[HomeAuto_User]

Hallo,

eine Frage an alle die das Problem

Code Auswählen Erweitern

Cannot fork: Cannot allocate memory
besitzen.

Ich betreibe nun seit längerem eine Fehlersuche und versuche alles auszuschließen.
Derzeit habe ich einen "heißen Verdacht" nachdem ich ja schon diverse Module ausgeschlossen habe.

Betreibt Ihr das modul HTTPMOD? Wenn ja, mit wielviel reading08Name & reading08Regex?
Versucht mal das Modul zu deaktivieren bei dem Auftreten von Cannot fork und restartet FHEM.
... Danach beobachten und zu Wort melden hier.

Bei einer Anzahl von je 93 ist der Fehler derzeit immer aufgetreten bei mir.

MfG

[MadMax-FHEM]

HTTPMOD war schon mal in Verdacht...
...wurde aber wieder fallen gelassen!?

Ich habe in meiner Hauptinstanz ein paar HTTPMOD aber mit wenigen Readings/attrRegex:

2x63
Ansonsten noch 5 mit max. 5

Dort habe ich das Problem kaum: (deutlich) übr 1 Monat ohne das Problem


In einer anderen fhem Instanz (Testsystem) kein HTTPMOD und trotzdem rasanten Anstieg...
...dort kann ich das mit dem echodevice Modul nachvollziehen.

Ich habe ein Testfhem mit quasi (fast) nur dem echodevice Modul: Speicher steigt, komme gerade mal eine gute Woche hin...
...Modul raus: alles gut.

Interessant wären eher die "Gemeinsamkeiten", wenn es welche gibt, um letztendlich auf das zugrundeliegende Perl-Modul/Lib zu kommen...

Gruß, Joachim

[Frank_Huber]

Meine Instanzen haben nicht so arg das Problem, aber einen Speicheranstieg sehe ich auch.
Die Instanz mit dem meisten Anstieg ist auch in der Tat die mit den meisten httpmod.
Aber jeweils nur ein oder zwei readings / Regex.

Gesendet von meinem S60 mit Tapatalk

[Eistee]

Ich glaube nicht das dies nur HTTPMOD betrifft. Ja ich verwende es auch aber das Problem sind diese nonblocking calls die, unter welchen Bedingungen auch immer, bestehen bleiben. die müsste man einfach nur mal ordentlich mit einem Time-out killen so das sie ihren speicher wieder freigeben und nicht einfach als Leichen hängen bleiben. bei mir macht z.B. auch das pioneeravr Probleme und die max Thermostate weil sie keine nonblocking calls mehr ausführen können (Limit erreicht). Da sehe ich vor allen wenn FHEM sich mal wieder fast weg gehangen hat und ich es noch schaffe einen shutdown restart zu machen.