Cannot fork: Cannot allocate memory | BlockingInformParent

[Wernieman]

Umgekehrte Frage: besser es sich, wenn Du das Modul "HUEBridge" wieder rausnimmst?

P.S. ausnahmsweise nach dem rausnehmen fhem rebooten ... um sicherzugehen

[Timmy.m]

Werde ich testen, habe durch freezemon gelernt, dass man alles rauswerfen muss, statt nur auf "inactive" zu setzen.
Lasse es erst mal eine Nacht so (ohne freezemon) laufen und werde berichten.

Grüße Tim

[Gerrit]

Die Huebridge läuft bei mir problemlos.

Gruß Gerrit

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

[Hardlife]

Leider hat´s mich wohl auch erwischt

Mein Sys:
- Raspberry Pi 3B
- Raspbian Jessie - alle Pakete aktuell
- Perl 5.20.2 (habe auch 5.20.3 per perlbrew versucht)

freezemon habe ich nicht installiert

Fehler ist reproduzierbar:
Immer, wenn ich auf den Raum "Everything" schalte, steigt der Ram-Verbrauch um ca. 2-3MB

-> Ich habe ein SD-Image vom 12.10.2018 aufgespielt (fhem per 12.10.2018 aktuell - raspbian Pakete per 12.10.2018 aktuell)
-> damit tritt der Fehler nicht auf
-> auch nicht, wenn ich alle Raspbian-Pakete aktualisiere

-> Fehler tritt auf, sobald ich FHEM auf aktuellen Stand bringe

Einzige, mir ersichtliche Auffälligkeit:
(weiß aber nicht, ob das was mit dem Fehler zu tun hat)
ein "fhemdebug memusage" ergibt über 3 Tage:
(man beachte "defs")

Code Auswählen Erweitern

   1. defs                                                               4100093                    4440206                 4549439
   2. modules                                                            1188353                    1207470                 1207691
   3. modules::eventTypes                                                 923419                     925738                  925738
   4. modules::eventTypes::ldata                                          922357                     924676                  924676
   5. attr                                                                603400                     610883                  612336
   6. defs::Homeserver_NextCloud_Kalender                                 383689                     383688                  383688     
   7. defs::Homeserver_NextCloud_Kalender::.fhem                          372843                     372843                  372843
   8. defs::Homeserver_NextCloud_Kalender::.fhem::iCalendar               340960                     340960                  340960
   9. defs::3_Stunden_Vorhersage_Proplanta_Wels                           317090                     333828                  334018
  10. defs::3_Stunden_Vorhersage_Proplanta_Wels::READINGS                 314433                     331914                  332104
  11. defs::calview_Homeserver_NextCloud_Kalender                         307956                     307956                  307956
  12. defs::calview_Homeserver_NextCloud_Kalender::READINGS               306660                     306660                  306660

Sonstige Werte:
(keine Auffälligkeiten ersichtlich - ja, ich habe eine umfangreiche Installation)

Code Auswählen Erweitern

{ int(keys %intAt) }   ==>> 96
{ int(keys %defs).":".int(keys %attr) }   ==>> 918:918


Gruß,
Hardlife

[Thorsten]

Vermutlich das hier:

Code Auswählen Erweitern

define nCannotForkRestart notify global:CANNOT_FORK shutdown restart

Gruß, Joachim

Ich habe das Notify bei mir auch eingestellt - es triggert, aber nach dem shutdown erfolgt kein restart.  Muss ich da etwas in irgendwelche Anführungszeichen schreiben?

[kadettilac89]

Ich habe das Notify bei mir auch eingestellt - es triggert, aber nach dem shutdown erfolgt kein restart.  Muss ich da etwas in irgendwelche Anführungszeichen schreiben?

wenn du shutdown restart in der befehlszeile eingibst - macht er dann einen restart? wenn nein, systemd fhem.service prüfen. gibt es posts im forum ...

[Kusselin]

Ich habe das Notify bei mir auch eingestellt - es triggert, aber nach dem shutdown erfolgt kein restart.  Muss ich da etwas in irgendwelche Anführungszeichen schreiben?

das gleiche habe/hatte ich auch....weiss auch nicht woran das liegt. bei den meisten macht er nach dem Shutdoen auch den restart...bei mir eben auch nicht...

egal...bei mir nmacht er einen restart..(es steht oben kurz das fhem die verbindung verloren jat für 5 sec. und dann steht fhem wieder auf der Hauptseite....also macht fhem einen restart...aber es funzt auch nicht mit dem notify...

wenn du shutdown restart in der befehlszeile eingibst - macht er dann einen restart? wenn nein, systemd fhem.service prüfen. gibt es posts im forum ...

schön das du ihm das hier postest...kannst ihm nicht dann auch gleich noch sagen was er in der systemd fhem.service einstellen/prüfen muss??

[Timmy.m]

Hatte auch Probleme, ich habe es so gelöst:

Code Auswählen Erweitern

define DI_Hauptspeicher DOIF (["global:CANNOT_FORK"])(shutdown restart)

Bezüglich dem RAM Verbrauch muss ich nochmal etwas mehr warten, schein wenn überhaupt nur noch minimal zu sein.

Grüße Tim

[kadettilac89]

egal...bei mir nmacht er einen restart..(es steht oben kurz das fhem die verbindung verloren jat für 5 sec. und dann steht fhem wieder auf der Hauptseite....also macht fhem einen restart...aber es funzt auch nicht mit dem notify...
schön das du ihm das hier postest...kannst ihm nicht dann auch gleich noch sagen was er in der systemd fhem.service einstellen/prüfen muss??

ok, mal gesucht ... https://forum.fhem.de/index.php/topic,82602.msg751694.html#msg751694
und ... nein, war nicht möglich da unterwegs, und auch nicht bekannt, ob thorsten das problem überhaupt hat. ging davon aus, dass mit den schlagworten die suche genutzt werden kann ...

bearbeiten auf der console möglich mit nano oder offline und datei tauschen

Code Auswählen Erweitern


sudo nano /etc/systemd/system/fhem.service


Code Auswählen Erweitern


systemctl daemon-reload


[Hardlife]

Hi!

konnte schon jemand einen Lösungsansatz/Workaround zum Thema RAM-Verbrauch identifizieren?
Wäre für Tipps dankbar.

Die neueste Raspbian soll ja auch keine Abhilfe schaffen, wie man so liest...
Bzw. sollte der Bug wohl ohnehin irgendwo in FHEM oder deren Modulen liegen (siehe meinen Vorpost)

Wie man an anhängigen Grafiken sieht, steigt mein RAM-Verbrauch langsam, aber kontinuierlich...
Immer soweit, bis der Pi sich "festfährt" und der Watchdog-Daemon den Pi neu startet...

Danke,
Hardlife

[rcmcronny]

Hi,

also bei mir lag es an den RegEx, die, ich hab leider kein Beispiel mehr, aber ich habe diese abgeändert und seitdem läuft es wieder korrekt.
Optisch war da nicht viel zu sehen, ich habs per wegnehmen und schauen nacheinander durchprobiert gehabt.

HTH,
Ronny

[frank]

moin,

ich habe zur zeit 2 verdächtige:

1. userreading mit modifier "integral"

Code Auswählen Erweitern

attr Broetje userReadings hzgGas:hzgBrennerMod:.* integral {ReadingsVal($NAME,"hzgBrennerMod",0)}
2. event-aggregator mit function "integral"

Code Auswählen Erweitern

attr Broetje userreadings hzgGas2:hzgBrennerMod:.* {ReadingsVal($NAME,"hzgBrennerMod",0)}
attr Broetje event-aggregator hzgGas2::const:integral:3600

falls es jemand nachstellen möchte, sind eventuell noch folgende attribute wichtig:

Code Auswählen Erweitern

attr Broetje event-min-interval hkTkomf:86400
attr Broetje event-on-change-reading .*
attr Broetje event-on-update-reading hzgTimeChanged,LAST_ERROR,MATCHED_READINGS


nach dem löschen der 3 attribute hatte ich über 28 std scheinbar keinen speicherverlust. sonst etwa 20MB.
da mein system nur einen sehr langsamen speicheranstieg zeigt, werden meine tests noch tage oder wochen dauern.
eventuell gibt es bei anderen mit intensivem gebrauch dieser funktionen deutlichere hinweise.

system: pi3B, jessie aktuell, perl 5.20.2

gruss frank

[Christoph Morrison]

Ich leide unter dem gleichen Problem und habe aktuell Devel::Leak::Object mitlaufen. Hier mal der Output nach so drei Stunden Laufzeit:

Code Auswählen Erweitern

Tracked objects by class:
DateTime::Format::Builder::Parser        2
DateTime::Format::Builder::Parser::Regex 63
DateTime::Infinite::Future               1
DateTime::Infinite::Past                 1
DateTime::Locale::FromData               2
DateTime::TimeZone::Floating             1
Encode::Guess                            1
Encode::Internal                         1
Encode::Unicode                          8
Encode::utf8                             2
FakeLocale                               1
HTML::Element::_travsignal               5
JSON::PP::Boolean                        2
Module::Pluggable::Object                1
RPC::XML::Parser::XMLParser              1
Specio::Coercion                         4
Specio::Constraint::AnyCan               6
Specio::Constraint::Enum                 10
Specio::Constraint::ObjectCan            3
Specio::Constraint::ObjectIsa            11
Specio::Constraint::Parameterizable      52
Specio::Constraint::Parameterized        2
Specio::Constraint::Simple               1282
Specio::Constraint::Union                7
Specio::DeclaredAt                       1377
Switch                                   2
Time::Piece                              2
Types::Serialiser::Error                 1
utf8                                     2

Sources of leaks:
DateTime::Format::Builder::Parser
     2 from /usr/share/perl5/DateTime/Format/Builder/Parser.pm line: 225
DateTime::Format::Builder::Parser::Regex
    63 from /usr/share/perl5/DateTime/Format/Builder/Parser/generic.pm line: 16
DateTime::Infinite::Future
     1 from /usr/lib/arm-linux-gnueabihf/perl5/5.24/DateTime/Infinite.pm line: 82
DateTime::Infinite::Past
     1 from /usr/lib/arm-linux-gnueabihf/perl5/5.24/DateTime/Infinite.pm line: 107
DateTime::Locale::FromData
     2 from /usr/share/perl5/DateTime/Locale.pm line: 276
DateTime::TimeZone::Floating
     1 from /usr/share/perl5/DateTime/TimeZone/Floating.pm line: 19
Encode::Guess
     1 from /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode/Guess.pm line: 10
Encode::Internal
     1 from /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line: 314
Encode::Unicode
     8 from /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode/Unicode.pm line: 37
Encode::utf8
     1 from /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line: 367
     1 from /usr/lib/arm-linux-gnueabihf/perl/5.24/Encode.pm line: 368
FakeLocale
     1 from /usr/lib/arm-linux-gnueabihf/perl5/5.24/DateTime/Infinite.pm line: 135
HTML::Element::_travsignal
     5 from /usr/share/perl5/HTML/Element.pm line: 85
JSON::PP::Boolean
     1 from /usr/share/perl5/Types/Serialiser.pm line: 124
     1 from /usr/share/perl5/Types/Serialiser.pm line: 125
Module::Pluggable::Object
     1 from /usr/local/share/perl/5.24.1/Module/Pluggable.pm line: 31
RPC::XML::Parser::XMLParser
     1 from /usr/share/perl5/RPC/XML/ParserFactory.pm line: 152
Specio::Coercion
     2 from /usr/share/perl5/Specio/OO.pm line: 296
     2 from Specio::Coercion->new line: 22
Specio::Constraint::AnyCan
     4 from /usr/share/perl5/Specio/OO.pm line: 296
     2 from Specio::Constraint::AnyCan->new line: 22
Specio::Constraint::Enum
     5 from /usr/share/perl5/Specio/OO.pm line: 296
     5 from Specio::Constraint::Enum->new line: 22
Specio::Constraint::ObjectCan
     2 from /usr/share/perl5/Specio/OO.pm line: 296
     1 from Specio::Constraint::ObjectCan->new line: 22
Specio::Constraint::ObjectIsa
     7 from /usr/share/perl5/Specio/OO.pm line: 296
     4 from Specio::Constraint::ObjectIsa->new line: 22
Specio::Constraint::Parameterizable
    48 from /usr/share/perl5/Specio/OO.pm line: 296
     4 from Specio::Constraint::Parameterizable->new line: 22
Specio::Constraint::Parameterized
     2 from Specio::Constraint::Parameterized->new line: 22
Specio::Constraint::Simple
  1245 from /usr/share/perl5/Specio/OO.pm line: 296
    37 from Specio::Constraint::Simple->new line: 22
Specio::Constraint::Union
     4 from /usr/share/perl5/Specio/OO.pm line: 296
     3 from Specio::Constraint::Union->new line: 22
Specio::DeclaredAt
  1317 from /usr/share/perl5/Specio/OO.pm line: 296
    60 from Specio::DeclaredAt->new line: 22
Switch
     1 from /usr/lib/arm-linux-gnueabihf/perl/5.24/Filter/Util/Call.pm line: 52
     1 from /usr/local/share/perl/5.24.1/Switch.pm line: 386
Time::Piece
     2 from /usr/lib/arm-linux-gnueabihf/perl/5.24/Time/Piece.pm line: 118
Types::Serialiser::Error
     1 from /usr/share/perl5/Types/Serialiser.pm line: 126
utf8
     2 from /usr/share/perl/5.24/utf8_heavy.pl line: 655

An der Interpretation arbeite ich noch ...

(perl 5, version 24, subversion 1, Debian Stretch)

[Hardlife]

Hi Christoph,

Bin leider in Perl etwas noob
Wie hast Du das "Devel::Leak::Object" implementiert?
Werden dann "Überläufe" gelistet?

Bitte halte uns über Deine Fortschritte auf dem Laufenden.
Ich trete hier so ziemlich auf der Stelle, echt frustrierend.

Ich arbeite hier an einem Produktivsystem im ziemlichen Endausbau (fhem.cfg = 594kB - ja, sind bereits optimiert).
Wenn ich nun anfange, zur Fehlerlokalisierung Part für Part zeitweise aus dem System zu nehmen, kollabiert mir erstens durch die Verwobenheit die Haussteuerung und zweitens würde ich dann mit dem Testen wohl 01.2020 fertig werden...

MFG,
Hardlife

[Christoph Morrison]

Wie hast Du das "Devel::Leak::Object" implementiert?

Das Modul muss über CPAN installiert und dann in die fhem.pl eingebunden werden. Sobald fhem.pl beendet wird, schreibt es die Statistiken ins Logfile.

Werden dann "Überläufe" gelistet?

Es werden Stellen gelistet, in denen Referenzen nicht richtig gelöscht werden können, siehe die Beschreibung. Es kann noch andere Ursachen geben, aber das war mein erster Schuss, nach dem fhemdebug memusage keinen hilfreichen Output lieferte - auch nach 10h Betrieb war da keine signifikante Änderung in der Speichernutzung festzustellen.

Bitte halte uns über Deine Fortschritte auf dem Laufenden.
Ich trete hier so ziemlich auf der Stelle, echt frustrierend.

Geht mir leider auch so

Ich arbeite hier an einem Produktivsystem im ziemlichen Endausbau (fhem.cfg = 594kB - ja, sind bereits optimiert).
Wenn ich nun anfange, zur Fehlerlokalisierung Part für Part zeitweise aus dem System zu nehmen, kollabiert mir erstens durch die Verwobenheit die Haussteuerung und zweitens würde ich dann mit dem Testen wohl 01.2020 fertig werden...

Sieht bei mir auch so aus, ich hab 880 definierte Entities am Start und ich kann das System auch nicht jede Stunde oder so neu starten. Die Probleme haben ziemlich sicher mit dem Upgrade auf Debian Stretch (und auf die genannte Perl-Version) begonnen.

Meine nächsten Schritte/Ideen sind:

• Mehrere Testsysteme, die Daten vom Livesystem über FHEM2FHEM bekommen, aber selbst keine Aktoren schalten können und dann sukzessive Abschaltung bis nichts mehr leckt. Schlecht weil ich ja die Sachen auch brauche, die ich habe ...
• Testen ob eine andere Perl-Version keine Leaks mehr hat (über perlbrew auf einer Testmaschine)
• Wechsel auf Debian Buster