Cannot fork: Cannot allocate memory | BlockingInformParent

[holle75]

@alle

kurze Info meinerseits. Seit (einigen?) Updates ist das Problem bei mir nicht mehr existent.

Leider kann ich nicht genau sagen, seit welchem update und an welchem Modul, oder welcher Kombi es gelegen hat.

Ich weiß, dass ist jetzt nur halb hilfreich, aber ich hatte mich mit dem regelmäßigen Neustart über notify abgefunden, es nicht mehr weiter überwacht und bin jetzt gerade nur positiv überrascht.

Gruß an euch
H.

[Rewe2000]

Hallo,

nachdem bei mir seit einigen Monaten Ruhe war, hat "Cannot fork: Cannot allocate memory" bei mir gestern auch wieder zugeschlagen.

Eigentlich sollte Fhem bei mir, nach auftreten des Fehlers automatisiert neu starten, dazu hatte ich mir ein notify nach Vorschlägen hier im Forum erstellt, doch irgendwie wurde dieses nicht getriggert. Habe ich da noch vergessen ein Attribut mit anzugeben oder passt das Suchmuster nicht?
Ich denke das Attribut "readLog" benötige ich hier nicht, da der Trigger ja vom Device global kommen sollte.

Kann mich bitte mal jemand erhellen, weshalb das notify den Neustart nicht ausgeführt hat.

Meldungen im Systemlog:

Code Auswählen Erweitern

.....
2020.07.19 00:33:23 1: Perfmon: possible freeze starting at 00:33:17, delay is 6.765
2020.07.19 00:33:23 3: ModbusTCPServer_Timeout, request: SimpleWrite [42 C9 00 00 00 06] 00 01 42 C9 00 08
2020.07.19 00:33:34 1: Perfmon: possible freeze starting at 00:33:32, delay is 2.143
2020.07.19 00:33:35 1: Cannot fork: Cannot allocate memory
2020.07.19 00:33:37 2: DbLog DBLogging - DBI connect('database=fhem;host=localhost;port=3306','Reinhard',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) at ./FHEM/93_DbLog.pm line 3085.

2020.07.19 00:33:37 1: Perfmon: possible freeze starting at 00:33:35, delay is 2.856
2020.07.19 00:33:38 2: DbLog DBLogging - DBI connect('database=fhem;host=localhost;port=3306','Reinhard',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) at ./FHEM/93_DbLog.pm line 3085.

2020.07.19 00:33:38 1: Cannot fork: Cannot allocate memory
......

Ein List meines notify:

Code Auswählen Erweitern

Internals:
   DEF        global:CANNOT_FORK { Log 3, "notify hat Cannot Fork Speicherfehler erkannt, Fhem wurde soeben neu gestartet!"; sleep 1; fhem "shutdown restart" }
   FUUID      5c47772f-f33f-7df9-2249-5ec9af4ccb759d04
   NAME       no_Fhem_Speicherfehler_Neustart
   NOTIFYDEV  global
   NR         244
   NTFY_ORDER 50-no_Fhem_Speicherfehler_Neustart
   REGEXP     global:CANNOT_FORK
   STATE      active
   TYPE       notify
   READINGS:
     2020-07-19 00:43:25   state           active
Attributes:
   DbLogExclude .*
   comment    Dieses notify startet Fhem neu, wenn der Trigger "CANNOT_FORK" (RAM-Speichermangel) vom Perl System gesendet wird.
Diesen notify soll vorübergehend das Speicherverbrauchsproblem durch Neustart von Fhem beheben, bis der Fehler gefunden und beseitigt wurde.
   group      Hardware
   icon       system_fhem_update
   room       System

Wäre es ev. besser und sicherer das notify so umzustellen, dass dieses mit readLog auf ein Suchmuster im Log selbst triggert oder was hat dies für Nachteile.

Gruß Reinhard

[der-Lolo]

Wenn im notify "CANNOT_FORK" groß geschrieben ist - im event aber "Cannot fork" steht kann das notify nicht schalten...

[Rewe2000]

Hallo der-Lolo,

ja dies ist mir schon klar, aber "Cannot fork" steht hier klein nur im Systemlog.
Aber wie ich es verstanden habe, ich triggere ja auf ein Event vom global Device mit "global:CANNOT_FORK". Leider habe ich versäumt bei Auftreten des Fehlers in den Eventmonitor zu gucken, welche Events hier kommen. Es könnte natürlich auch sein dass in dem Moment der Trigger nicht so gekommen ist.

Aber eigentlich sollte dies so passen, wenn ich Rudi da richtig verstanden habe, sollte so ein Event vom global Device kommen.
https://forum.fhem.de/index.php/topic,84372.msg846849.html#msg846849

Ich dachte mir auf ein Event zu triggern ist besser als ständig die Logeinträge durch das notify prüfen zu lassen.
Oder sehe ich da etwas falsch?

Gruß Reinhard

[MadMax-FHEM]

Das mit dem EVENT bei global sollte schon so sein/passen, bzw. ist es bei mir genauso, also: global:CANNOT_FORK shutdown restart

Allerdings ist mein Speicherproblem recht moderat, also (deutlich) über einen Monat bevor ich evtl. mal so eine Meldung bekomme...
Meistens habe ich aus anderen Gründen bereits mal neu gestartet, kann also nicht sagen, ob das mit dem Event noch funktioniert...
...aber hat mal!

Gruß, Joachim

[der-Lolo]

Ich habe damals als das problem noch akut bei mir vorhanden war auf den ram meiner DiskStaion mithilfe des Sysmon Moduls geschaut...

Ich wußte nicht wie der event zu CANNOT_FORK ausschaut...

[Rewe2000]

Hallo,
irgendwie kam die Meldung diesmal "anders".
Ich schreibe aktuell den RAM-Speicher und den SWAP-Speicher über sysmon mit, in der Vergangenheit hat der RAM-Speicher immer kontinuierlich abgenommen und dann kam der Fehler.
Dieses Mal war meiner Einschätzung nach noch mehr Speicher vorhanden (siehe Chart 00:33 Uhr) und wurde auch immer wieder freigegeben. War halt trotzdem nicht mehr ausreichend für die DBLog Aktion.

Deshalb würde ich schon gerne Fhem, automatisiert neu starten, denn auf die schnelle wird die Ursache nicht zu 100% behoben werden können. Und vor dem Rechner sitzt man auch nicht den ganzen Tag um das System zu beobachten.

Eigentlich hätte nach meinem Verständnis mein Fhem neu starten müssen, ich kan zumindest keinen Fehler im notify finden.
Wäre trotzden hilfreich die Ursache zu wissen, weshalb dies nicht geklappt hat, mir jedenfalls fällt da nichts auf, aber das soll nichts bedeuten.

Gruß Reinhard

[der-Lolo]

Das DOIF welches ich mit Sysmon einsetze läuft noch - auch wenn es wegen FHEM nicht mehr zum einsatz kommt...

Code Auswählen Erweitern

defmod RAMmsgAdjust DOIF ([DS716:ram:"Used: (\d+)"] > 2000) (msg push @rr_Michael Ram Auslastung angestiegen Neustart von FHEM ausführen)\
DOELSEIF ([$SELF:cmd] eq "1" and [XXXXXXXXXXX:msgText] eq "restart") (shutdown restart)\
DOELSE()\

attr RAMmsgAdjust group msg-adjust
attr RAMmsgAdjust room 97-Helper,99-Controller

setstate RAMmsgAdjust cmd_3
setstate RAMmsgAdjust 2020-07-19 16:50:51 Device DS716
setstate RAMmsgAdjust 2020-06-22 14:44:30 cmd 3
setstate RAMmsgAdjust 2020-06-22 14:44:30 cmd_event DS716
setstate RAMmsgAdjust 2020-06-22 14:44:30 cmd_nr 3
setstate RAMmsgAdjust 2020-07-19 16:50:51 e_DS716_ram Total: 7903.73 MB, Used: 795.12 MB, 10.06 %, Free: 311.71 MB
setstate RAMmsgAdjust 2020-07-16 17:24:17 e_XXXXXXXXX_msgText zu
setstate RAMmsgAdjust 2019-06-19 07:42:28 mode enabled
setstate RAMmsgAdjust 2020-06-22 14:44:30 state cmd_3


Ich habe halt eine message zu mir geschickt und nicht sofort einen shutdown restart ausgelöst...
Hauptsächlich aber um die sache dann genauer untersuchen zu können statt einfach neu zu starten.

[KNUT345]

Bei mir ist das Problem nun ebenfalls aufgetreten.
Ich hatte zuerst die SD-Karte in Verdacht, aber FHEM lief bei mir bis auf SYSMON mit dem ich mir am Raspberry Daten auslese,
z.B. Kernelauslastung, -temperatur usw.
Log-Files wurden geschrieben und Homematik lief eigentlich auch noch, eigentlich weil nicht alle Funktionen geprüft habe.

Nach einiger Recherche kam ich darauf, dass es Probleme mit FHEM und Stretch Lite gab, weil Memory nicht freigegeben wurde.
Shutdown Restart brachte keine Besserung. Sah dann immer noch so ähnlich aus.

Code Auswählen Erweitern

/opt/fhem/log$ free -m
              total        used        free      shared  buff/cache   available
Mem:            923         166         524          12         232         693
Swap:            99          99           0


Nach Raspberry Reboot sieht es nun besser aus.

Code Auswählen Erweitern

/opt/fhem/log$ free -m
              total        used        free      shared  buff/cache   available
Mem:            923         166         524          12         232         693
Swap:            99           0          99


Grüße
Knut

[rudolfkoenig]

Stretch verwendet (soweit ich sehe) perl 5.24, und diese Version hat Speicherloecher, wenn man bestimmte Regex-Varianten verwendet. Ich empfehle entweder ein OS Upgrade, oder eine andere Perl Version einzusetzen.

[KNUT345]

Danke für den Hinweis.
Jetzt nach Reboot sieht es erstmal unverändert gut aus.

Ich wundere mich wieder mal,
dass das System seit Installation 2018 diesen Fehler nicht gebracht hat
und das letzte FHEM update auch schon ein paar Tage her ist (15.06.2020).
Aber ja, es dauert evtl. ein paar Wochen bis das sich auswirkt.

Als ich den letzten Rechner mit Jessie Lite aufsetzen wollte hatte ich Probleme.
Werde das mal beobachten und dann ggf. erneut versuchen ein neueres Linux aufzuspielen.

Danke und Grüße
Knut

[hyper2910]

Stretch verwendet (soweit ich sehe) perl 5.24, und diese Version hat Speicherloecher, wenn man bestimmte Regex-Varianten verwendet. Ich empfehle entweder ein OS Upgrade, oder eine andere Perl Version einzusetzen.

Kann mal einer beschreiben wie man eine andere Perl Version installiert???

[frank]

am einfachsten ist sicherlich ein upgrade auf buster.
anleitungen für perl upgrade sind hier im thread.

[en-trust]

Nachdem ich mit perlbrew nicht zum Ziel kam, habe auch ich meinen Raspberry mit Buster und der neuen Perlversion neu aufgesetzt.

Code Auswählen Erweitern

pi@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster


Code Auswählen Erweitern

pi@raspberrypi:~ $ perl -v

This is perl 5, version 28, subversion 1 (v5.28.1) built for arm-linux-gnueabihf-thread-multi-64int
(with 61 registered patches, see perl -V for more detail)


Allerdings läuft mir der Speicher tgl. mehr voll.

Ich habe DBLogs nur auf die Thermometer laufen, habe mal einige devices wie sysmon abgeschalten.
Aber ich habe keinen Schimmer warum der Speicher voll läuft und vorallem, warum fhem keine Prozesse wieder frei gibt.

Hat jemand noch einen Tip ?

[Wernieman]

Wie hast Du mysql eingerichtet?
Wie viel Speicher braucht fhem/mysql?