FHEM Forum

FHEM => Frontends => Thema gestartet von: Burny4600 am 14 Februar 2018, 10:33:06

Titel: Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 14 Februar 2018, 10:33:06
Ich habe seit kurzem immer die Meldung Cannot fork: Cannot allocate memory im LOG, und auf FHEM kann ich mit dem Browaser nicht mehr zugreifen.
Nach einem Systemneustart ist zwar diese Meldung nicht mehr im LOG, taucht aber wieder nach einer gewissen Zeit wieder auf.
Es ist aber überall genügend Speicher an diesem Raspberry Pi 3. Auch gab es keine Änderungen unter FHEM.
Woher kommt dies Fehlermeldung.
2018.02.14 07:31:02.565 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:02.566 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:02.650 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:02.651 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:02.756 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:02.757 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:02.816 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:02.817 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:15.905 1: Perfmon: possible freeze starting at 07:31:04, delay is 11.905
2018.02.14 07:31:16.050 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:16.051 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:16.066 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:16.068 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:16.083 1: Cannot fork: Cannot allocate memory
2018.02.14 07:31:16.084 1: Cannot fork: Cannot allocate memory


Auch mit dieser Fehlermeldung kann ich nichts anfangen.

2018.02.14 10:08:40.299 1: BlockingInformParent (BlockingRegisterTelnet): Can't connect to localhost:37053: IO::Socket::INET: connect: Connection refused
2018.02.14 10:08:40.539 1: BlockingInformParent (BlockingRegisterTelnet): Can't connect to localhost:37053: IO::Socket::INET: connect: Connection refused
2018.02.14 10:08:43.502 1: BlockingInformParent (BlockingStart): Can't connect to localhost:37053: IO::Socket::INET: connect: Connection refused
2018.02.14 10:08:43.505 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:37053: IO::Socket::INET: connect: Connection refused
2018.02.14 10:08:43.623 1: BlockingInformParent (BlockingStart): Can't connect to localhost:37053: IO::Socket::INET: connect: Connection refused
2018.02.14 10:08:43.625 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:37053: IO::Socket::INET: connect: Connection refused
2018.02.14 10:09:15 2: Perfmon: ready to watch out for delays greater than one second

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 14 Februar 2018, 10:40:16
Bitte verwende die Suche. Es gibt reichlich Threads zu diesem Thema. Auch intensivere wo Rudi einiges zum aufspüren dieser Meldungen geschrieben hat. Gerade im Zusammenspiel mit BlockingCall und der Begrenzung der maximalen Aufrufe von BlockingCall's.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 14 Februar 2018, 13:15:42
Mehr als Reichliche Threads gibt es, da hast recht.
Kannst du mir mitteilen welche der Threads auch zum Ziel führt.
Ich habe schon vieles durch, nur der richtige war nicht dabei.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 14 Februar 2018, 14:18:34
Kann ich aktuell leider nicht. Bin nur mit Handy unterwegs
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 14 Februar 2018, 14:20:51
Was mir so pauschal dezu einfällt: Verwendest Du PRESENCE mit Ping?
Titel: cpanm Devel::Size
Beitrag von: Burny4600 am 14 Februar 2018, 14:51:32
@Wernieman
ZitatWas mir so pauschal dezu einfällt: Verwendest Du PRESENCE mit Ping?
PRESENCE läuft auf diesem System auch.
An diesem Master Raspberry kommen auch zusätzlich via FHEM2FHEM LOG auch davon PRESENCE durch und werden dazu wahrscheinlich nicht relefant sein.

An einem der Slave Raspberrys, der eigentlich kaum etwas zu tun hat ausser 3 St. PID 20, fällt mir das schon länger auf.
Mir fällt es an diesem Gerät aber erst dann auf wenn ich wieder einmal ein Update starte.

Ich denke das ich den Link den CoolTux gemeint hat
https://forum.fhem.de/index.php/topic,73490.15.html
gefunden zu haben.

Ich habe aber nur soviel herausbekommen, das jedenfalls beim Master ich ziemlich über die Grenzen das System strapaziere.
{ int(keys %intAt) } => 237

{ int(keys %defs).":".int(keys %attr) }  =>  1549:1549

{ join("\n", map { "$intAt{$_}{TRIGGERTIME} / $intAt{$_}{FN}" } (sort {$intAt{$a}{TRIGGERTIME}<=>$intAt{$b}{TRIGGERTIME}} keys %intAt)[0..49]) }
1518615744.26178 / I2C_SUSV_Poll_GPIO
1518615744.78934 / PRESENCE_StartLocalScan
1518615745 / perfmon_ProcessTimer
1518615751 / FW_closeInactiveClients
1518615751.83152 / Twilight_sunpos
1518615752.79756 / GPIO4_DeviceUpdateLoop
1518615753.47288 / PRESENCE_StartLocalScan
1518615753.50295 / PRESENCE_StartLocalScan
1518615753.5213 / PRESENCE_StartLocalScan
1518615753.82155 / PRESENCE_StartLocalScan
1518615753.83779 / GPIO4_DeviceUpdateLoop
1518615753.8391 / PRESENCE_StartLocalScan
1518615753.90618 / PRESENCE_StartLocalScan
1518615754.12509 / HTTPMOD_GetUpdate
1518615754.14932 / HMUARTLGW_CheckCredits
1518615754.16409 / HMUARTLGW_CheckCredits
1518615754.37304 / I2C_SUSV_Poll
1518615754.37329 / HTTPMOD_GetUpdate
1518615754.38215 / SYSMON_Update
1518615754.45656 / JSONMETER_GetUpdate
1518615755.811 / HMUARTLGW_CheckCredits
1518615756.26038 / HMUARTLGW_CheckCredits
1518615757.87214 / JSONMETER_GetUpdate
1518615757.90599 / JSONMETER_GetUpdate
1518615757.96055 / JSONMETER_GetUpdate
1518615758.01695 / JSONMETER_GetUpdate
1518615758.06349 / SIGNALduino_KeepAlive
1518615770.80646 / ENIGMA2_GetStatus
1518615770.80935 / ENIGMA2_GetStatus
1518615770.81208 / ENIGMA2_GetStatus
1518615796.94036 / at_Exec
1518615799.11965 / BlockingKill
1518615800.62754 / BlockingKill
1518615817.6202 / CUL_HM_ActCheck
1518615900 / DOIF_TimerTrigger
1518616032.56201 / DOIF_SleepTrigger
1518616040.82006 / DOIF_SleepTrigger
1518616095.60928 / DOIF_SleepTrigger
1518616248.44993 / DOIF_SleepTrigger
1518616248.51569 / DOIF_SleepTrigger
1518616248.55611 / DOIF_SleepTrigger
1518616248.59531 / DOIF_SleepTrigger
1518616263.53557 / PRESENCE_StartLocalScan
1518616268.11656 / DOIF_SleepTrigger
1518616268.27118 / DOIF_SleepTrigger
1518616270.06355 / PRESENCE_StartLocalScan
1518616395.56442 / DOIF_SleepTrigger
1518616395.65279 / DOIF_SleepTrigger
1518616395.68724 / DOIF_SleepTrigger
1518616395.72196 / DOIF_SleepTrigger


{ join("\n", map { "$intAt{$_}{TRIGGERTIME} / $intAt{$_}{FN}" } (sort {$intAt{$b}{TRIGGERTIME}<=>$intAt{$a}{TRIGGERTIME}} keys %intAt)[0..49]) }
1520291700 / HTTPMOD_GetUpdate
1518872663.77136 / DOIF_SleepTrigger
1518861726.13669 / DOIF_SleepTrigger
1518702300 / DOIF_TimerTrigger
1518701400 / DOIF_TimerTrigger
1518700500 / DOIF_TimerTrigger
1518698394 / DOIF_TimerTrigger
1518697038 / DOIF_TimerTrigger
1518697038 / DOIF_TimerTrigger
1518694794 / DOIF_TimerTrigger
1518694794 / DOIF_TimerTrigger
1518694794 / DOIF_TimerTrigger
1518693438 / DOIF_TimerTrigger
1518693438 / DOIF_TimerTrigger
1518693000 / DOIF_TimerTrigger
1518692400 / DOIF_TimerTrigger
1518692400 / DOIF_TimerTrigger
1518691194 / DOIF_TimerTrigger
1518691194 / DOIF_TimerTrigger
1518691194 / DOIF_TimerTrigger
1518689838 / DOIF_TimerTrigger
1518689838 / DOIF_TimerTrigger
1518688820 / DOIF_TimerTrigger
1518688800 / DOIF_TimerTrigger
1518688800 / DOIF_TimerTrigger
1518688800 / DOIF_TimerTrigger
1518687594 / DOIF_TimerTrigger
1518687594 / DOIF_TimerTrigger
1518687594 / DOIF_TimerTrigger
1518686238 / DOIF_TimerTrigger
1518686238 / DOIF_TimerTrigger
1518684600 / DOIF_TimerTrigger
1518684300 / DOIF_TimerTrigger
1518683994 / DOIF_TimerTrigger
1518683994 / DOIF_TimerTrigger
1518683994 / DOIF_TimerTrigger
1518682800 / DOIF_TimerTrigger
1518682638 / DOIF_TimerTrigger
1518682638 / DOIF_TimerTrigger
1518682500 / DOIF_TimerTrigger
1518681600 / DOIF_TimerTrigger
1518681600 / DOIF_TimerTrigger
1518681600 / DOIF_TimerTrigger
1518681600 / DOIF_TimerTrigger
1518681600 / DOIF_TimerTrigger
1518681600 / DOIF_TimerTrigger
1518681000 / DOIF_TimerTrigger
1518680394 / DOIF_TimerTrigger
1518680394 / DOIF_TimerTrigger
1518680394 / DOIF_TimerTrigger


{ join(",", grep { !$defs{$_} } sort keys %attr) }
XXX


list TYPE=FHEMWEB
WEB
WEB_192.168.17.40_62860
WEB_192.168.17.46_7736
WEBphone
WEBtablet


fhemdebug memusage
   1. defs                            8155729
   2. modules                         1875948
   3. modules::eventTypes             1529659
   4. modules::eventTypes::ldata      1528597
   5. attr                            1468674
   6. FW_RET                           295938
   7. defs::Wetter                     255109
   8. defs::Wetter::READINGS           253134
   9. defs::battStatus                  99103
  10. defs::SabStatus                   98797
  11. defs::SenRSSI                     98687
  12. defs::battStatus::CONTENT         90946
  13. defs::SenRSSI::CONTENT            90946
  14. defs::SabStatus::CONTENT          90946
  15. defs::UEST1VG_EG_STH              73965
  16. oldvalue                          60980
  17. defs::UEST1VG_EG_STH::READINGS    59494
  18. defs::ActionDetector              51965
  19. defs::SATReceiver_EG_WZ           51296
  20. defs::SATReceiver_OG1_WZ          49434
  21. defs::sysmon                      47234
  22. defs::DL2                         43767
  23. modules::CUL_HM                   40917
  24. POSIX::                           37247
  25. defs::SATReceiver_EG_WZ::READINGS    37174
  26. defs::BATALD                      36890
  27. defs::BATALD::READINGS            36056
  28. defs::myTwilight                  35687
  29. defs::SATReceiver_OG1_WZ::READINGS    33853
  30. defs::OG1_SL_HZG_TC_Climate       33284
  31. defs::EG_WZ_HZG_TC_Climate        33279
  32. defs::OG1_KU_HZG_TC_Climate       33278
  33. defs::OG1_KI_HZG_TC_Climate       33240
  34. defs::OG2_BU2_HZG_TC_Climate      33182
  35. defs::OG2_BU1_HZG_TC_Climate      33134
  36. defs::EG_KU_HZG_TC_Climate        33121
  37. defs::OG1_WZ_HZG_TC_Climate       33099
  38. defs::SATReceiver_OG1_SL          33046
  39. defs::AB_P_ZPHZST                 32142
  40. defs::SATReceiver_OG1_SL::READINGS    31868
  41. defs::sysmon::READINGS            31406
  42. defs::R_OG1_KI_ST                 31358
  43. defs::OG2_BU2_HZG_RT1_Clima       30845
  44. defs::OG1_SL_HZG_TC_Climate::READINGS    30176
  45. defs::EG_WZ_HZG_TC_Climate::READINGS    30173
  46. defs::OG1_KU_HZG_TC_Climate::READINGS    30170
  47. defs::OG1_KI_HZG_TC_Climate::READINGS    30132
  48. defs::OG1_WZ_HZG_TC_Climate::READINGS    30126
  49. defs::OG2_BU2_HZG_TC_Climate::READINGS    30044
  50. defs::OG2_BU1_HZG_TC_Climate::READINGS    30020


pi@ccs-ht-rasp01:~ $ ps -elf | sort -rnk 10 | head
1 S fhem       905     1 80  80   0 - 33987 -      10:20 pts/0    03:38:08 perl fhem.pl fhem.cfg
1 S fhem     17246   905  8  80   0 - 33987 -      14:50 pts/0    00:00:00 perl fhem.pl fhem.cfg
5 S root     11009   646  0  80   0 - 10578 -      13:09 ?        00:00:01 /usr/sbin/smbd
5 S root       703   646  0  80   0 - 10492 -      10:11 ?        00:00:47 /usr/sbin/smbd
5 S root       646     1  0  80   0 - 10166 -      10:09 ?        00:00:00 /usr/sbin/smbd
1 S root       650   646  0  80   0 - 10163 -      10:09 ?        00:00:00 /usr/sbin/smbd
1 S root       648   646  0  80   0 -  9665 -      10:09 ?        00:00:00 /usr/sbin/smbd
5 S root       647   646  0  80   0 -  9662 -      10:09 ?        00:00:03 /usr/sbin/smbd
4 S root       123     1  0  80   0 -  7089 -      10:08 ?        00:00:00 /lib/systemd/systemd-journald
5 S root       513     1  0  80   0 -  6619 -      10:09 ?        00:00:01 /usr/sbin/nmbd


Wenn nur das PRESENCE daran schuld sein sollte kann ich es auch an einen Slave auslagern.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 14 Februar 2018, 15:00:49
Ich weiß nur, das in der Vergangenheit bei einem PI andere User genau mit geforkten pings Probleme hatten ....
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 14 Februar 2018, 16:25:44
Ich habe die PRESENCE auf einen Slave ausgelagert.
Dies hatte ich ohnehin in der nächsten Zeit vor.

Unklar ist mir nur wieso es bei einem anderen Raspberry, der nur die PID20 zu verarbeiten hat, diese Cannot fork: Cannot allocate memory Meldungen schon länger hat.

Vielleicht ergeben sich noch Lösungsansätze.
Beim Master Raspberry denke ich wird sich das bald zeigen ob es an diesen PRESENCE Definitionen lag.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 14 Februar 2018, 21:14:51
Wie lange ist dein FHEM-update her? Ich habe fhemdebug memusage umgebaut, die alte Version hat gerne Sachen doppelt gezaehlt. Was sagt BlockingInfo? Und (in FHEM eingegeben): { `ps -elf | grep fhem` }
Aus den bisherigen Angaben kann ich leider keine Ursache ableiten.

Die Meldung "Can't connect to localhost:37053:... connection refused" kann ich auch nicht wirklich erklaeren. Nur mit "localhost zeigt nicht auf die aktuelle Maschine", was hoffentlich nicht wahr ist.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 15 Februar 2018, 16:18:00
@rudolfkönig
FHEM Updates sind aktuell.
In der Zwischenzeit habe ich alle PRESENCE auf ein Slave System übertragen was derzeit kaum etwas zu tun hat.

Derzeit ist wieder Ruhe eingekehrt und auch auf dem Slave System ist derzeit nichts auffälliges.
Wie ich bei den Updates heute gesehn habe wurde eine neu PRESENCE.pm eingespielt.

Ich weiß nicht ob das jetzt noch hilfreich ist was bei den Abfragen herauskommt.
Ich habe diese jetzt auf dem Slave Gerät wo PRESENCE läuft abgerufen.

{ `ps -elf | grep fhem` }
1 S fhem      2190     1 24  80   0 - 23605 -      15:39 pts/0    00:05:31 perl fhem.pl fhem.cfg
0 S fhem      2862  2190  0  80   0 -   475 wait   16:02 pts/0    00:00:00 sh -c ps -elf | grep fhem
0 R fhem      2863  2862  0  80   0 -  1934 -      16:02 pts/0    00:00:00 ps -elf
0 S fhem      2864  2862  0  80   0 -  1093 pipe_w 16:02 pts/0    00:00:00 grep fhem


BlockingInfo?
Pid:813 Fn:PRESENCE_DoLocalPingScan Arg:OG2_FR_EDVAWE02|192.168.17.40|0|4 Timeout:60 ConnectedVia:telnetForBlockingFn_1518625271_127.0.0.1_45604

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 15 Februar 2018, 17:41:10
Die Ausgaben sind z.Zt. unauffaellig, und sind eher im Problemfall hilfreich.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 18 Februar 2018, 09:48:33
Hallo Rudi,

ich habe seit dem Umstieg auf Raspbian Stretch ebenfalls das Problem dass der Speicher zunehmend verbraucht wird (siehe Screenshot) und ab ca. 50% Speicherbelegung erscheint die Fehlermeldung "Cannot fork: Cannot allocate memory" im Logfile.
Nehme ich die gleiche Config und lasse es unter Jessie laufen, ist alles i.O.

BlockingInfo:
Pid:9560 Fn:DbLog_PushAsync Arg:logdb|************************************************ Timeout:86400 ConnectedVia:telnetPort_127.0.0.1_59526

{ `ps -elf | grep fhem` }
1 S fhem       480     1 20  80   0 - 84744 -      Feb17 ?        02:53:46 perl fhem.pl fhem.cfg
0 S fhem      9891   480  0  80   0 -   475 wait   09:44 ?        00:00:00 sh -c ps -elf | grep fhem
0 R fhem      9892  9891  0  80   0 -  2035 -      09:44 ?        00:00:00 ps -elf
0 S fhem      9893  9891  0  80   0 -  1194 -      09:44 ?        00:00:00 grep fhem


fhemdebug memusage:
1. defs                            6132399
   2. modules                         1420446
   3. modules::eventTypes             1083021
   4. modules::eventTypes::ldata      1081959
   5. attr                             319187
   6. defs::EG_Jalousie_AZ_kl          250113
   7. defs::WetterWolfsburg            243123
   8. defs::WetterWolfsburg::READINGS   240596
   9. defs::Markise                    237808
  10. defs::EG_Jalousie_AZ_kl::READINGS   230311
  11. defs::Markise::READINGS          221912
  12. defs::EG_Jalousie_AZ_gr          199840
  13. defs::EG_Jalousie_WC             197810
  14. defs::EG_Jalousie_AZ_gr::READINGS   178637
  15. defs::EG_Jalousie_WC::READINGS   178200
  16. defs::EG_Jalousie_Kueche         146360
  17. defs::EG_Jalousie_Terasse_gr     145712
  18. defs::EG_Jalousie_Terasse_kl     145708
  19. defs::EG_Jalousie_Kueche::READINGS   125170
  20. defs::EG_Jalousie_Terasse_gr::READINGS   124732
  21. defs::EG_Jalousie_Terasse_kl::READINGS   124732
  22. defs::EG_Jalousie_WZ_1           119918
  23. defs::OG_Jalousie_KZ2            113840
  24. defs::OG_Jalousie_KZ1            113802
  25. defs::OG_Jalousie_SZ             113082
  26. defs::Heizung                    111141
  27. defs::logdb                      104546
  28. defs::myStatDevice               103800
  29. defs::myStatDevice::READINGS     102135
  30. defs::FritzBox_7490              101821
  31. defs::Lichtschalter_OG_KZ2       101692
  32. defs::EG_Jalousie_WZ_1::READINGS    98750
  33. defs::OG_Jalousie_KZ1::READINGS    96469
  34. defs::OG_Jalousie_KZ2::READINGS    96469
  35. defs::OG_Jalousie_SZ::READINGS    96044
  36. defs::Lichtschalter_OG_KZ1        95172
  37. defs::EG_Jalousie_WZ_2            94536
  38. defs::OG_Jalousie_Galerie         88434
  39. defs::OG_Jalousie_Bad             88411
  40. defs::Lichtschalter_OG_KZ2::READINGS    80911
  41. defs::WUWeather                   79572
  42. defs::Lichtschalter_OG_KZ1::READINGS    78626
  43. defs::WUWeather::READINGS         78578
  44. defs::Lichtschalter_Terasse_gross    76503
  45. defs::Dunstabzug                  75274
  46. defs::EG_Jalousie_WZ_2::READINGS    73357
  47. defs::sysmon                      72069
  48. defs::OG_Jalousie_Galerie::READINGS    71072
  49. defs::OG_Jalousie_Bad::READINGS    71072
  50. defs::logdb::cache                69386
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 18 Februar 2018, 10:45:34
Es waeren zwei Messpunkte mit memusage und ps interessant: kurz nach FHEM-Start, und kurz vor oder nach Auftreten des Problems.

Die blockinginfo und die ps Ausgaben sind widerspruechlich.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 18 Februar 2018, 11:20:09
Hallo Rudi,

die

Die Auszüge im Post vorher sind bei aktivem Fehler gewesen, hier das Ganze nach einem Neustart:

fhemdebug memusage:
1. defs                            5499111
   2. modules                         1418230
   3. modules::eventTypes             1083467
   4. modules::eventTypes::ldata      1082405
   5. attr                             317251
   6. defs::EG_Jalousie_AZ_kl          247039
   7. defs::WetterWolfsburg            243051
   8. defs::WetterWolfsburg::READINGS   240596
   9. defs::Markise                    236971
  10. defs::EG_Jalousie_AZ_kl::READINGS   230201
  11. defs::Markise::READINGS          221915
  12. defs::EG_Jalousie_AZ_gr          195323
  13. defs::EG_Jalousie_WC             194914
  14. defs::EG_Jalousie_AZ_gr::READINGS   178505
  15. defs::EG_Jalousie_WC::READINGS   178092
  16. defs::EG_Jalousie_Kueche         143288
  17. defs::EG_Jalousie_Terasse_gr     141427
  18. defs::EG_Jalousie_Terasse_kl     141400
  19. defs::EG_Jalousie_Kueche::READINGS   125060
  20. defs::EG_Jalousie_Terasse_kl::READINGS   124599
  21. defs::EG_Jalousie_Terasse_gr::READINGS   124599
  22. defs::EG_Jalousie_WZ_1           117065
  23. defs::OG_Jalousie_SZ             110759
  24. defs::myStatDevice               103525
  25. defs::OG_Jalousie_KZ1            102826
  26. defs::OG_Jalousie_KZ2            102826
  27. defs::myStatDevice::READINGS     101863
  28. defs::EG_Jalousie_WZ_1::READINGS    98640
  29. defs::Lichtschalter_OG_KZ2        96720
  30. defs::OG_Jalousie_KZ2::READINGS    96220
  31. defs::OG_Jalousie_KZ1::READINGS    96220
  32. defs::OG_Jalousie_SZ::READINGS    95958
  33. defs::Lichtschalter_OG_KZ1        92704
  34. defs::EG_Jalousie_WZ_2            91669
  35. defs::OG_Jalousie_Bad             86113
  36. defs::Lichtschalter_OG_KZ2::READINGS    80749
  37. defs::WUWeather                   79556
  38. defs::WUWeather::READINGS         78578
  39. defs::Lichtschalter_OG_KZ1::READINGS    78537
  40. defs::OG_Jalousie_Galerie         77435
  41. defs::Dunstabzug                  75528
  42. defs::Lichtschalter_Terasse_gross    74995
  43. defs::Heizung                     73540
  44. defs::EG_Jalousie_WZ_2::READINGS    73247
  45. defs::OG_Jalousie_Bad::READINGS    70988
  46. defs::OG_Jalousie_Galerie::READINGS    70823
  47. defs::Lichtschalter_EG_WZ         64652
  48. defs::sysmon                      63796
  49. defs::Lichtschalter_Terasse_gross::READINGS    62845
  50. defs::Dunstabzug::READINGS        61405


{ `ps -elf | grep fhem` }:
1 S fhem       493     1 34  80   0 - 27958 -      11:14 ?        00:01:03 perl fhem.pl fhem.cfg
1 S fhem      1160   493  4  80   0 - 27958 -      11:18 ?        00:00:00 perl fhem.pl fhem.cfg
0 S fhem      1165   493  0  80   0 -   475 wait   11:18 ?        00:00:00 sh -c ps -elf | grep fhem
0 R fhem      1166  1165  0  80   0 -  2035 -      11:18 ?        00:00:00 ps -elf
0 S fhem      1167  1165  0  80   0 -  1194 -      11:18 ?        00:00:00 grep fhem


Die blockinginfo und die ps Ausgaben habe ich direkt hintereinander abgerufen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 18 Februar 2018, 11:58:09
Da die beiden memusage Angaben aehnlich sind, die ps Angaben aber sehr unterschiedlich, kann man in diesem Fall memusage vegessen.
Wieviel Speicher steht zur Verfuegung (Ausgabe von free)? Mit fhem.pl < 90MB im Fehlerfall muessen entweder viele Blocking Prozesse parallel gestartet werden, oder der Speicher ist anderweitig voll.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 18 Februar 2018, 12:06:38
Hier schon mal die Werte nach einem Neustart:

total        used        free      shared  buff/cache   available
Mem:         949476      207172      546480       21624      195824      669700
Swap:        102396           0      102396


und die zugehörigen ps Angaben:
1 S fhem       466     1 20  80   0 - 27273 -      11:44 ?        00:04:15 perl fhem.pl fhem.cfg
1 S fhem      1578   466  0  80   0 - 27314 -      12:03 ?        00:00:00 perl fhem.pl fhem.cfg
0 S fhem      1617   466  0  80   0 -   475 wait   12:04 ?        00:00:00 sh -c ps -elf | grep fhem
0 R fhem      1618  1617  0  80   0 -  2035 -      12:04 ?        00:00:00 ps -elf
0 S fhem      1619  1617  0  80   0 -  1194 pipe_w 12:04 ?        00:00:00 grep fhem



Werte im Fehlerfall reiche ich heute Abend odre morgen nach.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 18 Februar 2018, 17:09:59
nimm bei ps mal, anstatt "-elf", den aux:
ps aux
Dort steht (meiner Meinung nach) der Memory Verbrauch "besser" drin
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 19 Februar 2018, 06:33:21
Hallo Rudi,

hier die Daten im Fehlerfall:

ps -elf:
1 S fhem       472     1 21  80   0 - 92575 -      Feb18 ?        03:19:41 perl fhem.pl fhem.cfg
1 S fhem     32522   472  0  80   0 - 92641 -      06:29 ?        00:00:00 perl fhem.pl fhem.cfg
0 S fhem     32584   472  0  80   0 -   475 wait   06:30 ?        00:00:00 sh -c ps -elf | grep fhem
0 R fhem     32585 32584  0  80   0 -  2035 -      06:30 ?        00:00:00 ps -elf
0 S fhem     32586 32584  0  80   0 -  1194 pipe_w 06:30 ?        00:00:00 grep fhem


ps -aux
fhem       472 21.4 37.9 370556 360452 ?       S    Feb18 200:04 perl fhem.pl fhem.cfg
fhem     32522  0.1 37.5 370564 356064 ?       S    06:29   0:00 perl fhem.pl fhem.cfg
fhem     32657  0.0  0.0   1900   372 ?        S    06:32   0:00 sh -c ps -aux | grep fhem
fhem     32658  0.0  0.3   8140  2944 ?        R    06:32   0:00 ps -aux
fhem     32659  0.0  0.0   4776   556 ?        S    06:32   0:00 grep fhem


free:
              total        used        free      shared  buff/cache   available
Mem:         949476      604236       83648       21744      261592      271516
Swap:        102396        6144       96252



Im log sind jetzt sehr viele von folgenden Meldungen:
2018.02.19 07:05:39 4: Closing connection WEB_192.168.178.97_61103 due to full buffer in FW_Notify
2018.02.19 07:05:39 4: Closing connection WEBtablet_192.168.178.23_45706 due to full buffer in FW_Notify
2018.02.19 07:05:39 4: Closing connection WEBtablet_192.168.178.92_34340 due to full buffer in FW_Notify
2018.02.19 07:05:39 4: Closing connection WEB_192.168.178.97_61103 due to full buffer in FW_Notify
2018.02.19 07:05:39 4: Closing connection WEBtablet_192.168.178.23_45706 due to full buffer in FW_Notify
2018.02.19 07:05:39 4: Closing connection WEBtablet_192.168.178.92_34340 due to full buffer in FW_Notify
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 19 Februar 2018, 09:23:20
ZitatFW_Notify
Was macht das?

FHEM braucht laut Deiner Anzeige c.a. 75% des Speichers ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 19 Februar 2018, 10:38:21
Wenn ich "man ps" richtig verstehe, dann hat dein FHEM mit 110MB (27k*4k) gestartet, und ist in ca 18 Stunden auf 360MB (in ps -elf: 92k*4k) gewachsen. Macht im Durchschnitt 240k Speicherverlust pro Minute, mAn sehr viel. Im Durchschnitt hat es auch 18%CPU verbraucht.

Zitat2018.02.19 07:05:39 4: Closing connection WEB_192.168.178.97_61103 due to full buffer in FW_Notify
FHEMWEB versucht Clients via longpoll bzw. websocket zu benachrichtigen, diese nehmen die Daten aber nicht ab. Falls der Zwischenpuffer 100k uebersteigt, wird die Verbindung gekappt. Merkwuerdig: alle drei Clients (XX.XX.XX.97, 23, 92) haben jeweils eine longpoll Verbindung zu zwei unterschiedlichen FHEMWEB Instanzen offen.

Habe im Moment keine Idee, woran es liegen koennte, evtl. hilft ein "list .* TYPE", um eine Ahnung von der Menge und Art der Geraete zu kriegen.
Du koenntest natuerlich auch mit der groben Methode der "Reihe nach Abschaltung einzelner Module" das Problem eingrenzen.

Zur Klarstellung an "Neulinge": mein Produktions-FHEM laeuft normalerweise mehrere Monate lang ohne Neustart, CPU ist unter 1%.
Ich will ab und zu mein Code selbst testen, deswegen starte ich FHEM neu.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 19 Februar 2018, 13:46:34
Hallo Rudi,

das mit dem Abschalten einzelner Module habe ich auch schon  begonnen, leider habe ich die Befürchtung dass es eines der Essentiellen Module wie FHEMWEB oder DBLOG ist, welche ich nicht abschalten möchte.
Was mich wundert ist eben dass das Problem unter Stretch immer da ist (hab schon 5 oder 6 mal alles neu aufgesetzt), unter Jessie aber absolut stabil läuft.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 20 Februar 2018, 10:40:41
@rudolfkönig

Ich habe mir die Jessie Installation angesehen welcher PI welches Image bekommen hat.
Alle Jessie Lite haben den Fehler Cannot fork: Cannot allocate memory nicht.
Die beiden letzten neu aufgesetzten Jessie Strech Lite bingen immer wieder nach längerer Laufzeit Cannot fork: Cannot allocate memory.
Bei einem System habe ich die Speicher Belegungen nach dem Neustart und dem Lauf nach einem Tag festgehalten.

ccs-ht-rasp02 nach NEUSTART
list .* TYPE
AB_FR_HZG_PFA2H          readingsProxy
AB_FR_HZG_PFA2HD         dummy
AB_FR_HZG_PFA2HN         notify
AB_P_DS                  readingsProxy
AB_P_DSFRD               dummy
AB_P_DSFRN               notify
AB_P_PP_STS              readingsProxy
AB_P_PP_STSD             dummy
AB_P_PP_STSN             notify
AB_P_ST_DT09T04D         dummy
AB_P_ST_PPPA2            readingsProxy
AB_P_ST_PPPA2.PID        PID20
AB_P_ST_PPPA2.PID.File     FileLog
AB_P_ST_PPPA2.PID.PWMST     DOIF
AB_P_ST_PPPA2.PID.PWMST.File     FileLog
AB_P_ST_PPPA2.PIDD       dummy
AB_P_ST_PPPFA2.PIDST     DOIF
AB_P_ST_PPPFA2D          dummy
AB_P_ST_V2               readingsProxy
AB_P_ST_V2D              dummy
AB_P_ST_V2N              notify
AB_P_ZP                  readingsProxy
AB_P_ZPFSD               dummy
AB_P_ZPFSN               notify
AB_P_ZPHZD               dummy
AB_P_ZPHZN               notify
AB_P_ZPPSD               dummy
AB_P_ZPPSN               notify
AB_SSP_ST_V1             readingsProxy
AB_SSP_ST_V1D            dummy
AB_SSP_ST_V1DN           notify
Aktueller_Verbrauch      readingsGroup
DL2                      HTTPMOD
DL2_CS10                 readingsProxy
DL2_R1                   readingsProxy
DL2_R2                   readingsProxy
DL2_R3                   readingsProxy
DL2_R4                   readingsProxy
DL2_R5                   readingsProxy
DL2_R6                   readingsProxy
DL2_R7                   readingsProxy
DL2_R8                   readingsProxy
DL2_R9                   readingsProxy
DL2_SZ                   readingsProxy
DL2_T01                  readingsProxy
DL2_T02                  readingsProxy
DL2_T03                  readingsProxy
DL2_T04                  readingsProxy
DL2_T05                  readingsProxy
DL2_T06                  readingsProxy
DL2_T07                  readingsProxy
DL2_T08                  readingsProxy
DL2_T09                  readingsProxy
DL2_T10                  readingsProxy
DL2_T11                  readingsProxy
DL2_T12                  readingsProxy
DL2_WMZ1IP               readingsProxy
DL2_WMZ1RT               readingsProxy
DL2_WMZ1VS               readingsProxy
DL2_WMZ1VT               readingsProxy
DL2_WMZ1W                readingsProxy
DL2_WMZ2IP               readingsProxy
DL2_WMZ2RT               readingsProxy
DL2_WMZ2VS               readingsProxy
DL2_WMZ2VT               readingsProxy
DL2_WMZ2W                readingsProxy
EnergieAB                JSONMETER
EnergieEG                JSONMETER
EnergieOG1               JSONMETER
EnergieOG2               JSONMETER
EnergiePV                JSONMETER
F2F_Rasp01               FHEM2FHEM
FileLog_DL2              FileLog
FileLog_DL2_T04k         FileLog
FileLog_EnergieAB        FileLog
FileLog_EnergieEG        FileLog
FileLog_EnergieOG1       FileLog
FileLog_EnergieOG2       FileLog
FileLog_EnergiePV        FileLog
FileLog_EnergieSV        FileLog
FileLog_sysmon           FileLog
HTZ_SDM630M_1            ModbusSDM630M
INT                      RPI_GPIO
Logfile                  FileLog
MBA                      ModbusAttr
ModbusRS485              Modbus
NTFY_BackupRun           at
OG2_HZR_HZG_PSSP         readingsProxy
OG2_HZR_HZG_PSSPD        dummy
OG2_HZR_HZG_PSSPN        notify
OG2_HZR_H_HS             readingsProxy
OG2_HZR_H_HSD            dummy
OG2_HZR_H_HSN            notify
OG2_HZR_NS_APC           readingsProxy
OG2_HZR_NS_APCUEW        readingsProxy
OG2_HZR_P_APS            readingsProxy
OG2_HZR_P_APSD           dummy
OG2_HZR_P_APSN           notify
OG2_HZR_STSP_HTE         readingsProxy
OG2_HZR_STSP_HTI         readingsProxy
OG2_HZR_ST_DT07T08D      dummy
OG2_HZR_ST_DT12T08D      dummy
OG2_HZR_ST_HVPA3         readingsProxy
OG2_HZR_ST_HVPA3.PID     PID20
OG2_HZR_ST_HVPA3.PID.File     FileLog
OG2_HZR_ST_HVPA3.PID.PWMST     DOIF
OG2_HZR_ST_HVPA3.PID.PWMST.File     FileLog
OG2_HZR_ST_HVPA3.PIDD     dummy
OG2_HZR_ST_HVPFA3.PIDST     DOIF
OG2_HZR_ST_HVPFA3D       dummy
OG2_HZR_ST_HVVV3         readingsProxy
OG2_HZR_ST_HVVV3D        dummy
OG2_HZR_ST_HVVV3N        notify
OG2_HZR_ST_KVPA5         readingsProxy
OG2_HZR_ST_KVPA5.PID     PID20
OG2_HZR_ST_KVPA5.PID.File     FileLog
OG2_HZR_ST_KVPA5.PID.PWMST     DOIF
OG2_HZR_ST_KVPA5.PID.PWMST.File     FileLog
OG2_HZR_ST_KVPA5.PIDD     dummy
OG2_HZR_ST_KVPFA5.PIDST     DOIF
OG2_HZR_ST_KVPFA5D       dummy
OG2_HZR_ST_PSSSPPA1      readingsProxy
OG2_HZR_ST_WWZPA4        readingsProxy
OG2_HZR_ST_WWZPA4D       dummy
OG2_HZR_ST_WWZPA4N       notify
PVA1                     FileLog
PVA1_M                   FileLog
PVA1_Y                   FileLog
RpiI2C_1                 RPII2C
SUSV                     I2C_SUSV
SVG_AB_P_ST_PPPA2.PID.File     SVG
SVG_DL2Solar01           SVG
SVG_DL2Solar02           SVG
SVG_DL2Solar03           SVG
SVG_DL2Solar04           SVG
SVG_EnergieAB            SVG
SVG_EnergieEG            SVG
SVG_EnergieOG1           SVG
SVG_EnergieOG2           SVG
SVG_EnergiePV            SVG
SVG_EnergieSV            SVG
SVG_OG2_HZR_ST_HVPA3.PID.File     SVG
SVG_OG2_HZR_ST_KVPA5.PID.File     SVG
SVG_PVA1                 SVG
SVG_PVA1_M               SVG
SVG_PVA1_Y               SVG
SolarThermie             FLOORPLAN
SysValues                weblink
WEB                      FHEMWEB
WEB_192.168.17.40_52920     FHEMWEB
WEBphone                 FHEMWEB
WEBtablet                FHEMWEB
allowed_WEB              allowed
allowed_WEBphone         allowed
allowed_WEBtablet        allowed
allowed_telnetPort       allowed
autocreate               autocreate
eventTypes               eventTypes
global                   Global
initNotify               notify
lp                       logProxy
mcp23017_B1_HZR          I2C_MCP23017
mcp23017_B1_HZR_A4       readingsProxy
mcp23017_B1_HZR_A5       readingsProxy
mcp23017_B1_HZR_A6       readingsProxy
mcp23017_B1_HZR_A7       readingsProxy
mcp23017_B1_HZR_B0       readingsProxy
mcp23017_B1_HZR_B1       readingsProxy
mcp23017_B1_HZR_B2       readingsProxy
mcp23017_B1_HZR_B3       readingsProxy
mcp23017_B1_HZR_B4       readingsProxy
mcp23017_B1_HZR_B5       readingsProxy
mcp23017_B2_HZR          I2C_MCP23017
mcp23017_B2_HZR_A3       readingsProxy
mcp23017_B2_HZR_B0       readingsProxy
mcp23017_B2_HZR_B6       readingsProxy
resolpump                readingsGroup
resoltemp                readingsGroup
resolwmz1                readingsGroup
resolwmz2                readingsGroup
sysmon                   SYSMON
telnetForBlockingFn_1519039922     telnet
telnetPort               telnet
telnetPort_192.168.17.131_33750     telnet
telnetPort_192.168.17.181_43502     telnet
wl_sysmon_cpustat        SVG
wl_sysmon_cpustatT       SVG
wl_sysmon_cpustat_s      SVG
wl_sysmon_eth0           SVG
wl_sysmon_fs_root        SVG
wl_sysmon_fs_usb1        SVG
wl_sysmon_load           SVG
wl_sysmon_power_ac       SVG
wl_sysmon_power_bat      SVG
wl_sysmon_ram            SVG
wl_sysmon_temp           SVG
wl_sysmon_wlan0          SVG


{ `ps -elf | grep fhem` }
1 S fhem      1300     1  8  80   0 - 10530 -      12:49 pts/0    00:00:08 perl fhem.pl fhem.cfg
0 S fhem      1374  1300  0  80   0 -   475 wait   12:50 pts/0    00:00:00 sh -c ps -elf | grep fhem
0 R fhem      1375  1374  0  80   0 -  1934 -      12:50 pts/0    00:00:00 ps -elf
0 S fhem      1376  1374  0  80   0 -  1093 pipe_w 12:50 pts/0    00:00:00 grep fhem


{ `ps aux | grep fhem` }
fhem      1300  6.4  3.9  42120 37908 pts/0    S    12:49   0:10 perl fhem.pl fhem.cfg
fhem      1411  0.0  0.0   1900   392 pts/0    S    12:51   0:00 sh -c ps aux | grep fhem
fhem      1412  0.0  0.3   7736  2948 pts/0    R    12:51   0:00 ps aux
fhem      1413  0.0  0.0   4372   560 pts/0    S    12:51   0:00 grep fhem


BlockingInfo
No BlockingCall processes running currently

fhemdebug memusage
1. defs                             628368
   2. modules                          340298
   3. attr                             187987
   4. FW_RET                           186850
   5. modules::eventTypes               79226
   6. modules::eventTypes::ldata        78164
   7. modules::ModbusSDM630M            61866
   8. modules::ModbusSDM630M::parseInfo    55649
   9. defs::HTZ_SDM630M_1               52176
  10. defs::sysmon                      48548
  11. defs::DL2                         43676
  12. defs::HTZ_SDM630M_1::READINGS     41981
  13. POSIX::                           37247
  14. defs::sysmon::READINGS            32161
  15. defs::DL2::READINGS               21484
  16. defs::OG2_HZR_ST_KVPA5.PID.PWMST    16578
  17. defs::OG2_HZR_ST_HVPA3.PID.PWMST    16578
  18. defs::AB_P_ST_PPPA2.PID.PWMST     16203
  19. Socket::                          15972
  20. defs::sysmon::helper              15254
  21. attr::DL2                         13340
  22. defs::sysmon::helper::cur_readings_map    13070
  23. defs::DL2::defptr                 12288
  24. defs::OG2_HZR_ST_KVPA5.PID        10420
  25. defs::AB_P_ST_PPPA2.PID           10397
  26. defs::OG2_HZR_ST_HVPA3.PID        10293
  27. oldvalue                          10119
  28. modules::eventTypes::ldata::HTZ_SDM630M_1     9373
  29. defs::mcp23017_B1_HZR              8443
  30. Fcntl::                            8426
  31. INC                                8336
  32. defs::mcp23017_B2_HZR              8243
  33. Errno::                            7893
  34. defs::mcp23017_B1_HZR::READINGS     7331
  35. defs::SUSV                         7308
  36. defs::mcp23017_B2_HZR::READINGS     7123
  37. defs::AB_P_ST_PPPFA2.PIDST         6366
  38. defs::HTZ_SDM630M_1::lastRead      6303
  39. defs::OG2_HZR_ST_KVPFA5.PIDST      6188
  40. defs::OG2_HZR_ST_HVPFA3.PIDST      6188
  41. defs::Aktueller_Verbrauch          5369
  42. defs::SUSV::READINGS               4529
  43. defs::INT                          4470
  44. modules::ModbusAttr                4429
  45. defs::resoltemp                    4399
  46. defs::ModbusRS485                  4331
  47. defs::OG2_HZR_ST_KVPA5.PID::READINGS     4220
  48. defs::AB_P_ST_PPPA2.PID::READINGS     4216
  49. defs::OG2_HZR_ST_HVPA3.PID::READINGS     4203
  50. modules::eventTypes::ldata::OG2_HZR_ST_KVPA5.PID.PWMST     4187


#########################################
Am nächstem Tag

list .* TYPE
AB_FR_HZG_PFA2H          readingsProxy
AB_FR_HZG_PFA2HD         dummy
AB_FR_HZG_PFA2HN         notify
AB_P_DS                  readingsProxy
AB_P_DSFRD               dummy
AB_P_DSFRN               notify
AB_P_PP_STS              readingsProxy
AB_P_PP_STSD             dummy
AB_P_PP_STSN             notify
AB_P_ST_DT09T04D         dummy
AB_P_ST_PPPA2            readingsProxy
AB_P_ST_PPPA2.PID        PID20
AB_P_ST_PPPA2.PID.File     FileLog
AB_P_ST_PPPA2.PID.PWMST     DOIF
AB_P_ST_PPPA2.PID.PWMST.File     FileLog
AB_P_ST_PPPA2.PIDD       dummy
AB_P_ST_PPPFA2.PIDST     DOIF
AB_P_ST_PPPFA2D          dummy
AB_P_ST_V2               readingsProxy
AB_P_ST_V2D              dummy
AB_P_ST_V2N              notify
AB_P_ZP                  readingsProxy
AB_P_ZPFSD               dummy
AB_P_ZPFSN               notify
AB_P_ZPHZD               dummy
AB_P_ZPHZN               notify
AB_P_ZPPSD               dummy
AB_P_ZPPSN               notify
AB_SSP_ST_V1             readingsProxy
AB_SSP_ST_V1D            dummy
AB_SSP_ST_V1DN           notify
Aktueller_Verbrauch      readingsGroup
DL2                      HTTPMOD
DL2_CS10                 readingsProxy
DL2_R1                   readingsProxy
DL2_R2                   readingsProxy
DL2_R3                   readingsProxy
DL2_R4                   readingsProxy
DL2_R5                   readingsProxy
DL2_R6                   readingsProxy
DL2_R7                   readingsProxy
DL2_R8                   readingsProxy
DL2_R9                   readingsProxy
DL2_SZ                   readingsProxy
DL2_T01                  readingsProxy
DL2_T02                  readingsProxy
DL2_T03                  readingsProxy
DL2_T04                  readingsProxy
DL2_T05                  readingsProxy
DL2_T06                  readingsProxy
DL2_T07                  readingsProxy
DL2_T08                  readingsProxy
DL2_T09                  readingsProxy
DL2_T10                  readingsProxy
DL2_T11                  readingsProxy
DL2_T12                  readingsProxy
DL2_WMZ1IP               readingsProxy
DL2_WMZ1RT               readingsProxy
DL2_WMZ1VS               readingsProxy
DL2_WMZ1VT               readingsProxy
DL2_WMZ1W                readingsProxy
DL2_WMZ2IP               readingsProxy
DL2_WMZ2RT               readingsProxy
DL2_WMZ2VS               readingsProxy
DL2_WMZ2VT               readingsProxy
DL2_WMZ2W                readingsProxy
EnergieAB                JSONMETER
EnergieEG                JSONMETER
EnergieOG1               JSONMETER
EnergieOG2               JSONMETER
EnergiePV                JSONMETER
F2F_Rasp01               FHEM2FHEM
FileLog_DL2              FileLog
FileLog_DL2_T04k         FileLog
FileLog_EnergieAB        FileLog
FileLog_EnergieEG        FileLog
FileLog_EnergieOG1       FileLog
FileLog_EnergieOG2       FileLog
FileLog_EnergiePV        FileLog
FileLog_EnergieSV        FileLog
FileLog_sysmon           FileLog
HTZ_SDM630M_1            ModbusSDM630M
INT                      RPI_GPIO
Logfile                  FileLog
MBA                      ModbusAttr
ModbusRS485              Modbus
NTFY_BackupRun           at
OG2_HZR_HZG_PSSP         readingsProxy
OG2_HZR_HZG_PSSPD        dummy
OG2_HZR_HZG_PSSPN        notify
OG2_HZR_H_HS             readingsProxy
OG2_HZR_H_HSD            dummy
OG2_HZR_H_HSN            notify
OG2_HZR_NS_APC           readingsProxy
OG2_HZR_NS_APCUEW        readingsProxy
OG2_HZR_P_APS            readingsProxy
OG2_HZR_P_APSD           dummy
OG2_HZR_P_APSN           notify
OG2_HZR_STSP_HTE         readingsProxy
OG2_HZR_STSP_HTI         readingsProxy
OG2_HZR_ST_DT07T08D      dummy
OG2_HZR_ST_DT12T08D      dummy
OG2_HZR_ST_HVPA3         readingsProxy
OG2_HZR_ST_HVPA3.PID     PID20
OG2_HZR_ST_HVPA3.PID.File     FileLog
OG2_HZR_ST_HVPA3.PID.PWMST     DOIF
OG2_HZR_ST_HVPA3.PID.PWMST.File     FileLog
OG2_HZR_ST_HVPA3.PIDD     dummy
OG2_HZR_ST_HVPFA3.PIDST     DOIF
OG2_HZR_ST_HVPFA3D       dummy
OG2_HZR_ST_HVVV3         readingsProxy
OG2_HZR_ST_HVVV3D        dummy
OG2_HZR_ST_HVVV3N        notify
OG2_HZR_ST_KVPA5         readingsProxy
OG2_HZR_ST_KVPA5.PID     PID20
OG2_HZR_ST_KVPA5.PID.File     FileLog
OG2_HZR_ST_KVPA5.PID.PWMST     DOIF
OG2_HZR_ST_KVPA5.PID.PWMST.File     FileLog
OG2_HZR_ST_KVPA5.PIDD     dummy
OG2_HZR_ST_KVPFA5.PIDST     DOIF
OG2_HZR_ST_KVPFA5D       dummy
OG2_HZR_ST_PSSSPPA1      readingsProxy
OG2_HZR_ST_WWZPA4        readingsProxy
OG2_HZR_ST_WWZPA4D       dummy
OG2_HZR_ST_WWZPA4N       notify
PVA1                     FileLog
PVA1_M                   FileLog
PVA1_Y                   FileLog
RpiI2C_1                 RPII2C
SUSV                     I2C_SUSV
SVG_AB_P_ST_PPPA2.PID.File     SVG
SVG_DL2Solar01           SVG
SVG_DL2Solar02           SVG
SVG_DL2Solar03           SVG
SVG_DL2Solar04           SVG
SVG_EnergieAB            SVG
SVG_EnergieEG            SVG
SVG_EnergieOG1           SVG
SVG_EnergieOG2           SVG
SVG_EnergiePV            SVG
SVG_EnergieSV            SVG
SVG_OG2_HZR_ST_HVPA3.PID.File     SVG
SVG_OG2_HZR_ST_KVPA5.PID.File     SVG
SVG_PVA1                 SVG
SVG_PVA1_M               SVG
SVG_PVA1_Y               SVG
SolarThermie             FLOORPLAN
SysValues                weblink
WEB                      FHEMWEB
WEB_192.168.17.46_1796     FHEMWEB
WEBphone                 FHEMWEB
WEBtablet                FHEMWEB
allowed_WEB              allowed
allowed_WEBphone         allowed
allowed_WEBtablet        allowed
allowed_telnetPort       allowed
autocreate               autocreate
eventTypes               eventTypes
global                   Global
initNotify               notify
lp                       logProxy
mcp23017_B1_HZR          I2C_MCP23017
mcp23017_B1_HZR_A4       readingsProxy
mcp23017_B1_HZR_A5       readingsProxy
mcp23017_B1_HZR_A6       readingsProxy
mcp23017_B1_HZR_A7       readingsProxy
mcp23017_B1_HZR_B0       readingsProxy
mcp23017_B1_HZR_B1       readingsProxy
mcp23017_B1_HZR_B2       readingsProxy
mcp23017_B1_HZR_B3       readingsProxy
mcp23017_B1_HZR_B4       readingsProxy
mcp23017_B1_HZR_B5       readingsProxy
mcp23017_B2_HZR          I2C_MCP23017
mcp23017_B2_HZR_A3       readingsProxy
mcp23017_B2_HZR_B0       readingsProxy
mcp23017_B2_HZR_B6       readingsProxy
resolpump                readingsGroup
resoltemp                readingsGroup
resolwmz1                readingsGroup
resolwmz2                readingsGroup
sysmon                   SYSMON
telnetForBlockingFn_1519040969     telnet
telnetPort               telnet
telnetPort_192.168.17.131_33776     telnet
telnetPort_192.168.17.181_55136     telnet
wl_sysmon_cpustat        SVG
wl_sysmon_cpustatT       SVG
wl_sysmon_cpustat_s      SVG
wl_sysmon_eth0           SVG
wl_sysmon_fs_root        SVG
wl_sysmon_fs_usb1        SVG
wl_sysmon_load           SVG
wl_sysmon_power_ac       SVG
wl_sysmon_power_bat      SVG
wl_sysmon_ram            SVG
wl_sysmon_temp           SVG
wl_sysmon_wlan0          SVG


{ `ps -elf | grep fhem` }
1 S fhem      1300     1  1  80   0 - 39140 -      Feb19 ?        00:18:45 perl fhem.pl fhem.cfg
0 S fhem     12281  1300  0  80   0 -   475 wait   10:30 ?        00:00:00 sh -c ps -elf | grep fhem
0 R fhem     12282 12281  0  80   0 -  1934 -      10:30 ?        00:00:00 ps -elf
0 S fhem     12283 12281  0  80   0 -  1093 pipe_w 10:30 ?        00:00:00 grep fhem


{ `ps aux | grep fhem` }
fhem      1300  1.4 16.0 156560 152076 ?       S    Feb19  18:45 perl fhem.pl fhem.cfg
fhem     12286  0.0  0.0   1900   372 ?        S    10:30   0:00 sh -c ps aux | grep fhem
fhem     12287  0.0  0.3   7736  2876 ?        R    10:30   0:00 ps aux
fhem     12288  0.0  0.0   4372   576 ?        S    10:30   0:00 grep fhem


BlockingInfo
No BlockingCall processes running currently

fhemdebug memusage

1. defs                             633595
   2. modules                          340429
   3. attr                             187986
   4. FW_RET                           186850
   5. modules::eventTypes               79293
   6. modules::eventTypes::ldata        78231
   7. modules::ModbusSDM630M            61866
   8. modules::ModbusSDM630M::parseInfo    55649
   9. defs::HTZ_SDM630M_1               52656
  10. defs::sysmon                      48593
  11. defs::DL2                         43639
  12. defs::HTZ_SDM630M_1::READINGS     42461
  13. POSIX::                           37247
  14. defs::sysmon::READINGS            32206
  15. defs::DL2::READINGS               21520
  16. defs::AB_P_ST_PPPA2.PID.PWMST     17257
  17. defs::OG2_HZR_ST_HVPA3.PID.PWMST    16578
  18. defs::OG2_HZR_ST_KVPA5.PID.PWMST    16578
  19. Socket::                          15972
  20. defs::sysmon::helper              15254
  21. attr::DL2                         13340
  22. defs::sysmon::helper::cur_readings_map    13070
  23. defs::DL2::defptr                 12288
  24. defs::OG2_HZR_ST_KVPA5.PID        10454
  25. defs::OG2_HZR_ST_HVPA3.PID        10411
  26. defs::AB_P_ST_PPPA2.PID           10397
  27. oldvalue                          10254
  28. modules::eventTypes::ldata::HTZ_SDM630M_1     9373
  29. defs::mcp23017_B1_HZR              8549
  30. INC                                8478
  31. Fcntl::                            8426
  32. defs::mcp23017_B2_HZR              8418
  33. defs::AB_P_ST_PPPFA2.PIDST         8268
  34. Errno::                            7893
  35. defs::SUSV                         7441
  36. defs::mcp23017_B1_HZR::READINGS     7432
  37. defs::mcp23017_B2_HZR::READINGS     7301
  38. defs::HTZ_SDM630M_1::lastRead      6303
  39. defs::OG2_HZR_ST_KVPFA5.PIDST      6188
  40. defs::OG2_HZR_ST_HVPFA3.PIDST      6188
  41. defs::Aktueller_Verbrauch          5439
  42. defs::INT                          4679
  43. defs::SUSV::READINGS               4583
  44. modules::ModbusAttr                4429
  45. defs::resoltemp                    4399
  46. defs::ModbusRS485                  4331
  47. defs::OG2_HZR_ST_KVPA5.PID::READINGS     4234
  48. defs::OG2_HZR_ST_HVPA3.PID::READINGS     4221
  49. defs::AB_P_ST_PPPA2.PID::READINGS     4216
  50. modules::eventTypes::ldata::OG2_HZR_ST_KVPA5.PID.PWMST     4187


Vielleicht ist aus diesem Verlauf etwas erkennbar.
Wenn wieder Cannot fork: Cannot allocate memory auftaucht werde ich nochmals einen Vergleich zu diesen Angaben liefern.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: nils_ am 20 Februar 2018, 17:18:40
ich hab mir die beiden werte aus memusage mal geschnappt und die änderungen zum vortag ausgerechnet (vielleicht hilft es ja bei der fehlersuche....)

1. defs                                                    5227
 2. modules                                                  131
 3. attr                                                      -1
 4. FW_RET                                                     0
 5. modules::eventTypes                                       67
 6. modules::eventTypes::ldata                                67
 7. modules::ModbusSDM630M                                     0
 8. modules::ModbusSDM630M::parseInfo                          0
 9. defs::HTZ_SDM630M_1                                      480
10. defs::sysmon                                              45
11. defs::DL2                                                -37
12. defs::HTZ_SDM630M_1::READINGS                            480
13. POSIX::                                                    0
14. defs::sysmon::READINGS                                    45
15. defs::DL2::READINGS                                       36
16. defs::AB_P_ST_PPPA2.PID.PWMST                           1054
17. defs::OG2_HZR_ST_HVPA3.PID.PWMST                           0
18. defs::OG2_HZR_ST_KVPA5.PID.PWMST                           0
19. Socket::                                                   0
20. defs::sysmon::helper                                       0
21. attr::DL2                                                  0
22. defs::sysmon::helper::cur_readings_map                     0
23. defs::DL2::defptr                                          0
24. defs::OG2_HZR_ST_KVPA5.PID                                34
25. defs::OG2_HZR_ST_HVPA3.PID                               118
26. defs::AB_P_ST_PPPA2.PID                                    0
27. oldvalue                                                 135
28. modules::eventTypes::ldata::HTZ_SDM630M_1                  0
29. defs::mcp23017_B1_HZR                                    106
30. INC                                                      142
31. Fcntl::                                                    0
32. defs::mcp23017_B2_HZR                                    175
33. defs::AB_P_ST_PPPFA2.PIDST                              1902
34. Errno::                                                    0
35. defs::SUSV                                               133
36. defs::mcp23017_B1_HZR::READINGS                          101
37. defs::mcp23017_B2_HZR::READINGS                          178
38. defs::HTZ_SDM630M_1::lastRead                              0
39. defs::OG2_HZR_ST_KVPFA5.PIDST                              0
40. defs::OG2_HZR_ST_HVPFA3.PIDST                              0
41. defs::Aktueller_Verbrauch                                 70
42. defs::INT                                                209
43. defs::SUSV::READINGS                                      54
44. modules::ModbusAttr                                        0
45. defs::resoltemp                                            0
46. defs::ModbusRS485                                          0
47. defs::OG2_HZR_ST_KVPA5.PID::READINGS                      14
48. defs::OG2_HZR_ST_HVPA3.PID::READINGS                      18
49. defs::AB_P_ST_PPPA2.PID::READINGS                          0
50. modules::eventTypes::ldata::OG2_HZR_ST_KVPA5.PID.PWMST     0

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 20 Februar 2018, 23:07:57
Ich fuerchte memusage wird in diesem Fall nicht helfen: die Unterschiede sind minimal, jedenfalls erklaeren sie nicht den laut ps vervierfachung des Speicherverbrauchs. Auch der Hinweis, dass das Problem OS-abhaengig ist, unterstuetzt die Theorie, dass das Problem nicht auf der FHEM-Modulprogrammierungs-Ebene, sondern tiefer, perl oder libc passiert. Die Liste der Geraete ist unauffaellig, auch wenn ich nicht alle Module persoenlich kenne.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: nils_ am 21 Februar 2018, 08:32:58
Zitat von: rudolfkoenig am 20 Februar 2018, 23:07:57
Ich fuerchte memusage wird in diesem Fall nicht helfen: die Unterschiede sind minimal, jedenfalls erklaeren sie nicht den laut ps vervierfachung des Speicherverbrauchs. Auch der Hinweis, dass das Problem OS-abhaengig ist, unterstuetzt die Theorie, dass das Problem nicht auf der FHEM-Modulprogrammierungs-Ebene, sondern tiefer, perl oder libc passiert. Die Liste der Geraete ist unauffaellig, auch wenn ich nicht alle Module persoenlich kenne.

ja sowas hatte ich aus deinen letzten aussagen schon vermutet.  :(
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 21 Februar 2018, 09:57:06
Das Problem ist nur, das es sehr viel sein könnte. Mann wird also um ein "einkreisen", d.h. verringern der Module und damit er Möglichkeiten, nicht drum rum kommen ...

Ich glaube nicht, das es an "Debian Strech" liegt, sondern an irgendeinem Versionskonflikt ..... sonst währe der Aufschrei in der Community größer ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 09 März 2018, 17:20:40
Gibt es in der Zwischenzeit neu Erkenntnisse zu dem Thema?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 09 März 2018, 17:30:22
Müssten nicht die Helfenden das dem Hilfesuchenden fragen?
Hast Du bereits angefangen einzelne Module zu deaktivieren?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 09 März 2018, 18:58:29
Auf dem Testgerät läuft nur FHEM mit den JSONMETER LS110.
Wenn dieser einige Tage läuft und ich ein Update ausführen möchte kommt diese Meldung.

Bei denn Master Raspberry ist mir aufgefallen das die JSONMETER LS110 nach längerem Betrieb plötzlich nicht mehr eingelesen werden.
Wenn dies der Fall ist kommt zu 100% die Cannot fork: Cannot allocate memory Meldung und das System muss neu gestartet werden.
Am zweiten aktiven Raspberry ist das gleiche nur zu einem viel späteren Zeitpunkt.
Auffällig ist das Beide und das Testgerät das aktuelle Jessie Stretch Lite Betriebssystem haben und ein anderer Raspberry der kein Stretch Lite hat ohne Probleme mit dem JSONMETER LS110 noch nie mit dieser Fehlermeldung ausgefallen ist.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 09 März 2018, 19:37:54
Sehr schön, das war jetzt das Stammtischgespräch. Nun aber Mal bitte was handfestes. Lese Dir bitte noch mal den Thread durch um zu erfassen was wirklich wichtige Daten wären.
Einzig das du auf einer FHEM Instanz nur ein Device aktiv hast war interessant.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 11 März 2018, 20:25:44
Hallo Zusammen,

ich für meinen Teil bin aus Zeitnot zurück auf Jessie gewechselt.
Mein Produktiv-FHEM kann/will ich nicht runterspecken, für eine Testinstallation habe ich momentan einfach keine Zeit.


Gruß
Alex
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 11 März 2018, 22:48:55
Hallo,

auch ich habe unter Stretch Lite seit 2 Tagen folgende Fehlermeldungen im Log und meine SQL Datenbank wird nicht mehr geschrieben. Ich hänge mich mit meinem Problem mal an den neuesten Beitrag an.

2018.03.10 18:17:32 1: Cannot fork: Cannot allocate memory
2018.03.10 18:29:59 2: [Freezemon] freezemon: possible freeze starting at 18:29:58, delay is 1.425 possibly caused by ModbusTCPServer_Poll(N/A)
2018.03.10 18:47:32 1: PROPLANTA proplanta: Start.608 Could not start forked process, old process still running


Der Proplanta Fehler, denke ich hängt mit dem zu geringen Speicher zusammen.

Folgende Situation/Beobachtungen:

- Fhem und Stretch Lite auf Raspi3 ist aktuell (10.03.2018
- HM und HmIP Geräte alle über CCU2 an Fhem angebunden, nicht über COC (
- Fehler das erste Mal am 10.03.2018 aufgetaucht
- Mit auftreten der erstem Meldung von "Cannot fork: Cannot allocate memory" wird die Mariadb SQL Datenbank nicht mehr geschrieben
- Nach Neustart Fhem läuft es wieder ca. 10-20 Stunden
- Änderungen in Fhem Programmierung oder installation neuer Module in den letzten Tagen keine (bewusst)
- Einige entscheidende Module: SIP, ModbusTCPServer, ModbusRegister, ModbusCoil, DbLog, DbRep, HMCCU, HMCCUDEV, HMCCURPCPROC, doif, Proplanta, HTTPMOD, Abfall, Calendar

Hatte die Module apptime und Freezemon in Verdacht, nach Deinstallation und disable kommt aber der Fehler nach wie vor.
So wie ich die Beiträge lese, gibt es (derzeit) nur wenige User mit dem gleichen Fehler. Auch gibt es bei den Betroffenen (bisher) keine eindeutige Ursache.

Speicherauslastung im Fehlerfall:
pi@raspberrypi:~ $ free -m -t
              total        used        free      shared  buff/cache   available
Mem:            927         809          50           2          66          66
Swap:            99          99           0
Total:         1027         909          51


Speicherauslastung nach Reset:
pi@raspberrypi:~ $ free -m -t
              total        used        free      shared  buff/cache   available
Mem:            927         317         405           1         204         556
Swap:            99          44          55
Total:         1027         361         461


Belegung 16GB Speicherkarte am RASPI3:
pi@raspberrypi:~ $ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root        14G    3,0G   11G   23% /
devtmpfs        460M       0  460M    0% /dev
tmpfs           464M       0  464M    0% /dev/shm
tmpfs           464M     18M  446M    4% /run
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           464M       0  464M    0% /sys/fs/cgroup
/dev/mmcblk0p1   42M     21M   21M   51% /boot
tmpfs            93M       0   93M    0% /run/user/1000


Speicherauslastung ca. 8 Stunden nach Neustart - ps aux --sort -rss:
pi@raspberrypi:~ $ ps aux --sort -rss
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
fhem      8476  5.5 24.3 240184 231036 ?       S    13:26  27:49 /usr/bin/perl f
mysql      770  0.3 19.0 650424 181040 ?       Ssl  Mär10   5:18 /usr/sbin/mysq
fhem      8484  0.1  9.7 107136 92692 ?        S    13:26   0:57 /usr/bin/perl f
fhem      8486  0.0  9.7 107064 92624 ?        S    13:26   0:18 /usr/bin/perl f
fhem      8483  0.0  9.7 106680 92212 ?        S    13:26   0:26 /usr/bin/perl f
root     11681  0.0  0.5  11520  5676 ?        Ss   21:44   0:00 sshd: pi [priv]
pi       11687  0.0  0.5   9660  4948 ?        Ss   21:44   0:00 /lib/systemd/sy
root         1  0.0  0.4   9600  4288 ?        Ss   Mär10   0:03 /sbin/init
root       627  0.0  0.4   7724  4184 ?        Ss   Mär10   0:04 /usr/sbin/apac
pi       11700  0.0  0.4   5920  3824 pts/0    Ss   21:44   0:00 -bash
pi       11697  0.0  0.3  11520  3768 ?        S    21:44   0:00 sshd: pi@pts/0
root       356  0.0  0.3   7376  3720 ?        Ss   Mär10   0:00 /lib/systemd/s
www-data  5440  0.0  0.3 230164  3544 ?        Sl   06:25   0:12 /usr/sbin/apach
root       126  0.0  0.3  26920  3172 ?        Ss   Mär10   0:01 /lib/systemd/s
pi       11759  0.0  0.3   7884  3000 pts/0    R+   21:50   0:00 ps aux --sort -
www-data  5412  0.0  0.3 230148  2984 ?        Sl   06:25   0:12 /usr/sbin/apach
message+   357  0.0  0.2   6492  2204 ?        Ss   Mär10   0:00 /usr/bin/dbus-
avahi      397  0.0  0.2   6400  2144 ?        Ss   Mär10   0:00 avahi-daemon:
root       347  0.0  0.2  23748  1996 ?        Ssl  Mär10   0:00 /usr/sbin/rsys
systemd+   303  0.0  0.1  17280  1840 ?        Ssl  Mär10   0:00 /lib/systemd/s
root       609  0.0  0.1  10200  1636 ?        Ss   Mär10   0:00 /usr/sbin/sshd
root       348  0.0  0.1   5292  1428 ?        Ss   Mär10   0:00 /usr/sbin/cron
root       572  0.0  0.1   2948  1392 ?        Ss   Mär10   0:01 /sbin/dhcpcd -
root       144  0.0  0.1  14292  1356 ?        Ss   Mär10   0:00 /lib/systemd/s
nobody     345  0.0  0.1   5292  1156 ?        Ss   Mär10   0:00 /usr/sbin/thd
root       622  0.0  0.1   4196  1016 tty1     Ss+  Mär10   0:00 /sbin/agetty -
pi       11690  0.0  0.1  11264  1008 ?        S    21:44   0:00 (sd-pam)
root       430  0.0  0.0  10128   908 ?        Ss   Mär10   0:01 wpa_supplicant
avahi      400  0.0  0.0   6400     8 ?        S    Mär10   0:00 avahi-daemon:
root         2  0.0  0.0      0     0 ?        S    Mär10   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Mär10   0:00 [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/0:0H]
root         7  0.0  0.0      0     0 ?        S    Mär10   0:02 [rcu_sched]
root         8  0.0  0.0      0     0 ?        S    Mär10   0:00 [rcu_bh]
root         9  0.0  0.0      0     0 ?        S    Mär10   0:00 [migration/0]
root        10  0.0  0.0      0     0 ?        S<   Mär10   0:00 [lru-add-drain
root        11  0.0  0.0      0     0 ?        S    Mär10   0:00 [cpuhp/0]
root        12  0.0  0.0      0     0 ?        S    Mär10   0:00 [cpuhp/1]
root        13  0.0  0.0      0     0 ?        S    Mär10   0:00 [migration/1]
root        14  0.0  0.0      0     0 ?        S    Mär10   0:00 [ksoftirqd/1]
root        16  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/1:0H]
root        17  0.0  0.0      0     0 ?        S    Mär10   0:00 [cpuhp/2]
root        18  0.0  0.0      0     0 ?        S    Mär10   0:00 [migration/2]
root        19  0.0  0.0      0     0 ?        S    Mär10   0:02 [ksoftirqd/2]
root        21  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/2:0H]
root        22  0.0  0.0      0     0 ?        S    Mär10   0:00 [cpuhp/3]
root        23  0.0  0.0      0     0 ?        S    Mär10   0:00 [migration/3]
root        24  0.0  0.0      0     0 ?        S    Mär10   0:00 [ksoftirqd/3]
root        26  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/3:0H]
root        27  0.0  0.0      0     0 ?        S    Mär10   0:00 [kdevtmpfs]
root        28  0.0  0.0      0     0 ?        S<   Mär10   0:00 [netns]
root        29  0.0  0.0      0     0 ?        S    Mär10   0:00 [khungtaskd]
root        30  0.0  0.0      0     0 ?        S    Mär10   0:00 [oom_reaper]
root        31  0.0  0.0      0     0 ?        S<   Mär10   0:00 [writeback]
root        32  0.0  0.0      0     0 ?        S    Mär10   0:00 [kcompactd0]
root        33  0.0  0.0      0     0 ?        S<   Mär10   0:00 [crypto]
root        34  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        35  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kblockd]
root        36  0.0  0.0      0     0 ?        S<   Mär10   0:00 [watchdogd]
root        38  0.0  0.0      0     0 ?        S<   Mär10   0:00 [rpciod]
root        39  0.0  0.0      0     0 ?        S<   Mär10   0:00 [xprtiod]
root        40  0.0  0.0      0     0 ?        S    Mär10   0:03 [kswapd0]
root        41  0.0  0.0      0     0 ?        S<   Mär10   0:00 [vmstat]
root        42  0.0  0.0      0     0 ?        S<   Mär10   0:00 [nfsiod]
root        52  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kthrotld]
root        53  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        54  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        55  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        56  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        57  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        58  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        59  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        60  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        61  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        62  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        63  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        64  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        65  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        66  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        67  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        68  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        69  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        70  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        71  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        72  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        73  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        74  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        75  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        76  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        77  0.0  0.0      0     0 ?        S<   Mär10   0:00 [iscsi_eh]
root        78  0.0  0.0      0     0 ?        S<   Mär10   0:00 [dwc_otg]
root        80  0.0  0.0      0     0 ?        S<   Mär10   0:00 [DWC Notificat
root        81  0.0  0.0      0     0 ?        S<   Mär10   0:00 [VCHIQ-0]
root        82  0.0  0.0      0     0 ?        S<   Mär10   0:00 [VCHIQr-0]
root        83  0.0  0.0      0     0 ?        S<   Mär10   0:00 [VCHIQs-0]
root        84  0.0  0.0      0     0 ?        S    Mär10   0:00 [VCHIQka-0]
root        85  0.0  0.0      0     0 ?        S<   Mär10   0:00 [SMIO]
root        88  0.0  0.0      0     0 ?        S    Mär10   0:00 [irq/92-mmc1]
root        90  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        91  0.0  0.0      0     0 ?        S    Mär10   0:11 [mmcqd/0]
root        93  0.0  0.0      0     0 ?        S    Mär10   0:02 [jbd2/mmcblk0p
root        94  0.0  0.0      0     0 ?        S<   Mär10   0:00 [ext4-rsv-conv
root        96  0.0  0.0      0     0 ?        S<   Mär10   0:00 [ipv6_addrconf
root       109  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/1:1H]
root       250  0.0  0.0      0     0 ?        S<   Mär10   0:00 [cfg80211]
root       257  0.0  0.0      0     0 ?        S<   Mär10   0:00 [brcmf_wq/mmc1
root       258  0.0  0.0      0     0 ?        S    Mär10   0:00 [brcmf_wdog/mm
root       467  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/3:1H]
root       468  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/0:1H]
root       514  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/2:1H]
root      4027  0.0  0.0      0     0 ?        S    03:15   0:00 [kworker/u8:2]
root      4660  0.0  0.0      0     0 ?        S    04:46   0:01 [kworker/u8:0]
root      6748  0.0  0.0      0     0 ?        S    08:50   0:03 [kworker/3:2]
root     10952  0.0  0.0      0     0 ?        S    20:02   0:00 [kworker/3:0]
root     11092  0.0  0.0      0     0 ?        S    20:20   0:00 [kworker/0:2]
root     11540  0.0  0.0      0     0 ?        S    21:22   0:00 [kworker/1:2]
root     11638  0.0  0.0      0     0 ?        S    21:39   0:00 [kworker/2:0]
root     11673  0.0  0.0      0     0 ?        S    21:40   0:00 [kworker/0:0]
root     11676  0.0  0.0      0     0 ?        S    21:42   0:00 [kworker/1:0]
root     11683  0.0  0.0      0     0 ?        S    21:44   0:00 [kworker/2:1]
root     11758  0.0  0.0      0     0 ?        S    21:49   0:00 [kworker/1:1]

Mir fallen hier 4 Fhem Prozesse auf, aber als Linux Neuling kann ich mit diesen Angaben nicht wirklich viel anfangen.

{ join(",", grep { !$defs{$_} } sort keys %attr) } bringt bei mir immer einen Eintrag (egal ob Fehler ansteht oder nicht):
secDBLogging

Ich brauche noch einige Tipps von euch in welche Richtung ihr hier mit der Fehlersuche beginnen würdet. Aber ich denke es wird mir nichts anderes übrigbleiben als Module zu disablen oder auf eine alte Version zurückzugehen.

Ich hoffe ihr habt noch einige Tipps für mich. Schön langsam fange ich zu transpirieren an, da ich echt keine Ahnung habe, an was es liegen könnte und es sich um mein Live System handelt.

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 12 März 2018, 08:13:08
Die 4 perl-Prozesse dürften FHEM + 3 "non-Blocking-FHEM-Module" sein.
(Alles bitte mal als root oder mit sudo)

Mach doch eifnach mal ein:
pstree -a | grep [f]hem
Falls er pstree nicht kennt, instalieren mit:
apt-get install psmisc

Wenn ich Deine Ausgabe so lese, sehe ich ~550MByte für FHEM und ~190MByte für mysql, also nur diese beiden produkte zusammen c.a. 780MByte. Da bleibt mit ~220MByte nicht viel Platz fürs Restsystem.
(Alle Angaben auf 1GByte System bezogen, er sagt bei Dir aber 927MByte)

Kannst Du die 3 "non-Blocking-Module" identifizieren?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 12 März 2018, 11:01:12
Auf meinen Systemen ist auch nicht mehr Speicher vorhanden, egal ob mit Strech oder ohne.

pi@ccs-ht-rasp01:~ $ free -m -t
             total        used        free      shared  buff/cache   available
Mem:            927         129         335           0         462         746
Swap:             0           0           0
Total:          927         129         335

Ich denke das der reszliche Speicher die GPU beansprucht.

Was mir beim SYSMON auffält ist das auch die CPU nicht richtige erkannt wird.
CPU model name:    ARMv7 Processor rev 4 (v7l)
Die sollte laut Wiki für aktuelle Pi 2 un dPi 3 dieses CPU beinhalten ARM Cortex-A53.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 12 März 2018, 21:50:56
Hallo,

ich versuche mal die benötigten Daten zu liefern, in der Hoffnung ihr könnt da was erkennen.
Einige Fragen bleiben aber meinerseits noch offen:
1. Reicht es aus die Module zur Fehlersuche mit disabled zu deaktivieren oder sollten diese aus Fhem entfernt werden (shutdown restart ist obligatorisch natürlich in beiden Fällen).
2. Gibt es eine Möglichkeit (für mich als Laien), nonblocking- Module im Code (z.B. an einer Codezeile) zu erkennen?
3. Die nonblocking- Module bei mir, dürften unter DbLog, DbRep, HMCCU, HMCCUDEV, HMCCURPCPROC zu suchen sein.
4. Kann dieser Fehler auch von der Speicherkarte kommen, diese ist ca. 16 Monate alt?

pstree -a | grep [f]hem:
root@raspberrypi:/home/pi# pstree -a | grep [f]hem
  |-perl fhem.pl fhem.cfg
  |   |-perl fhem.pl fhem.cfg
  |   |-perl fhem.pl fhem.cfg
  |   `-perl fhem.pl fhem.cfg


free -m -t wieder nach 8 Stunden Laufzeit (Raspi läuft noch ohne erkennbaren Fehler):
root@raspberrypi:/home/pi# free -m -t
              total        used        free      shared  buff/cache   available
Mem:            927         583          39           1         304         291
Swap:            99          44          55
Total:         1027         628          94


Speicherkartennutzung:
root@raspberrypi:/home/pi# df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root        14G    3,0G   11G   23% /
devtmpfs        460M       0  460M    0% /dev
tmpfs           464M       0  464M    0% /dev/shm
tmpfs           464M     12M  452M    3% /run
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           464M       0  464M    0% /sys/fs/cgroup
/dev/mmcblk0p1   42M     21M   21M   51% /boot
tmpfs            93M       0   93M    0% /run/user/1000


Speicherauslastung, wieder ca. 8 Stunden nach Neustart - ps aux --sort -rss:
root@raspberrypi:/home/pi# ps aux --sort -rss
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
fhem     16855  5.5 32.3 316040 306960 ?       S    08:08  43:08 /usr/bin/perl f
mysql      770  0.3 18.8 654520 179228 ?       Ssl  Mär10  10:28 /usr/sbin/mysq
fhem     16863  0.1 10.4 113836 99272 ?        S    08:08   1:27 /usr/bin/perl f
fhem     16864  0.0 10.4 113796 99152 ?        S    08:08   0:28 /usr/bin/perl f
fhem     16862  0.0 10.3 113092 98736 ?        S    08:08   0:40 /usr/bin/perl f
root     21725  0.0  0.6  11520  5712 ?        Ss   20:55   0:00 sshd: pi [priv]
pi       21731  0.0  0.5   9660  5056 ?        Ss   20:55   0:00 /lib/systemd/sy
root         1  0.0  0.4   9600  4228 ?        Ss   Mär10   0:04 /sbin/init
root       627  0.0  0.4   7724  4192 ?        Ss   Mär10   0:08 /usr/sbin/apac
pi       21744  0.0  0.4   5976  3876 pts/0    Ss   20:55   0:00 -bash
pi       21741  0.0  0.3  11520  3688 ?        S    20:55   0:00 sshd: pi@pts/0
www-data 15871  0.0  0.3 230164  3384 ?        Sl   06:25   0:12 /usr/sbin/apach
www-data 15872  0.0  0.3 230164  3384 ?        Sl   06:25   0:11 /usr/sbin/apach
root       126  0.0  0.3  26920  3352 ?        Ss   Mär10   0:01 /lib/systemd/s
root     21787  0.0  0.3   5320  3232 pts/0    S    21:00   0:00 bash
root     21782  0.0  0.3   6880  3184 pts/0    S    21:00   0:00 su
root     21883  0.0  0.3   7884  2972 pts/0    R+   21:10   0:00 ps aux --sort -
root       356  0.0  0.3   7408  2872 ?        Ss   Mär10   0:00 /lib/systemd/s
root       347  0.0  0.2  23748  2024 ?        Ssl  Mär10   0:00 /usr/sbin/rsys
message+   357  0.0  0.2   6492  1988 ?        Ss   Mär10   0:00 /usr/bin/dbus-
avahi      397  0.0  0.1   6400  1860 ?        Ss   Mär10   0:00 avahi-daemon:
systemd+   303  0.0  0.1  17280  1784 ?        Ssl  Mär10   0:00 /lib/systemd/s
root       609  0.0  0.1  10200  1608 ?        Ss   Mär10   0:00 /usr/sbin/sshd
root       572  0.0  0.1   2948  1384 ?        Ss   Mär10   0:02 /sbin/dhcpcd -
root       348  0.0  0.1   5292  1368 ?        Ss   Mär10   0:00 /usr/sbin/cron
root       144  0.0  0.1  14292  1352 ?        Ss   Mär10   0:00 /lib/systemd/s
nobody     345  0.0  0.1   5292  1216 ?        Ss   Mär10   0:01 /usr/sbin/thd
pi       21734  0.0  0.1  11264  1024 ?        S    20:55   0:00 (sd-pam)
root       430  0.0  0.0  10128   904 ?        Ss   Mär10   0:02 wpa_supplicant
root       622  0.0  0.0   4196   888 tty1     Ss+  Mär10   0:00 /sbin/agetty -
avahi      400  0.0  0.0   6400    12 ?        S    Mär10   0:00 avahi-daemon:
root         2  0.0  0.0      0     0 ?        S    Mär10   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Mär10   0:01 [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/0:0H]
root         7  0.0  0.0      0     0 ?        S    Mär10   0:04 [rcu_sched]
root         8  0.0  0.0      0     0 ?        S    Mär10   0:00 [rcu_bh]
root         9  0.0  0.0      0     0 ?        S    Mär10   0:00 [migration/0]
root        10  0.0  0.0      0     0 ?        S<   Mär10   0:00 [lru-add-drain
root        11  0.0  0.0      0     0 ?        S    Mär10   0:00 [cpuhp/0]
root        12  0.0  0.0      0     0 ?        S    Mär10   0:00 [cpuhp/1]
root        13  0.0  0.0      0     0 ?        S    Mär10   0:00 [migration/1]
root        14  0.0  0.0      0     0 ?        S    Mär10   0:00 [ksoftirqd/1]
root        16  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/1:0H]
root        17  0.0  0.0      0     0 ?        S    Mär10   0:00 [cpuhp/2]
root        18  0.0  0.0      0     0 ?        S    Mär10   0:00 [migration/2]
root        19  0.0  0.0      0     0 ?        S    Mär10   0:04 [ksoftirqd/2]
root        21  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/2:0H]
root        22  0.0  0.0      0     0 ?        S    Mär10   0:00 [cpuhp/3]
root        23  0.0  0.0      0     0 ?        S    Mär10   0:00 [migration/3]
root        24  0.0  0.0      0     0 ?        S    Mär10   0:00 [ksoftirqd/3]
root        26  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/3:0H]
root        27  0.0  0.0      0     0 ?        S    Mär10   0:00 [kdevtmpfs]
root        28  0.0  0.0      0     0 ?        S<   Mär10   0:00 [netns]
root        29  0.0  0.0      0     0 ?        S    Mär10   0:00 [khungtaskd]
root        30  0.0  0.0      0     0 ?        S    Mär10   0:00 [oom_reaper]
root        31  0.0  0.0      0     0 ?        S<   Mär10   0:00 [writeback]
root        32  0.0  0.0      0     0 ?        S    Mär10   0:00 [kcompactd0]
root        33  0.0  0.0      0     0 ?        S<   Mär10   0:00 [crypto]
root        34  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        35  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kblockd]
root        36  0.0  0.0      0     0 ?        S<   Mär10   0:00 [watchdogd]
root        38  0.0  0.0      0     0 ?        S<   Mär10   0:00 [rpciod]
root        39  0.0  0.0      0     0 ?        S<   Mär10   0:00 [xprtiod]
root        40  0.0  0.0      0     0 ?        S    Mär10   0:06 [kswapd0]
root        41  0.0  0.0      0     0 ?        S<   Mär10   0:00 [vmstat]
root        42  0.0  0.0      0     0 ?        S<   Mär10   0:00 [nfsiod]
root        52  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kthrotld]
root        53  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        54  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        55  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        56  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        57  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        58  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        59  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        60  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        61  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        62  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        63  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        64  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        65  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        66  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        67  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        68  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        69  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        70  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        71  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        72  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        73  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        74  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        75  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        76  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        77  0.0  0.0      0     0 ?        S<   Mär10   0:00 [iscsi_eh]
root        78  0.0  0.0      0     0 ?        S<   Mär10   0:00 [dwc_otg]
root        80  0.0  0.0      0     0 ?        S<   Mär10   0:00 [DWC Notificat
root        81  0.0  0.0      0     0 ?        S<   Mär10   0:00 [VCHIQ-0]
root        82  0.0  0.0      0     0 ?        S<   Mär10   0:00 [VCHIQr-0]
root        83  0.0  0.0      0     0 ?        S<   Mär10   0:00 [VCHIQs-0]
root        84  0.0  0.0      0     0 ?        S    Mär10   0:00 [VCHIQka-0]
root        85  0.0  0.0      0     0 ?        S<   Mär10   0:00 [SMIO]
root        88  0.0  0.0      0     0 ?        S    Mär10   0:00 [irq/92-mmc1]
root        90  0.0  0.0      0     0 ?        S<   Mär10   0:00 [bioset]
root        91  0.0  0.0      0     0 ?        S    Mär10   0:22 [mmcqd/0]
root        93  0.0  0.0      0     0 ?        S    Mär10   0:04 [jbd2/mmcblk0p
root        94  0.0  0.0      0     0 ?        S<   Mär10   0:00 [ext4-rsv-conv
root        96  0.0  0.0      0     0 ?        S<   Mär10   0:00 [ipv6_addrconf
root       109  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/1:1H]
root       250  0.0  0.0      0     0 ?        S<   Mär10   0:00 [cfg80211]
root       257  0.0  0.0      0     0 ?        S<   Mär10   0:00 [brcmf_wq/mmc1
root       258  0.0  0.0      0     0 ?        S    Mär10   0:00 [brcmf_wdog/mm
root       467  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/3:1H]
root       468  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/0:1H]
root       514  0.0  0.0      0     0 ?        S<   Mär10   0:00 [kworker/2:1H]
root     12173  0.0  0.0      0     0 ?        S    Mär11   0:05 [kworker/3:1]
root     14308  0.0  0.0      0     0 ?        S    03:16   0:00 [kworker/u8:1]
root     19588  0.0  0.0      0     0 ?        S    15:32   0:00 [kworker/3:2]
root     20905  0.0  0.0      0     0 ?        S    19:02   0:00 [kworker/u8:2]
root     21290  0.0  0.0      0     0 ?        S    20:08   0:00 [kworker/0:2]
root     21601  0.0  0.0      0     0 ?        S    20:44   0:00 [kworker/1:0]
root     21724  0.0  0.0      0     0 ?        S    20:55   0:00 [kworker/0:1]
root     21779  0.0  0.0      0     0 ?        S    20:59   0:00 [kworker/2:1]
root     21792  0.0  0.0      0     0 ?        S    21:01   0:00 [kworker/1:2]
root     21795  0.0  0.0      0     0 ?        S    21:02   0:00 [kworker/2:3]
root     21839  0.0  0.0      0     0 ?        S    21:07   0:00 [kworker/2:0]
root     21845  0.0  0.0      0     0 ?        S    21:08   0:00 [kworker/1:1]


Mich wundert nur, dass der Fehler bei mir aufgetreten ist, ohne dass ich wissentlich etwas an der Programmierung verändert habe. Irgendwie schon mysteriös, wenn es von einem Modul kommen würde, wäre im Forum sicherlich mehr zu lesen.
Ich weiß mir derzeit leider nicht anders zu helfen, als mit einem notify auf den Logeintrag "Cannot fork: Cannot allocate memory" zu triggern und dann Fhem gnadenlos durchzustarten. Sicher nicht die eleganteste Art, aber (derzeit) die einzig hilfreiche.

Nachtrag:
Ich kann richtig mitverfolgen wie der genutzte MEM-Speicher bei mir größer wird, alleine in der Zeit wie ich diesen Beitrag geschrieben habe, ist der freie Speicher von 592 auf 609 gestiegen.

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 13 März 2018, 08:22:04
Du solltest mit dem "lleren Speicher Verbrauch" vorsichtig sein. Unix verwendet den leeren speicher um z.B: Daten zu cachen. Der wird hier hier als "buff/cache" angezeigt und auch beim "freien Speicher" abgezogen. Deshalb ist "freier Speicher" nicht  mit "freiem Speicher" bei Windows zu vergleichen.

Interessant ist eher das "available" .. was bei Dir Deutlich runtergeht.

Trickern würde ich eher, wenn "available" sehr klein wird (Größe müsstest Du empirisch ermitteln). "Cannot fork: Cannot allocate memory" ist eigentlich schon zu spät.

Hintergrund zum Speicherverbrauch:
In der Historie schreibt Unix immer schon in den Speicher und von dort aufs Speichermedium. Anders als Windows, was früher direkt aufs Speichermedium schrieb und das Caching später kam.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 13 März 2018, 10:14:32
ZitatReicht es aus die Module zur Fehlersuche mit disabled zu deaktivieren oder sollten diese aus Fhem entfernt werden (shutdown restart ist obligatorisch natürlich in beiden Fällen).
Haengt vom Modul ab. Da hier keiner so recht die Ursache kennt, und viel Verwirrung herrscht, wuerde ich die Suche vereinfachen, und die Module auskommentieren, also nicht nur disable flag setzen, sondern aus der fhem.cfg temporaer entfernen. Ich wuerde vorher ein komplettbackup machen.
Mein Stand ist, dass debian stretch die "Ursache" ist, habe aber in diese Richtung nichts sinnvolles im Netzt gefunden.

Zitat
2. Gibt es eine Möglichkeit (für mich als Laien), nonblocking- Module im Code (z.B. an einer Codezeile) zu erkennen?
Ich gehe davon aus, dass du "BlockingCall" meinst, d.h. die Moeglichkeit per fork das Blocken zu vermeiden.
Dafuer reicht es im Modulcode nach "use Blocking" zu suchen.

Zitat
4. Kann dieser Fehler auch von der Speicherkarte kommen, diese ist ca. 16 Monate alt?
Ich behaupte nein, wenn doch, dann waere ich sehr ueberrascht, und wuerde was Neues lernen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 13 März 2018, 17:04:55
Hallo,
mein fhem hat sich heute auch aufgehängt mit einen  haufen Meldungen von "Cannot allocate memory" im logfile habe leider zu schnell FHEM neu gestartet.... ich hätte vorher mal den Speicher untersuchen sollen..... Ich werde berichten fals es nochmal auftaucht....
Leider bekommt man es ja nicht sofort mit, ein benachrichten per push wird  warscheinlich auch nicht mehr funktionieren....

Gruß Thorsten
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 14 März 2018, 18:50:18
Hallo,

@Rudi
Danke für die Aufklärung.
Du ermunterst mich (als Laie) nicht besonders, mit der Fehlersuche in Fhem zu beginnen.
ZitatMein Stand ist, dass debian stretch die "Ursache" ist, habe aber in diese Richtung nichts sinnvolles im Netzt gefunden.

Irgendwie kann ich den Fehler logisch nicht eingrenzen, da ich absolut keine Abhängigkeiten oder Gemeinsamkeiten erkennen kann.
Am Sonntag und Montag musste ich Fhem ca. alle 12 Stunden neu starten. Am Montag konnte ich über SSH zusehen, wie der freie Speicher von Stunde zu Stunde immer weniger wurde.
Heute dagegen ohne irgend welche Updates oder große Programmänderungen läuft alles wieder (bisher) bestens, zumindest noch nach 10 Stunden.

pi@raspberrypi:~ $ sudo free -m -t
              total        used        free      shared  buff/cache   available
Mem:            927         221         468          12         237         644
Swap:            99           0          99
Total:         1027         221         568


Irgendwie höchst seltsam.
Ich will das Ganze noch ein wenig beobachten, bevor ich Updates mache.  Nach einigen Tagen will ich dann sysmon installieren und den Speicherverbrauch mitloggen. Eventuell bringt das ja neue Erkenntnisse.

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 14 März 2018, 20:56:31
Das ganze ist sehr Eigenartig.

Auf der Konsole ist noch genügend Speicher vorhanden.
pi@ccs-ht-rasp01:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         949576      517380      266696         972      165500      377924
Swap:             0           0           0


Unter FHEM ist bei der Aufzeichung der Speicher ersichtlich das das System immer mehr zu stottern beginnt bis dann plötzlich kein Speicher laut Sysmon vorhanden ist, was aber nicht stimmt laut Konsole.
list Sysmon
Internals:
   CFGFN      /media/hdd/fhem/mycfg/schnittstellen_rasp01.cfg
   CHANGED   
   DEF        1 1 1 10
   INTERVAL_BASE 60
   INTERVAL_MULTIPLIERS 1 1 1 10
   MODE       local
   NAME       sysmon
   NR         214
   STATE      it_nas@0CFB0C
   TYPE       SYSMON
   READINGS:
     2018-03-14 20:45:12   cpu0_freq       1200
     2018-03-14 20:45:12   cpu0_freq_stat  600.00 1200.00 1190.18
     2018-03-14 12:56:11   cpu0_idle_stat  0.00 99.79 70.09
     2018-03-14 20:45:12   cpu1_freq       1200
     2018-03-14 20:45:12   cpu1_freq_stat  600.00 1200.00 1190.18
     2018-03-14 12:56:11   cpu1_idle_stat  3.51 107.34 98.96
     2018-03-14 20:45:12   cpu2_freq       1200
     2018-03-14 20:45:12   cpu2_freq_stat  600.00 1200.00 1190.18
     2018-03-14 12:56:11   cpu2_idle_stat  0.62 100.00 99.45
     2018-03-14 20:45:12   cpu3_freq       1200
     2018-03-14 20:45:12   cpu3_freq_stat  600.00 1200.00 1190.18
     2018-03-14 12:56:11   cpu3_idle_stat  2.47 100.00 99.07
     2018-03-12 17:45:15   cpu_bogomips    76.80
     2018-03-14 16:16:17   cpu_core_count  4
     2018-03-14 20:45:12   cpu_freq        1200
     2018-03-14 20:45:12   cpu_freq_stat   600.00 1200.00 1190.18
     2018-03-14 12:56:11   cpu_idle_stat   30.90 99.11 92.12
     2018-03-12 17:45:15   cpu_model_name  ARMv7 Processor rev 4 (v7l)
     2018-03-14 16:16:17   cpu_temp        0.00
     2018-03-14 16:16:17   cpu_temp_avg    0.2
     2018-03-14 16:16:17   cpu_temp_stat   0.00 78.44 0.01
     2018-03-14 16:16:17   ethernet        not available
     2018-03-14 16:16:17   ethernet_diff   not available
     2018-03-14 13:57:21   ethernet_ip     192.168.17.181
     2018-03-14 13:57:21   ethernet_rx     1126266792
     2018-03-14 13:57:21   ethernet_speed  not available
     2018-03-14 13:57:21   ethernet_tx     881144010
     2018-03-14 16:16:17   fhemstarttime   1520873095
     2018-03-14 16:16:17   fhemstarttime_text 12.03.2018 17:44:55
     2018-03-14 16:16:17   fhemuptime      167482
     2018-03-14 16:16:17   fhemuptime_text 1 days, 22 hours, 31 minutes
     2018-03-14 16:00:06   fs_boot         Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /boot (not available)
     2018-03-14 16:00:06   fs_hdd          Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /media/hdd (not available)
     2018-03-14 16:00:06   fs_root         Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at / (not available)
     2018-03-14 14:42:28   idletime        175013 88.75 %
     2018-03-14 14:42:28   idletime_text   2 days, 00 hours, 36 minutes (88.75 %)
     2018-03-14 13:10:26   loadavg         0.17 0.26 0.29
     2018-03-12 17:45:15   perl_version    v5.24.1
     2018-03-14 16:16:17   ram             n/a
     2018-03-14 14:24:45   ram_used_stat   -205.39 711.58 50.23
     2018-03-14 14:42:28   starttime       1520837758
     2018-03-14 14:42:28   starttime_text  12.03.2018 07:55:58
     2018-03-14 12:56:11   stat_cpu        7331764 11547 432006 67756932 8964 0 41652
     2018-03-14 12:56:11   stat_cpu0       6931678 2135 162587 11248685 3433 0 41363
     2018-03-14 12:56:11   stat_cpu0_diff  1793 0 72 3956 2 0 12
     2018-03-14 12:56:11   stat_cpu0_percent 30.73 0.00 1.23 67.80 0.03 0.00 0.21
     2018-03-14 12:56:11   stat_cpu0_text  user: 30.73 %, nice: 0.00 %, sys: 1.23 %, idle: 67.80 %, io: 0.03 %, irq: 0.00 %, sirq: 0.21 %
     2018-03-14 12:56:11   stat_cpu1       124930 7131 123674 18810596 1531 0 183
     2018-03-14 12:56:11   stat_cpu1_diff  10 0 33 6042 0 0 0
     2018-03-14 12:56:11   stat_cpu1_percent 0.16 0.00 0.54 99.29 0.00 0.00 0.00
     2018-03-14 12:56:11   stat_cpu1_text  user: 0.16 %, nice: 0.00 %, sys: 0.54 %, idle: 99.29 %, io: 0.00 %, irq: 0.00 %, sirq: 0.00 %
     2018-03-14 12:56:11   stat_cpu2       152097 1569 68045 18844562 2109 0 69
     2018-03-14 12:56:11   stat_cpu2_diff  3 0 30 6045 0 0 0
     2018-03-14 12:56:11   stat_cpu2_percent 0.05 0.00 0.49 99.46 0.00 0.00 0.00
     2018-03-14 12:56:11   stat_cpu2_text  user: 0.05 %, nice: 0.00 %, sys: 0.49 %, idle: 99.46 %, io: 0.00 %, irq: 0.00 %, sirq: 0.00 %
     2018-03-14 12:56:11   stat_cpu3       123059 712 77700 18853089 1891 0 37
     2018-03-14 12:56:11   stat_cpu3_diff  0 0 23 6051 0 0 0
     2018-03-14 12:56:11   stat_cpu3_percent 0.00 0.00 0.38 99.62 0.00 0.00 0.00
     2018-03-14 12:56:11   stat_cpu3_text  user: 0.00 %, nice: 0.00 %, sys: 0.38 %, idle: 99.62 %, io: 0.00 %, irq: 0.00 %, sirq: 0.00 %
     2018-03-14 12:56:11   stat_cpu_diff   1806 0 158 22094 2 0 12
     2018-03-14 12:56:11   stat_cpu_percent 7.50 0.00 0.66 91.78 0.01 0.00 0.05
     2018-03-14 12:56:11   stat_cpu_text   user: 7.50 %, nice: 0.00 %, sys: 0.66 %, idle: 91.78 %, io: 0.01 %, irq: 0.00 %, sirq: 0.05 %
     2018-03-14 16:16:17   swap            n/a
     2018-03-14 14:24:45   swap_used_stat  0.00 0.00 0.00
     2018-03-14 14:42:28   uptime          197189
     2018-03-14 14:42:28   uptime_text     2 days, 06 hours, 46 minutes
   helper:
     net_ethernet_stat_class 0
     proc_fs    1
     sys_cpu0_freq 1
     sys_cpu0_temp 0
     sys_cpu1_freq 1
     sys_cpu1_temp 0
     sys_cpu2_freq 1
     sys_cpu2_temp 0
     sys_cpu3_freq 1
     sys_cpu3_temp 0
     sys_cpu4_freq 0
     sys_cpu4_temp 0
     sys_cpu5_freq 0
     sys_cpu5_temp 0
     sys_cpu6_freq 0
     sys_cpu6_temp 0
     sys_cpu7_freq 0
     sys_cpu7_temp 0
     sys_cpu_core_num 4
     sys_cpu_freq_rpi_bbb 1
     sys_cpu_num 1
     sys_cpu_temp_bbb 0
     sys_cpu_temp_rpi 1
     sys_fb     0
     sys_power_ac 0
     sys_power_bat 0
     sys_power_usb 0
     u_first_mark 1
     READOUT_RUNNING_PID:
       abortFn    SYSMON_blockingAbort
       arg        sysmon|0
       bc_pid     13656
       finishFn   SYSMON_blockingFinish
       fn         SYSMON_blockingCall
       pid        WAITING:
       timeout    55
       abortArg:
     cur_readings_map:
       cpu0_freq  CPU frequency (core 0)
       cpu0_freq_stat CPU frequency (core 0) stat
       cpu0_idle_stat CPU0 min/max/avg (idle)
       cpu1_freq  CPU frequency (core 1)
       cpu1_freq_stat CPU frequency (core 1) stat
       cpu1_idle_stat CPU1 min/max/avg (idle)
       cpu2_freq  CPU frequency (core 2)
       cpu2_freq_stat CPU frequency (core 2) stat
       cpu2_idle_stat CPU2 min/max/avg (idle)
       cpu3_freq  CPU frequency (core 3)
       cpu3_freq_stat CPU frequency (core 3) stat
       cpu3_idle_stat CPU3 min/max/avg (idle)
       cpu4_idle_stat CPU4 min/max/avg (idle)
       cpu5_idle_stat CPU5 min/max/avg (idle)
       cpu6_idle_stat CPU6 min/max/avg (idle)
       cpu7_idle_stat CPU7 min/max/avg (idle)
       cpu_bogomips BogoMIPS
       cpu_core_count Number of CPU cores
       cpu_freq   CPU frequency
       cpu_freq_stat CPU frequency stat
       cpu_idle_stat CPU min/max/avg (idle)
       cpu_model_name CPU model name
       cpu_temp   CPU temperature
       cpu_temp_avg Average CPU temperature
       cpu_temp_stat CPU temperature stat
       date       Date
       ethernet   Ethernet
       ethernet_diff Ethernet (diff)
       ethernet_ip Ethernet (IP)
       ethernet_ip6 Ethernet (IP6)
       ethernet_rx Ethernet (RX)
       ethernet_speed Ethernet (speed)
       ethernet_tx Ethernet (TX)
       fhemstarttime Fhem start time
       fhemstarttime_text Fhem start time
       fhemuptime System up time
       fhemuptime_text FHEM up time
       fs_boot    Filesystem-Boot
       fs_boot_free Filesystem-Boot (free)
       fs_boot_used Filesystem-Boot (used)
       fs_boot_used_percent Filesystem-Boot (used %)
       fs_hdd     LAN-HDD
       fs_hdd_free LAN-HDD (free)
       fs_hdd_used LAN-HDD (used)
       fs_hdd_used_percent LAN-HDD (used %)
       fs_root    microSD-lokal
       fs_root_free microSD-lokal (free)
       fs_root_used microSD-lokal (used)
       fs_root_used_percent microSD-lokal (used %)
       idletime   Idle time
       idletime_text Idle time
       io_sda     TEST
       io_sda_diff TEST
       io_sda_raw TEST
       loadavg    Load average
       loadavg_1  Load average 1
       loadavg_15 Load average 15
       loadavg_5  Load average 5
       perl_version Perl Version
       ram        RAM
       ram_free   RAM free
       ram_free_percent RAM free %
       ram_total  RAM total
       ram_used   RAM used
       ram_used_stat RAM used stat
       starttime  System start time
       starttime_text System start time
       stat_cpu   CPU statistics
       stat_cpu0  CPU0 statistics
       stat_cpu0_diff CPU0 statistics (diff)
       stat_cpu0_percent CPU0 statistics (diff, percent)
       stat_cpu0_text CPU0 statistics (text)
       stat_cpu1  CPU1 statistics
       stat_cpu1_diff CPU1 statistics (diff)
       stat_cpu1_percent CPU1 statistics (diff, percent)
       stat_cpu1_text CPU1 statistics (text)
       stat_cpu2  CPU2 statistics
       stat_cpu2_diff CPU2 statistics (diff)
       stat_cpu2_percent CPU2 statistics (diff, percent)
       stat_cpu2_text CPU2 statistics (text)
       stat_cpu3  CPU3 statistics
       stat_cpu3_diff CPU3 statistics (diff)
       stat_cpu3_percent CPU3 statistics (diff, percent)
       stat_cpu3_text CPU3 statistics (text)
       stat_cpu4  CPU4 statistics
       stat_cpu4_diff CPU4 statistics (diff)
       stat_cpu4_percent CPU4 statistics (diff, percent)
       stat_cpu4_text CPU4 statistics (text)
       stat_cpu5  CPU5 statistics
       stat_cpu5_diff CPU5 statistics (diff)
       stat_cpu5_percent CPU5 statistics (diff, percent)
       stat_cpu5_text CPU5 statistics (text)
       stat_cpu6  CPU6 statistics
       stat_cpu6_diff CPU6 statistics (diff)
       stat_cpu6_percent CPU6 statistics (diff, percent)
       stat_cpu6_text CPU6 statistics (text)
       stat_cpu7  CPU7 statistics
       stat_cpu7_diff CPU7 statistics (diff)
       stat_cpu7_percent CPU7 statistics (diff, percent)
       stat_cpu7_text CPU7 statistics (text)
       stat_cpu_diff CPU statistics (diff)
       stat_cpu_idle_percent CPU statistics idle %
       stat_cpu_io_percent CPU statistics io %
       stat_cpu_irq_percent CPU statistics irq %
       stat_cpu_nice_percent CPU statistics nice %
       stat_cpu_percent CPU statistics (diff, percent)
       stat_cpu_sirq_percent CPU statistics sirq %
       stat_cpu_sys_percent CPU statistics sys %
       stat_cpu_text CPU statistics (text)
       stat_cpu_user_percent CPU statistics user %
       swap       swap
       swap_free  swap free
       swap_total swap total
       swap_used  swap used
       swap_used_percent swap used %
       swap_used_stat swap used stat
       uptime     System up time
       uptime_text System up time
     excludes:
     shadow_map:
       cpu_core_count 4
       cpu_temp   0.00
       cpu_temp_avg 0.2
       cpu_temp_stat 0.00 78.44 0.01
       ethernet   not available
       ethernet_diff not available
       fhemstarttime 1520873095
       fhemstarttime_text 12.03.2018 17:44:55
       fhemuptime 183581
       fhemuptime_text 2 days, 02 hours, 59 minutes
       fs_boot    Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /boot (not available)
       fs_hdd     Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /media/hdd (not available)
       fs_root    Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at / (not available)
       ram        n/a
       swap       n/a
Attributes:
   alias      Systemmonitor
   event-min-interval .*:600
   event-on-change-reading cpu_temp,cpu_temp_avg,cpu_freq,ethernet_diff,loadavg,ram,fs_.*,stat_cpu_percent
   eventMap   Initialized:it_nas@0CFB0C
   filesystems fs_boot:/boot:Filesystem-Boot,fs_root:/:microSD-lokal,fs_hdd:/media/hdd:LAN-HDD
   group      RPi
   icon       time_graph
   network-interfaces ethernet:eth0:Ethernet
   room       _Systemlast
   sortby     01
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: kaputt am 14 März 2018, 21:35:40
Wo sagt sysmon das kein Arbeitsspeicher frei wäre?
Ich nur rund 450 MB verwendet.
Hast du eine(n) Swappartition/Datei?
Wenn ja wie ist den swappiness eingestellt?
sysctl vm.swappiness
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 15 März 2018, 07:54:16
Wenn Du Dir seinen "free" Auszug ansiehst, er hat keinen Swap.
Swap:             0           0           0

Es sieht mir danach aus, das ein Modul kurzfristig sehr viel Speicher haben will und es (fast) sofort wieder freigibt ... komisch
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 15 März 2018, 07:59:48
Ist alles wunderbar bei der Übersicht, dem List und den zugehörigen Plots  zu sehen das plötzlich kein einziger Speicher laut FHEM Sysmon vorhanden sein soll.
Prüfe ich dazu auf der Konsole den Speicher ist aber aber noch vorhanden.
Swap Speicher verwende ich bei keinen Raspberry.

Nur warum FHEM Sysmon wiedersprüchlich zu free auf der Konsole keinen Speicher mehr anzeigt ist eigenartig.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 15 März 2018, 08:07:02
Es könnte sein, weil sysmon zu einem anderen Zeitpiunkt guckt als Du in Deine Konsole. Weiß auch nicht, wie viel Recourcen sysmon dafür braucht.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 15 März 2018, 10:06:13
Da ist kaum ein Zeitunterschied beim Vergleich zwischen Sysmon und Konsole.
Zudem gibt es ab dem Cannot fork: Cannot allocate memory LOG Eintrages keine Änderungen der ausgefallenen Werte.
Laut Sysmon, wie man anhand der Printcopies sehen kann, gibt es nicht nur keinen Speicher vom RAM. der microSD und HDD sondern auch keine CPU Temperatur, CPU Last und keinen Netzwertrafic der von Sysmon erfasst werden kann.
Zu dem werden auch keine Leistungswerte der LS110 mehr erfasst.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 15 März 2018, 10:22:35
Was steht im kern.log zu der Zeit?
Titel: Antw:Cannot fork: Cannot allocate memory
Beitrag von: Brice am 16 März 2018, 08:28:33
Gleiches Problem habe ich seit vorgestern. Letzte Meldungen im Log sind

2018.03.15 23:02:31 1: Cannot fork: Cannot allocate memory
2018.03.15 23:01:10 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2018.03.15 23:01:10 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3635.
2018.03.15 23:00:58 2: PRESENCE (Stefan_Bluetooth) - error while processing check: no hcitool binary found. Please check that the bluez-package is properly installed
2018.03.15 23:00:58 1: PERL WARNING: Use of uninitialized value $hcitool in -x at ./FHEM/73_PRESENCE.pm line 957.
2018.03.15 23:00:58 1: PERL WARNING: Use of uninitialized value $hcitool in scalar chomp at ./FHEM/73_PRESENCE.pm line 955.
2018.03.15 23:00:58 1: PERL WARNING: Use of uninitialized value $hcitool in concatenation (.) or string at ./FHEM/73_PRESENCE.pm line 954.
2018.03.15 23:00:58 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/73_PRESENCE.pm line 941.
2018.03.15 22:59:51 2: PRESENCE (Angelika_Bluetooth) - error while processing check: no hcitool binary found. Please check that the bluez-package is properly installed
2018.03.15 22:59:51 1: PERL WARNING: Use of uninitialized value $hcitool in -x at ./FHEM/73_PRESENCE.pm line 957.
2018.03.15 22:59:51 1: PERL WARNING: Use of uninitialized value $hcitool in scalar chomp at ./FHEM/73_PRESENCE.pm line 955.
2018.03.15 22:59:51 1: PERL WARNING: Use of uninitialized value $hcitool in concatenation (.) or string at ./FHEM/73_PRESENCE.pm line 954.
2018.03.15 22:59:51 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/73_PRESENCE.pm line 941.
2018.03.15 22:56:10 2: PRESENCE (Angelika_Bluetooth) - error while processing check: no hcitool binary found. Please check that the bluez-package is properly installed
2018.03.15 22:56:10 1: PERL WARNING: Use of uninitialized value $hcitool in -x at ./FHEM/73_PRESENCE.pm line 957.
2018.03.15 22:56:10 1: PERL WARNING: Use of uninitialized value $hcitool in scalar chomp at ./FHEM/73_PRESENCE.pm line 955.
2018.03.15 22:56:10 1: PERL WARNING: Use of uninitialized value $hcitool in concatenation (.) or string at ./FHEM/73_PRESENCE.pm line 954.
2018.03.15 22:56:10 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/73_PRESENCE.pm line 941.
2018.03.15 22:55:09 1: PERL WARNING: Use of uninitialized value $devname in pattern match (m//) at ./FHEM/73_PRESENCE.pm line 982.
2018.03.15 22:55:09 1: PERL WARNING: Use of uninitialized value $devname in concatenation (.) or string at ./FHEM/73_PRESENCE.pm line 980.
2018.03.15 22:55:09 1: PERL WARNING: Use of uninitialized value $devname in scalar chomp at ./FHEM/73_PRESENCE.pm line 979.


Das Produktivsystem wird heute wieder unter Jessie Lite aufgesetzt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 16 März 2018, 09:06:23
Damit das Problem greifbarerer wird, versuche ich es zusammenfassen. Wenn ich was falsch verstanden habe, bitte korrigieren:
- nach einem update auf das am 10.3.2018 freigegebene Debian Stretch gibt es Speicherprobleme , die sich innerhalb weniger Stunden zu Fehlermeldungen beim fork fuehren: ein FHEM Prozess waechst in 18 Stunden von 110MB auf 360MB, in einem anderen Fall in 22 Stunden von 40MB auf 160MB.
- Systeme liefen bisher ohne Probleme auf Debian Jessie (wie lange maximal?)
- es betrifft nur RPis
- die FHEM-internen Speicherstrukturen (soweit es mit fhemdebug zu messen ist) sind nicht gewachsen
- es gibt bisher keine Hinweise darauf, an welcher Stelle der Speicher verlorengeht.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 16 März 2018, 12:19:08
>>Was mich mal interessiert, welche PERL Versionen sind es eigentlich, über die wir hier sprechen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 16 März 2018, 12:49:56
Zitat von: Wernieman am 16 März 2018, 12:19:08
>>Was mich mal interessiert, welche PERL Versionen sind es eigentlich, über die wir hier sprechen?

Bei mir mit den gleichen "Memory" Problemen auf RPi 3 Stretch nur FHEM (von gestern) headless ohne andere zusätzlichen Prozesse ohne Swap mit Perl v5.24.1

Nach drei Tagen muss ich FHEM rebooten, dann wird mit SYSMON wieder freier Speicher angezeigt. Nach 4 Tagen stottert das System mit Memorymeldungen.

Ich beobachte zur Zeit folgende Module kritisch: SIP, Dblog, Tahoma und MPD. MPD werde ich dieses Wochenende mal auf einen anderen RPi "auslagern"...

Gruss
  Enno
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: kaputt am 16 März 2018, 15:32:03
Stretch is the development codename for Debian 9. It is the current stable distribution, released 2017-06-17
Stammt vom Debian Wiki.
Ich glaube auch nicht das dieses Problem ausschließlich ein Debian Stretch Problem ist! Denn dann wäre der Aufschrei schon lange zu hören gewesen.
Durchaus möglich das es eine Kombination aus vielen Kleinigkeiten ist, aber wer will das auseinanderdrösseln?
Deswegen auch meine Frage nach dem Swap!
Da keiner eingerichtet ist wäre es evtl. ein Weg um heraus zu finden ob hier ein echtes Problem vorliegt! Oder ob einfach nur ein Prozess mehr Speicher haben will als vorhanden ist.
Die swappiness dann mal auf 60 (ist glaube ich Default) setzten und schauen was passiert, 1GB ist ja jetzt nun mal nicht so der Brüller.
Nachteil wäre allerdings wenn er anfängt zu swapen dann wird das Ding schnarch langsam  :-[
Wenn ihr immer noch der Meinung seid es ist ein Bug dann hier hin https://www.debian.org/Bugs/Reporting (https://www.debian.org/Bugs/Reporting)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 16 März 2018, 15:40:36
ZitatDa keiner eingerichtet ist wäre es evtl. ein Weg um heraus zu finden ob hier ein echtes Problem vorliegt!
Das Problem ist ziemlich sicher vom Swap unabhaengig: es ist was falsch, wenn ein FHEM Prozess einer produktiven FHEM-Installation (d.h., wo man nicht staendig was Neues einbaut), innerhalb von einem Tag auf das 4-fache waechst.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: kaputt am 16 März 2018, 16:01:14
Zitat von: rudolfkoenig am 16 März 2018, 15:40:36
Das Problem ist ziemlich sicher vom Swap unabhaengig: es ist was falsch, wenn ein FHEM Prozess einer produktiven FHEM-Installation (d.h., wo man nicht staendig was Neues einbaut), innerhalb von einem Tag auf das 4-fache waechst.
Da will ich dir nicht wiedersprechen. Der Efekt wäre wenn mit Swap das System weiter läuft und bedienbar ist und es sich zeigt das der Prozess XY extrem viel Speicher benötigt hätte man/frau einen Ansatzpunkt!
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 16 März 2018, 16:23:19
Hallo Rudi,

bei meinem System war und ist es unter Jessie so, das ich mehrere Wochen lang ohne Reboot auskomme, unter Stretch dauert es ~ 24 Stunden und dann muss rebootet werden.
Uneter Verdacht habe ich ebenfalls das DBLog, auf dem Produktivsystem kann / will ich es aber nicht deaktivieren.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 16 März 2018, 16:27:30
Hat jemand von denjenigen mit dem Problem das Netatmo Modul definiert?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 16 März 2018, 16:38:19
Hallo,

bei mir läuft Fhem auf dem Raspi3 mit Stretch nun seit 43 Stunden, zumindest ohne Fehler in Fhem.
Ich beobachte nach einiger Zeit immer wieder den freien Speicher vom Raspi, dieser schwankt zwischen 136 - 44 Mb in den letzten Stunden. Bei 50 Mb kamen in der Vergangenheit schon die Cannot fork Meldungen. Der Swap Speicher schwankt bei mir zwischen 99-50 MB.

Es könnte natürlich sein, dass auch in der letzten Zeit der freie Speicher schon so gering war, ich hatte nur nie nach den freien Speicher geschaut, erst als Fehler in Fhem aufgetreten sind, rückt dies in das Interesse. In der Vergangenheit ist der Raspi auch bei mir mehrere Wochen, ohne Reboot gelaufen.

Übrigens, folgendes Perl ist bei mir in Verwendung:
This is perl 5, version 24, subversion 1 (v5.24.1) built for arm-linux-gnueabihf-thread-multi-64int
(with 75 registered patches, see perl -V for more detail)


Ergänzung: Netamo ist bei mir nicht installiert.

Gruß Reinhard

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 16 März 2018, 16:39:47
Koennten bitte alle, die dieses Problem haben, die Ausgabe von version hier anhaengen?
Und wenn jemand unter Stretch keine Probleme hat, der sollte das bitte auch tun, aber dazuschreiben, dass es eben keine Probleme gibt.
Evtl. hilft uns danach die Mengenlehre weiter.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 16 März 2018, 16:45:24
Hallo,

Probleme mit "Cannot fork" unter RPI3 und Stretch.

Latest Revision: 16366

File                  Rev   Last Change

fhem.pl               16354 2018-03-09 07:31:31Z rudolfkoenig
57_ABFALL.pm          11020 2017-09-13 00:40:21Z uniqueck
96_allowed.pm         16295 2018-02-28 22:11:09Z rudolfkoenig
90_at.pm              15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm      15620 2017-12-16 18:10:36Z rudolfkoenig
57_Calendar.pm        15612 2017-12-15 09:26:59Z neubert
00_CUL.pm             15027 2017-09-08 09:11:43Z rudolfkoenig
10_CUL_HM.pm          16258 2018-02-24 22:11:14Z martinp876
93_DbLog.pm           16336 2018-03-05 21:55:44Z DS_Starter
93_DbRep.pm           16347 2018-03-07 20:29:44Z DS_Starter
98_DOIF.pm            16182 2018-02-14 21:36:04Z Damian
98_dummy.pm           12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm      14888 2017-08-13 12:07:12Z rudolfkoenig
00_FBAHAHTTP.pm       16344 2018-03-06 21:06:34Z rudolfkoenig
10_FBDECT.pm          16293 2018-02-28 21:33:57Z rudolfkoenig
01_FHEMWEB.pm         16350 2018-03-07 21:30:37Z rudolfkoenig
92_FileLog.pm         15874 2018-01-13 17:16:33Z rudolfkoenig
88_HMCCU.pm           16298 2018-03-01 08:04:35Z zap
88_HMCCUDEV.pm        16038 2018-01-29 16:07:43Z zap
88_HMCCURPCPROC.pm    16165 2018-02-13 10:55:01Z zap
98_HTTPMOD.pm         16216 2018-02-18 15:26:11Z StefanStrobel
02_HTTPSRV.pm         13976 2017-04-12 13:35:44Z neubert
98_JsonList2.pm       16293 2018-02-28 21:33:57Z rudolfkoenig
37_ModbusCoil.pm         14 2017-01-14 16:46:00Z ChrisD
37_ModbusRegister.pm     24 2018-02-06 21:22:00Z CD
# $Id: 36_ModbusTCPServer.pm 0021 $
91_notify.pm          15937 2018-01-20 13:43:28Z rudolfkoenig
No Id found for 99_perfmon.pm
59_PROPLANTA.pm       15358 2017-10-30 20:04:27Z tupol
70_Pushover.pm        16358 2018-03-09 09:58:05Z loredo
33_readingsGroup.pm   16299 2018-03-01 08:06:55Z justme1968
96_SIP.pm             15827 2018-01-08 18:36:07Z Wzut
99_SUNRISE_EL.pm      16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm             16293 2018-02-28 21:33:57Z rudolfkoenig
98_telnet.pm          16293 2018-02-28 21:33:57Z rudolfkoenig
98_Text2Speech.pm     13704 2017-03-14 19:33:42Z Tobias.Faust
99_Utils.pm           15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm         15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm         16293 2018-02-28 21:33:57Z rudolfkoenig

ABFALL_getEvents.pm   11021 2017-09-13 00:32:22Z uniqueck
ABFALL_setUpdate.pm   11021 2017-09-13 00:32:22Z uniqueck
Blocking.pm           15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm              11159 2016-03-30 16:08:06Z justme1968
DevIo.pm              16329 2018-03-04 20:18:08Z rudolfkoenig
FritzBoxUtils.pm      16344 2018-03-06 21:06:34Z rudolfkoenig
HMCCUConf.pm          16301 2018-03-01 10:47:08Z zap
HMConfig.pm           16265 2018-02-25 18:22:43Z martinp876
HttpUtils.pm          16343 2018-03-06 20:44:37Z rudolfkoenig
Info.pm                  28 2008-11-09 01:08:44Z dsully
myUtilsTemplate.pm     7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm             10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm      16211 2018-02-18 11:59:09Z rudolfkoenig
SubProcess.pm         14334 2017-05-20 23:11:06Z neubert
TcpServerUtils.pm     15707 2017-12-27 14:41:21Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968



Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 16 März 2018, 16:48:08
Zitat von: rudolfkoenig am 16 März 2018, 09:06:23
- nach einem update auf das am 10.3.2018 freigegebene Debian Stretch gibt es Speicherprobleme
Diese Probleme bestanden auch bei vorherigen Lite Stretch.
Der Rest passt.

Wie in einem meiner vorherigen List ersichtlich verwende ich die Perl_version V5.24.1.
Wie rufe ich das kern.log in diesem Zustand auf der Konsole auf.

Mit Swap und DBLog kann es eigentlich auch nicht zusammenhängen, den beides verwende ich nicht.
Laufzeit des Systems ungefähr 24 Stunden, dann ist ein Reboot des Systems notwendig.
In den Sysmon Plots sieht wie der Ramspeicher immer mehr belastet wird bis dann das System immer mehr laut den Plots Speicher verliert und dann plötzlich überhaupt keinen Speicher welcher Art auch immer anzeigt unter FHEM.
Laut Konsole free -m hat sich aber am Speicher nichts geändert.

Cannot fork mit dieser Version:

Latest Revision: 16414

File                Rev   Last Change

fhem.pl             16403 2018-03-13 21:16:06Z rudolfkoenig
96_allowed.pm       16295 2018-02-28 22:11:09Z rudolfkoenig
95_Astro.pm         15508 2017-11-27 15:24:42Z phenning
90_at.pm            15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm    15620 2017-12-16 18:10:36Z rudolfkoenig
98_cloneDummy.pm    13015 2017-01-08 20:26:33Z betateilchen
00_CUL.pm           15027 2017-09-08 09:11:43Z rudolfkoenig
10_CUL_HM.pm        16258 2018-02-24 22:11:14Z martinp876
No Id found for 14_CUL_REDIRECT.pm
14_CUL_TCM97001.pm  16274 2018-02-25 20:42:39Z bjoernh
14_CUL_TX.pm        14784 2017-07-25 15:06:43Z rudolfkoenig
14_CUL_WS.pm        15603 2017-12-13 20:53:47Z rudolfkoenig
98_dewpoint.pm      15927 2018-01-19 15:46:47Z hotbso
98_DOIF.pm          16406 2018-03-14 18:02:13Z Damian
98_dummy.pm         12700 2016-12-02 16:49:42Z rudolfkoenig
70_ENIGMA2.pm       14985 2017-09-01 11:18:48Z loredo
91_eventTypes.pm    14888 2017-08-13 12:07:12Z rudolfkoenig
93_FHEM2FHEM.pm     15006 2017-09-05 09:37:33Z rudolfkoenig
01_FHEMWEB.pm       16407 2018-03-14 19:43:35Z rudolfkoenig
11_FHT.pm           16293 2018-02-28 21:33:57Z rudolfkoenig
92_FileLog.pm       15874 2018-01-13 17:16:33Z rudolfkoenig
95_FLOORPLAN.pm     13735 2017-03-19 12:43:53Z UliM
10_FS20.pm          14888 2017-08-13 12:07:12Z rudolfkoenig
No Id found for 58_GPIO4.pm
98_help.pm          15223 2017-10-10 10:14:24Z betateilchen
14_Hideki.pm        15450 2017-11-18 21:34:47Z Sidey
98_HMinfo.pm        16225 2018-02-19 19:23:47Z martinp876
12_HMS.pm           15027 2017-09-08 09:11:43Z rudolfkoenig
00_HMUARTLGW.pm     16166 2018-02-13 19:52:08Z mgernoth
95_holiday.pm       16293 2018-02-28 21:33:57Z rudolfkoenig
98_HourCounter.pm   11307 2016-04-25 08:02:06Z rudolfkoenig
98_HTTPMOD.pm       16216 2018-02-18 15:26:11Z StefanStrobel
52_I2C_MCP23017.pm  12059 2016-08-22 21:14:59Z klauswitt
No Id found for 52_I2C_SUSV.pm
10_IT.pm            14852 2017-08-06 08:48:24Z bjoernh
70_JSONMETER.pm     16360 2018-03-09 14:18:10Z tupol
13_KS300.pm         15627 2017-12-17 11:00:46Z rudolfkoenig
98_logProxy.pm      16299 2018-03-01 08:06:55Z justme1968
# $Id: 99_myUtils.pm  2016-09-25  V1.0  Christian Schmidt $
99_myUtils_Astro.pm    11 2017-07-15 00:00:00Z Fhemmike
91_notify.pm        15937 2018-01-20 13:43:28Z rudolfkoenig
41_OREGON.pm        12928 2017-01-02 00:23:46Z Sidey
No Id found for 99_perfmon.pm
59_PROPLANTA.pm     15358 2017-10-30 20:04:27Z tupol
33_readingsGroup.pm 16299 2018-03-01 08:06:55Z justme1968
33_readingsProxy.pm 16299 2018-03-01 08:06:55Z justme1968
# $Id: 44_ROLLO.pm 1202 2016-08-29 19:14:00Z                                         $ #
00_RPII2C.pm        15021 2017-09-06 19:48:55Z klausw
51_RPI_GPIO.pm      15821 2018-01-07 21:36:43Z klausw
# $Id: 14_SD_UT.pm 32 2016-04-02 14:00:00 v3.2-dev $
14_SD_WS07.pm       15450 2017-11-18 21:34:47Z Sidey
91_sequence.pm      14996 2017-09-03 15:20:42Z rudolfkoenig
No Id found for 99_sethmkey.pm
00_SIGNALduino.pm   16390 2018-03-11 22:22:56Z Sidey
10_SOMFY.pm         15807 2018-01-06 23:32:41Z viegener
99_SUNRISE_EL.pm    16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm           16402 2018-03-13 21:14:22Z rudolfkoenig
42_SYSMON.pm        15910 2018-01-16 23:07:56Z hexenmeister
98_telnet.pm        16293 2018-02-28 21:33:57Z rudolfkoenig
45_TRX.pm           11456 2016-05-15 20:19:24Z wherzig
46_TRX_ELSE.pm      11451 2016-05-15 19:04:06Z wherzig
46_TRX_LIGHT.pm     11592 2016-06-01 21:15:30Z wherzig
46_TRX_SECURITY.pm  11452 2016-05-15 19:05:17Z wherzig
46_TRX_WEATHER.pm   11450 2016-05-15 19:03:23Z wherzig
59_Twilight.pm      16005 2018-01-27 06:05:51Z igami
10_UNIRoll.pm       12819 2016-12-18 14:27:48Z C_Herrmann
99_Utils.pm         15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm       15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm       16293 2018-02-28 21:33:57Z rudolfkoenig

Blocking.pm         15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm            11159 2016-03-30 16:08:06Z justme1968
DevIo.pm            16329 2018-03-04 20:18:08Z rudolfkoenig
HMConfig.pm         16265 2018-02-25 18:22:43Z martinp876
HttpUtils.pm        16407 2018-03-14 19:43:35Z rudolfkoenig
RTypes.pm           10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm    16211 2018-02-18 11:59:09Z rudolfkoenig
TcpServerUtils.pm   15707 2017-12-27 14:41:21Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 16 März 2018, 17:08:42
Zitat von: rudolfkoenig am 16 März 2018, 16:39:47
Koennten bitte alle, die dieses Problem haben, die Ausgabe von version hier anhaengen?
Und wenn jemand unter Stretch keine Probleme hat, der sollte das bitte auch tun, aber dazuschreiben, dass es eben keine Probleme gibt.
Evtl. hilft uns danach die Mengenlehre weiter.

Wie bekomme ich die Version heraus?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 16 März 2018, 17:08:57
Bezüglich kern.log
cat /var/log/kern.log

bezüglich perl-version
perl -v

bezüglich FHEM-Modulversionen:
in der "Fhem-Commandozeile"
version
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 16 März 2018, 17:09:36
Zitat von: Burny4600 am 16 März 2018, 16:48:08
Diese Probleme bestanden auch bei vorherigen Lite Stretch.
Das kann ich nicht bestätigen. Auf meinem Produktivsystem Pi 3b lief FHEM unter Stetch ab 24.10.2017 bis zum 14.03.2018 problemlos. Am 12.03.2018 habe ich ein apt-get udpate && apt-get upgrade durchgeführt.

Ein zweites System (FHEM nur mit PIR_GIPO, mpd, TechemWZ) ohne update/upgrade läuft seit dem 24.10.2017 ohne "Cannot fork: Cannot allocate memory".

Das Produktivsystem hatte ich heute noch mit einem gesicherten Image vom 18.01.2019 (Stetch aufgesetzt am 24.10.2017) versehen und konnte im Sysmon wiederum sehen, wie sich RAM permanent füllt. Produktivsytem ist akutell unter Jessie aufgesetzt und wird weiter beobachtet.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 16 März 2018, 17:21:43
Hier das Problemsystem:

Latest Revision: 16411

File                        Rev   Last Change

fhem.pl                     16403 2018-03-13 21:16:06Z rudolfkoenig
96_allowed.pm               16295 2018-02-28 22:11:09Z rudolfkoenig
No Id found for 47_anelPwrCtrl.pm
95_Astro.pm                 15508 2017-11-27 15:24:42Z phenning
90_at.pm                    15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm            15620 2017-12-16 18:10:36Z rudolfkoenig
98_cmdalias.pm              16300 2018-03-01 08:48:21Z rudolfkoenig
00_CUL.pm                   15027 2017-09-08 09:11:43Z rudolfkoenig
15_CUL_EM.pm                16293 2018-02-28 21:33:57Z rudolfkoenig
09_CUL_FHTTK.pm             15426 2017-11-12 20:10:43Z Matscher
10_CUL_HM.pm                16258 2018-02-24 22:11:14Z martinp876
14_CUL_TX.pm                14784 2017-07-25 15:06:43Z rudolfkoenig
14_CUL_WS.pm                15603 2017-12-13 20:53:47Z rudolfkoenig
93_DbLog.pm                 16369 2018-03-10 08:15:06Z DS_Starter
98_dewpoint.pm              15927 2018-01-19 15:46:47Z hotbso
98_DOIF.pm                  16406 2018-03-14 18:02:13Z Damian
98_dummy.pm                 12700 2016-12-02 16:49:42Z rudolfkoenig
73_ElectricityCalculator.pm 16260 2018-02-25 09:25:23Z Sailor
91_eventTypes.pm            14888 2017-08-13 12:07:12Z rudolfkoenig
72_FB_CALLLIST.pm           16346 2018-03-07 16:01:02Z markusbloch
72_FB_CALLMONITOR.pm        16392 2018-03-12 13:45:07Z markusbloch
93_FHEM2FHEM.pm             15006 2017-09-05 09:37:33Z rudolfkoenig
01_FHEMWEB.pm               16407 2018-03-14 19:43:35Z rudolfkoenig
11_FHT.pm                   16293 2018-02-28 21:33:57Z rudolfkoenig
92_FileLog.pm               15874 2018-01-13 17:16:33Z rudolfkoenig
95_FLOORPLAN.pm             13735 2017-03-19 12:43:53Z UliM
72_FRITZBOX.pm              16285 2018-02-27 17:58:54Z tupol
10_FS20.pm                  14888 2017-08-13 12:07:12Z rudolfkoenig
89_FULLY.pm                 15968 2018-01-23 12:36:57Z zap
73_GasCalculator.pm         16261 2018-02-25 09:26:04Z Sailor
98_help.pm                  15223 2017-10-10 10:14:24Z betateilchen
98_HMinfo.pm                16225 2018-02-19 19:23:47Z martinp876
12_HMS.pm                   15027 2017-09-08 09:11:43Z rudolfkoenig
00_HMUARTLGW.pm             16166 2018-02-13 19:52:08Z mgernoth
31_HUEDevice.pm             16352 2018-03-08 07:42:40Z justme1968
73_km200.pm                 14221 2017-05-08 10:55:47Z Sailor
30_LIGHTIFY.pm              13672 2017-03-11 23:20:19Z justme1968
98_logProxy.pm              16299 2018-03-01 08:06:55Z justme1968
98_Modbus.pm                15871 2018-01-13 16:24:22Z StefanStrobel
98_ModbusAttr.pm            15034 2017-09-09 12:01:43Z StefanStrobel
73_MPD.pm                   15830 2018-01-08 18:45:38Z Wzut
75_msgConfig.pm             15167 2017-10-01 18:46:23Z loredo
76_msgDialog.pm             15678 2017-12-24 06:31:42Z igami
91_notify.pm                15937 2018-01-20 13:43:28Z rudolfkoenig
21_OWAD.pm                  13642 2017-03-08 16:41:55Z phenning
21_OWCOUNT.pm               13664 2017-03-11 02:09:19Z phenning
21_OWID.pm                  13642 2017-03-08 16:41:55Z phenning
21_OWMULTI.pm               13642 2017-03-08 16:41:55Z phenning
21_OWSWITCH.pm              13668 2017-03-11 14:24:14Z phenning
21_OWTHERM.pm               13642 2017-03-08 16:41:55Z phenning
00_OWX.pm                   14108 2017-04-26 04:03:51Z phenning
33_readingsGroup.pm         16299 2018-03-01 08:06:55Z justme1968
96_SIP.pm                   15827 2018-01-08 18:36:07Z Wzut
98_statistics.pm            16357 2018-03-09 09:01:35Z tupol
99_SUNRISE_EL.pm            16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm                   16402 2018-03-13 21:14:22Z rudolfkoenig
42_SYSMON.pm                15910 2018-01-16 23:07:56Z hexenmeister
26_tahoma.pm                15245 2017-10-13 18:26:18Z mike3436
50_TelegramBot.pm           16382 2018-03-11 13:20:55Z viegener
98_telnet.pm                16293 2018-02-28 21:33:57Z rudolfkoenig
98_Text2Speech.pm           13704 2017-03-14 19:33:42Z Tobias.Faust
59_Twilight.pm              16005 2018-01-27 06:05:51Z igami
99_Utils.pm                 15713 2017-12-28 11:01:02Z rudolfkoenig
77_UWZ.pm                   15650 2017-12-20 05:41:22Z CoolTux
98_version.pm               15140 2017-09-26 09:20:09Z markusbloch
73_WaterCalculator.pm       16262 2018-02-25 09:26:25Z Sailor
98_weblink.pm               16293 2018-02-28 21:33:57Z rudolfkoenig
98_WeekdayTimer.pm          16005 2018-01-27 06:05:51Z igami
59_Wunderground.pm          15171 2017-10-02 09:52:16Z loredo
71_YAMAHA_AVR.pm            15417 2017-11-10 20:03:22Z markusbloch

BatteryCheckUtils.pm         7570 2018-03-06 20:55:44Z Amenophis86
Blocking.pm                 15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm                    11159 2016-03-30 16:08:06Z justme1968
DevIo.pm                    16329 2018-03-04 20:18:08Z rudolfkoenig
FritzBoxUtils.pm            16344 2018-03-06 21:06:34Z rudolfkoenig
GPUtils.pm                   6653 2014-10-02 11:59:37Z ntruchsess
HMConfig.pm                 16265 2018-02-25 18:22:43Z martinp876
HttpUtils.pm                16407 2018-03-14 19:43:35Z rudolfkoenig
Info.pm                        28 2008-11-09 01:08:44Z dsully
msgSchema.pm                16359 2018-03-09 11:35:12Z loredo
myUtilsTemplate.pm           7570 2015-01-14 18:31:44Z rudolfkoenig
No Id found for ProtoThreads.pm
RTypes.pm                   10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm            16211 2018-02-18 11:59:09Z rudolfkoenig
TcpServerUtils.pm           15707 2017-12-27 14:41:21Z rudolfkoenig
UConv.pm                    14398 2017-05-28 09:40:42Z loredo
Unit.pm                     14136 2017-04-29 16:31:46Z loredo

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 16 März 2018, 17:21:54
ZitatWie bekomme ich die Version heraus?
In der FHEM-Eingabezeile version eintippen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 16 März 2018, 17:22:36
@Brice
Bei mir ist es so und es muss ja nicht heißen das ein jeder die gleichen Fehler haben muss.

List mit Cannot fork zweites System gerade wieder
Latest Revision: 16411

File                Rev   Last Change

fhem.pl             16403 2018-03-13 21:16:06Z rudolfkoenig
96_allowed.pm       16295 2018-02-28 22:11:09Z rudolfkoenig
90_at.pm            15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm    15620 2017-12-16 18:10:36Z rudolfkoenig
98_DOIF.pm          16406 2018-03-14 18:02:13Z Damian
98_dummy.pm         12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm    14888 2017-08-13 12:07:12Z rudolfkoenig
93_FHEM2FHEM.pm     15006 2017-09-05 09:37:33Z rudolfkoenig
01_FHEMWEB.pm       16407 2018-03-14 19:43:35Z rudolfkoenig
92_FileLog.pm       15874 2018-01-13 17:16:33Z rudolfkoenig
95_FLOORPLAN.pm     13735 2017-03-19 12:43:53Z UliM
98_HTTPMOD.pm       16216 2018-02-18 15:26:11Z StefanStrobel
52_I2C_MCP23017.pm  12059 2016-08-22 21:14:59Z klauswitt
No Id found for 52_I2C_SUSV.pm
70_JSONMETER.pm     16360 2018-03-09 14:18:10Z tupol
98_logProxy.pm      16299 2018-03-01 08:06:55Z justme1968
98_Modbus.pm        15871 2018-01-13 16:24:22Z StefanStrobel
98_ModbusAttr.pm    15034 2017-09-09 12:01:43Z StefanStrobel
No Id found for 98_ModbusSDM630M.pm
# $Id: 99_myUtils.pm  2016-09-25  V1.0  Christian Schmidt $
91_notify.pm        15937 2018-01-20 13:43:28Z rudolfkoenig
No Id found for 99_perfmon.pm
98_PID20.pm         10722 2016-02-04 17:12:18Z john99sr
33_readingsGroup.pm 16299 2018-03-01 08:06:55Z justme1968
33_readingsProxy.pm 16299 2018-03-01 08:06:55Z justme1968
00_RPII2C.pm        15021 2017-09-06 19:48:55Z klausw
51_RPI_GPIO.pm      15821 2018-01-07 21:36:43Z klausw
No Id found for 99_sethmkey.pm
98_statistics.pm    16357 2018-03-09 09:01:35Z tupol
99_SUNRISE_EL.pm    16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm           16402 2018-03-13 21:14:22Z rudolfkoenig
42_SYSMON.pm        15910 2018-01-16 23:07:56Z hexenmeister
98_telnet.pm        16293 2018-02-28 21:33:57Z rudolfkoenig
98_update.pm        15862 2018-01-12 21:01:28Z rudolfkoenig
99_Utils.pm         15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm       15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm       16293 2018-02-28 21:33:57Z rudolfkoenig

Blocking.pm         15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm            11159 2016-03-30 16:08:06Z justme1968
DevIo.pm            16329 2018-03-04 20:18:08Z rudolfkoenig
HttpUtils.pm        16407 2018-03-14 19:43:35Z rudolfkoenig
RTypes.pm           10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm    16211 2018-02-18 11:59:09Z rudolfkoenig
TcpServerUtils.pm   15707 2017-12-27 14:41:21Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
svg.js                     15896 2018-01-14 21:35:42Z rudolfkoenig


kernel.log
Mar 11 06:25:18 ccs-ht-rasp02 kernel: [34962.036162] w1_master_driver w1_bus_master1: Family 0 for 00.054000000000.a4 is not registered.
Mar 11 06:26:09 ccs-ht-rasp02 kernel: [35012.718046] w1_master_driver w1_bus_master1: Family 0 for 00.854000000000.28 is not registered.
Mar 11 06:27:02 ccs-ht-rasp02 kernel: [35066.119750] w1_master_driver w1_bus_master1: Family 0 for 00.454000000000.e2 is not registered.
Mar 11 06:28:06 ccs-ht-rasp02 kernel: [35129.641474] w1_master_driver w1_bus_master1: Family 0 for 00.c54000000000.6e is not registered.
Mar 11 06:29:22 ccs-ht-rasp02 kernel: [35205.860160] w1_master_driver w1_bus_master1: Family 0 for 00.254000000000.87 is not registered.
Mar 11 06:30:13 ccs-ht-rasp02 kernel: [35256.524850] w1_master_driver w1_bus_master1: Family 0 for 00.a54000000000.0b is not registered.
Mar 11 06:30:51 ccs-ht-rasp02 kernel: [35294.525520] w1_master_driver w1_bus_master1: Family 0 for 00.654000000000.c1 is not registered.
Mar 11 06:31:44 ccs-ht-rasp02 kernel: [35347.766718] w1_master_driver w1_bus_master1: Family 0 for 00.e54000000000.4d is not registered.
Mar 11 06:32:34 ccs-ht-rasp02 kernel: [35398.247753] w1_master_driver w1_bus_master1: Family 0 for 00.154000000000.39 is not registered.
Mar 11 06:33:26 ccs-ht-rasp02 kernel: [35450.318498] w1_master_driver w1_bus_master1: Family 0 for 00.954000000000.b5 is not registered.
Mar 11 06:34:42 ccs-ht-rasp02 kernel: [35525.449874] w1_master_driver w1_bus_master1: Family 0 for 00.554000000000.7f is not registered.
Mar 11 06:35:21 ccs-ht-rasp02 kernel: [35564.650381] w1_master_driver w1_bus_master1: Family 0 for 00.d54000000000.f3 is not registered.
Mar 11 06:35:47 ccs-ht-rasp02 kernel: [35590.690790] w1_master_driver w1_bus_master1: Family 0 for 00.354000000000.1a is not registered.
Mar 11 06:36:49 ccs-ht-rasp02 kernel: [35653.011834] w1_master_driver w1_bus_master1: Family 0 for 00.b54000000000.96 is not registered.
Mar 11 06:37:28 ccs-ht-rasp02 kernel: [35692.212232] w1_master_driver w1_bus_master1: Family 0 for 00.754000000000.5c is not registered.
Mar 11 06:38:08 ccs-ht-rasp02 kernel: [35731.412737] w1_master_driver w1_bus_master1: Family 0 for 00.f54000000000.d0 is not registered.
Mar 11 06:39:23 ccs-ht-rasp02 kernel: [35806.973708] w1_master_driver w1_bus_master1: Family 0 for 00.0d4000000000.66 is not registered.
Mar 11 06:40:14 ccs-ht-rasp02 kernel: [35857.734304] w1_master_driver w1_bus_master1: Family 0 for 00.8d4000000000.ea is not registered.
Mar 11 06:40:41 ccs-ht-rasp02 kernel: [35885.214630] w1_master_driver w1_bus_master1: Family 0 for 00.4d4000000000.20 is not registered.
Mar 11 06:41:45 ccs-ht-rasp02 kernel: [35948.814989] w1_master_driver w1_bus_master1: Family 0 for 00.cd4000000000.ac is not registered.
Mar 11 06:43:01 ccs-ht-rasp02 kernel: [36025.095583] w1_master_driver w1_bus_master1: Family 0 for 00.2d4000000000.45 is not registered.
Mar 11 06:43:52 ccs-ht-rasp02 kernel: [36075.856284] w1_master_driver w1_bus_master1: Family 0 for 00.ad4000000000.c9 is not registered.
Mar 11 06:44:55 ccs-ht-rasp02 kernel: [36139.296857] w1_master_driver w1_bus_master1: Family 0 for 00.6d4000000000.03 is not registered.
Mar 11 06:45:49 ccs-ht-rasp02 kernel: [36192.617228] w1_master_driver w1_bus_master1: Family 0 for 00.ed4000000000.8f is not registered.
Mar 11 06:46:39 ccs-ht-rasp02 kernel: [36243.257283] w1_master_driver w1_bus_master1: Family 0 for 00.1d4000000000.fb is not registered.
Mar 11 06:47:42 ccs-ht-rasp02 kernel: [36305.507877] w1_master_driver w1_bus_master1: Family 0 for 00.9d4000000000.77 is not registered.
Mar 11 06:48:21 ccs-ht-rasp02 kernel: [36344.618112] w1_master_driver w1_bus_master1: Family 0 for 00.5d4000000000.bd is not registered.
Mar 11 06:49:00 ccs-ht-rasp02 kernel: [36383.738387] w1_master_driver w1_bus_master1: Family 0 for 00.dd4000000000.31 is not registered.
Mar 11 06:49:26 ccs-ht-rasp02 kernel: [36410.018609] w1_master_driver w1_bus_master1: Family 0 for 00.3d4000000000.d8 is not registered.
Mar 11 06:50:28 ccs-ht-rasp02 kernel: [36472.258910] w1_master_driver w1_bus_master1: Family 0 for 00.bd4000000000.54 is not registered.
Mar 11 06:51:33 ccs-ht-rasp02 kernel: [36537.077136] w1_master_driver w1_bus_master1: Family 0 for 00.7d4000000000.9e is not registered.
Mar 11 06:52:12 ccs-ht-rasp02 kernel: [36576.179841] w1_master_driver w1_bus_master1: Family 0 for 00.fd4000000000.12 is not registered.
Mar 11 06:53:28 ccs-ht-rasp02 kernel: [36651.539923] w1_master_driver w1_bus_master1: Family 0 for 00.034000000000.79 is not registered.
Mar 11 06:54:20 ccs-ht-rasp02 kernel: [36703.580312] w1_master_driver w1_bus_master1: Family 0 for 00.834000000000.f5 is not registered.
Mar 11 06:55:24 ccs-ht-rasp02 kernel: [36768.300726] w1_master_driver w1_bus_master1: Family 0 for 00.434000000000.3f is not registered.
Mar 11 06:56:14 ccs-ht-rasp02 kernel: [36817.781166] w1_master_driver w1_bus_master1: Family 0 for 00.c34000000000.b3 is not registered.
Mar 11 06:56:40 ccs-ht-rasp02 kernel: [36843.981333] w1_master_driver w1_bus_master1: Family 0 for 00.234000000000.5a is not registered.
Mar 11 06:57:32 ccs-ht-rasp02 kernel: [36896.021559] w1_master_driver w1_bus_master1: Family 0 for 00.a34000000000.d6 is not registered.
Mar 11 06:58:11 ccs-ht-rasp02 kernel: [36935.062130] w1_master_driver w1_bus_master1: Family 0 for 00.634000000000.1c is not registered.
Mar 11 06:59:01 ccs-ht-rasp02 kernel: [36984.542383] w1_master_driver w1_bus_master1: Family 0 for 00.e34000000000.90 is not registered.
Mar 11 06:59:53 ccs-ht-rasp02 kernel: [37037.102803] w1_master_driver w1_bus_master1: Family 0 for 00.134000000000.e4 is not registered.


pi@ccs-ht-rasp02:~ $ perl -v

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

Copyright 1987-2017, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.


pi@ccs-ht-rasp02:~ $ free -m

              total        used        free      shared  buff/cache   available
Mem:            927         610          56           0         260         264
Swap:             0           0           0
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 16 März 2018, 17:27:51
version
In die FHEMWEB Kommandozeile eingeben.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 16 März 2018, 17:28:58
Hier mein Problemsystem:

Latest Revision: 16240

File                 Rev   Last Change

fhem.pl              16228 2018-02-20 09:23:11Z rudolfkoenig
96_allowed.pm        16200 2018-02-17 12:34:42Z rudolfkoenig
90_at.pm             15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm     15620 2017-12-16 18:10:36Z rudolfkoenig
10_CUL_HM.pm         16212 2018-02-18 13:05:21Z martinp876
93_DbLog.pm          16224 2018-02-19 18:58:18Z DS_Starter
93_DbRep.pm          16232 2018-02-20 16:21:12Z DS_Starter
98_dewpoint.pm       15927 2018-01-19 15:46:47Z hotbso
98_DOIF.pm           16182 2018-02-14 21:36:04Z Damian
98_dummy.pm          12700 2016-12-02 16:49:42Z rudolfkoenig
70_ENIGMA2.pm        14985 2017-09-01 11:18:48Z loredo
91_eventTypes.pm     14888 2017-08-13 12:07:12Z rudolfkoenig
00_FBAHA.pm          15437 2017-11-16 08:48:48Z rudolfkoenig
10_FBDECT.pm         15670 2017-12-22 22:03:42Z rudolfkoenig
72_FB_CALLLIST.pm    16055 2018-01-31 12:46:39Z markusbloch
72_FB_CALLMONITOR.pm 16000 2018-01-26 11:48:32Z markusbloch
01_FHEMWEB.pm        16153 2018-02-11 17:02:29Z rudolfkoenig
92_FileLog.pm        15874 2018-01-13 17:16:33Z rudolfkoenig
72_FRITZBOX.pm       16187 2018-02-15 18:14:12Z tupol
# $Id: 99_getstate.pm,v 1.3 2009-12-16 16:46:00 m_fischer Exp $
37_harmony.pm        15971 2018-01-23 13:41:25Z justme1968
98_HMinfo.pm         16225 2018-02-19 19:23:47Z martinp876
00_HMLAN.pm          14073 2017-04-22 13:45:25Z martinp876
00_HMUARTLGW.pm      16166 2018-02-13 19:52:08Z mgernoth
98_HTTPMOD.pm        16216 2018-02-18 15:26:11Z StefanStrobel
02_HTTPSRV.pm        13976 2017-04-12 13:35:44Z neubert
49_IPCAM.pm           2626 2013-02-01 19:19:15Z mfr69bs
98_JsonList2.pm      13757 2017-03-20 19:17:02Z rudolfkoenig
75_msgConfig.pm      15167 2017-10-01 18:46:23Z loredo
91_notify.pm         15937 2018-01-20 13:43:28Z rudolfkoenig
No Id found for 99_perfmon.pm
70_Pushbullet.pm      9730 2015-10-30 15:06:41Z fhainz
70_Pushover.pm       15162 2017-10-01 11:25:11Z loredo
33_readingsGroup.pm  16030 2018-01-28 19:16:05Z justme1968
44_S7.pm             14697 2017-07-13 04:36:34Z charlie71
44_S7_ARead.pm       15539 2017-12-01 21:52:13Z charlie71
44_S7_Client.pm      14257 2017-05-12 16:39:44Z charlie71
44_S7_DRead.pm       15539 2017-12-01 21:52:13Z charlie71
44_S7_DWrite.pm      15539 2017-12-01 21:52:13Z charlie71
44_S7_S5Client.pm    15518 2017-11-28 21:17:47Z charlie71
44_S7_S7Client.pm    15511 2017-11-27 21:13:16Z charlie71
96_SIP.pm            15827 2018-01-08 18:36:07Z Wzut
98_statistics.pm     15455 2017-11-19 12:30:39Z tupol
99_SUNRISE_EL.pm     15572 2017-12-08 22:18:13Z rudolfkoenig
98_SVG.pm            16236 2018-02-20 21:54:24Z rudolfkoenig
42_SYSMON.pm         15910 2018-01-16 23:07:56Z hexenmeister
98_telnet.pm         15676 2017-12-23 19:33:43Z rudolfkoenig
98_Text2Speech.pm    13704 2017-03-14 19:33:42Z Tobias.Faust
98_THRESHOLD.pm      14179 2017-05-03 20:10:16Z Damian
99_Utils.pm          15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm        15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm        14888 2017-08-13 12:07:12Z rudolfkoenig

Blocking.pm          15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm             11159 2016-03-30 16:08:06Z justme1968
DevIo.pm             15939 2018-01-20 17:17:19Z rudolfkoenig
FritzBoxUtils.pm     14541 2017-06-19 09:13:10Z rudolfkoenig
HMConfig.pm          16070 2018-02-03 15:50:55Z martinp876
HttpUtils.pm         15631 2017-12-17 12:33:03Z rudolfkoenig
Info.pm                 28 2008-11-09 01:08:44Z dsully
msgSchema.pm         15175 2017-10-02 14:29:50Z loredo
RTypes.pm            10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm     16211 2018-02-18 11:59:09Z rudolfkoenig
TcpServerUtils.pm    15707 2017-12-27 14:41:21Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16237 2018-02-20 22:17:13Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 16 März 2018, 17:37:30
Version Stetch (Produktivsystem siehe Signatur) mit Problem (ist per restore von 16404 ohne Lösung des Problems zurück auf 16390 gesetzt):

Latest Revision: 16390

File                 Rev   Last Change

fhem.pl              16354 2018-03-09 07:31:31Z rudolfkoenig
# $Id: 60_airquality.pm 00000 2017-04-08 $$$
39_alexa.pm          16299 2018-03-01 08:06:55Z justme1968
90_at.pm             15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm     15620 2017-12-16 18:10:36Z rudolfkoenig
98_BOSEST.pm         15641 2017-12-18 21:49:03Z dominik
98_cmdalias.pm       16300 2018-03-01 08:48:21Z rudolfkoenig
00_CUL.pm            15027 2017-09-08 09:11:43Z rudolfkoenig
10_CUL_HM.pm         16258 2018-02-24 22:11:14Z martinp876
14_CUL_WS.pm         15603 2017-12-13 20:53:47Z rudolfkoenig
95_Dashboard.pm      12251 2016-10-03 09:45:43Z talkabout
98_DLNARenderer.pm   15836 2018-01-09 21:01:49Z dominik
98_DOIF.pm           16388 2018-03-11 20:32:41Z Damian
98_dummy.pm          12700 2016-12-02 16:49:42Z rudolfkoenig
70_ENIGMA2.pm        14985 2017-09-01 11:18:48Z loredo
91_eventTypes.pm     14888 2017-08-13 12:07:12Z rudolfkoenig
00_FBAHAHTTP.pm      16344 2018-03-06 21:06:34Z rudolfkoenig
10_FBDECT.pm         16293 2018-02-28 21:33:57Z rudolfkoenig
72_FB_CALLLIST.pm    16346 2018-03-07 16:01:02Z markusbloch
72_FB_CALLMONITOR.pm 16342 2018-03-06 16:47:19Z markusbloch
01_FHEMWEB.pm        16350 2018-03-07 21:30:37Z rudolfkoenig
92_FileLog.pm        15874 2018-01-13 17:16:33Z rudolfkoenig
95_FLOORPLAN.pm      13735 2017-03-19 12:43:53Z UliM
98_freezemon.pm      16384 2018-03-11 16:16:12Z KernSani
72_FRITZBOX.pm       16285 2018-02-27 17:58:54Z tupol
10_FS20.pm           14888 2017-08-13 12:07:12Z rudolfkoenig
00_HMUARTLGW.pm      16166 2018-02-13 19:52:08Z mgernoth
95_holiday.pm        16293 2018-02-28 21:33:57Z rudolfkoenig
98_HTTPMOD.pm        16216 2018-02-18 15:26:11Z StefanStrobel
02_HTTPSRV.pm        13976 2017-04-12 13:35:44Z neubert
30_HUEBridge.pm      16310 2018-03-02 10:43:36Z justme1968
31_HUEDevice.pm      16352 2018-03-08 07:42:40Z justme1968
49_IPCAM.pm           2626 2013-02-01 19:19:15Z mfr69bs
10_IT.pm             14852 2017-08-06 08:48:24Z bjoernh
13_KS300.pm          15627 2017-12-17 11:00:46Z rudolfkoenig
No Id found for 99_myUtils.pm
99_myUtilsTelefon.pm  1932 2012-10-06 20:15:33Z ulimaass
91_notify.pm         15937 2018-01-20 13:43:28Z rudolfkoenig
73_PRESENCE.pm       16177 2018-02-14 08:58:43Z markusbloch
70_Pushbullet.pm      9730 2015-10-30 15:06:41Z fhainz
70_PushNotifier.pm   11040 2016-03-10 14:42:46Z xusader
33_readingsGroup.pm  16299 2018-03-01 08:06:55Z justme1968
33_readingsProxy.pm  16299 2018-03-01 08:06:55Z justme1968
17_SIRD.pm           41052 2017-03-28 16:41:14Z joergbackus
98_structure.pm      16293 2018-02-28 21:33:57Z rudolfkoenig
99_SUNRISE_EL.pm     16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm            16293 2018-02-28 21:33:57Z rudolfkoenig
42_SYSMON.pm         15910 2018-01-16 23:07:56Z hexenmeister
32_TechemWZ.pm       10662 2016-01-30 10:22:50Z herrmannj
50_TelegramBot.pm    16382 2018-03-11 13:20:55Z viegener
98_telnet.pm         16293 2018-02-28 21:33:57Z rudolfkoenig
98_THRESHOLD.pm      14179 2017-05-03 20:10:16Z Damian
59_Twilight.pm       16005 2018-01-27 06:05:51Z igami
99_Utils.pm          15713 2017-12-28 11:01:02Z rudolfkoenig
77_UWZ.pm            15650 2017-12-20 05:41:22Z CoolTux
98_version.pm        15140 2017-09-26 09:20:09Z markusbloch
91_watchdog.pm       14888 2017-08-13 12:07:12Z rudolfkoenig
59_Weather.pm        12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm        16293 2018-02-28 21:33:57Z rudolfkoenig
36_WMBUS.pm          16320 2018-03-03 20:25:22Z kaihs
10_ZWave.pm          16266 2018-02-25 18:22:51Z rudolfkoenig
00_ZWDongle.pm       16293 2018-02-28 21:33:57Z rudolfkoenig

Blocking.pm          15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm             11159 2016-03-30 16:08:06Z justme1968
Common.pm            10759 2016-02-07 20:00:12Z rleins
ControlPoint.pm      15823 2018-01-07 22:42:45Z Reinerlein
DevIo.pm             16329 2018-03-04 20:18:08Z rudolfkoenig
FritzBoxUtils.pm     16344 2018-03-06 21:06:34Z rudolfkoenig
HMConfig.pm          16265 2018-02-25 18:22:43Z martinp876
HttpUtils.pm         16343 2018-03-06 20:44:37Z rudolfkoenig
RTypes.pm            10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm     16211 2018-02-18 11:59:09Z rudolfkoenig
TcpServerUtils.pm    15707 2017-12-27 14:41:21Z rudolfkoenig
WMBus.pm             15376 2017-11-01 15:51:17Z kaihs
YahooWeatherAPI.pm   15742 2018-01-01 07:55:55Z neubert
ZWLib.pm             15466 2017-11-20 22:22:19Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
svg.js                     15896 2018-01-14 21:35:42Z rudolfkoenig


Version Stetch (zweites System siehe Signatur) ohne Probleme:
Latest Revision: 16404

File                Rev   Last Change

fhem.pl             16403 2018-03-13 21:16:06Z rudolfkoenig
96_allowed.pm       16295 2018-02-28 22:11:09Z rudolfkoenig
90_at.pm            15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm    15620 2017-12-16 18:10:36Z rudolfkoenig
98_backup.pm        15862 2018-01-12 21:01:28Z rudolfkoenig
00_CUL.pm           15027 2017-09-08 09:11:43Z rudolfkoenig
14_CUL_TX.pm        14784 2017-07-25 15:06:43Z rudolfkoenig
14_CUL_WS.pm        15603 2017-12-13 20:53:47Z rudolfkoenig
98_DOIF.pm          16388 2018-03-11 20:32:41Z Damian
98_dummy.pm         12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm    14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm       16350 2018-03-07 21:30:37Z rudolfkoenig
92_FileLog.pm       15874 2018-01-13 17:16:33Z rudolfkoenig
98_freezemon.pm     16384 2018-03-11 16:16:12Z KernSani
72_FRITZBOX.pm      16285 2018-02-27 17:58:54Z tupol
10_FS20.pm          14888 2017-08-13 12:07:12Z rudolfkoenig
10_IT.pm            14852 2017-08-06 08:48:24Z bjoernh
13_KS300.pm         15627 2017-12-17 11:00:46Z rudolfkoenig
73_MPD.pm           15830 2018-01-08 18:45:38Z Wzut
91_notify.pm        15937 2018-01-20 13:43:28Z rudolfkoenig
73_PRESENCE.pm      16177 2018-02-14 08:58:43Z markusbloch
33_readingsGroup.pm 16299 2018-03-01 08:06:55Z justme1968
51_RPI_GPIO.pm      15821 2018-01-07 21:36:43Z klausw
98_structure.pm     16293 2018-02-28 21:33:57Z rudolfkoenig
99_SUNRISE_EL.pm    16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm           16402 2018-03-13 21:14:22Z rudolfkoenig
42_SYSMON.pm        15910 2018-01-16 23:07:56Z hexenmeister
32_TechemWZ.pm      10662 2016-01-30 10:22:50Z herrmannj
50_TelegramBot.pm   16382 2018-03-11 13:20:55Z viegener
98_telnet.pm        16293 2018-02-28 21:33:57Z rudolfkoenig
99_Utils.pm         15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm       15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm       16293 2018-02-28 21:33:57Z rudolfkoenig
36_WMBUS.pm         16320 2018-03-03 20:25:22Z kaihs

Blocking.pm         15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm            11159 2016-03-30 16:08:06Z justme1968
DevIo.pm            16329 2018-03-04 20:18:08Z rudolfkoenig
FritzBoxUtils.pm    16344 2018-03-06 21:06:34Z rudolfkoenig
HttpUtils.pm        16343 2018-03-06 20:44:37Z rudolfkoenig
myUtilsTemplate.pm   7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm           10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm    16211 2018-02-18 11:59:09Z rudolfkoenig
TcpServerUtils.pm   15707 2017-12-27 14:41:21Z rudolfkoenig
WMBus.pm            15376 2017-11-01 15:51:17Z kaihs

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 16 März 2018, 23:09:50
Hallo miteinander,

ich bin gerade auf diesen Thread gestoßen.
Für die User die DbLog und DbRep verwenden, möchte ich ein paar Hinweise und Tipps zur Arbeitsweise dieser Module geben.
Ich selbst verwende beide naturgemäß wegen der Entwicklungs- und Testtätigkeit massiv, ohne ein derartiges Verhalten bei mir auf (virtualisierten Systemen) Debian Jessie zu beobachten.

Umgebung:
Test: 6 x DbLog im asynch Mode (MySQL,PostgreSQL,SQLite), 41 x DbRep, 1 GB RAM, 250 - 380 MB Used
Prod: 2 x DbLog in asynch Mode (MySQL), 101 x DbRep, 1.2 GB RAM, 300 - 500 MB Used

DbLog:

* nur im Modus "asynchron = 1" verwendet dieses Modul einen BlockingCall.
   Wenn man den Verdacht hat deswegen Speicherprobleme zu haben, reicht es aus das Attribut "asynchron = 0" zu setzen (oder löschen).
   
* Bei asynchroner Nutzung und entsprechend vieler zu loggender Events in Zusammenhang mit einer sehr lang eingestellter Sync-Zeit (attr syncInterval) kann
   ein zeitweise!! erhöhter Speicherbedarf auftreten weil entsprechend viele Daten im Speicher gehalten werden. Abhilfe würde hier ein verringerter Wert für
   syncInterval schaffen.
   
Der asynchrone Modus kann in gewisser Weise dafür anfällig sein Speicher zu allokieren, wenn die Daten nicht an die Datenbank abgegeben werden können.
Das kann z.B. an einem länger!!! bestehenden Problem der DB liegen oder daran, dass in irgendeiner Weise die Abarbeitung der BlockingCall-Queue zum Erliegen kommt. DbLog muss dabei nicht der Auslöser der Situation sein, aber da in dem Fall die Log-Daten im RAM auflaufen, kann sich das Problem dadurch zeigen bzw. verstärken.
Ob ein solches Problem vorliegt, ist einfach an dem Reading "cacheUsage" zu erkennen. Der cacheUsage-Wert muß sich immer über einen Zyklus auf- und wieder abbauen und darf nicht stetig ansteigen.
Man kann cacheUsage auch z.B. in einem Filelog loggen (cacheEvents=2 setzen) und sich damit einen Überblick verschaffen.

DbRep:

* das Modul arbeitet mit BlockingCall, führt aber nur dann Aktivitäten aus wenn set/get-Befehle abgesetzt werden. Ansonsten passiert nichts.

* (temporärer) Speicherbedarf entsteht insbesondere bei umfangreichen Selektionen und/oder der Erstellung sehr vieler Readings (z.B. fetchrows über einen
   entsprechend großen Zeitraum und Attr "limit" angehoben). Wenn man die Daten nicht mehr benötigt, kann man sie mit "set ... eraseReadings" entsorgen.

* Etwas Fingerspitzengefühl wird benötigt, wenn man für MySQL die Funktion "dumpMySQL clientSide" benutzt. Diese Funktion selektiert entsprechend viele Datensätze
   aus der DB in den RAM um sie dann wegzuschreiben. Hier gibt es die Attribute dumpMemlimit, dumpSpeed um den Speicherkonsum dieser Funktion zu beschränken bzw.
   zu optimieren. D.h. bei dieser dump-Funktion kann es einen Peak bei der Speicherverwendung geben der sich aber nach Abschluß der Funktion wieder normalisiert.

Ich hoffe diese Erläuterungen helfen etwas um die Arbeit beider Module einzuordnen und in dem Zusammenhang bewerten zu können.

LG,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 17 März 2018, 08:57:21
Zwischenergebnis der version Sammlung:
In allen 6 Problemfaellen kommen folgende Perl Dateien vor:
01_FHEMWEB.pm
33_readingsGroup.pm
90_at.pm
91_eventTypes.pm
91_notify.pm
92_FileLog.pm
98_DOIF.pm
98_SVG.pm
98_autocreate.pm
98_dummy.pm
98_telnet.pm
98_version.pm
98_weblink.pm
99_SUNRISE_EL.pm
99_Utils.pm
Blocking.pm
Color.pm
DevIo.pm
HttpUtils.pm
RTypes.pm
SetExtensions.pm
TcpServerUtils.pm
fhem.pl

Leider kommen diese alle auch in der "ohne Probleme" Liste vor, d.h. das Problem ist nicht auf die einfache Verwendung eines Moduls zurueckzufuehren.

@Heiko: ich glaube nicht, dass das Problem an DBLog liegt, siehe auch die o.g. Liste, und meine Kommentare vorhin.
Aber wenn du schon dabei bist: wuerdest du deine Systeme auf Stretch updaten ? :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 17 März 2018, 09:16:58
Morgen Rudi,

Zitatich glaube nicht, dass das Problem an DBLog liegt, siehe auch die o.g. Liste, und meine Kommentare vorhin.
Ja, ich habe gelesen dass das Problem auch bei Nicht-DbLog-Usern auftritt.
Meine Hinweise solten nur DbLog-Usern ein paar Anhaltspunkte zur Arbeitsweise liefern, ein bisschen Know-How Aufbau  ;)

ZitatAber wenn du schon dabei bist: wuerdest du deine Systeme auf Stretch updaten ? :)
Ich würde ein weiteres virtualisiertes System auf Stretch aufbauen, habe ja ESX zur Verfügung.
Wird aber etwas dauern, Zeit ist momentan ein etwas knappes Gut ...

LG,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 17 März 2018, 10:37:07
Zur Info:

ein gestern unter Jessie Lite aufgesetztes und um 17:53 gestartetes FHEM hat ab 01:03:54 ebenfalls die Meldungen geworfen.

2018.03.17 01:03:54 1: Cannot fork: Cannot allocate memory

2018-03-17_01:02:30 sysmon ram: Total: 923.35 MB, Used: 523.34 MB, 56.68 %, Free: 400.01 MB
2018-03-17_01:03:30 sysmon ram: Total: 923.35 MB, Used: 516.72 MB, 55.96 %, Free: 406.63 MB
2018-03-17_01:04:30 sysmon ram: Total: 923.35 MB, Used: 517.41 MB, 56.04 %, Free: 405.94 MB
2018-03-17_01:05:28 sysmon ram: n/a
2018-03-17_01:06:30 sysmon ram: Total: 923.35 MB, Used: 521.20 MB, 56.45 %, Free: 402.15 MB
2018-03-17_01:07:28 sysmon ram: n/a
2018-03-17_01:08:37 sysmon ram: Total: 923.35 MB, Used: 526.31 MB, 57.00 %, Free: 397.04 MB
2018-03-17_01:09:30 sysmon ram: Total: 923.35 MB, Used: 522.95 MB, 56.64 %, Free: 400.41 MB
2018-03-17_01:10:29 sysmon ram: n/a
2018-03-17_01:11:30 sysmon ram: Total: 923.35 MB, Used: 521.67 MB, 56.50 %, Free: 401.68 MB
2018-03-17_01:12:29 sysmon ram: n/a
2018-03-17_01:13:28 sysmon ram: n/a
2018-03-17_01:14:29 sysmon ram: n/a
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 17 März 2018, 10:37:31
Hallo,

bei mir läuft nun mein Fhem auf dem Raspi (Stretch, neu aufgesetzt) seit 14.03.2018 22:03:28 ohne Neustart und auch ohne Fehler, jedoch mit sehr wenig freien RAM-Speicher.

Ob diese Beobachtung zur Problemlösung beiträgt, kann ich wegen fehlenden Kenntnissen nicht beurteilen, ich möchte Sie dennoch weitergeben. Wenn das nervt, gebt mir bitte Bescheid und ich werde es lassen.

Ich habe gestern sysmon installiert und schreibe den RAM Speicher mit, heute morgen ist mir folgendes aufgefallen:

Genau um 02:03 Uhr starte ich per at das verdichten der DBlog Datenbank mit "set DBLogging reduceLogNbl 30 average".
Und um  03:06 führe ich ein Backup der Maria SQLDB mit "set DBReport dumpMySQL clientSide" aus, welches um 03:16 Uhr beendet ist.
Irgendwas muss hier zur gleichen Zeit Speicher freigeben.

Meine Attribute zu DBLogging:
defmod DBLogging DbLog /opt/fhem/contrib/dblog/db.conf .*:.*
attr DBLogging DbLogExclude .*
attr DBLogging DbLogSelectionMode Exclude/Include
attr DBLogging DbLogType Current/History
attr DBLogging asyncMode 1
attr DBLogging room Logging
attr DBLogging shutdownWait 4
attr DBLogging verbose 2


Meine Attribute zu DBReport:
defmod DBReport DbRep DBLogging
attr DBReport DbLogExclude .*
attr DBReport dumpDirLocal /opt/fhem/backup
attr DBReport dumpFilesKeep 8
attr DBReport optimizeTablesBeforeDump 1
attr DBReport room Logging
attr DBReport verbose 2


Der freie Ram Speicher nimmt dann langsam wieder ab, derzeit sind (so wie immer eigentlich) wieder nur ca. 50 Mb frei.

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 17 März 2018, 11:58:54
Hallo Reinhard,

ZitatIrgendwas muss hier zur gleichen Zeit Speicher freigeben.

vorausgesetzt du betreibst die MySQL-DB mit auf dem Raspi, hängt die Speicherfreigabe kurz nach dem "set DBLogging reduceLogNbl 30 average" sehr wahrscheinlich mit Datenbank internen Vorgängen zusammen. Das reduceLogNbl  löscht ja mehr oder weniger viel Daten in der DB.
MySQL hat eine eigene Speicher- und Cacheverwaltung und kennt jede Menge Servervariablen mit denen das Verhalten und die Performance des DBMS bestimmt wird.

Wenn es dich interressiert und du dich etwas damit beschäftigen willst gibt es hier: https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html einen Einstieg.
Die Standardkonfiguration befindet sich in einer Konfigdatei. Auf Synology/MariaDB10 ist es "/usr/local/mariadb10/etc/mysql/my.cnf".

Hier mal ein Beispiel (Auszug) meiner MariaDB10 auf Synology, also extern:

[mysqld]
skip-external-locking
key_buffer_size = 384M
max_allowed_packet = 1M
table_open_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8


Wenn du wie von mir vermutet die MySQL mit auf dem Raspi betreibst, lohnt es sich wahrscheinlich einen Blick darauf zu werfen ob die DB evtl. mit zu viel Speicherzuweisung (per default) arbeitet und es abändern um mehr RAM-Speicher frei zu haben. 
Allerdings hast du ja keine Probleme und wäre deswegen eher eine Grundlagenforschung für den Fall das du mal etwas ändern musst.
Solltest du mehr in diese Thematik einsteigen wollen, würde ich dir aber empfehlen einen separaten Thread zu eröffnen.

LG,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 17 März 2018, 20:17:32
Man merkt, das "freier Speicher" mal wieder falsch verstanden wird.

Wie schon mal erläutert, cacht Unix im Speicher und das wird im "freien Speicher" mit abgerechnet (anders als z.B. bei Windows). Wenn jetzt also kurzfristig jemand VIEL Speicher braucht, es aber auch schnell wieder komlett freigiebt, kannfolgendes Pasieren:
- Der Cache ist gefüllt: wenig "freier Speicher"
- Viel Ram verbrauch durch Programm: Cache wird reduziert: "freie Speicher" bleibt ziemlich gleich
- Ram wird wieder freigegeben, Cache wird aber nicht SOFORT wieder gefüllt (Passiert nur beim lesen, schreiben) -> viel freier Speicher
- Durch laufende Prozesse (s.o.) wird Cache wieder gefüllt.

Deshalb muß man beim UNIX nicht nur den "freien Speicher", sondern auch die "gecachten Blöcke" beachten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 17 März 2018, 22:18:58
Hallo Rudi,

habe mir nun eine weitere VM mit Stretch erstellt.
Ich bin absichtlich von einem bestehenden Jessie System ausgegangen und habe den Upgrade durchgezogen.

Bis jetzt läuft alles gewohnt unauffällig. Werde das nun eine Weile beobachten und berichten...

LG,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 18 März 2018, 19:11:39
Jetzt ist die erstellte Testinstanz mit Stretch rund 1 Tag gelaufen und läuft absolut fehlerfrei ohne irgendwelche festzustellenden Unterschiede zum Testsystem unter Jessie.
Das Stretch-System ist eine VM-Kopie des Jessie-Systems und enthält somit genau die gleichen Module/Konfiguration wie dieses.
Der RAM-Verbrauch ist durchschnittlich 310 MB, mit Peak auf rund 680MB während eines MySQL-Backups. Anbei auch noch ein Plot.
Hier sieht man auch gut den von Wernieman beschriebenen Sachverhalt nach dem Backup denke ich.

Also rundrum sehr zufriedenstellend und ich werde meine ganzen Systeme auch mal auf Stretch heben wenn ich Zeit habe und nichts anderes zu tun ist.

Hier noch die verwendeten Module (alles aktuellster Update-Stand) mit der Anzahl der Devices, sieht leider etwas verschoben aus:


System Info
ConfigType: configFile
SVN rev: 16431
OS: linux
Perl: 5.20.2
uniqueId: 60d...

Modules Model Count
CALVIEW 1
CUL_HM
ActionDetector 1
Calendar 1
DBPlan 1
DOIF 3
Dashboard 1
DbLog
MYSQL 2
SQLITE 2
POSTGRESQL 2
DbRep 41
FHEMWEB 4
FULLY 1
FileLog 1
FileLogConvert 2
HTTPMOD 4
HTTPSRV 1
Log2Syslog 3
MQTT 1
NUT 1
Nmap 2
PHILIPS_AUDIO
NP3700 1
SHM 1
SHMForecastRelative 1
SMAEM 1
SMAInverter 1
SSCam
CAM 4
SVS 1
SVG 51
SYSMON 1
TPLinkHS110
HS100(EU) 1
TelegramBot 1
Verkehrsinfo 1
Weather 1
YAAHM 1
allowed 1
at 22
autocreate 1
cmdalias 7
dummy 17
eventTypes 1
freezemon 1
holiday 1
logProxy 1
msgConfig 1
notify 25
readingsGroup 5
rssFeed 2
serviced 1
telnet 1
weblink 13
withings 3


LG,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 18 März 2018, 20:01:04
ZitatJetzt ist die erstellte Testinstanz mit Stretch rund 1 Tag gelaufen und läuft absolut fehlerfrei ohne irgendwelche festzustellenden Unterschiede zum Testsystem unter Jessie.
Naja, meine Theorie ist, dass Stretch auf einem RPi das Problem verursacht :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 18 März 2018, 20:14:51
Deine Theorie würde durch meine Beobachtung auch untermauert denke ich. Kann diesbzgl. nun leider nicht mehr unterstützen Rudi ... habe/nutze ausschließlich VM's.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 18 März 2018, 20:23:11
Nur .. auf Jessi zu bleiben ist keine Lösung für die Zukunft. Habe hier nur den Pi als reine "Daten-Sammel-gerät" ohne FHEM, welches auf einem größeren Rechner läuft. Kann deshalb auch schlecht etawas dazu sagen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 18 März 2018, 20:26:52
Ich habe hier auf 2 Pi einmal Debian 9.1 und Debian 9.3 jeweils als Raspbian Version.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 19 März 2018, 16:16:10
@DS_Starter
Bei deinem Ram Plot bleibt der Speicher grundsätzlich immer gleich groß was bei meinen beiden System bei denen ich diesen Fehler habe nicht der Fall ist.
Siehe Anhang.

Eine Änderung habe ich in der raspi-config vorgenommen um nocj ein wenig mehr Speicher zur Verfügung zu haben.
Unter Advanced Options   => Memory Split habe ich auf 32 geändert denn ich brauche keine GPU.
Leider kann man das Memory Split nicht noch mehr verkleinern oder abstellen weil sonst eine Fehlermeldung im kernel.log erscheint.
kernel [    2.945481] vc_vchi_sm_init failed to open VCHI service (-1)
kernel [    2.945482] [vc_sm_connected_init] failed to initialize shared memory service


Mal sehen ob sich dadurch etwas verbessert.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 20 März 2018, 13:25:46
Läst sich irgendwie ein automatischer Reboot einrichten bis dieser Fehler gefunden wurde.
Wenn ich alle 24 Stunden einen Autorboot durchführen könnte wäre ich zumindest so weit Sicher das sich das System nicht weghängt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 20 März 2018, 13:32:28
Ja das geht.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 20 März 2018, 14:00:28
Testweise hatte ich einen Reboot alle 8 Stunden eingerichtet:
Internals:
   COMMAND    { system("sudo reboot &") }
   DEF        +*08:00:00 { system("sudo reboot &") }
   NAME       Raspi_neu_Starten
   NR         1088
   NTM        19:48:17
   PERIODIC   yes
   RELATIVE   yes
   REP        -1
   STATE      disabled
   TIMESPEC   08:00:00
   TRIGGERTIME 1521571697.96166
   TRIGGERTIME_FMT 2018-03-20 19:48:17
   TYPE       at
   READINGS:
     2018-03-20 11:48:17   state           disabled
Attributes:
   disable    1
   room       System


Ein shutdown restart reicht wohl aus
Internals:
   COMMAND    shutdown restart
   DEF        +*12:00:00 shutdown restart
   NAME       shutdown_restart
   NR         1091
   NTM        15:48:17
   PERIODIC   yes
   RELATIVE   yes
   REP        -1
   STATE      Next: 15:48:17
   TIMESPEC   12:00:00
   TRIGGERTIME 1521557297.97026
   TRIGGERTIME_FMT 2018-03-20 15:48:17
   TYPE       at
   READINGS:
     2018-03-20 03:48:17   state           Next: 15:48:17
Attributes:
   room       System


Edit: wenn es an Stretch liegen sollte, wäre die Angabe der Version hilfreich?
Das problembehaftete System war auf 9.3
Das System ohne Problem ist auf 9.1

Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 20 März 2018, 15:36:39
Ich habe auf den beiden System einmal diese Version 2017-08-16-raspbian-stretch-lite.img und auf dem zweiten ist diese Version 2017-11-29-raspbian-stretch-lite.img installiert.
Alle anderen Raspberrys haben noch die normale Lite Version installiert 2017-04-10-raspbian-jessie-lite.img oder älter.

Danke erstmal für den Tipp mit dem automatischen Reboot.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 20 März 2018, 15:44:31
Version:
lsb_release -a
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 20 März 2018, 16:21:33
Danke für den Hinweis:
FHEM Server
pi@ccs-ht-rasp01:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 9.4 (stretch)
Release:        9.4
Codename:       stretch


FHEM Client

pi@ccs-ht-rasp02:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 9.1 (stretch)
Release:        9.1
Codename:       stretch
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 20 März 2018, 16:45:50
FHEM Server
enno@FHEM:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch


Ich habe gerade den RPi3+ bekommen. Werde ihn jetzt mit Rapbian Jesse vom 05.07.2017 aufbauen. Einen automatischen Neustart hatte ich auch schon mal versucht, da bleiben aber hin und wieder CUL oder 1-Wire auf der Strecke. Das ist für mich leider keine Lösung.

Gruss
  Enno
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 20 März 2018, 21:10:16
Hallo,
im Plott ist mir aufgefallen, das um 23:05 Uhr wenn ich per FFmpeg mit dem Raspi aus den Wettercambildern ein Zeitraffervideo erstelle zunächst der freie Speicher auf ca 40mb abfällt und nach beendigung des Vorgangs dann wieder 230 mb freier Speicher zur verfügung ist.... Zum testen habe ich das ganze auch mal um 17:27 manuel ausgelöst....

Weiß nicht ob das evtl weiterhilft......
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Fixel2012 am 20 März 2018, 21:22:21
Habe seit einigen Wochen ebenfalls das Problem.

No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 8.0 (jessie)
Release:        8.0
Codename:       jessie
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 21 März 2018, 08:29:19
Zitat von: jailbreaker07 am 20 März 2018, 21:10:16
Hallo,
im Plott ist mir aufgefallen, das um 23:05 Uhr wenn ich per FFmpeg mit dem Raspi aus den Wettercambildern ein Zeitraffervideo erstelle zunächst der freie Speicher auf ca 40mb abfällt und nach beendigung des Vorgangs dann wieder 230 mb freier Speicher zur verfügung ist.... Zum testen habe ich das ganze auch mal um 17:27 manuel ausgelöst....

Bezügloich Speicherverbrauch bei Unixsystemen habe ich hier schon etwas geschrieben:
https://forum.fhem.de/index.php/topic,84372.msg782708.html#msg782708 (https://forum.fhem.de/index.php/topic,84372.msg782708.html#msg782708)
Ist also normales Verhalten ... Freie Speicher Unix <> Freier Speicher Windows
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 21 März 2018, 11:52:24
Der Fehler ist hier in den letzten 30 Stunden nicht mehr aufgetreten. Nun ja  ::)

Folgender Workaround ist jetzt eingerichtet: userReadings für sysmon auf ram_used

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


und dann ein Notify, das bei Überschreitung eines definierten Wertes den shutdown restart auslöst.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 25 März 2018, 15:35:54
HAllo,

gibt es mittlerweile Neuigkeiten bezüglich einer Lösung ?

Gruß

Thorsten
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 25 März 2018, 17:11:28
Hallo,

ich wäre auch an einer Lösung Interessiert die die Ursache abstellt...
Momentan löst mein Watchdog das Problem mit einem Neustart...normal ist das aber nicht.

MFG
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: nils_ am 26 März 2018, 09:07:35
Zitat von: rico5588 am 25 März 2018, 17:11:28
Hallo,

ich wäre auch an einer Lösung Interessiert die die Ursache abstellt...
Momentan löst mein Watchdog das Problem mit einem Neustart...normal ist das aber nicht.

MFG

dann poste doch mal bitte mehr Informationen zu deinem System, verwendeten Modulen, usw usw.
(siehe weiter oben irgendwo....)


btw. deine "kurve" steigt schön an :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 26 März 2018, 16:28:41
Ok,

versuche mal ein paar Infos zu geben.
weitere Infos gern nach Anleitung....

Ich hatte vor einer Woche folgende Updates gemacht und gefühlt sind seit dem die Probleme vorhanden.
sudo apt get update && sudo apt get upgrade
sudo rpi-update

uname -a
Linux raspberrypi 4.14.27-v7+ #1100 SMP Fri Mar 16 13:51:48 GMT 2018 armv7l GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 8.0 (jessie)
Release:        8.0
Codename:       jessie


perl
perl -v

This is perl 5, version 20, subversion 2 (v5.20.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 100 registered patches, see perl -V for more detail)

Copyright 1987-2015, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

version
Latest Revision: 16469

File                     Rev   Last Change

fhem.pl                  16453 2018-03-20 21:15:44Z rudolfkoenig
96_allowed.pm            16295 2018-02-28 22:11:09Z rudolfkoenig
90_at.pm                 15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm         15620 2017-12-16 18:10:36Z rudolfkoenig
00_CUL.pm                15027 2017-09-08 09:11:43Z rudolfkoenig
10_CUL_HM.pm             16258 2018-02-24 22:11:14Z martinp876
No Id found for 14_CUL_REDIRECT.pm
14_CUL_TCM97001.pm       16274 2018-02-25 20:42:39Z bjoernh
14_CUL_TX.pm             14784 2017-07-25 15:06:43Z rudolfkoenig
14_CUL_WS.pm             15603 2017-12-13 20:53:47Z rudolfkoenig
95_Dashboard.pm          12251 2016-10-03 09:45:43Z talkabout
93_DbLog.pm              16423 2018-03-17 07:28:59Z DS_Starter
93_DbRep.pm              16465 2018-03-21 22:26:02Z DS_Starter
70_DENON_AVR.pm             10 2018-03-18 00:00:00Z raman
71_DENON_AVR_ZONE.pm        10 2017-03-21 00:00:00Z raman
98_DLNARenderer.pm       15836 2018-01-09 21:01:49Z dominik
98_DOIF.pm               16464 2018-03-21 20:23:57Z Damian
98_dummy.pm              12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm         14888 2017-08-13 12:07:12Z rudolfkoenig
72_FB_CALLLIST.pm        16433 2018-03-18 08:20:35Z markusbloch
72_FB_CALLMONITOR.pm     16392 2018-03-12 13:45:07Z markusbloch
93_FHEM2FHEM.pm          15006 2017-09-05 09:37:33Z rudolfkoenig
01_FHEMWEB.pm            16407 2018-03-14 19:43:35Z rudolfkoenig
92_FileLog.pm            15874 2018-01-13 17:16:33Z rudolfkoenig
98_freezemon.pm          16411 2018-03-14 22:22:14Z KernSani
72_FRITZBOX.pm           16461 2018-03-21 18:26:03Z tupol
10_FRM.pm                15941 2018-01-20 21:20:20Z jensb
20_FRM_IN.pm             16012 2018-01-27 20:11:34Z jensb
20_FRM_OUT.pm            15928 2018-01-19 21:07:42Z jensb
No Id found for 98_gcmsend.pm
21_HEOSMaster.pm         16400 2018-03-13 19:19:38Z CoolTux
21_HEOSPlayer.pm         16400 2018-03-13 19:19:38Z CoolTux
14_Hideki.pm             15450 2017-11-18 21:34:47Z Sidey
98_HMinfo.pm             16421 2018-03-17 06:15:49Z martinp876
98_HTTPMOD.pm            16216 2018-02-18 15:26:11Z StefanStrobel
49_IPCAM.pm               2626 2013-02-01 19:19:15Z mfr69bs
10_IT.pm                 14852 2017-08-06 08:48:24Z bjoernh
36_JeeLink.pm            14707 2017-07-13 18:08:33Z justme1968
36_LaCrosse.pm           16168 2018-02-13 21:01:41Z HCS
98_Modbus.pm             15871 2018-01-13 16:24:22Z StefanStrobel
37_ModbusRegister.pm        24 2018-02-06 21:22:00Z CD
No Id found for 98_ModbusRTUDimplexHP.pm
No Id found for 98_ModbusRTUDimplexZL.pm
# $Id: 36_ModbusTCPServer.pm 0021 $
No Id found for 99_myUtilsHeatPump.pm
91_notify.pm             15937 2018-01-20 13:43:28Z rudolfkoenig
41_OREGON.pm             12928 2017-01-02 00:23:46Z Sidey
10_pilight_ctrl.pm       16028 2018-01-28 18:34:25Z Risiko
30_pilight_switch.pm     11306 2016-04-24 17:03:16Z risiko79
30_pilight_temp.pm       10506 2016-01-14 20:40:45Z risiko79
73_PRESENCE.pm           16177 2018-02-14 08:58:43Z markusbloch
70_Pushbullet.pm          9730 2015-10-30 15:06:41Z fhainz
33_readingsGroup.pm      16299 2018-03-01 08:06:55Z justme1968
95_remotecontrol.pm      10724 2016-02-04 18:17:33Z ulimaass
96_SIP.pm                15827 2018-01-08 18:36:07Z Wzut
98_statistics.pm         16438 2018-03-18 18:51:57Z tupol
70_STV.pm                12857 2016-12-21 11:59:33Z Zwiebel
99_SUNRISE_EL.pm         16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm                16402 2018-03-13 21:14:22Z rudolfkoenig
42_SYSMON.pm             15910 2018-01-16 23:07:56Z hexenmeister
32_SYSSTAT.pm            10567 2016-01-18 21:34:09Z justme1968
98_telnet.pm             16293 2018-02-28 21:33:57Z rudolfkoenig
59_Twilight.pm           16005 2018-01-27 06:05:51Z igami
10_UNIRoll.pm            12819 2016-12-18 14:27:48Z C_Herrmann
99_Utils.pm              15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm            15140 2017-09-26 09:20:09Z markusbloch
59_Weather.pm            12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm            16293 2018-02-28 21:33:57Z rudolfkoenig
32_WifiLight.pm          15907 2018-01-16 20:58:44Z herrmannj
98_XmlList.pm            13128 2017-01-17 21:40:09Z rudolfkoenig

No Id found for Base.pm
Blocking.pm              15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm                 11159 2016-03-30 16:08:06Z justme1968
Common.pm                10759 2016-02-07 20:00:12Z rleins
No Id found for Constants.pm
ControlPoint.pm          15823 2018-01-07 22:42:45Z Reinerlein
DevIo.pm                 16329 2018-03-04 20:18:08Z rudolfkoenig
No Id found for Firmata.pm
FritzBoxUtils.pm         16344 2018-03-06 21:06:34Z rudolfkoenig
GPUtils.pm                6653 2014-10-02 11:59:37Z ntruchsess
HMConfig.pm              16265 2018-02-25 18:22:43Z martinp876
HttpUtils.pm             16407 2018-03-14 19:43:35Z rudolfkoenig
myUtilsTemplate.pm        7570 2015-01-14 18:31:44Z rudolfkoenig
No Id found for Platform.pm
No Id found for Protocol.pm
RTypes.pm                10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm         16211 2018-02-18 11:59:09Z rudolfkoenig
TcpServerUtils.pm        15707 2017-12-27 14:41:21Z rudolfkoenig
YahooWeatherAPI.pm       15742 2018-01-01 07:55:55Z neubert

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
svg.js                     15896 2018-01-14 21:35:42Z rudolfkoenig


und noch ...kern.log
Mar 20 23:27:00 raspberrypi kernel: [13120.516420] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 20 23:27:00 raspberrypi kernel: [13120.557959] CIFS VFS: Free previous auth_key.response = b9b6ab40
Mar 21 06:02:15 raspberrypi kernel: [36836.424855] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 21 06:02:16 raspberrypi kernel: [36836.585391] CIFS VFS: Free previous auth_key.response = bbc3d600
Mar 21 08:29:43 raspberrypi kernel: [45683.811778] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 21 08:29:43 raspberrypi kernel: [45683.872469] CIFS VFS: Free previous auth_key.response = bbf16900
Mar 21 10:07:00 raspberrypi kernel: [51520.628067] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 21 10:07:00 raspberrypi kernel: [51520.695347] CIFS VFS: Free previous auth_key.response = b9bfa480
Mar 21 20:47:00 raspberrypi kernel: [89920.717238] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 21 20:47:00 raspberrypi kernel: [89920.758606] CIFS VFS: Free previous auth_key.response = b9bf1a80
Mar 22 07:27:00 raspberrypi kernel: [128320.828999] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 22 07:27:00 raspberrypi kernel: [128320.870171] CIFS VFS: Free previous auth_key.response = bc26d9c0
Mar 22 13:52:50 raspberrypi kernel: [151470.958390] CIFS VFS: couldn't get user pages (rc=-512)
Mar 22 14:29:46 raspberrypi kernel: [153687.401447] bash (18001): drop_caches: 3
Mar 22 14:29:59 raspberrypi kernel: [153699.922579] bash (18019): drop_caches: 3
Mar 22 17:02:29 raspberrypi kernel: [162850.196320] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 22 17:02:29 raspberrypi kernel: [162850.308872] CIFS VFS: Free previous auth_key.response = b7b326c0
Mar 22 18:07:00 raspberrypi kernel: [166720.927149] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 22 18:07:00 raspberrypi kernel: [166721.003223] CIFS VFS: Free previous auth_key.response = 9ed729c0
Mar 22 19:27:45 raspberrypi kernel: [171566.037036] bash (29243): drop_caches: 3
Mar 22 19:28:28 raspberrypi kernel: [171608.954226] bash (29263): drop_caches: 3
Mar 22 19:41:13 raspberrypi kernel: [172374.319385] bash (29652): drop_caches: 3
Mar 22 20:59:02 raspberrypi kernel: [177042.873496] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 22 20:59:02 raspberrypi kernel: [177042.968372] CIFS VFS: Free previous auth_key.response = b7bcb000
Mar 23 00:40:44 raspberrypi kernel: [190345.572969] CIFS VFS: couldn't get user pages (rc=-512)
Mar 23 09:08:07 raspberrypi kernel: [220788.279096] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 23 09:08:07 raspberrypi kernel: [220788.327694] CIFS VFS: Free previous auth_key.response = ae314a80
Mar 23 10:18:48 raspberrypi kernel: [225029.191216] smsc95xx 1-1.1:1.0 eth0: link down
Mar 23 10:18:52 raspberrypi kernel: [225033.198611] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1
Mar 23 10:19:07 raspberrypi kernel: [225047.959319] smsc95xx 1-1.1:1.0 eth0: link down
Mar 23 10:19:11 raspberrypi kernel: [225052.351139] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
Mar 23 10:20:17 raspberrypi kernel: [225118.530131] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 23 10:20:20 raspberrypi kernel: [225121.609173] CIFS VFS: Free previous auth_key.response = 9ed1b180
Mar 24 00:32:22 raspberrypi kernel: [276243.141315] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 24 00:32:22 raspberrypi kernel: [276243.186988] CIFS VFS: Free previous auth_key.response = b9bffcc0
Mar 25 15:34:51 raspberrypi kernel: [413193.250673] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 25 15:34:51 raspberrypi kernel: [413193.303338] CIFS VFS: Free previous auth_key.response = ae2a6c00
Mar 25 22:17:17 raspberrypi kernel: [437339.228599] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 25 22:17:17 raspberrypi kernel: [437339.297795] CIFS VFS: Free previous auth_key.response = 9eeb4f00
Mar 26 00:27:20 raspberrypi kernel: [445142.129380] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 26 00:27:20 raspberrypi kernel: [445142.171369] CIFS VFS: Free previous auth_key.response = ae0a8c00
Mar 26 01:32:52 raspberrypi kernel: [449074.300972] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 26 01:32:52 raspberrypi kernel: [449074.342947] CIFS VFS: Free previous auth_key.response = bbdcc480
Mar 26 10:37:38 raspberrypi kernel: [481760.472609] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 26 10:37:38 raspberrypi kernel: [481760.558659] CIFS VFS: Free previous auth_key.response = ae2a6240
Mar 26 15:47:54 raspberrypi kernel: [500376.571595] CIFS VFS: Server 192.168.9.11 has not responded in 120 seconds. Reconnecting...
Mar 26 15:47:54 raspberrypi kernel: [500376.632303] CIFS VFS: Free previous auth_key.response = b993d900
Mar 26 15:47:55 raspberrypi kernel: [500376.881287] CIFS VFS: Autodisabling the use of server inode numbers on \\192.168.9.11\backupfhem. This server doesn't see
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 26 März 2018, 17:43:44
Interessant, ein von mir mit Jessie aufgesetzten System hatte ebenfalls Probleme siehe hier (https://forum.fhem.de/index.php/topic,84372.msg782436.html#msg782436).

Mein System läuft seit 20.03.2018 wieder unter Stretch 9.4 und bisher keine Probleme.
Latest Revision: 16469

Vorgenommene Änderung: das Modul freezmon in der fhem.cfg wurde auskommentiert.

Allerdings:
im zweiten System (siehe Signatur) war freezemon ebenfalls aktiv (mittlerweile inaktiv gesetzt), und es gab keine Probleme. Dieses FHEM-System dient lediglich als Internetradio im Gäste-WC (Modul mpd/mpc) und überwacht mehr Techem SmartMeetering-Devices als mein Produktivsystem. Also ein kaum belastetes System.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 26 März 2018, 19:15:40
Mein Freezemon ist schon länger auf Inaktiv ...zählt das auch oder muss dies direkt auskommentiert werden?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: nils_ am 27 März 2018, 07:57:50
Zitat von: rudolfkoenig am 18 März 2018, 20:01:04
Naja, meine Theorie ist, dass Stretch auf einem RPi das Problem verursacht :)

Zitat von: Brice am 26 März 2018, 17:43:44
Interessant, ein von mir mit Jessie aufgesetzten System hatte ebenfalls Probleme siehe hier (https://forum.fhem.de/index.php/topic,84372.msg782436.html#msg782436).

Mein System läuft seit 20.03.2018 wieder unter Stretch 9.4 und bisher keine Probleme.
Latest Revision: 16469

:o :o
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 27 März 2018, 10:14:43
Hallo,

heißt das jetzt auf Stretch upgraden?
Wenn ja gibt es da was zu beachten?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 27 März 2018, 11:10:45
Hallo Zusammen,
ich verfolge den Thread seit Samstag. Habe seitdem die gleichen Probleme und bin mittlerweile
bei ca. 2,5 Std. zwischen den Neustarts mit den beschriebenen Workarounds.

FHEM ist aktuell. Das debian-System ist schon seit September von Jessie auf Stretch aktualisiert
und seitdem auch absolut unauffällig und stabil. Laufzeiten von mehreren Wochen waren die Regel.

Als erstes beginnen die PRESENCE devices nicht mehr zu arbeiten, da sie kein ping mehr absetzen können.

Hier meine Systemdaten vom Pi3:
uname -a
Linux fhem1 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l GNU/Linux
cat /etc/debian_version
9.4
fheminfo:

System Info
ConfigType: configFile
SVN rev: 16492
OS: linux
Perl: 5.24.1
uniqueId: 197...

Die letzten eingespielten debian Updates von Freitag und Samstag sehen alle eher unkritisch aus:
Preparing to unpack .../libvorbisfile3_1.3.5-4+deb9u2_armhf.deb ...
Unpacking libvorbisfile3:armhf (1.3.5-4+deb9u2) over (1.3.5-4+deb9u1) ...
Preparing to unpack .../libvorbisenc2_1.3.5-4+deb9u2_armhf.deb ...
Unpacking libvorbisenc2:armhf (1.3.5-4+deb9u2) over (1.3.5-4+deb9u1) ...
Preparing to unpack .../libvorbis0a_1.3.5-4+deb9u2_armhf.deb ...
Unpacking libvorbis0a:armhf (1.3.5-4+deb9u2) over (1.3.5-4+deb9u1) ...
Processing triggers for libc-bin (2.24-11+deb9u3) ...
Setting up libvorbis0a:armhf (1.3.5-4+deb9u2) ...
Setting up libvorbisfile3:armhf (1.3.5-4+deb9u2) ...
Setting up libvorbisenc2:armhf (1.3.5-4+deb9u2) ...
Processing triggers for libc-bin (2.24-11+deb9u3) ...
Log ended: 2018-03-23  12:56:47
Vorbereitung zum Entpacken von .../libicu57_57.1-6+deb9u2_armhf.deb ...
Entpacken von libicu57:armhf (57.1-6+deb9u2) über (57.1-6+deb9u1) ...
Vorbereitung zum Entpacken von .../pi-bluetooth_0.1.7_all.deb ...
Entpacken von pi-bluetooth (0.1.7) über (0.1.6) ...
pi-bluetooth (0.1.7) wird eingerichtet ...
libicu57:armhf (57.1-6+deb9u2) wird eingerichtet ...
Trigger für libc-bin (2.24-11+deb9u3) werden verarbeitet ...
Log ended: 2018-03-24  21:22:50


Irgendwas ist da Mega-Faul...  :o

VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 27 März 2018, 14:06:14
Zitat von: enno am 16 März 2018, 12:49:56
Ich beobachte zur Zeit folgende Module kritisch: SIP, Dblog, Tahoma und MPD. MPD werde ich dieses Wochenende mal auf einen anderen RPi "auslagern"...

Habe letzte Woche MPD auf den anderen Pi "verschoben" das hat nichtsl gebracht.
Gestern bei SIP das Attribut sip_listen wfp gelöscht. Jetzt ist der Speicheranstieg seit ca. 24 Stunden nahezu weg....

Gruss
  Enno
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 März 2018, 14:14:12
Zitat von: enno am 27 März 2018, 14:06:14
Gestern bei SIP das Attribut sip_listen wfp gelöscht. Jetzt ist der Speicheranstieg seit ca. 24 Stunden nahezu weg....

Gruss
  Enno

Enno Du könntest eventuell Gold wert sein mein Junge.
Ein schneller Blick über alle Threadeinträge mit version ergab das alle das Modul
96_SIP.pm                15827 2018-01-08 18:36:07Z Wzut
in Verwendung haben die Probleme haben.

Die User welche das so haben sind nun am Zug. Modul deaktivieren oder besser noch erstmal komplett raushauen und testen bitte.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: nils_ am 27 März 2018, 14:41:53
ich will ja deine Euphorie nicht bremsen, aber in rudi's "sammlung" taucht SIP nicht auf.
soll nicht heißen das es nicht zum problem führt, wollte es nur erwähnen  :-[
Zitat von: rudolfkoenig am 17 März 2018, 08:57:21
Zwischenergebnis der version Sammlung:
In allen 6 Problemfaellen kommen folgende Perl Dateien vor:
01_FHEMWEB.pm
33_readingsGroup.pm
90_at.pm
91_eventTypes.pm
91_notify.pm
92_FileLog.pm
98_DOIF.pm
98_SVG.pm
98_autocreate.pm
98_dummy.pm
98_telnet.pm
98_version.pm
98_weblink.pm
99_SUNRISE_EL.pm
99_Utils.pm
Blocking.pm
Color.pm
DevIo.pm
HttpUtils.pm
RTypes.pm
SetExtensions.pm
TcpServerUtils.pm
fhem.pl

Leider kommen diese alle auch in der "ohne Probleme" Liste vor, d.h. das Problem ist nicht auf die einfache Verwendung eines Moduls zurueckzufuehren.

@Heiko: ich glaube nicht, dass das Problem an DBLog liegt, siehe auch die o.g. Liste, und meine Kommentare vorhin.
Aber wenn du schon dabei bist: wuerdest du deine Systeme auf Stretch updaten ? :)

Zitat von: CoolTux am 27 März 2018, 14:14:12
Die User welche das so haben sind nun am Zug. Modul deaktivieren oder besser noch erstmal komplett raushauen und testen bitte.
das schadet definitiv nicht :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 März 2018, 14:45:12
Komisch. Ich bin die Seiten des Threads durchgegangen und habe überall geschaut.
Aber ein Versuch wäre es ja Wert. Nicht das die User noch fälschlicher Weise denken hier geht es nicht weiter. Das stimmt ja nicht, selbst Rudi liest sicherlich immer mit, weiß aber im Moment selbst noch nicht ganz oder testet noch.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 27 März 2018, 15:03:27
Bei mir kommen auch weder SIP noch MPD zum Einsatz. Dafür die folgenden:
System Info
ConfigType: configFile
SVN rev: 16492
OS: linux
Perl: 5.24.1
uniqueId: 197...

Modules Model Count
ABFALL 1
AMADCommBridge 1
AMADDevice 1
Astro 1
Aurora 1
CALVIEW 1
Calendar 5
DOIF
FHEM 20
DOIFtools 1
EGPM 4
EGPM2LAN 1
ENIGMA2
dm800se 1
EnOcean 2
FHEM2FHEM 1
FHEMWEB 2
FRITZBOX
FRITZ!Box 6430 Cable 1
FileLog 5
GUEST 1
HOMEMODE 1
HTTPMOD 1
HUEBridge 1
HUEDevice 7
RB 185 C 1
LCT001 3
LWB004 2
IPCAM 1
KODI 1
LightScene 6
MQTT 1
MQTT_DEVICE 2
PRESENCE
function 4
lan-ping 5
event 5
PROPLANTA 1
QRCode 1
RESIDENTS 2
RFHEM 1
ROOMMATE 3
RandomTimer 3
SONOS 1
SONOSPLAYER
Sonos_S12 1
SVG 3
SYSMON 1
TCM
ESP3 1
TRAFFIC 7
TelegramBot 1
Twilight 1
UWZ 1
Verkehrsinfo 3
WINCONNECT
Windows 10 Enterprise 1
Windows 10 Home 1
WOL 2
Weather 1
WeekdayTimer 1
Wunderground 1
YAMAHA_AVR
RX-V479 1
alexa 1
allowed 2
archetype 4
at 6
autocreate 1
cmdalias 16
dash_dhcp 1
dummy 43
freezemon 1 (deaktiviert)
harmony 1
holiday 2
livetracking 1
monitoring 1
msgConfig 1
msgDialog 16
notify 32
readingsGroup 7
readingsHistory 1
remotecontrol 1
rssFeed 1
serviced 12
siri 1
speedtest 1
structure 8
telnet 1
weblink 8

VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 27 März 2018, 15:09:46
Hallo,
Bei mir kann es das Sip Modul nicht sein.... ich habe das Modul gelöscht, restart und eine halbe Stunde später ist der freier Speicher beim ausführen des Fhem Backups von 320mb auf 60mb gefallen....


Gesendet von iPhone mit Tapatalk
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 März 2018, 15:12:01
Och Menno, wäre ja auch zu einfach gewesen. Danke für die Rückmeldungen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 27 März 2018, 15:54:05
Einen Hinweis hätte ich noch aus eigener Erfahrung.
Wer 98_apptime einsetzt, sollte auf jeden Fall die aktuelle Version

98_apptime.pm             16460 2018-03-21 18:08:15Z martinp876

verwenden.
Das ältere apptime ist nicht kompatibel zur aktuellen fhem.pl.
Das Modul freezemon lädt zum Beispiel mit gesetztem Attribut "fm_forceApptime = 1" apptime automatisch.

Das Problem des ansteigenden Speichers hatte ich auch kurz nach der Umstellung der  InternalTimer-Verwaltung Mitte Februar.
Siehe hier: https://forum.fhem.de/index.php/topic,81365.msg771811.html#msg771811

Kurztest. Dieses Statement im FHEMWEB-Kommandozeile abgesetzt sollte nichts ausgeben:


{ join("\n", map {$intAtA[$_]->{FN}} grep { !$intAt{ $intAtA[$_]->{atNr} } } (0..@intAtA)) }

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 27 März 2018, 16:03:25
ZitatKurztest. Dieses Statement im FHEMWEB-Kommandozeile abgesetzt sollte nichts ausgeben:

Code: [Auswählen]
{ join("\n", map {$intAtA[$_]->{FN}} grep { !$intAt{ $intAtA[$_]->{atNr} } } (0..@intAtA)) }
Korrekt, die Ausgabe bleibt leer. Im Log erscheint aber folgendes:
2018.03.27 16:01:59 1: PERL WARNING: Use of uninitialized value in hash element at (eval 5130) line 1.
2018.03.27 16:01:59 3: eval: { join("\n", map {$intAtA[$_]->{FN}} grep { !$intAt{ $intAtA[$_]->{atNr} } } (0..@intAtA)) }
2018.03.27 16:01:59 1: PERL WARNING: Use of uninitialized value in join or string at (eval 5130) line 1.
2018.03.27 16:01:59 3: eval: { join("\n", map {$intAtA[$_]->{FN}} grep { !$intAt{ $intAtA[$_]->{atNr} } } (0..@intAtA)) }

VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 27 März 2018, 16:06:57
ZitatKorrekt, die Ausgabe bleibt leer. Im Log erscheint aber folgendes:
Ja, ist gut. Ist nur ein Test. Im Problemfall käme so eine Ausgabe:


CODE(0x1b36920)
CODE(0x1b45c10)
CODE(0x1be2988)
CODE(0x182ea88)
CODE(0x1c5ed48)
CODE(0x3ba2e58)
CODE(0x3cf6018)
CODE(0x4e12640)
CODE(0x5478bd8)
CODE(0x5b60530)
.......


Sieht man in dem von mir verlinkten Thread.


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 27 März 2018, 21:40:44
ZitatRudi liest sicherlich immer mit, weiß aber im Moment selbst noch nicht ganz oder testet noch.
Ich lese mit, gute Ideen habe ich keine, und teste deswegen auch nicht. "Stochern im dunkeln": kann jemand die Ausgabe von "cat /proc/<fhem-pid>/status" hier direkt nach dem Start, und bei deutlichen Anzeichen von einem Problem hier hochladen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 28 März 2018, 08:17:29
Hallo,

die Module
FRITZBOX,FB_CALLMONITOR,FB_CALLLIST,SIP
kann ich ausschließen.
Deaktivieren hat bei mir nicht geholfen.
Werde heute Nachmittag mal presence testen...oder noch andere Vorschläge?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 28 März 2018, 10:56:13
Zitat"Stochern im dunkeln": kann jemand die Ausgabe von "cat /proc/<fhem-pid>/status" hier direkt nach dem Start, und bei deutlichen Anzeichen von einem Problem hier hochladen?
Hallo Rudi, klaro geht das!  :)

Wenn die Meldung "Cannot fork: Cannot allocate memory" auftaucht:
Erste Anzeichen sind: sudo cat /proc/13445/status
Name:   perl
Umask:  0022
State:  S (sleeping)
Tgid:   13445
Ngid:   0
Pid:    13445
PPid:   1
TracerPid:      0
Uid:    999     999     999     999
Gid:    20      20      20      20
FDSize: 256
Groups: 5 20
NStgid: 13445
NSpid:  13445
NSpgid: 453
NSsid:  453
VmPeak:   495316 kB
VmSize:   495316 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:    487304 kB
VmRSS:    487304 kB
RssAnon:          479776 kB
RssFile:            7528 kB
RssShmem:              0 kB
VmData:   481760 kB
VmStk:       132 kB
VmExe:      1676 kB
VmLib:      6344 kB
VmPTE:       494 kB
VmPMD:         0 kB
VmSwap:        0 kB
Threads:        1
SigQ:   0/7742
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000011086
SigCgt: 0000000180006001
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Seccomp:        0
Cpus_allowed:   f
Cpus_allowed_list:      0-3
Mems_allowed:   1
Mems_allowed_list:      0
voluntary_ctxt_switches:        119313
nonvoluntary_ctxt_switches:     93028


Und hier direkt nach einem Neustart:
sudo cat /proc/29490/status
Name:   perl
Umask:  0022
State:  S (sleeping)
Tgid:   29490
Ngid:   0
Pid:    29490
PPid:   1
TracerPid:      0
Uid:    999     999     999     999
Gid:    20      20      20      20
FDSize: 256
Groups: 5 20
NStgid: 29490
NSpid:  29490
NSpgid: 453
NSsid:  453
VmPeak:   131820 kB
VmSize:   131608 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:    123408 kB
VmRSS:    123404 kB
RssAnon:          115792 kB
RssFile:            7612 kB
RssShmem:              0 kB
VmData:   118052 kB
VmStk:       132 kB
VmExe:      1676 kB
VmLib:      6344 kB
VmPTE:       134 kB
VmPMD:         0 kB
VmSwap:        0 kB
Threads:        1
SigQ:   0/7742
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000011086
SigCgt: 0000000180006001
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Seccomp:        0
Cpus_allowed:   f
Cpus_allowed_list:      0-3
Mems_allowed:   1
Mems_allowed_list:      0
voluntary_ctxt_switches:        610
nonvoluntary_ctxt_switches:     1549


VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 28 März 2018, 11:21:03
Ok, nichts Neues: Datensegment (VmData) waechst, typisch fuer Speicherleck.

Das Letzte was mir einfaellt, dass ein Freiwilliger mit dem Problem nach und nach Module deaktiviert, bis das Problem nicht mehr auftritt. Beachte: mit binaere Suche sind es hoechstens log(N) Neustarts :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: nils_ am 28 März 2018, 11:29:24
Zitat von: rudolfkoenig am 28 März 2018, 11:21:03
Das Letzte was mir einfaellt, dass ein Freiwilliger mit dem Problem nach und nach Module deaktiviert, bis das Problem nicht mehr auftritt. Beachte: mit binaere Suche sind es hoechstens log(N) Neustarts :)
oder jemand ohne probleme aktiviert nach und nach module  ::)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 28 März 2018, 11:31:53
Zitat von: rudolfkoenig am 28 März 2018, 11:21:03
Das Letzte was mir einfaellt, dass ein Freiwilliger mit dem Problem nach und nach Module deaktiviert, bis das Problem nicht mehr auftritt. Beachte: mit binaere Suche sind es hoechstens log(N) Neustarts :)

Ich bin schon dabei. Ich lager ein Modul (MPD, SIP, AVM) nach dem anderen auf meinen zweiten Pi aus. Verbunden über FHEM2FHEM und Dummys funktioniert die Steuerung auf dem auffälligen System weiter.

Die Verlagerung von MPD hat den Speicherverbrauch deutlich reduziert, aber noch nicht beseitigt. Ich warte gerade ab, wann das System das nächste mal stehen bleibt. Dann werde ich die ganzen Wetterdienste umziehen...

Gruss
  Enno
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: eisman am 28 März 2018, 12:56:49
hi,

ich hatte das Problem die letzten zwei tage auch,
ich hab ipv6 und Lan-Team in meinem Netzwerk abgeschaltet.
seit über 14 stunden keine Meldung mehr,
nur die laufenden HMLAN Disconnects sind zwar weniger geworden,
nur halt noch da.

kann also nicht sagen ob es vielleicht dazu gehört.
gruss
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 28 März 2018, 16:50:25
Automatischer Neustart bei RAM Speicher 0MB hat keine Funktion.
Das Reading des Ram Speicher gibt im Fehlerfall n/a aus und nicht Null!
Internals:
   CFGFN      /media/hdd/fhem/mycfg/schnittstellen_rasp02.cfg
   DEF        1 1 1 10
   INTERVAL_BASE 60
   INTERVAL_MULTIPLIERS 1 1 1 10
   MODE       local
   NAME       sysmon
   NR         92
   STATE      Error: Blocking call aborted (timeout)
   TYPE       SYSMON
   READINGS:
     2018-03-28 16:43:16   cpu0_freq       600
     2018-03-28 16:43:16   cpu0_freq_stat  600.00 1200.00 759.83
     2018-03-28 00:39:20   cpu0_idle_stat  8.24 99.91 96.98
     2018-03-28 16:43:16   cpu1_freq       600
     2018-03-28 16:43:16   cpu1_freq_stat  600.00 1200.00 759.83
     2018-03-28 00:39:20   cpu1_idle_stat  10.10 100.00 99.14
     2018-03-28 16:43:16   cpu2_freq       600
     2018-03-28 16:43:16   cpu2_freq_stat  600.00 1200.00 759.83
     2018-03-28 00:39:20   cpu2_idle_stat  5.73 100.00 97.92
     2018-03-28 16:43:16   cpu3_freq       600
     2018-03-28 16:43:16   cpu3_freq_stat  600.00 1200.00 759.83
     2018-03-28 00:39:20   cpu3_idle_stat  15.66 100.00 97.30
     2018-03-24 13:36:21   cpu_bogomips    38.40
     2018-03-28 01:40:46   cpu_core_count  4
     2018-03-28 16:43:16   cpu_freq        600
     2018-03-28 16:43:16   cpu_freq_stat   600.00 1200.00 759.83
     2018-03-28 00:39:20   cpu_idle_stat   46.32 99.57 97.86
     2018-03-24 13:36:21   cpu_model_name  ARMv7 Processor rev 4 (v7l)
     2018-03-28 01:40:46   cpu_temp        0.00
     2018-03-28 01:40:46   cpu_temp_avg    0.2
     2018-03-28 01:40:46   cpu_temp_stat   0.00 63.38 0.01
     2018-03-28 01:40:46   ethernet        not available
     2018-03-28 01:40:46   ethernet_diff   not available
     2018-03-28 00:39:20   ethernet_ip     192.168.17.182
     2018-03-28 00:39:20   ethernet_rx     203558254
     2018-03-28 00:39:20   ethernet_speed  not available
     2018-03-28 00:39:20   ethernet_tx     256661532
     2018-03-28 01:40:46   fhemstarttime   1521894924
     2018-03-28 01:40:46   fhemstarttime_text 24.03.2018 13:35:24
     2018-03-28 01:40:46   fhemuptime      299122
     2018-03-28 01:40:46   fhemuptime_text 3 days, 11 hours, 05 minutes
     2018-03-28 01:40:46   fs_boot         Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /boot (not available)
     2018-03-28 01:40:46   fs_hdd          Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /media/hdd (not available)
     2018-03-28 01:40:46   fs_root         Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at / (not available)
     2018-03-28 00:39:20   idletime        285192 96.45 %
     2018-03-28 00:39:20   idletime_text   3 days, 07 hours, 13 minutes (96.45 %)
     2018-03-28 00:39:20   loadavg         0.22 0.23 0.19
     2018-03-24 13:36:21   perl_version    v5.24.1
     2018-03-28 01:40:46   ram             n/a
     2018-03-28 16:43:16   ram_used       
     2018-03-28 00:39:20   ram_used_stat   -1054.83 520.80 493.07
     2018-03-28 00:39:20   starttime       1521894667
     2018-03-28 00:39:20   starttime_text  24.03.2018 13:31:07
     2018-03-28 00:39:20   stat_cpu        491262 946 1997694 114077157 39128 0 20299
     2018-03-28 00:39:20   stat_cpu0       256813 185 605754 27622988 18353 0 19752
     2018-03-28 00:39:20   stat_cpu0_diff  311 0 305 28661 17 0 18
     2018-03-28 00:39:20   stat_cpu0_percent 1.06 0.00 1.04 97.78 0.06 0.00 0.06
     2018-03-28 00:39:20   stat_cpu0_text  user: 1.06 %, nice: 0.00 %, sys: 1.04 %, idle: 97.78 %, io: 0.06 %, irq: 0.00 %, sirq: 0.06 %
     2018-03-28 00:39:20   stat_cpu1       65159 217 500747 28783466 6241 0 277
     2018-03-28 00:39:20   stat_cpu1_diff  81 0 93 30036 3 0 1
     2018-03-28 00:39:20   stat_cpu1_percent 0.27 0.00 0.31 99.41 0.01 0.00 0.00
     2018-03-28 00:39:20   stat_cpu1_text  user: 0.27 %, nice: 0.00 %, sys: 0.31 %, idle: 99.41 %, io: 0.01 %, irq: 0.00 %, sirq: 0.00 %
     2018-03-28 00:39:20   stat_cpu2       89931 320 435602 28837265 8991 0 164
     2018-03-28 00:39:20   stat_cpu2_diff  37 0 108 30022 6 0 0
     2018-03-28 00:39:20   stat_cpu2_percent 0.12 0.00 0.36 99.50 0.02 0.00 0.00
     2018-03-28 00:39:20   stat_cpu2_text  user: 0.12 %, nice: 0.00 %, sys: 0.36 %, idle: 99.50 %, io: 0.02 %, irq: 0.00 %, sirq: 0.00 %
     2018-03-28 00:39:20   stat_cpu3       79359 224 455591 28833438 5543 0 106
     2018-03-28 00:39:20   stat_cpu3_diff  9 0 1429 28018 8 0 0
     2018-03-28 00:39:20   stat_cpu3_percent 0.03 0.00 4.85 95.09 0.03 0.00 0.00
     2018-03-28 00:39:20   stat_cpu3_text  user: 0.03 %, nice: 0.00 %, sys: 4.85 %, idle: 95.09 %, io: 0.03 %, irq: 0.00 %, sirq: 0.00 %
     2018-03-28 00:39:20   stat_cpu_diff   438 0 1935 116737 34 0 19
     2018-03-28 00:39:20   stat_cpu_percent 0.37 0.00 1.62 97.96 0.03 0.00 0.02
     2018-03-28 00:39:20   stat_cpu_text   user: 0.37 %, nice: 0.00 %, sys: 1.62 %, idle: 97.96 %, io: 0.03 %, irq: 0.00 %, sirq: 0.02 %
     2018-03-28 01:40:46   swap            n/a
     2018-03-28 00:39:20   swap_used_stat  0.00 0.00 0.00
     2018-03-28 00:39:20   uptime          295692
     2018-03-28 00:39:20   uptime_text     3 days, 10 hours, 08 minutes
   helper:
     net_ethernet_stat_class 0
     proc_fs    1
     sys_cpu0_freq 1
     sys_cpu0_temp 0
     sys_cpu1_freq 1
     sys_cpu1_temp 0
     sys_cpu2_freq 1
     sys_cpu2_temp 0
     sys_cpu3_freq 1
     sys_cpu3_temp 0
     sys_cpu4_freq 0
     sys_cpu4_temp 0
     sys_cpu5_freq 0
     sys_cpu5_temp 0
     sys_cpu6_freq 0
     sys_cpu6_temp 0
     sys_cpu7_freq 0
     sys_cpu7_temp 0
     sys_cpu_core_num 4
     sys_cpu_freq_rpi_bbb 1
     sys_cpu_num 1
     sys_cpu_temp_bbb 0
     sys_cpu_temp_rpi 1
     sys_fb     0
     sys_power_ac 0
     sys_power_bat 0
     sys_power_usb 0
     u_first_mark 1
     READOUT_RUNNING_PID:
       abortFn    SYSMON_blockingAbort
       arg        sysmon|0
       bc_pid     25541
       finishFn   SYSMON_blockingFinish
       fn         SYSMON_blockingCall
       pid        WAITING:
       timeout    55
       abortArg:
     cur_readings_map:
       cpu0_freq  CPU frequency (core 0)
       cpu0_freq_stat CPU frequency (core 0) stat
       cpu0_idle_stat CPU0 min/max/avg (idle)
       cpu1_freq  CPU frequency (core 1)
       cpu1_freq_stat CPU frequency (core 1) stat
       cpu1_idle_stat CPU1 min/max/avg (idle)
       cpu2_freq  CPU frequency (core 2)
       cpu2_freq_stat CPU frequency (core 2) stat
       cpu2_idle_stat CPU2 min/max/avg (idle)
       cpu3_freq  CPU frequency (core 3)
       cpu3_freq_stat CPU frequency (core 3) stat
       cpu3_idle_stat CPU3 min/max/avg (idle)
       cpu4_idle_stat CPU4 min/max/avg (idle)
       cpu5_idle_stat CPU5 min/max/avg (idle)
       cpu6_idle_stat CPU6 min/max/avg (idle)
       cpu7_idle_stat CPU7 min/max/avg (idle)
       cpu_bogomips BogoMIPS
       cpu_core_count Number of CPU cores
       cpu_freq   CPU frequency
       cpu_freq_stat CPU frequency stat
       cpu_idle_stat CPU min/max/avg (idle)
       cpu_model_name CPU model name
       cpu_temp   CPU temperature
       cpu_temp_avg Average CPU temperature
       cpu_temp_stat CPU temperature stat
       date       Date
       ethernet   Ethernet
       ethernet_diff Ethernet (diff)
       ethernet_ip Ethernet (IP)
       ethernet_ip6 Ethernet (IP6)
       ethernet_rx Ethernet (RX)
       ethernet_speed Ethernet (speed)
       ethernet_tx Ethernet (TX)
       fhemstarttime Fhem start time
       fhemstarttime_text Fhem start time
       fhemuptime System up time
       fhemuptime_text FHEM up time
       fs_boot    Filesystem-Boot
       fs_boot_free Filesystem-Boot (free)
       fs_boot_used Filesystem-Boot (used)
       fs_boot_used_percent Filesystem-Boot (used %)
       fs_hdd     LAN-HDD
       fs_hdd_free LAN-HDD (free)
       fs_hdd_used LAN-HDD (used)
       fs_hdd_used_percent LAN-HDD (used %)
       fs_root    microSD-lokal
       fs_root_free microSD-lokal (free)
       fs_root_used microSD-lokal (used)
       fs_root_used_percent microSD-lokal (used %)
       idletime   Idle time
       idletime_text Idle time
       io_sda     TEST
       io_sda_diff TEST
       io_sda_raw TEST
       loadavg    Load average
       loadavg_1  Load average 1
       loadavg_15 Load average 15
       loadavg_5  Load average 5
       perl_version Perl Version
       ram        RAM
       ram_free   RAM free
       ram_free_percent RAM free %
       ram_total  RAM total
       ram_used   RAM used
       ram_used_stat RAM used stat
       starttime  System start time
       starttime_text System start time
       stat_cpu   CPU statistics
       stat_cpu0  CPU0 statistics
       stat_cpu0_diff CPU0 statistics (diff)
       stat_cpu0_percent CPU0 statistics (diff, percent)
       stat_cpu0_text CPU0 statistics (text)
       stat_cpu1  CPU1 statistics
       stat_cpu1_diff CPU1 statistics (diff)
       stat_cpu1_percent CPU1 statistics (diff, percent)
       stat_cpu1_text CPU1 statistics (text)
       stat_cpu2  CPU2 statistics
       stat_cpu2_diff CPU2 statistics (diff)
       stat_cpu2_percent CPU2 statistics (diff, percent)
       stat_cpu2_text CPU2 statistics (text)
       stat_cpu3  CPU3 statistics
       stat_cpu3_diff CPU3 statistics (diff)
       stat_cpu3_percent CPU3 statistics (diff, percent)
       stat_cpu3_text CPU3 statistics (text)
       stat_cpu4  CPU4 statistics
       stat_cpu4_diff CPU4 statistics (diff)
       stat_cpu4_percent CPU4 statistics (diff, percent)
       stat_cpu4_text CPU4 statistics (text)
       stat_cpu5  CPU5 statistics
       stat_cpu5_diff CPU5 statistics (diff)
       stat_cpu5_percent CPU5 statistics (diff, percent)
       stat_cpu5_text CPU5 statistics (text)
       stat_cpu6  CPU6 statistics
       stat_cpu6_diff CPU6 statistics (diff)
       stat_cpu6_percent CPU6 statistics (diff, percent)
       stat_cpu6_text CPU6 statistics (text)
       stat_cpu7  CPU7 statistics
       stat_cpu7_diff CPU7 statistics (diff)
       stat_cpu7_percent CPU7 statistics (diff, percent)
       stat_cpu7_text CPU7 statistics (text)
       stat_cpu_diff CPU statistics (diff)
       stat_cpu_idle_percent CPU statistics idle %
       stat_cpu_io_percent CPU statistics io %
       stat_cpu_irq_percent CPU statistics irq %
       stat_cpu_nice_percent CPU statistics nice %
       stat_cpu_percent CPU statistics (diff, percent)
       stat_cpu_sirq_percent CPU statistics sirq %
       stat_cpu_sys_percent CPU statistics sys %
       stat_cpu_text CPU statistics (text)
       stat_cpu_user_percent CPU statistics user %
       swap       swap
       swap_free  swap free
       swap_total swap total
       swap_used  swap used
       swap_used_percent swap used %
       swap_used_stat swap used stat
       uptime     System up time
       uptime_text System up time
     excludes:
     shadow_map:
       cpu_core_count 4
       cpu_temp   0.00
       cpu_temp_avg 0.2
       cpu_temp_stat 0.00 63.38 0.01
       ethernet   not available
       ethernet_diff not available
       fhemstarttime 1521894924
       fhemstarttime_text 24.03.2018 13:35:24
       fhemuptime 353264
       fhemuptime_text 4 days, 02 hours, 07 minutes
       fs_boot    Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /boot (not available)
       fs_hdd     Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /media/hdd (not available)
       fs_root    Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at / (not available)
       ram        n/a
       swap       n/a
Attributes:
   alias      Systemmonitor
   event-min-interval .*:600
   event-on-change-reading cpu_temp,cpu_temp_avg,cpu_freq,ethernet_diff,loadavg,ram,fs_.*,stat_cpu_percent
   eventMap   Initialized:it_nas@0CFB0C
   filesystems fs_boot:/boot:Filesystem-Boot,fs_root:/:microSD-lokal,fs_hdd:/media/hdd:LAN-HDD
   group      RPi
   icon       time_graph
   network-interfaces ethernet:eth0:Ethernet
   room       _Systemlast
   sortby     01
   userReadings ram_used {
if (ReadingsVal($name,'ram','0')  =~ m/Used:\s(.*)\sMB,/) {
return $1;
}
}
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 28 März 2018, 17:17:29
ZitatDas Reading des Ram Speicher gibt im Fehlerfall n/a aus und nicht Null!
Hallo Chris,
das kann ich bestätigen. Bei mir kommen die Cannot fork... Meldungen so ab 550 MByte used_ram:
defmod sysmon_notify_1 notify sysmon:ram_used:.* {
  my $ram_used = ReadingsVal("sysmon","ram_used","0");
  if ($ram_used > 550) {
    fhem "setreading sysmon ram_used 100; msg push FHEM-Neustart wegen Speichermangel!; sleep 5; shutdown restart";
  }
}

Das setreading musste ich einfügen um mehrmalige Neustarts direkt nacheinander zu vermeiden...
VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 28 März 2018, 18:05:26
Falls ihr euch auf meinen Workaround (ram_used) bezieht, ist euer Notify nicht korrekt. Hier hatte ich einen Auszug aus dem Logfile gepostet (https://forum.fhem.de/index.php/topic,84372.msg782436.html#msg782436), das bedeutet bei mir, dass ich den Schwellwert bei > 500 gesetzt habe. Notify bei mir (getestet mit Wert > 180):

sysmon:ram_used:.* {
if (ReadingsVal("sysmon","ram_used", " ") > 500)
{fhem ("shutdown restart")}
}


Mein Produktivsystem läuft ohne Restart seit dem 20.03.2018 problemlos. Warum? Keine Ahnung...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 28 März 2018, 18:42:07
@binford6000
Das ist bei meinen beiden Systemen ebenfalls das es ab ca. 550 Mbyte vorbei ist mit dem System.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 28 März 2018, 18:51:03
Hallo Brice,
ZitatFalls ihr euch auf meinen Workaround (ram_used) bezieht, ist euer Notify nicht korrekt.
Ja, ich verwende Dein userReading ram_used. Nein, das notify funktioniert. Es muss halt ein event-on-update-reading
auf ram_used eingerichtet werden.
Man könnte auch mit
grep -a "Cannot fork: Cannot allocate memory" /opt/fhem/log/fhem-$(date +%Y-%m-%d).log | tail -1
via cron in einem Shellskript das Logfile überwachen und selbiges jeweils bei global:INITIALIZE mit einem cmdalias löschen:
defmod c_dellog cmdalias dellog AS {qx(truncate $currlogfile --size 0);;Log 1, "Logfile gelöscht";;}

Viel besser wäre allerdings, wenn ich die ganze Restart-Sch.... wieder löschen könnte  :(
VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 28 März 2018, 19:28:15
Zitat von: binford6000 am 28 März 2018, 18:51:03
Viel besser wäre allerdings, wenn ich die ganze Restart-Sch.... wieder löschen könnte  :(
VG Sebastian

Das kannst Du! Kommentiere nach und nach alle Devices aus und schaue ab welchem Punkt das Problem nicht mehr auf tritt.
Aussitzen und warten bis andere das Problem für einen lösen ist eher Kontraproduktiv.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 28 März 2018, 19:46:42
ZitatAussitzen und warten bis andere das Problem für einen lösen ist eher Kontraproduktiv.
Vorsicht mit solchen Behauptungen! >:(
Mein Kommentar im letzten Post war meine persönliche Stimmungslage  :(

Ich habe bereits einige Module versuchsweise deaktiviert - leider ohne Erfolg. Ich tippe daher auf ein Problem mit debian und/oder perl...
VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 29 März 2018, 07:56:42
ZitatIch tippe daher auf ein Problem mit debian und/oder perl...
Ich auch, aber wahrscheinlich nur im Zusammenspiel mit irgendeiner Funktion, was in FHEM nur an bestimmten Stellen verwendet wird, sonst haetten wir hier keine Faelle ohne Probleme. Wenn wir diese Stellen kennen wuerden, dann koennten wir einen Workaround schreiben, oder gezielter nach Loesung suchen.

Weitere Ideen fuer das Lokalisieren des Problems:
- Unterschiedliche perl Versionen installieren, und testen
- FHEM mit einem debug-malloc library (valgrind oder dmalloc) starten, um die Stelle einzugrenzen.

Btw. mit dem FHEM-Neustart zu warten bis man kein Speicher hat, ist zu spaet: wenn FHEM auf etwa die Haelfte des verfuegbaren Speichers angewachsen ist, wird BlockingCall nicht mehr klappen, weil Linux nicht garantieren kann, dass genug Speicher nach dem fork zur Verfugung steht (stark vereinfacht: fork in BlockingCall dupliziert den alten Prozess).
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 29 März 2018, 10:16:45
Zitat von: rudolfkoenig am 16 März 2018, 16:39:47
Koennten bitte alle, die dieses Problem haben, die Ausgabe von version hier anhaengen?
Und wenn jemand unter Stretch keine Probleme hat, der sollte das bitte auch tun, aber dazuschreiben, dass es eben keine Probleme gibt.
Evtl. hilft uns danach die Mengenlehre weiter.

Habe hier unter einem PI3 mit Stretch das selbe a Problem.
DBLOG nutze ich nicht.
Latest Revision: 16492

File                         Rev   Last Change

fhem.pl                      16453 2018-03-20 21:15:44Z rudolfkoenig
57_ABFALL.pm                 11020 2017-09-13 00:40:21Z uniqueck
95_Alarm.pm                  16368 2018-03-10 07:01:51Z phenning
90_at.pm                     15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm             15620 2017-12-16 18:10:36Z rudolfkoenig
57_Calendar.pm               15612 2017-12-15 09:26:59Z neubert
57_CALVIEW.pm                16023 2018-01-28 16:28:47Z chris1284
10_CUL_HM.pm                 16258 2018-02-24 22:11:14Z martinp876
98_DOIF.pm                   16481 2018-03-25 09:10:27Z Damian
98_DOIFtools.pm              16245 2018-02-23 13:16:23Z Ellert
98_dummy.pm                  12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm             14888 2017-08-13 12:07:12Z rudolfkoenig
00_FBAHAHTTP.pm              16344 2018-03-06 21:06:34Z rudolfkoenig
10_FBDECT.pm                 16441 2018-03-18 21:39:08Z rudolfkoenig
72_FB_CALLMONITOR.pm         16483 2018-03-25 09:42:35Z markusbloch
01_FHEMWEB.pm                16407 2018-03-14 19:43:35Z rudolfkoenig
92_FileLog.pm                15874 2018-01-13 17:16:33Z rudolfkoenig
98_freezemon.pm              16411 2018-03-14 22:22:14Z KernSani
72_FRITZBOX.pm               16461 2018-03-21 18:26:03Z tupol
98_help.pm                   15223 2017-10-10 10:14:24Z betateilchen
98_HMinfo.pm                 16421 2018-03-17 06:15:49Z martinp876
00_HMLAN.pm                  14073 2017-04-22 13:45:25Z martinp876
95_holiday.pm                16293 2018-02-28 21:33:57Z rudolfkoenig
98_HTTPMOD.pm                16216 2018-02-18 15:26:11Z StefanStrobel
02_HTTPSRV.pm                13976 2017-04-12 13:35:44Z neubert
49_IPCAM.pm                   2626 2013-02-01 19:19:15Z mfr69bs
10_IT.pm                     14852 2017-08-06 08:48:24Z bjoernh
36_JeeLink.pm                14707 2017-07-13 18:08:33Z justme1968
98_JsonList2.pm              16293 2018-02-28 21:33:57Z rudolfkoenig
36_LaCrosse.pm               16168 2018-02-13 21:01:41Z HCS
91_notify.pm                 15937 2018-01-20 13:43:28Z rudolfkoenig
No Id found for 99_on_as_long_as_daylight.pm
No Id found for 99_perfmon.pm
10_pilight_ctrl.pm           16028 2018-01-28 18:34:25Z Risiko
30_pilight_switch.pm         11306 2016-04-24 17:03:16Z risiko79
30_pilight_temp.pm           10506 2016-01-14 20:40:45Z risiko79
59_PROPLANTA.pm              16468 2018-03-22 18:06:34Z tupol
33_readingsGroup.pm          16299 2018-03-01 08:06:55Z justme1968
39_siri.pm                   14044 2017-04-20 07:48:44Z justme1968
98_structure.pm              16293 2018-02-28 21:33:57Z rudolfkoenig
99_SUNRISE_EL.pm             16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm                    16402 2018-03-13 21:14:22Z rudolfkoenig
42_SYSMON.pm                 15910 2018-01-16 23:07:56Z hexenmeister
98_telnet.pm                 16293 2018-02-28 21:33:57Z rudolfkoenig
59_Twilight.pm               16005 2018-01-27 06:05:51Z igami
98_update.pm                 16426 2018-03-17 16:23:45Z rudolfkoenig
99_Utils.pm                  15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm                15140 2017-09-26 09:20:09Z markusbloch
59_Weather.pm                12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm                16293 2018-02-28 21:33:57Z rudolfkoenig
98_WeekdayTimer.pm           16005 2018-01-27 06:05:51Z igami
10_ZWave.pm                  16266 2018-02-25 18:22:51Z rudolfkoenig
00_ZWDongle.pm               16293 2018-02-28 21:33:57Z rudolfkoenig

ABFALL_getEvents.pm          11021 2017-09-13 00:32:22Z uniqueck
ABFALL_setUpdate.pm          11021 2017-09-13 00:32:22Z uniqueck
Blocking.pm                  15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm                     11159 2016-03-30 16:08:06Z justme1968
DevIo.pm                     16329 2018-03-04 20:18:08Z rudolfkoenig
FritzBoxUtils.pm             16344 2018-03-06 21:06:34Z rudolfkoenig
HMConfig.pm                  16265 2018-02-25 18:22:43Z martinp876
No Id found for HMConfig_SenTHPL.pm
HttpUtils.pm                 16407 2018-03-14 19:43:35Z rudolfkoenig
myUtilsTemplate.pm            7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm                    10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm             16211 2018-02-18 11:59:09Z rudolfkoenig
TcpServerUtils.pm            15707 2017-12-27 14:41:21Z rudolfkoenig
YahooWeatherAPI.pm           15742 2018-01-01 07:55:55Z neubert
ZWLib.pm                     15466 2017-11-20 22:22:19Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
svg.js                     15896 2018-01-14 21:35:42Z rudolfkoenig


Ich habe eventuell das Gefühl das es was mit dem Homebridge Modul zusammen hängt?

Ich weiß alles nicht sehr hilfreich

Gruß
Jens
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 29 März 2018, 10:28:55
Zitat von: Burny4600 am 20 März 2018, 13:25:46
Läst sich irgendwie ein automatischer Reboot einrichten bis dieser Fehler gefunden wurde.
Wenn ich alle 24 Stunden einen Autorboot durchführen könnte wäre ich zumindest so weit Sicher das sich das System nicht weghängt.

Das lässt sich über die crontab einfach einrichten.


Z.B.
0 3 * * * sudo reboot

Ich denke es reicht aber einfach schon fhem mit sudo Service fhem restart

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 29 März 2018, 10:32:02
ZitatBtw. mit dem FHEM-Neustart zu warten bis man kein Speicher hat, ist zu spaet: wenn FHEM auf etwa die Haelfte des verfuegbaren Speichers angewachsen ist, wird BlockingCall nicht mehr klappen, weil Linux nicht garantieren kann, dass genug Speicher nach dem fork zur Verfugung steht (stark vereinfacht: fork in BlockingCall dupliziert den alten Prozess).
Genau das kann ich bei mir beobachten. Allerdings verschwinden die duplizierten fhem-Prozesse wieder nach kurzer Zeit.
ZitatIch habe eventuell das Gefühl das es was mit dem Homebridge Modul zusammen hängt?
Homebridge habe ich auch im Einsatz. Werde es mal testweise deaktivieren und schauen.

Ich habe zwischenzeitlich meinen nextcloud Kalender via CALENDAR-Modul deaktiviert. Das Resultat ist leider das gleiche,
lediglich die Zeitspanne verlängert sich um etwa eine Stunde...
VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 29 März 2018, 10:34:57
Zitat von: rudolfkoenig am 29 März 2018, 07:56:42
Btw. mit dem FHEM-Neustart zu warten bis man kein Speicher hat, ist zu spaet: wenn FHEM auf etwa die Haelfte des verfuegbaren Speichers angewachsen ist, wird BlockingCall nicht mehr klappen, weil Linux nicht garantieren kann, dass genug Speicher nach dem fork zur Verfugung steht (stark vereinfacht: fork in BlockingCall dupliziert den alten Prozess).

Bedeutet das, wenn FHEM 100MB belegt und irgendwann 5 BlockingCalls von verschiedenen Modulen aufeinandertreffen, dass dann kurzzeitig 600MB RAM benötigt werden? Was passiert wenn es zu diesem Problem kommt? Bleibt es beim Versuch den Fork zu machen ohne das irgndwas im Speicher zurück bleibt oder crasht dann irgendwas so, das dann der restliche Speicher komplett dicht gemacht wird?

Gibts denn keine Möglichkeit sich den RAM Verbrauch der einzelnen Module irgendwie anzuzeigen? Falls doch was genau müssten die betroffenen Personen machen? Ich für meinen Teil wüsste jetzt nicht auf Anhieb was man hierfür machen müsste: "FHEM mit einem debug-malloc library (valgrind oder dmalloc) starten, um die Stelle einzugrenzen".

PS: Das habe ich auf die Schnelle finden können aber nicht getestet:

sudo apt-get install libtest-valgrind-perl
valgrind --tool=massif --depht=1 --trace-children=yes perl fhem.pl fhem.cfg
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 29 März 2018, 10:35:55
Zitat von: CoolTux am 27 März 2018, 14:14:12
Enno Du könntest eventuell Gold wert sein mein Junge.
Ein schneller Blick über alle Threadeinträge mit version ergab das alle das Modul
96_SIP.pm                15827 2018-01-08 18:36:07Z Wzut
in Verwendung haben die Probleme haben.

Die User welche das so haben sind nun am Zug. Modul deaktivieren oder besser noch erstmal komplett raushauen und testen bitte.

Das Modul wird in meiner fhem Installation nicht genutzt, und trotzdem habe ich das gleiche Problem.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 29 März 2018, 10:46:31
ZitatGibts denn keine Möglichkeit sich den RAM Verbrauch der einzelnen Module irgendwie anzuzeigen?
Ich denke so:
fhemdebug memusage
Sieht bei mir aktuell so aus:
1. defs                            2239018
   2. attr                             351253
   3. modules                          323827
   4. defs::AgrarWetter                257655
   5. defs::AgrarWetter::READINGS      255724
   6. FW_cmdret                        170161
   7. defs::WU_Home                    115415
   8. defs::WU_Home::READINGS          111670
   9. defs::Sonos_Kueche                59881
  10. defs::Sonos_Kueche::READINGS      58230
  11. attr::Wohnung                     57409
  12. defs::FritzBox                    56994
  13. modules::Wunderground             53122
  14. modules::Wunderground::readingsDesc    51614
  15. defs::MeinWetter                  48150
  16. defs::sysmon                      47267
  17. defs::MeinWetter::READINGS        46093
  18. POSIX::                           37247
  19. defs::Daemmerung                  35562
  20. defs::Shuttle.PC                  35177
  21. defs::Muell_Kalender              35126
  22. defs::Dreambox                    34619
  23. defs::rgr_AufderDahl              33805
  24. defs::Shuttle.PC::READINGS        33749
  25. defs::Dreambox::READINGS          33588
  26. defs::Wohnung                     33217
  27. defs::rgr_Kinder                  33114
  28. defs::Spielplatz.PC               32642
  29. defs::sysmon::READINGS            31714
  30. defs::Sonos                       31548
  31. defs::Spielplatz.PC::READINGS     31211
  32. defs::rgr_AufderDahl::READINGS    30920
  33. defs::rgr_Kinder::READINGS        30870
  34. defs::Sonos::READINGS             30504
  35. defs::FritzBox::READINGS          30459
  36. defs::Wohnung::READINGS           28874
  37. defs::WEBapi_10.3.3.40_53916      27113
  38. defs::Muell_Kalender::.fhem       26048
  39. defs::WEBapi_10.3.3.40_53916::inform    25537
  40. defs::WEBapi_10.3.3.40_53916::inform::devices    24854
  41. defs::Astrodaten                  23943
  42. defs::FritzBox::fhem              23922
  43. defs::fhemBot                     23444
  44. B::                               23404
  45. defs::Astrodaten::READINGS        23014
  46. INC                               22289
  47. defs::Muell_Kalender::.fhem::iCalendar    21738
  48. defs::rr_Sebastian                21650
  49. defs::Sonos::READINGS::MusicServicesList    21326
  50. defs::Sonos::READINGS::MusicServicesList::VAL    20993

VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 29 März 2018, 10:59:57
Na das ist doch schon mal was.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 29 März 2018, 11:52:58
ZitatBedeutet das, wenn FHEM 100MB belegt und irgendwann 5 BlockingCalls von verschiedenen Modulen aufeinandertreffen, dass dann kurzzeitig 600MB RAM benötigt werden?
Ja.

ZitatWas passiert wenn es zu diesem Problem kommt?
Erstmal nix, 600MB zu Verbrauchen ist per-se kein Problem, nur wenn man nicht so viel hat. Und dann gibt es beim letzten Fork die im Betreff: zu findende Fehlermeldung. Und der letzte BlockingCall geht schief.

ZitatBleibt es beim Versuch den Fork zu machen ohne das irgndwas im Speicher zurück bleibt oder crasht dann irgendwas so, das dann der restliche Speicher komplett dicht gemacht wird?
Wenn die BlockingCall Prozesse terminieren, dann geben diese den Speicher frei. Der urspruengliche Prozess waechst aber munter weiter. Wenn nichts mehr geht, weil kein Speicher da ist, dann schiesst der Linux-Kernel den groessten Prozess ab.


ZitatGibts denn keine Möglichkeit sich den RAM Verbrauch der einzelnen Module irgendwie anzuzeigen?
Es gibt zwar fhemdebug memusage, das ist aber ungenau, weil es nur "richtige" Perl Variablen zaehlt (z.Bsp. keine Funktionsdefinitionen, usw). Weiterhin vermute ich das Problem nicht an dieser Stelle, sondern in einem der Bibliotheken.

Zitatvalgrind --tool=massif --depht=1 --trace-children=yes perl fhem.pl fhem.cfg
Den Verbrauch der Kinder wuerde ich nicht pruefen (die Ursache sind nicht die, sondern der zuerst gestartete Prozess), aber damit das klappt, muss man "attr global nofork" setzen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 29 März 2018, 15:12:35
Würde gerne weiter testen, allerdings bleibt valgrind direkt nach dem Start stehen:
pi@fhem1:/opt/fhem $ sudo valgrind --tool=massif perl fhem.pl fhem.cfg
==28761== Massif, a heap profiler
==28761== Copyright (C) 2003-2011, and GNU GPL'd, by Nicholas Nethercote
==28761== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==28761== Command: perl fhem.pl fhem.cfg
==28761==
--28761-- WARNING: Serious error when reading debug info
--28761-- When reading debug info from /lib/arm-linux-gnueabihf/ld-2.24.so:
--28761-- Ignoring non-Dwarf2/3/4 block in .debug_info
--28761-- WARNING: Serious error when reading debug info
--28761-- When reading debug info from /lib/arm-linux-gnueabihf/ld-2.24.so:
--28761-- Last block truncated in .debug_info; ignoring
--28761-- WARNING: Serious error when reading debug info
--28761-- When reading debug info from /lib/arm-linux-gnueabihf/libdl-2.24.so:
--28761-- Ignoring non-Dwarf2/3/4 block in .debug_info
--28761-- WARNING: Serious error when reading debug info
--28761-- When reading debug info from /lib/arm-linux-gnueabihf/libdl-2.24.so:
--28761-- Last block truncated in .debug_info; ignoring
--28761-- WARNING: Serious error when reading debug info
--28761-- When reading debug info from /lib/arm-linux-gnueabihf/libm-2.24.so:
--28761-- Ignoring non-Dwarf2/3/4 block in .debug_info
--28761-- WARNING: Serious error when reading debug info
--28761-- When reading debug info from /lib/arm-linux-gnueabihf/libm-2.24.so:
--28761-- Last block truncated in .debug_info; ignoring
Getötet

--depht=1 kennt es übrigens nicht...  ???
VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 29 März 2018, 16:16:17
Hallo,

ich habe zu gestern folgende Module Inaktiv gesetzt.
10_FRM.pm                15941 2018-01-20 21:20:20Z jensb
10_pilight_ctrl.pm       16028 2018-01-28 18:34:25Z Risiko
20_FRM_IN.pm             16012 2018-01-27 20:11:34Z jensb
20_FRM_OUT.pm            15928 2018-01-19 21:07:42Z jensb
21_HEOSMaster.pm         16400 2018-03-13 19:19:38Z CoolTux
21_HEOSPlayer.pm         16400 2018-03-13 19:19:38Z CoolTux
30_pilight_switch.pm     11306 2016-04-24 17:03:16Z risiko79
30_pilight_temp.pm       10506 2016-01-14 20:40:45Z risiko79
73_PRESENCE.pm           16177 2018-02-14 08:58:43Z markusbloch

Gefühlt hat es 1 oder 2 Stunden länger gedauert, bis der Neustart kam. Was mich darauf bringt das ich wahrscheinlich ewig Module ausschließen kann, bis ich die Kombination an Problem Modulen herausgefunden habe...
2 Fragen habe ich noch.

1. Wenn ich fhemdebug memusage ausführe steigt der RAM auch ohne das er wieder freigeben wird!
Normal oder nicht?!

2. Um Module auszuschließen habe ich dies im Fhem Ordner umbenannt. Nach dem 1. Neustart  erhalte ich eine Meldung das Geräte definiert wurden die kein Modul besitzen. So weit auch OK.
Nach dem 2 Neustart (eventuell auch ausgelöst durch den Watchdog) erhalte ich diese Meldung nicht, weil die Zeilen Code in der fhem.cfg fehlen... und muss danach alle Geräte neu anlegen.
Bin ich falsch an die Sachen herangegangen? Oder ist das verhalten so Normal?

Mfg Rico

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 29 März 2018, 16:40:04
Nochwas was ich nicht verstehe.

Ich habe "fhemdebug memusage" mehrfach nach einander ausgeführt.
Mit jedem mal Ausführen steigt der RAM verbrauch um genau 37MB.
Jedoch die Ausgabe von "fhemdebug memusage" steigt/ändert sich nur um wenige Byte.
Versuch 1 - Ram = 567MB - Summe von fhemdebug memusage = 8061491
Versuch 2 - Ram = 604MB - Summe von fhemdebug memusage = 8060671
Versuch 3 - Ram = 567MB - Summe von fhemdebug memusage = 8066781

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 29 März 2018, 16:44:47
Hallo Rico,

Was bringt denn ein

blockinginfo

raus ?

Alternativ kannst du auch ein

get <dbrep> blockinginfo

In einem DbRep-Device benutzen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 29 März 2018, 17:29:03
dies zeigt mir Aktuell nur das.
Pid:20173 Fn:SIP_ListenStart Arg:Raspifon Timeout:N/A ConnectedVia:N/A
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 29 März 2018, 17:57:53
habe nach einer Anleitung im Netz zur Auswertung von RAM diesen Befehl ausgeführt (vor und nach einem fhemdebug memusage)
die erste Adresse steigt wieder im Verbrauch.
sudo pmap -d <pid von fhem>

Ergebnis ...vorher
19892: perl f hem.pl fhem.cfg
Address Kbytes Mode Offset Device Mapping
mapped: 256152K wri teable/private: 2 37680K shared: 32K
783000      218656 rw--- 0 000:00000 [ anon ]
7548c000 8188 rwx-- 0 000:00000 [ anon ]
000c4000 6908 rw--- 0 000:00000 [ anon ]
75d94000 2584 r-x-- 0 0b3:00007 libmysqlclient.so.18.0.0
76963000 1572 r---- 0 0b3:00007 locale-archive
76d22000 1520 r-x-- 0 0b3:00007 libperl.so.5.20.2
7629c000 1300 r-x-- 0 0b3:00007 libcrypto.so.1.0.0
74ec4000 1236 rw--- 0 000:00000 [ anon ]
76b2b000 1196 r-x-- 0 0b3:00007 libc-2.19.so

nach her
19892: perl fh em.pl fhem.cfg
Address Kbytes Mode Offset Device Mapping
mapped: 294484K wri teable/private: 2 76012K shared: 32K
783000   256444 rw--- 0 000:00000 [ anon ]
7548c000 8188 rwx-- 0 000:00000 [ anon ]
000c4000 6908 rw--- 0 000:00000 [ anon ]
75d94000 2584 r-x-- 0 0b3:00007 libmysqlclient.so.18.0.0
74ec4000 1780 rw--- 0 000:00000 [ anon ]
76963000 1572 r---- 0 0b3:00007 locale-archive
76d22000 1520 r-x-- 0 0b3:00007 libperl.so.5.20.2
7629c000 1300 r-x-- 0 0b3:00007 libcrypto.so.1.0.0
76b2b000 1196 r-x-- 0 0b3:00007 libc-2.19.so

vielleicht sagt es ja jemandem von euch etwas?! :o
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 29 März 2018, 22:45:43
Ich bin mit meiner Konfiguration jetzt auf einem Intel NUC 7 mit installierten Ubuntu umgestiegen....Bis jetzt habe ich keine Probleme mehr mit dem schrumpfenden Speicher..... klar ich habe jetzt mehr zur Verfügung... aber eine Tendenz nach unten konnte ich bis jetzt nicht erkennen....


Gesendet von iPhone mit Tapatalk
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 29 März 2018, 22:52:11
Mit
sudo pmap -d <fhem pid>
sehe ich nur diesen Eintrag signifikant anwachsen:
02833000  366372 rw--- 0000000000000000 000:00000   [ anon ]
Schade nur dass er sich nicht zu erkennen gibt...  :o
VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 30 März 2018, 09:54:58
Zitatsehe ich nur diesen Eintrag signifikant anwachsen:
Ist genau das, was mit "cat /proc/<fhem-pid>/status" zu sehen ist (s.o.), da mit etwas sprechenderen Namen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 30 März 2018, 10:11:38
UPDATE:
Mit perl 5.26.1 aus debian buster steigt der Speicherverbrauch auch kontiniuierlich an...

Nebenbei ein paar Nebeneffekte mit MQTT:
2018.03.30 08:52:13 1: reload: Error:Modul 00_MQTT deactivated:
Can't locate Module/Pluggable.pm in @INC (you may need to install the Module::Pluggable module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.26.1 /usr/local/share/perl/5.26.1 /usr/lib/arm-linux-gnueabihf/perl5/5.26 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at FHEM/lib/Net/MQTT/Message.pm line 9, <$fh> line 2556.
BEGIN failed--compilation aborted at FHEM/lib/Net/MQTT/Message.pm line 9, <$fh> line 2556.
Compilation failed in require at ./FHEM/00_MQTT.pm line 78, <$fh> line 2556.
BEGIN failed--compilation aborted at ./FHEM/00_MQTT.pm line 78, <$fh> line 2556.
2018.03.30 08:52:13 0: Can't locate Module/Pluggable.pm in @INC (you may need to install the Module::Pluggable module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.26.1 /usr/local/share/perl/5.26.1 /usr/lib/arm-linux-gnueabihf/perl5/5.26 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at FHEM/lib/Net/MQTT/Message.pm line 9, <$fh> line 2556.
BEGIN failed--compilation aborted at FHEM/lib/Net/MQTT/Message.pm line 9, <$fh> line 2556.
Compilation failed in require at ./FHEM/00_MQTT.pm line 78, <$fh> line 2556.
BEGIN failed--compilation aborted at ./FHEM/00_MQTT.pm line 78, <$fh> line 2556.
2018.03.30 08:52:13 1: PERL WARNING: "all" is not defined in %MQTT::EXPORT_TAGS at ./FHEM/10_MQTT_DEVICE.pm line 85.
2018.03.30 08:52:13 1: reload: Error:Modul 10_MQTT_DEVICE deactivated:
Can't continue after import errors at ./FHEM/10_MQTT_DEVICE.pm line 71.
BEGIN failed--compilation aborted at ./FHEM/10_MQTT_DEVICE.pm line 85, <$fh> line 2569.
2018.03.30 08:52:13 0: Can't continue after import errors at ./FHEM/10_MQTT_DEVICE.pm line 71.
BEGIN failed--compilation aborted at ./FHEM/10_MQTT_DEVICE.pm line 85, <$fh> line 2569.
2018.03.30 08:52:13 1: PERL WARNING: Subroutine cttorgb redefined at ./FHEM/31_Aurora.pm line 534, <$fh> line 3133.
2018.03.30 08:52:13 1: PERL WARNING: Subroutine xyYtorgb redefined at ./FHEM/31_Aurora.pm line 571, <$fh> line 3133.
2018.03.30 08:52:14 1: PERL WARNING: Subroutine main::Log3 redefined at ./FHEM/98_freezemon.pm line 823, <$fh> line 3717.
2018.03.30 08:52:14 1: PERL WARNING: Subroutine MQTT_DEVICE_Initialize redefined at ./FHEM/10_MQTT_DEVICE.pm line 34, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_UNSUBSCRIBE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_QOS_AT_MOST_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNECT_REFUSED_BAD_USER_NAME_OR_PASSWORD redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNECT_ACCEPTED redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_PUBREC redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNECT_REFUSED_IDENTIFIER_REJECTED redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_QOS_AT_LEAST_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_PUBCOMP redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_PUBREL redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_PINGRESP redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_SUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_QOS_EXACTLY_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_UNSUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_PINGREQ redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNECT_REFUSED_NOT_AUTHORIZED redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_PUBLISH redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNECT_REFUSED_SERVER_UNAVAILABLE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_SUBSCRIBE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_PUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNECT redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_DISCONNECT redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNECT_REFUSED_UNACCEPTABLE_PROTOCOL_VERSION redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 3894.
2018.03.30 08:52:14 1: reload: Error:Modul 10_MQTT_DEVICE deactivated:
Can't continue after import errors at ./FHEM/10_MQTT_DEVICE.pm line 71.
BEGIN failed--compilation aborted at ./FHEM/10_MQTT_DEVICE.pm line 85, <$fh> line 3894.
2018.03.30 08:52:14 0: Can't continue after import errors at ./FHEM/10_MQTT_DEVICE.pm line 71.
BEGIN failed--compilation aborted at ./FHEM/10_MQTT_DEVICE.pm line 85, <$fh> line 3894.
2018.03.30 08:52:21 0: Featurelevel: 5.8
2018.03.30 08:52:21 0: Server started with 305 defined entities (fhem.pl:16453/2018-03-20 perl:5.026001 os:linux user:fhem pid:553)

Downgrade wieder auf 5.24.1...
VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 30 März 2018, 21:10:39
Habe meine gesamte fhem.cfg auf nen Raspi 3 kopiert.
Was nicht mit umgezogen ist, weil nicht angeschlossen oder eingerichtet...
Cunx(HM),Nanocul(HM),Jeelink,Cul433(IT),Modbusline, DBLog und jeglicher zugriff aufs NAS...(Fritzbox Modul bringt "Didn't get a session ID")

aber der Rest läuft und der RAM steigt nicht!!!
Der Test läuft aber erst seit 1-2 Stunden...

gibt es irgendwelche gemeinsamen CODE schnipsel in myutils?
myutils.pm
##############################################
# $Id: myUtilsTemplate.pm 7570 2015-01-14 18:31:44Z rudolfkoenig $
#
# Save this file as 99_myUtils.pm, and create your own functions in the new
# file. They are then available in every Perl expression.

package main;

use strict;
use warnings;
use POSIX;

#sub
#myUtils_Initialize($$)
#{
#  my ($hash) = @_;
#}

# Enter you functions below _this_ line.
########watchdog Heartbeat
# --- Liefert aktueller Zeitstempel ---
sub CurrentTime()
{
  return strftime("%H:%M:%S", localtime());
}

# --- server heartbeat / watchdog ---
sub tickHeartbeat($)
{
    my ($device) = @_;
    my $v = int(Value($device));
    $v = $v+1;
    if($v>=60) {$v=0;}
    fhem("set $device $v");
}
########watchdog Heartbeat ende
###############Notify repeat
sub
myUtils_Initialize($$)
{
my ($hash) = @_;
my $NewMailtime = time;
my $NewMailtime2 = time;
}
##############Notify repeat ende
########watchdog 2
sub fhem_not()
{
Wd_exec();
# alte watchdogs vorsichtshalber löschen
my $ret = `ps | grep watchdog.pl`;
my @lines = split("\n",$ret);
my @retval;
foreach my $l (@lines)
{
if($l =~m/.*perl watchdog.pl.*/)
{
my ($wpid) = split(' ',$l);
push(@retval,"killed: ".$l);
$l = `kill -9 $wpid`;
} # if watchdog
} # end foreach
Log(1,join("\n",@retval));
# und neu starten

system("./startwatchdog&");
} # end sub fhem_not

sub Wd_exec()
{
my $filename = ">./watchdog.log";
my $pid = getpid();
if (open (WATCHDOGFILE,$filename))
{
printf (WATCHDOGFILE "%d\t%d\n%s",time(),$pid,TimeNow());
close WATCHDOGFILE;
}
return undef;
} # end sub Wd_exec
########watchdog 2 ende
######## DebianMail  Mail auf dem RPi versenden ############
sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $attach = shift;
my $ret = "";
my $sender = "fhem\@unserhaus.biz";
my $konto = "m039bff3";
#my $konto = "fhem\@unserhaus.biz";
my $passwrd = "Mrbaron1";
my $provider = "w006802d.kasserver.com:587";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";
Log 1, "sendEmail Anhang: $attach";;

$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=auto -o message-charset=utf-8);
$ret =~ s,[\r\n]*,,g;    # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}
###############################################################################
# Markus1407, 2017-12-06
#
# splits a string by given value and retrun the choosen element, index [0,1,...]
#
# splitAndReturnElement($stringToSplit,$splitByValue,$returnIndex)
# splitAndReturnElement("This is some string to split", " ", 2)  -> returns "some"
#
# http://rextester.com/l/perl_online_compiler
###############################################################################
sub splitAndReturnElement($$$){
   my ($stringToSplit,$splitByValue,$returnIndex) = @_;
   my @splittedValues = split("$splitByValue", "$stringToSplit");
   
   if (exists $splittedValues[$returnIndex])
   {
       return $splittedValues[$returnIndex];
   }
   else
   {   # index does not exist
       return "0";
   }
}
# Enter you functions below _this_ line.

1;

Außerdem nutze ich noch Backup.sh und 99_myUtilsHeatPump.pm...

MFG Rico
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 30 März 2018, 23:05:23
@Rico: kannst du bitte auf beiden Maschinen version ausfuehren, und das Ergebnis uns zeigen?

Kann bitte jemand auf einer Problem-Maschine "perl fhem.pl fhem.cfg.test" mit folgende Konfiguration:
attr global logfile -
attr global modpath .
attr global verbose 3

{ use HttpUtils }
{ use Blocking }

define at1 at +*00:00:01 { HttpUtils_NonblockingGet({ url=>"http://fhem.de/MAINTAINER.txt", callback=>sub($$$){ Log 1,"ERR:$_[1] DATA:".length($_[2]) } }) }
define at2 at +*00:00:01 { BlockingCall(sub(){sleep(10);; Log 1, "Sleep done"}, undef);; undef }

in einem Terminal fuer ca 10 Minuten ausfuehren, und sowohl direkt nach dem Start, wie auch kurz vor Abbruch (mit Ctrl-C) in einem anderen Terminal "grep VmData /proc/fhem-pid/status" ausfuehren, und das Ergebnis hier zeigen?

Ich bekomme in einem Ubuntu-VM mit perl 5.18 "VmData: 16360 kB", und mit perl 5.26 "VmData: 16932 kB", ein Wachstum ist nicht zu sehen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 31 März 2018, 06:47:39
Moin an alle die auch nicht schlafen können... ;)

Raspi2 (Problemkind)
version
Latest Revision: 16504

File                     Rev   Last Change

fhem.pl                  16453 2018-03-20 21:15:44Z rudolfkoenig
96_allowed.pm            16295 2018-02-28 22:11:09Z rudolfkoenig
90_at.pm                 15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm         15620 2017-12-16 18:10:36Z rudolfkoenig
00_CUL.pm                15027 2017-09-08 09:11:43Z rudolfkoenig
10_CUL_HM.pm             16258 2018-02-24 22:11:14Z martinp876
No Id found for 14_CUL_REDIRECT.pm
14_CUL_TCM97001.pm       16274 2018-02-25 20:42:39Z bjoernh
14_CUL_TX.pm             14784 2017-07-25 15:06:43Z rudolfkoenig
14_CUL_WS.pm             15603 2017-12-13 20:53:47Z rudolfkoenig
95_Dashboard.pm          12251 2016-10-03 09:45:43Z talkabout
93_DbLog.pm              16423 2018-03-17 07:28:59Z DS_Starter
93_DbRep.pm              16475 2018-03-24 15:09:48Z DS_Starter
70_DENON_AVR.pm             10 2018-03-18 00:00:00Z raman
71_DENON_AVR_ZONE.pm        10 2017-03-21 00:00:00Z raman
98_DLNARenderer.pm       15836 2018-01-09 21:01:49Z dominik
98_DOIF.pm               16481 2018-03-25 09:10:27Z Damian
98_dummy.pm              12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm         14888 2017-08-13 12:07:12Z rudolfkoenig
72_FB_CALLLIST.pm        16433 2018-03-18 08:20:35Z markusbloch
72_FB_CALLMONITOR.pm     16504 2018-03-28 15:53:55Z markusbloch
93_FHEM2FHEM.pm          15006 2017-09-05 09:37:33Z rudolfkoenig
01_FHEMWEB.pm            16407 2018-03-14 19:43:35Z rudolfkoenig
92_FileLog.pm            15874 2018-01-13 17:16:33Z rudolfkoenig
98_freezemon.pm          16411 2018-03-14 22:22:14Z KernSani
72_FRITZBOX.pm           16461 2018-03-21 18:26:03Z tupol
10_FRM.pm                15941 2018-01-20 21:20:20Z jensb
20_FRM_IN.pm             16012 2018-01-27 20:11:34Z jensb
20_FRM_OUT.pm            15928 2018-01-19 21:07:42Z jensb
No Id found for 98_gcmsend.pm
21_HEOSMaster.pm         16400 2018-03-13 19:19:38Z CoolTux
21_HEOSPlayer.pm         16400 2018-03-13 19:19:38Z CoolTux
14_Hideki.pm             15450 2017-11-18 21:34:47Z Sidey
98_HMinfo.pm             16421 2018-03-17 06:15:49Z martinp876
98_HTTPMOD.pm            16216 2018-02-18 15:26:11Z StefanStrobel
49_IPCAM.pm               2626 2013-02-01 19:19:15Z mfr69bs
10_IT.pm                 14852 2017-08-06 08:48:24Z bjoernh
36_JeeLink.pm            14707 2017-07-13 18:08:33Z justme1968
36_LaCrosse.pm           16168 2018-02-13 21:01:41Z HCS
98_Modbus.pm             15871 2018-01-13 16:24:22Z StefanStrobel
37_ModbusRegister.pm        24 2018-02-06 21:22:00Z CD
No Id found for 98_ModbusRTUDimplexHP.pm
No Id found for 98_ModbusRTUDimplexZL.pm
# $Id: 36_ModbusTCPServer.pm 0021 $
No Id found for 99_myUtilsHeatPump.pm
91_notify.pm             15937 2018-01-20 13:43:28Z rudolfkoenig
41_OREGON.pm             12928 2017-01-02 00:23:46Z Sidey
10_pilight_ctrl.pm       16028 2018-01-28 18:34:25Z Risiko
30_pilight_smoke.pm      11733 2016-07-03 13:05:19Z risiko79
30_pilight_switch.pm     11306 2016-04-24 17:03:16Z risiko79
30_pilight_temp.pm       10506 2016-01-14 20:40:45Z risiko79
73_PRESENCE.pm           16177 2018-02-14 08:58:43Z markusbloch
70_Pushbullet.pm          9730 2015-10-30 15:06:41Z fhainz
33_readingsGroup.pm      16299 2018-03-01 08:06:55Z justme1968
95_remotecontrol.pm      10724 2016-02-04 18:17:33Z ulimaass
00_RPII2C.pm             15021 2017-09-06 19:48:55Z klausw
96_SIP.pm                15827 2018-01-08 18:36:07Z Wzut
98_statistics.pm         16438 2018-03-18 18:51:57Z tupol
70_STV.pm                12857 2016-12-21 11:59:33Z Zwiebel
99_SUNRISE_EL.pm         16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm                16402 2018-03-13 21:14:22Z rudolfkoenig
42_SYSMON.pm             15910 2018-01-16 23:07:56Z hexenmeister
32_SYSSTAT.pm            10567 2016-01-18 21:34:09Z justme1968
98_telnet.pm             16293 2018-02-28 21:33:57Z rudolfkoenig
59_Twilight.pm           16005 2018-01-27 06:05:51Z igami
10_UNIRoll.pm            12819 2016-12-18 14:27:48Z C_Herrmann
99_Utils.pm              15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm            15140 2017-09-26 09:20:09Z markusbloch
59_Weather.pm            12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm            16293 2018-02-28 21:33:57Z rudolfkoenig
32_WifiLight.pm          15907 2018-01-16 20:58:44Z herrmannj
98_XmlList.pm            13128 2017-01-17 21:40:09Z rudolfkoenig

No Id found for Base.pm
Blocking.pm              15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm                 11159 2016-03-30 16:08:06Z justme1968
Common.pm                10759 2016-02-07 20:00:12Z rleins
No Id found for Constants.pm
ControlPoint.pm          15823 2018-01-07 22:42:45Z Reinerlein
DevIo.pm                 16329 2018-03-04 20:18:08Z rudolfkoenig
No Id found for Firmata.pm
FritzBoxUtils.pm         16344 2018-03-06 21:06:34Z rudolfkoenig
GPUtils.pm                6653 2014-10-02 11:59:37Z ntruchsess
HMConfig.pm              16265 2018-02-25 18:22:43Z martinp876
HttpUtils.pm             16407 2018-03-14 19:43:35Z rudolfkoenig
myUtilsTemplate.pm        7570 2015-01-14 18:31:44Z rudolfkoenig
No Id found for Platform.pm
No Id found for Protocol.pm
RTypes.pm                10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm         16211 2018-02-18 11:59:09Z rudolfkoenig
TcpServerUtils.pm        15707 2017-12-27 14:41:21Z rudolfkoenig
YahooWeatherAPI.pm       15742 2018-01-01 07:55:55Z neubert

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
svg.js                     15896 2018-01-14 21:35:42Z rudolfkoenig


Raspi3 (ohne Probleme)
Latest Revision: 16504

File                  Rev   Last Change

fhem.pl               16453 2018-03-20 21:15:44Z rudolfkoenig
96_allowed.pm         16295 2018-02-28 22:11:09Z rudolfkoenig
90_at.pm              15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm      15620 2017-12-16 18:10:36Z rudolfkoenig
00_CUL.pm             15027 2017-09-08 09:11:43Z rudolfkoenig
10_CUL_HM.pm          16258 2018-02-24 22:11:14Z martinp876
14_CUL_TCM97001.pm    16274 2018-02-25 20:42:39Z bjoernh
14_CUL_TX.pm          14784 2017-07-25 15:06:43Z rudolfkoenig
14_CUL_WS.pm          15603 2017-12-13 20:53:47Z rudolfkoenig
95_Dashboard.pm       12251 2016-10-03 09:45:43Z talkabout
93_DbRep.pm           16475 2018-03-24 15:09:48Z DS_Starter
No Id found for 71_DENON_AVR.pm
98_DLNARenderer.pm    15836 2018-01-09 21:01:49Z dominik
98_DOIF.pm            16481 2018-03-25 09:10:27Z Damian
98_dummy.pm           12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm      14888 2017-08-13 12:07:12Z rudolfkoenig
72_FB_CALLLIST.pm     16433 2018-03-18 08:20:35Z markusbloch
72_FB_CALLMONITOR.pm  16504 2018-03-28 15:53:55Z markusbloch
93_FHEM2FHEM.pm       15006 2017-09-05 09:37:33Z rudolfkoenig
98_fhemdebug.pm       16056 2018-01-31 13:12:54Z rudolfkoenig
01_FHEMWEB.pm         16407 2018-03-14 19:43:35Z rudolfkoenig
92_FileLog.pm         15874 2018-01-13 17:16:33Z rudolfkoenig
98_freezemon.pm       16411 2018-03-14 22:22:14Z KernSani
72_FRITZBOX.pm        16461 2018-03-21 18:26:03Z tupol
10_FRM.pm             15941 2018-01-20 21:20:20Z jensb
20_FRM_IN.pm          16012 2018-01-27 20:11:34Z jensb
20_FRM_OUT.pm         15928 2018-01-19 21:07:42Z jensb
98_help.pm            15223 2017-10-10 10:14:24Z betateilchen
21_HEOSMaster.pm      16400 2018-03-13 19:19:38Z CoolTux
21_HEOSPlayer.pm      16400 2018-03-13 19:19:38Z CoolTux
98_HMinfo.pm          16421 2018-03-17 06:15:49Z martinp876
98_HTTPMOD.pm         16216 2018-02-18 15:26:11Z StefanStrobel
49_IPCAM.pm            2626 2013-02-01 19:19:15Z mfr69bs
10_IT.pm              14852 2017-08-06 08:48:24Z bjoernh
36_JeeLink.pm         14707 2017-07-13 18:08:33Z justme1968
36_LaCrosse.pm        16168 2018-02-13 21:01:41Z HCS
98_Modbus.pm          15871 2018-01-13 16:24:22Z StefanStrobel
37_ModbusRegister.pm     24 2018-02-06 21:22:00Z CD
# $Id: 36_ModbusTCPServer.pm 0021 $
91_notify.pm          15937 2018-01-20 13:43:28Z rudolfkoenig
30_pilight_smoke.pm   11733 2016-07-03 13:05:19Z risiko79
30_pilight_switch.pm  11306 2016-04-24 17:03:16Z risiko79
73_PRESENCE.pm        16177 2018-02-14 08:58:43Z markusbloch
70_Pushbullet.pm       9730 2015-10-30 15:06:41Z fhainz
33_readingsGroup.pm   16299 2018-03-01 08:06:55Z justme1968
95_remotecontrol.pm   10724 2016-02-04 18:17:33Z ulimaass
98_statistics.pm      16438 2018-03-18 18:51:57Z tupol
70_STV.pm             12857 2016-12-21 11:59:33Z Zwiebel
99_SUNRISE_EL.pm      16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm             16402 2018-03-13 21:14:22Z rudolfkoenig
42_SYSMON.pm          15910 2018-01-16 23:07:56Z hexenmeister
32_SYSSTAT.pm         10567 2016-01-18 21:34:09Z justme1968
98_telnet.pm          16293 2018-02-28 21:33:57Z rudolfkoenig
59_Twilight.pm        16005 2018-01-27 06:05:51Z igami
99_Utils.pm           15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm         15140 2017-09-26 09:20:09Z markusbloch
59_Weather.pm         12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm         16293 2018-02-28 21:33:57Z rudolfkoenig
32_WifiLight.pm       15907 2018-01-16 20:58:44Z herrmannj

No Id found for Base.pm
Blocking.pm           15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm              11159 2016-03-30 16:08:06Z justme1968
Common.pm             10759 2016-02-07 20:00:12Z rleins
No Id found for Constants.pm
ControlPoint.pm       15823 2018-01-07 22:42:45Z Reinerlein
DevIo.pm              16329 2018-03-04 20:18:08Z rudolfkoenig
No Id found for Firmata.pm
FritzBoxUtils.pm      16344 2018-03-06 21:06:34Z rudolfkoenig
GPUtils.pm             6653 2014-10-02 11:59:37Z ntruchsess
HMConfig.pm           16265 2018-02-25 18:22:43Z martinp876
HttpUtils.pm          16407 2018-03-14 19:43:35Z rudolfkoenig
No Id found for Platform.pm
No Id found for Protocol.pm
RTypes.pm             10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm      16211 2018-02-18 11:59:09Z rudolfkoenig
TcpServerUtils.pm     15707 2017-12-27 14:41:21Z rudolfkoenig
YahooWeatherAPI.pm    15742 2018-01-01 07:55:55Z neubert

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
svg.js                     15896 2018-01-14 21:35:42Z rudolfkoenig



Auswertung dauert aber noch ein bissl.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 31 März 2018, 09:07:52
ZitatIch bekomme in einem Ubuntu-VM mit perl 5.18 "VmData: 16360 kB", und mit perl 5.26 "VmData: 16932 kB", ein Wachstum ist nicht zu sehen.
Moin Rudi,
bei mir ist auch kein Anstieg zu verzeichnen: Mit perl 5.24.1 bleibt der Speicher nach 10 Minuten mit "VmData: 10464 kB" unverändert.

EDIT: Auch Mit perl 5.26.1 bleibt der Speicher nach 10 Minuten mit "VmData: 23228 kB" unverändert.

VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 01 April 2018, 08:48:23
hallo ,

ich erhalte folgende Meldung auf perl fhem.pl fhem.cfg.test fortlaufend (ausgeführt unter user pi)
2018.04.01 08:45:57 1: Sleep done
2018.04.01 08:45:57 1: ERR: DATA:36835

und das Ergebnis von grep
VmData:    10052 kB

ist immer gleich.

nach einem kopieren der fhem.cfg auf einen Ersatz-Pi dachte ich dort geht alles soweit jedoch hat es hier nur länger gedauert....

Könnte jemand bitte noch die Aussage bestätigen das auf einem Problem-System bei mehrmaliger Nutzung von "fhemdebug memusage" der RAM-Verbrauch immer weiter steigt und auf einem "Gesunden-System" nur einmal...

Damit könnte man Problem Module schneller finden, da man nicht einen halben Tag auf RAM anstieg warten muß.

MFG Rico
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 01 April 2018, 09:14:45
@Rico/@Sebastian: stimmt das, dass die fhem.cfg.test Experimente auf dem "Problem-Server" ausgefuehrt wurden? Wenn ja, dann sind die beiden Bibliotheken HttpUtils und Blocking vermutlich nicht an dem Problem schuld.

ZitatKönnte jemand bitte noch die Aussage bestätigen das auf einem Problem-System bei mehrmaliger Nutzung von "fhemdebug memusage" der RAM-Verbrauch immer weiter steigt und auf einem "Gesunden-System" nur einmal...
Ich gehe davon aus, dass diese Aussage nicht stimmt, sonst koennten wir relativ einfach lokalisieren, welche Stelle waechst. Ich meine mich zu erinnern, dass "Beweise" auch in diesem Thema zu finden sind, man muss diese nur suchen, und dazu sind wir beide zu faul :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 01 April 2018, 09:38:22
Zitat@Rico/@Sebastian: stimmt das, dass die fhem.cfg.test Experimente auf dem "Problem-Server" ausgefuehrt wurden?
Ja das wurde immer auf dem Problem-Server durchgeführt.
ZitatWenn ja, dann sind die beiden Bibliotheken HttpUtils und Blocking vermutlich nicht an dem Problem schuld.
Davon ist auszugehen. Die Werte haben sich im Testzeitraum 10 Min+ nie verändert...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 01 April 2018, 10:31:59
Hallo,

irgendwie ist der ganze Fehler sehr mysteriös.
Auch ich hatte die gleichen Speicherprobleme auf meinem Raspi, doch seit ca. 14 Tagen kommt der Fehler nicht mehr.
Das einzige was ich getan habe war, ich habe Freezemon und das damit aufgerufene apptime von meinem System entfernt und dafür Perfmon installiert. Zusätzlich habe ich noch ein notify erstellt, damit Fhem bei der "cannot fork.." Meldung neu gestartet wird (werde es umstellen bei zu wenig Speicher auf kompletten Raspi Neustart).
Mein Linux System versuche ich immer aktuell zu halten und aktualisiere dies wenn möglich alle 1-2 Wochen, Fhem dagegen 1-2 mal wöchentlich. Weitere Module weder Perl noch Fhem habe ich nicht geändert!

Latest Revision: 16516

File                  Rev   Last Change

fhem.pl               16453 2018-03-20 21:15:44Z rudolfkoenig
57_ABFALL.pm          11020 2017-09-13 00:40:21Z uniqueck
96_allowed.pm         16295 2018-02-28 22:11:09Z rudolfkoenig
90_at.pm              15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm      15620 2017-12-16 18:10:36Z rudolfkoenig
57_Calendar.pm        15612 2017-12-15 09:26:59Z neubert
00_CUL.pm             15027 2017-09-08 09:11:43Z rudolfkoenig
10_CUL_HM.pm          16258 2018-02-24 22:11:14Z martinp876
93_DbLog.pm           16423 2018-03-17 07:28:59Z DS_Starter
93_DbRep.pm           16475 2018-03-24 15:09:48Z DS_Starter
98_DOIF.pm            16481 2018-03-25 09:10:27Z Damian
98_dummy.pm           12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm      14888 2017-08-13 12:07:12Z rudolfkoenig
00_FBAHAHTTP.pm       16344 2018-03-06 21:06:34Z rudolfkoenig
10_FBDECT.pm          16441 2018-03-18 21:39:08Z rudolfkoenig
98_fhemdebug.pm       16056 2018-01-31 13:12:54Z rudolfkoenig
01_FHEMWEB.pm         16407 2018-03-14 19:43:35Z rudolfkoenig
92_FileLog.pm         15874 2018-01-13 17:16:33Z rudolfkoenig
88_HMCCU.pm           16500 2018-03-27 08:07:03Z zap
88_HMCCUDEV.pm        16500 2018-03-27 08:07:03Z zap
88_HMCCURPCPROC.pm    16165 2018-02-13 10:55:01Z zap
98_HTTPMOD.pm         16216 2018-02-18 15:26:11Z StefanStrobel
02_HTTPSRV.pm         13976 2017-04-12 13:35:44Z neubert
98_JsonList2.pm       16293 2018-02-28 21:33:57Z rudolfkoenig
37_ModbusCoil.pm         14 2017-01-14 16:46:00Z ChrisD
37_ModbusRegister.pm     24 2018-02-06 21:22:00Z CD
# $Id: 36_ModbusTCPServer.pm 0021 $
91_notify.pm          15937 2018-01-20 13:43:28Z rudolfkoenig
No Id found for 99_perfmon.pm
59_PROPLANTA.pm       16468 2018-03-22 18:06:34Z tupol
70_Pushover.pm        16358 2018-03-09 09:58:05Z loredo
33_readingsGroup.pm   16299 2018-03-01 08:06:55Z justme1968
96_SIP.pm             15827 2018-01-08 18:36:07Z Wzut
99_SUNRISE_EL.pm      16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm             16402 2018-03-13 21:14:22Z rudolfkoenig
42_SYSMON.pm          15910 2018-01-16 23:07:56Z hexenmeister
98_telnet.pm          16293 2018-02-28 21:33:57Z rudolfkoenig
98_Text2Speech.pm     13704 2017-03-14 19:33:42Z Tobias.Faust
99_Utils.pm           15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm         15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm         16293 2018-02-28 21:33:57Z rudolfkoenig

ABFALL_getEvents.pm   11021 2017-09-13 00:32:22Z uniqueck
ABFALL_setUpdate.pm   11021 2017-09-13 00:32:22Z uniqueck
Blocking.pm           15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm              11159 2016-03-30 16:08:06Z justme1968
DevIo.pm              16329 2018-03-04 20:18:08Z rudolfkoenig
FritzBoxUtils.pm      16344 2018-03-06 21:06:34Z rudolfkoenig
HMCCUConf.pm          16500 2018-03-27 08:07:03Z zap
HMConfig.pm           16265 2018-02-25 18:22:43Z martinp876
HttpUtils.pm          16407 2018-03-14 19:43:35Z rudolfkoenig
Info.pm                  28 2008-11-09 01:08:44Z dsully
myUtilsTemplate.pm     7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm             10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm      16211 2018-02-18 11:59:09Z rudolfkoenig
SubProcess.pm         14334 2017-05-20 23:11:06Z neubert
TcpServerUtils.pm     15707 2017-12-27 14:41:21Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968



Ich bin zwar froh, dass der Fehler bei mir nicht mehr auftaucht, dies hilft aber euch sicherlich nicht sehr weiter, wollte diese Erkenntnisse doch in die Runde geben.

Wenn ich mit meinem System noch irgend etwas testen sollte, was euch ggf. weiterhilft so gebt mir bitte Bescheid, ich will mich ja nicht nur zurücklehnen und abwarten bis andere für mich "die heißen Kohlen aus dem Feuer holen".

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 01 April 2018, 14:35:13
ZitatDas einzige was ich getan habe war, ich habe Freezemon und das damit aufgerufene apptime von meinem System entfernt und dafür Perfmon installiert.

Will mich nicht zu früh freuen, aber seit 3 Stunden keine RAM anstieg....
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 01 April 2018, 14:50:33
ZitatDas einzige was ich getan habe war, ich habe Freezemon und das damit aufgerufene apptime von meinem System entfernt und dafür Perfmon installiert.
Hier auch! Ich hatte vorher freezemon nur mit "set inactive" bzw. "disable 1" stillgelegt. Jetzt komplett gelöscht und fhem-Neustart durchgeführt.
VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 01 April 2018, 14:54:08
Hatte es auch nur mit "set inactive" bzw. "disable 1" stillgelegt....

Ich dachte auch das das reicht?!
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 01 April 2018, 15:25:48
Diejenigen welche apptime am laufen haben, haben diese auch AMAD Devices? Es gab da vor einem Jahr mal Probleme mit apptime und AMAD.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 01 April 2018, 15:39:02
Hallo,

ich wollte eigentlich nur meine Erfahrungen mit dem Fehler bei mir mitteilen, ob die Ursache tatsächlich bei den beiden Programmen liegt, dies kann ich mangels Linux Kenntnissen nicht beurteilen. Sollte es natürlich tatsächlich so sein, dass sich durch entfernen der beiden Programme das Verhalten bessert, so sind die Profis gefragt.

Freut euch bitte nicht zu früh :-\

Ich meine immer noch mein zur Verfügung stehender Speicher bewegt sich am absoluten Minimum und es ist nur eine Frage der Zeit, bis der Fehler wiederkommt. Ich beobachte eine kontinuierliche Abnahme meines swap Speichers immer nach einigen Tagen (siehe Bild im Anhang, am 25.03. und 31.03 hatte ich den Raspi neu gestartet. Ich verfolge die Diskussion nun schon seit Wochen, doch ich bin mir immer noch unsicher, wie ich eigentlich korrekt den freien Speicher unter Linux berechnen kann.

pi@raspberrypi:~ $ free -m -t
              total        used        free      shared  buff/cache   available
Mem:            927         362          53           1         511         509
Swap:            99          15          84
Total:         1027         378         137


Wären demnach bei mir derzeit 646 MB Speicher frei? (MEM 53 + Swap 84 + buff/cache + 509)
Oder sehe ich da etwas grundlegend falsch?

@CoolTux:
AMAD habe und kenne ich nicht!

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 01 April 2018, 16:06:17
Ich nutze AMAD auch nicht.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 01 April 2018, 16:10:49
Danke euch. Nehme ich so mit.
AMAD ist zum auslesen und steuern von Androidgeräten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 01 April 2018, 16:12:12
Zitat von: CoolTux am 01 April 2018, 15:25:48
Diejenigen welche apptime am laufen haben, haben diese auch AMAD Devices? Es gab da vor einem Jahr mal Probleme mit apptime und AMAD.
Ich nutze AMAD.
VG Sebastian


Gesendet von iPad mit Tapatalk
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 01 April 2018, 16:15:43
Zitat von: binford6000 am 01 April 2018, 16:12:12
Ich nutze AMAD.
VG Sebastian


Gesendet von iPad mit Tapatalk

Mit apptime zusammen? Kannst Du dann apptime Mal bitte deaktivieren? Also so richtig.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 01 April 2018, 16:21:13
ZitatMit apptime zusammen? Kannst Du dann apptime Mal bitte deaktivieren? Also so richtig.
Da ich freezemon gelöscht habe und fhem neugestartet ist sollte apptime nicht mehr laufen oder?
Perfmon ist ebenso nicht im Einsatz.
VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 01 April 2018, 16:22:59
Sollte dann in der Tat weg sein.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 01 April 2018, 16:37:07
Hab jetzt testweise freezemon wieder aktiviert. Werde später berichten...
VG Sebastian
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KernSani am 01 April 2018, 18:24:31
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...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 01 April 2018, 18:27:26
Zitat von: KernSani am 01 April 2018, 18:24:31
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.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KernSani am 01 April 2018, 20:09:07
Zitat von: CoolTux am 01 April 2018, 18:27:26
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)

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 01 April 2018, 20:13:36
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 02 April 2018, 15:31:35
Hallo Zusammen,
der aktuelle Stand bei mir:
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 02 April 2018, 15:45:36
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 (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 (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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KernSani am 02 April 2018, 16:22:17
@Sebastian: Auch wenn Freezemon deaktiviert ist, bleibt apptime aktiv. Hast du mal apptime ohne Freezemon probiert?


Kurz, weil mobil...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 02 April 2018, 16:47:15
Zitat von: binford6000 am 02 April 2018, 15:31:35Haben andere Betroffene auch freezemon ausprobiert oder im Einsatz?

Ja, wie hier berichtet (https://forum.fhem.de/index.php/topic,84372.msg786907.html#msg786907).

Freezemon werde ich morgen wieder aktivieren und das Verhalten überwachen. Ich bezweifle aber, dass es ausschließlich am Modul freezemon liegt, da
Allerdings habe ich keine Aufzeichnungen darüber, wann ich das Modul upgedatet hatte.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 02 April 2018, 17:34:44
Hallo Reinhard, Oli, Brice,
ZitatKannst 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:
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;}}

ZitatIch hatte immer die vom Entwickler KernSani vorgeschlagenen SVG Charts eingerichtet, hast du die auch aktiv?
Hatte ich kurz im Einsatz, dann wieder gelöscht.
Zitat@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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KernSani am 02 April 2018, 18:10:24
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. 
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 02 April 2018, 18:13:05
ZitatIch fürchte möglicherweise ist doch Freezemon (mit) Schuld... allerdings nur ein inaktiver Freezemon.
Das deckt sich ja mit meinen Beobachtungen  ;)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 02 April 2018, 18:40:45
Bei meinem zweiten System (siehe Signatur) ist freezemon.pm seit dem 12.03.2018 auf inaktiv gesetzt.

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...
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


98_freezemon.pm     16411 2018-03-14 22:22:14Z KernSani
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KernSani am 02 April 2018, 18:47:24
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...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: binford6000 am 02 April 2018, 18:57:27
ZitatDas 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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 04 April 2018, 10:15:12
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 04 April 2018, 14:41:11
Auch bei mir steigt der Speicherverbrauch trotz gelöschtem Freezmon weiterhin an.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 04 April 2018, 14:49:01
Ist apptime geladen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 04 April 2018, 15:14:28
auch bei mir steigt der Speicherverbrauch immernoch an. Apptime und Freezemon sind nicht geladen.

Wenn ich bei 220 UsedRAM Plots anschaue, kommt "Cannot...."

Ich lasse jetzt FHEM doch automatisch bei Usedram über 220MB neu starten (Shutdown Restart). Bisher sind CUL und 1-Wire zum Glück immer wieder aktiviert worden.

Gruss
  Enno
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 04 April 2018, 15:25:33
Ich hatte um ganz sicher zugehen die Module umbenannt... Wäre auch noch nen Versuch wert.
Und seit dem bekannt werden von den beiden und einem Neustart am 1.4. habe ich keinen anstieg mehr vom RAM.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 04 April 2018, 16:10:27
Ich hatte freezemon 36 Stunden wieder aktiv (Rücknahme der Auskommentierung in der fhem.cfg  :D): kein Anstieg des Speicherverbrauchs.

Eine weitere Änderung hatte ich seit ca. Ende Februar: die Anzeige von Pi-hole auf einem anderen Pi per HTTPMOD über einen von mir nicht evaluierten Code aus dem Forum (https://forum.fhem.de/index.php/topic,84031.msg763331.html#msg763331). HTTPMOD nutze ich auch für andere Dinge. Hatte ich zur gleichen Zeit wie freezemon auskommentiert (20.03.2018). Möchte ich als Ursache eigentlich ausschließen, aber dennoch die Frage: hat jemand von euch ebenfalls eine Abfrage von Pi-hole?

Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 04 April 2018, 17:35:10
Hallo,

auch ich habe zum testen freezemon mit apptime wieder installiert und genau ab diesen Moment beobachte ich eine kontinuierliche Zunahme des Speicherverbrauchs. Vor der Installation konnte ich die steigende Zunahme definitiv nicht beobachten.

Ich verwende frezemon Vers. 0.0.19, wie im Beitrag beschrieben, mit dem Textlog (DBLog verwende ich für wichtige Daten) und SVG Plots https://forum.fhem.de/index.php/topic,83909.msg762539.html#msg762539 (https://forum.fhem.de/index.php/topic,83909.msg762539.html#msg762539). Perfmon war vor dem Test aktiv, ich habe es komplett entfernt.

Anbei noch die Attribute von freezemon wie ich es einsetze.

defmod freezemon freezemon
attr freezemon DbLogExclude .*
attr freezemon fm_forceApptime 1
attr freezemon fm_log 10:1 5:2 1:3
attr freezemon fm_logFile ./log/freeze-%Y%m%d-%H%M%S.log
attr freezemon fm_logKeep 10
attr freezemon room System
attr freezemon verbose 2


Speicherfehler sind bei mir jedoch noch nicht aufgetreten, ich denke aber es ist nur eine Frage der Zeit.

Nachtrag:
"extraSeconds-Attribut" gelöscht 
Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KernSani am 04 April 2018, 17:53:30
Bitte lösche mal das extraSeconds-Attribut


Kurz, weil mobil...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: zap am 06 April 2018, 08:45:45
Wenn wirklich freezemon die Ursache ist, sollte man das Modul eben nur dann einsetzen, wenn man wirklich Probleme mit Freezes hat und diese analysieren möchte.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 06 April 2018, 19:40:43
Zitat von: zap am 06 April 2018, 08:45:45
Wenn wirklich freezemon die Ursache ist, sollte man das Modul eben nur dann einsetzen, wenn man wirklich Probleme mit Freezes hat und diese analysieren möchte.

Also ich habe freezemon nicht installiert. Trotzdem ist das Problem vorhanden
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 13 April 2018, 14:35:58
ZitatIch meine bei mir inzwischen die auf dem gleichen Pi laufende Homebridge für das Problem identifiziert zu haben. Wenn ich den Homebridge Service auf dem PI stoppe, steigt der Speicherverbrauch von FHEM nicht mehr an...
Ich vermute das Homebridge sehr viele Anfragen/Daten an FHEM schickt.

Gruß
Jens

Ich nehme alles zurück und behaupte das Gegenteil. Der Speicheranstieg ist immer noch da. ich habe wohl nicht lange genug auf den Verlauf geschaut.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: andies am 21 April 2018, 22:23:27
Gleiches Problem, freezemon inzwischen gelöscht. Sonst

Latest Revision: 16610

File                        Rev   Last Change

fhem.pl                     16609 2018-04-13 19:53:08Z rudolfkoenig
90_at.pm                    15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm            15620 2017-12-16 18:10:36Z rudolfkoenig
57_Calendar.pm              16539 2018-04-02 20:09:57Z neubert
93_DbLog.pm                 16610 2018-04-13 21:06:38Z DS_Starter
98_DBPlan.pm                73000 2017-05-02 11:06:00Z jowiemann
93_DbRep.pm                 16595 2018-04-12 19:22:50Z DS_Starter
98_DOIF.pm                  16481 2018-03-25 09:10:27Z Damian
98_dummy.pm                 12700 2016-12-02 16:49:42Z rudolfkoenig
73_ElectricityCalculator.pm 16601 2018-04-13 17:57:41Z Sailor
91_eventTypes.pm            14888 2017-08-13 12:07:12Z rudolfkoenig
98_expandJSON.pm            16115 2018-02-08 08:20:45Z dev0
00_FBAHAHTTP.pm             16344 2018-03-06 21:06:34Z rudolfkoenig
10_FBDECT.pm                16441 2018-03-18 21:39:08Z rudolfkoenig
72_FB_CALLLIST.pm           16433 2018-03-18 08:20:35Z markusbloch
72_FB_CALLMONITOR.pm        16607 2018-04-13 18:31:53Z markusbloch
01_FHEMWEB.pm               16599 2018-04-13 17:28:07Z rudolfkoenig
92_FileLog.pm               15874 2018-01-13 17:16:33Z rudolfkoenig
No Id found for 37_flic2.pm
10_FS10.pm                    331 2017-06-23 17:00:00Z v3.3-dev
73_GasCalculator.pm         16602 2018-04-13 17:58:19Z Sailor
98_GEOFANCY.pm              14110 2017-04-26 06:54:58Z loredo
95_holiday.pm               16502 2018-03-27 20:59:14Z rudolfkoenig
98_HTTPMOD.pm               16216 2018-02-18 15:26:11Z StefanStrobel
02_HTTPSRV.pm               13976 2017-04-12 13:35:44Z neubert
49_IPCAM.pm                  2626 2013-02-01 19:19:15Z mfr69bs
10_IT.pm                    14852 2017-08-06 08:48:24Z bjoernh
98_JsonList2.pm             16293 2018-02-28 21:33:57Z rudolfkoenig
98_logProxy.pm              16299 2018-03-01 08:06:55Z justme1968
00_MQTT.pm                  16252 2018-02-23 21:32:59Z eisler
10_MQTT_DEVICE.pm           16252 2018-02-23 21:32:59Z eisler
No Id found for 99_myUtils.pm
No Id found for 99_myUtilsTelegram.pm
91_notify.pm                15937 2018-01-20 13:43:28Z rudolfkoenig
70_Pushover.pm              16358 2018-03-09 09:58:05Z loredo
33_readingsGroup.pm         16299 2018-03-01 08:06:55Z justme1968
14_SD_WS.pm                    39 2017-09-08 22:00:00Z v3.3-dev
00_SIGNALduino.pm           10488 2018-04-11 23:00:00Z v3.3.3-dev
# $Id: 90_SIGNALduino_un.pm 15479 2018-01-24 20:00:00 dev-r33 $
96_SIP.pm                   15827 2018-01-08 18:36:07Z Wzut
10_SOMFY.pm                 15807 2018-01-06 23:32:41Z viegener
99_SUNRISE_EL.pm            16266 2018-02-25 18:22:51Z rudolfkoenig
98_SVG.pm                   16402 2018-03-13 21:14:22Z rudolfkoenig
42_SYSMON.pm                15910 2018-01-16 23:07:56Z hexenmeister
50_TelegramBot.pm           16382 2018-03-11 13:20:55Z viegener
98_telnet.pm                16293 2018-02-28 21:33:57Z rudolfkoenig
99_Utils.pm                 15713 2017-12-28 11:01:02Z rudolfkoenig
No Id found for 89_VCLIENT.pm
98_version.pm               15140 2017-09-26 09:20:09Z markusbloch
No Id found for 23_VZLOGGER.pm
59_Weather.pm               12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm               16293 2018-02-28 21:33:57Z rudolfkoenig

Blocking.pm                 15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm                    11159 2016-03-30 16:08:06Z justme1968
DevIo.pm                    16329 2018-03-04 20:18:08Z rudolfkoenig
FritzBoxUtils.pm            16344 2018-03-06 21:06:34Z rudolfkoenig
GPUtils.pm                   6653 2014-10-02 11:59:37Z ntruchsess
HttpUtils.pm                16407 2018-03-14 19:43:35Z rudolfkoenig
RTypes.pm                   10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm            16568 2018-04-08 09:44:42Z rudolfkoenig
TcpServerUtils.pm           15707 2017-12-27 14:41:21Z rudolfkoenig
YahooWeatherAPI.pm          15742 2018-01-01 07:55:55Z neubert

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16546 2018-04-03 19:51:36Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968


und

Linux FHEM 4.14.34-v7+ #1110 SMP Mon Apr 16 15:18:51 BST 2018 armv7l GNU/Linux


sowie

Summary of my perl5 (revision 5 version 20 subversion 2) configuration:
   
  Platform:
    osname=linux, osvers=4.9.0-0.bpo.4-armmp, archname=arm-linux-gnueabihf-thread-multi-64int
    uname='linux bm-wb-04 4.9.0-0.bpo.4-armmp #1 smp debian 4.9.51-1~bpo8+1 (2017-10-17) armv7l gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Dldflags= -Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dcccdlflags=-fPIC -Darchname=arm-linux-gnueabihf -Dprefix=/usr -Dprivlib=/usr/share/perl/5.20 -Darchlib=/usr/lib/arm-linux-gnueabihf/perl/5.20 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/arm-linux-gnueabihf/perl5/5.20 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.20.2 -Dsitearch=/usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dusesitecustomize -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -Uversiononly -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.20.2 -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='4.9.2', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/gcc/arm-linux-gnueabihf/4.9/include-fixed /usr/include/arm-linux-gnueabihf /usr/lib /lib/arm-linux-gnueabihf /lib /usr/lib/arm-linux-gnueabihf
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=libc-2.19.so, so=so, useshrplib=true, libperl=libperl.so.5.20
    gnulibc_version='2.19'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib -fstack-protector'


Characteristics of this binary (from libperl):
  Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
                        PERL_DONT_CREATE_GVSV
                        PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
                        PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
                        PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
                        USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
                        USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE
                        USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
                        USE_REENTRANT_API USE_SITECUSTOMIZE
  Locally applied patches:
DEBPKG:debian/cpan_definstalldirs - Provide a sensible INSTALLDIRS default for modules installed from CPAN.
DEBPKG:debian/db_file_ver - http://bugs.debian.org/340047 Remove overly restrictive DB_File version check.
DEBPKG:debian/doc_info - Replace generic man(1) instructions with Debian-specific information.
DEBPKG:debian/enc2xs_inc - http://bugs.debian.org/290336 Tweak enc2xs to follow symlinks and ignore missing @INC directories.
DEBPKG:debian/errno_ver - http://bugs.debian.org/343351 Remove Errno version check due to upgrade problems with long-running processes.
DEBPKG:debian/libperl_embed_doc - http://bugs.debian.org/186778 Note that libperl-dev package is required for embedded linking
DEBPKG:fixes/respect_umask - Respect umask during installation
DEBPKG:debian/writable_site_dirs - Set umask approproately for site install directories
DEBPKG:debian/extutils_set_libperl_path - EU:MM: set location of libperl.a under /usr/lib
DEBPKG:debian/no_packlist_perllocal - Don't install .packlist or perllocal.pod for perl or vendor
DEBPKG:debian/prefix_changes - Fiddle with *PREFIX and variables written to the makefile
DEBPKG:debian/fakeroot - Postpone LD_LIBRARY_PATH evaluation to the binary targets.
DEBPKG:debian/instmodsh_doc - Debian policy doesn't install .packlist files for core or vendor.
DEBPKG:debian/ld_run_path - Remove standard libs from LD_RUN_PATH as per Debian policy.
DEBPKG:debian/libnet_config_path - Set location of libnet.cfg to /etc/perl/Net as /usr may not be writable.
DEBPKG:debian/mod_paths - Tweak @INC ordering for Debian
DEBPKG:debian/module_build_man_extensions - http://bugs.debian.org/479460 Adjust Module::Build manual page extensions for the Debian Perl policy
DEBPKG:debian/prune_libs - http://bugs.debian.org/128355 Prune the list of libraries wanted to what we actually need.
DEBPKG:fixes/net_smtp_docs - [rt.cpan.org #36038] http://bugs.debian.org/100195 Document the Net::SMTP 'Port' option
DEBPKG:debian/perlivp - http://bugs.debian.org/510895 Make perlivp skip include directories in /usr/local
DEBPKG:debian/deprecate-with-apt - http://bugs.debian.org/747628 Point users to Debian packages of deprecated core modules
DEBPKG:debian/squelch-locale-warnings - http://bugs.debian.org/508764 Squelch locale warnings in Debian package maintainer scripts
DEBPKG:debian/skip-upstream-git-tests - Skip tests specific to the upstream Git repository
DEBPKG:debian/patchlevel - http://bugs.debian.org/567489 List packaged patches for 5.20.2-3+deb8u10 in patchlevel.h
DEBPKG:debian/skip-kfreebsd-crash - http://bugs.debian.org/628493 [perl #96272] Skip a crashing test case in t/op/threads.t on GNU/kFreeBSD
DEBPKG:fixes/document_makemaker_ccflags - http://bugs.debian.org/628522 [rt.cpan.org #68613] Document that CCFLAGS should include $Config{ccflags}
DEBPKG:debian/find_html2text - http://bugs.debian.org/640479 Configure CPAN::Distribution with correct name of html2text
DEBPKG:debian/perl5db-x-terminal-emulator.patch - http://bugs.debian.org/668490 Invoke x-terminal-emulator rather than xterm in perl5db.pl
DEBPKG:debian/cpan-missing-site-dirs - http://bugs.debian.org/688842 Fix CPAN::FirstTime defaults with nonexisting site dirs if a parent is writable
DEBPKG:fixes/memoize_storable_nstore - [rt.cpan.org #77790] http://bugs.debian.org/587650 Memoize::Storable: respect 'nstore' option not respected
DEBPKG:debian/regen-skip - Skip a regeneration check in unrelated git repositories
DEBPKG:fixes/regcomp-mips-optim - [perl #122817] http://bugs.debian.org/754054 Downgrade the optimization of regcomp.c on mips and mipsel due to a gcc-4.9 bug
DEBPKG:debian/makemaker-pasthru - http://bugs.debian.org/758471 Pass LD settings through to subdirectories
DEBPKG:fixes/perldoc-less-R - [rt.cpan.org #98636] http://bugs.debian.org/758689 Tell the 'less' pager to allow terminal escape sequences
DEBPKG:fixes/pod_man_reproducible_date - http://bugs.debian.org/759405 Support POD_MAN_DATE in Pod::Man for the left-hand footer
DEBPKG:fixes/io_uncompress_gunzip_inmemory - http://bugs.debian.org/747363 [rt.cpan.org #95494] Fix gunzip to in-memory file handle
DEBPKG:fixes/socket_test_recv_fix - http://bugs.debian.org/758718 [perl #122657] Compare recv return value to peername in socket test
DEBPKG:fixes/hurd_socket_recv_todo - http://bugs.debian.org/758718 [perl #122657] TODO checking the result of recv() on hurd
DEBPKG:fixes/regexp-performance - [0fa70a0] http://bugs.debian.org/777556 [perl #123743] simpify and speed up /.*.../ handling
DEBPKG:fixes/failed_require_diagnostics - http://bugs.debian.org/781120 [perl #123270] Report inaccesible file on failed require
DEBPKG:fixes/array-cloning - http://bugs.debian.org/779357 [perl #124127] [902d169] fix cloning arrays with unused elements
DEBPKG:fixes/perldb-threads - http://bugs.debian.org/779357 [perl #124127] [41ef2c6] lib/perl5db.pl: Restore noop lock prototype
DEBPKG:fixes/CVE-2015-8607_file_spec_taint_fix - ensure File::Spec::canonpath() preserves taint
DEBPKG:fixes/encode-unicode-bom - http://bugs.debian.org/798727 [rt.cpan.org #107043] Address https://rt.cpan.org/Public/Bug/Display.html?id=107043
DEBPKG:debian/encode-unicode-bom-doc - http://bugs.debian.org/798727 Document Debian backport of Encode::Unicode fix
DEBPKG:debian/kfreebsd-softupdates - http://bugs.debian.org/796798 Work around Debian Bug#796798
DEBPKG:fixes/CVE-2016-2381_duplicate_env - remove duplicate environment variables from environ
DEBPKG:debian/debugperl-compat-fix - [perl #127212] http://bugs.debian.org/810326 Disable PERL_TRACK_MEMPOOL for debugging builds
DEBPKG:fixes/CVE-2015-8853_regexp_hang - http://bugs.debian.org/821848 [perl #123562] PATCH [perl #123562] Regexp-matching "hangs"
DEBPKG:fixes/utf8_regexp_crash - http://bugs.debian.org/820328 [perl #124109] save_re_context(): do "local $n" with no PL_curpm
DEBPKG:fixes/regcomp_whitespace_fix - http://bugs.debian.org/820328 [perl #124109] Perl_save_re_context(): re-indent after last commit
DEBPKG:fixes/5.20.3/eval_label_crash - http://bugs.debian.org/822336 [perl #123652] eval {label:} crash
DEBPKG:fixes/5.20.3/preserve_record_separator - http://bugs.debian.org/822336 [perl #123218] "preserve" $/ if set to a bad value
DEBPKG:fixes/5.20.3/test_count_base_rs - http://bugs.debian.org/822336 Fix test count in t/base/rs.t
DEBPKG:fixes/5.20.3/remove_get_magic - http://bugs.debian.org/822336 [perl #123739] Remove get-magic from $/
DEBPKG:fixes/5.20.3/speed_up_scalar_g - http://bugs.debian.org/822336 [perl #123202] speed up scalar //g against tainted strings
DEBPKG:fixes/5.20.3/accidental_all_features - http://bugs.debian.org/822336 Stop $^H |= 0x1c020000 from enabling all features
DEBPKG:fixes/5.20.3/multidimensional_arrays_utf8 - http://bugs.debian.org/822336 [perl #124113] Make check for multi-dimensional arrays be UTF8-aware
DEBPKG:fixes/5.20.3/unquoted_utf8_heredoc_terminators - http://bugs.debian.org/822336 Allow unquoted UTF-8 HERE-document terminators
DEBPKG:fixes/5.20.3/parentheses_ambiguous_warning_utf8_functions - http://bugs.debian.org/822336 Fix "...without parentheses is ambuguous" warning for UTF-8 function names
DEBPKG:fixes/5.20.3/leak_namepv_copy - http://bugs.debian.org/822336 [perl #123786] don't leak the temp utf8 copy of namepv
DEBPKG:fixes/5.20.3/h2ph_hex_constants - http://bugs.debian.org/822336 h2ph: correct handling of hex constants for the preamble
DEBPKG:fixes/5.20.3/leftbracket_XTERMORDORDOR - http://bugs.debian.org/822336 [perl #123711] Fix crash with 0-5x-l{0}
DEBPKG:fixes/5.20.3/fatalize_warnings_unwinding - http://bugs.debian.org/822336 [perl #123398] don't fatalize warnings during unwinding (#123398)
DEBPKG:fixes/5.20.3/setpgrp - http://bugs.debian.org/822336 =?UTF-8?q?Don=E2=80=99t=20treat=20setpgrp($nonzero)=20as=20setpgr?= =?UTF-8?q?p(1)?=
DEBPKG:fixes/5.20.3/death_unwinding_crash - http://bugs.debian.org/822336 [perl #124156] RT #124156: death during unwinding causes crash
DEBPKG:fixes/5.20.3/stashpvn_crash - http://bugs.debian.org/822336 [perl #125541] Fix crash with %::=(); J->${\"::"}
DEBPKG:fixes/5.20.3/possessive_quantifier - http://bugs.debian.org/822336 [perl #125825] PATCH: [perl 125825] {n}+ possessive quantifier broken
DEBPKG:fixes/5.20.3/quoted_code_crash - http://bugs.debian.org/822336 [perl #123712] Fix /$a[/ parsing
DEBPKG:fixes/5.20.3/checking_sub_inwhat - http://bugs.debian.org/822336 [perl #123712] Don't check sub_inwhat
DEBPKG:fixes/5.20.3/yylex_loop - http://bugs.debian.org/822336 Fix hang with "@{"
DEBPKG:fixes/5.20.3/docs/op - http://bugs.debian.org/822336 Fix apidocs for OP_TYPE_IS(_OR_WAS) - arguments separated by |, not ,.
DEBPKG:fixes/5.20.3/docs/encoding - http://bugs.debian.org/822336 perlpodspec: Corrections/adds to detecting =encoding
DEBPKG:fixes/5.20.3/docs/SvPV_set - http://bugs.debian.org/822336 improve SvPV_set's docs, it really shouldn't be public API
DEBPKG:fixes/5.20.3/docs/autodie - http://bugs.debian.org/822336 Fix warning message regarding "use autodie" and "use open".
DEBPKG:fixes/5.20.3/docs/autodie_2_26 - http://bugs.debian.org/822336 perlunicook: Note that autodie >= 2.26 should be okay with "use open".
DEBPKG:fixes/5.20.3/docs/setenv - http://bugs.debian.org/822336 Fix setenv() replacement documentation in perlclib
DEBPKG:fixes/5.20.3/docs/clib_caution - http://bugs.debian.org/822336 perlhacktips: Add caution about clib ptr returns to static memory
DEBPKG:fixes/5.20.3/docs/perlunicook_typos - http://bugs.debian.org/822336 Fix minor code typos in perlunicook
DEBPKG:fixes/5.20.3/docs/ook_example - http://bugs.debian.org/822336 [perl #122322] Update OOK example in perlguts
DEBPKG:fixes/5.20.3/docs/study_noop - http://bugs.debian.org/822336 perlfunc: mention that study() is currently a noop
DEBPKG:fixes/CVE-2016-1238/remove-dot-when-loading - [perl #127834] (perl #127834) remove . from the end of @INC if complex modules are loaded
DEBPKG:fixes/CVE-2016-1238/remove-dot-in-padwalker - [perl #127834] perl5db.pl: ensure PadWalker is loaded from standard paths
DEBPKG:fixes/CVE-2016-1238/remove-dot-in-dist - [perl #127834] dist/: remove . from @INC when loading optional modules
DEBPKG:fixes/CVE-2016-1238/remove-dot-in-cpan - [perl #127834] cpan/: remove . from @INC when loading optional modules
DEBPKG:fixes/CVE-2016-1238/customized-encode - Update customized.dat for cpan/Encode/Encode.pm
DEBPKG:debian/CVE-2016-1238/test-suite-without-dot - [perl #127810] Patch unit tests to explicitly insert "." into @INC when needed.
DEBPKG:debian/CVE-2016-1238/eumm-without-dot - [perl #127810] Add PERL_USE_UNSAFE_INC support to EU::MM for fortify_inc support.
DEBPKG:debian/CVE-2016-1238/cpan-without-dot - [perl #127810] Set PERL_USE_UNSAFE_INC for cpan usage
DEBPKG:debian/CVE-2016-1238/mb-without-dot - Make Module::Build set PERL_USE_UNSAFE_INC
DEBPKG:debian/CVE-2016-1238/sitecustomize-in-etc - Look for sitecustomize.pl in /etc/perl rather than sitelib on Debian systems
DEBPKG:fixes/xsloader-eval - [rt.cpan.org #115808] http://bugs.debian.org/829578 =?UTF-8?q?Don=E2=80=99t=20let=20XSLoader=20load=20relative=20path?= =?UTF-8?q?s?=
DEBPKG:fixes/file_path_chmod_race - http://bugs.debian.org/863870 [rt.cpan.org #121951] Prevent directory chmod race attack.
DEBPKG:fixes/extutils_file_path_compat - [PATCH] Correct the order of tests of chmod(). (#294)
DEBPKG:debian/customized_file_path - Update customized.dat for File-Path changes
DEBPKG:debian/CVE-2016-1238/base-pm-amends-pt1 - Revert base.pm no-dot-in-inc fixes to make way for a better version
DEBPKG:debian/CVE-2016-1238/base-pm-amends-pt2 - [1afa289] Limit dotless-INC effect on base.pm with guard:
DEBPKG:fixes/CVE-2017-12837 - http://bugs.debian.org/875596 [perl #131582] regcomp [perl #131582]
DEBPKG:fixes/CVE-2017-12883 - http://bugs.debian.org/875597 [perl #131598] PATCH: [perl #131598]
DEBPKG:fixes/CVE-2017-12883-5.20 - http://bugs.debian.org/875597 [perl #131598] regcomp: Fix out of bound reads
DEBPKG:fixes/CVE-2018-6913 - [perl #131844] (perl #131844) fix various space calculation issues in pp_pack.c
  Built under linux
  Compiled at Apr 14 2018 18:38:03
  @INC:
    /etc/perl
    /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2
    /usr/local/share/perl/5.20.2
    /usr/lib/arm-linux-gnueabihf/perl5/5.20
    /usr/share/perl5
    /usr/lib/arm-linux-gnueabihf/perl/5.20
    /usr/share/perl/5.20
    /usr/local/lib/site_perl
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 21 April 2018, 23:19:35
Zitat... freezemon inzwischen gelöscht ...

Ich hatte mal das Problem des anwachsenden Speichers sobald ich apptime benutzt habe (ist aber schon etwas her). freezemon kann apptime laden.
Nur freezemon zu löschen reicht möglicherweise nicht.
Stelle bitte auch sicher dass apptime nicht mehr verwendet wird -> restart.
Vielleicht ergibt sich dann etwas ...
Das fällt mir nur auf weil du in einem anderen Thread (https://forum.fhem.de/index.php/topic,73490.msg796187.html#msg796187) darauf verwiesen hast dieses Problem zu beobachten seitdem du freezemon definiert hast.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: andies am 22 April 2018, 11:42:13
Danke, ich hatte neu gestartet. Ist denn jetzt sicher, dass apptime das Problem verursacht?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 22 April 2018, 11:56:18
ZitatIst denn jetzt sicher, dass apptime das Problem verursacht?
Nein, ich habe nur meine Beobachtungen zur Verfügung gestellt, die ich gemacht hatte.
Wenn man den Verlauf in diesem Thread nachliest, läßt sich für mich nicht die Abhängigkeit von einem bestimmten Modul erkennen.
Es gibt kein Modul was mit Sicherheit in allen verwendeten problembehafteten Installationen verwendet wird, außer eventuell apptime was nicht in der Übersicht die mit "version" erstellt wird, auftaucht.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: SouzA am 25 April 2018, 20:09:59
Hi,
selbes Problem hier.
Kein Freezemon (war mal installiert) und kein Apptime...

Gibt es schon Erkenntnisse?

Vielen Dank und bis denn.
SouzA
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Amenophis86 am 25 April 2018, 21:57:19
Zitat von: SouzA am 25 April 2018, 20:09:59
Gibt es schon Erkenntnisse?

Ja, aber die sind geheim. SCNR
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: SouzA am 25 April 2018, 23:02:12
Sehr hilfreich, danke.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Amenophis86 am 26 April 2018, 07:24:14
Sehr gerne :)

Aber mal im Ernst, meinst du nicht die Informationen würden hier stehen, wenn es bereits weitere gäbe? Es gibt sicher keinen Grund diese geheim zu halten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: andies am 26 April 2018, 08:50:26
Manchmal werden Threads vergessen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Amenophis86 am 26 April 2018, 09:11:58
Das stimmt, aber ob man bei 3 Tage nach dem letzten Post schon von vergessen reden kann mag ich bezweifeln. Aber wir weichen vom Thema ab :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 26 April 2018, 10:35:32
Zitat von: enno am 28 März 2018, 11:31:53
Ich bin schon dabei. Ich lager ein Modul (MPD, SIP, AVM) nach dem anderen auf meinen zweiten Pi aus. Verbunden über FHEM2FHEM und Dummys funktioniert die Steuerung auf dem auffälligen System weiter.

Die Verlagerung von MPD hat den Speicherverbrauch deutlich reduziert, aber noch nicht beseitigt. Ich warte gerade ab, wann das System das nächste mal stehen bleibt. Dann werde ich die ganzen Wetterdienste umziehen...

Gruss
  Enno

Ich habe den PI jetzt abgeschaltet und bin mit FHEM auf einen NUC mit 4 GB RAM umgezogen. Ich habe FHEM dazu neu installiert und dann die "fhem.cfg" einfach rüberkopiert. Läuft alles, auch der Speicherverbrauch steigt hier an. Da der Rechner aber deutlich mehr Speicher hat und nur FHEM läuft, kommt die Fehlermeldung nicht mehr. Ich habe es bisher noch nicht geschafft (> 2 Wochen) so lange laufenzulassen bis auch dieses System in die Knie geht.

Gruss
  Enno
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: nils_ am 26 April 2018, 10:55:20
Zitat von: enno am 26 April 2018, 10:35:32
Ich habe den PI jetzt abgeschaltet und bin mit FHEM auf einen NUC mit 4 GB RAM umgezogen. Ich habe FHEM dazu neu installiert und dann die "fhem.cfg" einfach rüberkopiert. Läuft alles, auch der Speicherverbrauch steigt hier an. Da der Rechner aber deutlich mehr Speicher hat und nur FHEM läuft, kommt die Fehlermeldung nicht mehr. Ich habe es bisher noch nicht geschafft (> 2 Wochen) so lange laufenzulassen bis auch dieses System in die Knie geht.

Gruss
  Enno
da langweilt sich der NUC aber  :o

aber wenn der speicher auch steigt, ist die wahrscheinlichkeit groß, das der Fehler _demnächst_ (t.b.d :) ) auch dort auftritt
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rico5588 am 26 April 2018, 13:56:33
Versuch doch mal, was bei mir geholfen hat, freezmon und apptime zu löschen/umbennen im fhem ordner. Danach weißt du dann ob es besser wird. Ich konnte so nach 1 Stunde sagen das es daran liegt...Deaktivierung hat bei mir kwine n Erfolg gezeigt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: frank am 26 April 2018, 15:12:05
freezemon ansich macht bei mir keine probleme. erst die aktivierung von apptime über das attribut fm_forceApptime=1 hat bei mir einen permanenten speicherzuwachs von ca 50MB pro tag produziert (sysmon => used ram). nach ca 7 tagen waren fast keine forks mehr möglich.

mit attr fm_forceApptime=0 plus fhem restart konnte ich diesen anstieg abschalten.

es muss allerdings mindestens noch ein problem geben, da ich jetzt auch gesehen habe, dass es bei mir im märz und anfang april bereits auch schon speicherprobleme gab, obwohl damals weder freezemon noch apptime existierten.

dieses "alte" problem kann ich aber zur zeit nicht mehr erkennen. eventuell wurde es mit einem fhem update am 9.4. behoben.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 26 April 2018, 15:41:41
freezemon und apptime kann es bei mir nicht sein, habe ich beide nicht aktiviert und zur Sicherheit auch aus /opt/fhem/FHEM/.. gelöscht und beim update exclude.

Gruss
  Enno
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 27 April 2018, 16:03:50
Mein Produktivsystem läuft seit dem 20.03.2018 auch ohne erzwungenem shutdown/restart fehlerfei und FHEM hat auch zwischenzeitlich ein update bekommen. Warum das so ist: keine Ahnung. Das es an freezemon liegt, halte ich immer noch für unwahrscheinlich.

Nur an der Androhung, das System zwangsweise bei Überschreitung eines Schwellwertes neu zu starten (https://forum.fhem.de/index.php/topic,84372.msg784569.html#msg784569), kann es nicht liegen :). Ich bin ratlos, aber wenn es läuft, dann ist es für mich ok.

Leider habe ich keinen weiteren Tipp für alle Betroffenen.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 01 Mai 2018, 12:36:45
Hallo zusammen,

möglicherweise gibt es einen Ansatz...

Vor einigen Tagen habe ich mir einen Sonos Play 1 zugelegt und demzufolge das Sonosmodul aktiviert.

Das Modul braucht ohnehin recht viel Speicher, aber die RAM-Ausnutzung stieg permanent von ca. 370MB auf ca.450MB und ebenfalls die  CPU-Last (Minimum) von ca. 0.50% auf über 3% innerhalb von 2 Tagen an. Einen Plot habe ich angehängt.

Zur Fehleriengrenzung habe ich nicht das Modul wieder deaktiviert, sondern habe einem Bauchgefühl folgend die fhem.pl-Version 16211 vom 18.02.2018 (https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl?rev=16211)  wieder implementiert. Diese Version war die letzte Version bevor die Umstellung der InternalTimer-Verwaltung von Hash nach Array vorgenommen wurde.

Seitdem bleibt die RAM-Nutzung stabil bei ca. 380 MB (geht natürlich mal kräftig hoch, aber wieder runter) und die CPU-Last schwankt zwischen 0,3 und 1,0%. (zweiter Plot)
Um auszuschließen, dass dieser positive Effekt nur bei mir in dieser Konstellation zutrifft, wäre natürlich hilfreich wenn die betroffenen Nutzer diese fhem.pl-Version ebenfalls zum Vergleich einsetzen würden (wer es sich zutraut !)

ACHTUNG: Wer DOIF benutzt wird wahrscheinlich Fehler bekommen und das DOIF-Modul nicht laden können weil in späteren fhem.pl-Versionen eine Funktion eingebaut wurde die DOIF benutzt. Vielleicht kann ja Rudi auch eine fhem.pl zur Verfügung stellen, die die Änderungen von Version 16211 zu Version 16214 nicht enthält (alle anderne aber noch drin sind).

In diesem Sinn Allen einen sonnigen Feiertag und hoffentlich Testerfolge.

LG,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 01 Mai 2018, 13:07:29
Da du die InternalTimer Aenderung im Verdacht hast: was liefert
fhem> { join("\n", map { "$_->{TRIGGERTIME}, $_->{FN}" } @intAtA) }
fhem> { int(keys %intAt) }

im Problemfall zurueck?

Ich habe ein fhem.pl mit
% svn diff -r16211:16214 fhem.pl > fhem.diff
% patch -R fhem.pl < fhem.diff
erstellt, kurz getestet, und hier angehaengt.

Btw. bei mir lief fhem.pl r16453 34 Tage lang, zuletzt mit 118MB Speicherbelegung.
Nach dem Neustart benoetigt r16675 110MB. Ich verwende nur die von mir betreuten Module.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 01 Mai 2018, 13:45:01
Hallo Rudi,

danke für die fhem.pl. Habe ich gerade eingespielt und beobachte ...

Zitat
Da du die InternalTimer Aenderung im Verdacht hast: was liefert
Code: [Auswählen]

fhem> { join("\n", map { "$_->{TRIGGERTIME}, $_->{FN}" } @intAtA) }
fhem> { int(keys %intAt) }

im Problemfall zurueck?
Ich hatte während des Ansteigens des RAM / CPU die diversen Testscripte aus dem Thread ausgeführt, aber keine Auffälligkeiten gesehen.
Vor dem Einsatz von Sonos hatte ich ebenfalls kein solches Verhalten von FHEM festgestellt (zumindest keine die ins Gewicht fielen).
Nun ist es aber so, dass Sonos mit einem Subprozess arbeitet. Liefert dieser Test in diesem Fall brauchbare Hinweise ?

Momentan bin ich mir auch noch nicht ganz so sicher, deswegen wünsche ich mir von anderen Nutzern auch noch Testergebnisse.
Bisher waren die verwendeten Module im Fehlerfall nicht sehr homogen, aber in häufigen Fällen half auf apptime/freezemon zu verzichten.
Das deutet für mich in diese Richtung....

Bis jetzt ist es wie beschrieben ein mit Indizien belegtes Bauchgefühl.
Ich werde die neue fhem.pl jetzt mindestens bis morgen Abend auf meinem Prod laufen lassen und dann nochmal einen Test mit der bisherigen "alten" Version machen. Dann kann ich auch das Statement von oben ausführen.

LG,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 01 Mai 2018, 14:02:27
Moin Rudi,

danke für die fhem.pl. Habe ich gerade auch eingespielt und beobachte ...

Gruss
  Enno
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 01 Mai 2018, 14:06:31
ZitatNun ist es aber so, dass Sonos mit einem Subprozess arbeitet. Liefert dieser Test in diesem Fall brauchbare Hinweise ?
Jein: waechst der Subprozess, oder der Haupt-FHEM-Prozess? Im ersten Fall nein, im zweiten Fall evtl. Nur als Info: InternalTimer in einem Subprozess (aka BlockingCall) aufzurufen ist sinnlos, und wuerde wirklich nur Speicher verschwenden. Das waere aber unabhaengig von der InternalTimer Implementation.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 02 Mai 2018, 08:26:34
Guten Morgen,

nach rund 19 Stunden Laufzeit kann ich einen kurzen Zwischenstand geben.

Die CPU-Last (Minimumwwert innerhalb einer Stunde) hat sich geringfügig auf 0,73% erhöht. Die RAM-Auslastung ist stabil geblieben bei ca. 380 MB.

Die Testscripte ergeben für den späteren Vergleich:

{ join("\n", map { "$_->{TRIGGERTIME}, $_->{FN}" } @intAtA) }:  keine Ausgabe
{ int(keys %intAt) }: 174

Heute Abend schaue ich erneut.

LG,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: SouzA am 02 Mai 2018, 12:31:19
Zitat von: rudolfkoenig am 01 Mai 2018, 13:07:29
Da du die InternalTimer Aenderung im Verdacht hast: was liefert
fhem> { join("\n", map { "$_->{TRIGGERTIME}, $_->{FN}" } @intAtA) }
fhem> { int(keys %intAt) }

im Problemfall zurueck?

Ich habe ein fhem.pl mit
% svn diff -r16211:16214 fhem.pl > fhem.diff
% patch -R fhem.pl < fhem.diff
erstellt, kurz getestet, und hier angehaengt.

Btw. bei mir lief fhem.pl r16453 34 Tage lang, zuletzt mit 118MB Speicherbelegung.
Nach dem Neustart benoetigt r16675 110MB. Ich verwende nur die von mir betreuten Module.

Hi,
ich würde auch gerne testen.

Aber was muss ich tun?
Einfach die fhem.pl auf den Raspi kopieren? Müssen da noch irgendwelche Rechte gebogen werden?
Die Codes werden auf dem Raspi in der Console ausgeführt?

Vielen Dank!

Bis denn
SouzA
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 02 Mai 2018, 13:05:08
Hallo SouzA,

du musst die fhem.pl nur auf den raspi kopieren und fhem restarten. Das reicht normalerweise. ggf. noch

chmod 777 fhem.pl

damit es beim nächsten update kein problem mit überschreiben gibt.

die testcodes kannst du im fhemweb in der Kommandozeile absetzen.

Grüße
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 02 Mai 2018, 14:02:34
Sorry, aber ein Vorschlag wie "chmod 777 fhem.pl" ist aus Sicherheitsgründen (und Grundsätzlich) abzulehnen!

Mann sollte es dann "richtig" machen:
chown fhem: fhem.pl
chmod +x fhem.pl


Alles erstmal immer global schreibbar zu machen, widerspricht SÄMMTLICHEN Unix-Grundideen ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 02 Mai 2018, 14:11:11
Ich wußte das du das sagen würdest in dem Moment als ich es schrieb  ;)
Wernieman hat natürlich recht ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: SouzA am 02 Mai 2018, 18:53:06
Hi,

hab ich gemacht!
Gerade gestartet:
{ int(keys %intAt) }: 95
{ join("\n", map { "$_->{TRIGGERTIME}, $_->{FN}" } @intAtA) }: Global symbol "@intAtA" requires explicit package name (did you forget to declare "my @intAtA"?) at (eval 1326) line 1.


Bis denn
SouzA
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 02 Mai 2018, 19:58:22
{ int(keys %intAt) }: 147
{ join("\n", map { "$_->{TRIGGERTIME}, $_->{FN}" } @intAtA) }: Global symbol "@intAtA" requires explicit package name (did you forget to declare "my @intAtA"?) at (eval 128450) line 1.


Leider kein grosser Unterschied mit der geänderten fhem.pl seit gestern 14:00 Uhr.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 02 Mai 2018, 21:36:58
Hallo zusammen,

nach rund 30 Stunden Laufzeit stellt es sich bei mir so dar:

RAM (mit SYSMON gemessen):     392 MB
CPU (Minimumwert pro Stunde):  1.08%
{ int(keys %intAt) }:          195


Der CPU-Wert hat sich also weiter erhöht.
Bezüglich der RAM-Auslastung hatte ich bisher den Wert aus Sysmon herangezogen. Aber wahrscheinlich ist es besser
"Top" anzusehen und dort den VIRT bzw. RES-Wert.

Ich habe über den ganzen Tag hin und wieder "Top" angeschaut und festgestellt dass die Werte für die Perl-Prozesse
im Prinzip etwa gleich bleiben wenn ein gewisses Level erreicht ist. Sie unterliegen natürlich Schwankungen:

Perl-Hauptprozess:  VIRT:  407708  RES: 200408
Subprozess SONOS:   VIRT:  434208  RES: 77056


Es ist bei mir auf jeden Fall eine Erhöhung der Anzahl InternalTimer die sich nicht mehr abbaut.
Mit einem kleinen Hilfsprogramm habe ich mal alles ausgeben lassen:


InternalTimer: 195
Number Date/Time Function
4682289 02.05.2018 21:02:33 HttpUtils_Err
4682775 02.05.2018 20:57:29 BlockingKill
4682777 02.05.2018 20:56:45 HttpUtils_Err
4682780 02.05.2018 20:56:45 HttpUtils_Err
4682783 02.05.2018 20:56:45 HttpUtils_Err
4682786 02.05.2018 20:56:45 HttpUtils_Err
4682789 02.05.2018 20:56:45 HttpUtils_Err
4682792 02.05.2018 20:56:45 HttpUtils_Err
4682795 02.05.2018 20:56:45 HttpUtils_Err
4682798 02.05.2018 20:56:45 HttpUtils_Err
4682801 02.05.2018 20:56:45 HttpUtils_Err
4682804 02.05.2018 20:56:45 HttpUtils_Err
4682807 02.05.2018 20:56:45 HttpUtils_Err
4682810 02.05.2018 20:56:45 HttpUtils_Err
4682813 02.05.2018 20:56:45 HttpUtils_Err
4682816 02.05.2018 20:56:45 HttpUtils_Err
4682819 02.05.2018 20:56:45 HttpUtils_Err
4682822 02.05.2018 20:56:45 HttpUtils_Err
4682825 02.05.2018 20:56:45 HttpUtils_Err
4682828 02.05.2018 20:56:45 HttpUtils_Err
4682831 02.05.2018 20:56:45 HttpUtils_Err
4682834 02.05.2018 20:56:45 HttpUtils_Err
4682837 02.05.2018 20:56:45 HttpUtils_Err
4682840 02.05.2018 20:56:45 HttpUtils_Err
4682843 02.05.2018 20:56:45 HttpUtils_Err
4682846 02.05.2018 20:56:45 HttpUtils_Err
4682849 02.05.2018 20:56:45 HttpUtils_Err
4682852 02.05.2018 20:56:45 HttpUtils_Err
4682855 02.05.2018 20:56:45 HttpUtils_Err
4682858 02.05.2018 20:56:45 HttpUtils_Err
4682861 02.05.2018 20:56:45 HttpUtils_Err
4682864 02.05.2018 20:56:45 HttpUtils_Err
4682867 02.05.2018 20:56:45 HttpUtils_Err
4682870 02.05.2018 20:56:45 HttpUtils_Err
4682873 02.05.2018 20:56:45 HttpUtils_Err
4682876 02.05.2018 20:56:45 HttpUtils_Err
4682879 02.05.2018 20:56:45 HttpUtils_Err
4682882 02.05.2018 20:56:45 HttpUtils_Err
4682885 02.05.2018 20:56:45 HttpUtils_Err
4682888 02.05.2018 20:56:45 HttpUtils_Err
4682891 02.05.2018 20:56:45 HttpUtils_Err
4682894 02.05.2018 20:56:45 HttpUtils_Err
4682897 02.05.2018 20:56:45 HttpUtils_Err
4682900 02.05.2018 20:56:45 HttpUtils_Err
4682903 02.05.2018 20:56:45 HttpUtils_Err
4682906 02.05.2018 20:56:45 HttpUtils_Err
4682909 02.05.2018 20:56:45 HttpUtils_Err
4682912 02.05.2018 20:56:45 HttpUtils_Err
4682915 02.05.2018 20:56:45 HttpUtils_Err
4682918 02.05.2018 20:56:45 HttpUtils_Err
4682921 02.05.2018 20:56:45 HttpUtils_Err
4682924 02.05.2018 20:56:45 HttpUtils_Err
4682927 02.05.2018 20:56:45 HttpUtils_Err
4682930 02.05.2018 20:56:45 HttpUtils_Err
4682933 02.05.2018 20:56:45 HttpUtils_Err
4682936 02.05.2018 20:56:45 HttpUtils_Err
4682939 02.05.2018 20:56:45 HttpUtils_Err
4682942 02.05.2018 20:56:45 HttpUtils_Err
4682945 02.05.2018 20:56:45 HttpUtils_Err
4682948 02.05.2018 20:56:45 HttpUtils_Err
4682951 02.05.2018 20:56:45 HttpUtils_Err
4682954 02.05.2018 20:56:45 HttpUtils_Err
4682957 02.05.2018 20:56:45 HttpUtils_Err
4682960 02.05.2018 20:56:45 HttpUtils_Err
4682963 02.05.2018 20:56:45 HttpUtils_Err
4682966 02.05.2018 20:56:45 HttpUtils_Err
4682969 02.05.2018 20:56:45 HttpUtils_Err
4682972 02.05.2018 20:56:45 HttpUtils_Err
4682975 02.05.2018 20:56:45 HttpUtils_Err
4682978 02.05.2018 20:56:45 HttpUtils_Err
4682981 02.05.2018 20:56:45 HttpUtils_Err
4682984 02.05.2018 20:56:45 HttpUtils_Err
4682987 02.05.2018 20:56:45 HttpUtils_Err
4682990 02.05.2018 20:56:45 HttpUtils_Err
4682993 02.05.2018 20:56:45 HttpUtils_Err
4682996 02.05.2018 20:56:45 HttpUtils_Err
4682999 02.05.2018 20:56:45 HttpUtils_Err
4683002 02.05.2018 20:56:45 HttpUtils_Err
651265 03.05.2018 00:00:01 FileLog_dailySwitch
2037878 03.05.2018 05:33:00 2037878 CUL_HM_statCntRfresh
4573656 02.05.2018 21:03:00 4573656 CUL_HM_complConfigTO
4628751 02.05.2018 20:57:03 4628751 HMinfo_autoUpdate
4645427 02.05.2018 20:58:43 4645427 HTTPMOD_GetUpdate
4646592 02.05.2018 20:59:08 4646592 HTTPMOD_GetUpdate
4666794 02.05.2018 21:03:10 4666794 CUL_HM_ActCheck
4666795 02.05.2018 21:03:10 4666795 HTTPMOD_GetUpdate
4670522 02.05.2018 21:04:08 4670522 HTTPMOD_GetUpdate
4679903 02.05.2018 20:56:57 4679903 FW_closeInactiveClients
4681098 02.05.2018 20:56:38 4681098 HMLAN_KeepAlive
4682283 02.05.2018 20:56:38 4682283 NUT_PollTimer
4682769 02.05.2018 20:56:58 4682769 HMLAN_KeepAlive
651352 03.05.2018 00:00:02 651352 holiday_refresh
4620525 03.05.2018 20:45:06 AT.au.lichtkette.he.An at_Exec
1256873 03.05.2018 04:47:09 AT.au.lichtkette.he.An1 at_Exec
625285 02.05.2018 23:45:00 AT.au.lichtkette.he.Aus at_Exec
1410638 03.05.2018 05:48:52 AT.au.lichtkette.he.Aus1 at_Exec
387816 02.05.2018 21:13:16 AT.au.weihnachtsstern.An at_Exec
574622 02.05.2018 23:15:00 AT.au.weihnachtsstern.Aus at_Exec
2844155 03.05.2018 01:33:07 AllCalView CALVIEW_GetUpdate
1395733 03.05.2018 05:45:00 At.AllCalView.Update at_Exec
4089971 03.05.2018 18:45:00 At.AllCalView.Update.Abend at_Exec
1282891 03.05.2018 05:00:00 At.Apptime.Clear at_Exec
4677059 02.05.2018 20:57:42 At.Check.HouseOpen at_Exec
577 04.05.2018 13:33:01 At.DbRep.LogDB.FindNaDevs at_Exec
4505125 02.05.2018 21:03:01 At.Del.All_Pwr_power at_Exec
2789639 03.05.2018 13:03:01 At.Del.DbShort at_Exec
2854709 03.05.2018 13:39:01 At.Del.Sonnenstrom_Relative at_Exec
4636062 03.05.2018 20:48:26 At.Fensterlichter.EG.Westseite.An at_Exec
637155 02.05.2018 23:52:00 At.Fhem.Dump at_Exec
4666080 02.05.2018 21:13:01 At.Fhem.Size at_Exec
599977 02.05.2018 23:30:00 At.FhemShort.Dump at_Exec
3010008 02.05.2018 22:33:03 At.LogDB.currentPurge at_Exec
3141850 02.05.2018 21:13:01 At.LogDB.sqlResult at_Exec
4666318 02.05.2018 21:03:03 At.LogDBShort.Addlog.FSM1.level at_Exec
3355586 03.05.2018 00:33:03 At.LogDBShort.currentPurge at_Exec
983979 03.05.2018 02:50:00 At.MariaDBs.reopen at_Exec
4628516 02.05.2018 21:37:01 At.PhilipsAudio.GetRadioFav at_Exec
4642813 02.05.2018 21:13:03 At.Rep.CPU at_Exec
2843964 03.05.2018 01:33:03 At.Rep.Fully.DelSeqDoublets at_Exec
863054 03.05.2018 01:52:00 At.Rep.Temp.Current.Month at_Exec
4619602 02.05.2018 21:05:03 At.Rep.az.fridge.kWh at_Exec
4628748 02.05.2018 20:57:02 At.Rep.server.kWh at_Exec
4639305 02.05.2018 21:03:03 At.og.bad.ladestation at_Exec
1621193 03.05.2018 07:10:00 Bad.Radio.WT.An at_Exec
4309810 02.05.2018 22:34:58 Baikal.Abfall Calendar_Wakeup
4620297 02.05.2018 21:00:09 Baikal.Heiko Calendar_Wakeup
4678955 02.05.2018 20:59:35 CamCP1 SSCam_getcaminfoall
4681084 02.05.2018 20:57:42 CamCP1 SSCam_wdpollcaminfo
4677760 02.05.2018 20:59:30 CamGW1 SSCam_getcaminfoall
4682042 02.05.2018 20:57:56 CamGW1 SSCam_wdpollcaminfo
4679906 02.05.2018 20:57:28 CamHE1 SSCam_wdpollcaminfo
4682282 02.05.2018 20:59:58 CamHE1 SSCam_getcaminfoall
4679672 02.05.2018 20:57:24 CamKE1 SSCam_wdpollcaminfo
4680847 02.05.2018 20:59:41 CamKE1 SSCam_getcaminfoall
4672166 02.05.2018 20:58:33 CamTER SSCam_getcaminfoall
4681584 02.05.2018 20:57:50 CamTER SSCam_wdpollcaminfo
1433678 03.05.2018 06:00:00 FHEMBackup at_Exec
372575 02.05.2018 21:00:00 FHEMBackup1 at_Exec
2844347 03.05.2018 13:33:08 Feiertage.ST Calendar_Wakeup
1153691 03.05.2018 04:04:59 Fensterlichter.eg.westseite.An1 at_Exec
608402 02.05.2018 23:35:00 Fensterlichter.eg.westseite.Aus at_Exec
1404241 03.05.2018 05:46:19 Fensterlichter.eg.westseite.Aus1 at_Exec
625288 02.05.2018 23:45:00 Kaminzimmer.Licht.Aus at_Exec
4680137 02.05.2018 20:57:12 LogDB DbLog_execmemcache
4680837 02.05.2018 20:57:30 LogDBShort DbLog_execmemcache
4432648 02.05.2018 23:05:05 MelderCP1.alive.check at_Exec
4495958 02.05.2018 23:20:18 MelderHE1.alive.check at_Exec
4478350 02.05.2018 23:16:05 MelderKE.alive.check at_Exec
4569795 02.05.2018 23:38:05 MelderTER.alive.check at_Exec
4673354 02.05.2018 21:14:35 MyWetter Weather_GetUpdate
4683003 02.05.2018 20:57:05 NP3500_Aussen PHILIPS_AUDIO_GetStatus
4680599 02.05.2018 20:56:36 NP3700_Bad PHILIPS_AUDIO_GetStatus
4682889 02.05.2018 20:57:05 NP3700_any PHILIPS_AUDIO_GetStatus
4679904 02.05.2018 20:56:52 Nmap.Gateway Nmap_statusRequest
4681085 02.05.2018 20:57:42 SDS1_SVS SSCam_wdpollcaminfo
4681340 02.05.2018 20:58:58 SDS1_SVS SSCam_getcaminfoall
4666085 02.05.2018 21:03:01 Sonnenstrom SHM_CallInfo
4680835 02.05.2018 20:56:39 Sonnenstrom delcookiefile
4666322 02.05.2018 20:58:04 Sonnenstrom_Relative SHMForecastRelative_Parse
4682158 02.05.2018 20:56:36 Sonos SONOS_IsSubprocessAliveChecker
4620524 03.05.2018 20:45:06 Wandregallampe.An at_Exec
4544403 03.05.2018 20:28:26 Whiskyregal.An at_Exec
4551930 03.05.2018 20:30:06 eg_wz_westfenster.An at_Exec
1224692 03.05.2018 04:33:49 eg_wz_westfenster.An1 at_Exec
591534 02.05.2018 23:25:00 eg_wz_westfenster.Aus at_Exec
1410637 03.05.2018 05:48:52 eg_wz_westfenster.Aus1 at_Exec
4301776 02.05.2018 21:33:00 fhem.write.statefile at_Exec
4675443 02.05.2018 20:57:17 googlenexus.fully FULLY_UpdateDeviceInfo
4670997 02.05.2018 21:04:03 graylog Log2Syslog_trate
4680366 02.05.2018 20:57:03 heartbeat at_Exec
4674516 02.05.2018 20:57:49 og.bad.ladestation TPLinkHS110_Get
4548012 03.05.2018 20:29:16 og_gz_westfenster.An at_Exec
1157459 03.05.2018 04:05:29 og_gz_westfenster.An1 at_Exec
625287 02.05.2018 23:45:00 og_gz_westfenster.Aus at_Exec
1410514 03.05.2018 05:48:49 og_gz_westfenster.Aus1 at_Exec
4669830 02.05.2018 20:58:55 recalc_Bezug at_Exec
4648497 02.05.2018 22:54:21 recalc_Bezug.monatlich at_Exec
4491393 03.05.2018 20:15:00 recalc_Dum.Energy.Quoten.Jahr at_Exec
4550756 02.05.2018 21:03:01 recalc_Dum.Energy.Quoten.Monat at_Exec
4573663 02.05.2018 21:03:01 recalc_Dum.Energy.Quoten.heute at_Exec
4671926 02.05.2018 20:59:16 recalc_Einspeisung at_Exec
4643792 02.05.2018 22:53:17 recalc_Einspeisung.monatlich at_Exec
4670762 02.05.2018 20:58:45 recalc_Erzeugung at_Exec
4625102 02.05.2018 22:49:01 recalc_Erzeugung.monatlich at_Exec
4680603 02.05.2018 20:56:51 samsunggalaxy.fully FULLY_UpdateDeviceInfo
4670995 02.05.2018 21:04:03 sds1log Log2Syslog_trate
4670996 02.05.2018 21:04:03 splunklog Log2Syslog_trate
660282 03.05.2018 00:05:00 sun_riseSet_timer at_Exec
4682774 02.05.2018 20:57:34 sysmon SYSMON_Update
4682041 02.05.2018 20:59:00 tplink.energymeter TPLinkHS110_Get
4666788 02.05.2018 20:59:49 trafficsaw Verkehrsinfo_GetUpdate
4682770 02.05.2018 20:57:33 withings withings_poll
4682772 02.05.2018 20:57:33 withings_D4592954 withings_poll
4682771 02.05.2018 20:57:33 withings_U13636180 withings_poll
4682773 02.05.2018 20:57:33 withings_U13702823 withings_poll


Merkwürdig kommen mir die Einträge "HttpUtils_Err" vor, kann sie aber momentan nicht einordnen.

Alles in allem sicher noch nicht der Durchbruch, aber zumindest bei mir gefühlt besser als mit der vorherigen Version.
Ich werde jetzt die vorher verwendete fhem.pl wieder aktivieren und nochmal eine Vergleichsmessung starten um etwas genauere Werte
zum Vergleich zu haben.

Bevor ich die alte fhem.pl wieder verwende, habe ich den InternalTimer-Hash gelöscht mit {%intAt = ()}. Danach ging die CPU-Last
wieder runter auf ca. 0.63%. Merkwürdigerweise wurden die Einträge "HttpUtils_Err" dabei nicht beseitigt.

Das System ist jetzt wieder gestartet mit Version 16609:

{ int(keys %intAt) }:  126
CPU:                   0,40%
Perl-Hauptprozess:  VIRT:  395252  RES: 193060
Subprozess SONOS:   VIRT:  434192  RES: 78024
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 02 Mai 2018, 21:44:51
@enno, bei dir ist der RAM-Anstieg aber sehr ausgeprägt. Hast du mal "top" auf BS-Ebene angeschaut wie es da bzgl. des perl-Prozesses aussieht ?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 03 Mai 2018, 06:53:01
Hallo Zusammen,

auch bei mir verändert die neue fhem.pl nichts an dem Anstieg, siehe Bild.


{ int(keys %intAt) }: 108
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 03 Mai 2018, 08:32:11
Guten Morgen,

nach rund 10 Stunden (zum Vergleich in #211 waren es 19 Stunden) Laufzeit Zwischenstand mit V 16609:

{ int(keys %intAt) }:  149
Perl-Hauptprozess:     VIRT:  402000  RES: 195848
Subprozess SONOS:   VIRT:  434192  RES: 77608
CPU:                         0,60%

InternalTimer: 149
Number Date/Time Function
81381 04.05.2018 00:00:01 FileLog_dailySwitch
701289 03.05.2018 08:20:41 HttpUtils_Err
701982 03.05.2018 08:15:51 BlockingKill
701984 03.05.2018 08:15:10 HttpUtils_Err
701987 03.05.2018 08:15:10 HttpUtils_Err
701990 03.05.2018 08:15:10 HttpUtils_Err
701993 03.05.2018 08:15:10 HttpUtils_Err
701996 03.05.2018 08:15:10 HttpUtils_Err
701999 03.05.2018 08:15:10 HttpUtils_Err
702002 03.05.2018 08:15:10 HttpUtils_Err
702005 03.05.2018 08:15:10 HttpUtils_Err
702008 03.05.2018 08:15:10 HttpUtils_Err
702011 03.05.2018 08:15:10 HttpUtils_Err
702014 03.05.2018 08:15:10 HttpUtils_Err
702017 03.05.2018 08:15:10 HttpUtils_Err
702020 03.05.2018 08:15:10 HttpUtils_Err
702023 03.05.2018 08:15:10 HttpUtils_Err
702026 03.05.2018 08:15:10 HttpUtils_Err
702029 03.05.2018 08:15:10 HttpUtils_Err
702032 03.05.2018 08:15:10 HttpUtils_Err
702035 03.05.2018 08:15:10 HttpUtils_Err
702038 03.05.2018 08:15:10 HttpUtils_Err
702041 03.05.2018 08:15:10 HttpUtils_Err
702044 03.05.2018 08:15:10 HttpUtils_Err
702047 03.05.2018 08:15:10 HttpUtils_Err
702050 03.05.2018 08:15:10 HttpUtils_Err
702053 03.05.2018 08:15:10 HttpUtils_Err
702056 03.05.2018 08:15:10 HttpUtils_Err
702059 03.05.2018 08:15:10 HttpUtils_Err
702062 03.05.2018 08:15:10 HttpUtils_Err
702065 03.05.2018 08:15:10 HttpUtils_Err
702071 03.05.2018 08:15:11 HttpUtils_Err
17 03.05.2018 17:19:17 17 CUL_HM_statCntRfresh
574817 03.05.2018 10:02:05 574817 SetExtensionsFn
655375 03.05.2018 08:19:17 655375 CUL_HM_complConfigTO
684362 03.05.2018 08:15:28 684362 HTTPMOD_GetUpdate
688096 03.05.2018 08:19:18 688096 HMinfo_autoUpdate
692030 03.05.2018 08:19:28 692030 CUL_HM_ActCheck
692040 03.05.2018 08:19:29 692040 HTTPMOD_GetUpdate
693183 03.05.2018 08:20:18 693183 HTTPMOD_GetUpdate
701539 03.05.2018 08:15:07 701539 HMLAN_KeepAlive
701543 03.05.2018 08:15:08 701543 HMLAN_KeepAlive
701717 03.05.2018 08:15:49 701717 FW_closeInactiveClients
701802 03.05.2018 08:24:58 701802 HTTPMOD_GetUpdate
701893 03.05.2018 08:15:05 701893 NUT_PollTimer
81389 04.05.2018 00:00:02 81389 holiday_refresh
567 03.05.2018 20:45:06 AT.au.lichtkette.he.An at_Exec
372579 04.05.2018 04:45:07 AT.au.lichtkette.he.An1 at_Exec
71601 03.05.2018 23:45:00 AT.au.lichtkette.he.Aus at_Exec
459700 04.05.2018 05:46:50 AT.au.lichtkette.he.Aus1 at_Exec
743 03.05.2018 21:15:06 AT.au.weihnachtsstern.An at_Exec
53236 03.05.2018 23:15:00 AT.au.weihnachtsstern.Aus at_Exec
969 03.05.2018 09:19:28 AllCalView CALVIEW_GetUpdate
454051 04.05.2018 05:45:00 At.AllCalView.Update at_Exec
403 03.05.2018 18:45:00 At.AllCalView.Update.Abend at_Exec
389754 04.05.2018 05:00:00 At.Apptime.Clear at_Exec
701980 03.05.2018 08:17:18 At.Check.HouseOpen at_Exec
578 05.05.2018 21:19:18 At.DbRep.LogDB.FindNaDevs at_Exec
655476 03.05.2018 08:34:18 At.Del.All_Pwr_power at_Exec
399 03.05.2018 21:04:18 At.Del.DbShort at_Exec
382 03.05.2018 21:22:18 At.Del.Sonnenstrom_Relative at_Exec
132 03.05.2018 20:48:26 At.Fensterlichter.EG.Westseite.An at_Exec
75910 03.05.2018 23:52:00 At.Fhem.Dump at_Exec
673554 03.05.2018 08:19:18 At.Fhem.Size at_Exec
62440 03.05.2018 23:30:00 At.FhemShort.Dump at_Exec
438656 03.05.2018 13:49:20 At.LogDB.currentPurge at_Exec
286694 03.05.2018 09:59:18 At.LogDB.sqlResult at_Exec
691765 03.05.2018 08:19:20 At.LogDBShort.Addlog.FSM1.level at_Exec
482730 03.05.2018 14:49:20 At.LogDBShort.currentPurge at_Exec
231118 04.05.2018 02:50:00 At.MariaDBs.reopen at_Exec
644593 03.05.2018 08:35:18 At.PhilipsAudio.GetRadioFav at_Exec
691767 03.05.2018 08:34:20 At.Rep.CPU at_Exec
801 03.05.2018 09:19:20 At.Rep.Fully.DelSeqDoublets at_Exec
172581 04.05.2018 01:52:00 At.Rep.Temp.Current.Month at_Exec
670038 03.05.2018 08:19:20 At.Rep.az.fridge.kWh at_Exec
688102 03.05.2018 08:19:20 At.Rep.server.kWh at_Exec
684097 03.05.2018 08:20:50 At.og.bad.ladestation at_Exec
588186 04.05.2018 07:10:00 Bad.Radio.WT.An at_Exec
507453 03.05.2018 09:20:09 Baikal.Abfall Calendar_Wakeup
684899 03.05.2018 08:22:29 Baikal.Heiko Calendar_Wakeup
695296 03.05.2018 08:15:07 CamCP1 SSCam_getcaminfoall
699519 03.05.2018 08:15:07 CamCP1 SSCam_wdpollcaminfo
696303 03.05.2018 08:15:50 CamGW1 SSCam_getcaminfoall
699951 03.05.2018 08:15:21 CamGW1 SSCam_wdpollcaminfo
699690 03.05.2018 08:15:13 CamHE1 SSCam_wdpollcaminfo
700575 03.05.2018 08:17:42 CamHE1 SSCam_getcaminfoall
700129 03.05.2018 08:15:29 CamKE1 SSCam_wdpollcaminfo
701047 03.05.2018 08:17:58 CamKE1 SSCam_getcaminfoall
698792 03.05.2018 08:17:25 CamTER SSCam_getcaminfoall
699521 03.05.2018 08:15:07 CamTER SSCam_wdpollcaminfo
475925 04.05.2018 06:00:00 FHEMBackup at_Exec
166 03.05.2018 21:00:00 FHEMBackup1 at_Exec
1267 03.05.2018 21:19:29 Feiertage.ST Calendar_Wakeup
317742 04.05.2018 04:04:59 Fensterlichter.eg.westseite.An1 at_Exec
65504 03.05.2018 23:35:00 Fensterlichter.eg.westseite.Aus at_Exec
456019 04.05.2018 05:44:17 Fensterlichter.eg.westseite.Aus1 at_Exec
71600 03.05.2018 23:45:00 Kaminzimmer.Licht.Aus at_Exec
700222 03.05.2018 08:15:12 LogDB DbLog_execmemcache
701541 03.05.2018 08:16:02 LogDBShort DbLog_execmemcache
520079 03.05.2018 09:30:58 MelderCP1.alive.check at_Exec
526590 03.05.2018 09:36:30 MelderHE1.alive.check at_Exec
524730 03.05.2018 09:34:58 MelderKE.alive.check at_Exec
534225 03.05.2018 09:42:58 MelderTER.alive.check at_Exec
674877 03.05.2018 08:20:01 MyWetter Weather_GetUpdate
702066 03.05.2018 08:15:30 NP3500_Aussen PHILIPS_AUDIO_GetStatus
702069 03.05.2018 08:15:31 NP3700_Bad PHILIPS_AUDIO_GetStatus
702024 03.05.2018 08:15:30 NP3700_any PHILIPS_AUDIO_GetStatus
701981 03.05.2018 08:15:52 Nmap.Gateway Nmap_statusRequest
699866 03.05.2018 08:15:20 SDS1_SVS SSCam_wdpollcaminfo
701263 03.05.2018 08:17:16 SDS1_SVS SSCam_getcaminfoall
691714 03.05.2018 08:19:18 Sonnenstrom SHM_CallInfo
701367 03.05.2018 08:15:07 Sonnenstrom delcookiefile
700779 03.05.2018 08:19:18 Sonnenstrom_Relative SHMForecastRelative_Parse
701895 03.05.2018 08:15:06 Sonos SONOS_IsSubprocessAliveChecker
138 03.05.2018 20:45:06 Wandregallampe.An at_Exec
136 03.05.2018 20:28:26 Whiskyregal.An at_Exec
149 03.05.2018 20:30:06 eg_wz_westfenster.An at_Exec
354876 04.05.2018 04:31:47 eg_wz_westfenster.An1 at_Exec
59354 03.05.2018 23:25:00 eg_wz_westfenster.Aus at_Exec
459699 04.05.2018 05:46:50 eg_wz_westfenster.Aus1 at_Exec
603960 03.05.2018 09:19:18 fhem.write.statefile at_Exec
700308 03.05.2018 08:16:20 googlenexus.fully FULLY_UpdateDeviceInfo
693539 03.05.2018 08:20:20 graylog Log2Syslog_trate
700782 03.05.2018 08:15:20 heartbeat at_Exec
700309 03.05.2018 08:17:05 og.bad.ladestation TPLinkHS110_Get
83 03.05.2018 20:29:16 og_gz_westfenster.An at_Exec
318323 04.05.2018 04:03:59 og_gz_westfenster.An1 at_Exec
71599 03.05.2018 23:45:00 og_gz_westfenster.Aus at_Exec
459628 04.05.2018 05:46:47 og_gz_westfenster.Aus1 at_Exec
692914 03.05.2018 08:15:02 recalc_Bezug at_Exec
647207 03.05.2018 09:49:48 recalc_Bezug.monatlich at_Exec
630 03.05.2018 20:15:00 recalc_Dum.Energy.Quoten.Jahr at_Exec
655474 03.05.2018 08:24:18 recalc_Dum.Energy.Quoten.Monat at_Exec
655472 03.05.2018 08:19:18 recalc_Dum.Energy.Quoten.heute at_Exec
695671 03.05.2018 08:16:28 recalc_Einspeisung at_Exec
646527 03.05.2018 09:49:24 recalc_Einspeisung.monatlich at_Exec
701674 03.05.2018 08:19:33 recalc_Erzeugung at_Exec
644183 03.05.2018 09:47:48 recalc_Erzeugung.monatlich at_Exec
701411 03.05.2018 08:15:22 samsunggalaxy.fully FULLY_UpdateDeviceInfo
693537 03.05.2018 08:20:20 sds1log Log2Syslog_trate
693538 03.05.2018 08:20:20 splunklog Log2Syslog_trate
85098 04.05.2018 00:05:00 sun_riseSet_timer at_Exec
700780 03.05.2018 08:15:18 sysmon SYSMON_Update
698522 03.05.2018 08:15:38 tplink.energymeter TPLinkHS110_Get
698079 03.05.2018 08:19:29 trafficsaw Verkehrsinfo_GetUpdate
701048 03.05.2018 08:15:28 withings withings_poll
701051 03.05.2018 08:15:28 withings_D4592954 withings_poll
701050 03.05.2018 08:15:28 withings_U13636180 withings_poll
701052 03.05.2018 08:15:28 withings_U13702823 withings_poll


Die Anzahl der InternalTimer-Einträge ist gewachsen und es tauchen wieder die "HttpUtils_Err" Einträge auf.

@Nighthawk, schau dooch auch mal mit "top" auf die RAM-Auslastung durch die Perl-Prozesse und beobachte ob diese Prozesse mehr RAM benötigen. Evtl. kommt der gemessene RAM-Verbrauch auch von einem anderen Prozess.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 03 Mai 2018, 08:47:38
Laut top belegt fhem ~400mb.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 03 Mai 2018, 09:01:32
Zitat von: DS_Starter am 02 Mai 2018, 21:44:51
@enno, bei dir ist der RAM-Anstieg aber sehr ausgeprägt. Hast du mal "top" auf BS-Ebene angeschaut wie es da bzgl. des perl-Prozesses aussieht ?

Ich schreibe jetzt mal die Daten aus Top mit, melde mich mit Ergebnissen morgen...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 03 Mai 2018, 09:58:38
ZitatDie Anzahl der InternalTimer-Einträge ist gewachsen
Von wieviel?

Zitatund es tauchen wieder die "HttpUtils_Err" Einträge auf.
Das ist normal fuer jeden HttpUtils_NonblockingGet. Ich habe 30 gezaehlt, ist das realistisch?
Alle anderen scheinen eindeutig und "sinnvoll" zu sein, und die timeouts auch.
Uebrigens: selbst wenn alle 150 Timeout-Funktionen "vergessen" waeren, wuerde das noch nicht die 100+ MB an Speicherverlust erklaeren.

Ich vermute, dass wir mehrere unterschiedliche Ursachen mit dem gleichen Resultat (Speicherzuwachs) haben. Diese Diskussion hat am Anfang suggeriert, dass das Problem nur auf einem RPi nach dem Umstieg auf die aktuelle OS-Version auftritt, was ein Programmierfehler in einem der Module ausschliessen wuerde. Da das Betreff aber zu allgemein gewaehlt ist, werden hier auch andere Ursachen gemeldet, was zur erfolgreichen Verwirrung aller fuehrt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 03 Mai 2018, 11:00:51
Hallo Rudi,

ZitatVon wieviel?
126 bei Start

ZitatDas ist normal fuer jeden HttpUtils_NonblockingGet. Ich habe 30 gezaehlt, ist das realistisch?
Dann ist es erklärbar und durchaus realistisch. Ich arbeite bei der Kamerasteuerung sehr intensiv mit HttpUtils_NonblockingGet.
Gewundert hat mich nur dass ich immer nur einen Anstieg dieser Einträge beobachtet hatte und es meiner Meinung nach in einem eingeschwungenen Zustand irgendwann stagnieren sollte. Aber vielleicht sind die Beobachtungszeiträume noch zu kurz.

Die Timereinträge sind meinen Erkenntnissen nach auch nur an der Grundlast der CPU beteiligt. Mehr Einträge -> mehr Grundlast. Beim RAM eher nicht.
Das ich viel RAM benötige, ist für mich auch nachvollziehbar und ok und nach den neuesten Erkenntnissen die ich über top erzielt habe, bleibt die RAM Auslastung ab einem bestimmten level weitgehend gleich.
Fehlermitteilungen im Sinne des Threads gibt es bei mir auch nicht.

ZitatIch vermute, dass wir mehrere unterschiedliche Ursachen mit dem gleichen Resultat (Speicherzuwachs) haben.
Bin ich komplett bei dir. Das Thema ist eben sehr komplex und schwer zu fassen.
Da müssen wir wohl weitersuchen ...

Grüße,
Heiko

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 03 Mai 2018, 18:45:46
Hallo Rudi,

inzwischen sind die Timereinträge auf 171 angewachsen und davon sind  53 "HttpUtils_Err".


InternalTimer: 171
Number Date/Time Function
81381 04.05.2018 00:00:01 FileLog_dailySwitch
2231124 03.05.2018 18:27:13 HttpUtils_Err
2231767 03.05.2018 18:22:15 BlockingKill
2231932 03.05.2018 18:21:34 HttpUtils_Err
2231935 03.05.2018 18:21:34 HttpUtils_Err
2231938 03.05.2018 18:21:34 HttpUtils_Err
2231941 03.05.2018 18:21:34 HttpUtils_Err
2231944 03.05.2018 18:21:34 HttpUtils_Err
2231947 03.05.2018 18:21:34 HttpUtils_Err
2231950 03.05.2018 18:21:34 HttpUtils_Err
2231953 03.05.2018 18:21:34 HttpUtils_Err
2231956 03.05.2018 18:21:34 HttpUtils_Err
2231959 03.05.2018 18:21:34 HttpUtils_Err
2231962 03.05.2018 18:21:34 HttpUtils_Err
2231965 03.05.2018 18:21:34 HttpUtils_Err
2231968 03.05.2018 18:21:34 HttpUtils_Err
2231971 03.05.2018 18:21:34 HttpUtils_Err
2231974 03.05.2018 18:21:34 HttpUtils_Err
2231977 03.05.2018 18:21:34 HttpUtils_Err
2231980 03.05.2018 18:21:34 HttpUtils_Err
2231983 03.05.2018 18:21:34 HttpUtils_Err
2231986 03.05.2018 18:21:34 HttpUtils_Err
2231989 03.05.2018 18:21:34 HttpUtils_Err
2231992 03.05.2018 18:21:34 HttpUtils_Err
2231995 03.05.2018 18:21:34 HttpUtils_Err
2231998 03.05.2018 18:21:34 HttpUtils_Err
2232001 03.05.2018 18:21:34 HttpUtils_Err
2232004 03.05.2018 18:21:34 HttpUtils_Err
2232007 03.05.2018 18:21:34 HttpUtils_Err
2232010 03.05.2018 18:21:34 HttpUtils_Err
2232013 03.05.2018 18:21:34 HttpUtils_Err
2232016 03.05.2018 18:21:34 HttpUtils_Err
2232019 03.05.2018 18:21:34 HttpUtils_Err
2232022 03.05.2018 18:21:34 HttpUtils_Err
2232025 03.05.2018 18:21:34 HttpUtils_Err
2232028 03.05.2018 18:21:34 HttpUtils_Err
2232031 03.05.2018 18:21:34 HttpUtils_Err
2232034 03.05.2018 18:21:34 HttpUtils_Err
2232037 03.05.2018 18:21:34 HttpUtils_Err
2232040 03.05.2018 18:21:34 HttpUtils_Err
2232043 03.05.2018 18:21:34 HttpUtils_Err
2232046 03.05.2018 18:21:34 HttpUtils_Err
2232049 03.05.2018 18:21:34 HttpUtils_Err
2232052 03.05.2018 18:21:34 HttpUtils_Err
2232055 03.05.2018 18:21:34 HttpUtils_Err
2232058 03.05.2018 18:21:34 HttpUtils_Err
2232061 03.05.2018 18:21:34 HttpUtils_Err
2232064 03.05.2018 18:21:34 HttpUtils_Err
2232067 03.05.2018 18:21:34 HttpUtils_Err
2232070 03.05.2018 18:21:34 HttpUtils_Err
2232073 03.05.2018 18:21:34 HttpUtils_Err
2232076 03.05.2018 18:21:34 HttpUtils_Err
2232079 03.05.2018 18:21:34 HttpUtils_Err
2232082 03.05.2018 18:21:34 HttpUtils_Err
2232085 03.05.2018 18:21:34 HttpUtils_Err
2035612 04.05.2018 13:19:17 2035612 CUL_HM_statCntRfresh
2224940 03.05.2018 18:49:17 2224940 CUL_HM_complConfigTO
2225116 03.05.2018 18:31:19 2225116 HMinfo_autoUpdate
2225611 03.05.2018 18:29:29 2225611 CUL_HM_ActCheck
2225618 03.05.2018 18:29:29 2225618 HTTPMOD_GetUpdate
2226976 03.05.2018 18:29:59 2226976 HTTPMOD_GetUpdate
2227828 03.05.2018 18:30:18 2227828 HTTPMOD_GetUpdate
2228156 03.05.2018 18:30:28 2228156 HTTPMOD_GetUpdate
2230807 03.05.2018 18:21:27 2230807 HMLAN_KeepAlive
2231126 03.05.2018 18:21:33 2231126 HMLAN_KeepAlive
2231605 03.05.2018 18:22:18 2231605 FW_closeInactiveClients
2231762 03.05.2018 18:21:29 2231762 NUT_PollTimer
81389 04.05.2018 00:00:02 81389 holiday_refresh
567 03.05.2018 20:45:06 AT.au.lichtkette.he.An at_Exec
372579 04.05.2018 04:45:07 AT.au.lichtkette.he.An1 at_Exec
71601 03.05.2018 23:45:00 AT.au.lichtkette.he.Aus at_Exec
459700 04.05.2018 05:46:50 AT.au.lichtkette.he.Aus1 at_Exec
743 03.05.2018 21:15:06 AT.au.weihnachtsstern.An at_Exec
53236 03.05.2018 23:15:00 AT.au.weihnachtsstern.Aus at_Exec
824000 03.05.2018 21:19:28 AllCalView CALVIEW_GetUpdate
454051 04.05.2018 05:45:00 At.AllCalView.Update at_Exec
403 03.05.2018 18:45:00 At.AllCalView.Update.Abend at_Exec
389754 04.05.2018 05:00:00 At.Apptime.Clear at_Exec
2231448 03.05.2018 18:23:36 At.Check.HouseOpen at_Exec
578 05.05.2018 21:19:18 At.DbRep.LogDB.FindNaDevs at_Exec
2225111 03.05.2018 19:04:18 At.Del.All_Pwr_power at_Exec
399 03.05.2018 21:04:18 At.Del.DbShort at_Exec
382 03.05.2018 21:22:18 At.Del.Sonnenstrom_Relative at_Exec
132 03.05.2018 20:48:26 At.Fensterlichter.EG.Westseite.An at_Exec
75910 03.05.2018 23:52:00 At.Fhem.Dump at_Exec
2225105 03.05.2018 18:39:18 At.Fhem.Size at_Exec
62440 03.05.2018 23:30:00 At.FhemShort.Dump at_Exec
1439916 03.05.2018 22:04:20 At.LogDB.currentPurge at_Exec
1855196 03.05.2018 22:39:18 At.LogDB.sqlResult at_Exec
2225124 03.05.2018 18:29:20 At.LogDBShort.Addlog.FSM1.level at_Exec
1600073 03.05.2018 23:34:20 At.LogDBShort.currentPurge at_Exec
231118 04.05.2018 02:50:00 At.MariaDBs.reopen at_Exec
2186143 03.05.2018 18:59:18 At.PhilipsAudio.GetRadioFav at_Exec
2192674 03.05.2018 18:34:20 At.Rep.CPU at_Exec
823717 03.05.2018 21:19:20 At.Rep.Fully.DelSeqDoublets at_Exec
172581 04.05.2018 01:52:00 At.Rep.Temp.Current.Month at_Exec
2205740 03.05.2018 18:35:20 At.Rep.az.fridge.kWh at_Exec
2225122 03.05.2018 18:31:20 At.Rep.server.kWh at_Exec
2225127 03.05.2018 18:35:05 At.og.bad.ladestation at_Exec
588186 04.05.2018 07:10:00 Bad.Radio.WT.An at_Exec
2229659 03.05.2018 21:20:49 Baikal.Abfall Calendar_Wakeup
2219349 03.05.2018 18:34:29 Baikal.Heiko Calendar_Wakeup
2229983 03.05.2018 18:24:37 CamCP1 SSCam_getcaminfoall
2231127 03.05.2018 18:22:39 CamCP1 SSCam_wdpollcaminfo
2226872 03.05.2018 18:23:51 CamGW1 SSCam_getcaminfoall
2231925 03.05.2018 18:22:52 CamGW1 SSCam_wdpollcaminfo
2226440 03.05.2018 18:23:13 CamHE1 SSCam_getcaminfoall
2231445 03.05.2018 18:22:43 CamHE1 SSCam_wdpollcaminfo
2227315 03.05.2018 18:23:28 CamKE1 SSCam_getcaminfoall
2227494 03.05.2018 18:21:30 CamKE1 SSCam_wdpollcaminfo
2228831 03.05.2018 18:24:38 CamTER SSCam_getcaminfoall
2231128 03.05.2018 18:22:39 CamTER SSCam_wdpollcaminfo
475925 04.05.2018 06:00:00 FHEMBackup at_Exec
166 03.05.2018 21:00:00 FHEMBackup1 at_Exec
1267 03.05.2018 21:19:29 Feiertage.ST Calendar_Wakeup
317742 04.05.2018 04:04:59 Fensterlichter.eg.westseite.An1 at_Exec
65504 03.05.2018 23:35:00 Fensterlichter.eg.westseite.Aus at_Exec
456019 04.05.2018 05:44:17 Fensterlichter.eg.westseite.Aus1 at_Exec
71600 03.05.2018 23:45:00 Kaminzimmer.Licht.Aus at_Exec
2230145 03.05.2018 18:21:58 LogDB DbLog_execmemcache
2227827 03.05.2018 18:21:27 LogDBShort DbLog_execmemcache
1732267 03.05.2018 18:39:43 MelderCP1.alive.check at_Exec
1756218 03.05.2018 18:49:24 MelderHE1.alive.check at_Exec
1749586 03.05.2018 18:46:43 MelderKE.alive.check at_Exec
1784238 03.05.2018 19:00:43 MelderTER.alive.check at_Exec
2228848 03.05.2018 18:40:27 MyWetter Weather_GetUpdate
2232086 03.05.2018 18:21:54 NP3500_Aussen PHILIPS_AUDIO_GetStatus
2231928 03.05.2018 18:21:54 NP3700_Bad PHILIPS_AUDIO_GetStatus
2232008 03.05.2018 18:21:54 NP3700_any PHILIPS_AUDIO_GetStatus
2230331 03.05.2018 18:21:49 Nmap.Gateway Nmap_statusRequest
2228651 03.05.2018 18:23:05 SDS1_SVS SSCam_getcaminfoall
2231768 03.05.2018 18:22:50 SDS1_SVS SSCam_wdpollcaminfo
2225102 03.05.2018 18:29:18 Sonnenstrom SHM_CallInfo
2231129 03.05.2018 18:21:39 Sonnenstrom delcookiefile
2225119 03.05.2018 18:24:19 Sonnenstrom_Relative SHMForecastRelative_Parse
2231764 03.05.2018 18:21:30 Sonos SONOS_IsSubprocessAliveChecker
138 03.05.2018 20:45:06 Wandregallampe.An at_Exec
136 03.05.2018 20:28:26 Whiskyregal.An at_Exec
149 03.05.2018 20:30:06 eg_wz_westfenster.An at_Exec
354876 04.05.2018 04:31:47 eg_wz_westfenster.An1 at_Exec
59354 03.05.2018 23:25:00 eg_wz_westfenster.Aus at_Exec
459699 04.05.2018 05:46:50 eg_wz_westfenster.Aus1 at_Exec
2035618 03.05.2018 19:19:18 fhem.write.statefile at_Exec
2227997 03.05.2018 18:22:26 googlenexus.fully FULLY_UpdateDeviceInfo
2228489 03.05.2018 18:30:20 graylog Log2Syslog_trate
2231765 03.05.2018 18:22:20 heartbeat at_Exec
2227669 03.05.2018 18:23:05 og.bad.ladestation TPLinkHS110_Get
83 03.05.2018 20:29:16 og_gz_westfenster.An at_Exec
318323 04.05.2018 04:03:59 og_gz_westfenster.An1 at_Exec
71599 03.05.2018 23:45:00 og_gz_westfenster.Aus at_Exec
459628 04.05.2018 05:46:47 og_gz_westfenster.Aus1 at_Exec
2227304 03.05.2018 18:25:02 recalc_Bezug at_Exec
2195331 03.05.2018 20:15:13 recalc_Bezug.monatlich at_Exec
630 03.05.2018 20:15:00 recalc_Dum.Energy.Quoten.Jahr at_Exec
2225109 03.05.2018 18:54:18 recalc_Dum.Energy.Quoten.Monat at_Exec
2225107 03.05.2018 18:49:18 recalc_Dum.Energy.Quoten.heute at_Exec
2222394 03.05.2018 18:23:29 recalc_Einspeisung at_Exec
2193167 03.05.2018 20:14:29 recalc_Einspeisung.monatlich at_Exec
2220955 03.05.2018 18:22:48 recalc_Erzeugung at_Exec
2184601 03.05.2018 20:11:33 recalc_Erzeugung.monatlich at_Exec
2230965 03.05.2018 18:21:48 samsunggalaxy.fully FULLY_UpdateDeviceInfo
2228487 03.05.2018 18:30:20 sds1log Log2Syslog_trate
2228488 03.05.2018 18:30:20 splunklog Log2Syslog_trate
85098 04.05.2018 00:05:00 sun_riseSet_timer at_Exec
2231766 03.05.2018 18:22:20 sysmon SYSMON_Update
2227915 03.05.2018 18:22:44 tplink.energymeter TPLinkHS110_Get
2225612 03.05.2018 18:26:09 trafficsaw Verkehrsinfo_GetUpdate
2229489 03.05.2018 18:21:37 withings withings_poll
2229491 03.05.2018 18:21:37 withings_D4592954 withings_poll
2229490 03.05.2018 18:21:37 withings_U13636180 withings_poll
2229492 03.05.2018 18:21:37 withings_U13702823 withings_poll


Ich habe mir HttpUtils angeschaut, aber die Logik hinter den InternalTimer-"HttpUtils_Err" Generierungen noch nicht durchschaut.
Wenn dieser Eintrag für einen aktuell laufenden HttpUtils_NonblockingGet gilt, dann wären das sicher zu viele.
Auch der identische Zeitstempel der "HttpUtils_Err" Einträge irritiert mich.

Die Einträge müssten doch auch mal abgebaut bzw. gelöscht werden ?

Wahrscheinlich ist dieses Thema aber nicht mehr passend zu diesem Thread. Deswegen würde ich vllt. das Thema nochmal separat nach meinem Urlaub (stecke gerade in den Vorbereitungen) ansprechen wenn es keine einfache Erklärung dafür geben sollte.

Grüße,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 03 Mai 2018, 20:12:43
Zitat von: enno am 03 Mai 2018, 09:01:32
Ich schreibe jetzt mal die Daten aus Top mit, melde mich mit Ergebnissen morgen...

Hier die Daten aus TOP zur vollen Stunde:
PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND

12:00 Uhr
28331 fhem      20   0  323204 209848  11052 S   0,0  5,3  86:23.38 perl
28359 fhem      20   0  247264 131980   4292 S   0,0  3,4   1:28.48 perl
28363 fhem      20   0  247604 131336   3220 S   0,0  3,3   0:00.00 perl

13:00 Uhr
28331 fhem      20   0  323348 209908  11052 S   1,7  5,3  86:31.24 perl
28359 fhem      20   0  247264 131980   4292 S   0,0  3,4   1:28.61 perl
28363 fhem      20   0  247604 131336   3220 S   0,0  3,3   0:00.00 perl

14:00 Uhr
28331 fhem      20   0  325140 211696  11052 S   3,3  5,4  88:19.45 perl
28359 fhem      20   0  247264 131980   4292 S   0,0  3,4   1:30.78 perl
28363 fhem      20   0  247604 131336   3220 S   0,0  3,3   0:00.00 perl 

15:00 Uhr
28331 fhem      20   0  329648 216260  11052 S   3,3  5,5  90:15.47 perl
26819 fhem      20   0  325764 204352   2920 S   0,0  5,2   0:00.01 perl
28359 fhem      20   0  247264 131980   4292 S   0,0  3,4   1:33.03 perl 

16:00 Uhr
28331 fhem      20   0  329648 216260  11052 S  13,6  5,5  92:08.94 perl
26819 fhem      20   0  325764 204352   2920 S   0,0  5,2   0:00.01 perl
28359 fhem      20   0  247264 131980   4292 S   0,0  3,4   1:35.26 perl

17:00 Uhr
28331 fhem      20   0  329648 216260  11052 S  14,2  5,5  94:01.75 perl   
28946 fhem      20   0  329648 209988   4780 S   0,7  5,3   0:00.02 perl
26819 fhem      20   0  325764 204352   2920 S   0,0  5,2   0:00.01 perl
28359 fhem      20   0  247264 131980   4292 S   0,0  3,4   1:37.43 perl 

18:00 Uhr
28331 fhem      20   0  330480 217096  11052 S  14,2  5,5  95:53.29 perl
26819 fhem      20   0  325764 204352   2920 S   0,0  5,2   0:00.01 perl
28359 fhem      20   0  247264 131980   4292 S   0,0  3,4   1:39.53 perl

19:00 Uhr
28331 fhem      20   0  332056 218920  11352 S   2,6  5,6  97:46.94 perl
26819 fhem      20   0  325764 204352   2920 S   0,0  5,2   0:00.01 perl   
28359 fhem      20   0  247264 131980   4292 S   0,0  3,4   1:41.76 perl 

19:42 Uhr
28331 fhem      20   0  333480 220360  11352 S   3,6  5,6  99:10.44 perl
26819 fhem      20   0  325764 204352   2920 S   0,0  5,2   0:00.01 perl
28359 fhem      20   0  247264 131980   4292 S   0,0  3,4   1:43.30 perl


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 07 Mai 2018, 14:58:26
Status:
Ich habe mich längere Zeit mit den Systemem Tests durchgeführt um den Speicheranstieg eingrenzen zu können.

Folgende Erkenntnisse:
Systeme mit Raspberrys Pi3 und Pi3+ mit aktuellem FHEM und Jessie Lite Stratch inklusive aktuellen Updates.
Bei Systeme die kein DOIF verwenden bleibt der Speicher konstant über längerem Zeitraum.
Systeme mit DOIF und keinem Attribut do Always ist ein leichter Speicheranstieg über längerem Zeitraum zu beobachten.
Systeme mit DOIF und dem Attribut do Always ist ein starker Speicheranstieg über kürzerem Zeitraum zu beobachten.

Vielleicht kann das jemand anderer auf DIOF bezogen auch testen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 07 Mai 2018, 17:56:35
Interessant wäre noch eine Aussage, wieviel DOIFs du verwendest.

Ich verwende DOIFs nur dann, wenn ich mit Notify nicht zum Ziel gekommen bin ::). Meine Systeme:

Produktiv
5 DOIF, 1mal mit do always
36 Notify
4 watchdogs
läuft unauffällig seit dem 20.03.2018

Gäste-WC (MPD/MPC)
2 DOIFs, 1mal mit do always
0 Notify
0 watchdogs
System hatte nie Probleme
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 07 Mai 2018, 19:49:16
Zitat von: Brice am 07 Mai 2018, 17:56:35
Gäste-WC (MPD/MPC)
2 DOIFs, 1mal mit do always
...
System hatte nie Probleme

Ich muss mich korrigieren. Mein System Gäste-WC (Signatur FHEM auf RPi 2) hat sehr wohl Probleme, die ich bisher nicht zuordnen konnte. FHEM steigt aus, was nur bemerkt wird, wenn das Radio im Gäste-WC nicht durch den PIR-GPIO eingeschaltet wird. Über Putty komme ich dann nicht mehr auf den Pi, es ist ein harter Reboot (Strom ab) notwendig.

...Und mein für das Produktivsystem erstelltes Notify zum shutdown/restart bei Speicherauslastung hatte ich nicht implementiert...

Gerade gesehen:
2018-05-07_08:51:54 sysmon ram_used: 302.10
2018-05-07_08:50:55 sysmon ram_used: 302.10
2018-05-07_08:50:53 sysmon ram_used: 302.17
2018-05-07_08:49:54 sysmon ram_used: 302.17
2018-05-07_08:49:53 sysmon ram_used: 99.84
2018-05-07_08:48:53 sysmon ram_used: 99.84
2018-05-07_08:48:53 sysmon ram_used: 100.39
2018-05-07_08:47:53 sysmon ram_used: 100.39
2018-05-07_08:47:53 sysmon ram_used: 99.45
2018-05-07_08:46:53 sysmon ram_used: 99.45
2018-05-07_08:46:53 sysmon ram_used: 99.76
2018-05-07_08:45:53 sysmon ram_used: 99.76


Genutzt zum Einschalten hatte ich bisher ein DOIF
(([05:30-07:59] and [?Angelika] eq "present") and [PIR:"on"]) ((set WifiRadio playlist rpr1)(set WifiRadio play))
DOELSEIF
(([08:00-20:59] and [?Angelika] eq "present") and [PIR:"on"]) ((set WifiRadio playlist swr3)(set WifiRadio play))
DOELSEIF
(([21:00-22:00] and [?Angelika] eq "present") and [PIR:"on"]) ((set WifiRadio playlist harmony)(set WifiRadio play))

mit attr do always

Ich habe auf ein Notify umgestellt (keine Ahnung, warum ich das in 2016 nicht hinbekommen habe) und werde weiter das Verhalten weiter beobachten.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 08 Mai 2018, 08:39:04
@Brice
Eigentlich gehört es nicht in diesen Thread aber du hast bei diesem DOIF einige Fehler eingebaut, dashalb hat es auch nicht funktionieren können.
Du musst auf die Klammern aufpassen.
Soweit ich aus deiner Definition entnehmen konnte müsste es so aussehen.
([05:30-07:59] and [?Angelika] eq "present" and [PIR:state] eq "on")
             (set WifiRadio playlist rpr1)(set WifiRadio play)
DOELSEIF
([08:00-20:59] and [?Angelika] eq "present" and [PIR:state] eq "on")
             (set WifiRadio playlist swr3)(set WifiRadio play)
DOELSEIF
([21:00-22:00] and [?Angelika] eq "present" and [PIR:state] eq "on")
             (set WifiRadio playlist harmony)(set WifiRadio play)


Es müsste dieses DOIF auch ohne dem Attribut do always funktionieren.

Um auf das DIOF nochmals zurück zu kommen. Es sind auf meinem Hauptsystem 225 DOIF's.
Wieviele ich davon mit dem Attribut do always versehen sind kann ich nicht genau sagen.
Das war für mich als Anfänger einfacher zu definieren. Ich bin aber dabei einiges davon abzuändern.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 08 Mai 2018, 11:47:59
ZitatWieviele ich davon mit dem Attribut do always versehen sind kann ich nicht genau sagen.
fhem> list a:do=always
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 08 Mai 2018, 14:07:01
@rudolfkoenig
Danke für den Tipp.
Es sind insgesamt 94 DIOFs mit do always
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: SouzA am 09 Mai 2018, 13:38:44
Hi,

ich hab nun einige Zeit laufen lassen und { int(keys %intAt) } ergibt jetzt 89.
Das andere in geschweiften Klammern gibt immer noch Fehlermeldung.
Das Sysmon hatte zwar den im Bild sichtbaren Error gebracht, aber FHEM funktionierte noch.
Abgekackt ist das System erst, als ich "list" gemacht habe um DOIF zu zählen.

91 DOIF
29 DOIF mit do always

Vielleicht bringt das uns ja irgendwie weiter?
Bis denn
SouzA
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 10 Mai 2018, 11:27:02
ZitatDas andere in geschweiften Klammern gibt immer noch Fehlermeldung.
Wenn mit "Das andere" Folgendes gemeint ist:
join("\n", map { "$_->{TRIGGERTIME}, $_->{FN}" } @intAtA) }
und du das von mir zurueckgepatchte fhem.pl verwendest, dann ist es klar, intAtA wurde in diesem fhem.pl explizit auf die Vermutung von Heiko ausgebaut.

ZitatAbgekackt ist das System erst, als ich "list" gemacht habe um DOIF zu zählen.
Das ist sehr merkwuerdig, bzw. vermute ich eher, dass list nicht die Ursache war, sondern es zufaellig zur gleichen Zeit geschah.

ZitatVielleicht bringt das uns ja irgendwie weiter?
Nicht wirklich, verstaerkt nur etwas die Hypothese, dass DOIF der Ausloeser ist.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 10 Mai 2018, 12:44:32
Um das Problem einkreisen zu können, sollte man eins nach dem anderen untersuchen:

Ich habe mal im Testsystem, wo sonst nichts läuft, 10 DOIFs definiert, die jeweils im Sekundentakt einen Dummy auf on setzen. Mal schauen was passiert.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 10 Mai 2018, 13:04:30
ZitatIch habe mal im Testsystem, wo sonst nichts läuft, 10 DOIFs definiert, die jeweils im Sekundentakt einen Dummy auf on setzen.
Auf einem RPi mit dem aktuellen Debian?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 10 Mai 2018, 13:08:30
Zitat von: rudolfkoenig am 10 Mai 2018, 13:04:30
Auf einem RPi mit dem aktuellen Debian?

Nein, bei mir läuft FHEM unter windows. Das sollte aber bei einem Problem in DOIF oder fhem.pl keine Rolle spielen.

Edit:
Ich kann bisher nach 2 Stunden Laufzeit (entspricht 2*3600*10=72000 mal Timer setzen und Dummy auf on setzen) keinen zusätzlichen Speicherbedarf erkennen.

Das ganze FHEM-System (Perlprozess) pendelt zwischen 12 und 20 MB.

This is perl 5, version 24, subversion 0 (v5.24.0) built for MSWin32-x86-multi-thread-64int
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 10 Mai 2018, 20:47:46
Nach neun Stunden Dauerstress 10 Timer pro Sekunde im Testsystem sieht das Ergebnis nicht auffällig aus: 10,5 MB. In meinem umfangreichen Produktionssystem (nur DOIFs, keine notifys oder ats) waren es zwischendurch 50 MB, jetzt sind es 39 MB (siehe Screenshot). Beide FHEM-Systeme sind die letzten neun Stunden durchgelaufen. Ich würde die Schuldigen woanders suchen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: SouzA am 11 Mai 2018, 06:32:21
Hi, vielen Dank für deine Tests.
Aber du musst nun nicht böse sein.
Vielleicht liegt das ja wirklich an was ganz anderem....

Aber eine bescheidene Frage habe ich noch an dich:
DOIFTOOLS lief bei deinem Test auch mit?

Vielleicht kannst du mir mal dein DOIF code schicken, den du zum Test verwendet hast?
Ich sehe zu, dass ich das am WE mal aufm Raspi laufen lasse.

Vielen Dank und bis denn
SouzA
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 11 Mai 2018, 07:06:02
Im Testsystem habe ich einfach definiert:

define bla dummy

und 10 verschiedene DOIFs mit jeweils:

define test DOIF ([+1] or [+1] or [+1] or [+1])(set bla on)
attr test do always


Die vier Timer fallen zusammen, deswegen würde hier auch einer ausreichen (DOIF erkennt das und macht nur einen daraus), aber auch diesen Fall wollte ich testen.

Wenn du das lange genug beobachtet hast, kannst du noch definieren:

define bla2 dummy

define n DOIF ([bla] eq "on") (set bla2 on)
attr n do always


Dieser reagiert auf das Setzen von bla.

Dann hast du schon 20 Aktionen (10 mal bla setzen und 10 mal bla2 setzen) pro Sekunde. Damit könnte ein raspi schon etwas beschäftigt sein.


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 11 Mai 2018, 08:40:07
Bei einer dummy Konfiguration hatte ich eine Überraschung erlebt was vielleicht mit dem Fehler zu tun hat.
Ein definierter Dummy mit der Bezeichnung define AB_VG_WBLD dummy hatte ständig ein und ausgeschaltet was das System sehr stark belastet hatte.
Was ich daran nicht verstehen kann ist dass der Dummy derzeit nur als Dummy vorhanden war und trotzdem mehrfach im Sekundenbereich geschaltet hatte.
Anfangs dachte ich das über FHEM2FHEM irgend etwas diesen Dummy schalten ließ was auch nicht der Fall war weil diese Bezeichnung auf keinem anderen System vorhanden war und zudem auch noch in einer FHEM2FHEM Definition eingetragen war.
Ein rename auf eine andere Bezeichung bendete diese Phänomen. Ein rename zurück ließt den Dummy wiederum ständig schalten.
Erst ein reboot des Systems beendete das Schauspiel.
Ich bin nur durch Zufall darüber gestolpert, weil ich den Eventmonitor laufen ließ und nicht beendet hatte.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: SouzA am 11 Mai 2018, 13:11:20
Hi,

@Damian
Läuft!
{ int(keys %intAt) } = 14
RAM ~80MB

Version:
Latest Revision: 16632

File              Rev   Last Change

fhem.pl           16609 2018-04-13 19:53:08Z rudolfkoenig
90_at.pm          15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm  15620 2017-12-16 18:10:36Z rudolfkoenig
98_copy.pm        16366 2018-03-09 21:33:00Z justme1968
98_DOIF.pm        16630 2018-04-17 18:28:20Z Damian
98_dummy.pm       12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm  14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm     16599 2018-04-13 17:28:07Z rudolfkoenig
92_FileLog.pm     15874 2018-01-13 17:16:33Z rudolfkoenig
91_notify.pm      15937 2018-01-20 13:43:28Z rudolfkoenig
99_SUNRISE_EL.pm  16632 2018-04-17 19:00:21Z rudolfkoenig
98_SVG.pm         16631 2018-04-17 18:50:09Z rudolfkoenig
42_SYSMON.pm      15910 2018-01-16 23:07:56Z hexenmeister
98_telnet.pm      16293 2018-02-28 21:33:57Z rudolfkoenig
99_Utils.pm       15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm     15140 2017-09-26 09:20:09Z markusbloch

Blocking.pm       15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm          11159 2016-03-30 16:08:06Z justme1968
DevIo.pm          16623 2018-04-15 18:44:05Z rudolfkoenig
HttpUtils.pm      16407 2018-03-14 19:43:35Z rudolfkoenig
RTypes.pm         10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm  16568 2018-04-08 09:44:42Z rudolfkoenig
TcpServerUtils.pm 15707 2017-12-27 14:41:21Z rudolfkoenig


@Burny4600
Hmm, sowas hab ich noch nie beobachtet. Wodurch sollte sowas geschehen?
Vielleicht noch irgendwo ne "alte" Ansteuerung noch aktiv gehabt?

Bis denn
SouzA
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 11 Mai 2018, 13:19:07
@SouzA
ZitatVielleicht noch irgendwo ne "alte" Ansteuerung noch aktiv gehabt?
Kann nicht sein denn das fällt dir gleich auf wenn eine Verknüpfung irgend wo gewesen wäre unter Probably associated with

Bisher hatte ich noch nie einen solchen Fall.
So etwas fällt dir für normal auch nicht auf. Das war ein Zufall das ich das durch den Event Monitor nach einem Update beobachtet hatte.
Wir sind hier um Umfälligkeiten zusammen zu tragen um dem Problem auf die Spur zu kommen, darum der Eintrag einer Beobachtung von mir.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 11 Mai 2018, 15:14:39
Probably associated "findet" bzw. zeigt aber nicht alle "Abhängigkeiten"...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Amenophis86 am 11 Mai 2018, 15:50:22
Würde mal manuell in der cfg bzw DB nach de Namen des Dummy suchen. Außer jemand weiß dafür einen Befehl über die Kommandozeile :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 11 Mai 2018, 15:53:08
MyUtils nicht vergessen...

Aber gegen 'grep' auf OS-Ebene spricht in dem Fall ja nichts...
...ist ja nur lesend... ;)

Allerdings geht das wohl nicht bei einer DB...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 11 Mai 2018, 16:51:24
Wenn es oft zu Abbrüchen mit BlockingKill kommen sollte, dann können Memory leaks die Folge sein. So lese ich jedenfalls die Beschreibung.

Zitat
kill('KILL', ...) can be used to terminate a pseudo-process by passing it the ID returned by fork(). The outcome of kill on a pseudo-process is unpredictable and it should not be used except under dire circumstances, because the operating system may not guarantee integrity of the process resources when a running thread is terminated. The process which implements the pseudo-processes can be blocked and the Perl interpreter hangs. Note that using kill('KILL', ...) on a pseudo-process() may typically cause memory leaks, because the thread that implements the pseudo-process does not get a chance to clean up its resources.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 11 Mai 2018, 17:06:22
Meines Wissens gibt es die Perl-Pseudo-Prozesse nur unter Windows.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: SouzA am 13 Mai 2018, 22:13:34
Hi,

ich habe den Test-Raspi nun fast zwei Tage mit den DOIFs von Damian laufen lassen. (Die Version mit den 20 Zugriffen pro Sekunde...)
Da fällt nix auf. Keine Speicherzunahme. Ich hätte jetzt behauptet, an DOIF liegt es nicht.
Hatte auch DOIFTools mitlaufen lassen...
Aktuelle version vom Test-Raspi:
Latest Revision: 16632

File              Rev   Last Change

fhem.pl           16609 2018-04-13 19:53:08Z rudolfkoenig
90_at.pm          15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm  15620 2017-12-16 18:10:36Z rudolfkoenig
98_count.pm       11992 2016-08-19 18:18:00Z betateilchen
98_DOIF.pm        16630 2018-04-17 18:28:20Z Damian
98_DOIFtools.pm   16245 2018-02-23 13:16:23Z Ellert
98_dummy.pm       12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm  14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm     16599 2018-04-13 17:28:07Z rudolfkoenig
92_FileLog.pm     15874 2018-01-13 17:16:33Z rudolfkoenig
98_help.pm        15223 2017-10-10 10:14:24Z betateilchen
91_notify.pm      15937 2018-01-20 13:43:28Z rudolfkoenig
99_SUNRISE_EL.pm  16632 2018-04-17 19:00:21Z rudolfkoenig
98_SVG.pm         16631 2018-04-17 18:50:09Z rudolfkoenig
42_SYSMON.pm      15910 2018-01-16 23:07:56Z hexenmeister
32_SYSSTAT.pm     10567 2016-01-18 21:34:09Z justme1968
98_telnet.pm      16293 2018-02-28 21:33:57Z rudolfkoenig
99_Utils.pm       15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm     15140 2017-09-26 09:20:09Z markusbloch

Blocking.pm       15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm          11159 2016-03-30 16:08:06Z justme1968
DevIo.pm          16623 2018-04-15 18:44:05Z rudolfkoenig
HttpUtils.pm      16407 2018-03-14 19:43:35Z rudolfkoenig
RTypes.pm         10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm  16568 2018-04-08 09:44:42Z rudolfkoenig
TcpServerUtils.pm 15707 2017-12-27 14:41:21Z rudolfkoenig

console.js                 16348 2018-03-07 21:02:42Z rudolfkoenig
doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16546 2018-04-03 19:51:36Z rudolfkoenig


Mein Produktivsystem ist allerdings wieder nahezu am Ende.
version:
Latest Revision: 16685

File                 Rev   Last Change

fhem.pl              16675 2018-04-29 22:15:41Z rudolfkoenig
96_allowed.pm        16295 2018-02-28 22:11:09Z rudolfkoenig
73_AMADCommBridge.pm 16559 2018-04-06 12:37:35Z CoolTux
74_AMADDevice.pm     16559 2018-04-06 12:37:35Z CoolTux
90_at.pm             15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm     15620 2017-12-16 18:10:36Z rudolfkoenig
No Id found for 74_BleTagBattery.pm
98_cmdalias.pm       16300 2018-03-01 08:48:21Z rudolfkoenig
10_CUL_HM.pm         16588 2018-04-11 18:21:53Z martinp876
95_Dashboard.pm      12251 2016-10-03 09:45:43Z talkabout
98_DOIF.pm           16651 2018-04-23 06:28:53Z Damian
98_DOIFtools.pm      16245 2018-02-23 13:16:23Z Ellert
98_dummy.pm          12700 2016-12-02 16:49:42Z rudolfkoenig
10_EnOcean.pm        16029 2018-01-28 18:43:46Z klaus.schauer
91_eventTypes.pm     14888 2017-08-13 12:07:12Z rudolfkoenig
72_FB_CALLLIST.pm    16433 2018-03-18 08:20:35Z markusbloch
72_FB_CALLMONITOR.pm 16607 2018-04-13 18:31:53Z markusbloch
01_FHEMWEB.pm        16677 2018-04-29 22:36:01Z rudolfkoenig
92_FileLog.pm        15874 2018-01-13 17:16:33Z rudolfkoenig
72_FRITZBOX.pm       16461 2018-03-21 18:26:03Z tupol
98_GOOGLECAST.pm     16589 2018-04-11 19:01:32Z dominik
20_GUEST.pm          14136 2017-04-29 16:31:46Z loredo
98_help.pm           15223 2017-10-10 10:14:24Z betateilchen
98_HMinfo.pm         16612 2018-04-14 09:28:35Z martinp876
00_HMUARTLGW.pm      16166 2018-02-13 19:52:08Z mgernoth
95_holiday.pm        16502 2018-03-27 20:59:14Z rudolfkoenig
98_HTTPMOD.pm        16216 2018-02-18 15:26:11Z StefanStrobel
02_HTTPSRV.pm        13976 2017-04-12 13:35:44Z neubert
36_JeeLink.pm        14707 2017-07-13 18:08:33Z justme1968
98_JsonList2.pm      16293 2018-02-28 21:33:57Z rudolfkoenig
36_LaCrosse.pm       16168 2018-02-13 21:01:41Z HCS
91_notify.pm         15937 2018-01-20 13:43:28Z rudolfkoenig
73_PRESENCE.pm       16177 2018-02-14 08:58:43Z markusbloch
33_readingsGroup.pm  16299 2018-03-01 08:06:55Z justme1968
10_RESIDENTS.pm      14136 2017-04-29 16:31:46Z loredo
20_ROOMMATE.pm       14136 2017-04-29 16:31:46Z loredo
32_speedtest.pm      12056 2016-08-22 19:30:31Z justme1968
99_SUNRISE_EL.pm     16632 2018-04-17 19:00:21Z rudolfkoenig
98_SVG.pm            16656 2018-04-24 21:12:43Z rudolfkoenig
42_SYSMON.pm         15910 2018-01-16 23:07:56Z hexenmeister
32_SYSSTAT.pm        10567 2016-01-18 21:34:09Z justme1968
00_TCM.pm            14876 2017-08-11 18:46:35Z klaus.schauer
50_TelegramBot.pm    16382 2018-03-11 13:20:55Z viegener
98_telnet.pm         16293 2018-02-28 21:33:57Z rudolfkoenig
59_Twilight.pm       16005 2018-01-27 06:05:51Z igami
98_update.pm         16551 2018-04-04 18:50:38Z rudolfkoenig
99_Utils.pm          15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm        15140 2017-09-26 09:20:09Z markusbloch
70_VIERA.pm          10463 2016-01-11 18:03:07Z teevau
59_Weather.pm        16644 2018-04-22 08:07:35Z neubert
98_weblink.pm        16293 2018-02-28 21:33:57Z rudolfkoenig
32_WifiLight.pm      15907 2018-01-16 20:58:44Z herrmannj
98_WOL.pm            10595 2016-01-22 17:05:38Z dietmar63

# $Id:  $
Blocking.pm          15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm             11159 2016-03-30 16:08:06Z justme1968
DevIo.pm             16623 2018-04-15 18:44:05Z rudolfkoenig
FritzBoxUtils.pm     16344 2018-03-06 21:06:34Z rudolfkoenig
HMConfig.pm          16265 2018-02-25 18:22:43Z martinp876
HttpUtils.pm         16407 2018-03-14 19:43:35Z rudolfkoenig
myUtilsTemplate.pm    7570 2015-01-14 18:31:44Z rudolfkoenig
RESIDENTStk.pm       14160 2017-05-01 19:43:40Z loredo
RTypes.pm            10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm     16568 2018-04-08 09:44:42Z rudolfkoenig
TcpServerUtils.pm    15707 2017-12-27 14:41:21Z rudolfkoenig
UConv.pm             14398 2017-05-28 09:40:42Z loredo
Unit.pm              14136 2017-04-29 16:31:46Z loredo
YahooWeatherAPI.pm   16641 2018-04-21 12:28:38Z neubert

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16678 2018-04-29 22:42:09Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
svg.js                     16617 2018-04-15 09:30:12Z rudolfkoenig


Siehe Bilder...

Bin ratlos...  :-\

Bis denn
SouzA
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 20 Mai 2018, 14:55:06
Ich habe jetzt herausgefunden wie man den Speicherüberlauf mit DIOF provozieren kann.
Mit diesem Test wird der Speicherüberlauf sehr rasch erreicht.
Ich habe mir ein PWM mit DIOF für Solarpumpen erstellt und das ist FHEM jedenfalls in der Form mit DOIF zu viel des Guten.
Dieses benötigte PWM Modul muss ich mir irgendwie anders erstellen obwohl es mit DOIF grundsätzlich funktioniert.
Ich hoffe dieses Test pm bringt die Lösung des Problems.

EDIT: 17:05
Wird diese PWM Funktion wieder angehalten wird aber der Speicher nicht mehr freigegeben.
Somit wird auch bei vielen kleineren Timing Funktionen mit der Zeit der Speicher immer weniger bis dann zu wenig frei ist und kein Speichern mehr möglich ist und die Meldung Cannot allocate memory eintritt.
Bei normalen DIOF Anwendungen gibt es auch keine Probleme, nur dort wo Timing Funktionen benötigt werden
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 21 Mai 2018, 08:31:46
Muss man nach einem "include test_DOIF.pm" was unternehmen?Ich sehe auf einem Ubuntu-VM selbst mit einem "define a at +*00:00:01 set PID20_RA {(rand(100))}" keinen Speicherzuwachs.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 21 Mai 2018, 10:07:02
@rudolfkoenig
Es ist in der fhem.cfg nur die Zeile include /.....link.../test_DOIF.pm einzufügen.
Im Anschluß ist der Wert vom Dummy PID20_RA ab 36 zu verwenden.
Ab dem Einstellwert >= 36 kannst du zusehen wie ram %tuel steigt.
Um so höher der Einstellwert um so schneller wird ram %tuel steigen.

TestumgebungJessie Stretch lite
Linux ccs-ht-rasp10 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l

FHEM Version
Latest Revision: 16759

File              Rev   Last Change

fhem.pl           16744 2018-05-15 20:06:23Z rudolfkoenig
96_allowed.pm     16295 2018-02-28 22:11:09Z rudolfkoenig
90_at.pm          15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm  15620 2017-12-16 18:10:36Z rudolfkoenig
98_DOIF.pm        16755 2018-05-18 13:47:23Z Damian
98_dummy.pm       12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm  14888 2017-08-13 12:07:12Z rudolfkoenig
93_FHEM2FHEM.pm   15006 2017-09-05 09:37:33Z rudolfkoenig
01_FHEMWEB.pm     16677 2018-04-29 22:36:01Z rudolfkoenig
92_FileLog.pm     15874 2018-01-13 17:16:33Z rudolfkoenig
No Id found for 52_I2C_SUSV.pm
98_logProxy.pm    16299 2018-03-01 08:06:55Z justme1968
# $Id: 99_myUtils.pm  2016-09-25  V1.0  Christian Schmidt $
91_notify.pm      15937 2018-01-20 13:43:28Z rudolfkoenig
94_PWM.pm         16090 2018-02-05 11:04:56Z jamesgo
00_RPII2C.pm      15021 2017-09-06 19:48:55Z klausw
No Id found for 99_sethmkey.pm
99_SUNRISE_EL.pm  16632 2018-04-17 19:00:21Z rudolfkoenig
98_SVG.pm         16737 2018-05-13 12:26:00Z rudolfkoenig
42_SYSMON.pm      15910 2018-01-16 23:07:56Z hexenmeister
98_telnet.pm      16293 2018-02-28 21:33:57Z rudolfkoenig
99_Utils.pm       15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm     15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm     16293 2018-02-28 21:33:57Z rudolfkoenig

Blocking.pm       15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm          11159 2016-03-30 16:08:06Z justme1968
HttpUtils.pm      16759 2018-05-19 07:24:56Z rudolfkoenig
RTypes.pm         10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm  16568 2018-04-08 09:44:42Z rudolfkoenig
TcpServerUtils.pm 15707 2017-12-27 14:41:21Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 16727 2018-05-11 09:12:01Z rudolfkoenig
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 21 Mai 2018, 11:20:23
Ich habe das Problem gefixed. Du kannst die angehängte Version testen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 21 Mai 2018, 14:13:13
@Damian
Ich habe deine 98_DOIF.pm getestet, aber keine Verbesserung feststellen können.
Sowie ich den Belastungstest starte steigt der Speicherverbrauch.
Wenn ich eine längere Zeit den Testlauf nicht beende wird der Speicher nicht mehr frei gegeben. Er bleibt auf dem letzten Level stehen.
Nur bei kürzeren Tests kann ich feststellen das wieder weniger Speicherverbrauch aufscheint.
Siehe Anhang.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 22 Mai 2018, 21:54:16
Das Problem kann ich alleine durch das Verzögern einer Anweisung mit einem Wait-Timer provozieren.

Der interne Aufruf sieht aus meiner Sicht ungefährlich aus:

InternalTimer($next_time, "DOIF_SleepTrigger",$hash, 0);

Das Löschen des speicherfressenden DOIFs gibt keinen Speicher frei. Ich weiß nicht, ob der $hash dann gelöscht wird, wenn ja, dann wird der Speicher vermutlich in fhem.pl verbraucht.

Ich kann z. Zt. nur rudimentär Analysen betreiben, da ich im Urlaub bin.



Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 23 Mai 2018, 13:04:15
Da bleibt nur zuwarten bis eine Lösung gefunden wird.
Momentan habe ich noch keine Lösung gefunden um die PWM Ausführung im DIOF anders zu lösen.

ZitatDas Problem kann ich alleine durch das Verzögern einer Anweisung mit einem Wait-Timer provozieren.
Das heißt ohnehin das hier ein Bedarf ist das dieser Fall nicht eintreten soll.
Zum einen soll der Speicherverbrauch nicht ständig steigen und zum Anderen sollte der vorher benötigte Speicher nach einem Halt der Funktion wieder frei gegeben werden.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 23 Mai 2018, 17:04:34
Hier mal eine einfache Definition zum Analysieren, die zum Speicherverbrauch führt:

defmod a at +*00:00:01 set bla  on

defmod b DOIF ([bla:"on"])(set bla2 on)
attr b do always
attr b wait 0.5


bla, bla2 sind Dummys

Dass at keinen Speicherverbrauch produziert, hat Rudi schon festgestellt. Das DOIF reagiert auf das Event "bla: on" und setzt um eine halbe Sekunde verzögert set bla2 on. Ohne Verzögerung durch das Attribut wait wird kein Speicher verbraucht.


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 28 Mai 2018, 20:07:44
Ich habe einen workaround gebaut. Bitte testen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 29 Mai 2018, 06:33:06
Hallo Damian,

danke für deine Arbeit, leider behebt der Fix, zumindest bei mir, nicht das Problem.

Wie man auf dem Bild im Anhang sieht, habe ich um 22:30 auf zu Stretch gewechselt und der Speicheranstieg ist sofort wieder da.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 29 Mai 2018, 11:56:24
@Damian

Einen Teilerfolg hat die Änderung gebracht.
Was mich verwundert ist das es beim Pi2+ keinen steigenden Speicherverbrauch mehr gibt. Auch die Belastung der CPU ist geringer die sich anhand der Temperatur auch bemerkbar macht weil diese jetzt geringer ist.
Man sieht sehr schön bei diesem Test wie ich das PWM Dummy aktiviere steigt die CPU Frequenz und Temperatur, aber der Speicherverbrauch bleibt nahezu gleich.

Beim Pi3+ ist aber mit der gleichen Konfiguration außer die Pi3+ spezifischen Softwarepakete aber keine Änderung bemerkbar. Hier wird der Speicher verbraucht bis nichts mehr geht was die Aufzeichnungen der Plot betrifft.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 29 Mai 2018, 12:52:24
Zitat von: Burny4600 am 29 Mai 2018, 11:56:24
@Damian

Einen Teilerfolg hat die Änderung gebracht.
Was mich verwundert ist das es beim Pi2+ keinen steigenden Speicherverbrauch mehr gibt. Auch die Belastung der CPU ist geringer die sich anhand der Temperatur auch bemerkbar macht weil diese jetzt geringer ist.
Man sieht sehr schön bei diesem Test wie ich das PWM Dummy aktiviere steigt die CPU Frequenz und Temperatur, aber der Speicherverbrauch bleibt nahezu gleich.

Beim Pi3+ ist aber mit der gleichen Konfiguration außer die Pi3+ spezifischen Softwarepakete aber keine Änderung bemerkbar. Hier wird der Speicher verbraucht bis nichts mehr geht was die Aufzeichnungen der Plot betrifft.

Mein Hack hat nur durch Tests die Symptome  des Speicherverbrauchs, die ich aufgrund meiner hier geposteten Testkonfiguration nachvollziehen konnte, beseitigt. Die Ursache des Problems ist mir nicht klar und scheint tief in Perl (möglicherweise versionsabhängig) begraben zu sein, siehe: https://forum.fhem.de/index.php/topic,88208.msg806196.html#msg806196
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 29 Mai 2018, 20:55:08
Das ist wirklich eine hartnäckige Angelegenheit.

Ich werde mit dem Pi3 einige Vergleiche machen wo es grundlegende Unterschiede noch gibt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 29 Mai 2018, 21:11:00
Zitat von: Burny4600 am 29 Mai 2018, 20:55:08
Das ist wirklich eine hartnäckige Angelegenheit.

Ich werde mit dem Pi3 einige Vergleiche machen wo es grundlegende Unterschiede noch gibt.

Ich werde versuchen den Programmiercode so abzuändern, dass die Verzögerungsangaben in wait nicht bei jedem Trigger über regex-Abfragen ausgewertet werden, sondern nur bei Änderungen. Das könnte neben Performancegewinn das Problem beheben, wenn es nicht noch mehr tickende Zeitbomben in Perl gibt ;)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 29 Mai 2018, 23:16:13
Wenn man mal intensiver danach sucht, dann findet man einige Bug reports in Bezug auf memory leaks in den unterschiedlichsten Perl Versionen. Interessant wäre nun, welche Perl Versionen auf den Rechnern installiert sind, bei denen das Problem auftritt und welche Perl Version bei denen wo das Problem nicht auftritt. Vielleicht kann man daraus ja was ableiten.
Wobei man natürlich beachten muss, das bei diesem Problem immer 2 Dinge zusammen kommen müssten: die fehlerhafte Perl Version + ein Modul das den Fehler auslöst. Vielleicht gibts aber jemanden der die gleichen Module auf 2 Rechnern verwendet, bei denen sich nur die Perl Version unterscheidet und bei einem läuft es und beim anderen gibts einen Speicherzuwachs.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 30 Mai 2018, 07:34:23
Also ich habe mittlerweile ein Raspi3 mit einem USB-Stick auf dem auf 2 Partitionen Raspbian Jessie und Stretch drauf ist und ich dazwischen springen kann.
Die FHEM Konfiguration wird jedes mal vor einem Wechsel kopiert, daher immer genau gleich.

Auf Raspbian Jessie läuft perl 5, version 20, subversion 2 (v5.20.2) ohne Probleme.

Auf Raspbian Stretch ist es  perl 5, version 24, subversion 1 (v5.24.1) mit dem Speicherzuwachs.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 30 Mai 2018, 08:56:28
Wenn man nach "perl 5.24 memory leak" im Internet sucht, dann tauchen einige Meldungen auf.
Kannst du bitte den "Crosstest" machen: auf Stretch 5.20 oder auf Jessie 5.24 installieren?
Mit ActivePerl koennte man auch einfach 5.26 testen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 30 Mai 2018, 13:55:57
Hallo Rudi,

kannst Du mir sagen wie ich es am elegantesten hinbekomme das 5.24.1 down zu graden?

Danke und Gruß
Alex
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 30 Mai 2018, 15:19:11
Ich wuerde ein ActivePerl Paket (.tar.gz) herunterladen, es irgendwo auspacken, und mit diesem perl testen (cd /opt/fhem; ...ActivePerl-5.20/bin/perl fhem.pl fhem.cfg).
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 30 Mai 2018, 16:05:00
Ok, teste ich heute Abend.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 30 Mai 2018, 19:43:24
An der Perlversion alleine kann es jedenfalls nicht liegen.
Sowohl am Pi3/3+ als auch am Pi2+ befindet sich die perl_version v5.24.1
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 30 Mai 2018, 21:02:39
Ich habe mal unter Windows die aktuelle ActivePerl-Version installiert:

ZitatThis is perl 5, version 26, subversion 1 (v5.26.1) built for MSWin32-x64-multi-thread

Der Memory leak scheint mit meiner Testkonfiguration mit der regulären DOIF-Version nicht mehr da zu sein.

Allerdings habe ich Probleme mit serialport


2018.05.30 20:45:25.328 3: Opening CUL device com10
2018.05.30 20:45:25.395 3: Setting CUL serial parameters to 9600,8,N,1
2018.05.30 20:45:25.416 1: PERL WARNING: Second Read attempted before First is done at ./FHEM/00_CUL.pm line 556.
2018.05.30 20:45:25.416 1: PERL WARNING: Use of uninitialized value $got in numeric ne (!=) at C:/Perl/site/lib/Win32/SerialPort.pm line 1216.
2018.05.30 20:45:25.416 1: PERL WARNING: Second Write attempted before First is done at ./FHEM/DevIo.pm line 128.
2018.05.30 20:45:25.416 1: PERL WARNING: Use of uninitialized value $written in numeric ne (!=) at C:/Perl/site/lib/Win32/SerialPort.pm line 1580.
2018.05.30 20:45:25.452 1: Cannot init com10, ignoring it (CUL)


Es ist jetzt wohl Perl 64 statt Perl x86 (32-bit). Perl 32-bit gibt es offenbar nicht mehr in der aktuellen Version unter Windows.



Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 31 Mai 2018, 11:12:30
Moin zusammen,

ich teste parallel auf meinem PROD-System mittels Perlbrew. Habe soeben Perl 5.20.2 installiert und nun kommen die ganzen Module dran. Vielleicht kann ich hier helfen, da ich dasselbe Problem habe.

VG


Edit:
Falls jemand auch mit Perlbrew arbeiten und andere Perl Versionen testen will, hier meine Installationsanleitung (ich hoffe ich habe nichts vergessen):

Install Perlbrew
------------------
1) Create perlbrew directory
cd /opt
sudo mkdir perlbrew
sudo chown fhem perlbrew
sudo chgrp dialout perlbrew

2) Switch user to fhem
sudo su - fhem

3) Set variables and install perlbrew
export PERLBREW_ROOT=/opt/perlbrew
curl -kL http://install.perlbrew.pl | bash

Install a Perl version
----------------------
1) Switch user to fhem

2) Check versions and install
cd /opt/perlbrew/bin/
./perlbrew available
./perlbrew --notest install perl-5.20.2 -D=usethreads

3) Activate perl version
cd /opt/perlbrew/bin/
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
./perlbrew switch perl-5.20.2
echo -e "Perl version:\r\n " && perl -v
echo -e "Perl active:\r\n " && which perl
echo -e "Perl environment variables:\r\n " && env | grep PERL
echo -e "Perl host system:\r\n " && lsb_release -a

Install modules
----------------------
1) Switch user to fhem
2) Activate your perl version

3) Install cpanm
curl -L https://cpanmin.us | perl - App::cpanminus

4) My modules installations
# prerequisite for IO::Socket::SSL is "sudo apt-get install libssl-dev"
# prerequisite for DBD::mysql is "sudo apt-get install default-libmysqlclient-dev"
cpanm JSON
cpanm DBI
cpanm URI::Escape
cpanm XML::Simple
cpanm Device::SerialPort
cpanm HTML::TreeBuilder::XPath
cpanm DBI::Const::GetInfoType
cpanm IO::Socket::SSL
cpanm Crypt::Rijndael
cpanm SOAP::Lite
cpanm DBD::mysql
cpanm Net::Telnet
cpanm -n IO::Tty --configure-timeout=200
cpanm Net::SCP::Expect
cpanm -n Net::OpenSSH

Start fhem with other Perl version
----------------------------------
1) Switch user to fhem

2) Stop fhem
/etc/init.d/fhem stop

3) Activate your perl version

4) Start fhem
/etc/init.d/fhem start
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 31 Mai 2018, 13:50:23
Das nenne ich mal eine super Anleitung.
Ich bin mit Active Perl leider gescheitert und Perlbrew ist mir nach ca. 3/4 Stunde Kompilieren von Perl 5.20 mit einer Fehlermeldung abgeschmiert, ich versuche es heute nochmal mit der Anleitung Perl 5.20 über Perlbrew zu installieren.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 31 Mai 2018, 14:02:00
Danke,

führe es mit --notest aus (wie in der Anleitung), ich hatte bei einem Test einen Fehler, dass der abgebrochen ist ... so sparst du mindestens 30 Minuten ;)

Mit perlbrew kannst du jederzeit zwischen den Versionen switchen.

Falls irgendwas nicht funktioniert, einfach melden, vielleicht kann ich helfen oder es fehlt etwas in der Anleitung.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 31 Mai 2018, 18:28:44
Nach den ersten paar Stunden sieht die mit Perlbrew geswitchte Version auf 5.20.2 vernünftig aus (grüner Part im Bild im Anhang). Alles was davor sichtbar ist, ist eindeutig ein Speicherleck, ganz deutlich sieht man dies im 30 Tage Chart.

Ich lasse so Fhem ein paar Tage laufen und gebe dann nochmal Rückmeldung.

Korrektur:
Ich habe anstatt 5.20.3 versehentlich 5.20.2 installiert!
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 01 Juni 2018, 06:16:32
Hallo Zusammen,

auch bei mir funktioniert es mit der Perl Version 5.20.3 ohne Speicheranstieg.

Jetzt stellen sich bei mir nur folgende Fragen
1. wie stelle ich die Perlversion dauerhaft um
2. ich habe 2 Module die nicht laufen wolen,
RPII2C (I2C: Error! no library for Hardware access installed)
und MQTT (Cannot load module MQTT)
! Finding Net::MQTT:Simple on cpanmetadb failed.
! Finding Net::MQTT:Simple () on mirror http://www.cpan.org failed.
! Couldn't find module or a distribution Net::MQTT:Simple

wie bekomme ich diese noch zum laufen
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 01 Juni 2018, 07:20:12
Zitatwie bekomme ich diese noch zum laufen
Bei mir hat das gerade mit "cpan -i Net::MQTT::Simple" geklappt. Heruntergeladen wurde die Datei (automatisch) von dieser Adresse:
http://www.perl.org/CPAN/authors/id/J/JU/JUERD/Net-MQTT-Simple-1.21.tar.gz

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 01 Juni 2018, 07:33:32
Hallo Rudi cpan funktioniert bei mir auch, dies gilt aber nur der im OS installierten Version von Perl,
versucht man das ganze wie in der Anleitung oben mit cpanm zu installieren, kommt die Fehlermeldung.


Was mir noch aufgefallen ist, ist dass der  Sigduino nicht funktioniert.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 01 Juni 2018, 07:37:48
Ich wuerde cpan (nicht cpanm) aus der gewuenschten Perl-Installation aurufen, muesste neben dem perl Binary sein.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 01 Juni 2018, 08:17:26
ok, danke, habe ich zum laufen bekommen.

Dem Sigduino bzw. eher dem Modul SD_WS09 fehlte das Modul Digest::CRC.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 01 Juni 2018, 08:20:02
Moin,

im Internet lese ich immer, dass mit Perlbrew immer cpanm genutzt werden sollte, da das nur ein Modul zur spezifischen Perl Installation ist. Ich denke cpan macht betriebsbedingt Probleme bzgl. dem Perl vom OS und Perlbrew.

Muss allerdings sagen, da kenne ich mich nicht so gut aus und lasse mich gerne belehren.


Zum Thema:
Bei mir funktioniert die Installation (nur testen kann ich es nicht)... sicher dass du der FHEM user bist und mit Perlbrew auf 5.20.3 gewechselt hast?

fhem@Fhem:/opt/perlbrew/bin$ cpanm Net::MQTT::Simple
--> Working on Net::MQTT::Simple
Fetching http://www.cpan.org/authors/id/J/JU/JUERD/Net-MQTT-Simple-1.21.tar.gz ... OK
Configuring Net-MQTT-Simple-1.21 ... OK
Building and testing Net-MQTT-Simple-1.21 ... OK
Successfully installed Net-MQTT-Simple-1.21
1 distribution installed
fhem@Fhem:/opt/perlbrew/bin$

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 01 Juni 2018, 08:55:53
ZitatIch denke cpan macht betriebsbedingt Probleme bzgl. dem Perl vom OS und Perlbrew.
Wichtig ist, dass man cpan/cpanm aus der gewuenschten perl Installation aufruft, sonst installiert man die Pakete fuer den "falschen" perl.
Will jetzt nicht gegen cpanm Front machen, nur klarstellen.

Btw. inzwischen gibt es auch perl 5.26, mAn waere sinnvoll 5.26 auch zu testen, und falls ok, dann eher auf 5.26 "upgraden", und nicht auf 5.20 "downgraden".
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 01 Juni 2018, 09:04:25
Vielen Dank für die Info, das war mir so nicht bewusst.

5.26 habe ich parallel auch bereits installiert. Nur zum Testen erstmal 5.20 genommen. In ein paar Tagen werde ich dann auf 5.26 switchen.

Zum Thema "Autostart von Perlbrew" habe ich bereits einige Versuche unternommen, allerdings noch nichts brauchbares bauen können. :(
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 01 Juni 2018, 09:10:19
Zitat von: rudolfkoenig am 01 Juni 2018, 08:55:53
Wichtig ist, dass man cpan/cpanm aus der gewuenschten perl Installation aufruft, sonst installiert man die Pakete fuer den "falschen" perl.
Will jetzt nicht gegen cpanm Front machen, nur klarstellen.

Btw. inzwischen gibt es auch perl 5.26, mAn waere sinnvoll 5.26 auch zu testen, und falls ok, dann eher auf 5.26 "upgraden", und nicht auf 5.20 "downgraden".

Meine Testkonfiguration führte, wie bereits geschrieben, bei 5.26 im Gegensatz zu 5.24 zu keinem memory leak. Die Version 5.26 sollen ruhig die Betroffenen in ihrer Umgebung noch mal selbst untersuchen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 01 Juni 2018, 10:21:50
CPAN ist bei dieser Version von Perl kein Problem, da auch Perl selber manuell installiert wurde.

Man sollte nur Sichergehen, das bei Updates des Systems eventuelle Perl-Updates nachgezogen werden müssen ....

Deshalb nichts für Anfänger ....
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 01 Juni 2018, 10:58:40
5.26.2 kann leider nicht über homebrew installiert werden.
Gibt es einen weg perl normal upzudaten?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 01 Juni 2018, 11:07:30
Also ich habe es mittels Perlbrew installiert:

./perlbrew --notest install perl-5.26.2 -D=usethreads

Hatte also keinerlei Probleme:

fhem@Fhem:/opt/perlbrew/bin$ ./perlbrew list
   perl-5.26.2
* perl-5.20.2


Wie hast du im Detail installiert? Warum ist es fehlgeschlagen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 01 Juni 2018, 12:25:43
Vermutlich ging es nicht, weil ich zu dem Zeitpunkt über perlbrew das fhem am laufen hatte.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 02 Juni 2018, 06:44:08
Hallo zusammen,

ich habe es nun auch mit Perl 5.26.2 getestet und leider ist hier ebenfalls der Speicheranstieg zu beobachten.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 03 Juni 2018, 22:14:38
Wie sieht es bei den anderen mit 5.20.2 oder 5.20.3 aus?

Ich habe über das Wochenende FHEM auf 5.20.2 (da ich nicht zu Hause war) laufen lassen und es sieht auf dem Graphen wunderbar aus. Ein Unterschied wie Tag und Nacht.

Ich werde trotzdem einmal gegen Ende der Woche 5.26.2 testen, das Wechseln mit Perlbrew ist ja super einfach.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 06 Juni 2018, 11:35:10
Ist perlbrew auf einem Raspberry 3 mit fhem einfach zu installieren? Ich habe leider keine Möglichkeit ein Testsystem aufzusetzen, und müßte mein produktivsystem nehmen.
Wie startet man fhem dann in den unterschiedlichen perl Versionen?

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Thyraz am 06 Juni 2018, 11:59:47
Blätter mal 1-2 Seiten zurück, da hat Rudi irgendwo den Aufruf gepostet.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 08 Juni 2018, 09:31:16
ZitatBlätter mal 1-2 Seiten zurück, da hat Rudi irgendwo den Aufruf

Gut das klärt zumindest schon mal, wie ich das fhem mit der entsprechende Version starte.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 10 Juni 2018, 21:28:58
Rückmeldung zum gestrigen DOIF Update.
Der Speicheranstieg bei einem Raspberry 2 ist nicht mehr vorhanden.
Bei einem Raspberry 3 hat sich der Speicheranstieg sehr stark reduziert aber es ist noch ein Speicherzuwachs ersichtlich.
Beide Systeme haben die  perl_version v5.24.1.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 10 Juni 2018, 22:59:11
Zitat von: Burny4600 am 10 Juni 2018, 21:28:58
Rückmeldung zum gestrigen DOIF Update.
Der Speicheranstieg bei einem Raspberry 2 ist nicht mehr vorhanden.
Bei einem Raspberry 3 hat sich der Speicheranstieg sehr stark reduziert aber es ist noch ein Speicherzuwachs ersichtlich.
Beide Systeme haben die  perl_version v5.24.1.

Das bestätigt meine Beobachtung: häufige Regex-Abfragen in bestimmten Konstellationen führen zum memory leak.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 11 Juni 2018, 18:25:48
Hallo Damian,

auch ich kann eine deutliche Verbesserung bestätigen.

Danke schon mal für die Arbeit.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 13 Juni 2018, 15:22:20
Also für den Memory Leak scheint es für 5.24.(1) sogar einen Bug Report zu geben:
https://rt.perl.org/Public/Bug/Display.html?id=130254

So wie das für mich aussieht, wird das unter 5.24 nicht mehr gefixt werden, am Ende des Threads wird auf die neuere 5.26 verwiesen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 13 Juni 2018, 19:35:00
Siehe Post #290
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 16 Juni 2018, 08:26:49
Weitere Optimierungen bzgl. memory leak siehe: https://forum.fhem.de/index.php/topic,88291.msg811923.html#msg811923
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 16 Juni 2018, 09:24:53
Zitat von: Nighthawk am 13 Juni 2018, 19:35:00
Siehe Post #290

Ich habe ja lediglich auf einen Bugreport indem behauptet wird die neue Version 5.26 hat das nicht. Wenn dem nicht der Fall ist, sollte man für 5.26 den Bug erneut Reporten....
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: duke am 16 Juni 2018, 12:27:46
Hi,

ich habe seit geraumer Zeit auch die "cannot fork cannot allocate memory" Meldungen im Log. Mittlerweile muss ich den Pi3 alle 24h neu starten, da er sonst nicht mehr erreichbar ist.
Ich habe jetzt den Thread überflogen und überall ist nur die Rede davon, dass ihr die Probleme mit Perl Version v5.20.2 nicht habt. Bei mir tritt es jedoch genau mit dieser Version auf. Das letzte FHEM Update habe ich vorgestern gemacht.

Liegt dann wahrscheinlich bei mir etwas anderes zu Grunde?

Gruß Andreas
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Thyraz am 16 Juni 2018, 13:46:40
Bei mir scheint es auch was anderes zu sein. :-/

Hatte das Problem schon immer auf dem Pi, sowohl unter Wheezy als auch Stretch.
Bin neulich auf einen Intel NUC umgestiegen, da mittlerweile noch andere Dinge auf der Kiste laufen sollen.

Hatte erst FHEM in einem Debian Stretch Proxmox Container laufen, dort trat das Problem wieder auf.
Hab jetzt testweise FHEM in einen Ubuntu Container umgezogen, da hier Perl 5.26 schon als Standard verfügbar ist.

Leider hat das auch nichts geändert. Fhem wächst und wächst über die Tage.
Durch die 16GB Ram im NUC restarte ich FHEM jetzt aber nur noch einmal die Woche statt täglich wie am Raspberry.

Die geänderte DOIF Version hatte ich schon laufen, die neue Version von heute teste ich nachher auch mal.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Shadow3561 am 18 Juni 2018, 16:48:23
Bei mir mit Perl 5.20.1 genau das selbe.

Ich bin ja der Meinung, dass es nicht an Perl liegen kann, sondern ein Fhem Modul zum Speicheranstieg führt.
Es tritt bei mir seit fast 2 Wochen (nach einem update von fhem) auf, vorher hatte ich keine Probleme.
Nur wurde bei diesem Update das DOIF Modul nicht geändert.

Die neueren versionen von Damian helfen bei mir leider auch nicht, spätestens alle 2 Tage ist ein restart von Fhem notwendig.


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 18 Juni 2018, 17:02:46
Zitat von: Shadow3561 am 18 Juni 2018, 16:48:23
Bei mir mit Perl 5.20.1 genau das selbe.

Ich bin ja der Meinung, dass es nicht an Perl liegen kann, sondern ein Fhem Modul zum Speicheranstieg führt.
Es tritt bei mir seit fast 2 Wochen (nach einem update von fhem) auf, vorher hatte ich keine Probleme.
Nur wurde bei diesem Update das DOIF Modul nicht geändert.

Die neueren versionen von Damian helfen bei mir leider auch nicht, spätestens alle 2 Tage ist ein restart von Fhem notwendig.

Tja das eine schließt das andere nicht aus. Es gibt auf jeden Fall einen memory leak in 5.24, der durch Regex-Abfragen ausgelöst wird. Unabhängig davon kann ein Modul selbst Speicher verbrauchen. Da hilft nur benutzte Module nacheinander deaktivieren und schauen ob es besser wird.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: TecCheck am 20 Juni 2018, 11:18:59
Hallo,

ich hatte vor einigen Wochen ebenfalls den 'Cannot fork: Cannot allocate memory' Fehler.

Mein Fhem läuft auf einem Intel Nuc mit Ubuntu 16.04.4 LTS  Perl v5.22.1
Besonderheit:
Ich habe an meinem Nuc per hdmi einen Touchscreen angeschlossen auf dem TabletUi läuft.

Nach langem suchen, konnte ich den firefox browser, (der durch TabletUi ständig lief), auf meinem Nuc
als den Verursacher identifizieren.

Nachdem ich den firefox durch midori ersetzt habe, läuft alles seit vier Wochen ohne den geringsten Speicheranstieg.

Übrigens laufen bei mir ca. 40 DOIF's ohne Probleme.

Vielleicht hat ja jemand eine ähnliche Config.

LG
Wolfgang

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Thyraz am 20 Juni 2018, 12:07:12
Bei dir ist dann ja aber der Firefox Prozess vom Speicher her angestiegen und nicht FHEM, oder?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 20 Juni 2018, 13:45:49
Moin zusammen,

kurze Rückmeldung. Ich  habe einiges mit den Hinweisen hier aus dem Thread getan:

- DOIF (Vorallem die mit "do always" durch Notify ersetzt
- Autocreate deaktiviert
- Update bei Tahoma Modul eingespielt
- Einen amoklaufenden Homematic Taster endlich ohne Fehler gepaired

Das hatte schon alles etwas geholfen. Jetzt nach dem letzten DOIF Update bleibt der Speicherverbrauch nahezu konstant bei 570  Der PI ist mir schon unter 500 mit der Fehlermeldung ausgestiegen. Der NUC hat genug Luft nach oben und läuft seit zwei Wochen ohne Probleme mit diesen Speicherverbrauch am Stück.

Ich danke für die vielen Hinweise hier, sieht aus als ob mein FHEM die anstehenden Ferien stabil überstehen könnte.

Gruss
  Enno
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: TecCheck am 20 Juni 2018, 15:33:40
Hallo,

Zitat von: Thyraz am 20 Juni 2018, 12:07:12
Bei dir ist dann ja aber der Firefox Prozess vom Speicher her angestiegen und nicht FHEM, oder?

Das Problem für mich als Linux-Leie war, das firefox laut 'top' völlig unauffällig war.

Dafür gab es einen Eintrag 'Webcontent' den ich nicht gleich zuordnen konnte. (fhem,firefox,TabUi).

Grüße
Wolfgang
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Shadow3561 am 22 Juni 2018, 05:56:20
So, ich habe es jetzt wohl auch im Griff.

Habe vor lauter Frust einen NUC gekauft und Ubuntu 18.04 Server installiert (Perl 5.26.1).
Bin dann mit meinem FHEM umgezogen und hatte wieder das gleiche Problem. Dauert bei 8GB Ram natürlich länger, aber der Speicherverbrauch stieg stetig an.

Habe dann in einem anderen Fred noch einiges gefunden. U.a., dass das Freezmon-Modul für den Anstieg verantwortlich sein kann.

Habe es dann aus dem Modulordner von FHEM gelöscht und einen restart von FHEM ausgeführt.
Und siehe da, seit einer Stunde bleibt die RAM-Nutzung stabil.

Ich lasse es jetzt erst einmal weiter laufen und beobachte weiter.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Marlen am 25 Juni 2018, 20:24:27
Hallo,

ich hab auch seit einigen Wochen dieses Cannot fork.

Dachte erst es liegt an einem anderen Modul das ist vor kurzem drauf hab aber scheinbar liegt es an "PRESENCE"
2018.06.24 19:28:59 2: PRESENCE (DBLinkCam_Ping) - error while processing check: Could not execute ping command: "ping -c 4 192.168.178.28"
2018.06.24 19:28:59 2: PRESENCE (EpsonDrucker) - error while processing check: Could not execute ping command: "ping -c 4 192.168.178.38"
2018.06.24 19:28:59 2: PRESENCE (FB_erreichbar) - error while processing check: Could not execute ping command: "ping -c 4 192.168.178.1"
2018.06.24 19:29:00 2: PRESENCE (FB_online) - error while processing check: Could not execute ping command: "ping -c 4 8.8.8.8"
2018.06.24 19:29:54 1: Cannot fork: Cannot allocate memory


Wie kann das sein? Das läuft so über ein Jahr und plötzlich fängt das an den Speicher voll zu machen.

Könnt ihr mir einen Tipp geben? Ich brauch leider PRESENCE!

LG
  Marlen
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 27 Juni 2018, 20:14:47
Zitat von: Marlen am 25 Juni 2018, 20:24:27
Hallo,

ich hab auch seit einigen Wochen dieses Cannot fork.

Dachte erst es liegt an einem anderen Modul das ist vor kurzem drauf hab aber scheinbar liegt es an "PRESENCE"
2018.06.24 19:28:59 2: PRESENCE (DBLinkCam_Ping) - error while processing check: Could not execute ping command: "ping -c 4 192.168.178.28"
2018.06.24 19:28:59 2: PRESENCE (EpsonDrucker) - error while processing check: Could not execute ping command: "ping -c 4 192.168.178.38"
2018.06.24 19:28:59 2: PRESENCE (FB_erreichbar) - error while processing check: Could not execute ping command: "ping -c 4 192.168.178.1"
2018.06.24 19:29:00 2: PRESENCE (FB_online) - error while processing check: Could not execute ping command: "ping -c 4 8.8.8.8"
2018.06.24 19:29:54 1: Cannot fork: Cannot allocate memory


Wie kann das sein? Das läuft so über ein Jahr und plötzlich fängt das an den Speicher voll zu machen.

Könnt ihr mir einen Tipp geben? Ich brauch leider PRESENCE!

LG
  Marlen

Wenn du hier etwas gelesen hast, dann weißt du was zu tun ist:

1. auf Perl 5.26 ggf. 5.22 wechseln
2. aktuelle DOIF-Version nehmen
3. einzelne Module abschalten bis das Problem eingekreist ist
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 27 Juni 2018, 20:51:15
Wie führe ich am besten die Perl Version 5.26 an einfachsten nach?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Fixel2012 am 22 Juli 2018, 13:57:17
Zitat von: Burny4600 am 27 Juni 2018, 20:51:15
Wie führe ich am besten die Perl Version 5.26 an einfachsten nach?

Das frage ich mich tatsächlich auch. Habe aus dem Internet nichts nützliches entnehmen können.

Hat da jemand einen Tipp?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 22 Juli 2018, 15:29:12
https://perlbrew.pl/ (https://perlbrew.pl/)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Shadow3561 am 22 Juli 2018, 15:32:35
Ich habe es mit perlbrew installiert und als Standard gesetzt.
Einfach mal nach perlbrew suchen, es gibt genug Tutorials.

MfG
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 22 Juli 2018, 18:01:46
Ich finde ActivePerl am einfachsten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 22 Juli 2018, 18:10:04
Hatte nicht hier im Thread jemand eine Anleitung gepostet?

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 22 Juli 2018, 23:27:07
Im Post #273 ist eine sehr gute Anleitung für Perlbrew.
Mit Active Perl bin ich leider nicht zurechtkommen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mark79 am 02 August 2018, 14:38:02
Hallo,

ich glaube ich habe das Problem nun auch, jedoch passiert das direkt beim Start von Fhem.

Der Fhem Prozess genehmigt sich innerhalb von 15 Sekunden nach Start gut ~50% Ram Speicher von 4 GB und 100% CPU Last auf einem Core.
Fhem ist dann natürlich nicht zu erreichen...

Meint ihr das liegt an der Perl Version?
ii  perl                                                  5.24.1-3+deb9u4                         arm64        Larry Wall's Practical Extraction and Report Language
ii  perl-base                                             5.24.1-3+deb9u4                         arm64        minimal Perl system
ii  perl-modules-5.24                                     5.24.1-3+deb9u4                         all          Core Perl modules
ii  perl-openssl-defaults:arm64                           3                                       arm64        version compatibility baseline for Perl OpenSSL packages


Das komische ist, das ich nichts upgradet habe. Vorher lief alles. Ich habe ein älteres Fhem Backup eingespielt, aber das hat auch nicht geholfen.

Bei mir läuft Fhem in einem LXC Container, dort habe ich nur das Wirtsystem aktualisiert (apt-get dist-upgrade).

Im Moment stehe ich auf dem Schlauch.... bin aber gerade dabei perlbrew mit Perl 5.20.2 zu installieren: https://forum.fhem.de/index.php/topic,84372.270.html


Viele Grüße
Mark
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 02 August 2018, 15:20:44
Hallo Zusammen,

auch bei mir ist das Problem des Speicheranstiegs seit gestern (Update des Systems und FHEM) wieder zu beobachten.

Update:
Das Problem bei mir hat einen neuen (anderen Ursprung), also bitte ignorieren.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 26 September 2018, 12:10:45
Es ist nun einige Zeit mit der Fehlerermittlung her.
Hat sich in der Zwischenzeit eine Fehlererörterung ergeben und entsprechende Maßnahmen?
Derzeit behelfe ich mich immer noch mit einem zyklischem Reboot ab.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 26 September 2018, 15:58:59
Die Ursachen können so verschieden sein, dass es dafür nicht wirklich irgendwelche Maßnahmen gibt, die man ergreifen könnte. Es wurde bereits festgestellt, das bestimmte Regular Expressions mit bestimmten Perl Versionen ein solches Problem hervorrufen können. Diese Regular Expressions müssen nicht mal zwangsläufig in einem FHEM Modul vergraben sein, sondern können auch in einer Perl Library stecken. Im Sird Modul wurde z.B. ebenfalls ein solches Problem gefunden. Dieses wurde durch eine XML Bibliothek hervorgerufen, die in ganz bestimmten Versionen und unter Verwendung ganz spezieller Funktionen Speicher nicht mehr freigegeben hat. Mit anderen Worten, die Bugs stecken durchaus in Perl Bibliotheken drin, auf die die Entwickler von FHEM Modulen keinen Einfluss haben.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gandy am 17 Oktober 2018, 15:31:29
Hallo Rudi,

meine Hoffnung, dass sich das Thema mit dem Update auf Ubuntu 18.04 und Perl 5.26.1 gibt, hat sich zerschlagen, wäre wohl auch zu einfach gewesen...

Typischerweise läuft meine Produktivumgebung etwa 10 Tage, bis Forks fehlschlagen, beim letzten Monatswechsel aber auch mal nur einen Tag lang. Da ich nicht jeden Tag das Logfile checke, merke ich das mit Tagen Verzögerung anhand irgendwelcher Nebeneffekte. Schöner fände ich es, hier auf ein Event reagieren zu können.

Was würdest Du zu folgender Änderung sagen?

--- fhem.pl     (Revision 17550)
+++ fhem.pl     (Arbeitskopie)
@@ -5311,6 +5311,7 @@
   if(!defined($pid)) {
     Log 1, "Cannot fork: $!";
     stacktrace() if($attr{global}{stacktrace});
+    DoTrigger("global", "CANNOT_FORK", 1);
     return undef;
   }


Danke und beste Grüße,
Andy.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 17 Oktober 2018, 17:57:12
Habs eingebaut.
Auchg die stacktrace Zeile.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gandy am 17 Oktober 2018, 18:29:38
Danke. War die stacktrace Zeile nicht drin? Hatte extra ein svn diff gemacht.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gandy am 09 November 2018, 08:07:56
Nachtrag auf Nachfrage: Hier als Beispiel mein zugehöriges Notify zum automatischen Restart nach einem CANNOT_FORK:


define nf.cannot_fork.restart notify global:CANNOT_FORK shutdown restart


Dieses Notify hat vorgestern erfolgreich getriggert und all die unangenehmen Nebeneffekte verhindert.

Grüße,
Andy.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: maci am 12 November 2018, 13:42:59
Ich habe das Problem auch, nur baut sich das bei mir über Tage auf.
Derzeit (seit 8. Nov) ist alles stabil im Speicherverbrauch.
Aber irgendwann wird das wieder zuschlagen.
Ich habe das nur beim 2. Server, der zur Zeit mit ca 75 MB Speicherverbrauch läuft.
Ist ein Pi2.
Hier läuft ein OWServer , Fhem und ein Midori Browser im Kioskmodus.
Allerdings erstelle ich hier keine Plots und fast keine Logs.
Die einzigen Logs sind Fhemlog und die Sysmon Logs.

Der Hauptserver ist ein Pi3, hier hatte ich das Problem noch nie.
Hier habe ich immer so um die 330 MB Speicherverbrauch. Hier läuft nur Fhem und DbLog

Bzgl Erkennung: mir ist nicht wirklich klar, wie das abfangen kann.
Das notify im Beitrag davor: Erkennt dieses das Auftreten des Fehlers, ohne zusätzliche Auswertung, das "CANNOT FORK" ?  :-\

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 12 November 2018, 23:07:37
Das erkennt wenn der Speicher ausgegangen ist und startet fhem dann neu. Das kannst du eigentlich immer einbauen, wenn du irgendwelche Probleme dahingehend hast.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: maci am 15 November 2018, 10:34:41
Zitat von: mumpitzstuff am 12 November 2018, 23:07:37
Das erkennt wenn der Speicher ausgegangen ist und startet fhem dann neu. Das kannst du eigentlich immer einbauen, wenn du irgendwelche Probleme dahingehend hast.

Ist nun auf beiden meiner Fhem Installationen eingebaut.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 15 November 2018, 11:38:48
Wobei es nur die Symptome beseitigt. Man sollte trotzdem den Grund nachgehen ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 18 November 2018, 11:37:43
Hallo,

"leider" kann ich zur Problemlösung nicht mehr viel beitragen, da CANNOT_FORK bei mir, seit März 2018 (derzeit) nicht mehr aufgetreten ist. Ich will aber für alle Fälle gewappnet sein und hatte bisher ein notify am laufen welches nur Fhem neu gestartet hätte.

Was habt ihr für Erfahrungen gemacht, reicht es aus, bei diesem Fehler Fhem alleine neu zu starten oder sollte hier gleich der Raspi komplett neu gestartet werden, wenn Fhem auf einem Raspi läuft.

Klar ist natürlich die Ursache für dieses Verhalten könnte gefunden und beseitigt werden, aber bis dies erfolgt ist, will man ja zumindest etwas vorsorgen.

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 18 November 2018, 11:48:21
Das es am Speicherverbrauch FHEM liegt, wäre ein Reboot vom Pi Overkill. Wir sind in der Unix und nicht in der Windows Welt .....
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: yamaha1983 am 21 November 2018, 08:50:33
Hallo,

ich hatte bis gestern das gleiche Problem. Mein Perl war 5.24.1 und per Grafana habe ich meinen Speicherverbrauch mitgeloggt. Es war wie hier mehrfach schon beschrieben. Der Arbeitsspeicher lief voll, forken ging an einem punkt nicht mehr und selbst FHEM hat irgendwann die grätsche gemacht.

Über Perlbrew habe ich dann "mühselig" die Perlversion 5.20.3 neben meinem oben genannten Systemperl kompiliert.
Naja, ein direktes starten mit der alten Version war dann auch nicht möglich, weil dann erstmal etliche Module fehlten. Diese konnten per CPAN auch nachkompiliert werden. Nach gefühlten 10 Umstellversuchen habe ich jetzt alle Module beisammen :).
Und ja, was soll ich sagen. Der Speicher ist seitdem absolut stabil bei 100MB. Im Anhang noch die Graphen.

Also probiert es ruhig aus. Klar ist es etwas Aufwand, aber mit perlbrew kann man nicht viel falsch machen.
Vielleicht noch als Tipp. Richtet perlbrew so ein, dass jeder Benutzer von den kompilierten Perlversionen profitieren kann. Ansonsten muss jeder Benutzer für sich alles kompilieren, wenn er etwas auf dem System davon nutzen möchte. Kostet Speicherplatz und vor allem Nerven und Zeit.

Dazu:
Zuerst Backup ;)
Dann System auf den aktuellen Stand bringen:
per root folgendes in die Shell:
apt-get update
apt-get upgrade
Entwicklertools installieren:
apt-get install build-essentials
Nun Perlbrew installieren:
export PERLBREW_ROOT=/opt/perlbrew
mkdir /opt/perlbrew
cd /opt/perlbrew
curl -L https://install.perlbrew.pl | bash

Nach der schnellen Installation kann man diese prüfen mit
perlbrew init

Diese gibt dann nochmal den freundlichen hinweis, dass man in der .bashrc folgenden Eintrag hinzufügen muss:
Öffnen der Bashrc: vi ~/.bashrc
Einfügen der Zeile am Ende: source /opt/perlbrew/etc/bashrc

Zum Testen der Wirksamkeit einfach nochmal ausloggen und per SSH neu als Root einloggen. Dann sollte der befehl perlbrew per Autovervollständigen (TAB Taste) zur verfügung stehen und "perlbrew init" quittiert mit einem "perlbrew root (/opt/perlbrew)" is installed.

Nochmal als Hinweis. Wenn man nun später etwas an den anderen Perlversionen ändern möchte, geht das nur über den root benutzer, weil er jetzt der Besitzer von /opt/perlbrew ist. Alle weiteren Nutzer wie pi, oder fhem brauchen keine Besitzrechte an /opt/perlbrew um es zu nutzen.

Damit jetzt die anderen Nutzer wie pi und fhem auch perlbrew nutzen können müssen folgende zwei Zeilen hinzugefügt werden.
Als pi Benutzer einloggen: vi ~/.profile
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc

Bei meinem FHEM-Installation (unter /opt/fhem) mit dem Benutzer fhem gibt es leider keine .bashrc und diese wird auch nicht verwendet, wenn man diese erstellt. Aber die Datei .profile wird ausgewertet.
Daher einloggen als Benutzer fhem: vi ~/.profile
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc

Jetzt sind die Benutzer dafür eingerichtet perlbrew zu benutzen. Das kann ebenfalls mit einem Neueinloggen in die Shell mit dem Benutzer geprüft werden. Hier wieder perlbrew init ausführen.

Nun geht es an das erstellen der alten Perlversion 5.20.3. Einloggen als root!
Ersteinmal kann geprüft werden, was perlbrew alles an perlversionen kompilieren kann. Dazu der Befehl
perlbrew available. Hier sieht man auch direkt, das wesentlich neuere Versionen verfügbar sind, als mit raspbian ausgeliefert werden. Ob diese funktionieren, weiß ich nicht. Daher bleiben wir erstmal bei 5.20.3. Alles weitere könnt ihr ja später selbst probieren :).

Damit das Perl nun kompiliert und für perlbrew verfügbar wird, muss man nun den Befehl
perlbrew install perl-5.20.3
absetzen. Perlbrew läd sich selbstständig die sourcen für perl runter und fängt an diese zu kompilieren. Das dauert jetzt eine ganze weile und die Shell darf nicht geschlossen werden, da sonst der Prozess beendet wird. Daher empfiehlt es sich eigentlich, den Prozess mit nohup zu starten:
nohup perlbrew install perl-5.20.3
Habt ihr aber schon gestartet und wollt diesen Prozess nachträglich von der session abkoppeln gibt es noch einen Trick:
Nach der Eingabe von perlbrew install perl-5.20.3 kommt die shell nicht zum prompt zurück.
Drückt hier einfach STRG+Z, dann steht in der Shell "Angehalten". anschließend gebt ihr "bg" ein. Nun arbeitet der Prozess im Hintergrund weiter, ist aber noch mit der Shell verheiratet und würde beim schließen mitsterben. Daher muss der Prozess noch abgehangen werden. Das geht mit dem Befehl disown %1 (wenn ihr keine weiteren Hintergrundprozesse durch BG erzeugt habt, ist es die 1, ansonsten die job id prüfen).

Während des Kompilierens wird sämtlicher output nach /opt/perlbrew/build.perl-5.20.3.log geschrieben. Ist perlbrew fertig wird am Ende des Logfiles die Meldung "##### Brew Finished #####" geschrieben.
Prüft dann nach, ob dem so ist mit dem Befehl:
perlbrew list
Hier sollte nun die perlversion zu sehen sein.
gebt ihr nun ein perl -v ein, seht ihr dass noch die alte System Perlversion zur Verfügung steht.
Der temporäre Wechsel erfolgt über den Befehl: perlbrew use perl-5.20.3
Jetzt nochmal perl -v eingeben und man sieht dann die Version 5.20.3 in der Ausgabe.

Jetzt kommt der etwas unangenehme Teil. Jetzt benötigt ihr noch sämtliche Module. FHEM ist ja nett und schreibt alles brav ins Log, wenn ein Modul fehlt. Hier kann in der FHEM Log nach @INC gesucht werden und ihr bekommt dann die entsprechenden Hinweise. Um es auch aber etwas zu erleichtern, habe ich die Module die ich brauchte hier mal zusammengetragen:

JSON
Device::SerialPort
URI::Escape
RPC::XML
IO::Socket::SSL
Crypt::CBC
Switch
Net::WebSocket::Server::Connection
Crypt::Cipher::AES
Crypt::Rijndael_PP
LWP::Simple
MIME::Base64
SOAP::Lite

Wenn ihr nun diese Module installiert haben wollt, dann geht das einfach über das cpan tool.
Bitte vorher mit perlbrew use perl-5.20.3 in das perlbrew perl wechseln und dann einfach
cpan JSON
...
cpan SOAP::Lite
eingeben.
Oder einfach alles in eine Zeile :)
cpan JSON Device::SerialPort URI::Escape RPC::XML IO::Socket::SSL Crypt::CBC Switch Net::WebSocket::Server::Connection Crypt::Cipher::AES Crypt::Rijndael_PP LWP::Simple MIME::Base64 SOAP::Lite

Kleiner Nachtrag hier: Für das SSL Modul muss zwingend noch vorher das Paket libssl-dev installiert sein, da er sonst beim kompilieren abbricht. Also per root:
aptitude install libssl-dev

Für dblog benötigt man noch eine weitere lib:
aptitude install libmariadb-dev

Diese dann so als root mit aktiven perl-5.20.3 installieren:
cpan -T DBD::mysql DBD::MariaDB

Zweite Methode hat den Nachteil, dass man nicht sieht, wenn etwas schiefgeht. Manche Module erfordern auch eine Eingabe (die aber immer mit einem enter quittiert werden kann). Hier nutze ich persönlich gerne das Programm "screen". Damit kann man ein virtuelles Terminal erzeugen und sich jederzeit wieder darauf connecten.


Nutzt ihr auch MySQL/Maria DB müsst ihr mit root noch folgendes Paket installieren:
aptitude install libmariadb-dev
Dann lassen sich auch folgende Perlmodule erfolgreich kompilieren:
cpan DBD::mysql DBD::MariaDB

Wenn ihr es bis hier geschafft habt, dann habt ihr das Schlimmste hinter euch.
Loggt euch nun wieder als fhem ein. Killt euren FHEM Prozess.
perlbrew use perl-5.20.3
perl fhem.pl fhem.cfg (wenn nicht configDB)

Schaut jetzt unbedingt in euer FHEM Log. Sollten euch Module fehlen, wird FHEM diese euch klar benennen. Dann einfach per CPAN nachkompilieren!

Um generell zu prüfen, ob FHEM nun auch mit 5.20 läuft, einfach oben auf der FHEM Seite in das Feld folgendes eingeben;
{`perl -v`}
jetzt sollte die alte Version 5.20.3 zu sehen sein.

Hinweis: perlbrew use setzt die perlversion nur temporär für die aktuelle Session (und deren Kinder natürlich). Bei einem abmelden und neuem anmelden ist die System perlversion 5.24 wieder aktiv.
Ich habe daher in meinem Startskript von FHEM (bei mir /etc/init.d/fhem) folgendes oben nach dem Header hinzugefügt:
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3

Damit startet das FHEM dann immer brav mit der alten Version.

Es ist auch möglich perlbrew permanent als Standardperl für alle Sessions des Benutzers zu setzen. Das geht über
perlbrew switch perl-5.20.3

Das mag ich persönlich aber nicht, weil ich immer selbst und selektiv entscheiden möchte, was ich verwende.

Habt ihr mit perl use eine Version in Benutzung erkennt man das auch, wenn man perlbrew list eingibt. Dann ist dies mit einem Stern gekennzeichnet. Wollt ihr in dieser Session wieder zurück zum Systemperl ohne aus und einloggen, dann geht es über perlbrew off.

Ich persönlich finde perlbrew ganz cool und gibt einem mehr Freiheiten beim rumprobieren mit den Perlversionen. Daher denke ich das sich der Aufwand lohnt. Das Speicherproblem ist damit erstmal Geschichte.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: kroman am 23 November 2018, 08:57:35
@yamaha1983: das nenn ich mal eine detailierte Beschreibung! Besten Dank dafür  :)

Doch wie es scheint brauche ich das nun nicht mehr zu testen, denn ich habe den Schurken gefunden, welcher den Speicher voll macht: apptime

Starte ich apptime, ist nach ca. 10 Stunden der Speicher der RPi3 so voll, dass fhem nicht mehr forken kann.
Starte ich apptime nicht, gibt es kein Problem.

In Verwendung habe ich aktuelles Raspian Stretch mit Perl 5.24.1, FHEM ist auch aktuell.

@Martin, liest du mit?
Das steht im log wenn apptime gestartet wird:


2018.11.22 13:39:00 5: Cmd: >apptime<
2018.11.22 13:39:00 5: Loading ./FHEM/98_apptime.pm
2018.11.22 13:39:00 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 46.
2018.11.22 13:39:00 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 149.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 23 November 2018, 09:02:38
Zitat von: kroman am 23 November 2018, 08:57:35
@Martin, liest du mit?
Das steht im log wenn apptime gestartet wird:


2018.11.22 13:39:00 5: Cmd: >apptime<
2018.11.22 13:39:00 5: Loading ./FHEM/98_apptime.pm
2018.11.22 13:39:00 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 46.
2018.11.22 13:39:00 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 149.


Das ist eine ganz normale Meldung und kein Fehler. Damit kann man leider nichts an fangen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: yamaha1983 am 23 November 2018, 09:48:15
und ohne apptime ist es bei dir stabil?`
Denn ich hatte das vorher auch versucht bei mir und es entfernt. Aber meine große FHEM Instanz ist trotzdem übergelaufen.
Meine große Installation (mit Homematic, 433, 868, Hue, WebOS, XIAOMI) startet mit 4 FHEM Prozessen und das überlaufen konntet ihr ja im Bild erkennen. Das Entfernen von Apptime hatte mir da nicht geholfen.

Auf meinem ZeroPI laufen zwar auch einige Module, es startet aber mit 20MB und einem Prozess. Hier dauert es lange bis es mit der kleinen Version auf 40MB ansteigt.

Ich denke das Überlaufen steigt schneller, wenn der Anfangsspeicherverbrauch schon sehr hoch ist und gleichzeitig mehrere Prozesse (als Kinder des Hauptprozesses) permanent vorhanden sind.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 23 November 2018, 09:59:47
ZitatDas ist eine ganz normale Meldung und kein Fehler.
Um nicht zu sagen, ist inherent bei apptime: sie erstetzt die genannten Funktionen mit Varianten, die mehr Daten sammeln, damit man daraus Statistiken berechnen kann. Das Sammeln war mir in der Originalversion zu kostspielig, deswegen habe ich Martin zu diese Variante geraten. Meiner Ansicht nach sollte man mit apptime kurzfristig sammeln, Statisktiken anschauen, und danach FHEM neu starten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: kroman am 23 November 2018, 18:05:54
Zitat
und ohne apptime ist es bei dir stabil?

Ja. Ohne apptime sind mir noch keine Probleme aufgefallen.
Sollte sich das ändern, werde ich berichten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 29 Dezember 2018, 08:57:54
Zitat von: yamaha1983 am 21 November 2018, 08:50:33
Hinweis: perlbrew use setzt die perlversion nur temporär für die aktuelle Session (und deren Kinder natürlich). Bei einem abmelden und neuem anmelden ist die System perlversion 5.24 wieder aktiv.
Ich habe daher in meinem Startskript von FHEM (bei mir /etc/init.d/fhem) folgendes oben nach dem Header hinzugefügt:
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3

Super Beitrag!!!

Bei mir haben die Einträge nur funktioniert, wenn man in der /etc/init.d/fhem
#!/bin/sh durch #!/bin/bash ersetzt.

Anschließend
systemctl daemon-reload
systemctl restart fhem
systemctl status  fhem

Wie man im Bild sieht ist der Speicherverbrauch mit perl-5.20.3 konstant ab 29. Dec
Bei mir begann das Drama am 27. Dec mit der Umstellung auf stretch und perl-5.24.1
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 03 Januar 2019, 04:35:19
Hilfe, gleiches Problem mit cannot fork.
Hier die Ausgaben im Fehlerzustand:



pi@rfhem-pi:~ $ ps -elf | grep fhem
4 S avahi      313     1  0  80   0 -  1634 -       2018 ?        00:00:09 avahi-daemon: running [rfhem-pi.local]
1 S fhem       470     1 16  80   0 - 122505 -      2018 ?        17:49:16 /usr/bin/perl fhem.pl fhem.cfg
1 S fhem     12864   470  0  80   0 - 106157 -     Jan02 ?        00:00:01 /usr/bin/perl fhem.pl fhem.cfg
1 S fhem     18520   470  0  80   0 - 109263 -     00:14 ?        00:00:01 /usr/bin/perl fhem.pl fhem.cfg
0 S pi       26929 26911  0  80   0 -  1093 pipe_w 04:03 pts/0    00:00:00 grep --color=auto fhem


pi@rfhem-pi:~ $ ps -aux | grep fhem
avahi      313  0.0  0.0   6536   632 ?        Ss    2018   0:09 avahi-daemon: running [rfhem-pi.local]
fhem       470 16.2 46.4 490020 440584 ?       S     2018 1069:20 /usr/bin/perl fhem.pl fhem.cfg
fhem     12864  0.0 38.8 424628 369204 ?       S    Jan02   0:01 /usr/bin/perl fhem.pl fhem.cfg
fhem     18520  0.0 40.2 437052 381872 ?       S    00:14   0:01 /usr/bin/perl fhem.pl fhem.cfg
pi       26931  0.0  0.0   4372   580 pts/0    S+   04:03   0:00 grep --color=auto fhem


pi@rfhem-pi:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         949452      874408       23312        1672       51732       24480
Swap:        102396       81408       20988


fhemdebug memusage
Can't locate Devel/Size.pm in @INC (you may need to install the Devel::Size module) (@INC contains: ./FHEM/lib ./lib . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM) at (eval 804137) line 2.
BEGIN failed--compilation aborted at (eval 804137) line 2.



BlockingInfo

Pid:WAITING: Fn:PRESENCE_DoLocalFunctionScan Arg:P_WIFI_Tobias|{ ((ReadingsVal("WZ_unifi_controller","OnePlus_6T","") eq "connected") and (index(ReadingsVal("WZ_unifi_controller","OnePlus_6T_accesspoint",""), "AP ")) != -1) ? 1 : 0}|0 Timeout:60 ConnectedVia:N/A
Pid:WAITING: Fn:WOL_Ping Arg:WOL_WZ_NOTEBOOK|192.168.0.1 Timeout:4 ConnectedVia:N/A
Pid:WAITING: Fn:WOL_Ping Arg:WOL_SERVER|192.168.0.5 Timeout:4 ConnectedVia:N/A
Pid:WAITING: Fn:WOL_Ping Arg:WOL_WZ_TV|192.168.0.3 Timeout:4 ConnectedVia:N/A
Pid:WAITING: Fn:PRESENCE_DoLocalFunctionScan Arg:P_WIFI_Roswitha|{ ((ReadingsVal("WZ_unifi_controller","Honor_10","") eq "connected") and (index(ReadingsVal("WZ_unifi_controller","Honor_10_accesspoint",""), "AP ")) != -1) ? 1 : 0}|0 Timeout:60 ConnectedVia:N/A
Pid:WAITING: Fn:PRESENCE_DoLocalFunctionScan Arg:P_WIFI_Stefi|{ ((ReadingsVal("WZ_unifi_controller","OnePlus5T","") eq "connected") and (index(ReadingsVal("WZ_unifi_controller","OnePlus5T_accesspoint",""), "AP ")) != -1) ? 1 : 0}|0 Timeout:60 ConnectedVia:N/A
Pid:WAITING: Fn:WOL_Ping Arg:WOL_SZ_TV|192.168.0.7 Timeout:4 ConnectedVia:N/A


list .* TYPE
AR_Decke                 IT
AZ_Decke                 IT
A_Szenen                 LightScene
Alexas                   echodevice
AsyncCMD                 dummy
BAD_Decke                IT
BAD_Trockner             TASMOTA_DEVICE
BAD_Waschmaschine        TASMOTA_DEVICE
BM_Badezimmer_Tuer       HUEDevice
BM_Badezimmer_Wanne      HUEDevice
BM_Kammerl               HUEDevice
BM_Kueche_Essbereich     HUEDevice
BM_Kueche_Tuer           HUEDevice
BM_Toilette              HUEDevice
CUL433                   CUL
DIM_SZ_Stefi_Dimmer      HUEDevice
DIM_SZ_Tobi_Dimmer       HUEDevice
DIM_VR_Master_Dimmer     HUEDevice
ECHO_90cc95530ddc4b55a55d7249ae19f177     echodevice
ECHO_Badezimmer          echodevice
ECHO_Julians_Zimmer      echodevice
ECHO_Kueche              echodevice
ECHO_Schlafzimmer        echodevice
ECHO_Wohnzimmer          echodevice
FileLog_IT_00000000      FileLog
FileLog_IT_1527xa9484     FileLog
HUEGroup0                HUEDevice
HUEGroup1                HUEDevice
HUEGroup2                HUEDevice
HUEGroup3                HUEDevice
HUEGroup4                HUEDevice
IT_00000000              IT
IT_000000FFFF            IT
IT_00000F0FFF            IT
IT_00000FF0FF            IT
IT_00000FFFFF            IT
IT_0111111111            IT
IT_0F11111111            IT
IT_1527x1bf99            IT
IT_1527x29890            IT
IT_1527x3e25e            IT
IT_1527x4f804            IT
IT_1527x5d4a0            IT
IT_1527x5e600            IT
IT_1527x6b9d0            IT
IT_1527x6dcf1            IT
IT_1527x7c720            IT
IT_1527x87b59            IT
IT_1527x9cbb9            IT
IT_1527xa46a4            IT
IT_1527xa54a9            IT
IT_1527xa9484            IT
IT_1527xbdbfe            IT
IT_1527xbffff            IT
IT_1527xdf5fe            IT
IT_1527xe87fb            IT
IT_1527xe8feb            IT
IT_1527xe8fec            IT
IT_1527xe8ff5            IT
IT_1527xe8ff8            IT
IT_1527xe8ffb            IT
IT_1527xe8ffd            IT
IT_1527xeec39            IT
IT_1527xeffff            IT
IT_1F11111111            IT
IT_F0000F000F            IT
IT_F111111111            IT
IT_FF000F000F            IT
IT_FF00F0000F            IT
IT_FF11111111            IT
IT_HE800_30581_12        IT
IT_HE800_30582_15        IT
IT_HE800_30583_14        IT
J_Decke                  IT
J_Leselicht              IT
J_Nachlicht              IT
J_Szenen                 LightScene
KUECHE_Decke             IT
KUECHE_Essbereich        IT
KUECHE_Schraenke         IT
KUECHE_Spuelmaschine     TASMOTA_DEVICE
KUECHE_Szenen            LightScene
Kodi_SZ                  KODI
Kodi_WZ                  KODI
LIGHT_Badezimmer_Wanne     HUEDevice
LIGHT_Kammerl            HUEDevice
LIGHT_Kueche_Essbereich     HUEDevice
LIGHT_Kueche_Tuer        HUEDevice
LIGHT_Toilette           HUEDevice
Logfile                  FileLog
P_All                    structure
P_Bad_All                structure
P_Bad_Tuer               dummy
P_Bad_Wanne              dummy
P_Kammerl_All            dummy
P_Kueche_All             structure
P_Kueche_Essbereich      dummy
P_Kueche_Tuer            dummy
P_Toilette_All           dummy
P_WIFI_All               structure
P_WIFI_Roswitha          PRESENCE
P_WIFI_Stefi             PRESENCE
P_WIFI_Tobias            PRESENCE
RoomCMD                  dummy
SVG_essbereich_light_log_1     SVG
SVG_spuele_log_1         SVG
SVG_trockner_log_1       SVG
SVG_waschmaschine_log_1     SVG
SZ_IndirekteBel          IT
SZ_Kasten                IT
SZ_NachtLichtStefi       HUEDevice
SZ_NachtLichtTobi        HUEDevice
SZ_Szene_Alle            LightScene
SZ_Szene_Stefi           LightScene
SZ_Szene_Tobi            LightScene
Switch_Arbeitsstation     UnifiSwitch
Switch_Schlafzimmer      UnifiSwitch
Switch_Wohnzimmer__150W_     UnifiSwitch
Switch_Wohnzimmer__PoE_passive_     UnifiSwitch
TEMP_Badezimmer          HUEDevice
TEMP_Kammerl             HUEDevice
TEMP_Kueche_Essbereich     HUEDevice
TEMP_Kueche_Tuer         HUEDevice
TEMP_Toilette            HUEDevice
Tageslicht               dummy
VR_Decke                 IT
VR_Klingel               dummy
WC_Decke                 IT
WC_Lueftung              IT
WEB                      FHEMWEB
WEB_192.168.0.1_62433     FHEMWEB
WEB_192.168.0.1_62492     FHEMWEB
WEB_192.168.0.1_62636     FHEMWEB
WEB_192.168.0.55_62238     FHEMWEB
WEBhabridge              FHEMWEB
WEBphone                 FHEMWEB
WEBtablet                FHEMWEB
WOL_SERVER               WOL
WOL_SZ_TV                WOL
WOL_WZ_NOTEBOOK          WOL
WOL_WZ_TV                WOL
WZ_Anybody_In            dummy
WZ_Decke                 IT
WZ_HUE_WohnwandOben      HUEDevice
WZ_KUCHE_Szenen          LightScene
WZ_KUECHE_Nachtlicht     dummy
WZ_Stehlampe             IT
WZ_Szenen                LightScene
WZ_Weih_Fenster          IT
WZ_WohnwandU             IT
WZ_unifi_controller      Unifi
act_AsyncCMD             notify
act_BAD_DeviceReady      notify
act_BM_Battery           notify
act_BM_Kammerl           notify
act_EchoVoice            notify
act_KUECHE_DeviceReady     notify
act_RoomCMD              notify
act_Tageslicht_WZ        notify
act_VR_Klingel           notify
act_off_PCs_SZ_OFF       notify
act_on_BM_Badezimmer     notify
act_on_BM_Kueche_Essbereich     notify
act_on_BM_Kueche_Tuer     notify
act_on_BM_Toilette       notify
act_on_FHEM_Initialized     notify
act_on_Master            notify
act_on_PCs_SZ_ON         notify
act_on_PCs_WZ_OFF        notify
act_on_PCs_WZ_ON         notify
act_on_P_Bad_All         notify
act_on_P_Kammerl_All     notify
act_on_P_Kueche_All      notify
act_on_Playstate_SZ      notify
act_on_Playstate_WZ      notify
act_sunset_WZ            notify
allowed_WEB              allowed
allowed_WEBphone         allowed
allowed_WEBtablet        allowed
allowed_telnetPort       allowed
at_Backup                at
autocreate               autocreate
essbereich_light_log     FileLog
eventTypes               eventTypes
fhemstart_fertig         notify
global                   Global
hueBridge1               HUEBridge
hueBridge1_HUEGroup5     HUEDevice
hueBridge1_HUEGroup6     HUEDevice
initialUsbCheck          notify
job_NachtAllesAus        at
job_NachtlichtReset      at
job_Tageslicht_sunrise     at
job_Tageslicht_sunset     at
job_Tageslicht_sunset_tl     at
kueche_spuele_log        FileLog
myBroker                 MQTT
myTL                     Twilight
pushmsg_all              PushNotifier
telnetForBlockingFn_1546090907     telnet
telnetPort               telnet
trockner_log             FileLog
waschmaschine_log        FileLog
watchdog_Kodi_SZ_paused     watchdog
watchdog_Kodi_SZ_stopped     watchdog
watchdog_Kodi_WZ_paused     watchdog
watchdog_Kodi_WZ_stopped     watchdog
watchdog_Niemand_Zuhause     watchdog
watchdog_Niemand_beim_Essbereich     watchdog
watchdog_Niemand_im_Bad_Tuer     watchdog
watchdog_Niemand_im_Bad_Wanne     watchdog
watchdog_Niemand_im_Kammerl     watchdog
watchdog_Niemand_im_Klo_Licht     watchdog
watchdog_Niemand_im_Klo_Lueftung     watchdog
watchdog_Niemand_in_Kueche     watchdog
watchdog_Spuelmaschine     watchdog
watchdog_Trockner        watchdog
watchdog_Waschmaschine     watchdog

apptime max


active-timers: 45; max-active timers: 115; max-timer-load: 20  min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 6135.3ms; totAvgDly: 39.7ms

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
tmr-watchdog_Trigger                     HASH(0x38913e0)                       6131        3   18050.76  6016.92     3.33     1.79 02.01. 16:05:27 HASH(watchdog_Niemand_Zuhause)
A_Szenen                                 LightScene_Set                        6127       11   65734.13  5975.83     0.00     0.00 02.01. 16:05:27 HASH(A_Szenen); A_Szenen; scene; Aus
act_on_Master                            notify_Exec                           6095        5   29887.51  5977.50     0.00     0.00 02.01. 15:39:06 HASH(act_on_Master); HASH(DIM_VR_Master_Dimmer)
tmr-at_Exec                              HASH(0x5071a78)                       5957        3   17848.60  5949.53     3.92     1.54 02.01. 01:00:05 HASH(job_NachtAllesAus)
tmr-echodevice_GetSettings               HASH(0x3d7d610)                       5069     3477  195837.46    56.32  4062.53     7.43 02.01. 04:49:26 HASH(Alexas)
tmr-echodevice_GetSettings               HASH(0x5043ee8)                       5038     3522   74314.45    21.10 14552.24    23.02 01.01. 07:40:29 HASH(ECHO_Kueche)
tmr-echodevice_GetSettings               HASH(0x4f7d7e8)                       5037     3540   82945.21    23.43 14503.81    22.19 01.01. 13:09:51 HASH(ECHO_Badezimmer)
tmr-echodevice_GetSettings               HASH(0x5052be0)                       5033     3585   74701.46    20.84  4737.76    20.67 31.12. 20:38:29 HASH(ECHO_Julians_Zimmer)
WEB                                      FW_Read                               4009      203   17770.24    87.54     0.00     0.00 03.01. 04:00:50 HASH(WEB)
tmr-HttpUtils_Err                        HASH_unnamed                          3566       32    3961.36   123.79  3607.67   274.32 01.01. 15:24:47 HASH(0xdc40168)
WZ_KUCHE_Szenen                          LightScene_Set                        2593        7    2593.92   370.56     0.00     0.00 02.01. 19:39:36 HASH(WZ_KUCHE_Szenen); WZ_KUCHE_Szenen; scene; Nachtlicht
tmr-echodevice_GetSettings               HASH(0x3a5cfa8)                       2414     3578   61057.57    17.06 11702.74    25.11 01.01. 15:08:17 HASH(ECHO_Wohnzimmer)
tmr-watchdog_Trigger                     HASH(0x4f7d320)                       1234        3    2790.11   930.04    39.35    14.20 31.12. 21:01:09 HASH(watchdog_Spuelmaschine)
tmr-watchdog_Trigger                     HASH(0x3ee5130)                       1176       44   34880.73   792.74   296.00    10.70 02.01. 20:33:46 HASH(watchdog_Niemand_in_Kueche)
P_Kueche_Tuer                            dummy_Set                             1174      738   35972.01    48.74     0.00     0.00 02.01. 20:33:46 HASH(P_Kueche_Tuer); P_Kueche_Tuer; absent
P_Kueche_All                             structure_Notify                      1167   377045   64699.52     0.17     0.00     0.00 02.01. 20:33:46 HASH(P_Kueche_All); HASH(P_Kueche_Tuer)
tmr-watchdog_Trigger                     HASH(0x4d386d0)                       1164       29    7225.09   249.14   137.94     7.22 01.01. 07:56:09 HASH(watchdog_Niemand_beim_Essbereich)
P_Kueche_Essbereich                      dummy_Set                             1162      664    7889.04    11.88     0.00     0.00 01.01. 07:56:09 HASH(P_Kueche_Essbereich); P_Kueche_Essbereich; absent
act_on_P_Kueche_All                      notify_Exec                           1157       72   40975.04   569.10     0.00     0.00 02.01. 20:33:46 HASH(act_on_P_Kueche_All); HASH(P_Kueche_All)
act_on_PCs_WZ_OFF                        notify_Exec                           1147       53   21393.43   403.65     0.00     0.00 03.01. 02:21:49 HASH(act_on_PCs_WZ_OFF); HASH(WOL_WZ_NOTEBOOK)
act_on_PCs_WZ_ON                         notify_Exec                           1140       53   29236.73   551.64     0.00     0.00 31.12. 19:03:51 HASH(act_on_PCs_WZ_ON); HASH(WOL_WZ_TV)
WZ_Szenen                                LightScene_Set                        1135       66   62492.59   946.86     0.00     0.00 31.12. 19:03:51 HASH(WZ_Szenen); WZ_Szenen; scene; Fernsehlicht
KUECHE_Szenen                            LightScene_Set                        1116       47   52134.69  1109.25     0.00     0.00 01.01. 07:56:09 HASH(KUECHE_Szenen); KUECHE_Szenen; scene; Aus
J_Szenen                                 LightScene_Set                        1108       11   12171.56  1106.51     0.00     0.00 01.01. 01:00:04 HASH(J_Szenen); J_Szenen; scene; Aus
pushmsg_all                              PushNotifier_Set                      1050       16    9727.26   607.95     0.00     0.00 31.12. 21:01:09 HASH(pushmsg_all); pushmsg_all; message; Spülmaschine; fertig,; bitte; ausräumen!; 21:01:08
act_on_BM_Kueche_Tuer                    notify_Exec                            821     1381  430974.28   312.07     0.00     0.00 01.01. 07:07:10 HASH(act_on_BM_Kueche_Tuer); HASH(BM_Kueche_Tuer)
tmr-at_Exec                              HASH(0x109a56c8)                       809        1     809.86   809.86     3.12     3.12 02.01. 18:11:45 HASH(at_BAD_Waschmaschine_Retry_2)
tmr-watchdog_Trigger                     HASH(0x4bf4020)                        759        8    5225.75   653.22    96.39    12.99 02.01. 20:38:10 HASH(watchdog_Trockner)
tmr-watchdog_Trigger                     HASH(0x4f3b580)                        748        2    1475.72   737.86     0.96     0.82 02.01. 17:51:45 HASH(watchdog_Waschmaschine)
VR_Klingel                               dummy_Set                              746        2     752.42   376.21     0.00     0.00 31.12. 23:52:54 HASH(VR_Klingel); VR_Klingel; on
act_VR_Klingel                           notify_Exec                            739        2     739.57   369.79     0.00     0.00 31.12. 23:52:54 HASH(act_VR_Klingel); HASH(VR_Klingel)
tmr-at_Exec                              HASH(0x109b3ff8)                       717        1     717.47   717.47     0.65     0.65 02.01. 18:01:45 HASH(at_BAD_Waschmaschine_Retry_1)
tmr-WakeUpFn                             HASH_unnamed                           643      367   28542.87    77.77  5978.10   108.98 31.12. 19:26:20 HASH(0x66c43e8)
SZ_Kasten                                IT_Set                                 641       66   24179.52   366.36     0.00     0.00 31.12. 19:26:20 HASH(SZ_Kasten); SZ_Kasten; off
act_on_BM_Badezimmer                     notify_Exec                            578     1016  196233.74   193.14     0.00     0.00 02.01. 16:51:23 HASH(act_on_BM_Badezimmer); HASH(BM_Badezimmer_Tuer)
CUL433                                   CUL_Get                                578     3140 1099343.57   350.11     0.00     0.00 02.01. 20:47:14 HASH(CUL433);  ; raw; isF0000F0F0FFF
tmr-watchdog_Trigger                     HASH(0x3fbba78)                        524       51   13495.39   264.62   384.02    15.03 02.01. 18:23:37 HASH(watchdog_Niemand_im_Bad_Tuer)
P_Bad_Tuer                               dummy_Set                              522      291   14190.56    48.76     0.00     0.00 02.01. 18:23:37 HASH(P_Bad_Tuer); P_Bad_Tuer; absent
P_Bad_All                                structure_Notify                       515   377045   43336.09     0.11     0.00     0.00 02.01. 18:23:37 HASH(P_Bad_All); HASH(P_Bad_Tuer)
act_on_P_Bad_All                         notify_Exec                            505      101   20122.48   199.23     0.00     0.00 02.01. 18:23:37 HASH(act_on_P_Bad_All); HASH(P_Bad_All)
act_on_PCs_SZ_ON                         notify_Exec                            439       43    7891.02   183.51     0.00     0.00 31.12. 21:08:56 HASH(act_on_PCs_SZ_ON); HASH(WOL_SZ_TV)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 03 Januar 2019, 04:39:31
Nach Neustart von FHEM (systemctl restart fhem):


pi@rfhem-pi:~ $ ps -elf | grep fhem
4 S avahi      313     1  0  80   0 -  1634 -       2018 ?        00:00:09 avahi-daemon: running [rfhem-pi.local]
1 S fhem     27026     1 24  80   0 - 14308 -      04:27 ?        00:00:17 /usr/bin/perl fhem.pl fhem.cfg
1 S fhem     27034 27026  0  80   0 - 11723 -      04:28 ?        00:00:00 /usr/bin/perl fhem.pl fhem.cfg
1 S fhem     27035 27026  0  80   0 - 11723 -      04:28 ?        00:00:00 /usr/bin/perl fhem.pl fhem.cfg
0 S pi       27080 26911  0  80   0 -  1093 pipe_w 04:29 pts/0    00:00:00 grep --color=auto fhem

pi@rfhem-pi:~ $ ps -aux | grep fhem
avahi      313  0.0  0.1   6536  1492 ?        Ss    2018   0:09 avahi-daemon: running [rfhem-pi.local]
fhem     27026 24.0  5.5  57232 52280 ?        S    04:27   0:22 /usr/bin/perl fhem.pl fhem.cfg
fhem     27034  0.0  4.0  46892 38256 ?        S    04:28   0:00 /usr/bin/perl fhem.pl fhem.cfg
fhem     27035  0.0  4.0  46892 38256 ?        S    04:28   0:00 /usr/bin/perl fhem.pl fhem.cfg
fhem     27092  0.5  5.0  57232 48136 ?        S    04:29   0:00 /usr/bin/perl fhem.pl fhem.cfg
fhem     27093  0.5  0.0   4928   720 ?        S    04:29   0:00 ping -c 1 -w 2 192.168.0.7
fhem     27094  1.0  5.0  57232 48136 ?        S    04:29   0:00 /usr/bin/perl fhem.pl fhem.cfg
fhem     27095  0.0  0.0   4928   696 ?        S    04:29   0:00 ping -c 1 -w 2 192.168.0.3
pi       27097  0.0  0.0   4372   548 pts/0    S+   04:29   0:00 grep --color=auto fhem



pi@rfhem-pi:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         949452      127404      755864        1684       66184      771140
Swap:        102396       31380       71016


fhemdebug memusage
Can't locate Devel/Size.pm in @INC (you may need to install the Devel::Size module) (@INC contains: ./FHEM/lib ./lib . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM) at (eval 804137) line 2.
BEGIN failed--compilation aborted at (eval 804137) line 2.


BlockingInfo
No BlockingCall processes running currently

list .* TYPE
AR_Decke                 IT
AZ_Decke                 IT
A_Szenen                 LightScene
Alexas                   echodevice
AsyncCMD                 dummy
BAD_Decke                IT
BAD_Trockner             TASMOTA_DEVICE
BAD_Waschmaschine        TASMOTA_DEVICE
BM_Badezimmer_Tuer       HUEDevice
BM_Badezimmer_Wanne      HUEDevice
BM_Kammerl               HUEDevice
BM_Kueche_Essbereich     HUEDevice
BM_Kueche_Tuer           HUEDevice
BM_Toilette              HUEDevice
CUL433                   CUL
DIM_SZ_Stefi_Dimmer      HUEDevice
DIM_SZ_Tobi_Dimmer       HUEDevice
DIM_VR_Master_Dimmer     HUEDevice
ECHO_90cc95530ddc4b55a55d7249ae19f177     echodevice
ECHO_Badezimmer          echodevice
ECHO_Julians_Zimmer      echodevice
ECHO_Kueche              echodevice
ECHO_Schlafzimmer        echodevice
ECHO_Wohnzimmer          echodevice
FileLog_IT_00000000      FileLog
FileLog_IT_1527xa9484     FileLog
HUEGroup0                HUEDevice
HUEGroup1                HUEDevice
HUEGroup2                HUEDevice
HUEGroup3                HUEDevice
HUEGroup4                HUEDevice
IT_00000000              IT
IT_000000FFFF            IT
IT_00000F0FFF            IT
IT_00000FF0FF            IT
IT_00000FFFFF            IT
IT_0111111111            IT
IT_0F11111111            IT
IT_1527x1bf99            IT
IT_1527x29890            IT
IT_1527x3e25e            IT
IT_1527x4f804            IT
IT_1527x5d4a0            IT
IT_1527x5e600            IT
IT_1527x6b9d0            IT
IT_1527x6dcf1            IT
IT_1527x7c720            IT
IT_1527x87b59            IT
IT_1527x9cbb9            IT
IT_1527xa46a4            IT
IT_1527xa54a9            IT
IT_1527xa9484            IT
IT_1527xbdbfe            IT
IT_1527xbffff            IT
IT_1527xdf5fe            IT
IT_1527xe87fb            IT
IT_1527xe8feb            IT
IT_1527xe8fec            IT
IT_1527xe8ff5            IT
IT_1527xe8ff8            IT
IT_1527xe8ffb            IT
IT_1527xe8ffd            IT
IT_1527xeec39            IT
IT_1527xeffff            IT
IT_1F11111111            IT
IT_F0000F000F            IT
IT_F111111111            IT
IT_FF000F000F            IT
IT_FF00F0000F            IT
IT_FF11111111            IT
IT_HE800_30581_12        IT
IT_HE800_30582_15        IT
IT_HE800_30583_14        IT
J_Decke                  IT
J_Leselicht              IT
J_Nachlicht              IT
J_Szenen                 LightScene
KUECHE_Decke             IT
KUECHE_Essbereich        IT
KUECHE_Schraenke         IT
KUECHE_Spuelmaschine     TASMOTA_DEVICE
KUECHE_Szenen            LightScene
Kodi_SZ                  KODI
Kodi_WZ                  KODI
LIGHT_Badezimmer_Wanne     HUEDevice
LIGHT_Kammerl            HUEDevice
LIGHT_Kueche_Essbereich     HUEDevice
LIGHT_Kueche_Tuer        HUEDevice
LIGHT_Toilette           HUEDevice
Logfile                  FileLog
P_All                    structure
P_Bad_All                structure
P_Bad_Tuer               dummy
P_Bad_Wanne              dummy
P_Kammerl_All            dummy
P_Kueche_All             structure
P_Kueche_Essbereich      dummy
P_Kueche_Tuer            dummy
P_Toilette_All           dummy
P_WIFI_All               structure
P_WIFI_Roswitha          PRESENCE
P_WIFI_Stefi             PRESENCE
P_WIFI_Tobias            PRESENCE
RoomCMD                  dummy
SVG_essbereich_light_log_1     SVG
SVG_spuele_log_1         SVG
SVG_trockner_log_1       SVG
SVG_waschmaschine_log_1     SVG
SZ_IndirekteBel          IT
SZ_Kasten                IT
SZ_NachtLichtStefi       HUEDevice
SZ_NachtLichtTobi        HUEDevice
SZ_Szene_Alle            LightScene
SZ_Szene_Stefi           LightScene
SZ_Szene_Tobi            LightScene
Switch_Arbeitsstation     UnifiSwitch
Switch_Schlafzimmer      UnifiSwitch
Switch_Wohnzimmer__150W_     UnifiSwitch
Switch_Wohnzimmer__PoE_passive_     UnifiSwitch
TEMP_Badezimmer          HUEDevice
TEMP_Kammerl             HUEDevice
TEMP_Kueche_Essbereich     HUEDevice
TEMP_Kueche_Tuer         HUEDevice
TEMP_Toilette            HUEDevice
Tageslicht               dummy
VR_Decke                 IT
VR_Klingel               dummy
WC_Decke                 IT
WC_Lueftung              IT
WEB                      FHEMWEB
WEB_192.168.0.1_63920     FHEMWEB
WEB_192.168.0.1_63929     FHEMWEB
WEB_192.168.0.1_63938     FHEMWEB
WEB_192.168.0.1_63939     FHEMWEB
WEBhabridge              FHEMWEB
WEBphone                 FHEMWEB
WEBtablet                FHEMWEB
WOL_SERVER               WOL
WOL_SZ_TV                WOL
WOL_WZ_NOTEBOOK          WOL
WOL_WZ_TV                WOL
WZ_Anybody_In            dummy
WZ_Decke                 IT
WZ_HUE_WohnwandOben      HUEDevice
WZ_KUCHE_Szenen          LightScene
WZ_KUECHE_Nachtlicht     dummy
WZ_Stehlampe             IT
WZ_Szenen                LightScene
WZ_Weih_Fenster          IT
WZ_WohnwandU             IT
WZ_unifi_controller      Unifi
act_AsyncCMD             notify
act_BAD_DeviceReady      notify
act_BM_Battery           notify
act_BM_Kammerl           notify
act_EchoVoice            notify
act_KUECHE_DeviceReady     notify
act_RoomCMD              notify
act_Tageslicht_WZ        notify
act_VR_Klingel           notify
act_off_PCs_SZ_OFF       notify
act_on_BM_Badezimmer     notify
act_on_BM_Kueche_Essbereich     notify
act_on_BM_Kueche_Tuer     notify
act_on_BM_Toilette       notify
act_on_FHEM_Initialized     notify
act_on_Master            notify
act_on_PCs_SZ_ON         notify
act_on_PCs_WZ_OFF        notify
act_on_PCs_WZ_ON         notify
act_on_P_Bad_All         notify
act_on_P_Kammerl_All     notify
act_on_P_Kueche_All      notify
act_on_Playstate_SZ      notify
act_on_Playstate_WZ      notify
act_sunset_WZ            notify
allowed_WEB              allowed
allowed_WEBphone         allowed
allowed_WEBtablet        allowed
allowed_telnetPort       allowed
at_Backup                at
autocreate               autocreate
essbereich_light_log     FileLog
eventTypes               eventTypes
fhemstart_fertig         notify
global                   Global
hueBridge1               HUEBridge
hueBridge1_HUEGroup5     HUEDevice
hueBridge1_HUEGroup6     HUEDevice
initialUsbCheck          notify
job_NachtAllesAus        at
job_NachtlichtReset      at
job_Tageslicht_sunrise     at
job_Tageslicht_sunset     at
job_Tageslicht_sunset_tl     at
kueche_spuele_log        FileLog
myBroker                 MQTT
myTL                     Twilight
pushmsg_all              PushNotifier
telnetForBlockingFn_1546486091     telnet
telnetPort               telnet
trockner_log             FileLog
waschmaschine_log        FileLog
watchdog_Kodi_SZ_paused     watchdog
watchdog_Kodi_SZ_stopped     watchdog
watchdog_Kodi_WZ_paused     watchdog
watchdog_Kodi_WZ_stopped     watchdog
watchdog_Niemand_Zuhause     watchdog
watchdog_Niemand_beim_Essbereich     watchdog
watchdog_Niemand_im_Bad_Tuer     watchdog
watchdog_Niemand_im_Bad_Wanne     watchdog
watchdog_Niemand_im_Kammerl     watchdog
watchdog_Niemand_im_Klo_Licht     watchdog
watchdog_Niemand_im_Klo_Lueftung     watchdog
watchdog_Niemand_in_Kueche     watchdog
watchdog_Spuelmaschine     watchdog
watchdog_Trockner        watchdog
watchdog_Waschmaschine     watchdog


apptime max
WEB_192.168.0.1_63939                    FW_Notify                              304       10     305.18    30.52     0.00     0.00 03.01. 04:31:35 HASH(WEB_192.168.0.1_63939); HASH(WOL_SERVER)
WEB                                      FW_Read                                 82       10     644.19    64.42     0.00     0.00 03.01. 04:31:34 HASH(WEB)
myBroker                                 MQTT::Read                              31        2      58.74    29.37     0.00     0.00 03.01. 04:31:38 HASH(myBroker)
KUECHE_Spuelmaschine                     TASMOTA::DEVICE::onmessage              17        2      30.18    15.09     0.00     0.00 03.01. 04:31:38 HASH(KUECHE_Spuelmaschine); /smarthome/ku/spuele/tele/SENSOR; {"Time":"2019-01-03T04:31:38","ENERGY":{"TotalStartTime":"2018-12-04T21:18:17","Total":17.079,"Yesterday":1.390,"Today":0.000,"Period":0,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":239,"Current":0.000}}
tmr-WOL_UpdateReadings                   HASH(0x2c6a908)                         14        1      14.16    14.16     2.12     2.12 03.01. 04:31:41 HASH(WOL_SZ_TV_ping)
tmr-PRESENCE_StartLocalScan              HASH(0x1c88e78)                         13        1      13.81    13.81     3.01     3.01 03.01. 04:31:46 HASH(P_WIFI_Tobias)
tmr-WOL_UpdateReadings                   HASH(0x2c8cc88)                         13        1      13.35    13.35     1.79     1.79 03.01. 04:31:53 HASH(WOL_SZ_TV_ping)
tmr-WOL_UpdateReadings                   HASH(0x2bb8888)                         11        1      11.62    11.62    15.51    15.51 03.01. 04:31:34 HASH(WOL_SERVER_ping)
tmr-WOL_UpdateReadings                   HASH(0x2c87ff0)                         10        1      10.83    10.83     0.95     0.95 03.01. 04:31:54 HASH(WOL_WZ_TV_ping)
tmr-WOL_UpdateReadings                   HASH(0x2abed68)                         10        1      10.82    10.82     1.02     1.02 03.01. 04:31:42 HASH(WOL_WZ_TV_ping)
tmr-PRESENCE_StartLocalScan              HASH(0x1d5b2e8)                         10        1      10.61    10.61     0.97     0.97 03.01. 04:31:46 HASH(P_WIFI_Stefi)
tmr-WOL_UpdateReadings                   HASH(0x29d8d38)                         10        1      10.57    10.57     1.15     1.15 03.01. 04:31:38 HASH(WOL_WZ_NOTEBOOK_ping)
tmr-PRESENCE_StartLocalScan              HASH(0x1e52df8)                         10        1      10.55    10.55     1.04     1.04 03.01. 04:31:46 HASH(P_WIFI_Roswitha)
tmr-WOL_UpdateReadings                   HASH(0x2c87738)                         10        1      10.17    10.17     1.33     1.33 03.01. 04:31:48 HASH(WOL_WZ_NOTEBOOK_ping)
WEB_192.168.0.1_63938                    FW_Read                                 10        9      41.05     4.56     0.00     0.00 03.01. 04:31:34 HASH(WEB_192.168.0.1_63938)
act_BM_Battery                           notify_Exec                              9       10      17.48     1.75     0.00     0.00 03.01. 04:31:49 HASH(act_BM_Battery); HASH(WZ_unifi_controller)
act_on_Playstate_WZ                      notify_Exec                              9       10      14.93     1.49     0.00     0.00 03.01. 04:31:49 HASH(act_on_Playstate_WZ); HASH(WZ_unifi_controller)
act_on_Playstate_SZ                      notify_Exec                              9       10      15.06     1.51     0.00     0.00 03.01. 04:31:49 HASH(act_on_Playstate_SZ); HASH(WZ_unifi_controller)
essbereich_light_log                     FileLog_Log                              6       10      13.13     1.31     0.00     0.00 03.01. 04:31:49 HASH(essbereich_light_log); HASH(WZ_unifi_controller)
Logfile                                  FileLog_Log                              5       10      10.93     1.09     0.00     0.00 03.01. 04:31:49 HASH(Logfile); HASH(WZ_unifi_controller)
tmr-HUEDevice_GetUpdate                  HASH(0x286c4f0)                          5       21      63.35     3.02    49.82     5.29 03.01. 04:31:46 HASH(DIM_VR_Master_Dimmer)
WEB_192.168.0.1_64029                    FW_Read                                  5        2       5.72     2.86     0.00     0.00 03.01. 04:31:34 HASH(WEB_192.168.0.1_64029)
tmr-HUEDevice_GetUpdate                  HASH(0x2823080)                          5       21      72.22     3.44    57.22     4.33 03.01. 04:31:53 HASH(BM_Badezimmer_Wanne)
telnetForBlockingFn_1546486091           telnet_Read                              4       10      30.57     3.06     0.00     0.00 03.01. 04:31:41 HASH(telnetForBlockingFn_1546486091)
tmr-HUEDevice_GetUpdate                  HASH(0x28239f8)                          3       21      61.73     2.94    56.03     4.68 03.01. 04:31:54 HASH(BM_Kueche_Essbereich)
tmr-HUEDevice_GetUpdate                  HASH(0x22863b0)                          3       21      60.49     2.88    41.71     5.48 03.01. 04:31:54 HASH(BM_Badezimmer_Tuer)
tmr-HUEDevice_GetUpdate                  HASH(0x2858988)                          3       21      60.91     2.90    53.31     4.77 03.01. 04:31:41 HASH(BM_Kueche_Tuer)
tmr-HUEDevice_GetUpdate                  HASH(0x22c93a0)                          3       21      60.35     2.87    38.07     5.90 03.01. 04:31:41 HASH(BM_Kammerl)
watchdog_Kodi_SZ_paused                  watchdog_Notify                          3       10       7.80     0.78     0.00     0.00 03.01. 04:31:49 HASH(watchdog_Kodi_SZ_paused); HASH(WZ_unifi_controller)
watchdog_Kodi_WZ_paused                  watchdog_Notify                          3       10       7.30     0.73     0.00     0.00 03.01. 04:31:49 HASH(watchdog_Kodi_WZ_paused); HASH(WZ_unifi_controller)
watchdog_Kodi_SZ_stopped                 watchdog_Notify                          3       10       7.31     0.73     0.00     0.00 03.01. 04:31:49 HASH(watchdog_Kodi_SZ_stopped); HASH(WZ_unifi_controller)
act_KUECHE_DeviceReady                   notify_Exec                              3        4       4.38     1.10     0.00     0.00 03.01. 04:31:38 HASH(act_KUECHE_DeviceReady); HASH(KUECHE_Spuelmaschine)
watchdog_Kodi_WZ_stopped                 watchdog_Notify                          3       10       7.25     0.73     0.00     0.00 03.01. 04:31:49 HASH(watchdog_Kodi_WZ_stopped); HASH(WZ_unifi_controller)
tmr-HUEDevice_GetUpdate                  HASH(0x2269778)                          3       21      60.68     2.89    45.63     5.52 03.01. 04:31:37 HASH(BM_Toilette)
eventTypes                               eventTypes_Notify                        3       10      10.37     1.04     0.00     0.00 03.01. 04:31:49 HASH(eventTypes); HASH(Switch_Wohnzimmer__150W_)
WEB_192.168.0.1_64028                    FW_Read                                  2        2       5.16     2.58     0.00     0.00 03.01. 04:31:34 HASH(WEB_192.168.0.1_64028)
telnetForBlockingFn_1546486091_127.0.0.1_38694 telnet_Read                              2        1       2.18     2.18     0.00     0.00 03.01. 04:31:53 HASH(telnetForBlockingFn_1546486091_127.0.0.1_38694)
A_Szenen                                 LightScene_Notify                        2       10       3.48     0.35     0.00     0.00 03.01. 04:31:49 HASH(A_Szenen); HASH(WZ_unifi_controller)
J_Szenen                                 LightScene_Notify                        1       10       3.20     0.32     0.00     0.00 03.01. 04:31:49 HASH(J_Szenen); HASH(WZ_unifi_controller)
SZ_Szene_Alle                            LightScene_Notify                        1       10       3.07     0.31     0.00     0.00 03.01. 04:31:49 HASH(SZ_Szene_Alle); HASH(WZ_unifi_controller)
WZ_Szenen                                LightScene_Notify                        1       10       3.03     0.30     0.00     0.00 03.01. 04:31:49 HASH(WZ_Szenen); HASH(WZ_unifi_controller)



Für mich schaut komisch aus 2x structs einen count von über 300000 haben.
Ja, ich hatte anscheinen apptime vorher laufen, beim Problemfall und eingabe von "apptime" bekam ich nicht "apptime initialized" sondern gleich die AUsgabe.
Bitte um Hilfe, da sich bei mir Szenen in der Nacht schalten durch das Problem!

Hier das Log:


2019.01.03 03:30:06 1: act_off_PCs_SZ_OFF: Szene Aus aktivieren, es ist Schlafenszeit!
2019.01.03 03:30:17 1: act_on_PCs_SZ_ON: run! Tageslicht: dunkel
2019.01.03 03:30:17 1: act_on_PCs_SZ_ON: Szene Nacht aktivieren, es ist dunkel!
2019.01.03 03:30:18 1: Cannot fork: Cannot allocate memory
2019.01.03 03:30:18 1: Cannot fork: Cannot allocate memory
2019.01.03 03:30:18 1: act_on_PCs_WZ_OFF: run! Tageslicht: dunkel
2019.01.03 03:30:18 1: act_on_PCs_WZ_OFF: Szene Schlafen Gehen aktivieren, es ist dunkel!
2019.01.03 03:30:29 1: act_off_PCs_SZ_OFF: Szene Aus aktivieren, es ist Schlafenszeit!
2019.01.03 03:30:42 1: Cannot fork: Cannot allocate memory
2019.01.03 03:30:42 1: Cannot fork: Cannot allocate memory
2019.01.03 03:31:19 1: Cannot fork: Cannot allocate memory
2019.01.03 03:31:19 1: Cannot fork: Cannot allocate memory
2019.01.03 03:31:19 1: act_on_PCs_WZ_ON: run! Tageslicht: dunkel
2019.01.03 03:31:19 1: act_on_PCs_WZ_ON: Szene FernsehLicht aktivieren, es ist dunkel!
2019.01.03 03:31:41 1: act_on_PCs_SZ_ON: run! Tageslicht: dunkel
2019.01.03 03:31:41 1: act_on_PCs_SZ_ON: Szene Nacht aktivieren, es ist dunkel!
2019.01.03 03:31:42 1: act_on_PCs_WZ_OFF: run! Tageslicht: dunkel
2019.01.03 03:31:42 1: act_on_PCs_WZ_OFF: Szene Schlafen Gehen aktivieren, es ist dunkel!
2019.01.03 03:31:54 1: act_on_PCs_WZ_ON: run! Tageslicht: dunkel
2019.01.03 03:31:54 1: act_on_PCs_WZ_ON: Szene FernsehLicht aktivieren, es ist dunkel!
2019.01.03 03:31:55 1: act_off_PCs_SZ_OFF: Szene Aus aktivieren, es ist Schlafenszeit!
2019.01.03 03:32:05 1: act_on_PCs_SZ_ON: run! Tageslicht: dunkel
2019.01.03 03:32:05 1: act_on_PCs_SZ_ON: Szene Nacht aktivieren, es ist dunkel!
2019.01.03 03:32:07 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:07 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:07 1: act_on_PCs_WZ_OFF: run! Tageslicht: dunkel
2019.01.03 03:32:07 1: act_on_PCs_WZ_OFF: Szene Schlafen Gehen aktivieren, es ist dunkel!
2019.01.03 03:32:18 1: act_off_PCs_SZ_OFF: Szene Aus aktivieren, es ist Schlafenszeit!
2019.01.03 03:32:19 1: act_on_PCs_WZ_ON: run! Tageslicht: dunkel
2019.01.03 03:32:19 1: act_on_PCs_WZ_ON: Szene FernsehLicht aktivieren, es ist dunkel!
2019.01.03 03:32:25 1: act_on_PCs_WZ_ON: run! Tageslicht: dunkel
2019.01.03 03:32:25 1: act_on_PCs_WZ_ON: Szene FernsehLicht aktivieren, es ist dunkel!
2019.01.03 03:32:29 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:29 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:29 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:29 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:30 1: act_on_PCs_SZ_ON: run! Tageslicht: dunkel
2019.01.03 03:32:30 1: act_on_PCs_SZ_ON: Szene Nacht aktivieren, es ist dunkel!
2019.01.03 03:32:41 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:41 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:41 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:41 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:56 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:56 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:56 1: Cannot fork: Cannot allocate memory
2019.01.03 03:32:56 1: Cannot fork: Cannot allocate memory
2019.01.03 03:33:32 1: Cannot fork: Cannot allocate memory
2019.01.03 03:33:32 1: Cannot fork: Cannot allocate memory
2019.01.03 03:33:32 1: Cannot fork: Cannot allocate memory


Danke
pOpY
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 03 Januar 2019, 08:28:37
Zitat von: iice64 am 29 Dezember 2018, 08:57:54
Super Beitrag!!!

Bei mir haben die Einträge nur funktioniert, wenn man in der /etc/init.d/fhem
#!/bin/sh durch #!/bin/bash ersetzt.

Anschließend
systemctl daemon-reload
systemctl restart fhem
systemctl status  fhem

Wie man im Bild sieht ist der Speicherverbrauch mit perl-5.20.3 konstant ab 29. Dec
Bei mir begann das Drama am 27. Dec mit der Umstellung auf stretch und perl-5.24.1
Wie bekommst du das RAM Diagram in fhem, möcht ich mir auch zur Analyse einbauen.

Danke

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 03 Januar 2019, 08:34:34
defmod sysmon SYSMON 1
attr sysmon event-min-interval cpu_temp:600,cpu_temp_avg:600,cpu_freq:600,cpu_freq_stat:600,ram:600,eth0_diff:600,fs_root.*:600
attr sysmon event-on-change-reading cpu_temp,cpu_temp_avg,cpu_freq,cpu_freq_stat,ram,eth0_diff,fs_root.*
attr sysmon event-on-update-reading cpu_temp,cpu_temp_avg,cpu_freq,cpu_freq_stat,ram,eth0_diff,fs_root.*
attr sysmon filesystems fs_boot:/boot:Boot,fs_root:/:Root
attr sysmon network-interfaces eth0:eth0:Ethernet
attr sysmon room System

defmod Sysmon.filelog FileLog ./log/sysmon-%Y-%W.log sysmon
attr Sysmon.filelog icon edit_settings
attr Sysmon.filelog nrarchive 4
attr Sysmon.filelog room Log

defmod Sysmon_RAM.svg SVG Sysmon.filelog:SM_RAM:CURRENT
attr Sysmon_RAM.svg label "RAM - Gesamt: $data{max1}, Min: $data{min2}, Max: $data{max2}, Aktuell: $data{currval2}"
attr Sysmon_RAM.svg room System

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 03 Januar 2019, 11:38:27
Zitat von: iice64 am 03 Januar 2019, 08:34:34
defmod sysmon SYSMON 1
attr sysmon event-min-interval cpu_temp:600,cpu_temp_avg:600,cpu_freq:600,cpu_freq_stat:600,ram:600,eth0_diff:600,fs_root.*:600
attr sysmon event-on-change-reading cpu_temp,cpu_temp_avg,cpu_freq,cpu_freq_stat,ram,eth0_diff,fs_root.*
attr sysmon event-on-update-reading cpu_temp,cpu_temp_avg,cpu_freq,cpu_freq_stat,ram,eth0_diff,fs_root.*
attr sysmon filesystems fs_boot:/boot:Boot,fs_root:/:Root
attr sysmon network-interfaces eth0:eth0:Ethernet
attr sysmon room System

defmod Sysmon.filelog FileLog ./log/sysmon-%Y-%W.log sysmon
attr Sysmon.filelog icon edit_settings
attr Sysmon.filelog nrarchive 4
attr Sysmon.filelog room Log

defmod Sysmon_RAM.svg SVG Sysmon.filelog:SM_RAM:CURRENT
attr Sysmon_RAM.svg label "RAM - Gesamt: $data{max1}, Min: $data{min2}, Max: $data{max2}, Aktuell: $data{currval2}"
attr Sysmon_RAM.svg room System



Danke Vielmals, jetzt monitore ich auch meinen RAM und schau mal wie der Anstieg ist.

Hier noch der memusage nach ~07h, mit ps sehe ich dass der Prozess auf 10% angewachsen ist.

fhemdebug memusage 03.01.2019 12:06:
Nach uptime: 07:27:33

   1. defs                            1840578
   2. modules                          614767
   3. defs::WZ_unifi_controller        569051
   4. modules::eventTypes              370353
   5. modules::eventTypes::ldata       369291
   6. defs::WZ_unifi_controller::READINGS   302340
   7. attr                             156017
   8. defs::WZ_unifi_controller::clients   133130
   9. defs::WZ_unifi_controller::accespoints   118054
  10. defs::BAD_Waschmaschine           62574
  11. defs::BAD_Trockner                62375
  12. defs::KUECHE_Spuelmaschine        58383
  13. defs::BAD_Waschmaschine::READINGS    56670
  14. defs::BAD_Trockner::READINGS      56636
  15. defs::KUECHE_Spuelmaschine::READINGS    52709
  16. defs::sysmon                      47260
  17. defs::Alexas                      46511
  18. defs::Switch_Wohnzimmer__150W_    42491
  19. POSIX::                           37247
  20. defs::myTL                        35354
  21. defs::Alexas::helper              34063
  22. defs::sysmon::READINGS            30093
  23. defs::Switch_Arbeitsstation       29787
  24. defs::ECHO_Kueche                 27335
  25. defs::ECHO_Wohnzimmer             24296
  26. defs::ECHO_Badezimmer             24294
  27. defs::Switch_Schlafzimmer         24212
  28. defs::Switch_Wohnzimmer__PoE_passive_    24137
  29. defs::ECHO_Julians_Zimmer         24135
  30. defs::Switch_Wohnzimmer__150W_::READINGS    23770
  31. defs::ECHO_Schlafzimmer           22688
  32. defs::WZ_unifi_controller::accespoints::5b4ccd9c93c42315e05aaf31    22635
  33. defs::WZ_unifi_controller::accespoints::5b4cc95a93c42315e05aac50    22523
  34. defs::Kodi_SZ                     22225
  35. defs::Kodi_SZ::READINGS           20911
  36. modules::eventTypes::ldata::ECHO_Julians_Zimmer    20353
  37. modules::eventTypes::ldata::ECHO_Kueche    20034
  38. modules::eventTypes::ldata::ECHO_Badezimmer    19866
  39. modules::eventTypes::ldata::ECHO_Wohnzimmer    19531
  40. modules::eventTypes::ldata::WZ_unifi_controller    19046
  41. modules::eventTypes::ldata::Kodi_SZ    18967
  42. modules::eventTypes::ldata::Kodi_WZ    18847
  43. modules::IT                       18487
  44. defs::ECHO_Kueche::READINGS       18438
  45. modules::eventTypes::ldata::BAD_Waschmaschine    18309
  46. modules::eventTypes::ldata::BAD_Trockner    18222
  47. modules::eventTypes::ldata::KUECHE_Spuelmaschine    18155
  48. defs::Kodi_WZ                     17708
  49. modules::eventTypes::ldata::CUL433    17431
  50. defs::Switch_Wohnzimmer__150W_::usw    17121


Kann mir Bitte jemand helfen das obige zu deuten?

Hier meine Fragen:
Würdet ihr den Umstieg auf die ältere Perl Version Vorsorglich empfehlen oder sollte ich anschauen was RAM Verbraucht?
Ist "apptime" ein Potentieller SPeicher fresser wenn ich nachher kein shutdown restart mache?

Danke
pOpY


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 03 Januar 2019, 13:44:05
Bei mir liegt es eindeutig an der perl version 5.24.1  :'(
Nachdem ich mit perlbrew zur alten version 5.20.3 zurück gegangen bin, läuft der Speicher nicht mehr voll.  :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 03 Januar 2019, 13:48:09
Zitat von: iice64 am 03 Januar 2019, 13:44:05
Bei mir liegt es eindeutig an der perl version 5.24.1  :'(
Nachdem ich mit perlbrew zur alten version 5.20.3 zurück gegangen bin, läuft der Speicher nicht mehr voll.  :)
Ok danke, ich glaube ich mache das auch.
Möchte zuerst noch ein Diagram sehen wo er vollläuft und dann werde ich zurüchsteigen.

Wie schaut es eigentlich bei einem apt-get update aus? Bleibt da die perlbrew version installiert und aktiviert?

pOpY

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 03 Januar 2019, 13:57:53
Mit diesem Script kann mann sich eine fertig kompilierte für den Raspberry Pi (armv7l-linux) perl-5.20.3 und perlbrew installieren.
https://www.dropbox.com/s/926car881dvhrau/install-perlbrew-from-tar.sh?dl=1  (https://www.dropbox.com/s/926car881dvhrau/install-perlbrew-from-tar.sh?dl=1)
(wie immer ohne Gewähr)

Dann noch /etc/init.d/fhem anpassen. Änderungen sind fett.

#!/bin/bash
# description: Start or stop the fhem server
# Added by Alex Peuchert

### BEGIN INIT INFO
# Provides:             fhem.pl
# Required-Start:       $local_fs $remote_fs
# Required-Stop:        $local_fs $remote_fs
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    FHEM server
### END INIT INFO

export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3

set -e
cd /opt/fhem
port=7072


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 03 Januar 2019, 14:52:30
Zitat von: popy am 03 Januar 2019, 13:48:09
Wie schaut es eigentlich bei einem apt-get update aus? Bleibt da die perlbrew version installiert und aktiviert?
Ja, denn die perl-5.20.3 ist zusätzlich zum system perl installiert.
Solange perlbrew use perl-5.20.3 in der /etc/init.d/fhem drin ist.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 03 Januar 2019, 15:18:47
Zitat von: iice64 am 03 Januar 2019, 14:52:30
Ja, denn die perl-5.20.3 ist zusätzlich zum system perl installiert.
Solange perlbrew use perl-5.20.3 in der /etc/init.d/fhem drin ist.

Danke für die ganzen Infos.
Habe das jetzt beobachtet und 3x den Speicherverbrauch angesehen, mit folgendem Ergebnis:


03.01.2019 04:41: fhem     27616 21.5  5.2  55184 49932 ?        R    04:40   0:14 /usr/bin/perl fhem.pl fhem.cfg
03.01.2019 11:52: fhem     27616 14.6 10.7 107928 101972 ?       S    04:40  63:20 /usr/bin/perl fhem.pl fhem.cfg
03.01.2019 14:42: fhem     27616 15.3 12.2 122124 116136 ?       S    04:40  92:17 /usr/bin/perl fhem.pl fhem.cfg


Das wäre ein Anstieg von:


0,71% / h = 6,86 MB / h


Sprich, in etwas mehr als 3 Tagen wäre der RAM wieder voll. Ich bin mir jetzt nicht sicher ob ich gleich das ältere Perl installieren soll.
Oder ich noch andere Analysen machen kann (ev. welches Modul sich den Speicher gönnt).
Mit "fhemdebug memusage" haben sich werte jetzt in ~3h wie folgt verändert:


   1. defs                            1840578 -> 1855907
   2. modules                          614767 -> 614831
   3. defs::WZ_unifi_controller        569051 -> 573265


Ich vermute es sind bytes (da, wenn kB der PI nicht so viel RAM hat) wären das ja "nur" 15329 bytes in 3h (bei den defs, die anderen sind vernachlässigbar).
Das ist weit weg von den 6,86 MB / h die der fhem Prozess sich gönnt (mit ps -aux).

Hast du noch Ideen wo ich noch schauen kann was den Speicher verbrät?
Wie ist der Speicherverbrauch mit ps -aux bei dir nach ein paar Stunden Laufzeit?

Danke Vielmals für Deine Unterstützung
pOpY


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 03 Januar 2019, 15:33:54
Zitat von: popy am 03 Januar 2019, 15:18:47
Sprich, in etwas mehr als 3 Tagen wäre der RAM wieder voll. Ich bin mir jetzt nicht sicher ob ich gleich das ältere Perl installieren soll.
Da wie ich vermute, perl-5.24.1 das Speicherleck produziert. Kannst du im fhem nichts feststellen.
Man erkennt es nur am perl Prozess, der sich immer mehr Speicher greift.

Ich würde dir zur perl-5.20.3 raten.

Oder man muss auf das CANNOT_FORK reagieren und fhem neu starten.
Finde ich persönlich unsauber, man weiß ja nie, wann es passiert und welches Ereignis nicht bearbeitet wurde.

defmod cannot_fork.restart.notify notify global:CANNOT_FORK shutdown restart
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 03 Januar 2019, 15:55:46
ZitatOder ich noch andere Analysen machen kann (ev. welches Modul sich den Speicher gönnt).
Die Ursache rauszufinden waere schon sinnvoll, und ein Modul zu indentifizieren der erste Schritt.
Es sei denn, irgendwer prueft 5.26, das Problem gibt es da nicht mehr, und wir sind den Spuk demnaechst automatisch los.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 03 Januar 2019, 16:07:31
Zitat von: rudolfkoenig am 03 Januar 2019, 15:55:46
Die Ursache rauszufinden waere schon sinnvoll, und ein Modul zu indentifizieren der erste Schritt.
Es sei denn, irgendwer prueft 5.26, das Problem gibt es da nicht mehr, und wir sind den Spuk demnaechst automatisch los.

5.26 wurde schon getestet unter Ubuntu, leider ohne Erfolg, Siehe Post: https://forum.fhem.de/index.php/topic,84372.msg846849.html#msg846849
Wenn du mir sagst wie ich draufkomme welches Modul sich den Speicher gönnt kann ich Gerne schauen.
Bei mir gönnt sich perl mit fhem.pl ~7MB RAM pro Stunde.

Das Problem ist dass dies mein (einziges) Produktiv System ist.
Der WAF ist auch schon im Keller  ;) wenn mitten in der Nacht irgendwelche Sachen von selbst schalten weil der RAM aus ist (Notifys sind angesprungen da keine Presence Forks (pings) mehr erstellt werden konnten). Deshalb tendiere ich eher zum alten perl als schnelle Abhilfe.

Bis 18:00 hätte ich noch Zeit  :P was zu analysieren.

Eine Sache noch: ich habe 2x structs (Siehe erste Posts) die über 300000 in count bei apptime aufscheinen.
Könnte es damit zusammenhängen?
In jeder Struct sind 2x dummys mit gesetztem "event-on.change-reading state", verstehe auch nicht warum, hier die Zeilen von apptime:

    name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
    P_Kueche_All                             structure_Notify                      1167   377045   64699.52     0.17     0.00     0.00 02.01. 20:33:46 HASH(P_Kueche_All); HASH(P_Kueche_Tuer)
    P_Bad_All                                structure_Notify                       515   377045   43336.09     0.11     0.00     0.00 02.01. 18:23:37 HASH(P_Bad_All); HASH(P_Bad_Tuer)


pOpY
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: kadettilac89 am 03 Januar 2019, 16:41:14
Zitat von: popy am 03 Januar 2019, 16:07:31
Eine Sache noch: ich habe 2x structs (Siehe erste Posts) die über 300000 in count bei apptime aufscheinen.
Könnte es damit zusammenhängen?

Ja, bei mir hat Modul apptime den Ram verschlungen. War bei dir apptime immer aktiv?

Deaktiviere mal apptime und schau ob Ram noch zunimmt. Ohne aktivem apptime ist mein Ram mehr oder weniger stabil. Mit version 5.24.1.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 03 Januar 2019, 17:24:26
Zitat von: kadettilac89 am 03 Januar 2019, 16:41:14
Ja, bei mir hat Modul apptime den Ram verschlungen. War bei dir apptime immer aktiv?

Deaktiviere mal apptime und schau ob Ram noch zunimmt. Ohne aktivem apptime ist mein Ram mehr oder weniger stabil. Mit version 5.24.1.

Ja, in dem Fall war apptime aktiv (hatte vergessen shutdown restart zu machen).
Das wusste ich deshalb da bei erster eingabe von "apptime max" im Fehlerfall ich sofort die Ausgabe bekam und nicht "apptime initialized".
Jetzt teste ich aber ohne apptime und der RAM von fhem steigt, derzeit soviel (mit ps -aux):


Nach 12:40:34 uptime:
0,63% / h
6,1 MB / h


Wieviel ist dass jetzt bei Dir mit 5.24.1.?

Danke
pOpY

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: kadettilac89 am 03 Januar 2019, 17:36:29
Zitat von: popy am 03 Januar 2019, 17:24:26
Ja, in dem Fall war apptime aktiv (hatte vergessen shutdown restart zu machen).
Das wusste ich deshalb da bei erster eingabe von "apptime max" im Fehlerfall ich sofort die Ausgabe bekam und nicht "apptime initialized".
Jetzt teste ich aber ohne apptime und der RAM von fhem steigt, derzeit soviel (mit ps -aux):


Nach 12:40:34 uptime:
0,63% / h
6,1 MB / h


Wieviel ist dass jetzt bei Dir?

Danke
pOpY


USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
fhem     28235  0.7  8.1  96080 62556 ?        S     2018  35:36 /usr/bin/perl fhem.pl fhem.cfg
fhem     28313  0.0  2.6  74240 20472 ?        S     2018   0:29 /usr/bin/perl fhem.pl fhem.cfg



FHEM up time: 3 days, 05 hours, 36 minutes
System up time: 8 days, 23 hours, 56 minutes


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 03 Januar 2019, 19:09:45
Nach meinen Untersuchungen führen bestimmte, häufige Regex-Abfragen in Perl 5.24 zu memory leak. Diese Perl-Version macht am meisten Probleme.

Mit Active Perl 5.26 war das Problem bei mir nicht mehr aufgetreten.


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 03 Januar 2019, 20:15:17
Danke euch allen, werde das RAM Log jetzt bis morgen laufen lassen und dann die Auslastung beurteilen.
Melde mich mit dem Graphen zurück.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 03 Januar 2019, 20:26:55
ZitatWenn du mir sagst wie ich draufkomme welches Modul sich den Speicher gönnt kann ich Gerne schauen.
Ein Modul nach dem Anderen abschalten, und dazwischen pruefen, ob das Problem noch besteht.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: yamaha1983 am 04 Januar 2019, 07:29:59
Die Mühe mit den Modulen abschalten hatte ich mir schon gemacht, bevor ich die Anleitung mit Perlbrew hier einstellt hab. Aber ich konnte kein spezifisches Modul feststellen. Auch Apptime abschalten hatte bei mir nichts gebracht.

Der Zusammenhang mit regex kann stimmen. Diese nutze ich exzessiv :).

Wenn jemand die Muße hat, kann er auch mal ein aktuelles Perl (perl-5.29.6) kompilieren und probieren. Vielleicht ist das Problem wirklich schon behoben.

Grüße

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 04 Januar 2019, 08:15:20
https://stackoverflow.com/questions/43288921/perl-program-leaking-memory-when-compiling-regex

https://rt.perl.org/Public/Bug/Display.html?id=130254
Hier dürfte der letzte Eintrag entscheidend sein

http://code.activestate.com/lists/perl5-porters/234233/

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gandi1791 am 04 Januar 2019, 09:07:59
Zitat von: binford6000 am 01 April 2018, 14:50:33
Hier auch! Ich hatte vorher freezemon nur mit "set inactive" bzw. "disable 1" stillgelegt. Jetzt komplett gelöscht und fhem-Neustart durchgeführt.
VG Sebastian

zuerst:
Grundsätzlich selbiges Phänomen: RAM läuft innerhalb weniger Stunden voll > Cannot allocate memory
Dann diesen Beitrag bis zu dem quote oben gelesen.
Festgestellt, dass ich Freezemon auch nur auf disable=1 gesetzt habe (im Nachhinein fällt mir auf, dass etwa zu der Zeit das Problem begann).
Nun Freezemon gestern Abend komplett gelöscht, fhem neustart, Ergebnis: Das Problem ist weg!  ;D (siehe RAM Verlauf im Anhang)
(Apptime hatte ich nicht aktiv)

Noch ein paar Hintergrunddaten, falls es noch nützlich sein sollte (habe den Thread hier leider - noch - nicht bis zum Schluss gelesen):
RaspberryPi 3b
Stretch 9.6
Perl Version: v5.24.1

Verison:

Latest Revision: 18080

File                   Rev   Last Change

fhem.pl                18029 2018-12-22 19:22:09Z rudolfkoenig
57_ABFALL.pm           11023 2018-06-13 12:34:34Z uniqueck
39_alexa.pm            16299 2018-03-01 08:06:55Z justme1968
60_allergy.pm          16669 2018-04-28 21:42:29Z moises
96_allowed.pm          17613 2018-10-24 15:37:39Z rudolfkoenig
90_at.pm               17561 2018-10-18 14:45:30Z rudolfkoenig
98_autocreate.pm       17993 2018-12-17 14:29:00Z rudolfkoenig
38_Broadlink.pm        15578 2017-12-09 11:44:57Z daniel2311
57_Calendar.pm         17531 2018-10-14 16:19:52Z neubert
57_CALVIEW.pm          17605 2018-10-23 16:37:40Z chris1284
00_CUL.pm              17559 2018-10-18 07:45:07Z rudolfkoenig
14_CUL_MAX.pm          12440 2016-10-26 20:24:45Z mgehre
14_CUL_TCM97001.pm     16274 2018-02-25 20:42:39Z bjoernh
93_DbLog.pm            17772 2018-11-18 07:42:15Z DS_Starter
98_DOIF.pm             18023 2018-12-21 15:07:36Z Damian
98_dummy.pm            16965 2018-07-09 07:59:58Z rudolfkoenig
37_echodevice.pm       15724 2017-12-29 22:59:44Z michael.winkler
91_eventTypes.pm       14888 2017-08-13 12:07:12Z rudolfkoenig
98_expandJSON.pm       17324 2018-09-11 06:48:31Z dev0
72_FB_CALLLIST.pm      17968 2018-12-13 12:23:17Z markusbloch
72_FB_CALLMONITOR.pm   17966 2018-12-13 10:52:26Z markusbloch
01_FHEMWEB.pm          18065 2018-12-27 10:12:16Z rudolfkoenig
92_FileLog.pm          17181 2018-08-20 17:23:26Z rudolfkoenig
72_FRITZBOX.pm         17437 2018-09-30 18:24:58Z tupol
98_Heating_Control.pm  16005 2018-01-27 06:05:51Z igami
98_HTTPMOD.pm          17736 2018-11-12 19:42:35Z StefanStrobel
02_HTTPSRV.pm          16874 2018-06-15 17:18:55Z neubert
30_HUEBridge.pm        17986 2018-12-16 14:20:19Z justme1968
31_HUEDevice.pm        18025 2018-12-21 19:19:55Z justme1968
10_IT.pm               17540 2018-10-15 19:00:42Z bjoernh
98_JsonList2.pm        17230 2018-08-30 13:03:48Z rudolfkoenig
10_MAX.pm              16847 2018-06-10 18:42:19Z rudolfkoenig
00_MQTT.pm             17362 2018-09-17 12:57:29Z hexenmeister
10_MQTT_DEVICE.pm      17362 2018-09-17 12:57:29Z hexenmeister
00_MYSENSORS.pm        17290 2018-09-06 08:29:45Z Hauswart
10_MYSENSORS_DEVICE.pm 17611 2018-10-24 10:56:06Z Hauswart
91_notify.pm           17225 2018-08-29 12:34:29Z rudolfkoenig
33_readingsGroup.pm    16299 2018-03-01 08:06:55Z justme1968
95_remotecontrol.pm    10724 2016-02-04 18:17:33Z ulimaass
14_SD_RSL.pm            7779 2017-11-14 18:00:00Z v3.3.1-dev
00_SIGNALduino.pm      10488 2018-12-19 12:00:00Z v3.3.3-dev
70_STV.pm              12857 2016-12-21 11:59:33Z Zwiebel
99_SUNRISE_EL.pm       16632 2018-04-17 19:00:21Z rudolfkoenig
98_SVG.pm              17779 2018-11-18 17:49:14Z rudolfkoenig
42_SYSMON.pm           17227 2018-08-29 19:58:18Z hexenmeister
50_TelegramBot.pm      16382 2018-03-11 13:20:55Z viegener
98_telnet.pm           17529 2018-10-14 12:57:06Z rudolfkoenig
98_THRESHOLD.pm        14179 2017-05-03 20:10:16Z Damian
59_Twilight.pm         16005 2018-01-27 06:05:51Z igami
99_Utils.pm            15713 2017-12-28 11:01:02Z rudolfkoenig
77_UWZ.pm              17646 2018-10-30 11:20:16Z CoolTux
98_version.pm          15140 2017-09-26 09:20:09Z markusbloch
91_watchdog.pm         16963 2018-07-09 07:40:22Z rudolfkoenig
59_Weather.pm          16644 2018-04-22 08:07:35Z neubert
98_weblink.pm          16293 2018-02-28 21:33:57Z rudolfkoenig
98_WeekdayTimer.pm     16005 2018-01-27 06:05:51Z igami

ABFALL_getEvents.pm    11023 2018-06-13 12:34:34Z uniqueck
ABFALL_setUpdate.pm    11021 2017-09-13 00:32:22Z uniqueck
AttrTemplate.pm        17973 2018-12-14 18:19:05Z rudolfkoenig
Blocking.pm            17553 2018-10-17 15:56:35Z rudolfkoenig
Color.pm               11159 2016-03-30 16:08:06Z justme1968
No Id found for Constants.pm
DevIo.pm               17994 2018-12-17 14:32:10Z rudolfkoenig
FritzBoxUtils.pm       16691 2018-05-05 17:11:26Z rudolfkoenig
GPUtils.pm              6653 2014-10-02 11:59:37Z ntruchsess
HttpUtils.pm           17831 2018-11-24 15:09:17Z rudolfkoenig
Info.pm                   28 2008-11-09 01:08:44Z dsully
No Id found for MaxCommon.pm
No Id found for Message.pm
myUtilsTemplate.pm      7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm              10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm       18040 2018-12-23 17:31:10Z rudolfkoenig
TcpServerUtils.pm      17529 2018-10-14 12:57:06Z rudolfkoenig
YahooWeatherAPI.pm     16641 2018-04-21 12:28:38Z neubert


Falls jemand (Rudi & Co) noch weitere Infos benötigt, sofern es in meiner Macht liegt, kann ich die gerne liefern.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 04 Januar 2019, 09:55:14
Zitat von: gandi1791 am 04 Januar 2019, 09:07:59

Noch ein paar Hintergrunddaten, falls es noch nützlich sein sollte (habe den Thread hier leider - noch - nicht bis zum Schluss gelesen):
RaspberryPi 3b
Stretch 9.6

Falls jemand (Rudi & Co) noch weitere Infos benötigt, sofern es in meiner Macht liegt, kann ich die gerne liefern.

Das wichtigste konnte ich deinem Post nicht entnehmen: Perlversion?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gandi1791 am 04 Januar 2019, 15:51:49
Zitat von: Damian am 04 Januar 2019, 09:55:14
Das wichtigste konnte ich deinem Post nicht entnehmen: Perlversion?

Sorry, hat heute morgen keinen Putty Zugriff.
Jetzt schon.
Habe die Version (v5.24.1) oben nachgetragen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DefanC am 05 Januar 2019, 13:08:49
Hallo,
ich hatte dasselbe Problem mit dem überlaufenden Speicher am Raspi. Nach längerem Suchen und deaktivieren einiger <devices> verbesserte sich leider nichts.
Mein Problem beruhigte sich, ebenso wie bei @gandi1791, nachdem ich Freezemon kpl. gelöscht hatte.
Hatte es zuvor ebenso nur <disabled 1> gesetzt, was (meiner Meinung nach) das Problem versursacht hatte.

zu meinen Systemdetails: 

RaspberryPi 3b
Stretch 9.6
Perl Version: v5.24.1
fhem:  aktuelle Version
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 05 Januar 2019, 13:39:00
Zitat von: DefanC am 05 Januar 2019, 13:08:49
Hallo,
ich hatte dasselbe Problem mit dem überlaufenden Speicher am Raspi. Nach längerem Suchen und deaktivieren einiger <devices> verbesserte sich leider nichts.
Mein Problem beruhigte sich, ebenso wie bei @gandi1791, nachdem ich Freezemon kpl. gelöscht hatte.
Hatte es zuvor ebenso nur <disabled 1> gesetzt, was (meiner Meinung nach) das Problem versursacht hatte.

zu meinen Systemdetails: 

RaspberryPi 3b
Stretch 9.6
Perl Version: v5.24.1
fhem:  aktuelle Version

Ich würde dennoch als erstes die 5.24 ersetzen, ich konnte den Speicherzuwachs jederzeit mit dem DOIF-Modul provozieren.

Es ist also eine tickende Zeitbombe, die sich je nach Einsatz der Module bei einem früher beim anderen später bemerkbar macht.

Edit: Das DOIF-Modul ist z. Zt. das einzige Modul, welches durch Umprogrammierung den Bug bewusst minimiert.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DefanC am 05 Januar 2019, 14:25:55
@Damian,

danke für deinen Hinweis!

Im Moment bin ich noch am Überlegen/Abwarten, die Perl 5.24 zu ersetzen.
Ich lese hier schon eine ganze Weile mit, um meinem/diesem Problem auf die Spur zu kommen.
Außer dem Freezemon-Modul und die Verbesserung nach dem löschen desselben, kann ich weiter nicht allzu viel dazu sagen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 06 Januar 2019, 14:13:32
Das mit der stetig steigenden Ram Auslastung meines Raspberry2 B unter DietPi V152 Perl V 5.20.2 beobachte ich auch schon länger. Bin aber auch Ratlos was ich dagegen tun kann.

Freezemon ist nicht aktiv, und auch apptime ist nicht Schuld.


Das Ram steigt stetig an, bis ich nach ein paar Tagen einen shutdown restart auslöse und alles wieder bei ca 130 beginnt.

Hilft es etwa nun das Perl zu updaten ? Ist ja schon etwas älter. Lief aber bisher gut. Ich update sowas ungerne wenn es nicht notwendig ist.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 06 Januar 2019, 20:22:00
Mein Speicherverbrauch des Systems schaut jetzt nach fast 4 tagen gut aus (Siehe Grafik).
Dies ist ohne apptime (was bei mir wahrscheinlich die Schuld hatte) und Perl 5.24.1.
Hier der Verbrauch des perl Prozess:


"ps -aux | grep fhem" ohne apptime:

03.01.2019 04:41: fhem     27616 21.5  5.2  55184 49932 ?        R    04:40   0:14 /usr/bin/perl fhem.pl fhem.cfg
03.01.2019 11:52: fhem     27616 14.6 10.7 107928 101972 ?       S    04:40  63:20 /usr/bin/perl fhem.pl fhem.cfg
03.01.2019 14:42: fhem     27616 15.3 12.2 122124 116136 ?       S    04:40  92:17 /usr/bin/perl fhem.pl fhem.cfg
03.01.2019 17:20: fhem     27616 15.5 13.3 133232 127148 ?       R    04:40 118:11 /usr/bin/perl fhem.pl fhem.cfg
03.01.2019 18:34: fhem     27616 15.6 14.0 140068 133852 ?       R    04:40 130:33 /usr/bin/perl fhem.pl fhem.cfg
03.01.2019 20:03: fhem     27616 15.8 14.8 147644 141432 ?       S    04:40 145:55 /usr/bin/perl fhem.pl fhem.cfg
03.01.2019 20:46: fhem     27616 15.8 15.8 156972 150756 ?       S    04:40 153:32 /usr/bin/perl fhem.pl fhem.cfg
04.01.2019 11:12: fhem     27616 15.9 16.5 163496 157284 ?       S    Jan03 291:52 /usr/bin/perl fhem.pl fhem.cfg
04.01.2019 20:10: fhem     27616 15.7 16.9 166596 160512 ?       S    Jan03 373:53 /usr/bin/perl fhem.pl fhem.cfg
06.01.2019 20:11: fhem     27616 15.7 18.7 184516 178308 ?       S    Jan03 824:31 /usr/bin/perl fhem.pl fhem.cfg

Nach 3 days, 15:36:52 uptime:
0,15% / h
1,4 MB / h


Ich beobachte das nun noch ein wenig und werde vll. doch mal Perl auf 5.26 up bzw. 5.20 downgraden.
Es gibt in der 5.24 lt. dem vorher geposteten Bugtracker Link ja definitiv memory leaks.

pOpY
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 07 Januar 2019, 18:56:49
Wenn ich das also richtig verstanden habe, kann es bei mir nicht an der veralteten Perl Version liegen, da ja scheinbar nur die 5.24 in der Hinsicht bugy ist.

Leider hab ich weder Freezemon noch Apptime laufen, und trotzdem steigt meine Ram Auslastung um ca 86 MB / 24h.

Wie kann man den einzelne Module abschalten um den Schuldigen zu finden. Es wird mir wohl nix anderes übrig bleiben als auf diese Weise der Sache auf die Spur zu kommen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 07 Januar 2019, 19:04:11
Zitat von: Skusi am 07 Januar 2019, 18:56:49
Wie kann man den einzelne Module abschalten um den Schuldigen zu finden. Es wird mir wohl nix anderes übrig bleiben als auf diese Weise der Sache auf die Spur zu kommen.

Schauen was das jeweilige Modul das du verwendest so bietet:

set DeviceName disable
set DeviceName inactive
...

attr DeviceName disable 1

Harter Weg:

Backup der fhem.cfg und dann Device löschen: delete DeviceName
(oder aber eher nicht empfohlen bzw. ebenfalls Backup: fhem.cfg editieren und Gerät "auskommenteren": '#' vor jede Zeile des Devices)

Aufpassen: bei manchen Geräten (2-Stufige: IODev -> Device) ist es wichtig die Reihenfolge zu beachten bzw. NICHT das "unterlagerte" Gerät (z.B. ein IODev für eine bestimmte Anbindung) zu deaktivieren, weil dann (meist) die darauf aufsetzenden Geräte eben der Boden unter den Füßen weggezogen wird/wurde und es dann zu Fehlern kommt bzw. diese nicht mehr (vernünftig) arbeiten können...

Und dann eben sehen wie sich der Speicher entwickelt.

EDIT: allerdings wurde das von einigen schon praktiziert... Und es gab schon viele "Verdächtige"... Daher beobachte ich, habe das Notify für "Notstart" aktiv und hoffe auf eine neue/andere Perl Version (sollte es tatsächlich [nur] daran liegen) in Raspbian... Aktuell "überlebt" mein System gut einen Monat. Das Testsystem (mit allem Möglichen installiert nicht nur fhem-Module auch auf OS-Seite ;)  ) nicht ganz so lang (aber es ist ja auch nur ein Testsystem) und das System bei meiner Freundin (ähnlich meinem Hauptsystem) gut gegen 2 Monate... Damit kann ich (noch) leben...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 07 Januar 2019, 19:52:37
Zitat von: iice64 am 03 Januar 2019, 13:57:53
Mit diesem Script kann mann sich eine fertig kompilierte für den Raspberry Pi (armv7l-linux) perl-5.20.3 und perlbrew installieren.
https://www.dropbox.com/s/926car881dvhrau/install-perlbrew-from-tar.sh?dl=1  (https://www.dropbox.com/s/926car881dvhrau/install-perlbrew-from-tar.sh?dl=1)
(wie immer ohne Gewähr)

Dann noch /etc/init.d/fhem anpassen. Änderungen sind fett.

#!/bin/bash
# description: Start or stop the fhem server
# Added by Alex Peuchert

### BEGIN INIT INFO
# Provides:             fhem.pl
# Required-Start:       $local_fs $remote_fs
# Required-Stop:        $local_fs $remote_fs
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    FHEM server
### END INIT INFO

export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3

set -e
cd /opt/fhem
port=7072


habe kein fhem init.d script mehr sondern ein systemd service Namens fhem.service:


  GNU nano 2.7.4                  File: fhem.service

[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target

[Service]
Type=forking
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target


Hast du eine Idee wie ich hier die bash optionen für perlbrew setzen kann?

Danke
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 08 Januar 2019, 18:49:27
sudo nano /opt/fhem/fhem.sh

mit folgendem Inhalt anlegen


#!/bin/bash
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3
cd /opt/fhem
perl fhem.pl fhem.cfg



sudo chown fhem:dialout /opt/fhem/fhem.sh
sudo chmod a+x /opt/fhem/fhem.sh

ExecStart=/opt/fhem/fhem.sh

eintragen
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Kusselin am 09 Januar 2019, 16:38:07
Hallo,

konnte die perl version 5.20.3 kompilieren und diese läuft jetzt auch.
Wollte jetzt mit"cpan SOAP::Lite" das Modul installieren...es läuft auch aber zum schluss kommt ne meldung:
Couldn´t untar SOAP-Lite-1.27.tar: Nicht genügend  Hauptspeicher verfügbar"

habe einen Raspi 3

Über ne Info vielen Dank

riting /root/.cpan/Metadata
Running install for module 'SOAP::Lite'
Checksum for /root/.cpan/sources/authors/id/P/PH/PHRED/SOAP-Lite-1.27.tar.gz ok
Uncompressed /root/.cpan/sources/authors/id/P/PH/PHRED/SOAP-Lite-1.27.tar.gz successfully
Using Tar:/bin/tar xf "SOAP-Lite-1.27.tar":
Couldn't untar SOAP-Lite-1.27.tar: 'Nicht gen?gend Hauptspeicher verf?gbar'
'YAML' not installed, will not store persistent state
  PHRED/SOAP-Lite-1.27.tar.gz
  Had problems unarchiving. Please build manually
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 09 Januar 2019, 18:17:18
Speicherplatz auf Speicherkarte voll?
"df -h"

Was läuft aktiv auf dem Gerät, mal alles "unwichtige" abgeschaltet?
"free -h"
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Kusselin am 09 Januar 2019, 21:59:39
ok...df -h bringt:
pi@raspberrypi:~ $ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root        15G    2,9G   12G   21% /
devtmpfs        460M       0  460M    0% /dev
tmpfs           464M       0  464M    0% /dev/shm
tmpfs           464M     12M  452M    3% /run
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           464M       0  464M    0% /sys/fs/cgroup
/dev/mmcblk0p1   41M     23M   19M   54% /boot
tmpfs            93M       0   93M    0% /run/user/1000


also das die Karte voll ist kann ich da aber nicht erkennen...

und das kommt bei free -h
pi@raspberrypi:~ $ free -h
              total        used        free      shared  buff/cache   available
Mem:           927M        615M        222M        1,1M         89M        262M
Swap:           99M         86M         13M


was sagt mir das jetzt??
Gruss
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 10 Januar 2019, 08:11:39
Komisch ... kannst DU mir auch noch die Inodes geben?
df -i

Btw: Könntest DU einen neuen Thread aufmachen? Hat jetzt erstmal nichts mit dem Hier diskutierten Problem zu tuen!
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 14 Januar 2019, 13:37:19
Zitat von: iice64 am 08 Januar 2019, 18:49:27
sudo nano /opt/fhem/fhem.sh

mit folgendem Inhalt anlegen


#!/bin/bash
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3
cd /opt/fhem
perl fhem.pl fhem.cfg



sudo chown fhem:dialout /opt/fhem/fhem.sh
sudo chmod a+x /opt/fhem/fhem.sh

ExecStart=/opt/fhem/fhem.sh

eintragen

Hast du dass bei Dir mit systemd auch so laufen?
Bin leider noch nicht dazugekommen, möchte aber schon Gerne auf eine andere Perl Version umstellen.

WIe geht das eigentlich beim RPI? Wird da das Package nicht mal aktualisiert?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Kusselin am 14 Januar 2019, 14:35:22
schau hier...so musst vorgehen....da reichts nicht grad den von Dir zitierten Beitrag in die Konsole einzugeben...ein dankeschön an Yamaha1983
Nun ins Eingemachte:

Bitte mache zuerst ein Backup deiner SD Karte. So kannst du jederzeit zurück zum "alten Zustand".
Folgende Zeichen zeigen dir immer in welcher Shell du dich befindest. Es ist Linux Konvention und bitte nicht mit eingeben
$ = Usershell
# = Rootshell

Wir starten mit dem User "pi" in der Shell über SSH
Als erstes bitte das System auf den aktuellsten Stand bringen mit:
$ sudo apt-get update
$ sudo apt-get upgrade

Dann benötigen wir noch die Kompiler, also Entwickertools:
$ sudo apt-get install build-essentials

Dann noch ein paar Librarys für die Perlmodule im späteren
$ sudo apt-get install libmariadb-dev libssl-dev


Dann Root werden:
$ sudo su -
# export PERLBREW_ROOT=/opt/perlbrew
# mkdir /opt/perlbrew
# cd /opt/perlbrew
# curl -L https://install.perlbrew.pl | bash

Jetzt wird Perlbrew in /opt/perlbrew eingerichtet

# perlbrew init
Der müsste nun sagen, dass perlbrew installiert ist und den Hinweis geben, dass hier noch etwas in die Startdatei der Shell (.bashrc / .profile) rein muss.

# nano ~/.bashrc
Das startet den Editor für die Startdatei ~/.bashrc  . Hier bitte ans Ende der Datei gehen und folgende Zeile einfügen. Anschließend speichern (ohne " bitte)
"source /opt/perlbrew/etc/bashrc"

Damit das Startskript der Shell geladen wird, muss man sich neu als root einloggen. Hierzu bitte folgendes Drücken:
Strg + D
Jetzt bist du wieder in der Shell vom User "pi"
Dann wieder
$ sudo su -
Jetzt bist du wieder root und das Startskript wurde geladen. Prüfe das mit
# perlbrew init
Dann kommt sowas hier (perlbrew root (/opt/perlbrew) is initialized.)
Für Root ist nun alles i.O. jetzt musst du das aber auch für pi und fhem einrichten.
Hier wieder zurück zum Benutzer "pi" mit Strg + D.
Wenn du wieder in der Shell vom Benutzer pi bist, dann editiere bitte die ~/.profile
$ nano ~/.profile
Hier ebenso ans Ende der Datei folgende 2 Zeilen einfügen, speichern, schließen:
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc


Jetzt ist der User pi auch bereit. Das gleiche wollen wir aber auch für den Benutzer "fhem".
Als Benutzer pi werden wir erstmal zu "fhem":
$ sudo su - fhem
Sollte das nicht gehen, dann schau mal mit dem nano in /etc/passwd
$ sudo nano /etc/passwd
Hier sollte die Zeile mit fhem wie folgt aussehen:
fhem:x:999:20::/opt/fhem:/bin/bash
Am Ende der Zeile siehst du die Shell, welche der Benutzer beim einloggen bekommt. Hier sollte /bin/bash stehen. Wenn nicht, abändern, speichern, schließen.

Ok wir sind nun "fhem". Jetzt bin ins Homeverzeichnis wechseln.
$ cd
Dann die .profile anlegen
nano .profile
Ebenso am Ende der Datei folgende zwei Zeilen hinzufügen:
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc

Damit die Änderungen für pi und fhem wirksam werden, muss sich neu eingeloggt werden. Am besten einfach putty schließen und eine neue SSH Verbindung aufmachen.
Neu eingeloggt als "pi" wechseln wir zum Beutzer root, damit wir nun die Perlversion 5.20.3 erstellen können:
$ sudo su -
Installation der Grund Perslversion 5.20.3
# perlbrew install perl-5.20.3
Das dauert nun eine Weile, weil perlbrew das Perl von aus den Quellen kompiliert. Bitte die Shell in dieser Zeit nicht schließen, oder den Rechner mit der Shell in den Stand by bringen.
In einer zweiten Shell kann man sich auch das kompilieren live anschauen.
dazu
$ tail -f [DATEI]

Ist das kompilieren durch, hast du eine Perl light version ohne spezielle Module.
$ perlbrew list
sagt dir die installierten Versionen. Hier sollte jetzt 5.20.3 erscheinen

Nun wollen wir weitere Module für Perl kompilieren. Diese Änderungen sind immer mit Root durchzuführen, da Perlbrew ausschließlich root gehört
$ sudo su -
Nun aktivieren wir diese Perlversion für die Shell:
# perlbrew use perl-5.20.3
Obs geklappt hat kann man einfach testen mit einem:
# perl -v
Nun sollte die Version 5.20.3 angezeigt werden

Wenn du nun Module kompilieren willst, dann mache es wie folgt nacheinander. Bitte warte immer ab, ob das kompilieren geklappt hat:
# cpan JSON
# cpan Device::SerialPort
# cpan URI::Escape
# cpan RPC::XML
# cpan IO::Socket::SSL
# cpan Crypt::CBC
# cpan Switch
# cpan Net::WebSocket::Server::Connection
# cpan Crypt::Cipher::AES
# cpan Crypt::Rijndael_PP
# cpan LWP::Simple
# cpan MIME::Base64
# cpan SOAP::Lite
# cpan -T DBD::mysql DBD::MariaDB

Beim letzt sorgt -T dafür, dass das MOdul nicht gegen eine DB Instanz getestet wird. Weiß ja nicht, ob du dblog oder sowas verwendest.

Sind dann alle Module kompiliert hast du es fast geschafft. Jetzt musst du gucken, dass dein FHEM immer mit dieser Version startet.
Je nachdem, wie du FHEM installiert hast, wird das mit dem rc system, oder dem systemctrl gestartet.
Ich nutze das rc system und konnte daher mein Startskript wie folgt als root ändern:

# nano /etc/init.d/fhem

oben nach den ersten Zeilen dann:
------------------------FILE /etc/init.d/fhem -----------------------------
#!/bin/bash
# description: Start or stop the fhem server
# Added by Alex Peuchert

### BEGIN INIT INFO
# Provides:             fhem.pl
# Required-Start:       $local_fs $remote_fs
# Required-Stop:        $local_fs $remote_fs
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    FHEM server
### END INIT INFO

export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3
------------------------------------------------------------------------------
Dadurch wird immer das richtige Perl genutzt.

Du kannst FHEM aber auch erstmal aus der Shell händisch starten, um zu sehen, dass du alle notwendigen Module hast.
Dazu logge dich als Benutzer "fhem" ein.

$ sudo su - fhem
$ perlbrew use perl-5.20.3
Jetzt hast du die richtige Perlverson. Kannst du hier nochmal testen:
$ perl -v
Wenn jetzt kein fhem läuft, kannst du das wie folgt starten:
perl fhem.pl fhem.cfg

Dein FHEM sollte nun ordentlich starten. Schau aber bitte im log Verzeichnissen nach der aktuellen FHEM Log
$ cd log
$ ls -la
Dann die letzte Log suchen und anschauen
$ less [LETZTE LOG]

Hier suche mal nach @INC. Sollten Meldungen zu sehen sein, wo Module fehlen, kannst du diese einfach also root mit cpan (so wie oben beschrieben) nachkompilieren.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 18 Januar 2019, 11:59:52
Ich bin gerade dabei einen Raspi neu aufzusetzten.
Mittlerweile gibt es ja schon die Perl Version 5.29.6.
Ich habe aber bisher keinen Erfolg diese zu installieren. Mir dürfte dabei ein Schritt fehlen.
wget https://www.cpan.org/src/5.0/perl-5.28.1.tar.gz
tar -xzf perl-5.28.1.tar.gz
cd perl-5.28.1

./Configure -des -Dprefix=$HOME/localperl
make
make test
make install


Was muss ich nach dem make install machen damit die vorhandene Perl Version 5.24.1 ersetzt wird.
Noch besser wäre natürlich kein Upgarde sondern gleich die letztgültige Perl Version zu installieren.

Hat jemand eine vollständige Installationsbeschreibung?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 19 Januar 2019, 06:38:20
Zitat von: iice64 am 03 Januar 2019, 13:57:53
Mit diesem Script kann mann sich eine fertig kompilierte für den Raspberry Pi (armv7l-linux) perl-5.20.3 und perlbrew installieren und sich mehre Stunden Arbeit sparen.

https://www.dropbox.com/s/926car881dvhrau/install-perlbrew-from-tar.sh?dl=1  (https://www.dropbox.com/s/926car881dvhrau/install-perlbrew-from-tar.sh?dl=1)

#!/bin/bash
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3


hinzufügen
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 19 Januar 2019, 16:30:56
Ich möchte eigentlich kein ältere Version installieren.
Gibt es eine Möglichkeit die 5.28.1 zu installieren?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 19 Januar 2019, 16:37:53
Zitat von: iice64 am 03 Januar 2019, 13:57:53
Mit diesem Script kann mann sich eine fertig kompilierte für den Raspberry Pi (armv7l-linux) perl-5.20.3 und perlbrew installieren.
https://www.dropbox.com/s/926car881dvhrau/install-perlbrew-from-tar.sh?dl=1  (https://www.dropbox.com/s/926car881dvhrau/install-perlbrew-from-tar.sh?dl=1)
(wie immer ohne Gewähr)

Dann noch /etc/init.d/fhem anpassen. Änderungen sind fett.

#!/bin/bash
# description: Start or stop the fhem server
# Added by Alex Peuchert

### BEGIN INIT INFO
# Provides:             fhem.pl
# Required-Start:       $local_fs $remote_fs
# Required-Stop:        $local_fs $remote_fs
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    FHEM server
### END INIT INFO

export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3

set -e
cd /opt/fhem
port=7072


Zitat von: iice64 am 08 Januar 2019, 18:49:27
sudo nano /opt/fhem/fhem.sh

mit folgendem Inhalt anlegen


#!/bin/bash
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3
cd /opt/fhem
perl fhem.pl fhem.cfg



sudo chown fhem:dialout /opt/fhem/fhem.sh
sudo chmod a+x /opt/fhem/fhem.sh

ExecStart=/opt/fhem/fhem.sh

eintragen

Danke hat geklappt.
{`perl -v`} gibt nun:




This is perl 5, version 20, subversion 3 (v5.20.3) built for armv7l-linux
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2015, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page


Wie weiß ich ob er alle PERL libs findet (die man sonst mit CPAN nachinstalliert)?
Das ist mein fhem start log:


2019.01.19 16:33:39 1: Including fhem.cfg
2019.01.19 16:33:40 2: eventTypes: loaded 3598 events from ./log/eventTypes.txt
2019.01.19 16:33:45 1: PERL WARNING: TASMOTA::DEVICE::Expand() called too early to check prototype at ./FHEM/10_TASMOTA_DEVICE.pm line 283, <$fh> line 1270.
2019.01.19 16:33:45 1: PERL WARNING: TASMOTA::DEVICE::Expand() called too early to check prototype at ./FHEM/10_TASMOTA_DEVICE.pm line 289, <$fh> line 1270.
2019.01.19 16:33:47 1: Including ./log/fhem.save
2019.01.19 16:33:53 0: Featurelevel: 5.9
2019.01.19 16:33:53 0: Server started with 227 defined entities (fhem.pl:18029/2018-12-22 perl:5.020003 os:linux user:fhem pid:11563)
2019.01.19 16:33:57 1: PERL WARNING: Use of uninitialized value $ret in numeric le (<=) at FHEM/HttpUtils.pm line 618.
2019.01.19 16:34:04 2: AttrTemplates: got 26 entries

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 19 Januar 2019, 18:07:55
Zitat von: popy am 19 Januar 2019, 16:37:53
Wie weiß ich ob er alle PERL libs findet (die man sonst mit CPAN nachinstalliert)?

Wenn im Log keine @INC erscheinen, wird alles gefunden.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 19 Januar 2019, 18:16:39
Zitat von: Burny4600 am 19 Januar 2019, 16:30:56
Ich möchte eigentlich kein ältere Version installieren.
Gibt es eine Möglichkeit die 5.28.1 zu installieren?
Die hat noch niemand auf Memory Leaks untersucht.
Von perl-5.20.3 weiß ich definitiv, das keine Memory Leaks auftreten.

Du kannst ja mal nach Yamahas Anleitung dein Glück versuchen. Die Kompilierung dauert allerdings ein paar Stunden.
Dann kannst du uns berichten, wie es bei dieser Version mit dem Speicherverbrauch aussieht.

Zitat von: yamaha1983 am 21 November 2018, 08:50:33
siehe hier
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 19 Januar 2019, 18:18:55
Zitat von: iice64 am 19 Januar 2019, 18:07:55
Wenn im Log keine @INC erscheinen, wird alles gefunden.
Danke, dann sollte es passen

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 19 Januar 2019, 18:24:14
ZitatDu kannst ja mal nach Yamahas Anleitung dein Glück versuchen.
Wo finde ich die Anleitung? Hier habe ich unter Yamahas nichts gefunden.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 19 Januar 2019, 18:28:52
Zitat von: Burny4600 am 19 Januar 2019, 18:24:14
Wo finde ich die Anleitung? Hier habe ich unter Yamahas nichts gefunden.
Klick mal auf den Link über siehe hier Zitat von: yamaha1983 am 21 November 2018, 08:50:33
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 20 Januar 2019, 09:01:43
Also bei mir unter Perl -5.20.2 sieht das leider so aus :
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 20 Januar 2019, 09:47:53
Zitat von: Skusi am 20 Januar 2019, 09:01:43
Also bei mir unter Perl -5.20.2 sieht das leider so aus :
Bei mir läuft perl-5.20.3 und läuft absolut stabil.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 21 Januar 2019, 18:09:36
Ich verstehe nur nicht wie das nun auf einmal kommt. Meine Perl Version ist schon ewig unverändert. Da muß sich doch eine Modul bugmäßig seit irgendeinem Update diesen Speicher gönnen.

Der Schuldige ist doch deswegen nicht Perl.

Außerdem frage ich mich wie ich meine live System mal eben auf Perl 5.20.3 updaten soll. Das geht doch bestimmt nur per neuaufsetzen des RPi - Oder ?

Lieber wäre mir das fehlerhafte Modul ausfindig zu machen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: maci am 21 Januar 2019, 19:35:56
Ich denke, dass hier mehr zusammenspielt.

Es muss nicht zwangsläufig perl oder python, .... sein.

Da dieses Problem nur beim aktuellen Debian System auftritt und das wiederum nur am Raspberry, vermute ich da irgendetwas im System, das nicht absolut mit dem Raspberry harmoniert.
Die kann das dann auslösen.
Ich hatte es anfangs auch, und wiederum nur auf einem Gerät.
Ich weiß nicht mehr was ich gemacht habe, aber jetzt läuft alles, bis auf die Tatsache, dass mein x-Deamon ständig abschmiert.
Da ich dem Gerät einen Bildschirm hängen habe, ist das nicht immer optimal.
Er meckert immer etwas von zuwenig Speicher, obwohl mein Speicherverbrauch nicht ansteigt.
Ich vermute dass ihm der deaktivierte Swap nicht schmeckt.

Da ich aber sowieso vorhabe, diesen Raspberry (mein HeizungsFhem) im Frühjahr eine SSD zu gönnen, belasse ich das erstmal so.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 21 Januar 2019, 19:46:22
Was läst Du denn auf X laufen?

Wenn ein Browser .... die können manchmal wirklich speicher ziehen ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 21 Januar 2019, 22:12:59
ZitatLieber wäre mir das fehlerhafte Modul ausfindig zu machen.
Mir auch. Ich behaupte, hier gibt es an mehreren Stellen Probleme, die sich mit dem gleichen Symptom melden:
- Bug in (mehreren?) FHEM-Modulen.
- Perl-Bug, was bei Verwendung bestimmter Features in einem Modul sich bemerkbar macht
- Bug in einem der OS-Bibliotheken.
Fuer alle diese Bugs gilt, dass es nicht in jedem FHEM/Perl/OS-Version auftreten, und die Mehrheit der FHEM-User nicht merklich stoert.

Keiner dieser Bugs ist einfach zu finden, selbst von erfahrenen Bug-Jaeger, und unmoeglich, falls man es selbst nicht reproduziert kriegt.
Um das Problem zu fixen, muss man es also erst lokalisieren.
Und das geht am einfachsten (auch wenn viele jetzt stoehnen werden), indem man die FHEM-Konfiguration schrittweise soweit verkleinert, bis das Problem nicht mehr auftritt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 22 Januar 2019, 09:59:49
Zitat von: iice64 am 20 Januar 2019, 09:47:53
Bei mir läuft perl-5.20.3 und läuft absolut stabil.

Auch bei mir mit der 5.20.3 ohne jeglichen Anstieg!

pOpY
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 22 Januar 2019, 19:37:55
Also, ich denke das es am saubersten wäre wenn ich den Raspberry neu aufsetze.

Bleibt die Frage welches Image würdet Ihr empfehlen.
Ich fahre schon ewig mit dem DietPI Image, und hatte bisher keine Probleme. Wenn ich nun schon alles neu machen muß, würde ich gerne welches System sich für den Pi2 B und Fhem am besten eignet. Und natürlich sollte eine Perl Version enthalten sein die diese Memory Leaks nicht mehr hat.

Irgendein Tipp ???
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 22 Januar 2019, 20:04:39
Nein ... und warum sollte ein Neuinstallieren helfen? Wir sind bei Linux und nicht bei Windows ;o)

Besser und Gesamtheitlich optimaler wäre, die Ursache zu finden ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 23 Januar 2019, 08:44:47
Zitat von: maci am 21 Januar 2019, 19:35:56

Es muss nicht zwangsläufig perl oder python, .... sein.

Da dieses Problem nur beim aktuellen Debian System auftritt und das wiederum nur am Raspberry, vermute ich da irgendetwas im System, das nicht absolut mit dem Raspberry harmoniert.
Da kann ich dir nicht ganz zustimmen. Ich bekam die Probleme mit dem Wechsel auf Debian Stretch. Hier wurde eine neue Perl Version 5.24.1 mitgeliefert. Mit dieser Version begann das Memory Leak. Meine einzige Änderung, die ich danach am System vorgenommen habe, war der Wechsel mit Perlbrew auf perl 5.20.3. Alles andere am System blieb unverändert.  Und genau diese Änderung bewirkte, dass das Memory Leak verschwand. Schalte ich mit perlbrew auf 5.24.1 zurück, ist das Memory Leak wieder da!
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 23 Januar 2019, 09:26:52
Zitat von: iice64 am 23 Januar 2019, 08:44:47
Da kann ich dir nicht ganz zustimmen. Ich bekam die Probleme mit dem Wechsel auf Debian Stretch. Hier wurde eine neue Perl Version 5.24.1 mitgeliefert. Mit dieser Version begann das Memory Leak. Meine einzige Änderung, die ich danach am System vorgenommen habe, war der Wechsel mit Perlbrew auf perl 5.20.3. Alles andere am System blieb unverändert.  Und genau diese Änderung bewirkte, dass das Memory Leak verschwand. Schalte ich mit perlbrew auf 5.24.1 zurück, ist das Memory Leak wieder da!

siehe https://forum.fhem.de/index.php/topic,84372.msg881837.html#msg881837

zu betonen ist: "ich konnte mit der 5.24 Version jederzeit das Memory Leak provozieren" mit anderen Versionen insb. 5.26 kann ich das Memory Leak nicht mehr provozieren.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Morgennebel am 23 Januar 2019, 09:36:32
https://rt.perl.org/Public/Search/Simple.html?q=memory+leak

führt zu dem Hinweis, daß 5.24.1 mehrere Memory Leaks hat, die erst in 5.25.10 gefixt wurden.

Z.B. https://rt.perl.org/Public/Bug/Display.html?id=131219 https://rt.perl.org/Public/Bug/Display.html?id=130254 https://rt.perl.org/Public/Bug/Display.html?id=128313 usw.

Vieles davon betrifft RegExps. Ich denke, gerade dieses nutzt FHEM ganz massiv und es würde den Geschwindigkeit erklären...

Ciao, -MN
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Timmy.m am 23 Januar 2019, 10:36:42
Ich bin auch von den Speicherproblemen betroffen und mir ist aufgefallen, dass der Speicher in +0.1% Schritten steigt, wenn man zwischen einem Raum und "Everything" im linken Menü wechselt.

Zu lesen auf https://forum.fhem.de/index.php/topic,96256.0.html (https://forum.fhem.de/index.php/topic,96256.0.html)

Grüße Tim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 23 Januar 2019, 10:44:16
Zitat von: Morgennebel am 23 Januar 2019, 09:36:32
https://rt.perl.org/Public/Search/Simple.html?q=memory+leak

führt zu dem Hinweis, daß 5.24.1 mehrere Memory Leaks hat, die erst in 5.25.10 gefixt wurden.

Z.B. https://rt.perl.org/Public/Bug/Display.html?id=131219 https://rt.perl.org/Public/Bug/Display.html?id=130254 https://rt.perl.org/Public/Bug/Display.html?id=128313 usw.

Vieles davon betrifft RegExps. Ich denke, gerade dieses nutzt FHEM ganz massiv und es würde den Geschwindigkeit erklären...

Ciao, -MN

Ich konnte bei mir sogar die Regex-Aufrufe in meinem Modul identifizieren, die allerdings nur im FHEM-Umfeld in der Perlversion 5.24 zum memory leak  geführt haben.

Ich könnte (aus meinem Modul) ein abgespecktes Programm zur Verfügung stellen, welches das Regex-Problem provoziert. Damit könnte man feststellen, ob man mit einer Perlversion arbeitet, die ein bestimmtes regex-memory-leak hat.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 23 Januar 2019, 11:32:06
Das wäre toll und würde dem einen oder anderen sicher helfen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Timmy.m am 23 Januar 2019, 16:16:11
Zitat von: iice64 am 20 Januar 2019, 09:47:53
Bei mir läuft perl-5.20.3 und läuft absolut stabil.

Hattest du am 17.1 ein Neustart von FHEM gemacht? Es sieht bei dir so aus, als würde der RAM Verbrauch auch steigen... aber halt nur minimal. Hast du mal geschaut, ob du beim Räume wechseln (Zwischen Everything und anderen Räumen) per htop auch RAM Einbußen in 0.1% Schritten verzeichnen kannst.

Grüße Tim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: iice64 am 23 Januar 2019, 17:46:31
Zitat von: Timmy.m am 23 Januar 2019, 16:16:11
Hattest du am 17.1 ein Neustart von FHEM gemacht? Es sieht bei dir so aus, als würde der RAM Verbrauch auch steigen... aber halt nur minimal. Hast du mal geschaut, ob du beim Räume wechseln (Zwischen Everything und anderen Räumen) per htop auch RAM Einbußen in 0.1% Schritten verzeichnen kannst.
Ja da war ein Neustart und dann dauert es halt immer bis alle Prozesse sich eingeschwungen haben.
Zumal bei mir nginx, tomcat (java heap), fhem und diverse Cronjobs laufen.
Aber der perl Prozess nimmt sich nicht ständig mehr Speicher wie perl 5.24.1. Da hat mein Pi nach ca. 10 Stunden keinen Speicher mehr gehabt.
Der Wechsel von Everything zu anderen Räumen führt nicht zu einer ständigen Zunahme des Speichers, sondern er pendelt um 285MB herum.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 23 Januar 2019, 18:13:47
In 10 Stunden kein Ram mehr !? Das ist Krass.
Da bin ich ja noch froh das es bei mir "nur" ca 60 MB / Tag sind. Ich fliege ab Sonntag 14 Tage weg, da kann ich sowas nicht brauchen. Ich fasse nun auch nix mehr an, aus Angst alles noch schlimmer zu machen. Aber doof finde ich das schon extrem. Lief doch jahrelang ohne diese Lecks.

Also scheint dieses perlbrew wohl die beste Lösung zu sein. Da muß ich mich also nach meinem Urlaub mal mit beschäftigen. Ich bin aber noch guter Hoffnung das hier noch jemand die Ursache findet.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 23 Januar 2019, 22:22:43
Geh mal ein paar Kommentare zurück, da gab es irgendwas, um bei einem Speicherproblem Fhem zu restarten. Könnte für den Urlaub hilfreich sein.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 23 Januar 2019, 22:37:34
Zitat von: mumpitzstuff am 23 Januar 2019, 22:22:43
Geh mal ein paar Kommentare zurück, da gab es irgendwas, um bei einem Speicherproblem Fhem zu restarten. Könnte für den Urlaub hilfreich sein.

Vermutlich das hier:

define nCannotForkRestart notify global:CANNOT_FORK shutdown restart

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Timmy.m am 25 Januar 2019, 21:56:52
Dank der Anleitung hier im Forum habe ich nun mit Perlbrew die perl version 5.20.3.
Jetzt bekomme ich Fehler beim Start, dass Pakete nicht installiert sind

ZitatMessages collected while initializing FHEM:
configfile: Cannot load module UWZ
Cannot define A61 device. Perl modul HTML::TreeBuilder::XPath  is missing.
Cannot load module SIP

Wie bekomme ich die nun Installiert... in der "Standard Perl Version" sind sie bereits installiert und wenn ich im Terminal Perlbrew mit perl version 5.20.3. aktiviere und nachinstalliere zeigt es für FHEM keine Wirkung. Ich bin ratlos.

Grüße Tim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Timmy.m am 26 Januar 2019, 10:49:00
Jetzt kommt die große Überraschung. Eine ganze Nacht lief nun der Raspberry mit version 5.20.3.
Und oh Wunder... er verbraucht immer noch RAM.

Bin nun endgültig fix und fertig!

Grüße Tim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: frank am 26 Januar 2019, 12:30:49
da hast du dir ja was "eingefangen".

dein os ist nun stretch?
hast du dann ein neues stretch lite image genommen, oder dein altes jessie "aufgemotzt".
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Timmy.m am 26 Januar 2019, 15:11:20
Hallo Frank.

Ich bin zurück auf Jessie per Backup. Also das alte System nur mit Perlbrew.

Grüße Tim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 26 Januar 2019, 15:57:31
Na toll, dann bleibt ja nur noch nachzuweisen das es mit Perl ab 5.25.10 gefixt ist.

Danke an Timmy.m der mir den Weg über 5.20.3 erspart hat. Ich hoffe das es jemand nochmal testet um zu bestätigen das die Arbeit sich gelohnt hat. Wegen meine Reise hab ich erstmal nur die Auto Restart Funktion realisiert. So startet das System zwar alle paar Tage neu, aber mehr kann ich auf die schnelle nicht tun.

Ich mußte auch feststellen das verfügbarer Speicher unter 500 MB schon zum cannot_Fork führt. Das bedeutet das ich nach einem Neustart ca 5 Tage bis zum restart habe.

Hoffentlich geht das gut. Bin 12 Tage weg...

Ich hoffe nach meiner Rückkehr zu wissen was Zutun ist.


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 26 Januar 2019, 16:31:45
ZitatDanke an Timmy.m der mir den Weg über 5.20.3 erspart hat.
Wie ich geschrieben habe: Hier werden mehrere Probleme diskutiert, die das gleiche _Symptom_ haben. Einer der Ursachen ist sicher perl 5.24, die anderen Ursachen sind z.Zt. noch nicht bekannt, und das sie im Perl zu finden ist, ist (d)eine neue Hypothese.

Welche Ursache wen betrifft, ist je nach verwendetes Modul, gesetzte Attribute, OS und Hardware unterschiedlich. Solange deine Konfiguration, OS und Hardware mit der von Timmy.m nicht identisch ist, wuerde ich von perl 5.24 auf eine andere Version wechseln, damit dieses eine bekannte Bug schonmal ausgeschlosen wird.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 26 Januar 2019, 19:57:34
Vor allem, da es für jessie keine updates mehr gibt ...

Glaube auch, das arm eine zusätzliche Fehlerquelle ist. Bis jetzt habe ich bei X86 nichts gehört .... und meine (Allerdings kleine) fhem Installation dümpelt mit wenig Speicher vor sich hin (auf X86)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 26 Januar 2019, 21:06:11
Zitat von: Wernieman am 26 Januar 2019, 19:57:34
Vor allem, da es für jessie keine updates mehr gibt ...

Glaube auch, das arm eine zusätzliche Fehlerquelle ist. Bis jetzt habe ich bei X86 nichts gehört .... und meine (Allerdings kleine) fhem Installation dümpelt mit wenig Speicher vor sich hin (auf X86)

Perl 5.24 hat auch das Problem auch unter x86. Das kann ich aus eigener Erfahrung sagen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: maci am 27 Januar 2019, 08:56:30
Jetzt habe ich das Problem auch auf meinem Fhem Hauptserver.
Hier läuft die Perl-Problemversion 5.24.

Ich hatte das Problem hier bisher noch nie.
Vor kurzem habe ich hier grab installiert.
Anfangs habe ich mir nicht dabei gedacht.
Gestern ist mir aufgefallen, nach dem ich ein paar Tage nicht nachgesehen hatte, dass im Logfile das hier steht:
Cannot fork: Cannot allocate memory
2019.01.26 16:51:45 1: Cannot fork: Cannot allocate memory
2019.01.26 16:51:45 1: stacktrace:
2019.01.26 16:51:45 1:     main::fhemFork                      called by FHEM/Blocking.pm (172)
2019.01.26 16:51:45 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.01.26 16:51:45 1:     main::BlockingCall                  called by ./FHEM/42_SYSMON.pm (905)
2019.01.26 16:51:45 1:     main::SYSMON_Update                 called by ./FHEM/98_apptime.pm (205)
2019.01.26 16:51:45 1:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (113)
2019.01.26 16:51:45 1:     main::HandleTimeout                 called by fhem.pl (649)
2019.01.26 16:51:45 1: Cannot fork: Cannot allocate memory


Die Steuerungen der Rolläden liefen allerdings normal weiter. Auch die Temperaturwerte wurden ordnungsgemäß in die DbLog eingetragen.

Am 20. 1 um 22:51 kam erstmals diese Meldung.
Dazwischen immer andere normale Logmeldungen.
Interessant ist, dass zwischen den Cannot fork Meldungen immer wieder Pausen von 4-6 Stunden sind. In dieser Zeit waren die Logmeldungen normal.

Habe gestern abend dann mal die stutdown restart Routine eingebaut, denn ein Downgrade will ich derzeit nicht machen.

Interessant ist allerdings, dass im Anschluß an mein Connot fork Meldungen dass hier kommt:
PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3494.
2019.01.21 01:13:38 3: eval: {BlockingStart('33485')}
2019.01.21 01:13:38 1: stacktrace:
2019.01.21 01:13:38 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (3493)
2019.01.21 01:13:38 1:     main::SYSMON_isProcFS               called by ./FHEM/42_SYSMON.pm (1188)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.01.21 01:13:38 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (192)
2019.01.21 01:13:38 1:     main::BlockingStart                 called by (eval 1035576) (1)
2019.01.21 01:13:38 1:     (eval)                              called by fhem.pl (1115)
2019.01.21 01:13:38 1:     main::AnalyzePerlCommand            called by fhem.pl (1140)
2019.01.21 01:13:38 1:     main::AnalyzeCommand                called by fhem.pl (1062)
2019.01.21 01:13:38 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (242)
2019.01.21 01:13:38 1:     main::telnet_Read                   called by ./FHEM/98_apptime.pm (205)
2019.01.21 01:13:38 1:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (165)
2019.01.21 01:13:38 1:     main::CallFn                        called by fhem.pl (726)
2019.01.21 01:13:38 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3625.
2019.01.21 01:13:38 3: eval: {BlockingStart('33485')}
2019.01.21 01:13:38 1: stacktrace:
2019.01.21 01:13:38 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (3624)
2019.01.21 01:13:38 1:     main::SYSMON_isSysCpuNum            called by ./FHEM/42_SYSMON.pm (1572)
2019.01.21 01:13:38 1:     main::SYSMON_getCPUCoreNum_intern   called by ./FHEM/42_SYSMON.pm (1597)
2019.01.21 01:13:38 1:     main::SYSMON_getCPUCoreNum          called by ./FHEM/42_SYSMON.pm (1203)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.01.21 01:13:38 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (192)
2019.01.21 01:13:38 1:     main::BlockingStart                 called by (eval 1035576) (1)
2019.01.21 01:13:38 1:     (eval)                              called by fhem.pl (1115)
2019.01.21 01:13:38 1:     main::AnalyzePerlCommand            called by fhem.pl (1140)
2019.01.21 01:13:38 1:     main::AnalyzeCommand                called by fhem.pl (1062)
2019.01.21 01:13:38 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (242)
2019.01.21 01:13:38 1:     main::telnet_Read                   called by ./FHEM/98_apptime.pm (205)
2019.01.21 01:13:38 1:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (165)
2019.01.21 01:13:38 1:     main::CallFn                        called by fhem.pl (726)
2019.01.21 01:13:38 1: PERL WARNING: Use of uninitialized value $val in int at ./FHEM/42_SYSMON.pm line 1765.
2019.01.21 01:13:38 3: eval: {BlockingStart('33485')}
2019.01.21 01:13:38 1: stacktrace:
2019.01.21 01:13:38 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (1765)
2019.01.21 01:13:38 1:     main::SYSMON_getCPUTemp_RPi         called by ./FHEM/42_SYSMON.pm (1207)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.01.21 01:13:38 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (192)
2019.01.21 01:13:38 1:     main::BlockingStart                 called by (eval 1035576) (1)
2019.01.21 01:13:38 1:     (eval)                              called by fhem.pl (1115)
2019.01.21 01:13:38 1:     main::AnalyzePerlCommand            called by fhem.pl (1140)
2019.01.21 01:13:38 1:     main::AnalyzeCommand                called by fhem.pl (1062)
2019.01.21 01:13:38 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (242)
2019.01.21 01:13:38 1:     main::telnet_Read                   called by ./FHEM/98_apptime.pm (205)
2019.01.21 01:13:38 1:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (165)
2019.01.21 01:13:38 1:     main::CallFn                        called by fhem.pl (726)
2019.01.21 01:13:38 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3516.
2019.01.21 01:13:38 3: eval: {BlockingStart('33485')}
2019.01.21 01:13:38 1: stacktrace:
2019.01.21 01:13:38 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (3515)
2019.01.21 01:13:38 1:     main::SYSMON_isCPUTempBBB           called by ./FHEM/42_SYSMON.pm (1209)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.01.21 01:13:38 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (192)
2019.01.21 01:13:38 1:     main::BlockingStart                 called by (eval 1035576) (1)
2019.01.21 01:13:38 1:     (eval)                              called by fhem.pl (1115)
2019.01.21 01:13:38 1:     main::AnalyzePerlCommand            called by fhem.pl (1140)
2019.01.21 01:13:38 1:     main::AnalyzeCommand                called by fhem.pl (1062)
2019.01.21 01:13:38 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (242)
2019.01.21 01:13:38 1:     main::telnet_Read                   called by ./FHEM/98_apptime.pm (205)
2019.01.21 01:13:38 1:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (165)
2019.01.21 01:13:38 1:     main::CallFn                        called by fhem.pl (726)
2019.01.21 01:13:38 1: PERL WARNING: Use of uninitialized value $val in int at ./FHEM/42_SYSMON.pm line 1820.
2019.01.21 01:13:38 3: eval: {BlockingStart('33485')}
2019.01.21 01:13:38 1: stacktrace:
2019.01.21 01:13:38 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (1820)
2019.01.21 01:13:38 1:     main::SYSMON_getCPUTemp_X           called by ./FHEM/42_SYSMON.pm (1214)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.01.21 01:13:38 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (192)
2019.01.21 01:13:38 1:     main::BlockingStart                 called by (eval 1035576) (1)
2019.01.21 01:13:38 1:     (eval)                              called by fhem.pl (1115)
2019.01.21 01:13:38 1:     main::AnalyzePerlCommand            called by fhem.pl (1140)
2019.01.21 01:13:38 1:     main::AnalyzeCommand                called by fhem.pl (1062)
2019.01.21 01:13:38 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (242)
2019.01.21 01:13:38 1:     main::telnet_Read                   called by ./FHEM/98_apptime.pm (205)
2019.01.21 01:13:38 1:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (165)
2019.01.21 01:13:38 1:     main::CallFn                        called by fhem.pl (726)
2019.01.21 01:13:38 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.01.21 01:13:38 3: eval: {BlockingStart('33485')}
2019.01.21 01:13:38 1: stacktrace:
2019.01.21 01:13:38 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (2268)
2019.01.21 01:13:38 1:     main::SYSMON_getRamAndSwap          called by ./FHEM/42_SYSMON.pm (1255)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.01.21 01:13:38 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (192)
2019.01.21 01:13:38 1:     main::BlockingStart                 called by (eval 1035576) (1)
2019.01.21 01:13:38 1:     (eval)                              called by fhem.pl (1115)
2019.01.21 01:13:38 1:     main::AnalyzePerlCommand            called by fhem.pl (1140)
2019.01.21 01:13:38 1:     main::AnalyzeCommand                called by fhem.pl (1062)
2019.01.21 01:13:38 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (242)
2019.01.21 01:13:38 1:     main::telnet_Read                   called by ./FHEM/98_apptime.pm (205)
2019.01.21 01:13:38 1:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (165)
2019.01.21 01:13:38 1:     main::CallFn                        called by fhem.pl (726)
2019.01.21 01:13:38 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.01.21 01:13:38 3: eval: {BlockingStart('33485')}
2019.01.21 01:13:38 1: stacktrace:
2019.01.21 01:13:38 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (2269)
2019.01.21 01:13:38 1:     main::SYSMON_getRamAndSwap          called by ./FHEM/42_SYSMON.pm (1255)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.01.21 01:13:38 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.01.21 01:13:38 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (192)
2019.01.21 01:13:38 1:     main::BlockingStart                 called by (eval 1035576) (1)
2019.01.21 01:13:38 1:     (eval)                              called by fhem.pl (1115)
2019.01.21 01:13:38 1:     main::AnalyzePerlCommand            called by fhem.pl (1140)
2019.01.21 01:13:38 1:     main::AnalyzeCommand                called by fhem.pl (1062)
2019.01.21 01:13:38 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (242)
2019.01.21 01:13:38 1:     main::telnet_Read                   called by ./FHEM/98_apptime.pm (205)
2019.01.21 01:13:38 1:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (165)
2019.01.21 01:13:38 1:     main::CallFn                        called by fhem.pl (726)


Danach ist wieder Ruhe und nur normale Einträge, bis es dann ein paar Stunden später wieder auftaucht.

Jedenfalls beobachte ich mein Fhem weiterhin etwas.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Gerrit am 27 Januar 2019, 09:58:41
Moin,

mir ist das "vollaufen" des Speichers vor ein paar Tagen auch zufällig aufgefallen. Ich hatte freezemon und yeelightbridge installiert. Nach der Deinstallation war wieder Ruhe. Perl ist 5.20.2

Gruß Gerrit
https://uploads.tapatalk-cdn.com/20190127/b705556ec1006601c241319858bdfa8d.jpg (https://uploads.tapatalk-cdn.com/20190127/b705556ec1006601c241319858bdfa8d.jpg)

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Timmy.m am 27 Januar 2019, 20:53:58
Danke Gerrit!

ich habe freezemon mal aus meiner Config raus geworfen und es sieht erst einmal besser aus. Werde es über Nacht einmal ansehen.
Wohlgemerkt habe ich nun Raspberry Pi3 mit Jessie und Perl 5.20.2, sowohl der Option Raspberry Pi3 mit Jessie und Perlbrew 5.20.3 und einen ganz neu aufgesetzten Raspberry PI3+ mit Stretch und Perl 5.24.1, wenn auch dieser verhält sich ohne freezemon wesentlich besser.

Die Frage ist halt, warum der Speicherverbrauch immer noch steigt und nicht wieder freigegeben wird, wenn man zwischen einem sehr vollen Raum "Everything" und einem anderen Raum wechselt. Irgendetwas mit dem WEB Modul?

Trotzdem bin ich noch etwas skeptisch, es muss noch etwas mehr dahinter stecken. Meine Probleme fingen an, als ich das Modul "HUEBridge" mit insgesamt 13 Lampen in Betrieb genommen habe, erst deswegen habe ich freezemon installiert.


Grüße Tim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 27 Januar 2019, 20:57:31
Umgekehrte Frage: besser es sich, wenn Du das Modul "HUEBridge" wieder rausnimmst?

P.S. ausnahmsweise nach dem rausnehmen fhem rebooten ... um sicherzugehen
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Timmy.m am 27 Januar 2019, 21:01:43
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Gerrit am 27 Januar 2019, 23:18:07
Die Huebridge läuft bei mir problemlos.

Gruß Gerrit

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 28 Januar 2019, 00:14:13
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")
   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)
{ int(keys %intAt) }   ==>> 96
{ int(keys %defs).":".int(keys %attr) }   ==>> 918:918



Gruß,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Thorsten am 28 Januar 2019, 15:34:08
Zitat von: MadMax-FHEM am 23 Januar 2019, 22:37:34
Vermutlich das hier:

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?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: kadettilac89 am 28 Januar 2019, 15:40:43
Zitat von: Thorsten am 28 Januar 2019, 15:34:08
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 ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Kusselin am 28 Januar 2019, 15:53:42
Zitat von: Thorsten am 28 Januar 2019, 15:34:08
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...

Zitatwenn 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?? :-\
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Timmy.m am 28 Januar 2019, 17:05:18
Hatte auch Probleme, ich habe es so gelöst:

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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: kadettilac89 am 28 Januar 2019, 18:32:15
Zitat von: Kusselin am 28 Januar 2019, 15:53:42
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

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



systemctl daemon-reload
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 30 Januar 2019, 00:00:59
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rcmcronny am 30 Januar 2019, 09:35:54
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: frank am 30 Januar 2019, 11:19:37
moin,

ich habe zur zeit 2 verdächtige:

1. userreading mit modifier "integral"
attr Broetje userReadings hzgGas:hzgBrennerMod:.* integral {ReadingsVal($NAME,"hzgBrennerMod",0)}
2. event-aggregator mit function "integral"
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:
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Christoph Morrison am 02 Februar 2019, 22:05:28
Ich leide unter dem gleichen Problem und habe aktuell Devel::Leak::Object mitlaufen. Hier mal der Output nach so drei Stunden Laufzeit:
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)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 03 Februar 2019, 02:37:15
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Christoph Morrison am 03 Februar 2019, 12:18:44
Zitat von: Hardlife am 03 Februar 2019, 02:37:15
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.

Zitat von: Hardlife am 03 Februar 2019, 02:37:15
Werden dann "Überläufe" gelistet?

Es werden Stellen gelistet, in denen Referenzen nicht richtig gelöscht werden können, siehe die Beschreibung (https://metacpan.org/pod/Devel::Leak::Object). 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.

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

Geht mir leider auch so :-(

ZitatIch 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:
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Christoph Morrison am 03 Februar 2019, 18:48:52
Hier ist mal ein neuer Kandidat aufgeschlagen:

Calendar::Event
   182 from ./FHEM/57_Calendar.pm line: 1074
Calendar::Events
   364 from ./FHEM/57_Calendar.pm line: 742
   364 from ./FHEM/57_Calendar.pm line: 743


Ich benutze Calendar zusammen mit Abfall für die Mülltermine. Hat diese Kombination noch jemand laufen (Perl 5.24.1, Stretch)? Auch wenn ich aktuell nicht glaube, dass das der Übeltäter ist, so wäre das doch für den Maintainer eine hilfreiche Info.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Dr. Boris Neubert am 04 Februar 2019, 21:17:36
Zitat von: Christoph Morrison am 03 Februar 2019, 18:48:52
Hier ist mal ein neuer Kandidat aufgeschlagen:

Calendar::Event
   182 from ./FHEM/57_Calendar.pm line: 1074
Calendar::Events
   364 from ./FHEM/57_Calendar.pm line: 742
   364 from ./FHEM/57_Calendar.pm line: 743


Danke für den Hinweis! Sobald ich mich wieder mit FHEM befassen kann, werde ich mir das ansehen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 04 Februar 2019, 21:24:28
Da es scheinbar nicht "den" Auslöser gibt, können wir nur durch solchen "Kleinscheiß" FHEM besser machen und im Endeffekt das Problem Beseitigen

Nach dem Motto: "Auch Kleinvieh macht Mist"

(Hinweis: Ist jetzt gegen keinen Böse gemeint, sondern eher eine positive Aussage!)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Christoph Morrison am 04 Februar 2019, 21:35:21
Aktuell teste ich mit Test::LeakTrace::Script um eine genauere Aussage zu bekommen, wo die Leaks geschehen. Leider gestaltet sich selbst der Start von FHEM dann sehr sehr zäh. Hat jemand schon mal mit LeakTrace gearbeitet?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 19 Februar 2019, 17:08:16
Gibts schon irgendwas neues ???
Die Lösung mit dem Automatischen Reboot alle paar Tage ist sehr unbefriedigend. Ich weiß nicht wo ich nun ansetzten soll.
Neu aufsetzten ? Aber mit welchem Image nun ?
Ich hab keine Lust die ganze Arbeit umsonst zu machen.
Mit dem Stück für Stück deinstallieren von Modulen in meinem sehr umfangreichen Life System hab ich auch so meine Probleme. Wo soll ich anfangen? Und ausserdem greift doch alles irgendwie in einander.

Hmm Ratlos....
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: yamaha1983 am 25 Februar 2019, 14:44:39
einfach wie ich zuvor beschrieben habe, eine ältere Version einsetzen, bis das Problem gelöst wurde.

Grüße,
yamaha1983
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 01 März 2019, 21:57:42
Hallo,
ich bin jetzt auch dabei auf per v5.20.3 umzusteigen. Mit perlbrew hat das auf das Kompilieren von mysql hat das auch soweit funktioniert.  Sobald ich mysql über cpan -T DBD::mysql DBD::MariaDB Kompilieren wird das mit einem Fehler beendet: "  /opt/perlbrew/perls/perl-5.20.3/bin/perl Makefile.PL -- NOT OK". Mit hilfe von Google komme ich auch nihct so richtig weiter.....

root@thorsten:/home/thorsten# cpan DBD::mysql DBD::MariaDB
Reading '/root/.cpan/Metadata'
  Database was generated on Fri, 01 Mar 2019 16:41:03 GMT
Running install for module 'DBD::mysql'
Checksum for /root/.cpan/sources/authors/id/D/DV/DVEEDEN/DBD-mysql-4.050.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring D/DV/DVEEDEN/DBD-mysql-4.050.tar.gz with Makefile.PL
Can't exec "mysql_config": Datei oder Verzeichnis nicht gefunden at Makefile.PL line 89.

Cannot find the file 'mysql_config'! Your execution PATH doesn't seem
not contain the path to mysql_config. Resorting to guessed values!


PLEASE NOTE:

For 'make test' to run properly, you must ensure that the
database user 'root' can connect to your MySQL server
and has the proper privileges that these tests require such
as 'drop table', 'create table', 'drop procedure', 'create procedure'
as well as others.

mysql> grant all privileges on test.* to 'root'@'localhost' identified by 's3kr1t';

You can also optionally set the user to run 'make test' with:

perl Makefile.PL --testuser=username

Can't exec "mysql_config": Datei oder Verzeichnis nicht gefunden at Makefile.PL line 603.
Can't find mysql_config. Use --mysql_config option to specify where mysql_config is located
Failed to determine directory of mysql.h. Use

  perl Makefile.PL --cflags=-I<dir>

to set this directory. For details see DBD::mysql::INSTALL,
section "C Compiler flags" or type

  perl Makefile.PL --help
Warning: No success on command[/opt/perlbrew/perls/perl-5.20.3/bin/perl Makefile.PL]
  DVEEDEN/DBD-mysql-4.050.tar.gz
  /opt/perlbrew/perls/perl-5.20.3/bin/perl Makefile.PL -- NOT OK
Running install for module 'DBD::MariaDB'
Checksum for /root/.cpan/sources/authors/id/P/PA/PALI/DBD-MariaDB-1.21.tar.gz ok
Configuring P/PA/PALI/DBD-MariaDB-1.21.tar.gz with Makefile.PL


PLEASE NOTE:

For 'make test' to run properly, you must ensure that the
database user 'root' can connect to your MariaDB or MySQL server
and has the proper privileges that these tests require such
as 'drop table', 'create table', 'drop procedure', 'create procedure'
as well as others.

mysql> grant all privileges on test.* to 'root'@'localhost' identified by 's3kr1t';

You can also optionally set the user to run 'make test' with:

perl Makefile.PL --testuser=username

I will use the following settings for compiling and testing:

  cflags       (mysql_config) = -I/usr/include/mariadb -I/usr/include/mariadb/mysql
  libs         (mysql_config) = -L/usr/lib/x86_64-linux-gnu/ -lmariadb -lz -ldl -lm -lpthread -lssl -lcrypto
  mysql_config (guessed     ) = mariadb_config
  testdb       (default     ) = test
  testhost     (default     ) =
  testpassword (default     ) =
  testport     (default     ) =
  testsocket   (default     ) =
  testuser     (guessed     ) = root

To change these settings, see 'perl Makefile.PL --help' and
'perldoc DBD::MariaDB::INSTALL'.

Checking if libs and header files are available for compiling...
Can't link/include C library 'z', aborting.
Warning: No success on command[/opt/perlbrew/perls/perl-5.20.3/bin/perl Makefile.PL]
  PALI/DBD-MariaDB-1.21.tar.gz
  /opt/perlbrew/perls/perl-5.20.3/bin/perl Makefile.PL -- NOT OK


vielen dank schonmal für die Hilfe :-)

Gruß

Thorsten

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 01 März 2019, 22:36:11
Hallo,

habe es jetzt hin bekommen. Das hat gefehlt:

sudo apt install libmysqlclient-dev



Gruß

Thorsten
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 02 März 2019, 07:52:22
Hallo,

Bei mir ist mit Perl v5.20.3 auch kein Speicheranstieg mehr zu erkennen.
Jedoch bekomme ich folgende Pakete nicht zum laufen:
Pushbullet, Pushover und HTTP mod (XML Datei auslesen)

Die Module WWW::Pushbullet IO::Socket::SSL habe ich hinzugefügt...

Vielleicht kann mir ja jemand helfen...


Gruß

Thorsten
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 02 März 2019, 12:03:05
ZitatJedoch bekomme ich folgende Pakete nicht zum laufen:
Vmtl. koennte man helfen, wenn man mehr Details (Fehlermeldungen, FHEM-Log, etc) sehen wuerde.
Allerdings wird das Off-Topic, bitte dafuer ein neues Thema anfangen.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: yamaha1983 am 06 März 2019, 11:02:51
Zitat von: jailbreaker07 am 02 März 2019, 07:52:22
Hallo,

Bei mir ist mit Perl v5.20.3 auch kein Speicheranstieg mehr zu erkennen.
Jedoch bekomme ich folgende Pakete nicht zum laufen:
Pushbullet, Pushover und HTTP mod (XML Datei auslesen)

Die Module WWW::Pushbullet IO::Socket::SSL habe ich hinzugefügt...

Vielleicht kann mir ja jemand helfen...


Gruß

Thorsten

HTTPmod läuft bei mir aber mit altem Perl. Sicher fehlt dir ein Modul. Schau dir das Log an, da solltest du den Hinweis finden.

Grüße,
yamaha1983
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 21 März 2019, 13:50:53
Zitat von: jailbreaker07 am 01 März 2019, 22:36:11
sudo apt install libmysqlclient-dev

@jailbreaker07
Das war der wichtigste Hinweis der meiner Verzweiflung endlich ein Ende gesetzt hat.
Eine kleine Ergänzung habe ich dazu noch:
bei Raspbian Stretch fehlt das Paket in der Quelle, daher muss die Sources.list kurzzeitig zu Jessie geändert werden (und danach wieder zurück zu Stretch).


Also folgendes Vorgehen:

sicherstellen das man das Perl von Perlbrew aktiv ist

dann die Sources-list öffnen:

nano /etc/apt/sources.list


folgende Zeile mit # auskommentieren:

deb http://raspbian.raspberrypi.org/raspbian/ stretch main contrib non-free rpi


und folgende hinzufügen:

deb http://raspbian.raspberrypi.org/raspbian/ jessie main contrib non-free rpi


danach


sudo apt-get update

sudo apt-get install libmysqlclient-dev

cpan DBD::mysql DBD::MariaDB


WICHTIG!!!! nach der Installation sofort die Sources-Änderung wieder rückgängig machen

folgende Zeile muss dazu in der Sources.list  mit # auskommentiert, oder gelöscht werden:


deb http://raspbian.raspberrypi.org/raspbian/ jessie main contrib non-free rpi


danach die ursprüngliche Stretch Quelle wieder aktivieren (# entfernen)

deb http://raspbian.raspberrypi.org/raspbian/ stretch main contrib non-free rpi


und nur noch

sudo apt-get update


fertig.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 21 März 2019, 15:21:06
äääääähhhhhh ... mal eben die Sources eine Produktivsystemes auf eine andere Distri setzen .... ... böse .....

Es kann Dir bei so etwas immer passieren, das anschließpend Dein System nicht mehr funktioniert!

ich hoffe, Du hast es wenigstens wieder zurückgeändert?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 22 März 2019, 01:12:56
Steht doch da, "Danach die Sourcesänderung wieder rückgängig machen",
ich habe jetzt mal den Text etwas besser strukturiert und den hinweis hervorgehoben.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 26 März 2019, 19:54:54
So, ich hab mich nun mal beigesetzt und auf einem Rasperry3 den ich hier noch nutzlos hatte ein frisches DietPi Image aufzuspielen.

Dieses kommt aber mit Perl Version 5.24.1

Mit dieser Version wird mir dann sicherlich das selbe Ram Leck ärger bereiten.

Wie kann ich denn nun auf Perl 5.20.3 downgraden ??
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 26 März 2019, 19:59:59
Muss nicht sein...

Ich habe Perl 5.20.2 und 5.20.3 probiert und trotzdem tritt das Leck auf :-(

Bin momentan auf Raspbian Jessie unterwegs...

Tja...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nighthawk am 27 März 2019, 03:09:49
Wie man auf 5.20.3 wechselt ist unter Anderem im Post #379 sehr detailiert beschrieben.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Timo_FHEM am 27 März 2019, 20:36:36
Hallo zusammen,

ich habe das Problem auch sporadisch. Ich bekomme bevor der Fehler "Cannot fork" auftritt im Log immer diese Einträge:


2019.03.26 00:00:33 1: [YAAHM_updater] on device Status called for this day
2019.03.26 03:53:06 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 03:59:06 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3635.
2019.03.26 03:59:06 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:01:06 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:03:06 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:04:06 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:06:07 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3635.
2019.03.26 04:06:07 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:12:07 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:13:07 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:14:07 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3635.
2019.03.26 04:14:07 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:15:07 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:15:07 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:16:07 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.03.26 04:16:07 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:16:07 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:17:07 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.03.26 04:17:07 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:17:07 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:18:07 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3516.
2019.03.26 04:18:07 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.03.26 04:18:07 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:18:07 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:19:07 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:19:07 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:21:07 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:21:07 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:22:08 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:23:07 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:24:08 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:24:08 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:26:08 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:27:07 1: PERL WARNING: Use of uninitialized value $val in int at ./FHEM/42_SYSMON.pm line 1765.
2019.03.26 04:27:07 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3516.
2019.03.26 04:27:07 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.03.26 04:27:07 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:27:07 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:28:08 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:30:08 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:30:08 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:32:08 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:33:08 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3635.
2019.03.26 04:33:08 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:36:08 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:37:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:40:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:42:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:43:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:44:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:45:09 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3635.
2019.03.26 04:45:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:48:08 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3516.
2019.03.26 04:48:08 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.03.26 04:48:08 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:48:08 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:49:09 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.03.26 04:49:09 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 04:49:09 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 04:51:09 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3635.
2019.03.26 04:51:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:52:09 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3635.
2019.03.26 04:52:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 04:53:09 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3635.
2019.03.26 04:53:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2867.
2019.03.26 05:01:10 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.03.26 05:01:10 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 05:01:10 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 05:02:10 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.03.26 05:02:10 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 05:02:10 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 05:03:09 1: PERL WARNING: Use of uninitialized value $val in int at ./FHEM/42_SYSMON.pm line 1765.
2019.03.26 05:03:10 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3516.
2019.03.26 05:03:10 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 05:03:10 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.03.26 05:04:10 1: PERL WARNING: Use of uninitialized value $val in int at ./FHEM/42_SYSMON.pm line 1765.
2019.03.26 05:04:10 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3516.
2019.03.26 05:04:10 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.03.26 05:04:10 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.03.26 05:04:10 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.


Die nächste Meldung ist dann Cannot fork: Cannot allocate memory:

2019.03.26 05:04:10 1: Cannot fork: Cannot allocate memory
2019.03.26 05:04:10 1: Cannot fork: Cannot allocate memory
2019.03.26 05:04:10 1: in CANNOT_FORK
2019.03.26 05:04:10 1: in CANNOT_FORK
2019.03.26 05:04:10 1: Server shutdown delayed due to alexa for max 10 sec
2019.03.26 05:04:13 1: in SHUTDOWN
2019.03.26 05:04:13 1: in SHUTDOWN
2019.03.26 05:04:13 0: Server shutdown
2019.03.26 05:04:16 1: PERL WARNING: "my" variable $sleepId masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 114.
2019.03.26 05:04:16 1: Including fhem.cfg
2019.03.26 05:04:27 1: [Alarm_Define] data hash restored from save file with date 2018-12-14 21:20:12
2019.03.26 05:04:32 1: PERL WARNING: Subroutine YAAHM_restore redefined at ./FHEM/95_YAAHM.pm line 980, <$fh> line 957.
2019.03.26 05:04:32 1: PERL WARNING: Subroutine YAAHM_setWeeklyTime redefined at ./FHEM/95_YAAHM.pm line 1813, <$fh> line 957.
2019.03.26 05:04:32 1: [YAAHM_Define] data hash restored from save file with date 2019-02-15 19:36:01
2019.03.26 05:04:32 1: [YAAHM] does not find an Astro device, loading module Astro separately
2019.03.26 05:04:33 1: Including ./log/fhem.save
2019.03.26 05:04:35 1: in INITIALIZED
2019.03.26 05:04:35 1: in INITIALIZED
2019.03.26 05:04:36 1: usb create starting
2019.03.26 05:04:37 1: usb create end
2019.03.26 05:04:37 0: Featurelevel: 5.9
2019.03.26 05:04:37 0: Server started with 134 defined entities (fhem.pl:18343/2019-01-20 perl:5.024001 os:linux user:fhem pid:19813)
2019.03.26 05:04:38 1: in DEFINED
2019.03.26 05:04:38 1: in DEFINED
2019.03.26 05:04:38 1: in ATTR
2019.03.26 05:04:38 1: in ATTR
2019.03.26 05:04:39 1: in MODIFIED
2019.03.26 05:04:39 1: in MODIFIED
2019.03.26 05:04:39 1: in MODIFIED
2019.03.26 05:04:39 1: in MODIFIED
2019.03.26 05:04:53 1: PERL WARNING: Odd number of elements in hash assignment at ./FHEM/98_Modbus.pm line 4861.
2019.03.26 05:04:53 1: [YAAHM_updater] on device Status called for this day
2019.03.26 05:04:53 1: PERL WARNING: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 269.
2019.03.26 05:04:53 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1837.
2019.03.26 05:04:53 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1857.
2019.03.26 05:10:00 1: PERL WARNING: Use of uninitialized value $mval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1140.
2019.03.26 05:10:00 1: PERL WARNING: Use of uninitialized value $nval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1141.
2019.03.26 05:10:00 1: PERL WARNING: Use of uninitialized value $tval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1142.
2019.03.26 05:10:00 1: PERL WARNING: Use of uninitialized value $mval in numeric ge (>=) at ./FHEM/95_YAAHM.pm line 1145.
2019.03.26 05:10:00 1: PERL WARNING: Use of uninitialized value $nval in numeric gt (>) at ./FHEM/95_YAAHM.pm line 1145.
2019.03.26 05:10:01 1: PERL WARNING: Use of uninitialized value $xval in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1267.
2019.03.26 05:10:01 1: PERL WARNING: Use of uninitialized value $xval in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1269.
2019.03.26 05:10:01 1: [YAAHM_time] executing
2019.03.26 05:10:01 1: PERL WARNING: Use of uninitialized value $cmd in pattern match (m//) at fhem.pl line 1051.


Kann jemand damit was anfangen?
Kann das ein Problem im Modul 42_SYSMON sein?

Ein Bild des Plots hab ich angehängt.

Danke und Gruß
Timo
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wondermusic am 04 April 2019, 12:22:45
Das muss nicht unbedingt sein... Bei mir läuft es ohne Probleme.
Aber ich hatte vor einigen Tagen eine ähnliche Meldung in der auch sysmon in ähnlicher Weise vorgekommen ist (zu dem Zeitpunkt musste ich FHEM 2 mal am Tag neustarten).

Aber an einem anderen Punkt hier in der Diskussion wurde gesagt, ein Modul nach dem anderen mal rauszunehmen.
Glücklicherweise brauchte ich nicht lange suchen, denn ich hatte vor einigen Tagen hier einen Threat bzgl. eines ewig andauernen Freeze bei fhem aufgemacht. Nachdem ich zu diesem Zwecke Freezemon aktiviert hatte konnte ich den Fehler ausmachen der zu den freezes geführt hat. Freezemon hatte ich danach deaktiviert.
Aber ca. zu diesem Zeitpunkt fingen die "Cannot Fork"- Probleme an - also ständig anwachsender RAM- verbrauch. Daher habe ich das Modul aus dem fhem Verzeichnis genommen und unter contrib abgelegt.
Seitdem läuft der RPi3 mit konstant 13% +/- 1% Speicherbelastung durch.

Gruß,
Richy
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 06 April 2019, 19:54:11
Schade, ich habe  voller Hoffnung das Freezemon auch aus dem Fhem Ordner in den contrip Ordner  verschoben. Leider steigt mein Ram immer noch genauso an.
Ich bin echt ratlos. Ich hab schon ein frisches Fhem auf einem frischen rasperry 3 den ich hier noch hatte aufgesetzt. Leider startet dieses Fhem nicht durch wenn ich meine fehm.cfg einfüge. Wie könnte ich den nun einkreisen welches Modul der Täter ist. Wobei ich doch schon gelesen habe dass es sich nicht mal um nur ein Modul handeln könnte. Den Fehler findet man doch nie.
Mich ärgert es masslos das alles jahrelang gut lief, und nun plötzlich das System kaum noch zu gebrauchen ist. Ich kann doch nicht alles von vorne neu programmieren.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 07 April 2019, 09:23:45
ZitatWobei ich doch schon gelesen habe dass es sich nicht mal um nur ein Modul handeln könnte. Den Fehler findet man doch nie.
Sicher doch: ein Modul nach dem anderen abschalten, und Verbrauch jeweils vorher/nachher protokollieren.
Verwendest du perl 5.24? Wenn ja, bitte eine andere Version (vorzugsweise 5.20, da getestet) einsetzen, da 5.24 bekanntermassen ein Speicherloch hat.
Ich habe auch RPi Bibliotheken in Verdacht: womoeglich laesst sich diese Theorie belegen, indem man den Speicherverbraucht auf einem x86 PC prueft.

ZitatMich ärgert es masslos das alles jahrelang gut lief, und nun plötzlich das System kaum noch zu gebrauchen ist. Ich kann doch nicht alles von vorne neu programmieren.
Ich kann dein Aerger nachvollziehen, allerdings koennen wir (Entwickler) daran mangels neuer Ideen oder genauere Infos (wo es auftritt) nicht weiterhelfen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 07 April 2019, 19:51:06
Zitat von: rudolfkoenig am 07 April 2019, 09:23:45
Sicher doch: ein Modul nach dem anderen abschalten, und Verbrauch jeweils vorher/nachher protokollieren.
Verwendest du perl 5.24? Wenn ja, bitte eine andere Version (vorzugsweise 5.20, da getestet) einsetzen, da 5.24 bekanntermassen ein Speicherloch hat.
Ich habe auch RPi Bibliotheken in Verdacht: womoeglich laesst sich diese Theorie belegen, indem man den Speicherverbraucht auf einem x86 PC prueft.
Ich kann dein Aerger nachvollziehen, allerdings koennen wir (Entwickler) daran mangels neuer Ideen oder genauere Infos (wo es auftritt) nicht weiterhelfen.

Selbst auf einem X86 PC unter Windows ist der Bug mit Ver. 5.24 (Active Perl) reproduzierbar.

Ich konnte es mit der alten DOIF-Version jederzeit nachstellen. Die neue DOIF-Version umgeht bestimmte Regex-Abfragen, die zum Speicherverbrauch führten. Damit ist das Speicherproblem in Kombination mit DOIF mit der Version 5.24 weitgehend ausgemerzt.

Zu anderen Modulen kann ich natürlich keine Aussage machen.

Auf jeden Fall ist die Version 5.24 zu meiden, leider ist das die aktuelle Version beim Raspi.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 07 April 2019, 20:11:48
Und leider ist 5.24 auch die aktuelle Version von ActivePerl auf dem Synology NAS - Die auslagerung die FHEM hier bei mir in den Arbeitsspeicher legt wird problemlos bis zu 4GB groß - ab da wird FHEM träge, ich merke das am Webinterface...
Nach einem FHEM neustart ist dann alles wieder schick - für die nächsten 5 Tage...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 08 April 2019, 20:17:17
Ok, ich würde mich dann mal an die Arbeit machen. Glücklicherweise läuft mein Live System noch auf Perl 5.20.2.  Aber wie kann ich nun in meinem Live System ein Modul nach dem anderen ausschalten ohne das gleich alles zusammenbricht? Soll ich eine Moduldatei nach der anderen aus dem Fhem Verzeichnis nehmen und dann die Fehlermeldungen im Log ignorieren und die Funktionsstörungen ?

Oder meint Ihr mit abschalten eine define nach der anderen auf disable zu setzten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 08 April 2019, 21:05:44
Das Attribut disable  (wenn es ueberhaupt implementiert ist) arbeitet bei jedem Modul anders.
Ich wuerde die defines entfernen, aber Moduldatei entfernen (und Fehlermeldungen ignorieren) geht auch.
Wichtig: Methodisch vorgehen, bei jedem Versuch notieren, was entfern wurde und Verbrauch aufzeichnen.
Und vorher natuerlich alles sichern.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 09 April 2019, 08:04:23
Wobei beiu solchen radikalen Ansätzen ich empfehlen würde, mal im ausgeschalteten Zustand (FHEM) den Ordner /opt/fhem zu kopieren. So ist ein "wieder anfahren" einfacher möglich.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 09 April 2019, 09:20:52
Ohne jetzt einem bestimmten Modul "Schuld" geben zu wollen aber ich fahre grad den Ansatz:

Test-System (wild installiert und eine Spielwiese für alles): ja klar Speicheranstieg. Es läuft so gut 1-2 Wochen bevor es dann eng wird

Pre-Aktiv-System (sauber installiert und hier "wandern" erst mal die Module vom Test-System die ich für das Aktiv-System gerne haben würde): Speicheranstieg erst seit echodevice Modul. Nicht schlimm (läuft ja wenig in Summe) aber deutlich erkennbar.

Aktiv-System: leider auch hier Speicheranstieg. Läuft aber problemlos 1 Monat und länger. Meistens habe ich da dann etwas optimiert und starte eh mal durch. Kann also damit leben und fange dort jetzt nicht mit dem Deaktivieren einzelner Module an, um das (weiter) zu entspannen. Hier fahre ich eher die Strategie: keine Module aufzunehmen, die auf dem Pre-Aktiv-System "Probleme" gezeigt haben...



Also auf dem Test-System wird alles was ich so finde mal ausprobiert und getestet.
Installations-Schwierigkeiten werden dort auch versucht "auszumerzen"...
...und notiert wie eine saubere Installation funktionieren sollte/müsste.
Wenn ich dann denke, dass ich das im Aktiv-System haben will, wird es auf das Pre-Aktiv-System eingespielt.
Hier wird dann getestet, ob die notierte Installation wirklich so geht ;)

Sorry, ich schweife ab...

Hierbei bin ich grad am Umziehen von alexa-fhem und dem echodevice...

alexa-fhem lief einige Monate ohne Auffälligkeiten bzgl. Speicher auf dem Pre-Aktiv-System.
Seit dem Umzug des echodevice-Moduls (vor so 2-3 Wochen) ging dann der Speicheranstieg auf meinem Pre-Aktiv-System los.
Neben dem echodevice Modul (mit so ca. 10+ Devices) habe ich noch weblink (current Artist etc.) "aktiviert".
Werde mal testen ob das echodevice oder weblink (oder eines der anderen "neuen" Module/Dinge) die "Probleme" verursacht...
...ist ja grad erst in die "Pre-Aktiv-Phase" gegangen ;)


Alles PI3 mit in etwa gleich aktuellem Stretch lite (letzte Aktualisierung zw. 6 und 2 Monaten) und perl 5.24.1

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: canis am 10 April 2019, 22:58:35
Hi,
Seit einem Update Ende März hatte ich auch das Problem.
Nach vielen Versuchen, alle möglichen Module zu deaktiviren, auch mySQL auszulagern, hat sich das Problem (zumindest bei mir) nach dem Lesen dieses Threads wie folgt lösen lassen:
- Das zuvor mit disable 1 gekennzeichnete freezmon aus der Konfiguration endgültig gelöscht
- Dar Modul 98_freezemon.pm von ./FHEM nach ./contrib verschoben
- attr global exclude_from_update 98_freezemon.pm ./FHEM/98_freezemon.pm zum ausschliessen der Rückspeicherung in fhem.cfg eingefügt
FHEM läuft nun ohne den Speicher zuzumüllen und ohne Swap zu benutzen mit ca. 337.79 MB Speicherbedarf,
allerdings (noch) mit externem mySQL.
P.S.: Nun wieder mit eigenem mySQL ohne Speicherprobleme, Speichernutzung konstant ca. 510 MB
Lerneffekt:
"attr xxx disable 1" deaktiviert das bezogene Modul nicht wirklich.
98_freezemon.pm ist wohl etwas buggy
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: yamaha1983 am 11 April 2019, 08:38:20
Noch ein kleiner Hinweis für alle perlbrew Nutzer, die auf Version perl-5.20.3 wechseln.

Solltet ihr immer noch memory leaks feststellen, dann bitte prüft nochmal, ob FHEM auch das richtige Perl nutzt.
Einfach in die Kommandozeile von fhem folgendes eingeben:

{`perl -v`}

Hier sollte dann folgende Meldung kommen

---
This is perl 5, version 20, subversion 3 (v5.20.3) built for armv7l-linux
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2015, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
---

Ansonsten ist euer FHEM Startskript nicht ok.

Grüße,
yamaha1983
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 11 April 2019, 12:19:17
Seit 03/2018 konnte ich dem Ausstieg von FHEM bedingt durch schleichenden RAM-Anstieg erfolgreich begegnen. (https://forum.fhem.de/index.php/topic,84372.msg784569.html#msg784569) Am 07.03.2019 und heute hatte ich ein neues Problem: der RAM-Verbrauch ist heute morgen um 06:08 innerhalb einer Minute von 250 auf 751 MB angestiegen, das Notify zum Neustart von FHEM triggert den shutdown / restart, aber es wird kein Arbeitsspeicher freigegeben. Selbst ein shutdown des RPi 3 mit anschließendem Neustart gibt den Arbeitsspeicher nicht mehr frei und FHEM wird permanent aufgrund des Notify neu gestartet.
2019-04-11_13:51:41 sysmon ram_used: 757.18
2019-04-11_13:50:30 sysmon ram_used: 757.18
2019-04-11_06:36:33 sysmon ram_used: 757.18
2019-04-11_06:35:17 sysmon ram_used: 757.18
2019-04-11_06:34:01 sysmon ram_used: 757.18
2019-04-11_06:32:45 sysmon ram_used: 757.18
2019-04-11_06:31:30 sysmon ram_used: 757.18
2019-04-11_06:27:28 sysmon ram_used: 757.18
2019-04-11_06:26:13 sysmon ram_used: 757.18
2019-04-11_06:24:57 sysmon ram_used: 757.18
2019-04-11_06:23:40 sysmon ram_used: 757.18
2019-04-11_06:18:38 sysmon ram_used: 757.18
2019-04-11_06:17:22 sysmon ram_used: 757.18
2019-04-11_06:16:07 sysmon ram_used: 757.18
2019-04-11_06:14:50 sysmon ram_used: 757.18
2019-04-11_06:13:33 sysmon ram_used: 757.18
2019-04-11_06:12:18 sysmon ram_used: 757.18
2019-04-11_06:10:59 sysmon ram_used: 757.18
2019-04-11_06:09:43 sysmon ram_used: 757.18
2019-04-11_06:08:26 sysmon ram_used: 757.18
2019-04-11_06:08:23 sysmon ram_used: 245.92
2019-04-11_06:07:21 sysmon ram_used: 245.92
2019-04-11_06:07:20 sysmon ram_used: 257.37
2019-04-11_06:06:18 sysmon ram_used: 257.37


Logfile (verbose 3) gibt noch nicht einmal "cannot fork ...". Im März 2019 hat erst das Beschreiben der SD-Karte mit einem gesicherten Image das Problem gelöst.
2019.04.11 06:08:32 1: Including fhem.cfg
2019.04.11 06:08:31 1: PERL WARNING: Subroutine getEmoji redefined at ./FHEM/99_myUtilsBlitzerSF.pm line 326.
2019.04.11 06:08:31 1: PERL WARNING: Subroutine getInfoBlitzer redefined at ./FHEM/99_myUtilsBlitzerSF.pm line 211.
2019.04.11 06:08:31 1: PERL WARNING: Subroutine checkHTTPMODBlitzer redefined at ./FHEM/99_myUtilsBlitzerSF.pm line 123.
2019.04.11 06:08:31 1: PERL WARNING: Subroutine getBlitzer redefined at ./FHEM/99_myUtilsBlitzerSF.pm line 27.
2019.04.11 06:08:31 1: PERL WARNING: Subroutine myUtilsBlitzer_Initialize redefined at ./FHEM/99_myUtilsBlitzerSF.pm line 15.
2019.04.11 06:08:28 0: Server shutdown
2019.04.11 06:08:28 1: sendEmail returned: Reading message body from STDIN because the '-m' option was not used.If you are manually typing in a message:  - First line must be received within 60 seconds.  - End manual input with a CTRL-D on its own line.Apr 11 06:08:27 fhemprod_rpi3 sendEmail[564]: Message input complete.Apr 11 06:08:28 fhemprod_rpi3 sendEmail[564]: Email was sent successfully!
2019.04.11 06:08:26 1: sendEmail Text:
2019.04.11 06:08:26 1: sendEmail Subject: RPi3 Produktiv wurde vom System neu gestartet
2019.04.11 06:08:26 1: sendEmail RCP: xxx@xxx.de
2019.04.11 06:04:47 3: Watchdog watchdog_Bad_ZW_off triggered

FHEM up time            : 7 days, 13 hours, 01 minutes
System up time          : 7 days, 13 hours, 02 minutes
2019.04.11 06:00:01 1: Date                    : 11.04.2019 06:00:01
2019.04.11 05:59:44 3: Watchdog watchdog_Abstell_aus triggered


free ergibt:

pi@FHEMProd_RPi3:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         949448       75576      669864       18244      204008      803688
Swap:        102396           0      102396
pi@FHEMProd_RPi3:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         949448      142132      600524       18244      206792      737092
Swap:        102396           0      102396
pi@FHEMProd_RPi3:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         949448      130896      611504       18244      207048      748316
Swap:        102396           0      102396
pi@FHEMProd_RPi3:~ $


Perl-Version ist 5.24.1

Hat jemand schon einmal ein ähnliches Problem gehabt und hätte einen Lösungsvorschlag?

Unabhängig davon werde ich über perlbrew auf die V5.20 gehen.

Stefan

edit: Auszüge Logfiles hinzugefügt
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: swsmily am 11 April 2019, 13:44:36
Zitat von: yamaha1983 am 11 April 2019, 08:38:20
Noch ein kleiner Hinweis für alle perlbrew Nutzer, die auf Version perl-5.20.3 wechseln.

Solltet ihr immer noch memory leaks feststellen, dann bitte prüft nochmal, ob FHEM auch das richtige Perl nutzt.
Einfach in die Kommandozeile von fhem folgendes eingeben:

{`perl -v`}

Hier sollte dann folgende Meldung kommen

---
This is perl 5, version 20, subversion 3 (v5.20.3) built for armv7l-linux
(with 1 registered patch, see perl -V for more detail)

Bei mir kommt
This is perl 5, version 20, subversion 2 (v5.20.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 103 registered patches, see perl -V for more detail)


Aber dennoch habe ich einen langsam aber stetigen Speicheranstieg. Nicht so extrem wie manche hier, die mehrfach am Tag neustarten müssen. Ich muss ca einmal pro Woche neustarten, bevor die "Cannot Fork"-Meldungen kommen.


Edit: Gerade noch bei meinem Bruder nachgesehen, bei ihm nutzt Fhem die Version (v5.24.1).
Aber ohne Speicherprobleme. Sein FHEM läuft bereits 75 Tage ohne Probleme durch.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 11 April 2019, 17:09:43
Alternativ schaut man ins FHEM-Log:
Zitat2019.04.11 17:10:23.251 0: Server started with 18 defined entities (fhem.pl:19085/2019-04-01 perl:5.028001 os:darwin user:rudi pid:35904)
5.028001 bedeutet perl 5.28.1
Titel: Problem mit perlbrew
Beitrag von: Brice am 16 April 2019, 17:57:34
Ich habe folgendes Problem:

SD-Karte mit einem Image des Produktivsystems bestückt. perlbrew nach dieser Anleitung aus Beitrag 334 (https://forum.fhem.de/index.php/topic,84372.msg861586.html#msg861586) installiert. Aufgrund der Meldung Please tell me where I can find your apache src Apache2 installiert.
Neustart von fhem ergibt wiederum
2019.04.14 21:20:42 2: FRITZBOX FritzBox: TR064_Init.4461 Cannot use TR-064. Perl modul Soap::Lite is missing on this system. Please install
ein apt-get install libsoap-lite-perl
ergibt
libsoap-lite-perl ist schon die neueste Version (1.20-1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.

Mit dem Befehl cpan force install SOAP::Lite
läuft Kompillieren durch, dennoch kommt 2019.04.16 16:08:30 2: FRITZBOX FritzBox: TR064_Init.4461 Cannot use TR-064. Perl modul Soap::Lite is missing on this system. Please install
Ich bin ratlos, habt ihr einen Tipp?

Die Module MBus und ZWave funktionieren auch nicht, aber darum würde ich mich später kümmern.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 17 April 2019, 20:51:53
Mit perlbrew installiert man eine weitere Version von perl, die Urspruengliche von der Distribution bleibt.
Mit apt-get installiert man Perl Module fuer diese "urspruengliche" Version.
Fuer die perlbrew Version kann man Module mit "cpan -i Soap::Lite" installieren, dabei muss cpan unbedingt aus dem "perlbrew" Verzeichnis stammen.


Howto-Perlbrew ist hier Off-Topic: bitte ein neues Thema aufmachen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 11 Juni 2019, 17:43:39
Zitat von: MadMax-FHEM am 09 April 2019, 09:20:52

alexa-fhem lief einige Monate ohne Auffälligkeiten bzgl. Speicher auf dem Pre-Aktiv-System.
Seit dem Umzug des echodevice-Moduls (vor so 2-3 Wochen) ging dann der Speicheranstieg auf meinem Pre-Aktiv-System los.
Neben dem echodevice Modul (mit so ca. 10+ Devices) habe ich noch weblink (current Artist etc.) "aktiviert".
Werde mal testen ob das echodevice oder weblink (oder eines der anderen "neuen" Module/Dinge) die "Probleme" verursacht...
...ist ja grad erst in die "Pre-Aktiv-Phase" gegangen ;)


Alles PI3 mit in etwa gleich aktuellem Stretch lite (letzte Aktualisierung zw. 6 und 2 Monaten) und perl 5.24.1

Gruß, Joachim

So, ich habe nun nach Wochenlanger suche das Schuldige Modul gefunden.
Bei mir ist definitiv Day echodevice Modul.

Ich habe reproduzierbar eine Speicherleck wenn ich eines meiner Echos anlege.
Ohne ist alles stabil.  Schade eigentlich, ich würde meine 4 Echos gerne einbinden.

Vielleicht kann der Entwickler ja was dazu sagen.

Danke an MadMax-FHEM für den Tipp,ich hätte sonst ewig gesucht.


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 11 Juni 2019, 18:50:26
Wenn man den und die anderen Threads bzgl. dieses Themas so liest, ist es vermutlich nicht das Modul...
...bzw. nicht das einzige Modul.

Es wird in dem Modul aber wohl etwas verwendet, das den Speicheranstieg hervorruft...

Konnte es auch zweifelsfrei wieder belegen: habe auf einem meiner Testsysteme das echodevice wieder gelöscht (also alle nat. ;)  ) und schon ist der Speicher wieder stabil...

Bei anderen Modulen konnte ich das so noch nicht nachvollziehen...
...werde aber weiterhin erst mal eine Weile auf meinem "Übergangs-System" testen und dann erst auf das Hauptsystem übernehmen...
...also bei positivem Test.

Solange bleibt das echodevice erst mal auf meinem Test-Test-System ;)

Aber vielleicht kann ja einer mit Ahnung mal drüber kucken, ob es Gemeinsamkeiten zwischen den "Verdächtigen" gibt.
Ich glaube bei DOIF war ja auch eine gewisse Reproduzierbarkeit...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: amenomade am 11 Juni 2019, 19:05:27
Ich kann bestätigen: ich hatte heute Nacht auch das "Cannot fork" Problem, und dieses Problem hatte ich bisher nie gehabt. Ich habe zwar vor kurzem andere Änderungen gemacht, hauptsächlich in notifies oder DOIFs... aber die grösste Änderung (im Sinn von neuen Modulen) war tatsächlich das echodevice.

EDIT: Log wenn Fhem sich verabschiedet hat:

2019.06.10 22:20:44 1: Cannot fork: Cannot allocate memory
Died at ./FHEM/37_echodevice.pm line 4561.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 11 Juni 2019, 19:06:49
Hallo Joachim,

auch bei mir gab es vor ca. einem Jahr den Speicheranstieg, ich bin dann dazu übergegangen, einen automatischen Neustart, bei zu wenig Speicher durchzuführen. Ich verwendete damals eigentlich keine "exotischen" (sorry) Module, nur einige Doifs und freezemon mit apptime. Ich bin dann wieder auf perfmon ohne apptime zurückgegangen und Damian hatte damals einige Änderungen am Doif gemacht und seit dieser Zeit beobachte ich keinerlei Speicheranstieg mehr bei mir.

Nachdem es doch viele User betrifft und eigentlich keine konkrete Ursache gefunden werden konnte, denke ich auch, es muss irgend etwas sein was diese Module gemeinsam verwenden. Deine Idee mit der Suche nach Gemeinsamkeiten, bei den bisher identifizierten Modulen, halte ich auch für Zielführend. Doch leider kann ich hier mangels Kenntnissen nichts dazu beitragen.

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 11 Juni 2019, 19:08:09
Kann es sein das das Modul echodevice nicht offiziell ist?
Habt ihr eure Erkenntnis dem Modulauthor mit geteilt?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: amenomade am 11 Juni 2019, 19:40:52
Ja, Du hast Recht Cooltux, das Modul ist noch nicht offiziell, und nicht über normales Update verteilt. Da es aber nicht immer einfach ist, genau auf einem einzigen Modul zu deuten, haben wir bisher gewartet ;)

Kann es sein, dass es bei der Erneuerung des Cookies passiert? Joachim, ich glaube, ich kann mich erinnern, dass Du auch die node Methode nutzt.

Bin am Denken, wie ich noch den Fehler weiter begrenzen könne.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: amenomade am 11 Juni 2019, 19:54:09
Habt ihr auch SYSMON in Betrieb?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 11 Juni 2019, 20:05:29
Hallo amenomade,

ja bei mir läuft es auf meinem Raspi seit einigen Monaten, ohne jegliche Auffälligkeiten.

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 11 Juni 2019, 21:37:04
Zitat von: amenomade am 11 Juni 2019, 19:54:09
Habt ihr auch SYSMON in Betrieb?

Nein, nicht mehr...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 11 Juni 2019, 21:41:12
Zitat von: Rewe2000 am 11 Juni 2019, 20:05:29
Hallo amenomade,

ja bei mir läuft es auf meinem Raspi seit einigen Monaten, ohne jegliche Auffälligkeiten.

Gruß Reinhard

Was ist es?
echodevice oder sysmon!? ;)

Welche Perl-Version und node-Version hast du?

Bei mir:

Perl v5.24.1

node v8.11.1

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 11 Juni 2019, 21:48:13
Ich habe keine Echo Device dinge in meiner Installation..
Bei mir könnte es auch SYSMON sein - ich deaktivier das mal, sehe dann aber auch nicht mehr den anstieg ;-)
Ich werd versuchen mir das nebenher mit htop anzuschauen. Oder hat jemand eine bessere Idee..?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 11 Juni 2019, 22:07:20
Hallo Joachim,

meinte natürlich sysmon.

Bei mir:
Perl:   5.24.1

Habe ich node oder nodejs überhaupt installiert?
Ich denke nein, den über SSH ergeben die Abfragen:
pi@raspberrypi:/usr/bin $ node -v
-bash: node: Kommando nicht gefunden.
pi@raspberrypi:/usr/bin $ nodejs -v
-bash: nodejs: Kommando nicht gefunden.

Wie ermittle ich die node Version, mach ich da einen Fehler?

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: amenomade am 11 Juni 2019, 22:09:54
Perl: 5.20.2
Node: 8.16.0
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 11 Juni 2019, 22:18:33
Zitat von: Rewe2000 am 11 Juni 2019, 22:07:20
Hallo Joachim,

meinte natürlich sysmon.

Bei mir:
Perl:   5.24.1

Habe ich node oder nodejs überhaupt installiert?
Ich denke nein, den über SSH ergeben die Abfragen:
pi@raspberrypi:/usr/bin $ node -v
-bash: node: Kommando nicht gefunden.
pi@raspberrypi:/usr/bin $ nodejs -v
-bash: nodejs: Kommando nicht gefunden.

Wie ermittle ich die node Version, mach ich da einen Fehler?

Gruß Reinhard

Nein, vermutlich kein Fehler, wenn du kein Modul hast, das node braucht ;)

Die Antwort wäre nur interessant gewesen, falls du auch das echodevice nutzt und das "ohne Auffälligkeiten"...

Ah, Sysmon...
War bei mir aber auch unauffällig bzgl. Speicher.
Aber da ich nur Temp. und Speicher wissen wollte frage ich das per Linux-Console ab...
...ohne Sysmon...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: amenomade am 11 Juni 2019, 22:57:40
Sysmon: ich habe deswegen gefragt, weil er angefangen hat, die Log mit Perl Warnings zu müllen, ungefähr gleichzeitig wie die erste Fehlermeldungen "Cannot fork". Aber das ist vielleicht eine Konsequenz.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 12 Juni 2019, 12:58:43
Also bei mir läuft Sysmon seit Monaten zum loggen des freien Speichers.

Perl v5.20.2
Node v8.15.1
Nodejs v8.15.1

Hier zwei typische Beispiel SVG´s des Speicherverbrauchs:



Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 12 Juni 2019, 13:31:14
Ich kann SYSMON jetzt wahrscheinlich auch ausschliessen - habe gestern Testweise entfernt.
Leider steigt der Speicherverbrauch weiterhin an...

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: frank am 12 Juni 2019, 13:57:02
Zitat von: frank am 30 Januar 2019, 11:19:37
moin,

ich habe zur zeit 2 verdächtige:

1. userreading mit modifier "integral"
attr Broetje userReadings hzgGas:hzgBrennerMod:.* integral {ReadingsVal($NAME,"hzgBrennerMod",0)}
2. event-aggregator mit function "integral"
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:
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

die 2 verdächtigen kann ich nun ausschliessen.

da ich quasi gleichzeitig mit dem löschen der verdächtigen funktionen auch jessie auf meinem pi aktualisiert (apt-get update / upgrade) hatte, wurde ich durch einen anderen verlauf der speicherauslastung getäuscht. die anstiege des genutzten speichers waren nach dem update seltener aber hatten grössere sprünge. es gab phasen, die über 1-2 tage keinen speicheranstieg erkennen liessen. auf dauer aber ein ähnlicher speicheranstieg, der weiterhin nach ca 14 tagen zur "cannot fork" meldung führte.

ein erneutes jessie update/upgrade vor ca 6 wochen hat mein speicherproblem nun deutlich verbessert. der speicherverlauf zeigt nun auch hin und wieder nennenswerte speicherfreigaben. dadurch hat sich die dauer von fhem restart bis zur ersten cannot-fork-message mehr als verdoppelt.

vielleicht probiert ihr auch mal ein update/upgrade.
die perl version zeigt allerdings immer noch 5.20.2.

gruss frank
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Christoph Morrison am 24 Juni 2019, 16:21:17
Raspbian kommt seit 20. Juni übrigens mit Debian Buster (und damit auch mit Perl 5.28.1).
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 24 Juni 2019, 18:44:36
Hallo,

die haben sich bestimmt verschrieben. Buster sollte wohl besser Bugster heißen.  ;)
Habe heute mein Testsytem gegen 17:00 upgegraded. Schaut euch den Plot im Anhang an ... ohne Worte.

Ich werde wohl noch etwas beobachten und dann restoren.

Grüße,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 24 Juni 2019, 20:21:47
Kurzes Update.
Nachdem sich der erste "Schreck" gelegt hat, habe ich noch etwas das Verhalten beobachtet.
Der RAM-Verbrauch scheint sich auf einem ca. 150 MB höheren Level (gegenüber Stretch) eingeschwungen zu haben.
Wobei das Verhalten recht volatil gegenüber der vorherigen Version ist. Auch eine höhere SWAP Nutzung ist sichtbar.
Ansonsten läuft FHEM ohne Klagen.

Naja, begeistert bin ich momentan nicht und werde weiter beobachten.Aber man sieht schon einen recht deutlichen Unterschied zwischen den beiden Debain Versionen bei sonst unveränderten Rahmenbedingungen.

EDIT: jetzt nach ca. 5 Stunden Laufzeit scheint sich das Bild zu manifestieren. Der RAM und SWAP Verbrauch ist insgesamt höher als mit Stretch, scheint sich aber auf diesem Niveau zu stabilisieren wobei ingesamt ein volatiler Eindruck verbleibt.
Zumindest bei meiner Installation.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hollo am 24 Juni 2019, 22:12:06
Zitat von: Christoph Morrison am 24 Juni 2019, 16:21:17
Raspbian kommt seit 20. Juni übrigens mit Debian Buster (und damit auch mit Perl 5.28.1).
Ist das mit der Perl-Version evtl. auch der Grund, warum die plötzlich auf Buster wechseln?
Buster soll doch eigentlich am 6.7. stable werden, die 3 Wochen wären ja absehbar.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Christoph Morrison am 24 Juni 2019, 22:24:45
Zitat von: Hollo am 24 Juni 2019, 22:12:06
Ist das mit der Perl-Version evtl. auch der Grund, warum die plötzlich auf Buster wechseln?
Buster soll doch eigentlich am 6.7. stable werden, die 3 Wochen wären ja absehbar.

Schätze eher dass es um die Hardwareunterstützung des Pi4 geht/ging.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: frank am 25 Juni 2019, 00:08:38
Zitat von: DS_Starter am 24 Juni 2019, 18:44:36
Habe heute mein Testsytem gegen 17:00 upgegraded. Schaut euch den Plot im Anhang an ... ohne Worte.
hast du dein vorhandenes stretch über apt/apt-get  "aufgebohrt" oder ein frisches buster aufgesetzt, wie raspberrypi.org es empfiehlt?
nach dem plot würde ich ersteres vermuten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 25 Juni 2019, 00:20:48
Hallo frank,

ich habe upgegradet. Habe eine Debian-VM, kein Raspberry.
Die Vorgehensweise ist hier -> https://linuxconfig.org/how-to-upgrade-debian-9-stretch-to-debian-10-buster bzw. hier https://www.debian.org/releases/buster/mips/release-notes/ch-upgrading.en.html

Grüße,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: frank am 25 Juni 2019, 00:24:43
ok, merci.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 25 Juni 2019, 15:52:06
Hallo zusammen,

so, das wars erstmal mit buster.
Nachdem ich weiterhin einen stetigen RAM-Anstieg verzeichnete, habe ich heute 13:00 wieder auf stretch restored.
Wie man auf dem Plot deutlich sieht, ist RAM und SWAP wieder so wie es sein soll.

Vielleicht versuche ich es später noch einmal und auch mit einer Neuinstallation, vorerst aber nicht.

Grüße,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 01 Juli 2019, 17:39:11
Ich hatte heute wieder einmal einen Totalausfall der Home-Automation ("zur Freude" der Family).
Inzwischen restarte ich die FHEM-Instanz 2x pro Tag. Aber in seltenen Fällen reicht nicht einmal das aus.

SystemInfo:
FHEM: Server started with 316 defined entities (fhem.pl:19719/2019-06-27 perl:5.024001 os:linux user:fhem pid:4854)
Raspberry mit Stretch und letztem Patch-Stand
Das System ist nicht wirklich unter Stress: top - 17:30:13 up  2:14,  1 user,  load average: 0.28, 0.26, 0.26
Die GUI (tabletUI) läuft auf einem anderen Device.


Im Logfile kommen immer wieder diese Meldungen von verschiedenen Modulen vor (hier nur ein Auszug)
Ich weiß nicht, ob das gehäufte Auftreten heute Morgen und der Memory-Verbrauch (siehe Grafik) in Zusammenhang stehen.

Vielleicht hat jemand einen Anhaltspunkt?


2019.07.01 06:47:40 1: PERL WARNING: Use of uninitialized value $hcitool in concatenation (.) or string at ./FHEM/73_PRESENCE.pm line 990.
2019.07.01 06:47:40 1: stacktrace:
2019.07.01 06:47:40 1:     main::__ANON__                      called by ./FHEM/73_PRESENCE.pm (990)
2019.07.01 06:47:40 1:     main::PRESENCE_DoLocalBluetoothScan called by FHEM/Blocking.pm (194)
2019.07.01 06:47:40 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 06:47:40 1:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (707)
2019.07.01 06:47:40 1:     main::PRESENCE_StartLocalScan       called by fhem.pl (3297)
2019.07.01 06:47:40 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 06:47:40 1: PERL WARNING: Use of uninitialized value $hcitool in scalar chomp at ./FHEM/73_PRESENCE.pm line 991.
2019.07.01 06:47:40 1: stacktrace:
2019.07.01 06:47:40 1:     main::__ANON__                      called by ./FHEM/73_PRESENCE.pm (991)
2019.07.01 06:47:40 1:     main::PRESENCE_DoLocalBluetoothScan called by FHEM/Blocking.pm (194)
2019.07.01 06:47:40 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 06:47:40 1:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (707)
2019.07.01 06:47:40 1:     main::PRESENCE_StartLocalScan       called by fhem.pl (3297)
2019.07.01 06:47:40 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 06:47:40 1: PERL WARNING: Use of uninitialized value $hcitool in -x at ./FHEM/73_PRESENCE.pm line 993.
2019.07.01 06:47:40 1: stacktrace:
2019.07.01 06:47:40 1:     main::__ANON__                      called by ./FHEM/73_PRESENCE.pm (993)
2019.07.01 06:47:40 1:     main::PRESENCE_DoLocalBluetoothScan called by FHEM/Blocking.pm (194)
2019.07.01 06:47:40 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 06:47:40 1:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (707)
2019.07.01 06:47:40 1:     main::PRESENCE_StartLocalScan       called by fhem.pl (3297)
2019.07.01 06:47:40 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 06:47:40 2: PRESENCE (Handy_Thomas) - error while processing check: no hcitool binary found. Please check that the bluez-package is properly installed

Das Tool ist installiert und die die Handy-Überwachung funktioniert auch.
root@homecontrol:/opt/fhem/FHEM# which hcitool
/usr/bin/hcitool

2019.07.01 06:57:11 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4751.
2019.07.01 06:57:11 1: stacktrace:
2019.07.01 06:57:11 1:     main::__ANON__                      called by fhem.pl (4751)
2019.07.01 06:57:11 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/37_Spotify.pm (803)
2019.07.01 06:57:11 1:     main::Spotify_dispatch              called by FHEM/HttpUtils.pm (609)
2019.07.01 06:57:11 1:     main::__ANON__                      called by fhem.pl (745)
2019.07.01 06:57:11 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4751.
2019.07.01 06:57:11 1: stacktrace:
2019.07.01 06:57:11 1:     main::__ANON__                      called by fhem.pl (4751)
2019.07.01 06:57:11 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/37_Spotify.pm (805)
2019.07.01 06:57:11 1:     main::Spotify_dispatch              called by FHEM/HttpUtils.pm (609)
2019.07.01 06:57:11 1:     main::__ANON__                      called by fhem.pl (745)
2019.07.01 07:15:43 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3516.
2019.07.01 07:15:43 1: stacktrace:
2019.07.01 07:15:43 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (3515)
2019.07.01 07:15:43 1:     main::SYSMON_isCPUTempBBB           called by ./FHEM/42_SYSMON.pm (1209)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.07.01 07:15:43 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (194)
2019.07.01 07:15:43 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 07:15:43 1:     main::BlockingCall                  called by ./FHEM/42_SYSMON.pm (905)
2019.07.01 07:15:43 1:     main::SYSMON_Update                 called by fhem.pl (3297)
2019.07.01 07:15:43 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 07:15:43 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2186.
2019.07.01 07:15:43 1: stacktrace:
2019.07.01 07:15:43 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (2186)
2019.07.01 07:15:43 1:     main::SYSMON_getCPUProcStat         called by ./FHEM/42_SYSMON.pm (1230)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.07.01 07:15:43 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (194)
2019.07.01 07:15:43 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 07:15:43 1:     main::BlockingCall                  called by ./FHEM/42_SYSMON.pm (905)
2019.07.01 07:15:43 1:     main::SYSMON_Update                 called by fhem.pl (3297)
2019.07.01 07:15:43 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 07:15:43 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2268.
2019.07.01 07:15:43 1: stacktrace:
2019.07.01 07:15:43 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (2268)
2019.07.01 07:15:43 1:     main::SYSMON_getRamAndSwap          called by ./FHEM/42_SYSMON.pm (1255)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.07.01 07:15:43 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (194)
2019.07.01 07:15:43 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 07:15:43 1:     main::BlockingCall                  called by ./FHEM/42_SYSMON.pm (905)
2019.07.01 07:15:43 1:     main::SYSMON_Update                 called by fhem.pl (3297)
2019.07.01 07:15:43 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 07:15:43 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2269.
2019.07.01 07:15:43 1: stacktrace:
2019.07.01 07:15:43 1:     main::__ANON__                      called by ./FHEM/42_SYSMON.pm (2269)
2019.07.01 07:15:43 1:     main::SYSMON_getRamAndSwap          called by ./FHEM/42_SYSMON.pm (1255)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters_intern called by ./FHEM/42_SYSMON.pm (1129)
2019.07.01 07:15:43 1:     main::SYSMON_obtainParameters       called by ./FHEM/42_SYSMON.pm (956)
2019.07.01 07:15:43 1:     main::SYSMON_blockingCall           called by FHEM/Blocking.pm (194)
2019.07.01 07:15:43 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 07:15:43 1:     main::BlockingCall                  called by ./FHEM/42_SYSMON.pm (905)
2019.07.01 07:15:43 1:     main::SYSMON_Update                 called by fhem.pl (3297)
2019.07.01 07:15:43 1:     main::HandleTimeout                 called by fhem.pl (671)

2019.07.01 07:17:28 1: Cannot fork: Cannot allocate memory
2019.07.01 07:17:28 1: stacktrace:
2019.07.01 07:17:28 1:     main::fhemFork                      called by FHEM/Blocking.pm (172)
2019.07.01 07:17:28 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2019.07.01 07:17:28 1:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (707)
2019.07.01 07:17:28 1:     main::PRESENCE_StartLocalScan       called by fhem.pl (3297)
2019.07.01 07:17:28 1:     main::HandleTimeout                 called by fhem.pl (671)
2019.07.01 07:17:28 1: Cannot fork:
2019.07.01 07:17:28 1: Cannot fork: Cannot allocate memory

2019.07.01 17:19:19 1: stacktrace:
2019.07.01 17:19:19 1:     main::__ANON__                      called by fhem.pl (4751)
2019.07.01 17:19:19 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/37_Spotify.pm (803)
2019.07.01 17:19:19 1:     main::Spotify_dispatch              called by FHEM/HttpUtils.pm (609)
2019.07.01 17:19:19 1:     main::__ANON__                      called by fhem.pl (745)
2019.07.01 17:19:19 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4751.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 01 Juli 2019, 17:59:26
Setze mal im global Device das Attribut
blockingCallMax auf 6
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: maci am 05 Juli 2019, 07:41:27
Seit ca einer Woche hatte ich schon 2 mal das Problem mit dem Cannot allocate memory.

Zuvor ist das bei diesem System noch nie aufgetreten.
Ich habe sogar das notify das, das System neu starten soll, wenn das auftreten soll eingebaut. Es läuft schon mehre Monate.
Doch bei mir ist es immer so, dass sich einfach Fhem beendet und alles andere bleibt.
Hier eine Log Auszug:
2019.07.04 21:53:27 3: DbLog DBLogging: Reopen requested.
2019.07.04 21:53:27 3: DbLog DBLogging - Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2019.07.04 21:53:27 3: DbLog DBLogging - Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2019.07.04 21:53:27 3: DBLogging_Reopen: Reopen executed.
2019.07.04 21:53:33 3: DbLog DBLogging -> addLog created - TS: 2019-07-04 21:53:33, Device: Raspberry_Ventilator, Type: RPI_GPIO, Event: addLog, Reading: state, Value: on, Unit:
2019.07.04 21:53:33 3: SolarEdge: set interval changed interval to 60 seconds
2019.07.04 21:53:34 3: DbLog DBLogging -> addLog created - TS: 2019-07-04 21:53:34, Device: Schalter_Poolpumpe_Sw, Type: CUL_HM, Event: addLog, Reading: state, Value: off, Unit:
2019.07.04 21:53:45 3: wforecast: poll (FORECAST)
2019.07.04 21:53:45 3: netatmo_R70_ee_50_0c_06_84: poll (RELAY)
2019.07.04 21:53:45 3: netatmo_R70_ee_50_0c_06_84: requestThermostatReadings (70:ee:50:0c:06:84)
2019.07.04 21:53:57 1: Cannot fork: Cannot allocate memory
2019.07.04 21:53:57 1: Cannot fork: Cannot allocate memory
2019.07.04 21:53:58 0: Server shutdown
2019.07.04 21:53:58 2: DbLog DBLogging - waiting for shutdown 3 seconds ...
2019.07.04 21:54:01 2: DbLog DBLogging - continuing shutdown sequence
2019.07.04 21:54:01 1: [Freezemon] myFreezemon: Long function call detected ShutdownFn:DBLogging - 3.014468 seconds
2019.07.04 21:54:01 1: Shutdown executed
2019.07.04 21:54:01 1: Shutdown executed
2019.07.04 23:44:42 3: [UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)
2019.07.04 23:44:43 1: Including fhem.cfg
2019.07.04 23:44:43 3: WEB: port 8083 opened
2019.07.04 23:44:43 3: WEBtablet: port 8085 opened

um 23.44 habe ich meinen Raspberry neu gestartet.

Mein Raspberry läuft mit einer SSD und hat eingeschalteten Swap.

Wenn ich in Sysmon nach sehe, sehe ich dass der RAM Verbrauch stetig steigt.

Was mich etwas erstaunt, ist die Tatsache, dass dies erst jetzt auftritt und nicht schon früher.
Wobei ich am System nichts geändert habe. Weder ein Update noch sonst etwas.

Gruß Georg
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 05 Juli 2019, 08:29:31
Wenn ich mich nicht täusche macht der Speicherverbrauch einen Sprung wenn im Logfile dieses Fehlermuster auftritt:

2019.07.05 06:47:37 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4751.
2019.07.05 06:47:37 1: stacktrace:
2019.07.05 06:47:37 1:     main::__ANON__                      called by fhem.pl (4751)
2019.07.05 06:47:37 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/37_Spotify.pm (803)
2019.07.05 06:47:37 1:     main::Spotify_dispatch              called by FHEM/HttpUtils.pm (609)
2019.07.05 06:47:37 1:     main::__ANON__                      called by fhem.pl (745)
2019.07.05 06:47:37 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4751.
2019.07.05 06:47:37 1: stacktrace:
2019.07.05 06:47:37 1:     main::__ANON__                      called by fhem.pl (4751)
2019.07.05 06:47:37 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/37_Spotify.pm (805)
2019.07.05 06:47:37 1:     main::Spotify_dispatch              called by FHEM/HttpUtils.pm (609)
2019.07.05 06:47:37 1:     main::__ANON__                      called by fhem.pl (745)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 05 Juli 2019, 08:45:40
@maci: _dass_ es ein Problem gibt, will hier keiner bestreiten, ich bin sogar der Meinung, dass mehrere Ursachen gibt. Ich habe das Problem aber nicht (wie die Mehrheit der FHEM-Benutzer auch nicht), kann es nicht nachstellen, und weiss auch nicht, woran das liegt. Bisher haben wir nur einen sinnvollen Vorschlag, das Problem einzugrenzen: alle Module einzeln nach und nach abzuschalten, bis ein Problem-Modul gefunden wird. Leider ist das bisher fuer alle Betroffenen unpraktikabel gewesen, deswegen haben wir auch kein Ergebnis.

@towag: die unmittelbare Ursache ist das Spotify Modul, das ein Reading auf undefined setzen will, weil es auf einem nicht existierenden Wert im JSON zugreift.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 05 Juli 2019, 09:41:32
könnte FHEM nicht z.b. einmal am Tag die Daten die im Arbeitsspeicher liegen ablöschen..?
Ich denke ja mittlerweile darüber nach täglich automatisch einen neustart zu machen...

Ich denke aber auch darüber nach FHEM auf eine Docker installation zu ändern, sodass nicht das ActivePerl der Synology NAS benutzt werden muss...

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 05 Juli 2019, 09:51:49
Zitat von: rudolfkoenig am 05 Juli 2019, 08:45:40
Bisher haben wir nur einen sinnvollen Vorschlag, das Problem einzugrenzen: alle Module einzeln nach und nach abzuschalten, bis ein Problem-Modul gefunden wird. Leider ist das bisher fuer alle Betroffenen unpraktikabel gewesen, deswegen haben wir auch kein Ergebnis.

Ich bin dabei es etwas andersrum zu machen ;)

Auf meinem Hauptsystem habe ich (glücklicherweise) auch kein/kaum ein Problem.
Speicher steigt zwar dort auch aber sooo langsam, dass ich gut damit leben kann.
1 Monat plus ist kein Problem.
Und das Notify mit autom. Restart hat dort erst 1x "zugeschlagen", ansonsten habe ich meist davor (wegen "irgendwas") gebootet/neu gestartet...


Ich habe 2 Testsysteme. Also eins zum ausprobieren von allen möglichen Dingen, das System ist (zugegebenermassen) daher schon reichlich "tot-installiert"...
Wenn ich etwas für sinnvoll erachte kommt es erst mal auf mein 2tes Testsystem, das ist eigentlich sehr sauber installiert, da wird eben getestet, ob meine "Installations-Notizen" richtig sind/waren.
Dann läuft es dort eine Weile, um zu sehen, ob "Auffälligkeiten" zu beobachten sind...

Und erst dann geht es auf das Hauptsystem (also nat. nur, wenn nichts aufgefallen ist ;)  )...

Hier habe ich bzgl. des echodevice-Moduls etwas geschrieben:
https://forum.fhem.de/index.php/topic,84372.msg928468.html#msg928468

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 05 Juli 2019, 09:54:54
Zitat von: der-Lolo am 05 Juli 2019, 09:41:32
könnte FHEM nicht z.b. einmal am Tag die Daten die im Arbeitsspeicher liegen ablöschen..?

Sollte ja passieren, aber der Fehler steckt wohl "in" Perl selbst (also einer oder mehrerer Libs) und daher wird das wohl nicht gehen...
Ansonsten wäre ja komplett ablöschen sowas wie ein "interner Neustart", da kann man auch gleich selbst neu starten...

Zitat von: der-Lolo am 05 Juli 2019, 09:41:32
Ich denke ja mittlerweile darüber nach täglich automatisch einen neustart zu machen...

Das macht das Notify doch im Bedarfsfall automatisch...

Zitat von: der-Lolo am 05 Juli 2019, 09:41:32
Ich denke aber auch darüber nach FHEM auf eine Docker installation zu ändern, sodass nicht das ActivePerl der Synology NAS benutzt werden muss...

Andere Perl-Version: neues Glück (oder auch nicht ;)  )...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: maci am 05 Juli 2019, 10:25:55
Zitat von: MadMax-FHEM am 05 Juli 2019, 09:54:54
Sollte ja passieren, aber der Fehler steckt wohl "in" Perl selbst (also einer oder mehrerer Libs) und daher wird das wohl nicht gehen...
Ansonsten wäre ja komplett ablöschen sowas wie ein "interner Neustart", da kann man auch gleich selbst neu starten...

Das macht das Notify doch im Bedarfsfall automatisch...

Andere Perl-Version: neues Glück (oder auch nicht ;)  )...

Gruß, Joachim

Ich habe schon angefangen mich in Docker einzuarbeiten.
Mein Dell Wyse (AMD 4kern, 4GB, 32GB) ist schon in Betrieb mit Ubuntu Server 18.04
Braucht derzeit ca. 7,8 - 8,5 Watt an Strom. Siehe: https://forum.fhem.de/index.php/topic,99124.0.html (https://forum.fhem.de/index.php/topic,99124.0.html)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 05 Juli 2019, 11:11:31
Ich habe ein DOIF gebastelt - welches mir bei RAM Nutzung > 2GB eine Message via Telegram schicken soll.
Nun ist es aber leider so das der Trigger oft ausbleibt wenn FHEM nicht in einem Browser geöffnet ist...
Wenn ich dann größer 2GB habe und FHEMWEB in einem Browser öffne triggert auch das DOIF -
keine ahnung warum das nicht vernünftig funktioniert, das gehört hier aber auch nicht her.

Ich habe jedenfalls keinen Ram Auslastung zuhoch Trigger der zuverlässig unattended kommt...

ein list des DOIFs
Internals:
   DEF        ([DS716:ram:"Used: (\d+)"] > 2000) (msg push @rr_Michael Ram Auslastung angestiegen Neustart von FHEM ausführen)
DOELSEIF ([$SELF:cmd] eq "1" and [Eichenheim_Bot:msgText] eq "restart") (shutdown restart)
DOELSE()

   FUUID      5d09cb44-f33f-68f5-c05b-95f6255d629b4e15
   MODEL      FHEM
   NAME       RAMmsgAdjust
   NR         202
   NTFY_ORDER 50-RAMmsgAdjust
   STATE      cmd_3
   TYPE       DOIF
   VERSION    19303 2019-05-01 08:47:16
   READINGS:
     2019-07-05 11:06:35   Device          DS716
     2019-06-29 12:16:26   cmd             3
     2019-06-29 12:16:26   cmd_event       DS716
     2019-06-29 12:16:26   cmd_nr          3
     2019-07-05 11:06:35   e_DS716_ram     Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     2019-06-20 17:19:26   e_Eichenheim_Bot_msgText zu
     2019-06-19 07:42:28   mode            enabled
     2019-06-29 12:16:26   state           cmd_3
   Regex:
     accu:
   attr:
     waitdel:
   condition:
     0          ::ReadingValDoIf($hash,'DS716','ram','','Used: (\d+)') > 2000
     1          ::ReadingValDoIf($hash,'RAMmsgAdjust','cmd') eq "1" and ::ReadingValDoIf($hash,'Eichenheim_Bot','msgText') eq "restart"
   devices:
     0           DS716
     1           RAMmsgAdjust Eichenheim_Bot
     all         DS716 RAMmsgAdjust Eichenheim_Bot
   do:
     0:
       0          msg push @rr_Michael Ram Auslastung angestiegen Neustart von FHEM ausführen
     1:
       0          shutdown restart
     2:
       0         
   helper:
     event      ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   DS716
     timerevent ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     triggerDev DS716
     bm:
       DOIF_Get:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        05.07. 11:06:58
         max        2.21729278564453e-05
         tot        2.21729278564453e-05
         mAr:
           HASH(0x8fd25b0)
           RAMmsgAdjust
           ?
       DOIF_Notify:
         cnt        7381
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        05.07. 11:03:35
         max        0.00153589248657227
         tot        0.382654190063477
         mAr:
           HASH(0x8fd25b0)
           HASH(0x8faf768)
       DOIF_Set:
         cnt        3
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        05.07. 11:06:58
         max        5.69820404052734e-05
         tot        0.00013279914855957
         mAr:
           HASH(0x8fd25b0)
           RAMmsgAdjust
           ?
     timerevents:
       ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     timereventsState:
       ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     triggerEvents:
       ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
     triggerEventsState:
       ram: Total: 7903.75 MB, Used: 909.80 MB, 11.51 %, Free: 1789.29 MB
   internals:
   itimer:
   perlblock:
   readings:
     0           DS716:ram
     1           RAMmsgAdjust:cmd Eichenheim_Bot:msgText
     all         DS716:ram RAMmsgAdjust:cmd Eichenheim_Bot:msgText
   trigger:
   uiState:
   uiTable:
Attributes:
   group      msg-adjust
   room       97-Helper,99-Controller

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Frank_Huber am 05 Juli 2019, 12:19:45

Zitat von: rudolfkoenig am 05 Juli 2019, 08:45:40
Ich habe das Problem aber nicht (wie die Mehrheit der FHEM-Benutzer auch nicht)

Oder es ist bei den meisten Usern nicht in einem problematischen Level.
Ich sehe bei mir auch auf allen Instanzen einen permanenten Anstieg des Arbeitsspeichers.
Hatte aber noch nie den Fehler mit allocate memory.
Also wenn man nicht darauf schaut merkt man es nicht.

Ich hänge nachher mal noch nen Screen an.

EDIT: Screen angehängt.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 05 Juli 2019, 12:37:37
Zitat von: Frank_Huber am 05 Juli 2019, 12:19:45

Oder es ist bei den meisten Usern nicht in einem problematischen Level.
Ich sehe bei mir auch auf allen Instanzen einen permanenten Anstieg des Arbeitsspeichers.
Hatte aber noch nie den Fehler mit allocate memory.
Also wenn man nicht darauf schaut merkt man es nicht.

Ich hänge nachher mal noch nen Screen an.

Gesendet von meinem S60 mit Tapatalk

Also mein Testsystem2 (welches die Module bekommt bevor sie [evtl.] auf's Hauptsystem gehen) hatte einige Zeit (größer 3 Monate) nur alexa-fhem, Tradfri, Harmony und einige Notify, at, Dummy und zeigte KEINERLEI anstieg... ;)

Aktuell teste ich das Unifi/UnifiClient-Modul und es steigt sehr, sehr, sehr, sehr leicht an...

Würde aber Unifi (und werde ich demnächst) ohne Bedenken auch auf das Hauptsystem nehmen...

Also es geht wohl auch (fast) komplett ohne Anstieg...

Daher ja die Idee mal zu untersuchen, was an den Modulen die definitiv Speicherlecks haben/verursachen, ob und wenn welche Gemeinsamkeiten diese Module aufweisen...
...ein Kandidat wäre das echodevice-Modul.

Ein anderer Kandidat war ja mal ein "spezielles DOIF" von Damian...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Brice am 05 Juli 2019, 16:02:36
Hier läuft es nach Schwierigkeiten im März 2018 seither "einigermaßen", alle 3 bis 4 Wochen müsste ich FHEM neu starten, wenn in dieser Zeit nicht ein shutdown/restart aufgrund update gemacht wird. Betrifft nur mein Produktivsystem.

Ich schicke täglich über Telegram eine Nachricht über den aktuellen Zustand, um dann bei Bedarf ein shutdow/restart durchzuführen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: maci am 06 Juli 2019, 15:45:05
Meine System läuft anscheinend wieder.
Ich habe nach der Logfileanalyse gesehen, dass vor und nach der Memorymeldung häufig viele Feezemon einträge waren.
Ich habe den Freezemon installiert, dann aber gesehen, dass haufenweise Meldungen kommen, die alle owserverabfragen betreffen.
Ich hatte ihn dann deaktiviert.

Ich habe Freezemon komplett deinstalliert, nun läuft mein System mit 272MB Speicherauslastung seit mehr als 24 Std. Kein langsamer Anstieg mehr, nur immer wieder ein paar Ausschläge auf etwas über 300MB. Aber dann gleich wieder normal.

Ich hatte das ganze jetzt 2 mal wo sich dann Fhem einfach beendet hat nach der Cannot allocate memory Meldung.
Erst ein kompletter Reboot half, da Fhem nicht gestartet ist, weil angeblich der Port 8083 belegt war.
Jedenfalls war Freezemon nach dem ersten Reboot aktiv. Dann wurde der Speicher immer voller, bis nach 26 Std wieder das Limit erreicht war.
Nach dem 2. Auftreten habe ich zuerst, weil fast Mitternacht, den Fhem-Server nur neugestartet.
Gestern mm Morgen war der Speicher mit fast 600MB schon wieder ziemlich ausgelastet.
Habe dann das Log durchgesehen und nach den vielen Meldungen von Freezemon, auch rund um die Abstürze, beschlossen, Feezemon zu entfernen. Dann das System nochmal neu gestartet, das war um ca. 9:30 Uhr. Seit dem ist Ruhe.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 07 Juli 2019, 00:12:09
Ich habe das globale Attribut blockingCallMax auf 6 gesetzt.

Nachdem es scheinbar auch einen Zusammenhang zwischen den Perl Stacktrace Meldungen im Logfile und dem Speicherverbrauch gibt habe ich betroffene Module "sysmon" und "Spotify" disabled.
Jetzt habe ich "nur mehr" einen fast linearen Anstieg von 5% pro Stunde.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 07 Juli 2019, 18:53:24
ZitatNachdem es scheinbar auch einen Zusammenhang zwischen den Perl Stacktrace Meldungen im Logfile und dem Speicherverbrauch gibt
An stacktrace selbst liegt das vermutlich nicht:
define a at +*00:00:01 { stacktrace() } In 13 Minuten (780 at/stacktrace Aufrufe) ist FHEM laut ps kein Kilobyte gewachsen.
Habs mit perl 5.18 getestet.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 07 Juli 2019, 20:23:14
Ich habe 2 weitere Beobachtungen, die sich irgendwie auf das Speicherverhalten auswirken:

1) Für 3 Standorte ist das UWZ Modul in Einsatz. Bisher erfolgte die Abfrage jede Stunde. Ich habe das Intervall auf 4 Stunden hochgesetzt und die Memory Kurve ist um einiges flacher. (Sieht man auch in der Anlage)
Im Gegenzug steigt der Verbrauch aber nicht massiv an, wenn ich das Polling im Minutentakt durchführe. Also auch nicht schlüssig.
In beiden Fällen traten keine Fehlersituationen laut Logfile auf.

2) Heute trat ein Timeout bei der Abfrage von ProPlanta auf: Zur gleichen Zeit stieg der Memory Verbrauch:
2019.07.07 17:59:59 1: PROPLANTA wetter_Wien: HtmlAcquire.590 Error: Can't get https://www.proplanta.de/Wetter-Oesterreich/profi-wetter-at.php?SITEID=70&PLZ=Wien&STADT=Wien&WETTERaufrufen=stadt&Wtp=&SUCHE=Wetter&wT=0 -- 500 read timeout
2019.07.07 18:00:09 1: PROPLANTA wetter_Wien: HtmlAcquire.590 Error: Can't get https://www.proplanta.de/Wetter-Oesterreich/profi-wetter-at.php?SITEID=70&PLZ=Wien&STADT=Wien&WETTERaufrufen=stadt&Wtp=&SUCHE=Wetter&wT=4 -- 500 read timeout


Ich bin nicht der Perl-Programmierer, also lege ich meine Hände jetzt etwas ins Feuer:
Ich habe ein paar Perl-Module (im Zusammenspiel mit URL-Abfragen, ...) durch http://perlcritic.com/critique/file geschickt.

In httpUtils.pm
Bareword file handle opened at line 122, column 3. See pages 202,204 of PBP.
Using bareword symbols to refer to file handles is particularly evil because they are global, and you have no idea if that symbol already points to some other file handle.
Was passiert, wenn mehrere Abfragen zur gleichen Zeit laufen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 07 Juli 2019, 23:22:44
ZitatBareword file handle opened at line 122, column 3. See pages 202,204 of PBP.
Wird in den (eigentlch unueblichen) Fall verwendet, wenn HttpUtils_*Get mit "file://" aufgerufen wird.
Weiterhin ist FHEM single-threaded: es ist nicht moeglich, diesen Codestueck parallel aufzurufen.
Und drittens (wenn ich 59_PROPLANTA.pm richtig lese), wird hier nicht HttpUtils verwendet sondern (das blockierende) LWP::UserAgent
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 18 Juli 2019, 11:20:57
Hallo Zusammen,

ich weiß nicht ob es weiterhilft, ich habe meinen fhem Server auf buster geupdatet (also über dist upgrade). Auch wenn es nicht empfohlen wird.
Aber es hat funktioniert und die Perl Version ist jetzt 5.28.1.
Seit dem Update habe ich kein Memoryleck mehr und der Speicheverbrauch unter fhem steigt nicht mehr an.

Bisher konnte ich noch nicht feststellen das etwas nicht mehr funktioniert.

gruß
Jens
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 18 Juli 2019, 11:31:27
Zitat von: Jens_B am 18 Juli 2019, 11:20:57
Hallo Zusammen,

ich weiß nicht ob es weiterhilft, ich habe meinen fhem Server auf buster geupdatet (also über dist upgrade). Auch wenn es nicht empfohlen wird.
Aber es hat funktioniert und die Perl Version ist jetzt 5.28.1.
Seit dem Update habe ich kein Memoryleck mehr und der Speicheverbrauch unter fhem steigt nicht mehr an.

Bisher konnte ich noch nicht feststellen das etwas nicht mehr funktioniert.

gruß
Jens

Tolle Info.

Werde ich auf meinem/n Testsystem/en mal testen...

Danke, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Frank_Huber am 18 Juli 2019, 11:40:11
Mein neu installiertes Buster auf RPI4 zeigt einen kleinen konstanten Speicheranstieg.
Er läuft aber jetzt noch nicht lange.
Werde das erstmal paar Wochen so laufen lassen ohne Neustarts vom PI bzw FHEM.
Dann sieht man mehr.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 18 Juli 2019, 12:09:36
Hallo Frank,
also der Anstieg unter Stretch ist bei Dir ja minimal ;-). Das was bei Dir über den Monat passiert, war bei auf meinem fhem in 2 Tagen erreicht. Ich hatte ein script, was fhem automatisch neu gestartet hat, wenn ich Logfile der Fehler "cannot allocate memory" auftauchte.

Gruß
Jens
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: HomeAuto_User am 24 Juli 2019, 18:34:25
Hallo,
nun melde ich mich auch mal zu Wort, da ich nun schon 3 Fach den Fehler sporadisch erhalten habe.
Cannot fork: Cannot allocate memory

Meine ersten Vermutungen waren, das ganze liegt an der Speicherkarte vom RasPi3.
- Speicherkarte neu geschrieben und neuer Test

Irgendwann nach kurzer Zeit kam der Fehler erneut auf und ich nahm eine nagelneue Speicherkarte und setzte das System neu auf.
- Erkenntnis nach nicht mal 72h, Fehler Cannot fork: Cannot allocate memory welcher alles blockierte.

Mein System wo dies auftrat ist
ZitatPRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster

ZitatLatest Revision: 19887

File                   Rev   Last Change

fhem.pl                19805 2019-07-09 09:44:07Z rudolfkoenig
96_allowed.pm          19046 2019-03-27 08:09:43Z rudolfkoenig
42_AptToDate.pm        19639 2019-06-18 13:43:31Z CoolTux
90_at.pm               17561 2018-10-18 14:45:30Z rudolfkoenig
98_autocreate.pm       19372 2019-05-11 15:13:59Z rudolfkoenig
88_Beispiel.pm         15699 2017-12-26 21:17:50Z HomeAuto_User
00_CUL.pm              17559 2018-10-18 07:45:07Z rudolfkoenig
09_CUL_FHTTK.pm        18391 2019-01-23 19:05:58Z Matscher
14_CUL_TCM97001.pm     19762 2019-07-02 19:21:52Z bjoernh
14_CUL_WS.pm           18128 2019-01-03 19:20:43Z rudolfkoenig
95_Dashboard.pm        16920 2018-06-29 12:01:56Z DS_Starter
98_dewpoint.pm         18846 2019-03-10 11:45:58Z hotbso
98_DOIF.pm             19786 2019-07-05 21:47:08Z Damian
98_dummy.pm            19585 2019-06-09 08:04:48Z rudolfkoenig
91_eventTypes.pm       14888 2017-08-13 12:07:12Z rudolfkoenig
72_FB_CALLLIST.pm      18181 2019-01-08 12:46:07Z markusbloch
72_FB_CALLMONITOR.pm   19517 2019-06-01 12:18:45Z markusbloch
01_FHEMWEB.pm          19878 2019-07-21 10:26:47Z rudolfkoenig
11_FHT.pm              18068 2018-12-27 17:08:46Z rudolfkoenig
92_FileLog.pm          19102 2019-04-02 19:48:57Z rudolfkoenig
# $Id: 14_FLAMINGO.pm 3818 2016-08-15 HomeAuto_User $
72_FRITZBOX.pm         17437 2018-09-30 18:24:58Z tupol
10_FS10.pm               331 2017-06-23 17:00:00Z v3.3-dev
10_FS20.pm             14888 2017-08-13 12:07:12Z rudolfkoenig
14_Hideki.pm           14395 2017-12-03 21:00:00Z v3.3.3-dev
98_HTTPMOD.pm          18644 2019-02-19 17:20:27Z StefanStrobel
10_IT.pm               19761 2019-07-02 18:37:03Z bjoernh
82_LGTV_IP12.pm        15140 2017-09-26 09:20:09Z markusbloch
00_MQTT.pm             18719 2019-02-24 20:20:51Z hexenmeister
10_MQTT_DEVICE.pm      17362 2018-09-17 12:57:29Z hexenmeister
91_notify.pm           19374 2019-05-11 17:48:03Z rudolfkoenig
41_OREGON.pm           34476 2017-12-26 13:23:00Z dev
73_PRESENCE.pm         18314 2019-01-18 13:49:05Z markusbloch
59_PROPLANTA.pm        18714 2019-02-24 16:08:46Z tupol
98_rain.pm              6916 2014-11-08 11:28:26Z baumrasen
33_readingsGroup.pm    19774 2019-07-04 14:10:53Z justme1968
95_remotecontrol.pm    10724 2016-02-04 18:17:33Z ulimaass
14_SD_BELL.pm          18657 2019-02-19 21:02:24Z HomeAuto_User
14_SD_Keeloq.pm           32 2019-02-23 12:00:00Z v3.4-dev_02.12.
14_SD_UT.pm            19886 2019-07-22 19:22:52Z HomeAuto_User
# $Id: 14_SD_WS.pm 18674 2019-05-05 12:00:00Z Sidey/elektron-bbs (dev-r34) $
14_SD_WS07.pm          18673 2019-07-10 20:52:45Z Sidey
00_SIGNALduino.pm      10488 2019-07-10 12:00:00Z v3.4.0
88_SIGNALduino_TOOL.pm 13115 2019-07-22 21:17:50Z HomeAuto_User
# $Id: 90_SIGNALduino_un.pm 15479 2018-01-24 20:00:00 dev-r34 $
98_statistics.pm       16438 2018-03-18 18:51:57Z tupol
99_SUNRISE_EL.pm       18732 2019-02-25 13:15:34Z rudolfkoenig
98_SVG.pm              19688 2019-06-23 07:17:03Z rudolfkoenig
42_SYSMON.pm           17227 2018-08-29 19:58:18Z hexenmeister
98_telnet.pm           17529 2018-10-14 12:57:06Z rudolfkoenig
No Id found for 98_unittest.pm
99_Utils.pm            18920 2019-03-16 09:58:52Z rudolfkoenig
77_UWZ.pm              19869 2019-07-20 13:59:38Z CoolTux
98_version.pm          15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm          16293 2018-02-28 21:33:57Z rudolfkoenig
88_xs1Bridge.pm        16681 2018-04-30 18:23:25Z HomeAuto_User
88_xs1Dev.pm           16598 2018-04-13 13:48:07Z HomeAuto_User
71_YAMAHA_AVR.pm       17547 2018-10-16 18:17:01Z markusbloch

AttrTemplate.pm        19085 2019-04-01 17:00:24Z rudolfkoenig
Blocking.pm            17553 2018-10-17 15:56:35Z rudolfkoenig
Color.pm               18481 2019-02-02 09:35:08Z justme1968
DevIo.pm               19372 2019-05-11 15:13:59Z rudolfkoenig
FritzBoxUtils.pm       16691 2018-05-05 17:11:26Z rudolfkoenig
GPUtils.pm             19666 2019-06-20 11:17:29Z CoolTux
HttpUtils.pm           19689 2019-06-23 07:28:05Z rudolfkoenig
Meta.pm                19650 2019-06-19 16:06:23Z loredo
RTypes.pm              10476 2016-01-12 21:03:33Z borisneubert
No Id found for SD_ProtocolData.pm
No Id found for SD_Protocols.pm
SetExtensions.pm       19208 2019-04-17 19:27:09Z rudolfkoenig
SubProcess.pm          14334 2017-05-20 23:11:06Z neubert
TcpServerUtils.pm      19138 2019-04-07 10:17:21Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 19285 2019-04-28 20:18:39Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
svg.js                     19667 2019-06-20 13:39:55Z rudolfkoenig

Zitatperl 5, version 28, subversion 1 (v5.28.1)

Nun habe ich das PRESENCE Modul sofort auf deaktiv gesetzt weil es mit einer Nachricht begann wie
ZitatPRESENCE (WLAN_Tablet) - error while processing check: Could not execute ping command: "ping -c 4 ASUS-T100HA"

Gibt es mitlerweile eine Möglichkeit, gezielt an die Fehlersuche des Problems heranzutreten anstall nur zu "schauen" nach verdächtigen Kanidaten?

MfG
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wzut am 24 Juli 2019, 19:21:59
Ich habe einen Speicherfresser finden können : die FHEM interne Funktion backup
Im angehängten oberen Screenshot sieht man wie jeden Tag der freie Speicher einen größeren Schritt nach unten macht.
Die untere Grafik ist ein Zoom und dort sieht man das die Stufe täglich um 4:00 Uhr ist und genau um die Zeit lief das backup via at. -> {fhem("backup");}
Ich habe jetzt von backup auf rsync via cronjob umgestellt und zumindest die Treppen sind jetzt verschwunden.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 25 Juli 2019, 07:34:16
Ich habe gerade backup ein paarmal mit einer leeren Konfiguration gestartet: beim ersten mal ist RSS laut "ps -elf" von 22820 auf 34376 gestiegen, aber nach wiederholten weiteren backups nicht mehr. Entweder schaue ich auf die falschen Zahlen, habe die falsche OS/Perl Kombination oder ist backup nicht der wahre Grund.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 25 Juli 2019, 09:35:43
Wie schon geschrieben:
Bei mir ist es definitiv das echodevice Modul.

Ohne Echo´s alles bestens !
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wzut am 25 Juli 2019, 09:54:38
Zitat von: rudolfkoenig am 25 Juli 2019, 07:34:16
Entweder schaue ich auf die falschen Zahlen
Nunja zumindes auf "andere" als ich :)
meine Grafik oben basiert auf der Ausgabe von
cat /proc/meminfo |grep -e "MemFree" |awk '{WERT=$2/1024;printf ( "%.0f", WERT )}'
Das interen Backup macht im Grunde ja auch nur ein einfaches tar . Ich habe mir dann die komplette tar Zeile aus dem log kopiert und mehrmals direkt auf der Konsole ausgeführt. Nach jedem Lauf ist meine MemFree Ausgabe dann wieder ein Stück kleiner geworden.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 25 Juli 2019, 10:23:49
ZitatMemFree: The amount of physical RAM, in kilobytes, left unused by the system.
Backup erstellt eine Datei, das landet (auch) im Filesystem-/Block-Cache, und damit sinkt MemFree.
MemFree gibt den RAM an, den man entsorgen kann, ohne dass man ein Performance-Unterschied merkt, und taugt leider nicht zum Lokalisieren eines Speicherlochs.
Titel: Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: HomeAuto_User am 25 Juli 2019, 15:27:26
Aktuell nervt es bei mir.
Ich habe nun aus der Ferne mal geschaut und ich tippe und bin mir sicher, das es vermutlich ein Prozess / Modul in FHEM ist bzw. etwas was FHEM ,,aufschaukelt".

Das System nimmt auf einmal 70% vom Mem. Ich fügte mal die Prozessliste mit bei.

Def. ausgeschlossen Presence Modul.

(https://uploads.tapatalk-cdn.com/20190725/b245a9bb28129a18a4af6b5756d35db5.jpg)


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Eistee am 26 Juli 2019, 09:15:27
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: HomeAuto_User am 26 Juli 2019, 09:48:56
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Jens_B am 26 Juli 2019, 10:30:28
Zitat von: Eistee am 26 Juli 2019, 09:15:27
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.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 26 Juli 2019, 16:48:25
Ist eigentlich jemand mit FHEM im Docker Container betroffen..?
Ich überlege zu wechseln...

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: kadettilac89 am 26 Juli 2019, 21:08:59
Zitat von: der-Lolo am 26 Juli 2019, 16:48:25
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.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Eistee am 27 Juli 2019, 00:49:06
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.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: HomeAuto_User am 27 Juli 2019, 08:42:24
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nestor am 30 Juli 2019, 11:02:44
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

   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

   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.

./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:
use Data::Dumper;
$Data::Dumper::Terse = 1;
$Data::Dumper::Sortkeys = 1;
$Data::Dumper::Maxdepth = 1;


./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


./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


./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

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: peter_w am 09 August 2019, 18:54:35
Zitat von: Eistee am 26 Juli 2019, 09:15:27
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 09 August 2019, 19:02:50
Dazu braucht es kein DOIF...
...ein simples Notify reicht (und wurde auch schon mehrfach gepostet), hier die raw definition eines Beispiels:


defmod nCannotForkRestart notify global:CANNOT_FORK shutdown restart


Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: peter_w am 09 August 2019, 19:04:17
Super, danke für dass du es trotzdem nochmal gepostet hast.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: HomeAuto_User am 09 August 2019, 19:17:46
Hallo,

eine Frage an alle die das Problem
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 09 August 2019, 19:33:42
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Frank_Huber am 09 August 2019, 19:59:36
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

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Eistee am 10 August 2019, 10:07:01
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.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: enno am 10 August 2019, 10:22:12
Ich hatte auf meinem NUC lange Ruhe. Im Urlaub hatte ich meine drei Yamaha Musiccast Geräte abgeschaltet. FHEM versuchte sie weiter regelmässig zu finden und der Speicher lief in zwei Tagen voll. Nachdem ich die Module gelöscht hatte war das Problem wieder verschwunden. Jetzt nach dem Urlaub sind die Geräte wieder normal auf Standby und die Module wieder eingespielt. Funktioniert ohne Speicherzuwachs. Kann ich aber schnell wieder provozieren, in dem ich am Gerät den "Stecker ziehe"...

Das Problem ist bei dem von mir genutzten Modul bekannt, nur leider noch nicht offiziell gefixt.
https://forum.fhem.de/index.php/topic,98383.msg955311.html#msg955311

Gruss
  Enno
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 August 2019, 09:07:42
Nun hat es auch mich extremst erwischt. Seit einigen Wochen läuft mir Tag täglich der Speicher voll. Am Ende beantsprucht FHEM 45% Speicher. Sobald er dann 2mal forkt ist Ende im Gelände.
Ich untersuche aktuell das HUE Bridge Modul nach dem ich fhem-connect ausgeschlossen habe. Es frisst zwar auch einiges aber nicht so extrem.
Das einzige was bei mir nachweislich an steigt wenn ich fhemdebug memusage mache ist defs
defs                            5228452
Das ist kurz nach einen FHEM neustart. Im Moment rette ich mich in dem ich den Speicherpuffer immer leer Räume.
sync && echo 3 > /proc/sys/vm/drop_caches

Senkt aber natürlich nicht den FHEM Verbrauch sondern gibt nur gepufferten Speicher frei.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 27 August 2019, 09:35:53
ZitatNun hat es auch mich extremst erwischt.
Finde ich gut, damit gibt es Hoffnung auf Besserung :)

Apropos "fhemdebug memusage": sie misst nur (mehr oder weniger richtig) die im Perl sichtbaren Daten, z.Bsp. wenn jemand immer mehr Daten in einem Hash packt, ohne je aufzuraeumen.
Es zeigt bestimmte Probleme aber nicht an:
- Speicherloch im C-Bibliothek
- Vergessene Aufrufe, um Daten im C-Bibliothek freizugeben. Z.Bsp. muessen die Ergebnisse von XML::DOM::Parser->parsefile explizit mit dispose entfernt werden, deswegen ist fuer mich alles, was XML::DOM verwendet, verdaechtig.

Um zu zeigen, dass das Problem nicht alle betrifft, im Anhang die Messungen meines Speicherverbrauchs.
Der leichte Zuwachs kann ich auch ohne Speicherloch erklaeren, da ich immer wieder Kleinigkeiten (z.Bsp. durch Modul-reload) ohne Neustart teste.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 August 2019, 10:04:05
Zitat von: rudolfkoenig am 27 August 2019, 09:35:53
Finde ich gut, damit gibt es Hoffnung auf Besserung :)

Apropos "fhemdebug memusage": sie misst nur (mehr oder weniger richtig) die im Perl sichtbaren Daten, z.Bsp. wenn jemand immer mehr Daten in einem Hash packt, ohne je aufzuraeumen.
Es zeigt bestimmte Probleme aber nicht an:
- Speicherloch im C-Bibliothek
- Vergessene Aufrufe, um Daten im C-Bibliothek freizugeben. Z.Bsp. muessen die Ergebnisse von XML::DOM::Parser->parsefile explizit mit dispose entfernt werden, deswegen ist fuer mich alles, was XML::DOM verwendet, verdaechtig.

Um zu zeigen, dass das Problem nicht alle betrifft, im Anhang die Messungen meines Speicherverbrauchs.
Der leichte Zuwachs kann ich auch ohne Speicherloch erklaeren, da ich immer wieder Kleinigkeiten (z.Bsp. durch Modul-reload) ohne Neustart teste.

Leider scheint die Hoffnung verschwindend klein zu sein. Es ist ein mühseliger Akt. Aber schauen wir mal.
Ich habe auf dem FHEM Host im übrigen Debian buster mit perl 5.28.1. Nur zur Info da ja mal der Verdacht auf die Perl Version lag.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 27 August 2019, 10:23:28
Da nun ein agiler Entwickler betroffen ist werfe ich noch mal das echodevice-Modul ins Rennen...

Evtl. gibt es "Parallelen"...

Ich habe eine kleine Testinstallation und wenn ich da dann meine echodevices anlege kann ich zusehen, wie der Speicher wächst...

Nehme ich es wieder raus ist Ruhe...

Mittlerweile teste ich jedes neue Modul auf diesem System für ein paar Tage/Wochen (auch/hauptsächlich wegen Speicher) bevor ich es auf meinem Hauptsystem aktiviere (oder auch nicht)...

Mein Hauptsystem schafft es auf einem PI locker einen Monat und mehr...
...und das soll auch so bleiben...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 August 2019, 10:39:43
Zitat von: MadMax-FHEM am 27 August 2019, 10:23:28
Da nun ein agiler Entwickler betroffen ist werfe ich noch mal das echodevice-Modul ins Rennen...

Evtl. gibt es "Parallelen"...

Ich habe eine kleine Testinstallation und wenn ich da dann meine echodevices anlege kann ich zusehen, wie der Speicher wächst...

Nehme ich es wieder raus ist Ruhe...

Mittlerweile teste ich jedes neue Modul auf diesem System für ein paar Tage/Wochen (auch/hauptsächlich wegen Speicher) bevor ich es auf meinem Hauptsystem aktiviere (oder auch nicht)...

Mein Hauptsystem schafft es auf einem PI locker einen Monat und mehr...
...und das soll auch so bleiben...

Gruß, Joachim

Ich habe kein Echo Device. Bei mi sind 2 Produktive Systeme betroffen. Ich habe auf meinem Entwicklersystem die Demo Konfig geladen und einige meiner Module. Dort verzeichne ich keinen Anstieg trotz mehrerer Tage Laufzeit. Auf meinem 1. Produktivsystem geht mittlerweile selbst nach einem kompletten reboot der Speicher innerhalb von 24 Stunden durch die Decke.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 27 August 2019, 10:56:12
Einen Echo Dot hätte ich noch über... ;)

Parallelen im Code könnte man auch ohne einen Echo zu haben finden...

Evtl. mit dem Hinweis von Rudi...

Allerdings würde ich es vermutlich nicht "sehen"...
...bzw. "verstehen"...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 August 2019, 11:18:09
Zitat von: MadMax-FHEM am 27 August 2019, 10:56:12
Einen Echo Dot hätte ich noch über... ;)

Parallelen im Code könnte man auch ohne einen Echo zu haben finden...

Evtl. mit dem Hinweis von Rudi...

Allerdings würde ich es vermutlich nicht "sehen"...
...bzw. "verstehen"...

Gruß, Joachim

Den Tipp von Rudi habe ich mir schon angeschaut. Gefunden habe ich in meiner Umgebung aber kein Modul welches XML::DOM verwendet.
Ich schaue mir gerne das Modul echo Dot an.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 August 2019, 11:21:39
Ich finde im SVN kein 37_echodevice.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 August 2019, 11:33:58
Ist nicht offiziell. Ich habe es mir angeschaut. Sieht soweit ok aus.
Der Micha arbeitet mit einer Queue, eventuell wird diese nicht korrekt abgebaut und daher kommt "DEIN" Speicheranstieg. Ist aber mehr so eine Vermutung. Allerdings sollte man das ja auch an Hand der Arbeitsweise des Modules erkennen. Kommen Befehle drüben an oder nicht, Werden Readings aktualisiert oder nicht.
Ich denke mal Du siehst es auch bei einem list am @{$hash->{helper}{CMD_QUEUE}}
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 27 August 2019, 12:08:35
Hallo Leon,

danke für's Nachschauen...
Ja ist (noch) nicht offiziell...

Was kann ich an der cmd_queue sehen?

Bei keinem der Echo-Devices steht dort was...

Ich dachte nur ich meld mich noch mal, weil ja nach Modulen "gesucht" wird, die einen Speicheranstieg hervorrufen.
Einige machen das mit "deaktivieren" und schauen wann der Speicheranstieg weg ist...
...ich hab halt (einfach) ein Testsystem aufgesetzt wo ich halt ein Modul nach dem anderen "mal aktiviere" und "teste" bevor es "scharf geht" ;)

Und bei dem Modul ist es einfach und deutlich zu sehen...

Damian hatte auch mal ein spezielles DOIF-Konstrukt gepostet mit dem ebenfalls ein Anstieg "generiert" werden konnte...

Hmmm, dass du es (auch) mit Buster hast, hmmm... :-|

Werde aber trotzdem mal ein System mit Buster aufsetzen...
...mal sehen.

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 August 2019, 14:42:58
Ich habe nun einige ausschließen können.
Proplanta
UWZ
und diverse eigene Sachen.

Aktuell teste ich ob eventuell meine Umstellung für das HM-MOD-RPI-PCB Schuld sein kann
Habe die Definition geändert von
/dev/ttyAMA0
nach
uart://192.168.42.23:12345
Schema
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 27 August 2019, 22:53:50
Er wächst und gedeiht

        USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
      1 fhem     22145 11.5 10.5 115056 99696 ?        S    14:36   2:11 /usr/bin/perl fhem.pl configDB
      2 fhem     22145 10.4 10.6 116316 100956 ?       S    14:36   2:25 /usr/bin/perl fhem.pl configDB
      3 fhem     22145  9.1 11.0 120300 105060 ?       S    14:36   3:03 /usr/bin/perl fhem.pl configDB
      4 fhem     22145  8.4 11.4 124268 108900 ?       S    14:36   3:40 /usr/bin/perl fhem.pl configDB
      5 fhem     22145  7.8 11.7 126724 111232 ?       S    14:36   4:09 /usr/bin/perl fhem.pl configDB
      6 fhem     22145  7.4 12.1 130244 114876 ?       S    14:36   4:42 /usr/bin/perl fhem.pl configDB
      7 fhem     22145  7.0 12.4 133392 118024 ?       S    14:36   5:11 /usr/bin/perl fhem.pl configDB
      8 fhem     22145  6.8 12.7 136536 121168 ?       S    14:36   5:43 /usr/bin/perl fhem.pl configDB
      9 fhem     22145  6.7 13.1 139684 124316 ?       S    14:36   6:15 /usr/bin/perl fhem.pl configDB
     10 fhem     22145  6.5 13.4 142836 127468 ?       R    14:36   6:44 /usr/bin/perl fhem.pl configDB
     11 fhem     22145  6.4 13.7 146024 130664 ?       S    14:36   7:20 /usr/bin/perl fhem.pl configDB
     12 fhem     30880  0.0 13.1 146024 124712 ?       S    16:30   0:00 /usr/bin/perl fhem.pl configDB
     13 fhem     22145  6.5 14.1 149228 133992 ?       S    14:36   8:03 /usr/bin/perl fhem.pl configDB
     14 fhem     22145  6.4 14.4 152476 137240 ?       S    14:36   8:35 /usr/bin/perl fhem.pl configDB
     15 fhem     22145  6.3 14.8 156384 141020 ?       S    14:36   9:08 /usr/bin/perl fhem.pl configDB
     16 fhem     22145  6.3 15.1 158996 143760 ?       S    14:36   9:44 /usr/bin/perl fhem.pl configDB
     17 fhem     22145  6.4 15.5 162260 147024 ?       S    14:36  10:27 /usr/bin/perl fhem.pl configDB
     18 fhem     22145  6.6 16.1 169028 153248 ?       S    14:36  11:26 /usr/bin/perl fhem.pl configDB
     19 fhem     22145  6.5 16.5 172948 157040 ?       S    14:36  12:03 /usr/bin/perl fhem.pl configDB
     21 fhem     22145  6.5 16.9 176212 160304 ?       S    14:36  12:37 /usr/bin/perl fhem.pl configDB
     22 fhem     22145  6.4 17.2 179480 163572 ?       S    14:36  13:11 /usr/bin/perl fhem.pl configDB
     23 fhem     22145  6.4 17.5 182744 166836 ?       S    14:36  13:48 /usr/bin/perl fhem.pl configDB
     24 fhem     22145  6.4 17.9 185684 169904 ?       S    14:36  14:27 /usr/bin/perl fhem.pl configDB
     25 fhem     22145  6.4 18.2 189276 173368 ?       S    14:36  15:03 /usr/bin/perl fhem.pl configDB
     27 fhem     22145  6.4 18.6 192544 176636 ?       R    14:36  15:40 /usr/bin/perl fhem.pl configDB
     28 fhem     22145  6.4 18.9 195808 179900 ?       S    14:36  16:15 /usr/bin/perl fhem.pl configDB
     29 fhem     22145  6.3 19.3 199076 183168 ?       S    14:36  16:50 /usr/bin/perl fhem.pl configDB
     30 fhem     22145  6.4 19.6 201688 185908 ?       S    14:36  17:29 /usr/bin/perl fhem.pl configDB
     31 fhem     22145  6.4 19.9 204956 189176 ?       S    14:36  18:10 /usr/bin/perl fhem.pl configDB
     33 fhem     22145  6.4 20.2 208236 192456 ?       S    14:36  18:57 /usr/bin/perl fhem.pl configDB
     34 fhem     22145  6.4 20.6 211508 195728 ?       S    14:36  19:32 /usr/bin/perl fhem.pl configDB
     35 fhem     22145  6.4 20.9 214784 199004 ?       S    14:36  20:10 /usr/bin/perl fhem.pl configDB
     36 fhem     22145  6.3 21.3 218064 202072 ?       S    14:36  20:41 /usr/bin/perl fhem.pl configDB
     37 fhem     22145  6.4 21.6 221340 205136 ?       S    14:36  21:24 /usr/bin/perl fhem.pl configDB
     39 fhem     22145  6.4 21.9 224592 208472 ?       S    14:36  21:59 /usr/bin/perl fhem.pl configDB
     40 fhem     22145  6.3 22.3 227840 211720 ?       S    14:36  22:30 /usr/bin/perl fhem.pl configDB
     41 fhem     22145  6.4 22.7 231412 215320 ?       S    14:36  23:15 /usr/bin/perl fhem.pl configDB
     42 fhem     22145  6.3 22.7 234656 215984 ?       S    14:36  23:49 /usr/bin/perl fhem.pl configDB
     43 fhem     22145  6.3 23.2 238940 220192 ?       S    14:36  24:21 /usr/bin/perl fhem.pl configDB
     44 fhem     22145  6.3 23.5 241536 222940 ?       S    14:36  24:56 /usr/bin/perl fhem.pl configDB
     46 fhem     22145  6.3 23.8 244460 225872 ?       S    14:36  25:27 /usr/bin/perl fhem.pl configDB
     47 fhem     22145  6.2 24.1 247708 229156 ?       S    14:36  25:57 /usr/bin/perl fhem.pl configDB
     48 fhem     22145  6.2 24.5 250960 232424 ?       S    14:36  26:29 /usr/bin/perl fhem.pl configDB
     49 fhem     22145  6.2 24.8 254220 235708 ?       S    14:36  27:14 /usr/bin/perl fhem.pl configDB
     50 fhem     22145  6.2 25.1 256812 238324 ?       S    14:36  27:52 /usr/bin/perl fhem.pl configDB
     51 fhem     22145  6.2 25.4 260056 241604 ?       S    14:36  28:33 /usr/bin/perl fhem.pl configDB
     52 fhem     22145  6.3 25.8 263312 244888 ?       S    14:36  29:13 /usr/bin/perl fhem.pl configDB
     53 fhem     22145  6.3 26.1 266572 248168 ?       S    14:36  29:56 /usr/bin/perl fhem.pl configDB
     54 fhem     22145  6.3 26.5 269896 251496 ?       S    14:36  30:37 /usr/bin/perl fhem.pl configDB
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 27 August 2019, 23:05:58
Hallo Marc,

ich hatte mit Buster ebenfalls negative Erfahrungen gemacht.
Nachdem ich Stretch zu Buster upgegradet hatte, war sofort ohne irgendwelche Änderungen an der FHEM-Konfiguration ein erhöhter Speicherverbrauch und ein stetig ansteigender Speicher zu verzeichen.
Schau hier: https://forum.fhem.de/index.php/topic,84372.msg952143.html#msg952143

Mittlerweile habe ich alle Systeme neu mit Buster aufgesetzt (nicht upgegradet). Es hat sich am Bild im Prinzip nicht viel geändert. Ingesamt würde ich behaupten ist der Anstieg nicht mehr so steil. Die Systeme halten 8-9 Tage bevor ein Neustart wegen cannot fork nötig wird. Insgesamt wird bei mir grundsätzlich mehr Speicher gegenüber Stretch verbraucht.

Das hatte ich mit Stretch nicht. Wie gesagt, das alles ohne Änderungen an dem Umfang der eingesetzten Module etc.
Andere User hatten gerade mit Stretch das Problem. Irgendwie gibt sich mir kein Bild.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 28 August 2019, 06:18:18
Guten Morgen,

Ich bin gerade wegen dem auf einmal auftretenden Speicherverbrauch zu Buster gewechselt  ;D.
Auch mir ergibt sich noch kein Bild.


Grüße
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: ESP_Fan am 30 August 2019, 08:31:25
Mich hat es auch erwischt. Da ich monatelang viele Sachen getestet und installiert habe und entsprechend oft Neustarts hatte, habe ich das erst im Urlaub bemerkt, als FHEM nach einer knappen Woche die Arbeit eingestellt hat und dann auch gleich den ganzen Pi lahmgelegt hatte. Ich habe Stretch drauf und will auch aktuell noch nicht upgraden, also habe ich erst mal Perlbrew installiert und damit auf Perl 5.30.0 hochgezogen. Das läuft jetzt seit gestern Abend und es scheint gut zu sein. Vorher ist der genutzte Speicher je Stunde um ca. 4 MB gestiegen, seit gestern abend ist Ruhe, es sind sogar 20 MB weniger geworden seit dem Start von FHEM.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 30 August 2019, 08:37:31
Ich habe meine produktive Instanz in einen Container. Damit kann ich relativ Problemlos testen. Habe schon diverse Geräte raus geworfen. Heute aktuell Homematic.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 30 August 2019, 10:27:10
Kleiner aktueller Stand. Ich habe für die Nacht entfernt
HMinfo
HOMBOT
EQ3BT
Pushover
DbLog

Der Speicherverbrauch stieg dennoch an.

Ich habe heute morgen entfernt
gassistant
VCCU CUL_HM
HMUARTLGW
FHEM2FHEM

Auch da ist der Speicher wieder gestiegen.

Nun habe ich alle meine FHEMWEB Instanzen entfernt. Es waren 3. Und dadurch bedingt sind alle Residents und Co Devices geflogen. Also Roommate Guest und so. Und nun wird es interessant. Bis her (10min) konnte ich keine Veränderung feststellen. Speicherverbrauch konstant 133MB und FHEM benötigt davon 10.9%
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 30 August 2019, 10:50:03
Ich habe etwas recherchiert. Zeitlich könnte eine Anpassung an FHEMWEB passen. Sollte also in den nächsten 60 min der Speicherverbrauch nicht weiter ansteigen werde ich in diese Richtung weiter schauen. Natürlich wird dies nun kein Problem von FHEMWEB alleine. Ich habe da meine 3 Jahre alte TabletUI Installation im Auge. Eventuell hat die Probleme mit dem neuen FHEMWEB. Aber das muss ich mir genauer anschauen.
Aktuell kann ich lediglich meine Beobachtungen kund tun.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 30 August 2019, 11:11:28
Immer noch 133MB Ram Verbrauch. Das sieht gut aus.

Mir ist doch tatsächlich eben noch eine Veränderung an meiner Umgebung auf gefallen. Ich habe ja noch HA Proxy installiert und greife darüber auf die Webinstanzen von FHEM zu. Könnte also auch ein Ansatz sein.
Das es Residents sein kann mag ich erstmal nicht so ganz glauben. Obwohl es natürlich im engeren Kreis der Täter steht.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 30 August 2019, 13:56:09
Wir kommen der Sache immer Näher. Und wie so oft kommt es anders wie gedacht.
Es bleiben nun noch 2 Täter übrig. Mein HAProxy oder mein Check_MK Plugin für HTTP Connection
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 30 August 2019, 13:58:50
Traurig. Das sind naemlich keine "Volksmodule", will sagen, deine Loesug wird den Anderen hier kaum helfen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 30 August 2019, 14:03:01
Zitat von: rudolfkoenig am 30 August 2019, 13:58:50
Traurig. Das sind naemlich keine "Volksmodule", will sagen, deine Loesug wird den Anderen hier kaum helfen.

Das denke ich auch. Sind aber auch keine Module sondern das eine ist mein Firewall auf der ein HAProxy lauft und das andere ist mein CheckMK Server. Beide bauen eine Verbindung zum FHEMWEB auf.

Davon aber mal ganz ab, wenn ich mir hier so die letzten Seiten durchlese so haben bei 2-3 Leuten jeweils eine andere Lösung zum Ziel geführt. Bei einem war es ein Modul beim anderen eine andere Perlversion welche beim dritten aber nicht geholfen hat sondern etwas anderes. Ist ist also alles andere als ein ein deutig.
Was es nun genau bei mir ist werde ich sicherlich in den nächsten Stunden noch raus finden.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: nuccleon am 30 August 2019, 14:52:35
Ich klinke mich hier mal zu mitlesen ein, da mein fhem process (läuft auf PI4) auch ziemlich heftig leakt.
Speicherverbrauch steigt von 6.5% nach dem booten kontinuierlich an (hat nach 6h ca 10% erreicht).

Auch ich habe mehrere FHEMWEB Instanzen aktiv (3 Stück)

Eine FHEMWEB Instanz wird dazu verwendet um von einer S7 SPS über HTTP, Dummy Devices zu "füttern" (set, setreading). Das sind z.B. Schalteraktion von Tastern / Schaltern die an der SPS verdrahtet sind oder eben auch zyklische Daten wie z.B. Temperaturmesswerte von der SPS etc...

Der Vollständigkeit halber häng ich mal noch ein list an.

Type list  for detailed info.

Global:
  global               (no definition)

HMUARTLGW:
  hm_uart_lgw          (opened)

MQTT2_CLIENT:
  mqtt2                (opened)

FHEMWEB:
  PLCWEB               (Initialized)
  WEB                  (Initialized)
  WEBFLEX              (Initialized)
  WEBFLEX_192.168.178.51_55744 (Connected)
  WEBFLEX_192.168.178.51_55748 (Connected)

CUL_HM:
  ActionDetector       (alive:10 dead:0 unkn:0 off:0)
  HM_Sirene            (CMDs_done)
  HM_Sirene_Arm        (0)
  HM_Sirene_Panic      (off)
  HM_Sirene_Sen_01     (off)
  HM_Sirene_Sen_02     (off)
  dts_aussen           (Info_Cleared)
  dts_aussen_event     (???)
  dts_aussen_t1        (T: 54.0)
  dts_aussen_t1_t2     (T: 20.1)
  dts_aussen_t2        (T: 33.9)
  dts_aussen_t2_t1     (T: -20.1)
  ftk_eg0_wohnzimmer   (open 2019-08-12 08:27:30)
  ftk_eg1_wohnzimmer   (open 2019-08-13 19:39:37)
  ftk_eg2_haustuere    (open 2019-08-30 14:42:16)
  ftk_eg3_wc           (open 2019-08-13 11:50:13)
  ftk_eg4_kueche       (open 2019-08-30 14:18:20)
  ftk_eg5_kueche       (open 2019-08-30 14:43:46)
  ftk_kg0_hobbyraum    (open 2019-08-13 21:50:46)
  ftk_kg1_technikraum  (open 2019-08-13 22:01:37)
  ftk_og0_bad          (open 2019-08-30 14:20:28)
  hm_vccu              (hm_uart_lgw:ok)
  hm_vccu_Btn1         (???)

MQTT2_DEVICE:
  MQTT2_ebusd          (running | ready)
  MQTT2_espeasy_dht_aussen (30.4 °C | 44.6 % | 192.168.178.28 disconnected)
  MQTT2_espeasy_dht_bad (26.0 °C | 61.9 % | 192.168.178.21 disconnected)
  MQTT2_espeasy_dht_k1 (21.5 °C | 72.1 % | 192.168.178.3 disconnected)
  MQTT2_espeasy_dht_k3 (22.7 °C | 67.1 % | 192.168.178.17 disconnected)
  MQTT2_espeasy_dht_lunos (25.9 °C | 58.0 % | 192.168.178.35 connected)
  MQTT2_espeasy_dht_studio (25.9 °C | 60.5 % | 192.168.178.27 sleeping)
  MQTT2_espeasy_dht_sz (25.3 °C | 59.2 % | 192.168.178.25 disconnected)
  MQTT2_espeasy_dht_wz (24.3 °C | 69.8 % | 192.168.178.29 disconnected)
  MQTT2_espeasy_io_dg  (192.168.178.30 sleeping)
  MQTT2_espeasy_io_eg  (192.168.178.4 sleeping)
  MQTT2_espeasy_io_og  (192.168.178.20 disconnected)
  MQTT2_general_bridge (closed)
  MQTT2_heizkreise     (0)
  MQTT2_shelly_luefter_bad (off 192.168.178.46 Online)
  MQTT2_shelly_luefter_wc (off 192.168.178.45 Online)
  MQTT2_shelly_wz_hifi (on 192.168.178.32 Online)
  MQTT2_shelly_wz_rgbww (off 192.168.178.32 Online)

MQTT_GENERIC_BRIDGE:
  MQTT2_generic_bridge (dev: 14 in: 40629 out: 218)

EspLedController:
  rgbww_kueche         (192.168.178.200 opened)
  rgbww_markise        (192.168.178.203 opened)
  rgbww_steinwand      (192.168.178.202 opened)

SYSSTAT:
  sys_stat             (0.04 0.07 0.08)

S7:
  CPU015               (connected to PLC)

S7_AWrite:
  blind0_CTRL_POS      (39)
  blind0_DAY_POS       (255)
  blind0_DBL_DN_POS    (35)
  blind0_DBL_UP_POS    (76)
  blind0_EARLIEST_LATE_UP (28800000)
  blind0_EARLIEST_UP   (25200000)
  blind0_NIGHT_POS     (35)
  blind0_SHADE_HORZ1   (160)
  blind0_SHADE_HORZ2   (295)
  blind0_SHADE_POS     (76)
  blind0_SHADE_VERT    (10)
  blind0_T_DN          (23500)
  blind0_T_MAX         (28500)
  blind0_T_UP          (26500)
  blind1_CTRL_POS      (255)
  blind1_DAY_POS       (255)
  blind1_DBL_DN_POS    (32)
  blind1_DBL_UP_POS    (76)
  blind1_EARLIEST_LATE_UP (28800000)
  blind1_EARLIEST_UP   (25200000)
  blind1_NIGHT_POS     (32)
  blind1_SHADE_HORZ1   (148)
  blind1_SHADE_HORZ2   (295)
  blind1_SHADE_POS     (76)
  blind1_SHADE_VERT    (10)
  blind1_T_DN          (23000)
  blind1_T_MAX         (27000)
  blind1_T_UP          (25000)
  blind2_CTRL_POS      (255)
  blind2_DAY_POS       (255)
  blind2_DBL_DN_POS    (28)
  blind2_DBL_UP_POS    (112)
  blind2_EARLIEST_LATE_UP (27000000)
  blind2_EARLIEST_UP   (23400000)
  blind2_NIGHT_POS     (28)
  blind2_SHADE_HORZ1   (238)
  blind2_SHADE_HORZ2   (279)
  blind2_SHADE_POS     (28)
  blind2_SHADE_VERT    (15)
  blind2_T_DN          (16000)
  blind2_T_MAX         (20000)
  blind2_T_UP          (18000)
  blind3_CTRL_POS      (255)
  blind3_DAY_POS       (255)
  blind3_DBL_DN_POS    (35)
  blind3_DBL_UP_POS    (112)
  blind3_EARLIEST_LATE_UP (27000000)
  blind3_EARLIEST_UP   (23400000)
  blind3_NIGHT_POS     (35)
  blind3_SHADE_HORZ1   (55)
  blind3_SHADE_HORZ2   (115)
  blind3_SHADE_POS     (112)
  blind3_SHADE_VERT    (10)
  blind3_T_DN          (14000)
  blind3_T_MAX         (17000)
  blind3_T_UP          (15000)
  blind4_CTRL_POS      (255)
  blind4_DAY_POS       (255)
  blind4_DBL_DN_POS    (37)
  blind4_DBL_UP_POS    (112)
  blind4_EARLIEST_LATE_UP (27000000)
  blind4_EARLIEST_UP   (23400000)
  blind4_NIGHT_POS     (37)
  blind4_SHADE_HORZ1   (55)
  blind4_SHADE_HORZ2   (125)
  blind4_SHADE_POS     (112)
  blind4_SHADE_VERT    (10)
  blind4_T_DN          (24000)
  blind4_T_MAX         (27000)
  blind4_T_UP          (25000)

S7_DWrite:
  alarm_events_ALARM   (off)
  alarm_events_FIRE    (off)
  blind0_CTRL_DOOR     (off)
  blind0_CTRL_FETCH    (off)
  blind0_EN_AUTO_ALERT_POS (on)
  blind0_EN_AUTO_DAY_POS (on)
  blind0_EN_AUTO_DOOR_POS (on)
  blind0_EN_AUTO_NIGHT_POS (on)
  blind0_EN_AUTO_SHADE_POS (on)
  blind0_MAINTANANCE   (off)
  blind1_CTRL_DOOR     (off)
  blind1_CTRL_FETCH    (off)
  blind1_EN_AUTO_ALERT_POS (on)
  blind1_EN_AUTO_DAY_POS (on)
  blind1_EN_AUTO_DOOR_POS (off)
  blind1_EN_AUTO_NIGHT_POS (on)
  blind1_EN_AUTO_SHADE_POS (on)
  blind1_MAINTANANCE   (off)
  blind2_CTRL_DOOR     (off)
  blind2_CTRL_FETCH    (off)
  blind2_EN_AUTO_ALERT_POS (on)
  blind2_EN_AUTO_DAY_POS (on)
  blind2_EN_AUTO_DOOR_POS (off)
  blind2_EN_AUTO_NIGHT_POS (on)
  blind2_EN_AUTO_SHADE_POS (on)
  blind2_MAINTANANCE   (off)
  blind3_CTRL_DOOR     (on)
  blind3_CTRL_FETCH    (off)
  blind3_EN_AUTO_ALERT_POS (on)
  blind3_EN_AUTO_DAY_POS (on)
  blind3_EN_AUTO_DOOR_POS (off)
  blind3_EN_AUTO_NIGHT_POS (on)
  blind3_EN_AUTO_SHADE_POS (on)
  blind3_MAINTANANCE   (off)
  blind4_CTRL_DOOR     (on)
  blind4_CTRL_FETCH    (off)
  blind4_EN_AUTO_ALERT_POS (on)
  blind4_EN_AUTO_DAY_POS (on)
  blind4_EN_AUTO_DOOR_POS (on)
  blind4_EN_AUTO_NIGHT_POS (on)
  blind4_EN_AUTO_SHADE_POS (on)
  blind4_MAINTANANCE   (off)
  light_staircase_LIGHT (off)
  rgbww_kitchen_STATE_LED (off)
  rgbww_marquee_STATE_LED (off)
  weather_events_RAIN  (off)
  weather_events_SUN   (on)
  weather_events_WIND  (off)

IPCAM:
  vivotek              (Defined)

Pushover:
  pushmsg              (connected)

at:
  at_5min_periodic     (Next: 14:50:44)
  at_T_sun_shadow_changed (Next: 14:48:00)

eventTypes:
  eventTypes           (active)

notify:
  initialUsbCheck      (disabled)
  notify_015_CEFPR00_advertise (active)
  notify_MQTT2_espeasy_connected (2019-08-30 14:47:37)
  notify_MQTT2_shelly_wz_rgbww_POWER1 (active)
  notify_bell_or_buzzer (active)
  notify_ftk_open_closed (2019-08-30 14:43:46)
  notify_ftk_sabotage  (active)
  notify_rgbww_stateLight (2019-08-30 08:20:57)
  notify_sirene_alarm_sen_01 (2019-08-30 14:43:46)
  notify_sirene_arm    (active)
  notify_sirene_panic  (active)
  notify_sirene_sabotage (active)
  notify_sun_sensor_T_sun_shadow (2019-08-30 14:46:25)
  notify_switch_rgbww  (active)
  notify_temperature_aussen (2019-08-30 14:46:25)
  sys_backup_run       (active)

watchdog:
  wd_luefter_bad       (defined)
  wd_luefter_wc        (defined)

FileLog:
  Logfile              (active)

DbLog:
  logdb                (connected)

DbRep:
  repdb                (connected)

Astro:
  astro                (Updated)

HMinfo:
  hm_info              (updated:2019-08-30 14:20:46)

THRESHOLD:
  th_sun_sensor        (external 10.0)

autocreate:
  autocreate           (active)

cmdalias:
  c_dellog             (defined)
  c_grep               (defined)
  c_lastloglines       (defined)

dewpoint:
  dew_all              (active)

dummy:
  015_CEFPR00          (advertise)
  015_CEFPR00_blind_control (29% | 29% | 35% | 100% | 100%)
  015_CEFPR00_calendar (day)
  015_CEFPR00_health   (ok)
  ftk_garden_gate      (open 2019-08-30 14:42:34)
  sun_sensor           (on 22.48 °C)
  switch_bell_door     (released)
  switch_bell_mb       (released)
  switch_blind0_dn     (released)
  switch_blind0_up     (released)
  switch_blind1_dn     (released)
  switch_blind1_up     (released)
  switch_blind2_dn     (released)
  switch_blind2_up     (released)
  switch_blind3_dn     (released)
  switch_blind3_up     (released)
  switch_blind4_dn     (released)
  switch_blind4_up     (released)
  switch_buzzer_door   (released)
  switch_buzzer_mb     (released)
  switch_light_staircase (released)
  switch_rgbww_kitchen (released)
  switch_rgbww_marquee (released)
  sys_backup           (Ausführen)
  vaillant_temp        (threshold)

expandJSON:
  015_CEFPR00_expand_json (2019-08-30 14:43:46)

telnet:
  telnetPort           (Initialized)


Hier noch fhemdebug memusage


   1. defs                            1447130
   2. modules                          624926
   3. modules::eventTypes              266175
   4. attr                             265686
   5. modules::eventTypes::ldata       265113
   6. defs::HM_Sirene_Sen_01           149510
   7. defs::HM_Sirene_Sen_01::READINGS   146142
   8. modules::MQTT2_DEVICE             79051
   9. modules::MQTT2_DEVICE::defptr     77188
  10. modules::MQTT2_DEVICE::defptr::re    72848
  11. defs::astro                       44921
  12. defs::astro::READINGS             43171
  13. defs::rgbww_kueche                40570
  14. defs::rgbww_markise               40272
  15. defs::rgbww_steinwand             39547
  16. defs::MQTT2_ebusd                 37593
  17. POSIX::                           37284
  18. UConv::                           34917
  19. defs::MQTT2_ebusd::READINGS       34823
  20. defs::rgbww_kueche::READINGS      34088
  21. defs::rgbww_steinwand::READINGS    34087
  22. defs::rgbww_markise::READINGS     33896
  23. FW_cmdret                         30593
  24. defs::MQTT2_shelly_luefter_bad    28110
  25. modules::CUL_HM                   26975
  26. defs::MQTT2_shelly_luefter_bad::READINGS    26304
  27. defs::HM_Sirene_Sen_02            25760
  28. attr::WEBFLEX                     25336
  29. defs::ftk_eg1_wohnzimmer          24892
  30. defs::ftk_eg2_haustuere           24821
  31. defs::ftk_eg5_kueche              24785
  32. defs::MQTT2_generic_bridge        24379
  33. defs::ftk_eg4_kueche              24368
  34. attr::WEBFLEX::styleData          24180
  35. defs::ftk_eg0_wohnzimmer          24044
  36. defs::ftk_kg1_technikraum         24043
  37. defs::ftk_kg0_hobbyraum           24041
  38. defs::ftk_eg3_wc                  24028
  39. defs::HM_Sirene_Sen_02::READINGS    22914
  40. defs::ftk_og0_bad                 22198
  41. modules::eventTypes::ldata::pushmsg    21993
  42. defs::MQTT2_shelly_wz_rgbww       21325
  43. defs::MQTT2_shelly_wz_hifi        20933
  44. defs::MQTT2_shelly_wz_rgbww::READINGS    19527
  45. defs::MQTT2_shelly_wz_hifi::READINGS    19137
  46. modules::eventTypes::ldata::HM_Sirene_Sen_01    19082
  47. modules::eventTypes::ldata::repdb    18227
  48. defs::HM_Sirene                   18148
  49. modules::eventTypes::ldata::MQTT2_shelly_wz_hifi    17069
  50. modules::eventTypes::ldata::MQTT2_shelly_wz_rgbww    17012
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 30 August 2019, 14:59:15
Also das würde ich noch als normal bezeichnen. Wie sieht es denn nach 48 Stunden aus?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: nuccleon am 30 August 2019, 15:03:59
Zitat von: CoolTux am 30 August 2019, 14:59:15
Also das würde ich noch als normal bezeichnen. Wie sieht es denn nach 48 Stunden aus?

Naja, das kann ich übermorgen quantifizieren.

Was ich aber jetzt schon - ohne genaue Zahlen - sagen kann ist, dass der Speicherverbrauch so lange anwächst bis Cannot fork: Cannot allocate memory im Log zu finden ist.
Gefühlt ist das typischerweise nach wenigen Tagen. Meistens in dem Moment in dem ich einen update Versuch starte.

Ich wurde eben hellhörig, als in diesem Thread der Bezug zu FHEMWEB aufgekommen ist. Da ich ja auch einen sehr speziellen Anwendungsfall für FHEMWEB gefunden habe (SPS -> HTTP -> FHEMWEB -> DUMMY) dachte ich, ich klinke mich hier mal ein.

Im Moment konnte ich den Täter noch nicht näher eingrenzen :-/
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gloob am 30 August 2019, 15:16:08
Ich selbst bin ja auch heftig betroffen und habe mitlerweile fast alle Module von einem Proxmox Container in einen anderen mit FHEM Installation geklont. Im neuen Container habe ich keinen Anstieg.
An der "Hauptinstallation" hängt allerdings ein Tablet mit TabletUI und dort frisst es den Speicher extrem schnell, ca 10MB pro Stunde.

Ich werde jetzt mal versuchen das Tablet auszuschalten und den Speicher beobachten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: HomeAuto_User am 30 August 2019, 15:18:42
Da ich den Faden auch sehr verfolge, so würde mich interessieren wie man dem ganzen am besten auf die Schliche kommt.

Ja, es gibt kein eindeutiges Verfahren oder eine einheitliche Beschreibung aber womit und wie, könnte man das Phänomen verfolgen. Ich stelle fest, wenn der httpMod mit 95 Einträgen läuft, so kommt es dazu. Ist er aus, so geht es. Alles läuft ,,nur" auf einem Pi3.


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 30 August 2019, 15:19:07
Zitat von: gloob am 30 August 2019, 15:16:08
Ich selbst bin ja auch heftig betroffen und habe mitlerweile fast alle Module von einem Proxmox Container in einen anderen mit FHEM Installation geklont. Im neuen Container habe ich keinen Anstieg.
An der "Hauptinstallation" hängt allerdings ein Tablet mit TabletUI und dort frisst es den Speicher extrem schnell, ca 10MB pro Stunde.

Ich werde jetzt mal versuchen das Tablet auszuschalten und den Speicher beobachten.

Wie greift tabletui bei Dir zu? Ich habe nginx dafür genommen. Hast du httpsrv?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 30 August 2019, 15:21:06
Zitat von: HomeAuto_User am 30 August 2019, 15:18:42
Da ich den Faden auch sehr verfolge, so würde mich interessieren wie man dem ganzen am besten auf die Schliche kommt.

Ja, es gibt kein eindeutiges Verfahren oder eine einheitliche Beschreibung aber womit und wie, könnte man das Phänomen verfolgen. Ich stelle fest, wenn der httpMod mit 95 Einträgen läuft, so kommt es dazu. Ist er aus, so geht es. Alles läuft ,,nur" auf einem Pi3.


Gesendet von iPhone mit Tapatalk Pro

Ich bin extra schneller in ein Linux Container umgezogen und Arbeit mit configdb. Da kann man schnell viele Devices löschen, testen und wieder zurück drehen. Ich sichere vorher die Device Config zusätzlich als RAW Export.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gloob am 30 August 2019, 15:25:30
Zitat von: CoolTux am 30 August 2019, 15:19:07
Wie greift tabletui bei Dir zu? Ich habe nginx dafür genommen. Hast du httpsrv?

Die TabletUI Webseite öffne ich auf einem Amazon Fire HD 8.
TabletUI läuft als:

define TABLETUI HTTPSRV ftui/ ./www/tablet/ Tablet-UI

Edit:
30.08.2019 16:15 So sieht aktuell mein Speicherverlauf aus vor dem Abschalten der TableUI anzeige.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 30 August 2019, 17:18:07
Zitat von: CoolTux am 30 August 2019, 10:50:03
Ich habe etwas recherchiert. Zeitlich könnte eine Anpassung an FHEMWEB passen. Sollte also in den nächsten 60 min der Speicherverbrauch nicht weiter ansteigen werde ich in diese Richtung weiter schauen. Natürlich wird dies nun kein Problem von FHEMWEB alleine. Ich habe da meine 3 Jahre alte TabletUI Installation im Auge. Eventuell hat die Probleme mit dem neuen FHEMWEB. Aber das muss ich mir genauer anschauen.
Aktuell kann ich lediglich meine Beobachtungen kund tun.

Wann wurde denn FHEMWEB geändert? Und was?

Ich frage deshalb, weil ich seit Jänner diesen Jahres auch zu den Gepeinigten gehöre  :(
- Ich habe hier ein Backup-Image vom 12.10.2018 - damit hatte ich keinerlei Probleme.
- Im Jänner 2019 habe ich dann upgedatet (ich mache nicht jede Woche ein Update)
- seither habe ich den Speicheranstieg, obwohl sich an der FHEM-Konfiguration nichts geändert hat. Alle 19 Stunden resetted FHEM :(
- Auch am Unterbau (damals  Raspbian-Jessie) hat sich nichts geändert
- ich habe dann verschiedene Perl-Versionen versucht und bin mittlerweile auf Raspbian-Buster. Leider ohne Erfolg

In meiner Wohnung hängen 6 Tablets, welche immer mit FHEMWEB verbunden sind. Auch 3 Handys greifen sporadisch auf FHEMWEB zu.
FHEMWEB wird über einen Apache-Proxy nach außen geleitet und der Zugriff erfolgt über WebViewControl...
Da die ganze Wohnung von FHEM gesteuert wird und die Interface-Tablet benötigt werden, kann ich leider nicht einfach zu Testen die FHEMWEB´s abschalten...

Grüße,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 30 August 2019, 17:37:40
Ich möchte noch mal explizit erwähnen daß es bei mir nicht am FHEMWEB lag. Es waren zu dem Zeitpunkt nur meine Beobachtungen.
Aktuell ist es so das es anscheinend mein HAProxy ist der Abfragen in irgendeiner Form an FHEMWEB macht. Genaueres muss ich dann erst noch schauen.
An ein verschulden von FHEMWEB denke ich nicht!!!
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gloob am 30 August 2019, 17:58:56
Ein Deaktivieren der FTUI GUI hat auch keinen Erfolg gebracht
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 30 August 2019, 19:05:55
Fuer Leute mit Kommandozeilen-Erfahrung: die zweite Antwort aus https://askubuntu.com/questions/152716/how-to-detect-a-memory-leak (das mit /proc/$pid/smaps) scheint fuer mich praktikabel zu sein, wobei Schritt 7 mAn ueberfluessig ist. Ich meine eher, dass man das Verfahren (mit gebuehrenden Abstand) zweimal anwenden muss, damit man feststellen kann, was dazugekommen ist.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 30 August 2019, 20:11:43
Zitat von: rudolfkoenig am 30 August 2019, 19:05:55
Fuer Leute mit Kommandozeilen-Erfahrung: die zweite Antwort aus https://askubuntu.com/questions/152716/how-to-detect-a-memory-leak (das mit /proc/$pid/smaps) scheint fuer mich praktikabel zu sein, wobei Schritt 7 mAn ueberfluessig ist. Ich meine eher, dass man das Verfahren (mit gebuehrenden Abstand) zweimal anwenden muss, damit man feststellen kann, was dazugekommen ist.

Danke für den Tipp. Das werde ich gleich mal versuchen.
Da bei mir der Speicher innerhalb eines Tages ca. um 500MB wächst, kann ich morgen Genauers sagen...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 30 August 2019, 21:18:31
Ich kann ebenfalls bestätigen, dass ein Abdrehen aller remote Browser (FTUI) keine Auswirkung auf den Speicherverbrauch gezeigt hat. Der Raspberry selbst hat keine GUI Komponenten
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 31 August 2019, 01:05:25
Zitat von: rudolfkoenig am 30 August 2019, 19:05:55
Fuer Leute mit Kommandozeilen-Erfahrung: die zweite Antwort aus https://askubuntu.com/questions/152716/how-to-detect-a-memory-leak (das mit /proc/$pid/smaps) scheint fuer mich praktikabel zu sein, wobei Schritt 7 mAn ueberfluessig ist. Ich meine eher, dass man das Verfahren (mit gebuehrenden Abstand) zweimal anwenden muss, damit man feststellen kann, was dazugekommen ist.

Ich habe mich mal dran versucht...
Und sehe nun auch den Speicheranstieg sehr deutlich.
Das memdump habe ich auch gemacht und mir das ganze in eine Textdatei konvertiert.

Für die paar Stunden ein ganz schön satter Anstieg:

BEFORE:
01e62000-06264000 rw-p 00000000 00:00 0          [heap]
Size:              69640 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:               69488 kB
Pss:               69488 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:     69488 kB
Referenced:        69488 kB
Anonymous:         69488 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB

AFTER:
01e62000-0ce0b000 rw-p 00000000 00:00 0          [heap]
Size:             179876 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:              179580 kB
Pss:               69999 kB
Shared_Clean:          0 kB
Shared_Dirty:     164384 kB
Private_Clean:         0 kB
Private_Dirty:     15196 kB
Referenced:       179580 kB
Anonymous:        179580 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB


Tja, das memdump ist leider 175MB groß und die daraus erzeugte Textdatei 52MB!

Da sehe ich als Laie leider gar nichts drin.
Ich sehe sehr wohl meine Geräte und die Events und so, aber das ist einfach zu umfangreich.
Wonach sollte man da suchen?

Vielen Dank,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 31 August 2019, 08:34:02
In memdump 0x06264000 - 0x0ce0b000 muessten nur die neu hinzugekommenen Texte vorhanden sein. Was sieht man da?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 31 August 2019, 12:46:35
Mann Mann Mann  :-[

War aber auch logisch... Und ich habe den ganzen Speicherbereich ausgelesen...
Ich mach noch eine Messung und messe vom Ende des ersten auf das Ende des zweiten Speicherbereichs.

Danke für die Unterstützung,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 31 August 2019, 14:40:15
So, ich habe nun einen zweiten Dump angefertigt - Messzeitraum habe ich kürzer gewählt und die Memory-Bereiche habe ich angepasst
-> die neue Datei hat leider 15MB  :o

Also habe ich einen dritten Dump angefertigt - Messzeitraum ein paar Minuten
-> diese Datei hat "nur" 1,4MB

Auch habe ich mir beide Text-Auszüge angesehen, stoße mangels Tiefenkenntnissen aber wieder an meine Grenzen...  :(
Ich "denke", dass ich immer wieder den Aufruf meines in FHEMWEB angezeigten Raummenüs in der 1,4MB-Datei erkenne.
(wie beschrieben, sind bei mir ja auch 6 Tablets ständig mit FHEM verbunden)
Kann aber auch sein, daß ich gar nichts sehe und meine Messergebnisse gar nicht aussagekräftig sind...  :)

In der 15MB-Datei ist noch etwas mehr zu sehen...
(die Datei hänge ich mal komprimiert an)

Vielleicht ist jemand so nett und sieht mit seinem fachkundigem Auge mal drüber?
Ich trete hier wie gesagt leider auf der Stelle...


LG,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 01 September 2019, 17:40:16
Danke fuer den Dump.

Nach studieren der Daten und Quellcode suchen meine ich ein Speicherloch aus FHEMWEB entfernt zu haben, was auftritt falls eine Raumuebersicht mit "FW_atPageEnd" Modulen aufgerufen wird (readingsGroup, readingsHistory, FB_CALLLIST, weblink, weekprofile). Auch SVG gehoert dazu, falls plotfork oder plotEmbed nicht gesetzt ist.
Ursache: in diesen Faellen wurden Daten aus einer Modul-Lokalen-Variable nicht entfernt.

Workaround: reload 01_FHEMWEB duerfte das Problem (temporaer) beheben, und Speicher freigeben, das sieht man in der "ps -elf" Ausgabe sofort.

Bei der Fehlersuche habe ich leider feststellen muessen, dass fhemdebug memusage solche Variablen nicht sieht, deswegen ist die Aussagekraft begrenzter, als ich es dachte.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gloob am 01 September 2019, 18:16:46
Zitat von: rudolfkoenig am 01 September 2019, 17:40:16
Danke fuer den Dump.

Nach studieren der Daten und Quellcode suchen meine ich ein Speicherloch aus FHEMWEB entfernt zu haben, was auftritt falls eine Raumuebersicht mit "FW_atPageEnd" Modulen aufgerufen wird (readingsGroup, readingsHistory, FB_CALLLIST, weblink, weekprofile). Auch SVG gehoert dazu, falls plotfork oder plotEmbed nicht gesetzt ist.
Ursache: in diesen Faellen wurden Daten aus einer Modul-Lokalen-Variable nicht entfernt.

Workaround: reload 01_FHEMWEB duerfte das Problem (temporaer) beheben, und Speicher freigeben, das sieht man in der "ps -elf" Ausgabe sofort.

Bei der Fehlersuche habe ich leider feststellen muessen, dass fhemdebug memusage solche Variablen nicht sieht, deswegen ist die Aussagekraft begrenzter, als ich es dachte.

Das klingt ja nach einer vielversprechenden Lösung, super Arbeit.
Ab morgen dann im Update?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Maista am 01 September 2019, 18:28:31
Ja :D

https://forum.fhem.de/index.php/topic,103416.0.html
(https://forum.fhem.de/index.php/topic,103416.0.html)

Gruss
Gerd
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 01 September 2019, 18:35:32
Zitat von: rudolfkoenig am 01 September 2019, 17:40:16
Danke fuer den Dump.

Keine Ursache, immer gern. Solange ich halbwegs durchsteige, bin ich zu allen Schandtaten bereit :)

Ich möchte mich im Gegenzug aber für all die Mühe und Arbeit bedanken, die Du in dieses echt endgeile Projekt steckst.
Ist sicher nicht immer einfach und lustig und darum VIELEN DANK fürs Erschaffen dieser tollen Smarthome-Basis

LG,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 01 September 2019, 19:41:39
Das reload 01_FHEMWEB hilft bei mir leider nicht...
Bin gespannt wie es morgen nach einem update ausschaut - Danke das unermüdlich gesucht und gefunden wird...
reload 01_FHEMWEB gegen 18 Uhr 30 ausgeführt...
Normalerweise schaut es nach einem "shutdown restart wie auf dem zweitem Bild aus...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gloob am 02 September 2019, 08:26:50
So ich habe heute früh ein Update ausgeführt und aktuell sieht es deutlich besser aus als gestern.
Leider habe ich parallel zum Update auch Freezemon rausgeworfen. Es kann aktuell also eines der beiden gewesen sein.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gloob am 02 September 2019, 17:39:32
Also ich habe es jetzt auf 2 Instanzen seit heute früh am laufen und keine Probleme mit Speicherzuwachs.
Vielen Dank für die super Arbeit an alle Beteiligten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 02 September 2019, 17:49:47
Hallo gloob,

hattest du auch apptime, zusammen mit Frezemon installiert?

Bei mir war das Problem vor einigen Monaten, von heute auf morgen wie weggeblasen, als ich Freezemon und apptime (zwingend mit shutdown restart) entfernt hatte. https://forum.fhem.de/index.php/topic,84372.msg790403.html#msg790403 (https://forum.fhem.de/index.php/topic,84372.msg790403.html#msg790403)

Ab diesem Zeitpunkt hatte ich keinerlei Probleme, bis zum heutigen Tag mehr.

Wie gesagt bei meiner Installation und den Modulen welche ich verwende. Bei anderen Anwendern sind die Probeme jedoch nie verschwunden und die Ursache für das Problem scheint sehr vielschichtig zu sein.

Danke an die unermüdliche Arbeit der Experten, auch wenn ich nicht mehr betroffen war, ich habe immer mit euch mitgelitten.

Gruß Reinhard
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: gloob am 02 September 2019, 17:53:54
Ich hatte Freezemon mal installiert, allerdings mit dem Update heute früh wieder entfernt.
Zur Gegenprobe habe ich vor 2 Stunde Freezemon nochmal hinzugefügt und kann aber trotzdem keinen Anstieg feststellen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Eistee am 02 September 2019, 20:32:42
Habe gerade das Update von FHEMWEB installiert.
Im Bild der RAM Verlauf von meinem FHEM mit dem DOIF welches bei "cannot fork" automatisch einen reboot auslöst.
Ich werde berichten ob sich was verbessert.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 03 September 2019, 06:53:03
In meiner Konfiguration hat das Update leider nicht geholfen.

Die Liste der geladenen Module:
Latest Revision: 20089

File                 Rev   Last Change

fhem.pl              20069 2019-08-27 08:36:02Z rudolfkoenig
96_allowed.pm        20069 2019-08-27 08:36:02Z rudolfkoenig
95_Astro.pm          19817 2019-07-11 14:04:24Z loredo
90_at.pm             17561 2018-10-18 14:45:30Z rudolfkoenig
98_autocreate.pm     19372 2019-05-11 15:13:59Z rudolfkoenig
70_BOTVAC.pm         19592 2019-06-10 17:45:38Z vuffiraa
70_BRAVIA.pm         19191 2019-04-15 17:40:25Z vuffiraa
57_Calendar.pm       19937 2019-08-02 19:03:44Z neubert
98_cmdalias.pm       16300 2018-03-01 08:48:21Z rudolfkoenig
00_CUL.pm            17559 2018-10-18 07:45:07Z rudolfkoenig
10_CUL_HM.pm         19983 2019-08-11 13:48:33Z martinp876
93_DbLog.pm          20059 2019-08-25 15:55:19Z DS_Starter
93_DbRep.pm          20074 2019-08-27 21:39:26Z DS_Starter
98_DOIF.pm           19786 2019-07-05 21:47:08Z Damian
98_DOIFtools.pm      19948 2019-08-04 15:53:01Z Ellert
98_dummy.pm          19585 2019-06-09 08:04:48Z rudolfkoenig
70_EGPM.pm           14071 2017-04-22 12:13:43Z alexus
17_EGPM2LAN.pm       14071 2017-04-22 12:13:43Z alexus
91_eventTypes.pm     14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm        20089 2019-09-01 15:17:06Z rudolfkoenig
92_FileLog.pm        19102 2019-04-02 19:48:57Z rudolfkoenig
95_FLOORPLAN.pm      13735 2017-03-19 12:43:53Z UliM
89_FULLY.pm          19966 2019-08-08 20:24:24Z zap
20_GUEST.pm          19533 2019-06-02 19:33:11Z loredo
98_HMinfo.pm         19495 2019-05-30 09:17:45Z martinp876
22_HOMEMODE.pm       19955 2019-08-05 21:01:55Z DeeSPe
98_HTTPMOD.pm        19978 2019-08-10 12:51:48Z StefanStrobel
02_HTTPSRV.pm        16874 2018-06-15 17:18:55Z neubert
49_IPCAM.pm          18505 2019-02-05 21:50:23Z rudolfkoenig
10_Itach_IR.pm       10723 2016-02-04 18:13:54Z ulimaass
88_Itach_IRDevice.pm 10723 2016-02-04 18:13:54Z ulimaass
98_JsonList2.pm      17230 2018-08-30 13:03:48Z rudolfkoenig
70_KODI.pm           19982 2019-08-11 09:55:36Z vbs
93_Log2Syslog.pm     19905 2019-07-28 10:42:28Z DS_Starter
91_notify.pm         19374 2019-05-11 17:48:03Z rudolfkoenig
34_NUT.pm             9023 2015-08-05 09:00:12Z narsskrarc
73_PRESENCE.pm       18314 2019-01-18 13:49:05Z markusbloch
59_PROPLANTA.pm      18714 2019-02-24 16:08:46Z tupol
33_readingsGroup.pm  19774 2019-07-04 14:10:53Z justme1968
33_readingsProxy.pm  16299 2018-03-01 08:06:55Z justme1968
10_RESIDENTS.pm      19533 2019-06-02 19:33:11Z loredo
20_ROOMMATE.pm       19533 2019-06-02 19:33:11Z loredo
No Id found for 17_SIRD.pm
37_Spotify.pm        16967 2018-07-09 16:02:50Z neumann
98_structure.pm      19809 2019-07-09 20:56:14Z rudolfkoenig
99_SUNRISE_EL.pm     18732 2019-02-25 13:15:34Z rudolfkoenig
42_SYSMON.pm         17227 2018-08-29 19:58:18Z hexenmeister
50_TelegramBot.pm    19451 2019-05-23 07:51:03Z viegener
98_telnet.pm         17529 2018-10-14 12:57:06Z rudolfkoenig
45_TRX.pm            18738 2019-02-25 21:56:28Z KernSani
46_TRX_LIGHT.pm      19312 2019-05-01 21:27:31Z KernSani
46_TRX_WEATHER.pm    18095 2018-12-30 14:37:23Z KernSani
74_Unifi.pm          19989 2019-08-12 18:25:21Z wuehler
74_UnifiClient.pm    19989 2019-08-12 18:25:21Z wuehler
74_UnifiSwitch.pm    20018 2019-08-18 18:58:36Z wuehler
99_Utils.pm          18920 2019-03-16 09:58:52Z rudolfkoenig
77_UWZ.pm            19869 2019-07-20 13:59:38Z CoolTux
98_version.pm        15140 2017-09-26 09:20:09Z markusbloch
91_watchdog.pm       16963 2018-07-09 07:40:22Z rudolfkoenig
98_WeekdayTimer.pm   19806 2019-07-09 16:52:45Z Beta-User
10_ZWave.pm          20052 2019-08-24 16:01:41Z rudolfkoenig
00_ZWDongle.pm       19856 2019-07-19 18:00:04Z rudolfkoenig

AttrTemplate.pm      19085 2019-04-01 17:00:24Z rudolfkoenig
Blocking.pm          17553 2018-10-17 15:56:35Z rudolfkoenig
Color.pm             18481 2019-02-02 09:35:08Z justme1968
DevIo.pm             19372 2019-05-11 15:13:59Z rudolfkoenig
GPUtils.pm           19666 2019-06-20 11:17:29Z CoolTux
HMConfig.pm          19226 2019-04-20 06:54:28Z martinp876
HttpUtils.pm         20037 2019-08-21 05:34:45Z rudolfkoenig
Meta.pm              20009 2019-08-17 11:06:17Z loredo
myUtilsTemplate.pm    7570 2015-01-14 18:31:44Z rudolfkoenig
RESIDENTStk.pm       19788 2019-07-06 08:10:55Z loredo
RTypes.pm            10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm     19208 2019-04-17 19:27:09Z rudolfkoenig
SubProcess.pm        14334 2017-05-20 23:11:06Z neubert
TcpServerUtils.pm    19138 2019-04-07 10:17:21Z rudolfkoenig
UConv.pm             19770 2019-07-03 15:58:46Z loredo
Unit.pm              19614 2019-06-13 23:11:25Z loredo
ZWLib.pm             17186 2018-08-20 20:10:55Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
f18.js                     20069 2019-08-27 08:36:02Z rudolfkoenig
fhemweb.js                 19957 2019-08-06 09:10:17Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968



Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 03 September 2019, 07:11:53
Dann wirst Du nicht drum rum kommen selbst aktiv zu werden.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 03 September 2019, 07:13:58
Bei mir ist es zwar besser geworden - aber nicht ganz weg...
Update und Shutdown restart deutlich zu erkennen gestern gegen 17 Uhr 30.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 03 September 2019, 07:16:50
Zitat von: der-Lolo am 03 September 2019, 07:13:58
Bei mir ist es zwar besser geworden - aber nicht ganz weg...
Update und Shutdown restart deutlich zu erkennen gestern gegen 17 Uhr 30.

Und woran erkennst Du das FHEM den Speicher beansprucht? Was sagt z.B. top wie viel fhem beansprucht?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: clumsy am 03 September 2019, 08:02:07
Ich kann bei mir ein ähnliches Verhalten feststellen, mit diversen symptomen wie dass z.b. Module welche TCP connections entgegennehmen nicht mehr (schnell genug) antworten, kein DBLog mehr geschrieben wird, etc.

Der Memoryverbruach unmittelbar nach dem Start ist ca. 180MB (laut top/ps), nach 24h ca. 2GB....

Ich werd auch mal versuchen mit Memorydumps/Analysen einzugrenzen was es sein könnte, wobei meine Kentnisse in Memdumps zu analysieren sehr beschränkt sind... wenn ichs einigermassen eingrenzen kann, würde ich es hier posten..

PS: ein reload von FHEMWEB ändert nichts am Memoryverbrauch...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 03 September 2019, 08:40:02
ZitatPS: ein reload von FHEMWEB ändert nichts am Memoryverbrauch...
Mein Speicherloch-Fix hilft nur in in den vorher genannten Faellen, in meiner "Produktion" z.Bsp. gar nicht.
Den Ausloeser habe ich am 2018-07-15 eingebaut, die Diskussion hier hat aber schon im Februar 2018 angefangen, d.h. es sind mehrere Ursachen fuer "unser" Speicherloch verantwortlich.

Neben der Memorydump Methode gibt es eine Andere, was beim Lokalisieren helfen koennte: nacheinander fuer alle Module ein "reload modulname" durchfuehren, und vorher/nachher z.Bsp. mit
Zitatps -elf | grep -v awk | awk '/fhem.pl/{print $10}'
den Speicherverbrauch vergleichen. Ich kann zwar nicht garantieren, dass reload keine Nebeneffekte hat, es wird aber zeigen, ob das Modul eine signifikante Datenmenge in Moduleigenen (my) Variablen haelt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: clumsy am 03 September 2019, 08:44:07
Zitat von: rudolfkoenig am 03 September 2019, 08:40:02
Neben der Memorydump Methode gibt es eine Andere, was beim Lokalisieren helfen koennte: nacheinander fuer alle Module ein "reload modulname" durchfuehren, und vorher/nachher z.Bsp. mitden Speicherverbrauch
Ah, gute idee, werd ich auch mal noch machen... habs jetzt heute morgen neu gestartet und in regelmässigen abständen mal ein dump der smap gemacht.

Ich verwende FHEMWEB schon auch relativ rege plus noch einiges anderes (wohl eher selten gebruachtes), evtl. ist da ja was dabei.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 03 September 2019, 19:42:54
Ich habe es nun mit dem neuen FHEMWEB eine Weile laufen lassen...

Ergebnis ist eine leichte Verbesserung. Statt alle 16 Stunden startet fhem nun nach 20 Stunden neu.
(bei fhem-Start werden 180MB RAM belegt und bei 600MB wird per DOIF fhem neu gestartet)

ich habe auch den Tipp mit "reload MODULE" versucht und alle meine Module einzeln nacheinnander neu geladen.
Latest Revision: 20089

File                   Rev   Last Change

fhem.pl                20069 2019-08-27 08:36:02Z rudolfkoenig
No Id found for 36_AliRF.pm
34_APCUPSD.pm          10167 2015-06-22 12:28:01Z premultiply
90_at.pm               17561 2018-10-18 14:45:30Z rudolfkoenig
57_Calendar.pm         19937 2019-08-02 19:03:44Z neubert
57_CALVIEW.pm          17605 2018-10-23 16:37:40Z chris1284
38_CO20.pm             14433 2017-05-30 20:29:44Z moises
00_CUL.pm              17559 2018-10-18 07:45:07Z rudolfkoenig
10_CUL_HM.pm           19983 2019-08-11 13:48:33Z martinp876
14_CUL_MAX.pm          12440 2016-10-26 20:24:45Z mgehre
14_CUL_REDIRECT.pm     18358 2019-01-20 20:21:05Z bjoernh
14_CUL_TX.pm           17102 2018-08-08 05:34:42Z rudolfkoenig
98_dewpoint.pm         18846 2019-03-10 11:45:58Z hotbso
98_DOIF.pm             19786 2019-07-05 21:47:08Z Damian
98_dummy.pm            19585 2019-06-09 08:04:48Z rudolfkoenig
91_eventTypes.pm       14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm          20089 2019-09-01 15:17:06Z rudolfkoenig
92_FileLog.pm          19102 2019-04-02 19:48:57Z rudolfkoenig
14_FLAMINGO.pm         18657 2019-02-19 21:02:24Z HomeAuto_User
14_Hideki.pm           18671 2019-02-20 20:38:21Z Sidey
00_HMUARTLGW.pm        18838 2019-03-09 20:40:14Z mgernoth
98_HourCounter.pm      11307 2016-04-25 08:02:06Z rudolfkoenig
98_HTTPMOD.pm          19978 2019-08-10 12:51:48Z StefanStrobel
02_HTTPSRV.pm          16874 2018-06-15 17:18:55Z neubert
49_IPCAM.pm            18505 2019-02-05 21:50:23Z rudolfkoenig
10_IT.pm               19761 2019-07-02 18:37:03Z bjoernh
36_JeeLink.pm          14707 2017-07-13 18:08:33Z justme1968
36_LaCrosse.pm         18149 2019-01-05 19:36:58Z HCS
82_LGTV.pm              2076 2012-11-04 13:49:43Z rudolfkoenig
98_logProxy.pm         17587 2018-10-22 07:18:30Z justme1968
10_MAX.pm              16847 2018-06-10 18:42:19Z rudolfkoenig
No Id found for 99_myUtils.pm
91_notify.pm           19374 2019-05-11 17:48:03Z rudolfkoenig
41_OREGON.pm           18660 2019-02-19 22:44:37Z Sidey
59_PROPLANTA.pm        18714 2019-02-24 16:08:46Z tupol
33_readingsGroup.pm    19774 2019-07-04 14:10:53Z justme1968
95_remotecontrol.pm    10724 2016-02-04 18:17:33Z ulimaass
No Id found for 19_Revolt.pm
93_RFHEM.pm            15058 2017-09-12 19:30:29Z chris1284
# $Id: 99_serial.pm $ 06/16/2013
00_SIGNALduino.pm      19857 2019-07-19 18:00:16Z Sidey
98_Siro.pm             19825 2019-07-14 08:05:23Z Byte09
No Id found for 74_StreamRadio.pm
98_structure.pm        19809 2019-07-09 20:56:14Z rudolfkoenig
99_SUNRISE_EL.pm       18732 2019-02-25 13:15:34Z rudolfkoenig
98_SVG.pm              19688 2019-06-23 07:17:03Z rudolfkoenig
42_SYSMON.pm           17227 2018-08-29 19:58:18Z hexenmeister
98_telnet.pm           17529 2018-10-14 12:57:06Z rudolfkoenig
No Id found for 99_TimeUtils.pm
99_Utils.pm            18920 2019-03-16 09:58:52Z rudolfkoenig
# $Id: 99_UtilsHourCounter.pm 2014-12-16 20:15:33 john $
No Id found for 99_UtilsMaxProf.pm
98_version.pm          15140 2017-09-26 09:20:09Z markusbloch
59_Weather.pm          19628 2019-06-15 07:49:18Z CoolTux
98_weblink.pm          16293 2018-02-28 21:33:57Z rudolfkoenig
No Id found for 95_WebViewControl.pm
32_WifiLight.pm        15907 2018-01-16 20:58:44Z herrmannj
98_WOL.pm              18573 2019-02-12 21:42:18Z KernSani
80_xxLG7000.pm          2076 2012-11-04 13:49:43Z rudolfkoenig

AttrTemplate.pm        19085 2019-04-01 17:00:24Z rudolfkoenig
Blocking.pm            17553 2018-10-17 15:56:35Z rudolfkoenig
Color.pm               18481 2019-02-02 09:35:08Z justme1968
DarkSkyAPI.pm          19628 2019-06-15 07:49:18Z CoolTux
DevIo.pm               19372 2019-05-11 15:13:59Z rudolfkoenig
GPUtils.pm             19666 2019-06-20 11:17:29Z CoolTux
HMConfig.pm            19226 2019-04-20 06:54:28Z martinp876
HttpUtils.pm           20037 2019-08-21 05:34:45Z rudolfkoenig
No Id found for MaxCommon.pm
RTypes.pm              10476 2016-01-12 21:03:33Z borisneubert
No Id found for SD_ProtocolData.pm
No Id found for SD_Protocols.pm
SetExtensions.pm       19208 2019-04-17 19:27:09Z rudolfkoenig
SubProcess.pm          14334 2017-05-20 23:11:06Z neubert
TcpServerUtils.pm      19138 2019-04-07 10:17:21Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 19957 2019-08-06 09:10:17Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968


Den Speicher habe ich immer vor und nach Modul-Loading mit dem vorgeschlagenen Befehl kontrolliert
ps -elf | grep -v awk | awk '/fhem.pl/{print $10}'

Ich konnte bei der Prozedur nur minimale Veränderungen feststellen (Beispiel:  111375 zu 111494 zu 112356 und so fort... Neu gestartet: 25014)
Eine regelrechten Speichereinbruch konnte ich nicht ausmachen...


LG,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 03 September 2019, 19:45:49
Ich habe für jedes Modul der Liste ein "reload" durchgeführt.
Die einzige Speicherreduktion von ca 10MB ergab sich, als ich ein reload auf 93_DbLog durchgeführt habe.


Ein anderer Ansatz:

root:/opt# ps -aef |grep perl
fhem     11460     1  3 17:45 ?        00:02:03 /usr/bin/perl fhem.pl fhem.cfg
fhem     17579 11460  5 18:38 ?        00:00:00 /usr/bin/perl fhem.pl fhem.cfg
root     17588  4463  0 18:38 pts/0    00:00:00 grep perl


root:~# cat /proc/17579/maps
00010000-001b4000 r-xp 00000000 b3:02 2188       /usr/bin/perl
001c3000-001c4000 r--p 001a3000 b3:02 2188       /usr/bin/perl
001c4000-001c6000 rw-p 001a4000 b3:02 2188       /usr/bin/perl
00209000-00999000 rw-p 00000000 00:00 0          [heap]
00999000-08599000 rw-p 00000000 00:00 0          [heap]
08599000-12c66000 rw-p 00000000 00:00 0          [heap]
6db74000-70264000 rw-p 00000000 00:00 0
...
...
75b32000-75c33000 rw-p 00000000 00:00 0
75cb4000-75e15000 rw-p 00000000 00:00 0
75e56000-75e5b000 r-xp 00000000 b3:02 368493     /usr/lib/arm-linux-gnueabihf/perl5/5.24/auto/XML/Bare/Bare.so
...
...


Memory Dump der heap Segmente

gdb --pid 17579
dump memory /opt/output 0x00209000 0x00999000

strings /opt/output > s
sort s |uniq -cd >sc

Häufigkeit der Strings sortiert (Auszug der meisten Vorkommen)
Von 31424 String mit Count > 2 sind 31000 weniger als 1000 Mal in der Liste.

13104   auto
14539   switch0102
14786   e: swit
14792   switch0201
16203   FULLY
16272   0.00
16356   disconnected
29143   ZWAVE
30101   switch0101
49009   sing ev
60180   UNIFISWITCH
73344   UnifiController
236674   UNIFI



Was ich auch noch gefunden habe (mit Timestamp versehen - daher nur Vorkommen 1)
"2019-09-03 14:58:15|UnifiController|UNIFI|-AP_switch0102_state: ok|-AP_switch0102_state|ok|"

root:/opt# cat s |grep "AP_switch0102_state" |wc -l
743


Vielleicht kann jemand aus diesen Daten Schlüsse ziehen?
Ich habe die UNIFI-Definitionen auskommentiert und warte mal ab
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 04 September 2019, 00:51:24
In welchem Zusammenhang verwendest du XML::bare? Wenn man das falsch verwendet, erzeugt das auf jeden Fall Memory leaks, weil die Library einen Bug hat.

https://rt.cpan.org/Ticket/Display.html?id=90562 (https://rt.cpan.org/Ticket/Display.html?id=90562)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 04 September 2019, 06:27:34
Seit gestern Abend gibt es keinen Anstieg im Speicherverbrauch mehr. Das Auskommentieren des UNIFI-Controllers und der Switch-Definitionen hat bei mir scheinbar geholfen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 04 September 2019, 09:31:19
Was für ein System?
Perl-Version?

Auf meinem "Speicher-Testsystem" mit "nur" UnifiControler, UnifiClient, Tradfri, Zoneminder kann ich nichts dergleichen beobachten...

Raspberry PI 3 (ohne Plus), Stretch und Perl v5.24.1

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: clumsy am 04 September 2019, 10:57:55
Nach ersten erkentnissen hat u.a. auch das DbLog evtl. noch Probleme. Nach 12h steigt der Memoryverbrauch von FHEM von 180M auf 1100M an. Nach einem Reload von DbLog sind es immerhin nur noch 900M... den Rest konnte ich noch nicht lokalisieren.

So wies aussieht ist das Problem wohl an mehreren orten. Evtl. sogar in einem drunterliegenden verwendeten Perl-Modul (ich verwende 5.28.1).
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: JoeALLb am 04 September 2019, 11:08:44
Zitat von: clumsy am 04 September 2019, 10:57:55
Nach 12h steigt der Memoryverbrauch von ...

Nun, bist Du dir da sicher? DbLog benötigt für das Cachen der Logeinträge natürlich Speicher, vermutlich deshalb auch mehr speicher als andere Module.
Aber dass der Speicher unkontrolliert anwächst stelle ich nicht fest!
Ich kenne diese Schwierigkeiten auch im Zusammenhang mit anderen Modulen, habe diese aber mittlerweile deaktiviert und komme so auf sehr lange Uptimezeiten....

Joe
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: clumsy am 04 September 2019, 11:31:14
Zitat von: JoeALLb am 04 September 2019, 11:08:44
Nun, bist Du dir da sicher?
Nein, bin ich natürlich nicht, deshalb bin ich am suchen... ;)

Zitat von: JoeALLb am 04 September 2019, 11:08:44
DbLog benötigt für das Cachen der Logeinträge natürlich Speicher, vermutlich deshalb auch mehr speicher als andere Module.
Das ist klar, dann müsste es aber immer in etwa gleich viel sein, was nach einem reload des DbLogs weggeht... aber je länger ich warte desto mehr reduziert der reload von DbLog das Memory...

Aber klar, alles nur heuristische Behauptungen bisher... es muss irgendwo noch etwas sein (zum. bei mir) da es so ca. 1M/min. ansteigt (ca. 1GB nach 12h)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 04 September 2019, 11:36:44
Wie Joe schon schrieb müsst ihr bei DbLog berücksichtigen ob ihr es im asynchronen oder synchronen mode betreibt. Je nachdem wie oft ihr im asynchronen mode die update Zeiten eingestellt habt, werden die Daten in der Zwischenzeit im Speicher gehalten und dann gelöscht. Es gibt dann also ein ständiges Auf und Ab des Speichers. (200 MB wären aber m.M. nach zuviel) Ein permanentes Ansteigen des Speichers darf aber nicht auftreten.
Wenn ihr unsicher seid, deaktiviert den asynchronen mode temporär. Dann werden die Daten nicht gecached.

Wichtig ist auch noch zu wissen, das unterschiedliche Datenbankbibliotheken je nach verwendeten DB-Typ vom Modul genutzt werden. Sollte dort ein Leak verborgen sein, würde ein MySql User zum Beispiel kein Problem haben, ein Postgre User eventuell. Nur damit ihr das etwas einordnen könnt und nicht global "draufspringt".

Ich behalte es trotzdem mal im Hinterkopf bzw. hatte wegen dieser Problematik in der Vergangenheit bereits im Modul geschaut aber bisher keine verdächtigen Stellen erkennen können.

Grüße,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: clumsy am 04 September 2019, 11:40:13
Zitat von: DS_Starter am 04 September 2019, 11:36:44
Wie Joe schon schrieb müsst ihr bei DbLog berücksichtigen ob ihr es im asynchronen oder synchronen mode betreibt. Je nachdem wie oft ihr im asynchronen mode die update Zeiten eingestellt habt, werden die Daten in der Zwischenzeit im Speicher gehalten und dann gelöscht. Es gibt dann also ein ständiges Auf und Ab des Speichers. (200 MB wären aber m.M. nach zuviel) Ein permanentes Ansteigen des Speichers darf aber nicht auftreten.
Wenn ihr unsicher seid, deaktiviert den asynchronen mode temporär. Dann werden die Daten nicht gecached.

Wichtig ist auch noch zu wissen, das unterschiedliche Datenbankbibliotheken je nach verwendeten DB-Typ vom Modul genutzt werden. Sollte dort ein Leak verborgen sein, würde ein MySql User zum Beispiel kein Problem haben, ein Postgre User eventuell. Nur damit ihr das etwas einordnen könnt und nicht global "draufspringt".

Absolut klar, ist ja auch keine Kritik am Modul oder gar eine "Schuldzuweisung" ;)

Ich verwende MySQL (resp. MariaDB), da gabs auch immermalwieder probleme bei den connectoren... das kann natürlich auch sein..

Werd aber mal auf synchron umstellen, mal sehen was dann passiert..

Und danke schonmal erstens für die Hilfe und zweitens fürs Modul ;)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 04 September 2019, 11:44:10
ZitatAbsolut klar, ist ja auch keine Kritik am Modul oder gar eine "Schuldzuweisung" ;)
Alles gut, habe ich auch nicht so verstanden.   :) Wir tappen ja alle irgendwie im Dunkeln und versuchen etwas zu finden was weiterhilft. Und kann ja auch hier noch etwas verborgen sein, nobody is perfect !
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: HomeAuto_User am 04 September 2019, 17:30:14
Hallo,
ich melde mich auch noch einmal zu Wort.
Ich habe mal ein Update gemacht, nachdem Rudi etwas fixte.

Bei dem Modeul HTTP Mod welcher 99 Readings auslesen soll bringt das ganze nicht. Ich kann auf jedenfalll reproduzieren, wenn ich das Modul auf disable 1 stelle, das mein System läuft. Wenn ich das Modul laufen lasse und disable deaktiere, so kommt der Fehler Cannot fork: Cannot allocate memory nach kurzer Zeit. Ich denke wir suchen einen Prozess der intern von Perl verwendet wird und zu dem Fehler führt.

Ich kann es nur wiederholen, wenn man mir Input´s geben könnte, wie man das ganze erforschen kann, so bin ich gern bereit aktiv mit zu helfen.
Gibt es Ideen oder Programmteile in Perl welche unter Verdacht sind?

MfG

PS: Bis dato folgt nun wieder Modul auf disable == 1 .... ist aber nur ein Workaround :-(
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 04 September 2019, 17:46:27
Mein System: Raspberry 3B+, Stretch
FHEM: Server started with 318 defined entities (fhem.pl:20069/2019-08-27 perl:5.024001 os:linux user:fhem pid:3769)

Seit gestern Abend ist die Speicherkurve sehr flach (um 17:05 war der Cron-Restart, den ich heute wieder stillgelegt habe)
Ich hoffe, dass das System nun ein paar Tage durchläuft. Danach werde ich nochmal einen MemoryDump ziehen.

Danach werde ich nur den UNIFI-Controller wieder einbinden ohne die Definitionen für die Switches.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 04 September 2019, 17:58:06
Zitat von: HomeAuto_User am 04 September 2019, 17:30:14
Hallo,
ich melde mich auch noch einmal zu Wort.
Ich habe mal ein Update gemacht, nachdem Rudi etwas fixte.

Bei dem Modeul HTTP Mod welcher 99 Readings auslesen soll bringt das ganze nicht. Ich kann auf jedenfalll reproduzieren, wenn ich das Modul auf disable 1 stelle, das mein System läuft. Wenn ich das Modul laufen lasse und disable deaktiere, so kommt der Fehler Cannot fork: Cannot allocate memory nach kurzer Zeit. Ich denke wir suchen einen Prozess der intern von Perl verwendet wird und zu dem Fehler führt.

Ich kann es nur wiederholen, wenn man mir Input´s geben könnte, wie man das ganze erforschen kann, so bin ich gern bereit aktiv mit zu helfen.
Gibt es Ideen oder Programmteile in Perl welche unter Verdacht sind?

MfG

PS: Bis dato folgt nun wieder Modul auf disable == 1 .... ist aber nur ein Workaround :-(


Zitat von: rudolfkoenig am 30 August 2019, 19:05:55
Fuer Leute mit Kommandozeilen-Erfahrung: die zweite Antwort aus https://askubuntu.com/questions/152716/how-to-detect-a-memory-leak (das mit /proc/$pid/smaps) scheint fuer mich praktikabel zu sein, wobei Schritt 7 mAn ueberfluessig ist. Ich meine eher, dass man das Verfahren (mit gebuehrenden Abstand) zweimal anwenden muss, damit man feststellen kann, was dazugekommen ist.


Rudis Link ist doch gut beschrieben. Haben sogar ein paar Leute ohne Nachfrage hinbekommen.
Solltest Du da Probleme mit haben müsstest Du bitte warten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 04 September 2019, 17:59:13
ZitatBei dem Modeul HTTP Mod welcher 99 Readings auslesen soll bringt das ganze nicht.
Das wuerde auch an einem Wunder grenzen, da ich nur FHEMWEB angefasst habe.

ZitatIch kann es nur wiederholen, wenn man mir Input´s geben könnte, wie man das ganze erforschen kann, so bin ich gern bereit aktiv mit zu helfen.
Ich kann ja auch nur wiederholen :)
- /proc/$pid/smaps auslesen (https://forum.fhem.de/index.php/topic,84372.msg970863.html#msg970863)
- Modul mit reload pruefen (https://forum.fhem.de/index.php/topic,84372.msg971563.html#msg971563)


Uebrigens ist es nicht so, dass wir ganz genau wissen,wie man die Ursache findet, und wir es nur nicht verraten wollen.
Eher andersherum: wir tappen weiterhin im dunkeln. Ich habe nur eins der vielen unterschiedlichen Loecher gestopft, die jeweils nur wenige Leute betreffen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 04 September 2019, 18:09:13
@Hardlife: koenntest bitte mit dem neuen FHEMWEB wieder ein memdump erstellen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 04 September 2019, 23:22:44
Zitat von: rudolfkoenig am 04 September 2019, 18:09:13
@Hardlife: koenntest bitte mit dem neuen FHEMWEB wieder ein memdump erstellen?

Kein Problem...
Danke für die Unterstützung.

Anbei ein Memdump, den ich gerade angefertigt habe.
- Messdauer ca. 15 Minuten
- Speicheranstieg während Messzeit ca. 6MB

LG,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 04 September 2019, 23:53:32
Bezüglich DbLog bzw. Mem Leaks in Database Interface habe ich noch etwas im Internet gesucht. Gefunden habe ich ein paar bereits etwas ältere Hinweise auf solche Fälle. So wie ich es gelesen und verstanden habe, müsste in diesen Fällen ein permanenter Anstieg der Database Handles zu verzeichnen sein.

Ich habe eine neue Version von DbLog erstellt (4.7.0), mit der man einen solchen Anstieg erkennen kann wenn man betroffen sein sollte. Dazu gibt es ein Attribut "traceHandles" um das Monitoring einzuschalten.
Verwendung:

attr <DbLog> traceHandles <Sekunden>

Dann werden alle <Sekunden> die vohandenen Handles Systemweit ! im Logfile (verbose 1) ausgegeben.
Im Normalfall gibt es pro verwendeten Datanbanktyp ein Driverhandle und für jede DbLog-Instanz ein DatabaseHandle.
Das kann mal kurzzeitig schwanken, darf aber nicht permanent steigen !

Bei meinem Testsystem sieht es zum Beispiel so aus:


2019.09.04 23:45:46.152 1: DbLog - traceHandles (system wide) - Driver: Pg, DriverHandle   : DBI::dr=HASH(0x55b3be3b8ae8)
2019.09.04 23:45:46.153 1: DbLog - traceHandles (system wide) - Driver: Pg, DatabaseHandle : DBI::db=HASH(0x55b3c2253f38)
2019.09.04 23:45:46.154 1: DbLog - traceHandles (system wide) - Driver: mysql, DriverHandle   : DBI::dr=HASH(0x55b3b9ac5740)
2019.09.04 23:45:46.154 1: DbLog - traceHandles (system wide) - Driver: mysql, DatabaseHandle : DBI::db=HASH(0x55b3c69eaef8)
2019.09.04 23:45:46.155 1: DbLog - traceHandles (system wide) - Driver: mysql, DatabaseHandle : DBI::db=HASH(0x55b3c69d2d40)
2019.09.04 23:45:46.156 1: DbLog - traceHandles (system wide) - Driver: SQLite, DriverHandle   : DBI::dr=HASH(0x55b3c6a14b88)
2019.09.04 23:45:46.156 1: DbLog - traceHandles (system wide) - Driver: SQLite, DatabaseHandle : DBI::db=HASH(0x55b3c6a16ee8)
2019.09.04 23:45:46.157 1: DbLog - traceHandles (system wide) - Driver: SQLite, DatabaseHandle : DBI::db=HASH(0x55b3c65d8d08)


Ich habe sowohl zwei Datenbanken vom Typ "SQLite", zwei Datenbanken vom Typ "MySQL" sowie eine Datenbank vom Typ "PostgreSQL" auf diesem System laufen. Alle im asynchronen Mode.
Wer mag, kann sich diese Version zunächst aus meinem contrib laden und das Verhalten auf seinem System checken. (Reload bzw. Restart nicht vergessen)

Sollte es einen stetigen Anstieg der Anzahl von DatabaseHandles geben, wäre etwas nicht ok.

Grüße,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 06 September 2019, 14:35:36
@Hardlife: Da sind meines Geschmacks nach immer noch zuviele Daten von SVG und/oder FHEMWEB drin, ich habe aber nach eine Weile Code-Anstarren keine Idee, woran es liegen koennte. Wie ist plotfork/plotEmbed gesetzt fuer FHEMWEB?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 06 September 2019, 18:34:29
Hi!

plotembedded habe ich nicht gesetzt - müsste also auf default=0 sein
plotfork steht auf "1"

LG,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 06 September 2019, 19:22:26
Kannst Du bitte pruefen, ob mit plotfork 0 dein Speicherproblem besteht?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 06 September 2019, 19:50:31
Seitdem ich die UNIFI-Komponenten deaktiviert habe ist der Speicherverbrauch moderat.
Ich helfe gerne im Detail zu suchen, wenn mir jemand einen Hinweis gibt was ich weiter tun könnte.

Der Spitzenreiter in den Memory-Dumps ist nach 3 Tagen Laufzeit der String "Assuming NOT a POSIX class"
Im Detail
"Assuming NOT a POSIX class since a semi-colon was found instead of a colon in regex; marked by <-- HERE in m/ group[ : <-- HERE ;]/"
"Assuming NOT a POSIX class since a semi-colon was found instead of a colon in regex; marked by <-- HERE in m/ group[ :; <-- HERE ]/"
Diese Strings kommen in Summe 280.000 Mal in den Heap-Segmenten vor.
Ich vermute, dass dies hiermit zu tun hat: https://rt.perl.org/Public/Bug/Display.html?id=130254
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 07 September 2019, 01:22:19
Zitat von: rudolfkoenig am 06 September 2019, 19:22:26
Kannst Du bitte pruefen, ob mit plotfork 0 dein Speicherproblem besteht?

gesagt - getan :-)
Leider keine erkennbare Veränderung.

Anbei ein neuer Dump mit "plotfork 0"

--> Darin erkennbar:
       einige meiner SVG-Plots, die ich mir anzeigen lasse
       UND
       ziemlich viele Dummy und Geräte, bei denen ich SVG-Grafiken als Icon oder sonstwas verwende

Vielleicht besteht hier ein Zusammenhang?

LG,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 07 September 2019, 20:04:07
@towag:
- ich gehe davon aus, dass "Assuming.." auch ohne UNIFI Probleme verursacht.
- verwendest Du perl 5.24, wie im Link beschrieben? Kannst Du es mit einem anderen Perl Version testen?
- sieht man diesen String im FHEM-Log mit "attr global stacktrace 1" ?
- kannst du bitte "fhemdebug memusage" nach einem update (s.u.) ausfuehren?

@Hardlife:
- genau das habe ich in dem letzten dump auch gesehen
- SVG-Icons werden anderes behandelt, damit man diese einfaerben kann. Allerdings sehe ich in FW_makeImage kein Speicherloch.
- Wie oft am Tag holst du eine Seite von FHEMWEB ab?

Da zu meinem erstaunen "fhemdebug memusage" nichtmal die globale Variable $data angezeigt hat, habe ich es komplett umgebaut.
Es zeigt weiterhin nur global sichtbare Variablen an, aber hoffentlich diesmal vollstaendig.
Man kann "weiterbohren", indem man das Angezeigte als Argument angibt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 07 September 2019, 20:51:10
1) ja genau: das war die Auswertung nach 3 Tagen ohne UNIFI und Restart nach Config-Änderung

2) perl -v
This is perl 5, version 24, subversion 1 (v5.24.1) built for arm-linux-gnueabihf-thread-multi-64int
(with 85 registered patches, see perl -V for more detail)
Ich habe mir bisher nicht angeschaut wie ich auf dem Standard Stretch eine andere Perl-Version zum Laufen bekomme

3) Ich hatte das Attribut bereits gesetzt gehabt - diese Strings sind nicht im Log-File

4) ich habe heute Abend ein Update von FHEM gemacht.
Vor dem Update hat "fhemdebug memusage" noch einen Output geliefert, jetzt steht im syslog nur mehr
"Sep 07 20:30:18 coruscant systemd[1]: fhem.service: Main process exited, code=killed, status=11/SEGV"
und meine systemd-Überwachung startet eine neue Instanz

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 07 September 2019, 23:43:57
Zitat von: rudolfkoenig am 07 September 2019, 20:04:07
- Wie oft am Tag holst du eine Seite von FHEMWEB ab?

Hmm, leider eine schwierige Frage....
Sicher unzählige Male, da wie beschrieben 6 Tablets ständig mit FHEM verbunden sind und deren Browser (WebViewControl) die Seiten im Intervall X aktualisieren.
Auch greifen ich und meine Freundin mit unseren Handys insgesamt ca 10 - 20 mal auf FHEM zu.

LG,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 08 September 2019, 12:44:05
ZitatThis is perl 5, version 24, subversion 1 (v5.24.1) built for arm-linux-gnueabihf-thread-multi-64int
Das ist laut deinem Link auch die beanstandete Version, ich wuerde versuchen, eine andere/neue Version zu installieren.



Zitat"Sep 07 20:30:18 coruscant systemd[1]: fhem.service: Main process exited, code=killed, status=11/SEGV"
Seufz. Da hat man die Wahl zwischen nichtssagenden Output oder eins, was abstuerzt.
Ich habe jetzt weitere Ausgaben bei "attr global verbose 5" in fhemdebug memusage eingebaut (update ab morgen), wenn Du Lust hast beim Lokalisieren des Absturzes zu helfen, dann bitte hier die Ausgabe anhaengen.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 08 September 2019, 19:38:45
Nur mal eben so zwischendurch:

Ich habe die Änderungen in FehmWeb zum Anlass genommen und testweise mal wieder das echodevice Modul installiert.
Seit dem wieder wie eh und jeh ca 20MB / Tag Speicher Anstieg.

Also hau ich das erstmal wieder raus. Dann ist alles stabil !
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: sig10680 am 09 September 2019, 07:09:22
Zitat von: Skusi am 08 September 2019, 19:38:45
Nur mal eben so zwischendurch:

Ich habe die Änderungen in FehmWeb zum Anlass genommen und testweise mal wieder das echodevice Modul installiert.
Seit dem wieder wie eh und jeh ca 20MB / Tag Speicher Anstieg.

Also hau ich das erstmal wieder raus. Dann ist alles stabil !

Hallo,

ich beobachte das Echodevice Modul seit einiger Zeit. Wenn ich das FHEM mit dem Modul laufen lasse benötige ich nach knapp 5 Tagen einen Neustart. Jetzt mal zum Test FHEM ohne Echodevice Modul läuft es schon seit ca.6 Wochen ohne jegliche Probleme. Ich habe am System Nichts verändert, auch kein FHEM Update!

MFG Sig10680
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Skusi am 09 September 2019, 10:06:18
Ich bin froh, das bei mir klar ist woran es liegt und ich nur auf das Echo Modul verzichten muß um einen stabilen Speicherverbraucht  zu haben. Ich lese hier schon lange mit, und habe Mitleid mit denen die den Grund noch nicht kennen. Nur schade das keiner rausfindet warum z. B. das Echomeodul diese Probleme verursacht. Ich würde das Modul sehr gerne wieder benutzen können.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: GSK19 am 09 September 2019, 17:58:11
Zitat von: Skusi am 09 September 2019, 10:06:18
Ich bin froh, das bei mir klar ist woran es liegt und ich nur auf das Echo Modul verzichten muß um einen stabilen Speicherverbraucht  zu haben. Ich lese hier schon lange mit, und habe Mitleid mit denen die den Grund noch nicht kennen. Nur schade das keiner rausfindet warum z. B. das Echomeodul diese Probleme verursacht. Ich würde das Modul sehr gerne wieder benutzen können.

Kann ich bei meinem System nicht ganz bestätigen. Bei uns wird der Echo nur zur Ausgabe genutzt (also set ... tunein und set ...  speak_ssml ), und damit läuft alles seit einiger Zeit stabil. Vorher hatten wir einen Speicheranstieg, der das System nach 18 Stunden gekillt hat, aber das lag an einem deaktivierten Freezemon-Device. Nachdem das gelöscht (und nicht nur deaktiviert) war, ist der Speicherbedarf absolut konstant.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 09 September 2019, 18:06:52
Hm, heute morgen habe ich ein Update gemacht - seitdem "Toi-Toi-Toi" ist der RAM bedarf stabil.

Und ja lieber CoolTux - es war FHEM, ich habe das problem schon länger gehabt - lange Zeit auch versucht zu analysieren, leider erfolglos.

Gestern machte ich auch ein Update, keine ahnung was jetzt zwischen gestern und heute geändert wurde - aber 10.000 Dank dafür...
So kann FHEM wohl endlich wieder etwas mehr unattended laufen ;-)


2019.09.09 07:23:56 1: update finished, "shutdown restart" is needed to activate the changes.
2019.09.09 07:23:56 1:
2019.09.09 07:23:15 1: Calling /volume1/@entware/ActivePerl-5.24/bin/perl-static ./contrib/commandref_join.pl -noWarnings, this may take a while
2019.09.09 07:23:15 1: nothing to do...
2019.09.09 07:23:15 1: homeconnect
2019.09.09 07:23:15 1:
2019.09.09 07:23:15 1:
2019.09.09 07:23:15 1: nothing to do...
2019.09.09 07:23:15 1: fhemdeparture
2019.09.09 07:23:15 1:
2019.09.09 07:23:15 1:
2019.09.09 07:23:15 1: ... rest of lines skipped.
2019.09.09 07:23:15 1:               added combineReads
2019.09.09 07:23:15 1:               check if request is already in rqueue
2019.09.09 07:23:15 1:               added timeout message
2019.09.09 07:23:15 1:               added ModbusRTU_CalcNextUpdate
2019.09.09 07:23:15 1:   150314 0008 fixed typo in attribute name pollIntervall
2019.09.09 07:23:15 1: 36_ModbusRTU:
2019.09.09 07:23:15 1:                                                                                                  .   
2019.09.09 07:23:15 1: all changes:
2019.09.09 07:23:15 1:                                                                                                  .   
2019.09.09 07:23:15 1:   180206 0024 added DATE
2019.09.09 07:23:15 1: 37_ModbusRegister:
2019.09.09 07:23:15 1:               fix Wago DO address calculation
2019.09.09 07:23:15 1:               documentation update
2019.09.09 07:23:15 1:               fixed access to Wago PFC area
2019.09.09 07:23:15 1:   170106 0014 added writeMode SetReset
2019.09.09 07:23:15 1: 37_ModbusCoil:
2019.09.09 07:23:15 1:   181107 0022 changed detection of wago plc
2019.09.09 07:23:15 1:   190906 0023 added (empty) fingerprint
2019.09.09 07:23:15 1: 36_ModbusTCPServer:
2019.09.09 07:23:15 1:               added support for coils
2019.09.09 07:23:15 1:               added combineReads
2019.09.09 07:23:15 1:               check if request is already in rqueue
2019.09.09 07:23:15 1:               added timeout message
2019.09.09 07:23:15 1:               added ModbusRTU_CalcNextUpdate
2019.09.09 07:23:15 1:   150314 0008 fixed typo in attribute name pollIntervall
2019.09.09 07:23:15 1: 36_ModbusRTU:
2019.09.09 07:23:15 1: New entries in the CHANGED file:
2019.09.09 07:23:15 1:
2019.09.09 07:23:15 1: saving ./log/fhem.save
2019.09.09 07:23:14 1: UPD FHEM/36_ModbusTCPServer.pm
2019.09.09 07:23:14 1: modbus
2019.09.09 07:23:14 1:
2019.09.09 07:23:14 1:
2019.09.09 07:23:14 1:  - feature:     30_tradfri: blind support
2019.09.09 07:23:14 1: New entries in the CHANGED file:
2019.09.09 07:23:14 1:
2019.09.09 07:23:14 1: saving ./log/fhem.save
2019.09.09 07:23:14 1: UPD www/images/fhemSVG/tradfri_gateway.svg
2019.09.09 07:23:14 1: UPD FHEM/firmware/JeeLink_LaCrosseGateway.bin
2019.09.09 07:23:14 1: UPD FHEM/98_fhemdebug.pm
2019.09.09 07:23:14 1: UPD FHEM/31_HUEDevice.pm
2019.09.09 07:23:14 1: UPD FHEM/30_tradfri.pm
2019.09.09 07:23:14 1: UPD ./configDB.pm
2019.09.09 07:23:13 1: UPD ./CHANGED
2019.09.09 07:23:13 1: RMDIR: ./restoreDir/update/2019-08-31
2019.09.09 07:23:13 1: fhem
2019.09.09 07:23:13 1:


Bei mir also vermutlich einer der Kandidaten die heute morgen ein Update bekommen haben.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: towag am 09 September 2019, 19:19:43
Output von MemUsage

2019.09.09 18:41:00 4: WEB_192.168.1.242_54097 POST /fhem&fw_id=1670&cmd=fhemdebug+memusage; BUFLEN:0
2019.09.09 18:41:00 5: Cmd: >fhemdebug memusage<
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 248 created:
<47>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 248 FHEM [version@Log2Syslog version="5.8.2"] 5: Cmd: >fhemdebug memus ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 248 sent

2019.09.09 18:41:00 5: Loading ./FHEM/98_fhemdebug.pm
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 249 created:
<47>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 249 FHEM [version@Log2Syslog version="5.8.2"] 5: Loading ./FHEM/98_fhe ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 249 sent

2019.09.09 18:41:00 5: Memusage checking selectTimestamp
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 250 created:
<47>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 250 FHEM [version@Log2Syslog version="5.8.2"] 5: Memusage checking sel ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 250 sent

2019.09.09 18:41:00 5: Memusage checking DbRep_vNotesExtern
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 251 created:
<47>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 251 FHEM [version@Log2Syslog version="5.8.2"] 5: Memusage checking DbR ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 251 sent

2019.09.09 18:41:00 5: Memusage checking DATEI
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 252 created:
<47>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 252 FHEM [version@Log2Syslog version="5.8.2"] 5: Memusage checking DAT ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 252 sent

2019.09.09 18:41:00 5: Memusage checking LOG
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 253 created:
<47>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 253 FHEM [version@Log2Syslog version="5.8.2"] 5: Memusage checking LOG ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 253 sent

2019.09.09 18:41:00 5: Memusage checking oldvalue
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 254 created:
<47>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 254 FHEM [version@Log2Syslog version="5.8.2"] 5: Memusage checking old ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 254 sent

2019.09.09 18:41:00 5: Memusage checking lastWarningMsg
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 255 created:
<44>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 255 FHEM [version@Log2Syslog version="5.8.2"] 5: Memusage checking las ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 255 sent

2019.09.09 18:41:00 5: Memusage checking DoInitDev
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 256 created:
<47>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 256 FHEM [version@Log2Syslog version="5.8.2"] 5: Memusage checking DoI ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 256 sent

2019.09.09 18:41:00 5: Memusage checking SVG_zoomLink
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 257 created:
<47>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 257 FHEM [version@Log2Syslog version="5.8.2"] 5: Memusage checking SVG ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 257 sent

2019.09.09 18:41:00 5: Memusage checking defs
2019.09.09 18:41:00 4: SyslogMgmt - Payload sequence 258 created:
<47>1 2019-09-09T18:41:00 myhost.mydomain.at SyslogMgmt_fhem 258 FHEM [version@Log2Syslog version="5.8.2"] 5: Memusage checking def ...
2019.09.09 18:41:00 4: Log2Syslog SyslogMgmt - Payload sequence 258 sent
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 09 September 2019, 21:16:38
@Rudi, habe das neue "fhemdebug memusage" gerade mal getestet.
FHEM startet nach dem Aufruf zügig neu:


....
2019.09.09 20:54:11.078 5: Cmd: >fhemdebug memusage<
2019.09.09 20:54:11.082 5: Memusage checking DbRep_vNotesIntern
2019.09.09 20:54:11.083 5: Memusage checking FW_icons
2019.09.09 20:54:11.084 5: Memusage checking HMinfo_templateMark
2019.09.09 20:54:11.084 5: Memusage checking FW_types
2019.09.09 20:54:11.085 5: Memusage checking FH1
2019.09.09 20:54:11.085 5: Memusage checking GetInfoType
2019.09.09 20:54:11.086 5: Memusage checking LOG
2019.09.09 20:54:11.086 5: Memusage checking FW_RETTYPE
2019.09.09 20:54:11.086 5: Memusage checking FW_formmethod
2019.09.09 20:54:11.087 5: Memusage checking currlogfile
2019.09.09 20:54:11.088 5: Memusage checking FW_httpheader
2019.09.09 20:54:11.088 5: Memusage checking lastWarningMsg
2019.09.09 20:54:11.088 5: Memusage checking structChangeHist
2019.09.09 20:54:11.089 5: Memusage checking readytimeout
2019.09.09 20:54:11.089 5: Memusage checking FW_ME
2019.09.09 20:54:11.090 5: Memusage checking DH
2019.09.09 20:54:11.090 5: Memusage checking oldvalue
2019.09.09 20:54:11.091 5: Memusage checking FH3
2019.09.09 20:54:11.091 5: Memusage checking FW_gplotdir
2019.09.09 20:54:11.092 5: Memusage checking DoInitDev
2019.09.09 20:54:11.092 5: Memusage checking _
2019.09.09 20:54:11.093 5: Memusage checking :
2019.09.09 20:54:11.093 5: Memusage checking RESIDENTStk_subTypes
2019.09.09 20:54:11.093 5: Memusage checking SMAInverter_vNotesIntern
2019.09.09 20:54:11.094 5: Memusage checking fhemForked
2019.09.09 20:54:11.094 5: Memusage checking SSCam_vHintsExt_de
2019.09.09 20:54:11.095 5: Memusage checking FILE
2019.09.09 20:54:11.095 5: Memusage checking ISA
2019.09.09 20:54:11.095 5: Memusage checking SIG
2019.09.09 20:54:11.097 1: PERL WARNING: Devel::Size: Unknown variable type: 244 encountered
2019.09.09 20:54:11.358 1: Including fhem.cfg
2019.09.09 20:54:11.369 3: telnetPort: port 7072 opened
2019.09.09 20:54:11.443 3: WEB: port 8083 opened
...


Die Stelle des Neustarts bzw. Nummern nach "Unknown variable type" sind variabel. Es können auch mehrere Warnings oder auch keine Warnings auftreten bevor der Neustart ausgeführt wird.

Grüße,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 09 September 2019, 22:05:51
Es schaut so aus, dass Devel::Size schwer kaputt ist.
Vermutlich muss man es selbst bauen.
Seufz.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 11 September 2019, 15:06:40
Ich habe fhemdebug memusage entfernt, da ich keine Version hingekriege, was nicht abstuerzt und trotzdem was Sinnvolles anzeigt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 14 September 2019, 21:39:25
Mir hat das ganze Thema keine Ruhe gelassen und habe angefangen den Speicherverbrauch meiner Module zu analysieren.
Dabei habe in SSCam einen unnötigen Speicherverbrauch festgestellt.
Es ist zwar kein richtiger Mememory-Leak, aber trotzdem unschön. Er kam zum Tragen wenn man sich Aufnahmen zugeschickt hat.
Die Daten verblieben dann im Speicher.
Darauf gekommen bin ich, weil ich eigene Hashes im lokalen Kontext definiert und darauf referenziert hatte was ich ändern
wollte.

Nach der Umstellung aller dieser Variablen auf das zentrale %data-Hash (hatte ich überhaupt nicht auf meinem Radar) konnte ich die Strukturen besser untersuchen.
Dazu habe ich mir ein kleines Programm in der 99_myUtils erstellt. Es funktioniert ähnlich dem memusage von Rudi.
Wer es nachnutzen möchte, kann es sich im Anhang herunterladen und in seine 99_myUtils kopieren.

Damit kann man nun seine eventuell verdächtigen Devices näher untersuchen oder in den zentralen %data Hash schauen.
Mit diesem Hilfsmittel konnte ich nun den Memorykonsum von SSCam-Devices im Extremfall auf 1/10tel reduzieren. Durch die Verarbeitung von Schnappschüssen und Aufnahmen macht es sich schnell bemerkbar, da es dabei nicht nur um ein paar Byte handelt.

@Rudi, ich habe festgestellt, dass Devices vom TYPE HTTPMOD und TelegramBot zum Absturz von Devel::Size führen. Warum das so ist, habe ich noch nicht herausgefunden. D.h. wenn man versuchen würde diese Devices mit meinem Programm zu untersuchen, kommt es zum gleichen Absturz wie bei deinem memusage. Ist ja auch nur Devel::Size. Deshalb werden diese Typen automatisch vom Check ausgeschlossen.
Alle anderen TYPEn sind bei mir problemlos durchgelaufen mit "analyzeObject("TYPE=.*")"

Man kann das Programm in zwei Kontexten verwenden. Um ein Device bzw. Gruppe von Devices (mit devspec) zu untersuchen,
sieht der Aufruf so aus:

   Verwendung im Device-Kontext:
   analyzeObject(<Devspec [Subhash1] [Subhash2] ...>,[<Analysetiefe>],[<Text zur Erläuterung>]);

   z.Bsp.:
   analyzeObject("CamHE1")
   analyzeObject("CamHE1 HELPER .SNAPHASH,6,SVS")
   analyzeObject("CamHE1 HELPER .SNAPHASH 2,0,SVS")
   analyzeObject("TYPE=SSCam HELPER .SNAPHASH")
   analyzeObject("TYPE=.*")

   
Mit "{ analyzeObject("CamHE1") }" kann man sich direkt in der FHEMWEB Kommandozeile die Größe des Device-Hash anschauen und mit Zusätzen wie "{analyzeObject("CamHE1 HELPER}" usw. immer weiter hineingehen. Will man sich den Inhalt der Hashes anschauen, setzt man noch eine Analysetiefe, z.B. "{analyzeObject("CamHE1 HELPER,7}".

Ähnlich funktioniert die Ausgabe für das %data Hash. Dazu gibt man am Anfang das Keywort "#DATA#" an.

   Verwendung im HASH-Kontext (z.Zt. nur $data):
   analyzeObject(<#DATA# [Subhash1] [Subhash2] ...>,[<Analysetiefe>],[<Text zur Erläuterung>]);

   z. Bsp.:
   analyzeObject("#DATA#")
   analyzeObject("#DATA# ESPBridge,10")
   analyzeObject("#DATA# SSCam CamHE1")
   analyzeObject("#DATA# SSCam CamHE1 PARAMS")


Das Hilfsmittel ist nicht perfekt und kann mit Sicherheit weiter ausgebaut und verbessert werden. Aber mir ging es darum
ein Hilfsmittel zu haben um ein bisschen besser in sein System hineinschauen zu können.
Wer es sich zutraut und mit Perl nicht ganz ungeübt ist, kann den sich den Inhalt der angehängten Datei in seine 99_myUtils
kopieren und dann wie angegeben verwenden. Ggf. ist Devel::Peek zu installieren. Geht mit dem Installer von Loredo ganz
einfach.

Hier ein Ausgabebeispiel von "{ analyzeObject("CamHE1") }"

analyzeObject - check object $defs{CamHE1} type: HASH
analyzeObject - Data::Peek deep: 0 -> analyzed $defs{CamHE1} (type: HASH):
SV = IV(0x555a8662f668) at 0x555a8662f678
  REFCNT = 1
  FLAGS = (ROK)
  RV = 0x555a91d8e488

analyzeObject - Devel::Size -> total size object $defs{CamHE1} (type: HASH): 6943118 Bytes
analyzeObject - checked SMTPCREDENTIALS (type: PV): 42 Bytes
analyzeObject - checked .attrminint (type: ARRAY): 64 Bytes
analyzeObject - checked FVERSION (type: PV): 80 Bytes
analyzeObject - checked SERVERADDR (type: PV): 46 Bytes
analyzeObject - checked OLDREADINGS (type: HASH): 120 Bytes
analyzeObject - checked HELPER (type: HASH): 6896144 Bytes
analyzeObject - checked CREDENTIALS (type: PV): 42 Bytes
analyzeObject - checked COMPATIBILITY (type: PV): 42 Bytes
analyzeObject - checked TYPE (type: PV): 42 Bytes
analyzeObject - checked MODEL (type: PV): 51 Bytes
analyzeObject - checked .setup (type: PV): 5865 Bytes
analyzeObject - checked .FhemMetaInternals (type: PV): 24 Bytes
analyzeObject - checked .attraggr (type: ARRAY): 64 Bytes
analyzeObject - checked SERVERPORT (type: PV): 58 Bytes
analyzeObject - checked CAMNAME (type: PV): 45 Bytes
analyzeObject - checked NR (type: PV): 58 Bytes
analyzeObject - checked .ptzhtml (type: PV): 42 Bytes
analyzeObject - checked STATE (type: PV): 82 Bytes
analyzeObject - checked NAME (type: PV): 42 Bytes
analyzeObject - checked READINGS (type: HASH): 37599 Bytes
analyzeObject - checked FUUID (type: PV): 74 Bytes
analyzeObject - checked OPMODE (type: PV): 47 Bytes
analyzeObject - checked DEF (type: PV): 63 Bytes
analyzeObject - checked PROTOCOL (type: PV): 42 Bytes
analyzeObject - checked CAMID (type: PV): 42 Bytes


Und ein Beispiel von "{ analyzeObject("ActionDetector helper io") }"

analyzeObject - check object $defs{ActionDetector}{helper}{io} type: HASH
analyzeObject - Data::Peek deep: 0 -> analyzed $defs{ActionDetector}{helper}{io} (type: HASH):
SV = PVNV(0x555a9027ea60) at 0x555a94c0e420
  REFCNT = 1
  FLAGS = (ROK)
  IV = 0
  NV = 0
  RV = 0x555a8ce25ec0
  PV = 0x555a8ce25ec0 ""
  CUR = 0
  LEN = 0

analyzeObject - Devel::Size -> total size object $defs{ActionDetector}{helper}{io} (type: HASH): 368 Bytes
analyzeObject - checked vccu (type: PV): 42 Bytes
analyzeObject - checked prefIO (type: PV): 24 Bytes


Für SSCam-Interressenten ... die Version 8.18.0 befindet sich zum Test in meinem contrib.

Grüße,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Mave am 06 Oktober 2019, 08:07:26
Gibt es zu diesem scheinbar global auftretenden Problem eigentlich einen zentralen Thread?

Ich bin seit einiger Zeit auch betroffen und da das Absturzintervall immer kürzer wird, muss ich mich jetzt auch mal damit beschäftigen. So macht FHEM keinen Spaß mehr.

Mein Sysmon zeigt nach einem Neustart des Rpi3 einen freien Speicher von ca. 520 MB an. Nach einem Tag sind nur noch ca. 130 MB frei.
Auch ein Neustart von FHEM ändert nichts an den freien 130 MB. Erst ein Neustart des Rpi3 ergibt wieder 520 MB freien Speicher.

Könnte mir das bitte jemand erklären?

Vielen Dank.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 06 Oktober 2019, 10:05:21
ZitatGibt es zu diesem scheinbar global auftretenden Problem eigentlich einen zentralen Thread?
Ja, diesen hier.
Diese Meldung ist typisch bei einem Speicherleck, weil fork() / BlockingCall nochmal die bisher allozierte Menge des Speichers reserviert.

Fuer einen Speicherleck gibt es sicher mehrere Ursachen, die mir bekannten:
- FHEMWEB bei bestimmten Kombination von plotfork und plotEmbed (ist mW gefixt)
- EchoDevice (nur in bestimmten, bisher unbekannten Konfigurationen).
- SSCam (Loesung unterwegs, siehe https://forum.fhem.de/index.php/topic,84372.msg974569.html#msg974569 (https://forum.fhem.de/index.php/topic,84372.msg974569.html#msg974569))
- DOIF mit perl 5.24 und bestimmten Attributen (Perl-Regexp-Bug, mit Workaround in DOIF geloest?)
Es gibt sicher noch Weitere, auch nicht genau identifizierte.

Generell hat FHEM kein Problem mit Speicheranstieg: ich protokolliere meine Produktion seit 3 Monaten, siehe Anhang.

Mir sind zwei Wege bekannt, um das Problem zu lokalisieren:
- alle Module einzeln abschalten, bis man keinen Speicheranstieg beobachtet. Alternativ: Module nacheinander auf eine zweite FHEM-Instanz umziehen.
- fuer Leute mit etwas UNIX Erfahrung: https://forum.fhem.de/index.php/topic,84372.msg970863.html#msg970863 (https://forum.fhem.de/index.php/topic,84372.msg970863.html#msg970863)


ZitatAuch ein Neustart von FHEM ändert nichts an den freien 130 MB.
Die Angabe "Freier Speicher" sollte mAn in "Unnuetz rumliegender Speicher" umbenannt werden, dann haetten wir beim Support weniger Aufgaben. Betriebsysteme benutzen den Hauptspeicher um Daten von der Festplatte zu cachen, diese Zahl zaehlt nicht zu "free", kann aber bei Bedarf jederzeit von Programmen belegt werden, und wird nur bei einem Betriebsystem-Neustart zurueckgesetzt.
EDIT: Perl version korrigiert.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Mave am 06 Oktober 2019, 10:25:40
Moin Rudi,

vielen Dank für Deine Erklärungen.

Welche Speicherwerte muss ich überwachen und mit welchem Tool?
Mit sysmon und dort den aktuellen Speicherbedarf?

Danke.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 06 Oktober 2019, 11:37:55
SYSMON kenne ich nicht wirklich, und ist mir wegen BlockingCall suspekt :)

Die Daten fuer meine SVG erstelle ich per crontab (alle 5 Minuten) mit
echo `date +"%Y-%m-%d_%H:%M:%S"` size `ps -flC perl | awk '/perl/{print $10}'` >> ..../log/perlsize.logDas funktioniert aber nur, weil ich kein Modul mit BlockingCall verwende, und damit nur eine perl-Instanz auf der Maschine laeuft.

Folgendes sollte selbst bei Verwendung von BlockingCall bzw. mehreren FHEM Instanzen funktionieren:
define pSizeAt at +*00:05 {`echo \`date +"%Y-%m-%d_%H:%M:%S"\` size \`awk '/VmSize/{print \$2}' /proc/$$/status\` >> /opt/FHEM/log/perlsize.log`}Achtung: ich habe Letzteres nur kurz/oberflaechlich getestet, und wg. /proc laeuft das nur unter Linux.

In beiden Faellen legt man ein FakeLog mit log/perlsize.log an, und damit baut man eine SVG.


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: tomcat.x am 06 Oktober 2019, 15:48:20
Zitat von: rudolfkoenig am 06 Oktober 2019, 10:05:21
Fuer einen Speicherleck gibt es sicher mehrere Ursachen, die mir bekannten:
- FHEMWEB bei bestimmten Kombination von plotfork und plotEmbed (ist mW gefixt)
- EchoDevice (nur in bestimmten, bisher unbekannten Konfigurationen).
- SSCam (Loesung unterwegs, siehe https://forum.fhem.de/index.php/topic,84372.msg974569.html#msg974569)
- DOIF mit perl 5.28 und bestimmten Attributen (Perl-Regexp-Bug, mit Workaround in DOIF geloest?)

Bei mir kam auf jeden Fall  Freezemon (in Verbindung mit apptime) dazu. Das Problem hatte glaube ich auch jemand anders hier im Thread. Seit ich Freezmon deaktiviert (in der fhem.cfg auskommentiert!) habe, lese ich hier nur noch aus Interesse mit.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Mave am 06 Oktober 2019, 16:02:02
In der cfg auskommentieren bedeutet, dass die Definition erhalten bleibt und später wieder aktiviert werden kann?
Wohingegen Device löschen bedeutet, dass alles aus der cfg entfernt wird?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 06 Oktober 2019, 16:05:43
Löschen ist hier der bessere Weg - die .cfg editiert man nicht.
Bei Freezemon ist es ja auch kein großes Problem neu zu definieren...

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Mave am 06 Oktober 2019, 16:08:51
Okay, vielen Dank.

Hab ich gestern gelöscht.
Jetzt heißt es beobachten.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 06 Oktober 2019, 18:36:49
Einige meinten, das man freezemon komplett löschen muss, um eine Besserung zu erzielen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Mave am 06 Oktober 2019, 18:39:42
Was meinst Du mit komplett löschen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 06 Oktober 2019, 20:05:10
Die Datei in /opt/fhem/FHEM löschen und fhem neu starten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: tomcat.x am 06 Oktober 2019, 20:21:38
Aus meiner Sicht reicht es, das Gerät zu löschen und fhem (mit Linux) neu zu starten. Auf jeden Fall reichte "set inactive" und/oder setzen des Attributs "disable" nicht.

Bei mir funktioniert es mit Auskommentieren in der cfg. Aber stimmt, ich hatte vor kurzem auch mal jemand empfohlen, nicht manuell zu editieren. Und bei einem Gerät, dass man nicht vorübergehend entfernen will und wo man vermutlich auch nur ein paar Attribute gepflegt hat, macht das keinen Sinn.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Damian am 06 Oktober 2019, 23:52:02
Zitat- DOIF mit perl 5.28 und bestimmten Attributen (Perl-Regexp-Bug, mit Workaround in DOIF geloest?)

Ist nicht richtig.

Es muss perl 5.24 heißen. siehe: https://forum.fhem.de/index.php/topic,84372.msg812511/topicseen.html#msg812511

Wer Raspberry benutzt, sollte auf jeden Fall auf Buster updaten, dort gibt es die 5.28 Perl-Version.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 07 Oktober 2019, 12:35:21
Zu meiner großen Freude scheine ich den Fehler in meiner Konfiguration nun eingegrenzt/gefunden zu haben...  :)

Vielleicht ist die Ursache des Fehlers bei mir auch die Ursache der Fehler bei manch anderem Forenteilnehmer und man kann ihn fixen.
Da mir aber die tieferen Kenntnisse fehlen, kann ich keine "Rundum-Glücklich"-Anleitung anbieten und möchte darum bitten, ob es sich ein Profi ansehen könnte.
Ich konnte wie gesagt den Fehler nur eingrenzen, woran es wirklich genau liegt, kann ich nicht sagen... :(
Da der Fehler eigentlich in einer untergeordneten Funktion (TV-Programm) auftritt, könnte man als Ratschlag geben: "verzichte halt drauf"
Das würde jedoch wohl nicht wirklich das Grundproblem (das ja irgendwo im Code vorhanden sein muss) lösen, und auf der anderen Seite hängen wir sehr an der Funktion.


--> Ich weiß, viel Text, aber ich wollte nochmal alle meine Erkenntnisse zusammenfassen und auf den Punkt bringen. Vielleicht hilfts ja wem.


Kurze rückblickende Zusammenfassung:


Was des Fehler ans Tageslicht beförderte:


Was war die Ursache:


Vielleicht könnte ein Profi untenstehenden Config in seine fhem.cfg übenehmen?
Bis auf die Icons, die ich mir selbst zusammengeschustert habe, dürfte man dann ein TV-Programm haben UND den damit verbundenen Speicheranstieg in Realtime beobachten können.
Dadurch hätte man ein Basis für eine qualifizierte Fehlersuche.

______________________________
EDIT: CODE angehängt als TXT-Datei
______________________________
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 07 Oktober 2019, 12:48:26
Soweit ich sehe, besteht diese Konfiguration aus zwei HTTPMOD Instanzen mit jeweils 100+ readingRegexps, und dem zugehoerigen readingsGroup.

Kannst Du bitte noch ein Versuch ohne readingsGroup bauen, um festzustellen, welche der beiden Module das Problem verursacht, und danach in dem zum Modul passenden Forums-Abschnitt eine neue Diskussion oeffnen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 07 Oktober 2019, 13:10:03
Kannst du noch bitte den Code für diese Funktion anhängen?

wrapLine

Dann würde ich mal versuchen unter Buster diese Dinge einzubinden und zu gucken ob es bei mir auch zu diesem Problem kommt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 07 Oktober 2019, 15:53:21
Zitat von: mumpitzstuff am 07 Oktober 2019, 13:10:03
Kannst du noch bitte den Code für diese Funktion anhängen?

wrapLine

Ups, vergessen...
Habe ich in der 99_myUtils.pm

#####################################
### Zeilenumbruch für TV-Programm ###
#####################################

sub
wrapLine($$)
{
  my ($string, $maxLength) = @_;
  $string = decode_entities($string);
my @stringParts = split(/ /, $string);
  my $actRowLength = 0;
  my $resultString = '';
  while (scalar(@stringParts) > 0) {
  my $tempString = shift @stringParts;
    if ($actRowLength > 0)
    {
    if (($actRowLength + length($tempString)) > $maxLength)
      {
      $actRowLength = 0;
        $resultString .= '<br>';
      }
    }
    $resultString .= $tempString;
    $actRowLength += length($tempString);
    if (scalar(@stringParts) > 0)
    {
    $resultString .= ' ';
    $actRowLength += 1;
    }
  }
  if ($resultString eq '')
  {
  return ' ';
  }
  else
  {
  return $resultString;
  }
}

#### ENDE ### Zeilenumbruch #############



Danke für Deine Unterstützung, wär toll, wenn man den Fehler finden würde...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 07 Oktober 2019, 15:55:17
Zitat von: rudolfkoenig am 07 Oktober 2019, 12:48:26
Soweit ich sehe, besteht diese Konfiguration aus zwei HTTPMOD Instanzen mit jeweils 100+ readingRegexps, und dem zugehoerigen readingsGroup.

:-[ :-[ :-[

Zitat von: rudolfkoenig am 07 Oktober 2019, 12:48:26
Kannst Du bitte noch ein Versuch ohne readingsGroup bauen, um festzustellen, welche der beiden Module das Problem verursacht, und danach in dem zum Modul passenden Forums-Abschnitt eine neue Diskussion oeffnen?

Ich versuche das, sobald ich ein paar Minuten übrig habe...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 07 Oktober 2019, 19:32:54
Hallo,

weiß nicht in wie weit das hier helfen könnte... Um 16 Uhr macht ein script immer automatisch ein Backup von fhem. In dem Diagramm ist ist heute genau um diese Uhrzeit zu sehen wie der freie Speicher von 5 GB auf 2,5 GB abfällt....

#!/bin/bash

mountIp="192.168.1.20"
mountDir="raspberry/backup"
mountUser="xxx"
mountPass="xxx"
mountSubDir="fhem"
localMountPoint="/mnt/backup"

#optional
backupsMax="40"
localBackupDir="/backup"
pushoverUser="xxxxx"
pushoverToken="xxxxx"
###################################

perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup info backup starting now"

if [ ! -e "$localBackupDir" ]
then
echo "$localBackupDir wird erstellt"
mkdir -p "$localBackupDir"
else
echo "$localBackupDir bereits vorhanden"
fi

tar --exclude=backup -cvzf "/$localBackupDir/$(date +%y%m%d_%H%M%S)_fhem_backup.tar.gz" "/opt/fhem" &>/dev/null

if ! ping -c 1 $mountIp
then
echo "$mountIp nicht erreichbar, stop"
perl /opt/fhem/fhem.pl 7072 "set FHEM.Backup error"
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup info $mountIp not found"
exit
else
echo "$mountIp erreichbar"
fi

localIp=$(hostname -I|sed 's/\([0-9.]*\).*/\1/')

if [ ! -e "$localMountPoint" ]
then
echo "$localMountPoint wird erstellt"
mkdir -p "$localMountPoint"
else
echo "$localMountPoint bereits vorhanden"
fi

if [ "$(ls -A $localMountPoint)" ]
then
echo "$localMountPoint nicht leer, kein Mounten notwendig"
else
echo "$localMountPoint leer, Mounten starten"
vorhanden="0"
while read line
do
mountComplete="//$mountIp/$mountDir $localMountPoint cifs username=$mountUser,password=$mountPass,iocharset=utf8,sec=ntlm,vers=1.0 0 0"
echo "mountComplete: $mountComplete"
if [ `echo "$line" | grep -c "$mountComplete"` != 0 ]
then
echo "/etc/fstab: Eintrag bereits vorhanden: $mountComplete"
vorhanden="1"
break
fi
done < "/etc/fstab"
if [ "$vorhanden" != "1" ]
then
echo "/etc/fstab: Eintrag wird ergänzt: $mountComplete"
echo "$mountComplete" >> "/etc/fstab"
fi
echo "Mounts werden aktualisiert"
mount -a
sleep 3
fi

if [ "$(ls -A $localMountPoint)" ]
then
if [ ! -e "$localMountPoint/$mountSubDir/$localIp" ]
then
mkdir -p "$localMountPoint/$mountSubDir/$localIp"
else
echo "$localMountPoint/$mountSubDir/$localIp existiert bereits"
fi
find "$localBackupDir" -name '*fhem_backup.tar.gz' | while read file
do
fileSize="0"
fileSizeMB=$(du -h $file)
fileSizeMB=${fileSizeMB%%M*}
filename=${file##*/}
echo "$filename ($fileSizeMB MB) wird in den Backupordner verschoben"
if [[ "$pushoverToken" != "" && "pushoverUser" != "" ]]
then
curl -s -F "token=$pushoverToken" -F "user=$pushoverUser" -F "title=FHEM $localIp" -F "message=Backup mit $fileSizeMB MB wird erstellt" https://api.pushover.net/1/messages.json
fi
#mv "$file" "$localMountPoint/$mountSubDir/$localIp/$filename"
cp "$file" "$localMountPoint/$mountSubDir/$localIp/$filename"
rm "$file"
perl /opt/fhem/fhem.pl 7072 "set FHEM.Backup off"
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup backup $filename"
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup backupMB $fileSizeMB"
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup info backup done"
done
else
echo "Mounten hat anscheinend nicht geklappt, skip."
exit
fi

#Löschen alter Backups
if [[ "$backupsMax" != "" && "$backupsMax" != "0" ]]
then
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup backupFilesMax $backupsMax"
backupsCurrent=`ls -A "$localMountPoint/$mountSubDir/$localIp" | grep -c "_fhem_backup.tar.gz"`
backupsDelete=$(($backupsCurrent-$backupsMax))
if [ "$backupsDelete" -gt "0" ]
then
echo "$backupsCurrent Backups vorhanden - nur $backupsMax aktuelle Backups werden vorgehalten - $backupsDelete Backups werden gelöscht"
ls -d "/$localMountPoint/$mountSubDir/$localIp/"* | grep "_fhem_backup.tar.gz" | head -$backupsDelete | xargs rm
else
echo "$backupsCurrent Backups vorhanden - bis $backupsMax aktuelle Backups werden vorgehalten"
fi
else
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup backupFilesMax no limit"
fi

backupsCurrent=`ls -A "$localMountPoint/$mountSubDir/$localIp" | grep -c "_fhem_backup.tar.gz"`
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup backupFiles $backupsCurrent"




Gruß

Thorsten
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Mave am 08 Oktober 2019, 06:45:03
Wie sieht denn eigentlich der idealtypische Verlauf einer Speicherauslastung aus?

Mein Speicherverbrauch ist seit 2 Tagen von ca. 200 MB auf ca. 270 MB angestiegen. Wenn das linear so weiterläuft, dann knallt es in ein paar Tagen. Wenn sich der Wert irgendwo einpendelt, ist alles gut.

Deshalb meine Frage, wie die Kurve idealtypisch aussieht...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 08 Oktober 2019, 10:56:19
So wie im Anhang zu meinem Beitrag hier https://forum.fhem.de/index.php/topic,84372.msg981088.html#msg981088 von Vorgestern.
Allerdings ist mein System mit 200 defines von 30 unterschiedlichen Modulen eher klein, und wird seit Jahren kaum angefasst.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Mave am 08 Oktober 2019, 13:29:27
Okay, Rudi.

Vielen Dank.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: HomeAuto_User am 08 Oktober 2019, 16:01:15
@Hardlife, den Fehler bei dir kann ich bestätigen. Sobald du das TV Programm mit HTTPMOD umsetzt und unzähligen Readings kommt es zu dem Fehler. Bei mir auch so und mehrfach verifiziert.

Ich selbst bastel an einem Modul nun, wo ich das ganze ohne HTTPMOD umsetze.


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 08 Oktober 2019, 23:23:08
Zitat von: rudolfkoenig am 07 Oktober 2019, 12:48:26
Kannst Du bitte noch ein Versuch ohne readingsGroup bauen, um festzustellen, welche der beiden Module das Problem verursacht, und danach in dem zum Modul passenden Forums-Abschnitt eine neue Diskussion oeffnen?

Ok, habs getestet.
Liegt wohl definitiv an HTTPMOD (oder den RegEx-Aufrufen).
Ich setzte einen Post in den zugehörigen Thread https://forum.fhem.de/index.php/topic,45176.0.html (https://forum.fhem.de/index.php/topic,45176.0.html)
Vielleicht kann man dort die Ursache finden...


Zitat von: HomeAuto_User am 08 Oktober 2019, 16:01:15
@Hardlife, den Fehler bei dir kann ich bestätigen. Sobald du das TV Programm mit HTTPMOD umsetzt und unzähligen Readings kommt es zu dem Fehler. Bei mir auch so und mehrfach verifiziert.

Vielen Dank für die Unterstützung und Bestätigung.
Ich dachte schon, ich werd wahnsinnig mit dem doofen Fehler  :o
Ich werde wie oben beschrieben eine Post setzten - vielleicht möchtest Du Dich der Fehlersuche anschließen.


Zitat von: HomeAuto_User am 08 Oktober 2019, 16:01:15
Ich selbst bastel an einem Modul nun, wo ich das ganze ohne HTTPMOD umsetze.

Kann man das Modul bereits testen? Gibts da einen Thread dazu?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 09 Oktober 2019, 00:42:00
Bei mir steigt mit dem HTTPMOD Device (habe das TV Device von oben importiert) der Speicherverbrauch ebenfalls an (Debian Buster). Der Anstieg selbst ist abhängig vom Intervall, je kürzer desto stärker ist der Anstieg. Setzt man das Device auf disable steigt der Verbrauch nicht weiter an. Die Readingsgroups habe ich rausgeschmissen und kann sie deshalb ebenfalls ausschließen.

Eine Sache ist mir bei deinen Regex Ausdrücken aufgefallen. Ersetz mal bitte alle:
</a>
durch
<\/a>

Meines Wissens muss ein / immer Escaped sein.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 09 Oktober 2019, 15:25:52
Zitat von: mumpitzstuff am 09 Oktober 2019, 00:42:00
Bei mir steigt mit dem HTTPMOD Device (habe das TV Device von oben importiert) der Speicherverbrauch ebenfalls an (Debian Buster). Der Anstieg selbst ist abhängig vom Intervall, je kürzer desto stärker ist der Anstieg. Setzt man das Device auf disable steigt der Verbrauch nicht weiter an. Die Readingsgroups habe ich rausgeschmissen und kann sie deshalb ebenfalls ausschließen.

Eine Sache ist mir bei deinen Regex Ausdrücken aufgefallen. Ersetz mal bitte alle:
</a>
durch
<\/a>

Meines Wissens muss ein / immer Escaped sein.

Danke schön, habe ich beherzigt und implementiert.
Hat zwar bisher funktioniert??? Und ändert nichts am Fehler... Aber auch ich schätzte möglichst korrekten Code  :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Mave am 10 Oktober 2019, 08:30:07
Nachdem ich FREEZEMON entfernt habe, ist die Speicherauslastung meines RPi nun seit 3 Tagen konstant bei 260 MB +/- 20

Es scheint also nicht speziell an einem einzigen Modul zu liegen sondern abhängig von der Gesamtinstallation.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 10 Oktober 2019, 23:12:42
@Rudi, vielen Dank für den Ansatz mit awk/VmSize. Dadurch gelingt die Analyse präziser als mit sysmon. Ich habe den Code auf DbLog zugeschnitten um die Werte in der DB zu speichern und auszuwerten. Anbei ein Vergleich zwischen sysmon und awk/pstat. Man sieht deutlich die Verzerrung der Werte durch den BlockingCall in der sysmon Ausgabe.
Dadurch ist es mir leichter gefallen eine weitere Speicheroptimierung bei der Verarbeitung von Cam-Aufnahmen vorzunehmen (ist eingecheckt) .

Zur Speicherverwaltung von Perl habe ich mich ein bisschen intensiver belesen und wenn ich alles richtig verstanden habe, stellt es sich folgendermaßen dar (bitte berichtigt mich wenn etwas nicht korrekt ist !).

Im Betrieb fordert Perl beim Betriebsystem Speicher an, sobald er für die Variablen, Hashes etc. benötigt wird. Sobald diese Variablen out of Scope gehen und keine Referenzen mehr darauf bestehen, wird der Speicher Perl-intern wieder freigegeben und kann wiederverwendet werden. 

Aber an das Betriebssystem wird dieser Speicher beim Abräumen (Garbage Collector) _nicht_ wieder zurück gegeben !

Das bedeutet, dass der User ein Ansteigen des Speichers solange beobachten wird, bis das System "eingeschwungen" ist. Das heißt wenn alle benötigten Variablen mindestens einmal verwendet wurden (Webinhalte abgerufen, Aufnahmen versendet, Caches gefüllt, etc), ist die High Water Mark des Speicherverbrauchs erreicht und stabilisiert sich.

Ausnahme ist der Fehlerfall, zum Beispiel weil zirkuläre Referenzen erstellt wurden, die nicht aufgelöst und abgeräumt werden können. Zum Beispiel verwendet das CPAN Modul HTML::TreeBuilder  solche Referenzen um seine Arbeit zu machen.
Diese müssen (in älteren Versionen von HTML::TreeBuilder) explizit aufgebrochen werden. HTTPMOD verwendet zum Beispiel dieses Modul.

CPAN sagt dazu:
Zitatprevious versions of HTML::TreeBuilder required you to call $tree->delete() to erase the contents of the tree from memory when you're done with the tree. This is not normally required anymore. See "Weak References" in HTML::Element for details.

Man muss es eigentlich aktuell nicht mehr tun, aber CPAN sagt auch "normalerweise".  Wäre ein Ansatz bzgl. HTTPMOD, aber _nur_ eine Vermutung !!

BlockingCalls gehen in die Betrachtung überhaupt nicht ein, weil die dort erstellten Variablen mit Beendigung des parallelen Prozesses zerstört werden und der Speicher an das Betriebssystem zurück gegeben wird.

Vielleicht hilft es das Speicherverhalten besser einordnen zu können und ich hoffe alles richtig dargestellt zu haben. Wie gesagt, berichtigt mich bitte wenn nötig.

Grüße,
Heiko

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 11 Oktober 2019, 00:25:00
"Garbage Collector" wuerde ich fuer das bei Java verwendete Verfahren reservieren: grob geht es um ein Thread, was parallel zum Rest laeuft, den Speicher untersucht, und freigegebene Speicherbereiche einsammelt. Ein Speicherstueck kann nach Freigabe nicht sofort wieder benutzt werden, erst wenn der Garbage-Collector es gefunden hat. Diese Methode hat kein Problem mit zirkulaeren Referenzen, kann aber den Prozess laenger blockieren, insb. wenn sehr viel Speicher alloziert ist.

Perl hat keinen separaten Thread, wenn der Referenzcounter eines Speicherstuecks auf 0 faelt, kann es sofort wiederverwendet werden. Diese Methode hat Probleme mit zirkulaeren Referenzen, bremst aber weniger. Dass der Speicher bei Freigabe nicht ans OS zurueckgegeben wird, liegt an dem verwendeten Malloc-Library (eine weitere Abstraktionsschicht, bekannt aus C), obwohl sie bemueht sich: https://stackoverflow.com/questions/2215259/will-malloc-implementations-return-free-ed-memory-back-to-the-system
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: nuccleon am 11 Oktober 2019, 10:51:25
Zitat von: DS_Starter am 10 Oktober 2019, 23:12:42
@Rudi, vielen Dank für den Ansatz mit awk/VmSize. Dadurch gelingt die Analyse präziser als mit sysmon. Ich habe den Code auf DbLog zugeschnitten um die Werte in der DB zu speichern und auszuwerten.
Top!
Würdest du den Code dazu hier teilen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 11 Oktober 2019, 11:00:41
ZitatWürdest du den Code dazu hier teilen?

Natürlich, gerne.

In die 99_myUtils kommt dieses kleine Stückchen:


############################################################################################################
#       RAM Verbrauch von Perl ermitteln und mit "<DbLog-Device>" speichern
#       Aufruf mit: { psize("<DbLog-Device>") }
############################################################################################################
sub psize($) {
    my ($name) = @_;
   
my $ts  = FmtDateTime(time);
my $ret = $ts."|psize|manual|manual|size|";
my $v   = `awk '/VmSize/{print \$2}' /proc/$$/status`;
$ret   .= sprintf("%.2f",(rtrim($v)/1024));
$ret   .= "|MB";

fhem ("set $name addCacheLine $ret");

return;
}


EDIT: DbLog muss im asynchronen Mode laufen wegen "addCacheLine".
Der Aufruf erfolgt dann mit "{ psize("<DbLog-Device>") }". Dazu habe ich ein at erstellt, was den Aufruf regelmäßig durchführt:


defmod AT.pSize at +*00:01 { psize("LogDBShort") }
attr AT.pSize icon clock
attr AT.pSize room Dienste->Monitoring


Hinweis: weil doch sehr viele gleiche Werte geloggt werden, kann man dann mit DbRep eine sehr einfache  Datenreduzierung vornehmen mit:


set <DbRep-Device> delSeqDoublets delete


Das habe ich dann auch regelmäßig über ein at eingeplant um nur die Pegeländerungen in der DB zu halten.

Grüße,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: StefanStrobel am 13 Oktober 2019, 08:52:10
Hallo,

Treebuilder wird von HTTPMOD nur verwendet, wenn in der Konfiguration mit XPath gearbeitet wird.

        } elsif ($aName eq "enableXPath"
                || $aName =~ /(get|reading)[0-9]+XPath$/
                || $aName =~ /[Rr]eAuthXPath$/
                || $aName =~ /[Ii]dXPath$/) {
            eval "use HTML::TreeBuilder::XPath";
            if($@) {
                return "Please install HTML::TreeBuilder::XPath to use the xpath-Option (apt-get install libxml-TreeBuilder-perl libhtml-treebuilder-xpath-perl) - error was $@";
            }
            $hash->{XPathEnabled} = ($aVal ? 1 : 0);
        }

In dem von Hardlife beschriebenen Problem ist aber alles mit Regexes umgesetzt.
Ich habe seine (abgespeckte) Konfiguration über Nacht und eine Weile sogar mit 10-Sekunden-Intervall auf meinem Raspberry laufen lassen, aber keinen Speicheranstieg nachvollziehen können.

Es muss also tatsächlich an weiteren Parametern liegen.

Gruss
   Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 13 Oktober 2019, 12:19:10
Was für ein Raspbian verwendest du denn? Unabhängig von Hardlife konnte ich (ich habe buster installiert) und noch ein weiterer User das sofort nachvollziehen. Bei mir läuft auf dieser fhem Installation auch kaum mehr als ein paar Sensoren, die per FHEM2FHEM von der Hauptinstallation abgefragt werden.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: StefanStrobel am 13 Oktober 2019, 13:08:59
Hallo,

ich habe es auf Stretch mit Perl 5.24.1.

seit heute morgen habe ich auch noch einen Test mit der vollen Konfiguration von Hardlife am Laufen.
Mal sehen was da passiert.
Eventuell ist da ja etwas drin, was den Fehler auslöst, aber bei seiner reduzierten Konfiguration (auch ohne Readingsgroup) fehlt.
Auf den ersten Blick sah es jedoch so aus, als ob es einfach nur mehr Readings mit mehr Regexes wären ...
Ich bleibe dran.

Gruss
   Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 14 Oktober 2019, 18:44:42
Eventuell kann ich noch etwas beitragen? Ich nutze seit mindestens einem Jahr perl 5, version 20, subversion 3 (v5.20.3) built for x86_64-linux-thread-multi. Alle darüberliegenden Perl-versionen haben bei mir generell zu einem Speicheranstieg geführt, welches ich nicht eingrenzen konnte.


Erklärung zum Dateianhang:
(1) Bis zum 19.10.2019 hatte ich das KODI Modul mit IP Adressen als Ziel im internen Netzwerk laufen.
(2) Seitdem ich die Einstellung auf DNS (z.B. htpc-pi2.fritz.box) umgestellt habe, ist ein deutlich linearer Speicheranstieg zu beobachten (4 eingerichtete Module im 60 Sekunden polling Takt) mit mehreren Neustarts
(3) Hier habe ich auf einem Snapshot meiner Produktions-VM herumgetestet ... daher keine Daten
(4) Hier bin ich wieder zurückgeswitched auf IP-Adresse und es sieht (zumindest in dem kurzen Zeitraum) wieder besser aus


Womöglich hat Perl, das KODI Modul oder FHEM ein DNS Namensauflösungsproblem? Eventuell können andere das Problem hiermit auch eingrenzen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Frank_Huber am 14 Oktober 2019, 19:42:43


Zitat von: fhemxperte am 14 Oktober 2019, 18:44:42
Womöglich hat Perl, das KODI Modul oder FHEM ein DNS Namensauflösungsproblem? Eventuell können andere das Problem hiermit auch eingrenzen?

Ich glaube hierfür wäre es noch wichtig zu wissen ob Du im global das dns Server Attribut gesetzt hast.

Gesendet von meinem S60 mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 14 Oktober 2019, 20:31:44
ZitatIch glaube hierfür wäre es noch wichtig zu wissen ob Du im global das dns Server Attribut gesetzt hast.

Korrekt, danke für den Gedankenanstoß. Den hatte ich nicht mehr im Kopf...

Meine Einstellung ist dnsServer=127.0.0.1, da ich lokal den Pi-Hole betreibe, somit sollte die Namensauflösung über den "FHEM specific nonblocking code" gehen anstatt über das OS.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 14 Oktober 2019, 21:01:38
Wenn HttpUtils die interne Namensaufloesung verwendet (d.h. dnsServer ist gesetzt), dann wird das Ergebnis jeder Namensaufloesung gespeichert.
Das fuehrt zum Speicherloch, wenn man staendig andere Rechnernamen aufloesen will. Ich gehe davon aus, dass das nie der Fall ist.

Man kann aber pruefen, ob sie die Ursache ist, indem man dnsServer entfernt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: herrmannj am 14 Oktober 2019, 21:12:50
Für alle die perl downgraden möchten (Linux)

* https://perlbrew.pl/


\curl -L https://install.perlbrew.pl | bash
echo source ~/perl5/perlbrew/etc/bashrc >> $HOME/.bashrc
perlbrew install perl-5.20.2
perlbrew switch perl-5.20.2


edit fhem.service

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


richtigen Pfad eintragen. Im Zweifel echo $PATH

ExecStart=/home/pi/perl5/perlbrew/perls/perl-5.20.2/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl fhem.cfg



sudo systemctl daemon-reload
sudo service fhem restart


Prüfen ob fhem läuft. Dann in der Eingabezeile von fhem die richtige perl version prüfen: (hier dann 5.20.2)
{$^V}

cpanm (https://perlbrew.pl/Perlbrew-and-Friends.html)
perlbrew install-cpanm
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 14 Oktober 2019, 21:18:17
Ab sofort kann man den HttpUtils internen Cache (d.h. wenn dnsServer gesetzt ist ) ausgeben mit:

fhem> { HttpUtils_dumpDnsCache() }
amazon.de    TS: 2019-10-14 21:15:14   TTL:   171   ADDR: 54.239.39.102
fhem.de      TS: 2019-10-14 21:13:54   TTL: 49166   ADDR: 88.99.31.202
google.com   TS: 2019-10-14 21:13:49   TTL:    11   ADDR: 172.217.16.78
heise.de     TS: 2019-10-14 21:13:51   TTL: 44493   ADDR: 193.99.144.80
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 14 Oktober 2019, 21:31:06
Gute Analysefunktion rudolfkoenig, werde ich mir merken, ggf. auch für die anderen interessant.

Ich werde nun allerdings erstmal die Woche durchtesten (und bei einer gleichbleibenden Version bleiben).


Danach werde ich updaten und prüfen was HttpUtils intern cached.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 16 Oktober 2019, 11:32:36
Update:

Folgende Tests habe ich nun durchgeführt (allerdings hat pro Test ein Tag ausgereicht).

Zitat

  • 2-3 Tage ohne dnsServer Eintrag in global
  • 2-3 Tage nochmal die Gegenprobe mit dem dnsServer Eintrag

Im Anhang sieht man das Ergebnis:

1.) In diesem Teil des Diagramms habe ich das Attribut dnsServer aus global gelöscht und laufen lassen -> Eine konstante Gerade
2.) In diesem Teil des Diagramms habe ich das Attribut dnsServer mit dem Value 127.0.0.1 auf meinen lokalen Pi-Hole wieder in global erstellt und laufen lassen -> Eine Gerade die linear ansteigt

Andere Änderungen habe ich zwischen diesen Tests nicht durchgeführt.


Jetzt werde ich Fhem updaten und die neue Analysefunktion des DNS Caches aus den HTTPUtils testen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 16 Oktober 2019, 14:26:52
Das kann ich bei mir leider nicht bestätigen. Ich habe durch 1 httpmod device eine steigende Gerade und hatte dort das dnsServer Attribut gesetzt. Dieses habe ich mit delete gelöscht und danach keine Änderung im Anstieg feststellen können. Vielleicht ist das einfache Löschen aber auch nicht ausreichend gewesen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: StefanStrobel am 16 Oktober 2019, 19:08:33
Ein paar Zwischenergebnisse von meiner Seite:

mit der vollen HTTPMOD-Konfiguration für die TV-Programme von Hardlife sehe ich auch einen kontinuierlichen Anstieg im Speicherverbrauch. Auch wenn ich die readingsgroups entferne ist dieser über einen Tag hinweg sichtbar.

Wenn ich den aktuellen HTML-Content von der abgefragten Website als Datei speichere und die HTTPMOD-Konfiguration so ändere, dass die Daten nicht von der Original-Website sondern als file:// gelesen werden, ist kein Anstieg sichtbar. Natürlich ändert sich der Inhalt dann nicht mehr, aber das Parsen von HTTPMOD wird dennoch ständig neu gemacht.

Um ganz sicher zu sein habe ich jetzt HTTPMOD zum Testen so erweitert, dass der Content nach jedem Seitenabruf in einer eigenen Datei gespeichert wird.
Nach einem Tag plane ich dann alle Seiten der letzten 24 Stunden aus den jeweiligen Dateien lesen zu lassen. So müsste sich klären lassen, ob der Leak irgendwo beim Parsen der Seiten passiert oder beim Abruf per HTTP.

Ich berichte wenn ich ein Ergebnis habe.

Gruss
   Stefan


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 16 Oktober 2019, 19:37:24
@Hardlife: Falls Du eventTypes definiert hast, und die beiden HTPMOD Definitionen nicht auf dem ignoreList sind, dann waere das eine (teilweise?) Erklaerung des Speicheranstiegs.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 16 Oktober 2019, 20:45:20
Bei mir ist der Anstieg desto höher, je mehr Regex Ausdrücke im Httpmod Device vorhanden sind. Da gibt es meiner Meinung nach einen Zusammenhang. Die Readinggroup konnte ich als Ursache ebenfalls ausschließen.

Zitat von: StefanStrobel am 16 Oktober 2019, 19:08:33
Ein paar Zwischenergebnisse von meiner Seite:

mit der vollen HTTPMOD-Konfiguration für die TV-Programme von Hardlife sehe ich auch einen kontinuierlichen Anstieg im Speicherverbrauch. Auch wenn ich die readingsgroups entferne ist dieser über einen Tag hinweg sichtbar.

Wenn ich den aktuellen HTML-Content von der abgefragten Website als Datei speichere und die HTTPMOD-Konfiguration so ändere, dass die Daten nicht von der Original-Website sondern als file:// gelesen werden, ist kein Anstieg sichtbar. Natürlich ändert sich der Inhalt dann nicht mehr, aber das Parsen von HTTPMOD wird dennoch ständig neu gemacht.

Um ganz sicher zu sein habe ich jetzt HTTPMOD zum Testen so erweitert, dass der Content nach jedem Seitenabruf in einer eigenen Datei gespeichert wird.
Nach einem Tag plane ich dann alle Seiten der letzten 24 Stunden aus den jeweiligen Dateien lesen zu lassen. So müsste sich klären lassen, ob der Leak irgendwo beim Parsen der Seiten passiert oder beim Abruf per HTTP.

Ich berichte wenn ich ein Ergebnis habe.

Gruss
   Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 16 Oktober 2019, 21:46:42
Ich kann auf einem OSX Rechner einen Bug nachvollziehen, was hier: https://rt.cpan.org/Public/Bug/Display.html?id=123520 beschrieben ist.
Das Problem betrifft alle TLS Verbindungen (nicht nur HTTPS oder HttpUtils). Hardlife waere auch betroffen, da http://www.klack.de nach https umleitet.
Ein Update von IO::Socket::SSL auf 2.066 und Net::SSLeay auf 1.88 hilft nicht, getestet mit perl 5.18 bzw. 5.28.

Auf debian buster (perl 5.28) oder auf ubuntu 14.04 (perl 5.18) hat das gleiche Programm _kein_ Speicherloch.
Seufz.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 16 Oktober 2019, 22:47:24
Ich habe buster mit Perl 5.28. Aber es könnten auch hier wieder mehrere Dinge zusammen spielen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 16 Oktober 2019, 22:57:35
Zitat von: rudolfkoenig am 16 Oktober 2019, 19:37:24
@Hardlife: Falls Du eventTypes definiert hast, und die beiden HTPMOD Definitionen nicht auf dem ignoreList sind, dann waere das eine (teilweise?) Erklaerung des Speicheranstiegs.

Hmmm.
Ok, ich hatte zwar noch nie ein ignorelist-Attribut beim eventtypes-Device, aber ich versuche es mal.
Soll ich ALLE HTTPMOD-Devices, welche RegEx beinhalten auf die ignorelist setzten?
Und was würde das bewirken/unterbinden?

Danke,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 17 Oktober 2019, 09:32:07
ZitatUnd was würde das bewirken/unterbinden?
eventTypes sammelt alle Events von jedem Geraet, damit man diese in Wizards (Hilfen im Benutzerinterface, wie z.Bsp. bei notify oder FileLog) verwenden kann.
Zahlen, HTML(?), lange Texte und etliches mehr werden ignoriert, nicht aber Sendungsnamen.
D.h. immer neue Sendungen koennen bei eventTypes zu einem "unendlichen" Archiv fuehren.

Aber ich sehe gerade: Anzahl der gespeicherten Events pro Device ist auf 200 begrenzt.

Bei FHEM Start wird eine Meldung ausgegeben: "eventTypes: loaded X events from Y".Falls X ungewoehnlich gross ist, sollte man handeln.


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: StefanStrobel am 17 Oktober 2019, 19:25:09
Hallo,

Als ich gestern begonnen habe, alle HTTP-Responses, die bei der Konfiguration von Hardlife eingehen, in Dateien zu sichern, habe ich auch das globale Attribut dnsServer gelöscht und danach Fhem neu gestartet.

Jetzt wäre ich also bereit, alles mit Dateien zu testen, aber die Speicherüberwachung hat für die letzten 24h keinen Anstieg mehr aufgezeichnet. Es geht zwar zwischendrin mal hoch, dann aber auch wieder runter. Damit haben sich die weiteren Tests eher erledigt.
Für mich sieht es so aus, als liegt es nur am dnsServer-Attribut.

Ich werde es mal noch einen weiteren Tag beobachten ...

Gruss
    Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 17 Oktober 2019, 20:00:53
Zitat von: rudolfkoenig am 17 Oktober 2019, 09:32:07
Bei FHEM Start wird eine Meldung ausgegeben: "eventTypes: loaded X events from Y".Falls X ungewoehnlich gross ist, sollte man handeln.

Ahh, danke für die Erklärung.

...
Server started with 1039 defined entities
...
eventTypes: loaded 9421 events from ./log/eventTypes.txt
...


... kommt mir in Relation gesehen nun nicht ganz so abnormal vor...



Zitat von: StefanStrobel am 17 Oktober 2019, 19:25:09
Für mich sieht es so aus, als liegt es nur am dnsServer-Attribut.

-> Diese Attribut habe ich leider gar nicht in Verwendung und trotzdem den Anstieg...


LG,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 17 Oktober 2019, 21:17:15
Zitat von: StefanStrobel am 17 Oktober 2019, 19:25:09
Hallo,

Als ich gestern begonnen habe, alle HTTP-Responses, die bei der Konfiguration von Hardlife eingehen, in Dateien zu sichern, habe ich auch das globale Attribut dnsServer gelöscht und danach Fhem neu gestartet.

Jetzt wäre ich also bereit, alles mit Dateien zu testen, aber die Speicherüberwachung hat für die letzten 24h keinen Anstieg mehr aufgezeichnet. Es geht zwar zwischendrin mal hoch, dann aber auch wieder runter. Damit haben sich die weiteren Tests eher erledigt.
Für mich sieht es so aus, als liegt es nur am dnsServer-Attribut.

Ich werde es mal noch einen weiteren Tag beobachten ...

Gruss
    Stefan

So ist es bei mir auch mit den Ups and Downs, das sollte aber je nach Last usw normal sein. Die Personen, die das DNSServer Attribut nicht gesetzt haben, haben wahrscheinlich noch ein weiteres mögliches Leck entdeckt.


Im Anhang enthalten ist mein neuer Graph mit der letzten Fhem Version und gesetztes DNSServer Attribut (die Zahl 1 im Graph kennzeichnet den Anstieg seit Update). Zudem habe ich das Auslesen des DNS Caches der HttpUtils getestet, allerdings sind hier keine Anzeichen eines Speicheranstiegs zu erkennen. Der Cache bleibt gleich befüllt.


16.10.2019 11:38:
api.luftdaten.info       TS: 2019-10-16 11:35:50   TTL:  1121   ADDR: 81.169.180.11
api.openweathermap.org   TS: 2019-10-16 11:36:02   TTL:  1907   ADDR: 37.139.20.5
api.telegram.org         TS: 2019-10-16 11:36:06   TTL:   328   ADDR: 32.1.6.124.4.232.240.4.0.0.0.0.0.0.0.9
api.wunderground.com     TS: 2019-10-16 11:35:50   TTL:    20   ADDR: 23.211.10.129
data.sensor.community    TS: 2019-10-16 11:35:50   TTL: 12028   ADDR: 42.1.2.56.66.241.51.0.235.174.86.156.201.88.223.56
htpcpi2-sz.fritz.box     TS: 2019-10-16 11:37:59   TTL:     9   ADDR: 192.168.20.27
htpcpi2-wz.fritz.box     TS: 2019-10-16 11:37:59   TTL:     9   ADDR: 192.168.20.45
htpcpi3-bl.fritz.box     TS: 2019-10-16 11:37:59   TTL:     9   ADDR: 192.168.20.35
www.allergie.hexal.de    TS: 2019-10-16 11:36:36   TTL:  3600   ADDR: 134.119.224.159
www.verkehrsinfo.de      TS: 2019-10-16 11:35:50   TTL:   101   ADDR: 217.160.0.27



17.10.2019 21:10:
api.luftdaten.info       TS: 2019-10-16 11:35:50   TTL:  1121   ADDR: 81.169.180.11
api.openweathermap.org   TS: 2019-10-17 20:39:04   TTL:   918   ADDR: 82.196.7.246
api.telegram.org         TS: 2019-10-17 21:10:04   TTL:   189   ADDR: 32.1.6.124.4.232.240.4.0.0.0.0.0.0.0.9
api.wunderground.com     TS: 2019-10-17 21:05:59   TTL:    20   ADDR: 23.211.10.129
data.sensor.community    TS: 2019-10-16 11:35:50   TTL: 12028   ADDR: 42.1.2.56.66.241.51.0.235.174.86.156.201.88.223.56
htpcpi2-sz.fritz.box     TS: 2019-10-17 21:09:13   TTL:     9   ADDR: 192.168.20.27
htpcpi2-wz.fritz.box     TS: 2019-10-17 21:09:47   TTL:     9   ADDR: 192.168.20.45
htpcpi3-bl.fritz.box     TS: 2019-10-17 21:09:47   TTL:     9   ADDR: 192.168.20.35
www.allergie.hexal.de    TS: 2019-10-17 20:36:38   TTL:  3600   ADDR: 134.119.224.159
www.verkehrsinfo.de      TS: 2019-10-17 20:05:58   TTL:  3600   ADDR: 217.160.0.27


Kann ich noch etwas beisteuern um das Problem einzugrenzen? Installierte Versionen diverser CPAN Bibliotheken? Oder Erstellung einer Fhem Konfiguration die bei jedem funktioniert zur Nachanalyse (kann ich natürlich nicht garantieren, aber probieren)?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 18 Oktober 2019, 01:01:03
ZitatFür mich sieht es so aus, als liegt es nur am dnsServer-Attribut.
Ich habe ein Speicherloch in HttpUtils_gethostbyname bei gesetztem dnsServer mit debian/buster, perl 5.28 gefunden und gefixt.
Evtl. tritt das Problem auch mit anderen Perl-Versionen auf, das habe ich aber nicht verifiziert.
Es hat ca 10kb pro Lookup verloren, wenn die IP nicht im Cache war. Das bedeutet ca 1MB pro Tag und Adresse, wenn TTL auf 900s gesetzt ist, wie bei www.klack.de
Ich tippe auf einem perl Bug, es ist mir aber zu kompliziert, um es nachzuweisen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 18 Oktober 2019, 08:03:16
Auch wenn es jetzt OT (und ich nicht betroffen):
Ich muß Dir (und allen die dabei geholfen haben) mal ein DANKE für Bugsuche und Fixing aussprechen!
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: fhemxperte am 19 Oktober 2019, 10:38:22
Zitat von: rudolfkoenig am 18 Oktober 2019, 01:01:03
Ich habe ein Speicherloch in HttpUtils_gethostbyname bei gesetztem dnsServer mit debian/buster, perl 5.28 gefunden und gefixt.
Evtl. tritt das Problem auch mit anderen Perl-Versionen auf, das habe ich aber nicht verifiziert.
Es hat ca 10kb pro Lookup verloren, wenn die IP nicht im Cache war. Das bedeutet ca 1MB pro Tag und Adresse, wenn TTL auf 900s gesetzt ist, wie bei www.klack.de
Ich tippe auf einem perl Bug, es ist mir aber zu kompliziert, um es nachzuweisen.


Hi rudolfkoenig,

ziemlich cool, dass du das Leck gefunden hast. Scheinbar, war es das, was den Speicheranstieg bei mir verursacht hat (und wahrscheinlich bei ganz vielen anderen). Es wird bestimmt nicht das einzige Leck sein, aber dafür ein sehr zentrales. Das Leck ist mindestens in den Perl Versionen "perl 5, version 20, subversion 3 (v5.20.3)" bis zu deiner eingesetzten 5.28 vorhanden.

Zur Verdeutlichung habe ich nochmal ein neues Diagramm beigefügt.
1 = Der Test ohne das dnsServer Attribut - Ergebnis: Perfekte horizontale Gerade
2 = Der Test mit dnsServer Attribut inkl. Updates usw - Ergebnis: Speicherleck, ansteigende Gerade
3 = Der Test nach Update mit gefixtem HttpUtils_gethostbyname - Ergebnis: (bisher) perfekte horizontale Gerade

Meinerseits war es Zufall, dass ich von IP Adressen auf interner DNS-Auflösung umstellen wollte und der Speicher anstieg, aber manchmal braucht es genau so etwas.

Vielen Dank soweit.

Gruß,
Michael
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: parabacus am 23 Oktober 2019, 08:57:39
Hallo zusammen!

Ich bin auch schon einige Zeit betroffen und lese auch schon länger mit. Leider sind meine Kenntnisse zu gering, um bei der Problemsuche im Detail zu helfen, jedoch kann ich jetzt auch bestätigen, dass es bei mir auch an der Verwendung von HTTPMOD liegt.

Ich lese meinen PV-Wechselrichter damit aus - genau nach dieser Umsetzung, was eigentlich bisher auch problemlos funktioniert:
https://forum.fhem.de/index.php/topic,46685.msg730900.html#msg730900 (https://forum.fhem.de/index.php/topic,46685.msg730900.html#msg730900)

Bei läuft das auf einem RasPi 3 mit Stretch und drauf ist Perl 5.24.1.

Als ich jetzt vor ein paar Tagen das Auslesen komplett entfernt habe, kann ich keinen Anstieg mehr feststellen.

Erst mal werde ich damit so leben - das Auslesen der Daten ist eh nur Spielerei und brauche ich nicht wirklich dringend.
Dennoch schon mal vielen Dank für die intensive Suche der Beteiligten, womit ich nun auch endlich weiss, was ich pragmatisch machen kann.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 23 Oktober 2019, 10:32:45
War in deinem Fall dnsServer aktiviert?
Wenn ja, hilft ein update auf die aktuelle Version?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: parabacus am 23 Oktober 2019, 13:17:27
Soweit ich das bewerten kann, ist dnsServer nicht aktiviert - zumindest ist kein Attribut gesetzt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 23 Oktober 2019, 21:20:00
Ich glaube das Problem bei HTTPMOD gefunden zu haben und damit wahrscheinlich auch das Problem vieler weiterer Module.

HTTPMOD holt sich seine regular Expressions aus Attributen, die der Anwender anlegen kann. Diese werden dann auf den Inhalt der Webseite losgelassen. Und genau hier liegt der Hund begraben. Die eingelesenen regular Expression besitzen ein besonderes Encoding. Das sorgt jetzt dafür, dass die regular Expressions zwar funktionieren, diese aber Perl intern Memory Leaks erzeugen. Um meine Theorie zu untermauern habe ich folgendes probiert und siehe da, die Memory Leaks bei HTTPMOD waren weg.

use utf8;
use Encode qw(encode_utf8 decode_utf8);
$regex = decode_utf8($regex);


Das eigentlich fatale daran ist, das der Programmierer dieses Problem nicht einmal bemerkt, denn auf den ersten Blick funktioniert alles wunderbar. Erst auf den Zweiten schwindet der RAM dahin.

Könnte man dieses Problem irgendwie zentral angehen und somit das Problem für alle Module aus der Welt schaffen?

Ansonsten habe ich das in einem meiner Module wie folgt gelöst:

1.) use utf8; am Anfang des Moduls
2.) Alles was an Strings von außerhalb des Moduls kommt (jedes reading, attribut, user eingabe usw.) durch die Funktion decode_utf8() jagen
3.) Alles was an Strings raus geht aus dem Modul (reading schreiben usw. usw.) durch die Funktion encode_utf8() jagen
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: herrmannj am 23 Oktober 2019, 22:06:45
Moin,

Es gibt (scheinbar) unter bestimmten Perl Version ein regex Mem leak: https://stackoverflow.com/questions/43288921/perl-program-leaking-memory-when-compiling-regex

https://github.com/perl/perl5/issues/15746

Würde mMn auch hier schon im thread behandelt. Scheinbar jedoch auch vom os, wetter, Sternenstand abhängig und scheinbar nie zu 100% reproduzierbar.

Möglich dass das bei dir funktioniert, woanders nicht. Hast du das per Trial and error gefunden oder kommen die Infos auch von wo anders?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 23 Oktober 2019, 22:13:01
Ich gehe davon aus, dass die "utf8-Loesung" nur in bestimmten Faellen hilft, weil einmy $i=0;
while(1) { $i++; "bla" =~ /$i/ }
kein Speicher verliert.
Es waere aber interessant zu wissen, was genau zum Speicherverlust fuehrt.

Das Problem zentral anzugehen reicht nicht, es muessten alle Module angepasst werden, damit sie decode nach jedem read, und encode vor jedem write ausfuehren.
Das fuer alle FHEM-Module durchzufuehren und testen ist aussichtslos, und wuerde vermutlich zu mehr Speicherverbrauch fuehren, da alle Daten intern knapp doppelt so viel Platz einnehmen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: herrmannj am 23 Oktober 2019, 22:30:18
Naja, Perl Version / Platform / distri und Sternenstand

Man braucht wohl compiled regex, was der Perl in der Optimierung manchmal selber macht. Ich konnte das nach einem Upgrade auf Buster Mal beobachten ohne das wirklich 100% auf die konkrete regex runter brechen zu können. Nach einem Perl downgrade war es weg. Dabei habe ich's dann auch belassen. Von daher schon möglich

Nachtrag: und ohne sicher sagen zu können das es wirklich regex waren
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 23 Oktober 2019, 23:28:46
Zitat von: rudolfkoenig am 23 Oktober 2019, 22:13:01
Ich gehe davon aus, dass die "utf8-Loesung" nur in bestimmten Faellen hilft, weil einmy $i=0;
while(1) { $i++; "bla" =~ /$i/ }
kein Speicher verliert.

Das Problem tritt immer nur auf, wenn Daten von außen ins Modul kommen und Zeichen jenseits von Zahlen und Buchstaben enthält. Außen bedeutet in diesem Fall: Usereingaben. Wie und durch welche Mechanismen das genau passiert entzieht sich meiner Kenntnis. Meines Erachtens ist das Problem zweistufig. Irgendwoher kommt ein falsch encodierter String rein und dieser String verursacht in Stufe 2 Memory Leaks in Perl. Das Problem tritt auch nicht bei jedem Anwender auf, sondern hängt unter anderen mit der Locale Einstellung zusammen, vielleicht auch noch mit anderen Faktoren. Das blöde daran ist, das man das nicht gleich sieht. In meinem Kalendermodul hatten auch nur einige Personen Probleme z.B. mit Umlauten. Das lag dort ebenfalls am Encoding und wurde durch utf8 behoben. Das Fehlerbild passt exakt zu dem was wir hier die ganze Zeit beobachten, nämlich das einige das Problem massiv haben und andere es einfach nicht nachvollziehen können.
Ich kann aber gern mal die HTTPMOD Version zur Verfügung stellen, bin aber eigentlich nicht der Entwickler des Moduls. In diesem Thread gab es bereits mind. 2 Leute die ebenfalls Probleme damit hatten. Vielleicht können sie das Ergebnis im Fall von HTTPMOD verifizieren.

Meine locale Einstellungen sehen auf dem Debian Buster Pi so aus:
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 24 Oktober 2019, 01:35:48
Im Anhang befindet sich die von mir veränderte HTTPMOD Version (entspricht ansonsten der aktuellsten Version). Bei mir ist damit der steigende Speicherverbrauch komplett weg, wie man auf dem anderen Bild sehen kann.

Getestet mit dem von Hardlife hier geposteten TV_Programme Device:
https://forum.fhem.de/index.php/topic,84372.msg981483.html#msg981483 (https://forum.fhem.de/index.php/topic,84372.msg981483.html#msg981483)

Ich würde mich freuen, wenn Hardlife und parabacus das mal testen könnten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: StefanStrobel am 24 Oktober 2019, 19:12:58
Hallo,

so wie ich das sehe reden wir über einen Perl-Bug, der eine Ähnlichkeit zu einem alten Bug in Perl 5.24 hat und eigentlich behoben sein sollte.
Dieser scheint unter unklaren Bedingungen getriggert zu werden, hat aber damit zu tun, dass Regexes nicht richtig "verdaut" werden.
Da bei HTTPMOD die Regexes vom Anwender per Attribut definiert werden, kann es also vorkommen, dass der Anwender Sonderzeichen verwendet hat, die dem Perl-Interpreter in bestimmten Versionen und unter bestimmten Umständen nicht schmecken und zu einem Memory-Leak führen.
Habe ich das soweit richtig verstanden?

Leider tritt der Fehler bei mir ja nicht in dieser Form auf und ich kann es daher nicht nachstellen / testen.
Bisher nehme ich die Regexes aus $attr{$name}, ohne irgendwelche Umkodierungen.

Wenn es bei dem Problem um die interne Kodierung der Regexes aus Attributen geht, dann wäre es für mich naheliegender, in der AttrFn eine Art Bereinigung durchzuführen, bevor die Werte gespeichert werden. Da würde ich aber befürchten, dass andere Dinge (bei anderen Anwendern) nicht mehr funktionieren.

Wenn der Perl-Bug umgangen werden kann, wenn bei einem Regex-Match die Regex als utf8 interpretiert wird, dann würde ich nur vor dem betreffenden match ein use utf8 und direkt danach wieder ein no utf8 setzen. Nach meinem Verständnis passt das dann aber nicht zu dem vorgeschlagenen decode, denn der Interpreter würde dann ja erst recht utf8 Regexes erwarten ...

ich würde ungern ein Befehle in HTTPMOD einbauen, bei denen ich den Effekt nicht wirklich verstanden habe.
Was meint Ihr dazu?

Gruss
    Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 24 Oktober 2019, 20:48:11
So hier ein kurzes Script mit dem jeder prüfen kann ob er betroffen ist oder nicht.

#!/usr/bin/perl
use strict;
use warnings;
use utf8;
use Encode qw(encode_utf8 decode_utf8);


sub leak($$)
{
  my ($data, $regex) = @_;
 
  my @matches = ($data =~ /$regex/);
 
  print "matches = ".join(", ", @matches)."\n" if (@matches);
}

sub noleak($$)
{
  my ($data, $regex) = @_;
 
  $regex = decode_utf8($regex);
 
  my @matches = ($data =~ /$regex/);
 
  print "matches = ".join(", ", @matches)."\n" if (@matches);
}


for (my $i = 0; $i < 9999; $i++)
{
  leak('title="SAT.1"><img<td class="timeRow"><div<div class="content"><a>match_first</a>', 'title="SAT.1"><img[\w\W]*?<td class="time[\w\W]*?Row">[\w\W]*?<div[\w\W]*?<div class="content">\s*<a[\w\W]*?>\s*(.*?)\s*<\/a>');
  leak('title="ORF 3"><img<div class="content"><a>match_second</a>', 'title="ORF 3"><img[\w\W]*?<div class="content">\s*<a[\w\W]*?>\s*(.*?)\s*<\/a>');
}


In dieser Version schaufelt mir das Script den RAM auf meinem Raspberry in Sekunden zu! Ersetze ich innerhalb der for Schleife "leak" durch "noleak" erhalte ich weiterhin matches und es wird kein RAM mehr verbraucht.

qed

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: herrmannj am 24 Oktober 2019, 21:11:26
Debian, perl 5.22 / Ubuntu 16.04.6 -> keine Auffälligkeiten
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 24 Oktober 2019, 21:28:10
Kann den Test wie von mumpitzstuff beschrieben 100%ig bestätigen.

perl5.28.1 / deb10u1 (2019-09-20)  Buster
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 24 Oktober 2019, 21:30:29
osx, perl 5.18 => kein Speicherloch
ubuntu, perl 5.18 => kein Speicherloch

osx, perl 5.30 => Speicherloch
debian buster, perl 5.28 => Speicherloch


Nachtrag:osx, perl 5.24 => kein Speicherloch
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 24 Oktober 2019, 21:37:10
Also Leak bei Perl > 2.24?

Kann mir jetzt noch jemand erklären weshalb das mit noleak() verschwindet? Hat dafür jemand eine Erklärung?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: herrmannj am 24 Oktober 2019, 21:41:43
wird sich in den source von perl finden lassen. Aber "bug" sagt ja auch dass es auch so gehen sollte - aber eben nicht tut.

hmmmm.... Anfangen alle regex(e) zu kapseln... (?)

Aus gegebenem Anlass: https://forum.fhem.de/index.php/topic,84372.msg983856.html#msg983856 ;)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 24 Oktober 2019, 22:02:55
Ich habe mal einen Bug reported:

https://github.com/Perl/perl5/issues/17218 (https://github.com/Perl/perl5/issues/17218)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nestor am 25 Oktober 2019, 09:22:47
archlinux perl v5.30.0
leak function: 740MB
noleak function: 7.74MB
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 25 Oktober 2019, 10:01:34
Ich habe den Codeschnipsel in meine 99_Utils gepackt und einen reload gemacht.

Dumme frage: wie rufe ich die Funktion auf..?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Morgennebel am 25 Oktober 2019, 10:03:42
Devuan ASCII 2.0 / perl 5.24.1 - kein Speicherproblem

Ciao, -MN
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 25 Oktober 2019, 10:16:11
Zwischenzeitlich haben sich die Perl Jungs gemeldet. Wenn es stimmt, dann ist der Bug in allen Perl Versionen ab 5.27 enthalten. Soweit ich mich erinnere war der andere leak Bug mit 5.26 behoben. Deshalb ist die 5.26 wahrscheinlich die stabilste Version, zumindest was die von uns nachvollzogenen Bugs angeht. Falls also jemand die Möglichkeit hat die Perl Version zu wechseln, scheint mir aktuell das die sicherste Hausnummer zu sein.

Die Probleme treten übrigens fast ausschließlich beim Kompilieren der Regex Ausdrücke auf, was letztendlich bedeutet, dass es aktuell keine gute Idee ist, diese innerhalb eines Moduls ständig neu zu kompilieren. Das sieht man daran, das wenn man im Script einen leak Aufruf entfernt, der Bug nicht mehr auftritt, weil der Ausdruck const ist und Perl das merkt.
Hat man also regular Expressions die sehr häufig ausgeführt werden müssen und nutzt man dabei Variablen für die Ausdrücke (die sich ändern von Aufruf zu Aufruf), dann sollte man die Ausdrücke mir qr// vorkompilieren und sich irgendwo im Speicher ablegen. Durch Verwendung der vorkompilierten Ausdrücke tritt dann der Leak nur einmalig auf, was mitunter verkraftbar  ist.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nestor am 25 Oktober 2019, 10:52:49
I tested Perl v5.26 on macOS and it is also leaking.

/usr/bin/time -lp /opt/local/bin/perl5.26 Desktop/leaktest.pl
571363328  maximum resident set size = 571MB


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 25 Oktober 2019, 11:02:41
ZitatZwischenzeitlich haben sich die Perl Jungs gemeldet.
Hab das commit angeschaut, braeuchte aber laenger, um sinnvoll beitragen zu koennen. Vermutlich fehlt "nur" ein SvREFCNT_dec_NN :)
Durch Diff-Lesen bin ich auf dem modifier /a gestossen, damit tritt das Problem unter 5.30 _nicht_ auf.
Das waere mAn eine Loesung mit weniger Seiteneffekten.


ZitatI tested Perl v5.26 on macOS and it is also leaking.
This contradicts the comment of dur-randir from the linked perl-issue site.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Nestor am 25 Oktober 2019, 11:39:54
These are Perl packages from MacPorts, all leaking except for 5.24

/usr/bin/time -l /opt/local/bin/perl5.24 Desktop/leaktest.pl > /dev/null
   5017600  maximum resident set size

/usr/bin/time -lp /opt/local/bin/perl5.26 Desktop/leaktest.pl > /dev/null
807833600  maximum resident set size

/usr/bin/time -lp /opt/local/bin/perl5.28 Desktop/leaktest.pl > /dev/null
802365440  maximum resident set size

/usr/bin/time -lp /opt/local/bin/perl5.30 Desktop/leaktest.pl > /dev/null
657444864  maximum resident set size

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 25 Oktober 2019, 11:56:11
Zitat von: rudolfkoenig am 25 Oktober 2019, 11:02:41
Hab das commit angeschaut, braeuchte aber laenger, um sinnvoll beitragen zu koennen. Vermutlich fehlt "nur" ein SvREFCNT_dec_NN :)
Durch Diff-Lesen bin ich auf dem modifier /a gestossen, damit tritt das Problem unter 5.30 _nicht_ auf.
Das waere mAn eine Loesung mit weniger Seiteneffekten.

This contradicts the comment of dur-randir from the linked perl-issue site.

Kann ich für Perl 5.28 ebenfalls bestätigen. Vermutlich funktionieren beide Lösungen aus ähnlichen Gründen.

Kann man das in HTTPMOD mit dem modifier implementieren? Das wäre wirklich nur eine ganz kleine Änderung an 3-4 Stellen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: herrmannj am 25 Oktober 2019, 12:21:57
5.24 ist scheinbar auch betroffen, siehe https://stackoverflow.com/questions/43288921/perl-program-leaking-memory-when-compiling-regex

Eventuell distribution/Patchlevel abhängig. Ich meine mich zu erinnern das ich das unter 5.24 auch das erste mal gesehen habe
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 25 Oktober 2019, 12:34:59
Ich gehe von unterschiedlichen Regexp-Bugs aus, bei 5.24 war mW nur(?) DOIF betroffen.
regcomp.c ist ca 1MB gross, da ist Platz fuer mehrere Bugs.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 25 Oktober 2019, 15:52:32
Hier kommt/kam ja mächtig Schwung rein :)

Schon nachdem Rudi etwas bzgl. HTTPMOD bzw. DNS-Lookup (war es glaub ich) gefunden hatte hab ich mal meine Testsysteme einem Update unterzogen...
...und was soll ich sagen: toll! :)

Also ich habe ein Testsystem mit Stretch und eins mit Buster und bei beiden am 23.10. ein fhem Update durchgeführt...

Die beiden Systeme sind meine "Modul-Testsysteme", d.h. bevor ich ein Modul auf mein Hauptsystem loslasse wird es darauf getestet.

Bislang war eben das echodevice-Modul mein "Problemfall": Modul defined -> Speicher steigt / Modul "gelöscht" -> Speicher "normal"...

Das Buster-System war schon immer etwas besser (siehe Screenshot) aber trotzdem merklich...
...auf dem Stretch System konnte ich das Modul gar nicht wirklich nutzen, alle paar Tage Neustart (siehe Screenshot).

Nach dem Update sind beide Systeme ohne Speicheranstieg :)

Auf meinem Hauptsystem habe ich einige HTTPMOD (u.a. auch TV aber sehr seltener Update) und eigentlich kaum Anstieg, d.h. das System läuft mehr als einen Monat ohne Problem (ja schon leichter Speicheranstieg aber damit kann/konnte ich leben)...
Meistens mache ich vorher aus anderen Gründen einen Neustart ;)

EDIT: habe nun mein Hauptsystem auch mal einem fhem Update unterzogen, mal sehen... (wobei ja wie geschrieben: dort kein [großes] Problem)

Stretch:
PI 3B+, perl: v5.24.1, dnsServer gesetzt

Buster:
PI 3B+, perl: v5.28.1, dnsServer gesetzt

Somit kann ich sogar das echodevice-Modul auf meinem Hauptsystem nutzen, ohne dieses (noch auf Stretch) updaten (also auf Buster) zu müssen...

Das "leak" Script leakt bei mir unter Stretch auch...
...unter Buster noch nicht getestet, wollte meinen "echodevice-Test" nicht "beeinflussen/stören"...

Gruß und danke, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: StefanStrobel am 25 Oktober 2019, 16:57:32
Wenn ein /a Modifier schon ausreicht um das Problem zu lösen, dann könnte man den ja auf die Schnelle auch einfach per Attribut readingRegOpt einstellen.
Ich werde mir aber auf jeden Fall ansehen, ob es in HTTPMOD nicht sinnvoller ist, generell die Regexes direkt in der AttrFn zu compilieren.

Gruss
   Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 25 Oktober 2019, 22:31:57
Zitat von: herrmannj am 25 Oktober 2019, 12:21:57
5.24 ist scheinbar auch betroffen, siehe https://stackoverflow.com/questions/43288921/perl-program-leaking-memory-when-compiling-regex

Eventuell distribution/Patchlevel abhängig. Ich meine mich zu erinnern das ich das unter 5.24 auch das erste mal gesehen habe

Unter Perl 5.28 passiert bei diesem Beispiel gar nix bei mir.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Hardlife am 26 Oktober 2019, 20:16:35
Zitat von: mumpitzstuff am 24 Oktober 2019, 01:35:48
Im Anhang befindet sich die von mir veränderte HTTPMOD Version (entspricht ansonsten der aktuellsten Version). Bei mir ist damit der steigende Speicherverbrauch komplett weg, wie man auf dem anderen Bild sehen kann.

Getestet mit dem von Hardlife hier geposteten TV_Programme Device:
https://forum.fhem.de/index.php/topic,84372.msg981483.html#msg981483 (https://forum.fhem.de/index.php/topic,84372.msg981483.html#msg981483)

Ich würde mich freuen, wenn Hardlife und parabacus das mal testen könnten.

Hi Com,

nach etwas Stress im Reallife  ::) bin ich nun wieder an der Sache dran.

Ich habe das modifizierte Modul von "mumpitzstuff" getestet und kann bestätigen, daß sich damit alle Probleme in Luft aufgelöst haben.
FHEM läuft performat und der exorbitante MEM-Zuwachs ist Geschichte.

Switche ich zurück zum originalen FHEM-Modul, klettert der RAM-Verbrauch wieder flugs in ungeahnte Höhen...  :)


Liebe Grüße,
Hardlife
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: StefanStrobel am 27 Oktober 2019, 09:49:13
Eine neue Version von HTTPMOD ist auf dem Weg.
Ich teste gerade selbst noch ein paar Optionen.
Prinzipiell möchte ich aber den Weg zur Umgehung des Perl-Bugs (und eventuelle Seiteneffekte) nicht im Modul fest vorgeben, sondern dem Anwender die Wahl lassen.
Entweder die Option a für Regexes (per Attribut readingRegOpt für alle Regexes), Decode der Regexes mit einem zu definierenden Encoding oder Vorcompilieren der Regexes bei der ersten Verarbeitung der Attribute.

Gruss
    Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: herrmannj am 27 Oktober 2019, 10:51:22
Ich würde mir wünschen dass dir Bug automatisch kompensiert wird. Vielleicht gekoppelt an die Perl Version. Der Anwender könnte das doch bei Seiteneffekten per Attribut deaktivieren. Viele Anwender werden sich erst damit beschäftigen wenn sie betroffen sind und nachdem sie den Zusammenhang erkennen und verstehen
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: StefanStrobel am 27 Oktober 2019, 13:37:59
Hallo,

Da ist die Frage, was am wenigsten Seiteneffekte verursacht.
Vermutlich wenn man die Regexes vorab compiliert. Optimistisch betrachtet würde das sogar die Performance verbessern.
Beim Decode kommt es vermutlich darauf an wie kreativ die Anwender ihre Regexes formuliert haben.
Ich würde ungern einen Perl-Bug umschiffen und dabei noch mehr Leute verärgern, deren Konfiguration seither gut funktioniert hat. Anderseits würde Deine Idee, das von der Perl-Version abhängig zu machen den Kreis der potentiell betroffenen weiter eingrenzen.
Ich tendiere bisher zu qr//, allerdings ist das der vergleichsweise größte Eingriff ins Modul.

Gruss
    Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: parabacus am 27 Oktober 2019, 22:08:09
Zitat von: mumpitzstuff am 24 Oktober 2019, 01:35:48
Im Anhang befindet sich die von mir veränderte HTTPMOD Version (entspricht ansonsten der aktuellsten Version). Bei mir ist damit der steigende Speicherverbrauch komplett weg, wie man auf dem anderen Bild sehen kann.

Getestet mit dem von Hardlife hier geposteten TV_Programme Device:
https://forum.fhem.de/index.php/topic,84372.msg981483.html#msg981483 (https://forum.fhem.de/index.php/topic,84372.msg981483.html#msg981483)

Ich würde mich freuen, wenn Hardlife und parabacus das mal testen könnten.
Sorry - war ein paar Tage unterwegs und offline... - hab's eben eingebaut und lass es laufen. Mal sehen was passiert...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: parabacus am 28 Oktober 2019, 21:04:59
Wie es scheint, lässt sich das Speicherloch bei mir mit modifiziertem HTTPMOD-Modul nicht beheben. Ich stelle seit gestern einen leichten Anstieg fest.
Ich lass es mal noch ein paar Tage laufen. Bisher hat's so nach 4..5 Tagen zugeschlagen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 28 Oktober 2019, 22:16:16
Welche Perl Version hast du?

PS: Ich habe mal deine regular Expressions ins leak Script kopiert und konnte dabei keinen Speicheranstieg feststellen mit Perl 5.28. Somit ist es bei dir irgend etwas anderes oder tritt nur mit deiner Perl Version auf.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: parabacus am 29 Oktober 2019, 08:17:18
Bei läuft das auf einem RasPi 3 mit Stretch und Perl 5.24.1.

Gefühlt war der Anstieg aber geringer, wobei ich das erst mal ein paar Tage unverändert laufen lassen müsste.
Derzeit baue ich aber bisschen was um und starte daher mehrfach.
Trotzdem danke für deine Bemühungen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 29 Oktober 2019, 09:12:53
Guten Morgen,

Woran kann das den liegen das bei jeden Fhem Backup ca 300mb Speicher verloren gehen?

Gruß

Thorsten
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CoolTux am 29 Oktober 2019, 10:04:37
Während oder auch noch danach?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: jailbreaker07 am 29 Oktober 2019, 10:59:14
Hey, ansonsten so 200 Mb pro Tag. Habe auch das geänderte httpmod Modul im Einsatz.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: StefanStrobel am 29 Oktober 2019, 11:46:37
Hallo,

ich habe auch auf meinem Raspi mit Stretch, Perl 5.24.1 und dem TV-Programme-Beispiel in den letzten 6 Tagen noch einen Anstieg von ca. 1MB je Tag.
Jetzt teste ich ob das mit vorcompilierten Regexes besser wird oder ob die Ursache noch an anderer Stelle ist.

Gruss
    Stefan
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 29 Oktober 2019, 12:55:14
Es gab ein Bespiel bei dem in den Rexexp </a> drin stand. Das führt zumindest zu Warnings, die ebenfalls zu Speicher Leaks führen können. Schau mal nach und ersetze gegebenenfalls </a> durch <\/a>. 
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 26 November 2019, 17:37:23
Was hat sich zwischen dem 20. und 23. November geändert, dass der Speicheranstieg plötzlich nicht mehr erkennbar ist?
Ich kann jetzt den täglichen Neustart entfernen und wäre noch einige Tage das System beobachten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 26 November 2019, 18:08:24
Einiges: https://svn.fhem.de/trac/log
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Burny4600 am 27 November 2019, 17:43:20
Das war einiges was sich geändert hat.
Jedenfalls sieht es jetzt sehr gut aus. Kein Speicheranstieg ist bemerkbar.
Ich habe die Perl Version nie geändert, sondern nur die FHEM Updates von Zeit zu Zeit durchgeführt.
Damit dürfte das Problem jetzt beseitigt sein.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Gunther am 09 Dezember 2019, 14:40:39
Ich hoffe, dass ich hier richtig bin. Ich sehe den Wald vor lauter Bäumen nicht.

Bisher dachte ich, dass das Unifi-Modul mein FHEM einfriert. Zumindest die Ausführungszeiten deuten nicht darauf hin.

Folgende Fehlermeldung taucht immer wieder in meinem Log auf:
BlockingInformParent (BlockingStart): Can't connect to localhost:7072: IO::Socket::INET: connect: Connection timed out
Was kann das sein und wie gehe ich damit um?

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 09 Dezember 2019, 14:54:39
Dieses Problem hat vmtl. nichts mit dem hier behandelten (Speicherloch in FHEM) zu tun, sondern wird durch eine Blockierung des "eigentlichen" FHEM Prozesses verursacht (aka FHEM hängt). Ich wuerde das Problem mit einem "attr global verbose 5" log lokalisieren, andere verwenden das apptime Befehl in FHEM.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Gunther am 09 Dezember 2019, 15:21:20
danke, habe global mal auf verbose 5 gesetzt. Mal sehen
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: xenos1984 am 27 Dezember 2019, 15:14:54
Schon eine Weile habe ich mich über den Speicherverbrauch von FHEM gewundert, und jetzt habe ich zufälligerweise mal diesen Thread gefunden. Vielleicht lässt sich mein Problem auf diesem Wege auch lösen.

Die Symptomatik: Der Speicherverbrauch wächst bei mir innerhalb von einigen Tagen / 1-2 Wochen von anfänglich unter 70MB in den GB-Bereich.

Das System:
Ubuntu Bionic (18.04.3 LTS)
Perl v5.26.1
FHEM neueste SVN 20827
libxml-parser-perl                    2.44-2build3
libxml-twig-perl                      1:3.50-1
libxml-xpath-perl                     1.42-1
libxml-xpathengine-perl               0.14-1


Im Verdacht habe ich HTTPMOD und XML / XPath - davon habe ich einige Geräte definiert. Ich habe einmal testweise das mit der höchsten Abfragerate (5 Sekunden, Ziel der Abfrage ist ein Mediaplayer, zwecks Anzeige von Status und "Now Playing") auf disable = 1 gesetzt, um zu testen, ob es dann immer noch so schnell ansteigt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: xenos1984 am 28 Dezember 2019, 07:53:22
Nun habe ich einige Testergebnisse:
Hier ist ein list aller Geräte, insbesondere das erste scheint zu einem schnellen Anstieg zu führen:
https://gist.github.com/xenos1984/dd5245db4804c1b4cd48fb0495179855
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 28 Dezember 2019, 08:02:29
Ist dein fhem aktuell!?

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: xenos1984 am 28 Dezember 2019, 09:01:20
Ja, also vom Stand gestern. Ich habe extra vor dem Test noch mal ein Update durchgeführt.
System Info
ConfigType: configFile
SVN rev: 20831
OS: linux
Perl: 5.26.1
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 28 Dezember 2019, 09:32:12
Ok, wollte ich nur sicherstellen.
Wurde ja einiges gemacht und seither ist bei mir der Speicherverbrauch (inkl. echodevice-Modul und HTTPMODs) wieder ok.

Zwar steigend aber im Rahmen: Laufzeit (weit) über 1 Monat auf einem PI mit 1GB...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: xenos1984 am 28 Dezember 2019, 10:07:40
Ja, ich habe das Thema einigermaßen verfolgt (bzw. den Verlauf hier zum Teil gelesen) und festgestellt, dass Speicherlecks scheinbar ein "altbekanntes Problem" sind, auch wenn wohl schon einige davon behoben wurden. Wenn auch vermutlich nicht alle...

Letztlich habe ich auch vor, FHEM auf einem RPi laufen zu lassen - gerade deshalb ist FHEM auch mein Favorit, weil es doch relativ wenige Ressourcen braucht. Zum Testen habe ich es erst einmal auf meinem Heimserver installiert - der hat 16GB, deshalb ist mir der Speicherverbrauch zuerst gar nicht aufgefallen, bis ich zufällig mal ein htop habe laufen lassen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 28 Dezember 2019, 11:30:22
@xenos1984: kannst Du bitte den Inhalt von http://deimos:8080/requests/status.xml (http://deimos:8080/requests/status.xml) bereitstellen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: xenos1984 am 28 Dezember 2019, 13:09:22
@rudolfkoenig: Hier sind gleich zwei Versionen davon, einmal während nichts abgespielt wird:

https://gist.github.com/xenos1984/e5c9195595aa90ed7017ae4d9ab9c499

Und hier während der Wiedergabe:

https://gist.github.com/xenos1984/0d248e2c91ead85c51b0e2f43a560361

Den Whitespace habe ich bewusst so gelassen, wie er vom Server kommt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 28 Dezember 2019, 14:05:04
Ich wuerde gerne das Problem eingrenzen:

Ob das Abholen der Daten ein Problem ist, koennte man so testen:fhem> { for my $i1 (0...1000) { HttpUtils_NonblockingGet({ url=>"http://deimos:8080/requests/status.xml", callback=>sub(){ } }) } }
Dabei vorher/nachher Speicherverbrauch pruefen.

Ob das Parsen/Weiterverarbeiten ein Problem ist, koennte man so testen:
- das Ergebnis des Requests erreichbar fuer FHEM in eine Datei ablegen (z.Bsp. /tmp/deimos_on.xml)
- folgende Funktion in 99_myUtils.pm (oder vgl.) einfuegen:sub
HTTPMOD_testFile($$)
{
  my ($hash, $fn) = @_;
  my $data = "";
  open(FH, $fn) || return "Can't open $fn: $!";
  $data = join("", <FH>);
  close(FH);
  $hash->{REQUEST}{type} = "update";
  HTTPMOD_Read($hash, undef, $data);
}
- erst testen:{ HTTPMOD_testFile($defs{deimos_vlc}, "/tmp/deimos_on.xml") }- wenn keine Fehlermeldung kommt, dann:
fhem> { for my $i1 (0..1000) { HTTPMOD_testFile($defs{deimos_vlc}, "/tmp/deimos_on.xml") } }

Auch in diesem Fall vorher/nachher pruefen, ob der Speicherverbrauch waechst.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: xenos1984 am 28 Dezember 2019, 14:52:25
@rudolfkoenig: Das scheint schon mal gut zu laufen. Ergebnisse:

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 28 Dezember 2019, 18:28:18
ZitatParsen der Daten: Das scheint der Knackpunkt zu sein. Hier steigt beim Aufruf der Schleife der Speicher reproduzierbar jedes Mal um ca. 25MB.
Kannst Du bitte dieses Experiment auch mit dem folgenden "leeren" fhem.cfg wiederholen:
attr global logfile -
attr global modpath .
define WEB FHEMWEB 8084 global
define deimos_vlc HTTPMOD http://deimos:8080/requests/status.xml 3600
attr deimos_vlc disable 1
[...alle anderen deimos_vlc Attribute]
Ich kann bei mir damit kein Speicherverbrauch feststellen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: xenos1984 am 28 Dezember 2019, 19:08:27
Hm... Das ist seltsam / interessant. Bei mir passiert auch mit der "leeren" fhem.cfg genau das gleiche. Direkt nach dem Start braucht FHEM ca. 33MB. Wenn ich
{ HTTPMOD_testFile($defs{deimos_vlc}, "/tmp/deimos_on.xml") }
ausführe, kommen knapp 30MB dazu, und das reproduzierbar jedes Mal, wenn ich den Befehl wiederhole.

Vielleicht ein Unterschied in der Perl-Version, oder einem der XML-Parser Module?

Perl v5.26.1
libxml-parser-perl                    2.44-2build3
libxml-twig-perl                      1:3.50-1
libxml-xpath-perl                     1.42-1
libxml-xpathengine-perl               0.14-1
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 28 Dezember 2019, 19:53:12
Ich habe kein Problem mit perl 5.18, 5.24 und 5.30.

Die Versionen der Perl-Module fuer 5.18 kann ich nicht mehr sagen, fuer die beiden anderen ist es XML::XPath 1.44, und XML::Parser 2.46 (da gerade eben installiert).
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: xenos1984 am 28 Dezember 2019, 21:59:12
Scheint, als hätten wir den Schuldigen gefunden. Nach einem Update von XML::XPath von 1.42 auf 1.44 verläuft der Test (1000 Mal parsen) ohne Speicherzuwachs. Im Moment lasse ich wieder den "Normalbetrieb" laufen, aber bisher habe ich auch hier nur einen geringen Speicheranstieg seit Start von FHEM, und seitdem bleibt er konstant (kein weiterer Anstieg alle 5 Sekunden wie vorher).

Danke für die Hilfe! :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: shamal2008 am 21 Januar 2020, 22:01:53
Hallo zusammen,

da ich seit einigen Tagen auch das Problem hatte und meine Fehler mal mit Abschalten des gesamten Presence-Dienstes einigermaßen geringer (=bessere Laufzeit bis Absturz) geworden sind, hätte ich folgende Frage:

- Wie habt ihr Perl samt den Zusatzmodulen auf diesen Stand gebracht? - mit apt-get update und upgrade erklärt mein Raspi, er ist auf aktuellstem Stand und lt. perl --version bin ich auf 5.24.1

Wie komme ich zu den Ständen, speziell x-path-perl (das scheint ja die Wurzel des Übels zu sein):
Perl v5.26.1
libxml-parser-perl                    2.44-2build3
libxml-twig-perl                      1:3.50-1
libxml-xpath-perl                     1.42-1
libxml-xpathengine-perl               0.14-1


Danke,
shamal
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KölnSolar am 21 Januar 2020, 22:56:14
Spekulation: veraltetes Raspbian und nicht buster ?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 22 Januar 2020, 01:39:53
cpan install XML::XPath

Versuchs mal damit. Mit apt bekommst du immer nur alte Bibliotheken.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: xenos1984 am 22 Januar 2020, 07:32:22
Zitat von: shamal2008 am 21 Januar 2020, 22:01:53Wie habt ihr Perl samt den Zusatzmodulen auf diesen Stand gebracht?
Unter Ubuntu hatte ich geschaut, ob es von den jeweiligen Bibliotheken aktuellere deb-Pakete gibt (aus einer neueren Ubuntu-Version), die mit den bisher installierten (Ubuntu Bionic) kompatibel sind. Im konkreten Fall brauchte ich nur eine aktuellere Version von libxml-xpath-perl.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: shamal2008 am 22 Januar 2020, 16:24:53
Zitat von: mumpitzstuff am 22 Januar 2020, 01:39:53
cpan install XML::XPath

Versuchs mal damit. Mit apt bekommst du immer nur alte Bibliotheken.

Danke mumpitzstuff für den sachdienlichen Hinweis. Die Lib ist jetzt 1.44, damit sollten die Presence Module über Ping ja auch wieder gehen, oder habe ich hier den Faden völlig in einen Knäuel verwoben?

lg Shamal

@KölnSolar: Mann kann es auch als veraltetes Raspian bezeichnen... das letzte Update mit apt-get (angeblich ja die empfohlene Methode) wurde unmittelbar vor dem FHEM Update am 19.1. gemacht...
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch


Aber der Raspi4 ist gerade heute vom Regenwald zu mir geflattert...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KölnSolar am 22 Januar 2020, 17:44:10
Aktuell ist halt buster.  ;) Aber stretch ist noch OK.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 22 Januar 2020, 17:55:09
Zitat von: shamal2008 am 22 Januar 2020, 16:24:53
Aber der Raspi4 ist gerade heute vom Regenwald zu mir geflattert...

Zitat von: KölnSolar am 22 Januar 2020, 17:44:10
Aktuell ist halt buster.  ;) Aber stretch ist noch OK.

Nicht mehr, wenn der PI4 da ist ;)

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: osid-timo am 04 Februar 2020, 20:35:09
Hallo,
die Euphorie kann ich leider noch nicht teilen, bei mir ist immernoch ein Speicherverbraucher aktiv
es läuft buster mit Perl 5.28.1
XML::XPath is up to date (1.44) und auch FHEM wird wöchentlich aktualisiert.

ohne den nächtlichen FHEM Restart bei einer Speicherauslastung >24% ist FHEM nicht mehr erreichbar.

wer hat noch eine Idee wie ich den Verschwender finden kann.

Gruß osid-timo
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 05 Februar 2020, 00:03:26
Konfiguration sichern und dann immer 5 Geräte löschen und beobachten (ohne Save zu drücken). Wenn der Verbrauch weiter steigt , dann mach ein shutdown restart (dann sind die gelöschten Geräte wieder da) und lösche die nächsten 5. so kannst du dich erst mal ran tasten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: e_brandt am 19 Februar 2020, 22:01:45
Ich hatte jetzt das gleiche problem, keine Ahnung was ich geändert habe das es dazu kam. Ich habe 2 identische SD Karten, eine ging nun auf einmal nicht mehr.
Durch besagten Fehler lief der Raspi nur noch ca 4 Stunden. Nun habe ich mir gedacht ich kopiere die Aktuelle Fhem.cfg mal auf die andere Karte und alles läuft wieder.
Das ging nicht...nun hatte ich auf beiden  Karten den gleichen Fehler.  Ich habe erstmal das eine System auf aktuellen Stand gebracht (Fhem auf 6.0 und Raspian auf Buster) auf einer Karte, das hat auch nichts gebracht. Jetzt haben wir mal die Demo cfg genommen.Damit war erstmal ruhe. Jetzt haben wir angefangen nach und nach die  Geräte aus der Fhem.cfg zu löschen. Nach der Hälfte war das leck auch gefunden, habe ich gedacht....

Wir haben dann nach und nach wieder alles rein kopiert, und komischer weise geht es jetzt ohne einen wirklichen Fehler gefunden zu haben. Das gleiche Spiel musste ich auf der anderen Karte auch machen. Ich konnte nicht einfach die Fhem.cfg von dem einen funktionierenden Raspi auf den anderen kopieren.

Geht das grundsätzlich nicht? Ich habe leider nicht so viel Ahnung von Fhem / Linux. Ich würde aber gern wissen was ich falsch gemacht habe?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: e_brandt am 23 Februar 2020, 19:15:45
Habe gestern bei meiner 2 Karte ein Update auf Buster gemacht und heute morgen war fhem wieder fest und der Speicher voll. Ich habe dann die fhem.cfg gelöscht und mit der Demo ersetzt. Danach in Teilen eingefügt bis ich alles wieder drin hatte und es läuft wieder.

Was soll das sein?

Gesendet von meinem MHA-L29 mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 28 Februar 2020, 12:47:35
Zitat von: yamaha1983 am 21 November 2018, 08:50:33
Hallo,

ich hatte bis gestern das gleiche Problem. Mein Perl war 5.24.1 und per Grafana habe ich meinen Speicherverbrauch mitgeloggt. Es war wie hier mehrfach schon beschrieben. Der Arbeitsspeicher lief voll, forken ging an einem punkt nicht mehr und selbst FHEM hat irgendwann die grätsche gemacht.

Über Perlbrew habe ich dann "mühselig" die Perlversion 5.20.3 neben meinem oben genannten Systemperl kompiliert.
Naja, ein direktes starten mit der alten Version war dann auch nicht möglich, weil dann erstmal etliche Module fehlten. Diese konnten per CPAN auch nachkompiliert werden. Nach gefühlten 10 Umstellversuchen habe ich jetzt alle Module beisammen :).
Und ja, was soll ich sagen. Der Speicher ist seitdem absolut stabil bei 100MB. Im Anhang noch die Graphen.

Also probiert es ruhig aus. Klar ist es etwas Aufwand, aber mit perlbrew kann man nicht viel falsch machen.
Vielleicht noch als Tipp. Richtet perlbrew so ein, dass jeder Benutzer von den kompilierten Perlversionen profitieren kann. Ansonsten muss jeder Benutzer für sich alles kompilieren, wenn er etwas auf dem System davon nutzen möchte. Kostet Speicherplatz und vor allem Nerven und Zeit.

Dazu:
Zuerst Backup ;)
Dann System auf den aktuellen Stand bringen:
per root folgendes in die Shell:
apt-get update
apt-get upgrade
Entwicklertools installieren:
apt-get install build-essentials
Nun Perlbrew installieren:
export PERLBREW_ROOT=/opt/perlbrew
mkdir /opt/perlbrew
cd /opt/perlbrew
curl -L https://install.perlbrew.pl | bash

Nach der schnellen Installation kann man diese prüfen mit
perlbrew init

Diese gibt dann nochmal den freundlichen hinweis, dass man in der .bashrc folgenden Eintrag hinzufügen muss:
Öffnen der Bashrc: vi ~/.bashrc
Einfügen der Zeile am Ende: source /opt/perlbrew/etc/bashrc

Zum Testen der Wirksamkeit einfach nochmal ausloggen und per SSH neu als Root einloggen. Dann sollte der befehl perlbrew per Autovervollständigen (TAB Taste) zur verfügung stehen und "perlbrew init" quittiert mit einem "perlbrew root (/opt/perlbrew)" is installed.

Nochmal als Hinweis. Wenn man nun später etwas an den anderen Perlversionen ändern möchte, geht das nur über den root benutzer, weil er jetzt der Besitzer von /opt/perlbrew ist. Alle weiteren Nutzer wie pi, oder fhem brauchen keine Besitzrechte an /opt/perlbrew um es zu nutzen.

Damit jetzt die anderen Nutzer wie pi und fhem auch perlbrew nutzen können müssen folgende zwei Zeilen hinzugefügt werden.
Als pi Benutzer einloggen: vi ~/.profile
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc

Bei meinem FHEM-Installation (unter /opt/fhem) mit dem Benutzer fhem gibt es leider keine .bashrc und diese wird auch nicht verwendet, wenn man diese erstellt. Aber die Datei .profile wird ausgewertet.
Daher einloggen als Benutzer fhem: vi ~/.profile
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc

Jetzt sind die Benutzer dafür eingerichtet perlbrew zu benutzen. Das kann ebenfalls mit einem Neueinloggen in die Shell mit dem Benutzer geprüft werden. Hier wieder perlbrew init ausführen.

Nun geht es an das erstellen der alten Perlversion 5.20.3. Einloggen als root!
Ersteinmal kann geprüft werden, was perlbrew alles an perlversionen kompilieren kann. Dazu der Befehl
perlbrew available. Hier sieht man auch direkt, das wesentlich neuere Versionen verfügbar sind, als mit raspbian ausgeliefert werden. Ob diese funktionieren, weiß ich nicht. Daher bleiben wir erstmal bei 5.20.3. Alles weitere könnt ihr ja später selbst probieren :).

Damit das Perl nun kompiliert und für perlbrew verfügbar wird, muss man nun den Befehl
perlbrew install perl-5.20.3
absetzen. Perlbrew läd sich selbstständig die sourcen für perl runter und fängt an diese zu kompilieren. Das dauert jetzt eine ganze weile und die Shell darf nicht geschlossen werden, da sonst der Prozess beendet wird. Daher empfiehlt es sich eigentlich, den Prozess mit nohup zu starten:
nohup perlbrew install perl-5.20.3
Habt ihr aber schon gestartet und wollt diesen Prozess nachträglich von der session abkoppeln gibt es noch einen Trick:
Nach der Eingabe von perlbrew install perl-5.20.3 kommt die shell nicht zum prompt zurück.
Drückt hier einfach STRG+Z, dann steht in der Shell "Angehalten". anschließend gebt ihr "bg" ein. Nun arbeitet der Prozess im Hintergrund weiter, ist aber noch mit der Shell verheiratet und würde beim schließen mitsterben. Daher muss der Prozess noch abgehangen werden. Das geht mit dem Befehl disown %1 (wenn ihr keine weiteren Hintergrundprozesse durch BG erzeugt habt, ist es die 1, ansonsten die job id prüfen).

Während des Kompilierens wird sämtlicher output nach /opt/perlbrew/build.perl-5.20.3.log geschrieben. Ist perlbrew fertig wird am Ende des Logfiles die Meldung "##### Brew Finished #####" geschrieben.
Prüft dann nach, ob dem so ist mit dem Befehl:
perlbrew list
Hier sollte nun die perlversion zu sehen sein.
gebt ihr nun ein perl -v ein, seht ihr dass noch die alte System Perlversion zur Verfügung steht.
Der temporäre Wechsel erfolgt über den Befehl: perlbrew use perl-5.20.3
Jetzt nochmal perl -v eingeben und man sieht dann die Version 5.20.3 in der Ausgabe.

Jetzt kommt der etwas unangenehme Teil. Jetzt benötigt ihr noch sämtliche Module. FHEM ist ja nett und schreibt alles brav ins Log, wenn ein Modul fehlt. Hier kann in der FHEM Log nach @INC gesucht werden und ihr bekommt dann die entsprechenden Hinweise. Um es auch aber etwas zu erleichtern, habe ich die Module die ich brauchte hier mal zusammengetragen:

JSON
Device::SerialPort
URI::Escape
RPC::XML
IO::Socket::SSL
Crypt::CBC
Switch
Net::WebSocket::Server::Connection
Crypt::Cipher::AES
Crypt::Rijndael_PP
LWP::Simple
MIME::Base64
SOAP::Lite

Wenn ihr nun diese Module installiert haben wollt, dann geht das einfach über das cpan tool.
Bitte vorher mit perlbrew use perl-5.20.3 in das perlbrew perl wechseln und dann einfach
cpan JSON
...
cpan SOAP::Lite
eingeben.
Oder einfach alles in eine Zeile :)
cpan JSON Device::SerialPort URI::Escape RPC::XML IO::Socket::SSL Crypt::CBC Switch Net::WebSocket::Server::Connection Crypt::Cipher::AES Crypt::Rijndael_PP LWP::Simple MIME::Base64 SOAP::Lite

Kleiner Nachtrag hier: Für das SSL Modul muss zwingend noch vorher das Paket libssl-dev installiert sein, da er sonst beim kompilieren abbricht. Also per root:
aptitude install libssl-dev

Für dblog benötigt man noch eine weitere lib:
aptitude install libmariadb-dev

Diese dann so als root mit aktiven perl-5.20.3 installieren:
cpan -T DBD::mysql DBD::MariaDB

Zweite Methode hat den Nachteil, dass man nicht sieht, wenn etwas schiefgeht. Manche Module erfordern auch eine Eingabe (die aber immer mit einem enter quittiert werden kann). Hier nutze ich persönlich gerne das Programm "screen". Damit kann man ein virtuelles Terminal erzeugen und sich jederzeit wieder darauf connecten.


Nutzt ihr auch MySQL/Maria DB müsst ihr mit root noch folgendes Paket installieren:
aptitude install libmariadb-dev
Dann lassen sich auch folgende Perlmodule erfolgreich kompilieren:
cpan DBD::mysql DBD::MariaDB

Wenn ihr es bis hier geschafft habt, dann habt ihr das Schlimmste hinter euch.
Loggt euch nun wieder als fhem ein. Killt euren FHEM Prozess.
perlbrew use perl-5.20.3
perl fhem.pl fhem.cfg (wenn nicht configDB)

Schaut jetzt unbedingt in euer FHEM Log. Sollten euch Module fehlen, wird FHEM diese euch klar benennen. Dann einfach per CPAN nachkompilieren!

Um generell zu prüfen, ob FHEM nun auch mit 5.20 läuft, einfach oben auf der FHEM Seite in das Feld folgendes eingeben;
{`perl -v`}
jetzt sollte die alte Version 5.20.3 zu sehen sein.

Hinweis: perlbrew use setzt die perlversion nur temporär für die aktuelle Session (und deren Kinder natürlich). Bei einem abmelden und neuem anmelden ist die System perlversion 5.24 wieder aktiv.
Ich habe daher in meinem Startskript von FHEM (bei mir /etc/init.d/fhem) folgendes oben nach dem Header hinzugefügt:
export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3

Damit startet das FHEM dann immer brav mit der alten Version.

Es ist auch möglich perlbrew permanent als Standardperl für alle Sessions des Benutzers zu setzen. Das geht über
perlbrew switch perl-5.20.3

Das mag ich persönlich aber nicht, weil ich immer selbst und selektiv entscheiden möchte, was ich verwende.

Habt ihr mit perl use eine Version in Benutzung erkennt man das auch, wenn man perlbrew list eingibt. Dann ist dies mit einem Stern gekennzeichnet. Wollt ihr in dieser Session wieder zurück zum Systemperl ohne aus und einloggen, dann geht es über perlbrew off.

Ich persönlich finde perlbrew ganz cool und gibt einem mehr Freiheiten beim rumprobieren mit den Perlversionen. Daher denke ich das sich der Aufwand lohnt. Das Speicherproblem ist damit erstmal Geschichte.

Hallo Zusammen.

Habe seit dem bei mir das Problem vor ~1,5 Jahren Auftrat die Perl Version 5.20.3 laufen.
Mit 5.24 hatte ich genau das gleiche Speicherloch wie jeder hier.
Bin noch auf rapsbian stretch und erwäge ein Update auf buster + perl Update,
die Perl Speicherloch Geschichte hält mich aber davon ab...

Habe die letzten Seiten gelesen und gesehen dass 5.28 das Problem nicht mehr haben sollte bzw. ein modifiziertes HTTPMOD im Umlauf ist.

Wie ist da jetzt der Stand der Dinge?

Ist das regex Thema behoben? kann ich wieder auf eine neuere Perl Version?
Oder muss auch die distro upgdated werden?

Danke
pOpY


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 28 Februar 2020, 14:15:28
Es wird dir niemand sagen können, ob du nach einem Upgrade Probleme haben wirst oder nicht. Ich würde dir deshalb raten, eine Kopie deiner SD Karte zu erstellen, dann das Upgrade durchzuführen und bei Problemen zurück auf die Kopie zu gehen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 29 Februar 2020, 17:49:56
Sorry, falsch formuliert  ::)
Hat jemand aktuelles fhem mit buster und perl 5.28 ohne dem RAM Thema am laufen und hatte mit der gleichen Konfiguration, stretch und perl 5.24 den memory leak?

Danke
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 29 Februar 2020, 18:08:50
Stretch und "altes" fhem: Speicherproblem. V.a. Testsystem mit echodevice-Modul.
Auf meinem Hauptsystem auch (bewusst noch ohne echdevice-Modul) aber nicht so schlimm...
fhem aktuell (mit "Fix" schon vor einiger Zeit bzgl. Regex glaub ich) und Stretch schon deutliche Besserung (inkl. echodevice-Modul mittlerweile) und mit Buster ebenfalls gut, ob (deutlich) besser kann ich jetzt nicht sagen...

Aber wie du dem Thread (und anderen) entnehmen kannst, hängt es wohl von vielen Faktoren ab...

Andere hatten z.B. keinerlei Probleme mit dem echodevice-Modul und Stretch...

Daher: wird auch das nicht wirklich beantwortet werden können...

Aber: irgendwann (demnächst) steht (bzw. sollte, meine Meinung) eh ein Umstieg auf Buster an...
...warum nicht jetzt!?

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 29 Februar 2020, 18:27:11
Danke Joachim.
Beim stretch mit perl 5.20.3 ist es eine gerade linie bei mir,
Sprich kein Memory leak.
Wie schaut das RAM Diagramm bei dir bei Buster (perl 5.28) über paar Stunden bzw. Tage aus?

Werde den Schritt auf buster wagen...

Danke
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 29 Februar 2020, 18:47:58
Über Stunden ist nichts zu erkennen, über einige Tage schon aber fhem läuft problemlos über mind. 1 Monat (und verm. [deutlich] länger)...

Meist mach ich aber vorher eh "irgendwas" ("programmieren", update, etc.) und dann ist es ja wieder gut...

EDIT: aber auf alle Fälle nicht schlimmer als zuvor mit Stretch...

EDIT2: wenn keine Speicherprobleme da sind, ist der Umstieg doch noch nicht "zwingend"!? Ich dachte du hast Probleme...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 01 März 2020, 13:05:33
Zitat von: MadMax-FHEM am 29 Februar 2020, 18:47:58
Über Stunden ist nichts zu erkennen, über einige Tage schon aber fhem läuft problemlos über mind. 1 Monat (und verm. [deutlich] länger)...

Meist mach ich aber vorher eh "irgendwas" ("programmieren", update, etc.) und dann ist es ja wieder gut...

EDIT: aber auf alle Fälle nicht schlimmer als zuvor mit Stretch...

EDIT2: wenn keine Speicherprobleme da sind, ist der Umstieg doch noch nicht "zwingend"!? Ich dachte du hast Probleme...

Gruß, Joachim

Nein, habe keine Probleme mit stretch + dem alten perl 5.20.3.
Wollte halt ev. mal das uralt perl in Rente schicken  :o

Aber du hast recht, wahrscheinlich sollte ich des dabei belassen.
Muss nochmal drüber nachdenken.

pOpY
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 07 März 2020, 16:16:36
Hallo, habe jetzt auf buster & testweise perl 5.28 getestet.
Ich glaube ich bleib beim alten perl  ;)

buster + perl 5.28 nach reboot:

05.03.2020 08:30 - 306,70 MB
06.03.2020 08:30 - 354, 31 MB
07.03.2020 08:30 - 365,64 MB
07.03.2020 15:30 - 367,66 MB

buster + perl 5.20.3 nach reboot:

02.03.2020 20:29 - 297,53 MB
03.03.2020 09:09 - 322,16 MB
03.03.2020 19:35 - 311,08 MB
04.03.2020 20:24 - 326,56 MB
05.03.2020 08:30 - 326,26 MB

pOpY
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 13 März 2020, 18:56:28
Ihr Lieben, habe den Thread seit Monaten verfolgt und vor ein paar Wochen das Update von Uralt-Jessie auf Buster auf dem RPI3 angegangen.
Das, um das einzige Poblem welches ich mit fhem hatte (ein gemäßigter RAM Anstieg über 1-2 Wochen bis unresponsiv) zu eliminieren.

Jetzt habe ich noch ca 4 Tage bis wenig bis Nichts mehr geht.

Was ist zu tun? Weiter oben habe ich etwas von LibXXX 1.44 gelesen .... und der Installation über CPAN.

Ist das die Lösung? Irgendwo mal gelesen, dass man es vermeiden sollte über Apt installierte Pakete mit CPAN drüberzubügeln? Ihr seht, kein Linux-Versteher, der Holle ;)

Hat denn jemand Buster mit "perl:5.028001" (und was weiß ich  welchen Perl Komponenten-Versionen) ohne das Problem am Laufen? Das wurde noch nicht definitiv beantwortet.

Danke euch
H.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 13 März 2020, 19:11:11
Jep, 2 fhem auf Buster...

Keine Probleme nicht...
...aber besser als zuvor mit Stretch.

Wobei bei meinen Speicherfressern die letzten fhem-Änderungen eine Verbesserung gebracht haben...

Bei mir läuft fhem auf PI 3 mind. 3-4 Wochen...
Dann ginge sicher noch was aber ich starte da dann mal durch...

Wenn nicht eh schon vorher wegen Änderungen oder einem Update...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 13 März 2020, 19:19:07
Zitat von: holle75 am 13 März 2020, 18:56:28
Ihr Lieben, habe den Thread seit Monaten verfolgt und vor ein paar Wochen das Update von Uralt-Jessie auf Buster auf dem RPI3 angegangen.
Das, um das einzige Poblem welches ich mit fhem hatte (ein gemäßigter RAM Anstieg über 1-2 Wochen bis unresponsiv) zu eliminieren.

Jetzt habe ich noch ca 4 Tage bis wenig bis Nichts mehr geht.

Was ist zu tun? Weiter oben habe ich etwas von LibXXX 1.44 gelesen .... und der Installation über CPAN.

Ist das die Lösung? Irgendwo mal gelesen, dass man es vermeiden sollte über Apt installierte Pakete mit CPAN drüberzubügeln? Ihr seht, kein Linux-Versteher, der Holle ;)

Hat denn jemand Buster mit "perl:5.028001" (und was weiß ich  welchen Perl Komponenten-Versionen) ohne das Problem am Laufen? Das wurde noch nicht definitiv beantwortet.

Danke euch
H.

Ich bin seit dem Anfang bei dem Thema dabei.
Bis jetzt hat bei mir immer nur ein downgrade von perl auf 5.20.3 geholfen. Aber das ist sicher von Konfiguration zu Konfiguration (verw. Module) unterschiedlich.

Hatte mit stretch 5.24 5.26 und mit buster 5.28 durch, am besten geht das perl 5.20.3 mit perl brew installiert, siehe folgenden link :

https://forum.fhem.de/index.php/topic,84372.msg861586.html#msg861586

Gutes gelingen
pOpY
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 13 März 2020, 21:19:14
Zitat von: xenos1984 am 28 Dezember 2019, 21:59:12
Scheint, als hätten wir den Schuldigen gefunden. Nach einem Update von XML::XPath von 1.42 auf 1.44 verläuft der Test (1000 Mal parsen) ohne Speicherzuwachs. Im Moment lasse ich wieder den "Normalbetrieb" laufen, aber bisher habe ich auch hier nur einen geringen Speicheranstieg seit Start von FHEM, und seitdem bleibt er konstant (kein weiterer Anstieg alle 5 Sekunden wie vorher).

@MadMax .... welche XML::XPath Vers. läuft bei dir?

@popy .... mmh, irgendwie nach dem Großputz jetzt so weit downzugraden würde mir schwer fallen. Wenn ich dich richtig verstehe, hast du aber trotzdem noch (wenn auch zeitlich freundlicher) das Problem?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 13 März 2020, 21:33:10
Was immer mit Buster mitkommt...

Wie krieg ich das raus?

EDIT: wobei die Verbesserung NICHT von irgendwelchen OS-Änderungen kam, sondern von fhem-Änderungen... Also bei mir...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 13 März 2020, 22:09:01
das würde mich auch interessieren. Ich fragte nur weil ich dachte du weißt vielleicht ;)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 13 März 2020, 22:28:53
Also auf meinem Hauptsystem (Buster) läuft: libxml-xpath-perl 1.44-1 Raspbian:stable

EDIT: auf meinem Stretch Testsystem läuft 1.40-1 / aber auch da hatte ich VOR den fhem-Änderungen ein Speicherproblem mit dem echodevice-Modul, ebenso (nicht ganz so schlimm) auf meinem Buster Testsystem. Dann wurde in fhem und im echodevice-Modul was geändert und es wurde deutlich besser! Sonst wäre das echodevice-Modul NIE auf mein Hauptsystem gekommen...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 13 März 2020, 22:52:41
... und wie hast du das ---- libxml-xpath-perl 1.44-1 Raspbian:stable ---- gefunden?
Würde mich interessieren was bei mir läuft ... und warum bei xenos1984 damit das Problem behoben war ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 14 März 2020, 07:44:28
sudo apt-get -s install libxml-xpath-perl

Sofern du ebenfalls mit apt-get installiert hast...

Es wird dabei auch angezeigt, ob eine neuere Version verfügbar wäre...

Bei CPAN hab ich keine Ahnung.

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 14 März 2020, 09:37:17
Ah, drüberinstallieren um die Version zu finden ;)

Ja Mist, hab auch schon 1.44.

Scheint, die Lösungsidee von xenos1984 funktioniert nur unter bestimmten Umständen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 14 März 2020, 10:02:40
Ja, "drüber installieren" SIMULIEREN (das -s) ;)

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 14 März 2020, 11:13:44
Zitat von: holle75 am 13 März 2020, 21:19:14
@MadMax .... welche XML::XPath Vers. läuft bei dir?

@popy .... mmh, irgendwie nach dem Großputz jetzt so weit downzugraden würde mir schwer fallen. Wenn ich dich richtig verstehe, hast du aber trotzdem noch (wenn auch zeitlich freundlicher) das Problem?

Das stimmt und dachte ich mir auch, aber ich kenne derzeit noch keinen anderen Weg...
Ja, das Thema habe ich noch, wenn auch nicht mehr so ausgeprägt wie am Anfang (da war der Speicher nach ein paar Tagen voll...)

pOpY
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 14 März 2020, 11:19:04
wobei mit CPAN es auch einen Schlater gibt, um ALLS zu aktualisieren .. google mal danach

allerdings bin ich bekein Freund von CPAN im Normalfalle .. genau aus den Gründen
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 14 März 2020, 21:02:16
Danke euch ... mmh, irgendwie ist das recht unbefriedigend, wenn man bei allen Variablen (OS, Perl, fhem) dann endlich auf dem allerneuesten Stand ist und von 2 Wochen Laufzeit bei 2-4 Tagen landet. Heftig.

Eigentlich sind einige der bis anhin genannten Verdächtigen bei mir essentiell (besonders HTTPMOD), aber dann fange ich wohl trotzdem mal mit dem Modul-Eliminierspiel an.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 16 März 2020, 17:55:35
So, es ist genau ein HTTPMOD Device was mir den Speicher vollfährt. Leider ein recht essentielles, da es meine Solaranlage ausliest. Ohne dieses Device kein Anstieg seit 2 Tagen.
Aber vielleicht auch ein gutes Beispiel, um "böses" RegEx zu finden.

da es gerade eliminiert ist, direkt aus der cfg:
define XtenderReadout HTTPMOD none 10
attr XtenderReadout userattr get01Format get01Name get01Poll:0,1 get01PollDelay get01Regex get01URL get02Format get02Name get02Poll:0,1 get02Regex get02URL get03Name get03OMap get03Poll:0,1 get03PollDelay get03Regex get03URL get04Format get04Name get04Poll:0,1 get04Regex get04URL get05Format get05Name get05Poll:0,1 get05Regex get05URL get06Format get06Name get06Poll:0,1 get06PollDelay get06Regex get06URL get07Format get07Name get07Poll:0,1 get07PollDelay get07Regex get07URL readingMaxAge readingMaxAgeReplacement readingMaxAgeReplacementMode:text,reading,internal,expression,delete
attr XtenderReadout event-min-interval .*:1800
attr XtenderReadout event-on-change-reading Charge_Discharge_W:20,PV_Power_KW:0.05,PV_Power_W:50,Volt_Batt:0.3,SoC,Battery_cycle_phase,Temp_Batt,PV_Day_KWh
attr XtenderReadout event-on-update-reading .*
attr XtenderReadout get01Format %.1f
attr XtenderReadout get01Name SoC
attr XtenderReadout get01Poll 1
attr XtenderReadout get01PollDelay 60
attr XtenderReadout get01Regex <FloatValue>([1-9][0-9]\.?[0-9]?[0-9]?)
attr XtenderReadout get01URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=BSP&infoId=7002
attr XtenderReadout get02Format %.2f
attr XtenderReadout get02Name Volt_Batt
attr XtenderReadout get02Poll 1
attr XtenderReadout get02Regex <FloatValue>([1-3][0-9]\.?[0-9]?[0-9]?)
attr XtenderReadout get02URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=BSP&infoId=7000
attr XtenderReadout get03Name Battery_cycle_phase
attr XtenderReadout get03OMap 0:Bulk, 1:Absorption, 2:Equalize, 3:Floating, 6:R.Floating ,7:Per.Absorption
attr XtenderReadout get03Poll 1
attr XtenderReadout get03PollDelay 60
attr XtenderReadout get03Regex <FloatValue>([0-9])
attr XtenderReadout get03URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=VT1&infoId=11038
attr XtenderReadout get04Format %.2f
attr XtenderReadout get04Name PV_Power_KW
attr XtenderReadout get04Poll 1
attr XtenderReadout get04Regex <FloatValue>([0-1]\.?[0-9]?[0-9]?)
attr XtenderReadout get04URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=VT1&infoId=11004
attr XtenderReadout get05Format %2d
attr XtenderReadout get05Name Charge_Discharge_W
attr XtenderReadout get05Poll 1
attr XtenderReadout get05Regex <FloatValue>([-.0-9]+)
attr XtenderReadout get05URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=BSP&infoId=7003
attr XtenderReadout get06Format %.1f
attr XtenderReadout get06Name Temp_Batt
attr XtenderReadout get06Poll 1
attr XtenderReadout get06PollDelay 60
attr XtenderReadout get06Regex <FloatValue>([.0-9]*)
attr XtenderReadout get06URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=BSP&infoId=7029
attr XtenderReadout get07Format %.2f
attr XtenderReadout get07Name PV_Day_KWh
attr XtenderReadout get07Poll 1
attr XtenderReadout get07PollDelay 600
attr XtenderReadout get07Regex <FloatValue>([0-1]?[0-9]\.?[0-9]?[0-9]?)
attr XtenderReadout get07URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=VT1&infoId=11007
attr XtenderReadout group Xtender
attr XtenderReadout readingMaxAge 1200
attr XtenderReadout readingMaxAgeReplacement "outdated - was " . $val
attr XtenderReadout readingMaxAgeReplacementMode expression
attr XtenderReadout stateFormat {sprintf("Phase: %s - SoC: %.1f - PV: %2d Watt", ReadingsVal($name,"Battery_cycle_phase",0), ReadingsVal($name,"SoC",0), ReadingsVal($name,"PV_Power_W",0))}
attr XtenderReadout userReadings PV_Power_W {ReadingsVal("XtenderReadout","PV_Power_KW",0)*1000}
attr XtenderReadout verbose 2


werde das auch mal StefanStrobel im entsprechenden HTTPMOD Thread verlinken. Vielleicht fällt ihm ja was ein.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 16 März 2020, 18:03:13
Zitat von: holle75 am 16 März 2020, 17:55:35
So, es ist genau ein HTTPMOD Device was mir den Speicher vollfährt. Leider ein recht essentielles, da es meine Solaranlage ausliest. Ohne dieses Device kein Anstieg seit 2 Tagen.
Aber vielleicht auch ein gutes Beispiel, um "böses" RegEx zu finden.

da es gerade eliminiert ist, direkt aus der cfg:
define XtenderReadout HTTPMOD none 10
attr XtenderReadout userattr get01Format get01Name get01Poll:0,1 get01PollDelay get01Regex get01URL get02Format get02Name get02Poll:0,1 get02Regex get02URL get03Name get03OMap get03Poll:0,1 get03PollDelay get03Regex get03URL get04Format get04Name get04Poll:0,1 get04Regex get04URL get05Format get05Name get05Poll:0,1 get05Regex get05URL get06Format get06Name get06Poll:0,1 get06PollDelay get06Regex get06URL get07Format get07Name get07Poll:0,1 get07PollDelay get07Regex get07URL readingMaxAge readingMaxAgeReplacement readingMaxAgeReplacementMode:text,reading,internal,expression,delete
attr XtenderReadout event-min-interval .*:1800
attr XtenderReadout event-on-change-reading Charge_Discharge_W:20,PV_Power_KW:0.05,PV_Power_W:50,Volt_Batt:0.3,SoC,Battery_cycle_phase,Temp_Batt,PV_Day_KWh
attr XtenderReadout event-on-update-reading .*
attr XtenderReadout get01Format %.1f
attr XtenderReadout get01Name SoC
attr XtenderReadout get01Poll 1
attr XtenderReadout get01PollDelay 60
attr XtenderReadout get01Regex <FloatValue>([1-9][0-9]\.?[0-9]?[0-9]?)
attr XtenderReadout get01URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=BSP&infoId=7002
attr XtenderReadout get02Format %.2f
attr XtenderReadout get02Name Volt_Batt
attr XtenderReadout get02Poll 1
attr XtenderReadout get02Regex <FloatValue>([1-3][0-9]\.?[0-9]?[0-9]?)
attr XtenderReadout get02URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=BSP&infoId=7000
attr XtenderReadout get03Name Battery_cycle_phase
attr XtenderReadout get03OMap 0:Bulk, 1:Absorption, 2:Equalize, 3:Floating, 6:R.Floating ,7:Per.Absorption
attr XtenderReadout get03Poll 1
attr XtenderReadout get03PollDelay 60
attr XtenderReadout get03Regex <FloatValue>([0-9])
attr XtenderReadout get03URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=VT1&infoId=11038
attr XtenderReadout get04Format %.2f
attr XtenderReadout get04Name PV_Power_KW
attr XtenderReadout get04Poll 1
attr XtenderReadout get04Regex <FloatValue>([0-1]\.?[0-9]?[0-9]?)
attr XtenderReadout get04URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=VT1&infoId=11004
attr XtenderReadout get05Format %2d
attr XtenderReadout get05Name Charge_Discharge_W
attr XtenderReadout get05Poll 1
attr XtenderReadout get05Regex <FloatValue>([-.0-9]+)
attr XtenderReadout get05URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=BSP&infoId=7003
attr XtenderReadout get06Format %.1f
attr XtenderReadout get06Name Temp_Batt
attr XtenderReadout get06Poll 1
attr XtenderReadout get06PollDelay 60
attr XtenderReadout get06Regex <FloatValue>([.0-9]*)
attr XtenderReadout get06URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=BSP&infoId=7029
attr XtenderReadout get07Format %.2f
attr XtenderReadout get07Name PV_Day_KWh
attr XtenderReadout get07Poll 1
attr XtenderReadout get07PollDelay 600
attr XtenderReadout get07Regex <FloatValue>([0-1]?[0-9]\.?[0-9]?[0-9]?)
attr XtenderReadout get07URL https://einServer.com/webservice.asmx/ReadUserInfo?email=net@xx.com&pwd=xxxxxx&installationNumber=111111&device=VT1&infoId=11007
attr XtenderReadout group Xtender
attr XtenderReadout readingMaxAge 1200
attr XtenderReadout readingMaxAgeReplacement "outdated - was " . $val
attr XtenderReadout readingMaxAgeReplacementMode expression
attr XtenderReadout stateFormat {sprintf("Phase: %s - SoC: %.1f - PV: %2d Watt", ReadingsVal($name,"Battery_cycle_phase",0), ReadingsVal($name,"SoC",0), ReadingsVal($name,"PV_Power_W",0))}
attr XtenderReadout userReadings PV_Power_W {ReadingsVal("XtenderReadout","PV_Power_KW",0)*1000}
attr XtenderReadout verbose 2


werde das auch mal StefanStrobel im entsprechenden HTTPMOD Thread verlinken. Vielleicht fällt ihm ja was ein.

Wie aktuell ist dein fhem!?

An HTTPMOD wurde ja was "gedreht"...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 16 März 2020, 18:04:36
Alles komplett neu aufgesetzt + update FHEM vor 4 Tagen

$Id: 98_HTTPMOD.pm 21141 2020-02-07 19:36:06Z StefanStrobel $
# fhem Modul für Geräte mit Web-Oberfläche / Webservices
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 16 März 2020, 19:38:15
In der HTTPMOD Doku (https://fhem.de/commandref_modular.html#HTTPMODattr) steht bei regexDecode was ueber memory leak.
Falls das nicht hilft, wuerde ich auch regexpCompile=0 ausprobieren.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 17 März 2020, 09:58:31
seit

attr <DEVICE> regexDecode utf-8

sieht es bis jetzt fantastisch aus. Dankeschön!

Ich beobachte.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 23 März 2020, 16:05:33
... zu früh gefreut. Immer noch Ram Anstieg bis freeze, aber wesentlich! langsamer ....
Ich schaue weiter ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 03 April 2020, 20:55:07
... jetzt muß ich kurz mal (wieder) eine unqualifizierte Frage stellen: habe soeben fhem, was weiterhin ca. 50MB täglich Ram-Zugewinn anzeigt, beendet, mit htop geschaut, dass es auch sicher nicht mehr läuft und dann fhem neu gestartet.... den Raspi habe ich nicht neu gestartet.

Für mich interessanterweise, wurde kein RAM Total freigegeben (vor/nach fhem restart selbe Menge RAM in Benutzung. Nach ca. 2 Tagen 100MB mehr als nach Raspi Neustart). Auf die Idee, dass der Raspi RAM leakt und nicht unbedingt fhem, bin ich noch nicht gekommen.

Oder wie muß ich mir das erklären?

Gruß
H.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Frank_Huber am 03 April 2020, 20:58:09
Perl nimmt sich ram, gibt ihn aber nicht wieder frei.
Innerhalb Perl wird er wohl recycled, aber auch nur was als "frei" markiert ist.
Daher hilft nur ein reboot um sicbtbar mehr ram zu haben.

Bin kein Perl Profi, meine das aber letzt in der Perl Ecke gelesen zu haben.

Gesendet von meinem S68Pro mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 03 April 2020, 21:02:10
Danke Frank. Hatte mich gerade wieder gefreut, irgendwann mal hinter diese Problematik hier zu steigen, bzw einen Ansatz zu finden.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 03 April 2020, 21:16:26
ZitatPerl nimmt sich ram, gibt ihn aber nicht wieder frei.
Innerhalb Perl wird er wohl recycled, aber auch nur was als "frei" markiert ist.
Das ist vermutlich richtig, haengt aber strenggenommen vom verwendeten libmalloc ab (was man beim Perl-Bauen angibt), und manche Varianten davon geben Speicher auch wieder zurueck an das OS, wenn sinnvoll machbar.

ZitatDaher hilft nur ein reboot um sicbtbar mehr ram zu haben.
Das ist falsch, ein Programm-Neustart gibt den Speicher frei.

Keine Ahnung, woher die Angabe "RAM-Total" stammt, und was genau es bezeichnet.
Der klassiche Fehler in dieser Zusammenhang ist, dass man annimmt, dass ein Problem sei, wenn "Memory used" gleich "Verfuegbarer Speicher" ist.
Dabei wird uebersehen, dass Betriebsysteme alles moegliche Cachen, damit das nicht nochmal von Platte geholt werden muss, und dieser Cache auch als "used" angezeigt wird.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Frank_Huber am 03 April 2020, 21:23:38
Danke Rudi,
Dann wird der freigemachte Speicher wohl nur nicht im Sysmon angezeigt.
Bei mir kommt das cannot fork erst so nach 3 bis 4 Monaten, bis dahin hab ich aber idr längst Updates mit Neustart gemacht.

Gesendet von meinem S68Pro mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 03 April 2020, 21:24:00
"RAM-Total" war in meinem Fall die von htop angezeigte Menge "mem" gemeint.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: AndreM am 21 April 2020, 22:36:36
Guten Abend,
ich habe dieses Problem seit ein paar Tagen auch. Was ich geändert habe ist nur das logging per mysql und ein ca. 8 SVG-plots daraus erzeugt.
Meine Beobachtung heute war, je länger der Server läuft und je mehr Daten in den SVG's angezeigt werden, desto langsamer wird der Server. Zusätzlich zeigt das Log immer öfter den Fehler "Cannot fork...."

Ich habe jetzt ein paar SVG-plots gelöscht. Der Server wird dadurch wieder schneller und die Anzahl der Fehlermeldungen geht zurück bzw. verschwindet.

Vielleicht hilft es ja wem weiter.

Schönen Abend noch.
Andre
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 22 April 2020, 12:50:38
ZitatMeine Beobachtung heute war, je länger der Server läuft und je mehr Daten in den SVG's angezeigt werden, desto langsamer wird der Server.
Dass SVGs mit viel Daten anzuzeigen laenger braucht, ist bekannt, und das ist unabhaengig vom Serverlaufzeit.
In vielen Faellen empfiehlt sich nur die notwendigen Daten anzuziegen, z.Bps. fuer Jahresuebersicht Tageswerte zu berechnen.

Die SVG Definition an sich benoetigt keinen nennenswerten Speicher, nur die Anzeige.
Mit plotfork=1 oder mit plotEmbed=2 wird fuer jedes anzuzeigendende SVG FHEM geforkt, die SVG-Berechnung blockiert damit den eigentlichen FHEM-Prozess nicht.
Die Parallelitaet wird vom Browser begrenzt, mW ist das bei den ueblichen Browser 6.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: satprofi am 31 Mai 2020, 12:57:24
Hallo.
Will nicht alle 54 seiten durchackern, aber habe seit 2 tagen kein update von proplanta erhalten. im log steht "Cannot fork: Cannot allocate memory", und mein speicher war nur mehr 10% frei, habe fhem neu gestartet, jetzt habe ich gerade mal 10% belegt und das proplanta update geht auch wieder.
gibts dafür keine lösung, oder?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 31 Mai 2020, 13:05:47
Entweder doch durchwühlen und versuchen eine Variante zu finden, die für DEIN System und "KÖNNEN" passt...

Frage: wie aktuell ist fhem!?

Welche HW-Plattform, OS-Release, ...

Oder "Notlösung" autom. fhem-Neustart, wenn "Cannot fork: Cannot allocate memory" kommt.

Gibt ein Event dazu -> Notify -> shutdown restart

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: satprofi am 31 Mai 2020, 13:09:04
fhem.pl:16675/2018-04-29
PI2 squeezy
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 31 Mai 2020, 14:27:23
Squeezy!?

Du meinst Wheezy!?

Da würde ich ja unabhängig von den Problemen auf Buster gehen...

Und die fhem.pl Version da müsste ich nachschauen, keine Lust...
Wie wär's einfach zu schreiben wie alt dein fhem ist, also wann der letzte Update war...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Frank_Huber am 31 Mai 2020, 15:44:31
Wheezy und ein fhem von 2018.
Dringend OS und FHEM updaten!

Gesendet von meinem S68Pro mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: satprofi am 31 Mai 2020, 16:36:51


Zitat von: MadMax-FHEM am 31 Mai 2020, 14:27:23

Wie wär's einfach zu schreiben wie alt dein fhem ist, also wann der letzte Update war...

Gruß, Joachim
original, muss ja nur meine sonoffs steuern.


Gesendet von meinem ONEPLUS A5000 mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 31 Mai 2020, 16:42:56
Zitat von: satprofi am 31 Mai 2020, 16:36:51
original, muss ja nur meine sonoffs steuern.


Gesendet von meinem ONEPLUS A5000 mit Tapatalk

Original ist noch viel mehr Quatsch als die pm-Version zu posten...
...es gibt kein "Original"...

Es gibt builds (.deb bei Debian) mit einem gewissen Stand die man installieren kann und dann eben Updates...
...oder auch nicht.
Und fhem ändert sich JEDEN TAG.

Aber bei deiner "Hilfsbereitschaft" DIR helfen zu lassen mache ich es kurz:

schließe mich Frank_Huber an...

wenn das nicht hilft bleibt dir wohl nichts über als dich "durchzuquälen"...

Weil (wie du spät. nach dem "Durchquälen" merken wirst) es nicht DIE Lösung gibt, weil es auch nicht DAS System gibt...
...und von deinem wissen wir dank dir nicht wirklich viel...
...und was wir wissen haben wir uns "erarbeitet"...

Viel Erfolg beim Updaten (oder auch nicht) und viel Erfolg danach, dass es dann "Geschichte" ist...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 31 Mai 2020, 18:33:18
@satprofi:
- wir haben sehr viel Energie reingesteckt, um dieses Problem zu loesen, das sieht man an der Laenge der Diskussion.
- die meisten Anwender haben keine Probleme
- die Probleme treten nur bei bestimmten Kombination von Modulen/Attributen/Perl-Version/etc auf.
- es gibt/gab mehrere Ursachen, es kann (nachgewiesen) an der Perl Version (5.24.x), an OS-Bibliotheken, an FHEM-Framework oder an FHEM-Modul-Code liegen
- wir haben auch in FHEM etliche Ursachen gefixt, vermutlich aber nicht alles.

Bitte FHEM in der aktuellen Version einsetzen (d.h. in FHEM update eintippen, gefolgt von shutdown restart), am besten mit einem aktuellen Perl.

Wenn es danach immer noch Probleme gibt, dann ist eine Moeglichkeit die Definitionen eins nach dem Anderen zu deaktivieren/entfernen, bis das Problem nicht mehr vorhanden ist, und die zuletzt entfernte Definition hier melden.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: satprofi am 31 Mai 2020, 19:39:10
ok, danke. werd mir den thread durchlesen. aber komisch nur das das ding fast 2 jahre ohne störung lief, und erst am 29.5. die meldung im log steht und proplanta nicht mehr updatete.

Gesendet von meinem ONEPLUS A5000 mit Tapatalk

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: holle75 am 14 Juli 2020, 11:27:30
@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.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 19 Juli 2020, 11:38:28
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:
.....
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:
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 19 Juli 2020, 11:42:17
Wenn im notify "CANNOT_FORK" groß geschrieben ist - im event aber "Cannot fork" steht kann das notify nicht schalten...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 19 Juli 2020, 11:56:08
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 (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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 19 Juli 2020, 12:23:51
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 19 Juli 2020, 14:05:37
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...



Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Rewe2000 am 19 Juli 2020, 16:22:55
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: der-Lolo am 19 Juli 2020, 16:56:15
Das DOIF welches ich mit Sysmon einsetze läuft noch - auch wenn es wegen FHEM nicht mehr zum einsatz kommt...

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.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KNUT345 am 11 August 2020, 20:21:49
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.
/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.
/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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 12 August 2020, 09:15:27
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.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KNUT345 am 12 August 2020, 17:54:44
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
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: hyper2910 am 26 August 2020, 22:21:45
Zitat von: rudolfkoenig am 12 August 2020, 09:15:27
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???
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: frank am 26 August 2020, 22:48:55
am einfachsten ist sicherlich ein upgrade auf buster.
anleitungen für perl upgrade sind hier im thread.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 17 November 2020, 13:17:10
Nachdem ich mit perlbrew nicht zum Ziel kam, habe auch ich meinen Raspberry mit Buster und der neuen Perlversion neu aufgesetzt.

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


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 ?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 17 November 2020, 16:04:11
Wie hast Du mysql eingerichtet?
Wie viel Speicher braucht fhem/mysql?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 17 November 2020, 19:28:41
Also mySQL und phpmyadmin ganz normal.

https://tutorials-raspberrypi.de/webserver-installation-teil-3-mysql/

Aber lt. Htop verbraucht fhem ja 55% steigend.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Christoph Morrison am 17 November 2020, 21:43:13
Funktioniert das Schreiben der Logs in die MySQL auch? Mach mal bitte ein list deines DBLog-Devices.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 18 November 2020, 07:12:13
Also gestern erst neugestartet und heut ist der Speicher bereits bei 650MB von 1GB. HTop zeigt dass fhem den meisten Speicher frisst und nicht mySQL. My SQL loggt aber die Daten richtig mit.

Was könnte denn noch den Speicher bei fhem fressen ? Ich habe aber schon das Gefühl, dass das Problem erst mit dem Umstieg auf mySQL auftritt. Hab mich aber an die Anleitung von https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DTOy9eP1YR98&psig=AOvVaw3mI3rnevd5pqzlJmmfObAY&ust=1605766264332000&source=images&cd=vfe&ved=2ahUKEwjuib_Pt4vtAhVMr6QKHTGzCYUQr4kDegUIARCQAQ (https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DTOy9eP1YR98&psig=AOvVaw3mI3rnevd5pqzlJmmfObAY&ust=1605766264332000&source=images&cd=vfe&ved=2ahUKEwjuib_Pt4vtAhVMr6QKHTGzCYUQr4kDegUIARCQAQ) gehalten.

List DBLogging
Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION ./db.conf
   DEF        ./db.conf .*:.*
   FUUID      5fa26001-f33f-e9d9-7b2d-89de79a5ad4b8f61
   FVERSION   93_DbLog.pm:v4.10.2-s22246/2020-06-23
   MODE       asynchronous
   MODEL      MYSQL
   NAME       DBLogging
   NR         1253
   NTFY_ORDER 50-DBLogging
   PID        845
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   UTF8       1
   dbconn     mysql:database=fhem;host=localhost;port=3306
   dbuser     fhemuser
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     PACKAGE    main
     READINGCOL 64
     TC         current
     TH         history
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
     VERSION    4.10.2
     REDUCELOG:
       DBLogging
       reduceLogNbl
       90
       average
   READINGS:
     2020-11-18 07:08:47   CacheUsage      0
     2020-11-18 07:08:47   NextSync        2020-11-18 07:09:17 or if CacheUsage 500 reached
     2020-11-18 03:00:02   reduceLogState  reduceLogNbl finished. Rows processed: 0, deleted: 0, updated: 0, time: 2.00sec
     2020-11-18 07:08:47   state           connected
   helper:
     bm:
       DbLog_Get:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        18.11. 07:04:49
         max        9.48905944824219e-05
         tot        9.48905944824219e-05
         mAr:
           HASH(0x66a7540)
           DBLogging
           ?
       DbLog_Log:
         cnt        407
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        18.11. 07:08:28
         max        0.101495981216431
         tot        0.842778921127319
         mAr:
           HASH(0x66a7540)
           HASH(0x554e8a8)
       DbLog_Set:
         cnt        3
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        18.11. 07:02:47
         max        0.0655310153961182
         tot        0.0677380561828613
         mAr:
           HASH(0x66a7540)
           DBLogging
           reopen
Attributes:
   DbLogExclude .*
   DbLogSelectionMode Exclude/Include
   DbLogType  Current/History
   asyncMode  1
   room       System->LogFiles


Gibt es nicht eine Möglichkeit die in fhem mir die Prozesse anzeigt, welche Speicher die verbrauchen ?

apptime liefert derzeit nur... und da habe ich jene mit average über 1000 schon deaktiviert.
active-timers: 182; max-active timers: 189; max-timer-load: 9  min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 343.9ms; totAvgDly: 47.5ms

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
tmr-DOIF_SleepTrigger                    HASH(0x3c7ead8)                        281        1     281.62   281.62     1.75     1.75 18.11. 07:13:29 HASH(Modus_FBH.Anwesenheit)
Modus_Sommer.Auto                        DOIF_Notify                            264        8     266.71    33.34     0.00     0.00 18.11. 07:08:28 HASH(Modus_Sommer.Auto); HASH(Wetter_Pro)
Modus_FBH                                dummy_Set                              243        2     450.57   225.28     0.00     0.00 18.11. 07:13:29 HASH(Modus_FBH); Modus_FBH; Auto
Modus_Sommer                             dummy_Set                              241        1     241.35   241.35     0.00     0.00 18.11. 07:08:28 HASH(Modus_Sommer); Modus_Sommer; off
tmr-DOIF_TimerTrigger                    REF(0x8ce50a0)                         236        1     236.92   236.92     1.59     1.59 18.11. 07:05:00 REF(0x8ce50a0)
myJeeLink                                JeeLink_Read                           233      420   14952.91    35.60     0.00     0.00 18.11. 07:04:44 HASH(myJeeLink)
Modus_FBH.Sommer                         DOIF_Notify                            224        8     226.47    28.31     0.00     0.00 18.11. 07:08:28 HASH(Modus_FBH.Sommer); HASH(Modus_Sommer)
tmr-SIP_watch_listen                     mySIP                                  170       12    1732.81   144.40   229.50    27.50 18.11. 07:12:45 mySIP
tmr-FW_closeInactiveClients              0                                      118       11     429.58    39.05     1.90     1.32 18.11. 07:06:15 0
WEB_192.168.178.22_62594                 FW_Read                                110        8     165.70    20.71     0.00     0.00 18.11. 07:04:49 HASH(WEB_192.168.178.22_62594)
DBLogging                                DbLog_Log                              101      689    1355.21     1.97     0.00     0.00 18.11. 07:08:28 HASH(DBLogging); HASH(Wetter_Pro)
tmr-at_Exec                              HASH(0x6c71ad0)                         92        1      92.99    92.99     1.49     1.49 18.11. 07:02:47 HASH(DBLogging.ReOpen)
tmr-DOIF_TimerTrigger                    REF(0x7ad21e0)                          86        1      86.15    86.15     1.32     1.32 18.11. 07:06:00 REF(0x7ad21e0)
tmr-GetUpdate                            update                                  84       10     228.11    22.81     5.83     2.19 18.11. 07:03:08 update:TV_ProgrammePT
LaCrosse.Statistiken                     statistics_Notify                       70      123    4326.27    35.17     0.00     0.00 18.11. 07:08:45 HASH(LaCrosse.Statistiken); HASH(WC.LaCrosse)
FBH.DG.HomeMatic.CH_01.Auto              DOIF_Notify                             68       22     643.17    29.24     0.00     0.00 18.11. 07:04:30 HASH(FBH.DG.HomeMatic.CH_01.Auto); HASH(GZ.LaCrosse)
FBH.DG.HomeMatic.CH_01.Off               DOIF_Notify                             67        9     109.56    12.17     0.00     0.00 18.11. 07:13:28 HASH(FBH.DG.HomeMatic.CH_01.Off); HASH(Modus_FBH)
DBLogging                                DbLog_Set                               65        3      67.74    22.58     0.00     0.00 18.11. 07:02:47 HASH(DBLogging); DBLogging; reopen
tmr-DbLog_execmemcache                   HASH(0x66a7540)                         65       22     627.33    28.52   169.07    15.09 18.11. 07:12:17 HASH(DBLogging)
myCUL_433                                CUL_Read                                62       37     424.01    11.46     0.00     0.00 18.11. 07:09:42 HASH(myCUL_433)
tmr-PRESENCE_StartLocalScan              HASH(0x5d16280)                         60       11     551.56    50.14   105.70    37.61 18.11. 07:05:06 HASH(Smartphone_Sven)
FBH.DG.HomeMatic.CH_02.Auto              DOIF_Notify                             60       19     449.55    23.66     0.00     0.00 18.11. 07:10:30 HASH(FBH.DG.HomeMatic.CH_02.Auto); HASH(AZ.LaCrosse)
tmr-PRESENCE_StartLocalScan              HASH(0x5d20a90)                         60       11     572.61    52.06    88.50    28.86 18.11. 07:10:07 HASH(Smartphone_Myriam)
tmr-PRESENCE_StartLocalScan              HASH(0x5cfd840)                         60       11     505.54    45.96   101.85    68.21 18.11. 07:03:05 HASH(iPhone.8.Wlan)
tmr-TSCUL_DispatchDelayed                DdlmyCUL                                52       22     704.91    32.04     0.00     0.00 18.11. 07:06:32 DdlmyCUL:myCUL:1605679592.55893 -53 A0E27800258270CF110340101000034::-53:myCUL:
tmr-Twilight_sunpos                      HASH(0x8f2af90)                         51        1      51.80    51.80     1.38     1.38 18.11. 07:05:01 HASH(twilight_sunpos)
BatteryStatus.Check                      notify_Exec                             50      689     649.35     0.94     0.00     0.00 18.11. 07:08:28 HASH(BatteryStatus.Check); HASH(Wetter_Pro)
tmr-FRITZBOX_Readout_Start               FritzBox.6490.Readout                   46       12     477.25    39.77   359.67   171.03 18.11. 07:10:45 FritzBox.6490.Readout
GZ.LaCrosse_statistic                    statistics_Notify                       45       20     435.49    21.77     0.00     0.00 18.11. 07:02:37 HASH(GZ.LaCrosse_statistic); HASH(GZ.LaCrosse)
tmr-FRITZBOX_Readout_Start               FritzBox.Repeater.310.Readout           45       12     500.40    41.70   343.72   170.37 18.11. 07:08:45 FritzBox.Repeater.310.Readout
tmr-FRITZBOX_Readout_Start               FritzBox.7490.Readout                   45       12     516.34    43.03   354.06   168.47 18.11. 07:08:44 FritzBox.7490.Readout
BZLueften                                notify_Exec                             44       25     539.73    21.59     0.00     0.00 18.11. 07:02:41 HASH(BZLueften); HASH(BZ.LaCrosse)
tmr-PRESENCE_StartLocalScan              HASH(0x46ff098)                         44        6     245.59    40.93   238.12   133.91 18.11. 07:03:44 HASH(devolo.dLAN.500.Wlan)
tmr-PRESENCE_StartLocalScan              HASH(0x4700de0)                         43        6     234.49    39.08   275.84   154.56 18.11. 07:09:45 HASH(devolo.dLAN.500.WiFi)
BZ.LaCrosse_statistic                    statistics_Notify                       43       19     352.51    18.55     0.00     0.00 18.11. 07:03:25 HASH(BZ.LaCrosse_statistic); HASH(SZ.LaCrosse)
FBH.DG.HomeMatic.CH_01.Auto              DOIF_Set                                42        2      64.44    32.22     0.00     0.00 18.11. 07:13:28 HASH(FBH.DG.HomeMatic.CH_01.Auto); FBH.DG.HomeMatic.CH_01.Auto; initialize
AZ.LaCrosse_statistic                    statistics_Notify                       41       17     325.31    19.14     0.00     0.00 18.11. 07:04:31 HASH(AZ.LaCrosse_statistic); HASH(AZ.LaCrosse)
FLKU.LaCrosse_statistic                  statistics_Notify                       40       20     393.36    19.67     0.00     0.00 18.11. 07:05:19 HASH(FLKU.LaCrosse_statistic); HASH(FLKU.LaCrosse)
tmr-DOIF_TimerTrigger                    REF(0x8e5ba38)                          40        1      40.44    40.44     0.90     0.90 18.11. 07:07:00 REF(0x8e5ba38)
tmr-RESIDENTStk_DurationTimer            HASH(0x78d5970)                         40        1      40.26    40.26   149.89   149.89 18.11. 07:02:43 HASH(residents_DurationTimer)
KZ.LaCrosse_statistic                    statistics_Notify                       39       24     528.00    22.00     0.00     0.00 18.11. 07:11:18 HASH(KZ.LaCrosse_statistic); HASH(KZ.LaCrosse)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 18 November 2020, 09:37:42
Nein gibt es nicht so wirklich meines Wissens. Es gibt nur eins das du machen kannst. Sichere deine Konfiguration. Lösche dann 5 Devices und starte FHEM mit shutdown restart neu und beobachte den Speicherverbrauch. Wenn er dann irgendwann nicht mehr steigt, dann ist es eins der 5 Devices die du davor gelöscht hast. Dann kannst du das auf dem gleichen Weg weiter eingrenzen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wzut am 18 November 2020, 10:19:55
naja , indirekt und je nach Verursacher schon : Bsp das SIP Modul , die PID des Child Prozess findest du in den Internals des SIP Device unter LPID und auch in den eckigen Klammern bei der Log Ausgabe. Mit der PID kannst dann ja den Pozess in der htop Anzeige finden
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 18 November 2020, 10:40:43
Hab mal diese Update. devices rausgeschmissen und Abfall auch. Nach restart erst bei 300 und dann der Sprung auf 500 MB innerhalb kürzester Zeit.
Zudem hab ich jetzt 4 Prozesse von fhem laufen...

in den Internals des mySIP fand ich dann die PID (LPID 25054) welche in htop als 4. fhem Prozess läuft.

Log
2020.11.18 10:22:49.636 4: mySIP, Listen new PID : 25054
2020.11.18 10:22:49.652 4: mySIP[25054], my parent is 24988


Die anderen PID fand ich im Log jedoch nicht.

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 18 November 2020, 11:39:17
Du hast mehr als 1 FHEM-Prozess, da in htop jeder folk einzeln gezeigt wird. Du hast schließlich auch "nur" ein mysql aber in htop ..... schaue mal bei htop unter setup/Display Options/Hide userland process threads und aktiviere es .....

Für fhem und steigenden Verbraucht gibt es schon einen Thread dazu.

Persönliche Meinung:
Ich würde Dir aber auf einem PI keine mysql Datenbank empfehlen ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 18 November 2020, 12:29:19
ZitatFür fhem und steigenden Verbraucht gibt es schon einen Thread dazu.
Hab in der Suche nichts brauchbares gefunden... kann es an der mySQL liegen, ob der Verbrauch am fhem Prozess hängt ?


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 18 November 2020, 12:33:34
Meistens liegt es an RegEX .. da hat perl einige Probleme ...

ABER ... Bei Dir: 5% des Speichers gehen aktuell für mysql "drauf". Dazu kommt noch apache (phpmysql) und schon hast Du einigen Verbrauche der "knappen" 1GByte. Zusätzlich ist mysql nicht gut für die SD, da es nicht optimal schreibt. Es ist eben für "Größere" Maschinen gedacht ....

Was hast Du eigentlich alles auf dem Pi?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 18 November 2020, 12:36:14
Auf dem Pi läuft nur fhem, mysql, phpmyadmin, perl 5.28 und dieses grafana.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 18 November 2020, 12:40:42
Meine Meinung:
Ich würde FHEM und sonstige "großen" Programme beim Pi physikalisch trennen .... aber das ist nur meine persönliche Meinung ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 18 November 2020, 14:11:11
Würde ein sog. Docker ggf. Abhilfe schaffen ?

https://blog.krannich.de/fhem-auf-rpi-mit-docker-und-hypriot/ (https://blog.krannich.de/fhem-auf-rpi-mit-docker-und-hypriot/)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 18 November 2020, 14:34:53
Das vergrößert nicht Dein Arbeitsspeicher ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 19 November 2020, 12:40:39
Also gestern lief der Speicher mir wieder voll und es ist immer nur ein fhem prozess lt. htop. Heute nach einem Neustart geht das Spielchen weiter...


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  768 fhem      20   0  274760 228776  12328 S   8,3  24,2  19:50.91 perl
1379 fhem      20   0  167312 113076   3764 S   0,0  11,9   0:12.29 perl
  595 mysql     20   0  723616  95296  15468 S   0,3  10,1   0:49.38 mysqld
1052 pi        20   0  307920  58248  44980 S   0,0   6,2   0:02.29 zenity


Es kann doch nicht sein, dass fhem keinen Speicher wieder freigibt oder gibt es da doch eine Möglichkeit. Am masql kannst nicht liegen, der Speicher bleibt konstant.

sagt das vielleicht noch etwas aus ?

pi@raspberrypi:~ $ sudo pstree -tca | grep [f]hem
  |-perl fhem.pl fhem.cfg
  |   `-perl fhem.pl fhem.cfg
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66


Hier mal der Code aus presence.sh (auch hier vom Forum).
#!/bin/bash
# detect Iphone/Android by IP/HOSTNAME and MAC address.
# use MAC address too, to prevent false positives if IP might change
# returns 1 or 0
# number of retries, less is faster, but less accurate

PREMAXRETRIES=6
MAXRETRIES=6
# exit immediately if no parameters supplied
if [ $# -lt 2 ]
  then
    echo "UNDEF"
  exit 1
fi

# Set variables
IP=`echo $1 | grep -oP '([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}'`
#HOST=`host -4 $1 | grep -oP '([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}'`
MAC=$2
COUNT=0
PRECOUNT=0

if [ -z "$IP" ]; then
IP=${HOST}
if [ -z "$IP" ]; then
echo "0"
exit 0
fi
fi

while [ ${PRECOUNT} -lt ${PREMAXRETRIES} ];
do
PRECHECK=`arp -a | grep -o "${MAC}"`
if [ ${#PRECHECK} -eq ${#MAC} ]; then
   # exit when phone is detected
   echo "1"
   exit 0
fi
((PRECOUNT++))
done


while [ ${COUNT} -lt ${MAXRETRIES} ];
do
  # Change dev and eth0 if needed
  #   sudo ip neigh flush dev eth0 ${IP}
  ping  ${IP} >/dev/null 2>&1
  #sudo hping3 -q -2 -c 10 -p 5353 -i u1 ${IP}
  sleep .1
  # Only arp specific device, grep for a mac-address
  STATUS=`arp -a | grep -o "${MAC}"`

  if [ ${#STATUS} -eq ${#MAC} ]; then
     # exit when phone is detected
     echo "1"
    exit 0
  fi
  ((COUNT++))
  sleep .1
done
# consider away if reached max retries
echo "0"
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 19 November 2020, 13:49:20
ZitatEs kann doch nicht sein, dass fhem keinen Speicher wieder freigibt ....
Doch, es kann sein. Ist nicht schoen, ist ein Fehler, und rauszukriegen, wo es herkommt, ist nicht trivial, wie man es an der Laenge dieser Diskussion sieht. Wir hatten als Schuldigen mal perl-Versionen ausgemacht, und ich habe auch bestimmte Betriebsystem-Bibliotheksversionen fuer ARM auch in Verdacht. Allerdings betrifft das Problem nur wenige, und definitiv nicht mich, sonst wuerde ich dem Problem auf dem Grund gehen.

Ich kenne z.Zt. nur zwei Methoden, um die Ursache zu identifizieren, das bereits erwaehnte Schrittweise entfernen der FHEM-Definitionen, und die in diesem Thread erwaehnte pmap Variante, was aber nur fuer Erfahrene und/oder Hartnaeckige zu empfehlen ist.

Die vielen presence.sh Prozesse in deinem Fall ist vermutlich auch nicht richtig, ich vermute es liegt an ping ohne Limitierung. Sollte aber nicht die Ursache des FHEM-Speicherverbrauchs sein.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 19 November 2020, 19:53:41
Naja ... da er ein System hat, wo auch mysql und apache läuft sollten die Anzahl der presents-Prozesse auf jedem Falle begrenzt werden.

Irgendwann hatten wir mal jemanden, wo die Begrenzung geholfen hat. Wie man aber presents bändigt, ist mir nicht bekannt ....
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wzut am 19 November 2020, 20:07:06
Zitat von: rudolfkoenig am 19 November 2020, 13:49:20
Ich kenne z.Zt. nur zwei Methoden, um die Ursache zu identifizieren
vllt, könnte hier im Thread von DS_Starter vorgeschlagene sub eine Methode 3 bringen ( Antwort #634 am: 14 September 2019, 21:39:25 )
Ich hatte die Tage mir einen Fehler in eines meiner Module gebaut der den hash dieses Device hat zyklisch kräftig wachsen lassen.
U.a. habe ich zum Thema Speicherplatz von Perl Variablen dies gefunden :
ZitatPerl vergrößert einen Hash schrittweise auf 8, 16, 32, 64, ... Elemente. D.h. wird das 8. Element zugewiesen, vergößert Perl intern auf 16 Elemente usw. Für jeden Key alloziert Perl vorab einen Pointer (4 Bytes). Zusätzlich kommt mit zunehmender Anzahl Buckets ein wachsender Overhead von 9, 10, 11, ... Bytes je Key hinzu. Die Größe des Key geht auch mit ein.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Christoph Morrison am 19 November 2020, 20:46:40
Zitat von: Wzut am 19 November 2020, 20:07:06
vllt, könnte hier im Thread von DS_Starter vorgeschlagene sub eine Methode 3 bringen ( Antwort #634 am: 14 September 2019, 21:39:25 )

(Einfach auf den Titel eines Postings klicken, dann springt man direkt zu ihm und kann es auch direkt verlinken: Posting #634 (https://forum.fhem.de/index.php/topic,84372.msg974569.html#msg974569))
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 20 November 2020, 14:14:10
So, das presence.sh hab ich erstmal rausgeschmissen und mir analyzeObject eingerichtet. Nach etwas Recherche hier im Forum bin ich noch auf eine Option innodb_buffer_pool_size=128M in der (/etc/mysql/mariadb.conf.d/50-server.cnf) gestoßen. Läuft seit heute morgen...

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  812 fhem      20   0  220864 175256  12556 S   3,6  18,8   8:31.17 perl
1372 fhem      20   0  167592 113284   3800 S   0,0  12,1   0:04.90 perl
  605 mysql     20   0  731600  94536  15760 S   0,0  10,1   0:21.38 mysqld
1173 pi        20   0  307844  58132  44872 S   0,0   6,2   0:02.49 zenity


mysql steht stabil bei 10%. Aber der erste Prozess von fhem steigt stetig, zwar nicht mehr so schnell, wie vorher, aber dennoch.

Hier mal die derzeit größten averages die apptime anzeigt
name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
HA.Sven.Off                              notify_Exec                          20124        3   20124.50  6708.17     0.00     0.00 20.11. 14:06:26 HASH(HA.Sven.Off); HASH(Smartphone_Sven)
HA.Sven                                  dummy_Set                            20118        2   40199.01 20099.51     0.00     0.00 20.11. 14:06:26 HASH(HA.Sven); HA.Sven; off
HA.Sven.Off.PushNotify                   notify_Exec                          20088        2   20088.83 10044.41     0.00     0.00 20.11. 14:06:26 HASH(HA.Sven.Off.PushNotify); HASH(HA.Sven)
PushMessenger                            Pushover_Set                         20084        2   40144.47 20072.24     0.00     0.00 20.11. 14:06:26 HASH(PushMessenger); PushMessenger; msg; 'Anwesenheit'; 'Sven/Handy; hat; das; Haus; verlassen.'; ''; 0; ''
HA.Sven.On                               notify_Exec                          20082        3   20082.79  6694.26     0.00     0.00 20.11. 14:09:15 HASH(HA.Sven.On); HASH(Smartphone_Sven)
tmr-GetUpdate                            update                               20064      176  224591.89  1276.09 106302.70  3580.65 20.11. 13:58:41 update:TV_Programme
HA.Sven.On.PushNotify                    notify_Exec                          20061        2   20062.13 10031.06     0.00     0.00 20.11. 14:09:15 HASH(HA.Sven.On.PushNotify); HASH(HA.Sven)


analyzeObject - check object $defs{HA.Sven} type: HASH
analyzeObject - Data::Peek deep: 0 -> analyzed $defs{HA.Sven} (type: HASH):
SV = IV(0x28a0448) at 0x28a0448
  REFCNT = 1
  FLAGS = (ROK)
  RV = 0x690de60

analyzeObject - Devel::Size -> total size object $defs{HA.Sven} (type: HASH): 2971 Bytes
analyzeObject - checked .attraggr (type: ARRAY): 44 Bytes
analyzeObject - checked .eventMapCmd (type: PV): 42 Bytes
analyzeObject - checked NAME (type: PV): 42 Bytes
analyzeObject - checked NR (type: PV): 50 Bytes
analyzeObject - checked helper (type: HASH): 1231 Bytes
analyzeObject - checked TYPE (type: PV): 42 Bytes
analyzeObject - checked .attreocr (type: ARRAY): 102 Bytes
analyzeObject - checked .attrminint (type: ARRAY): 44 Bytes
analyzeObject - checked FUUID (type: PV): 74 Bytes
analyzeObject - checked READINGS (type: HASH): 461 Bytes
analyzeObject - checked STATE (type: PV): 66 Bytes


analyzeObject - check object $defs{PushMessenger} type: HASH
analyzeObject - Data::Peek deep: 0 -> analyzed $defs{PushMessenger} (type: HASH):
SV = IV(0x28a0448) at 0x28a0448
  REFCNT = 1
  FLAGS = (ROK)
  RV = 0x25d3d68

analyzeObject - Devel::Size -> total size object $defs{PushMessenger} (type: HASH): 9239 Bytes
analyzeObject - checked TYPE (type: PV): 42 Bytes
analyzeObject - checked FVERSION (type: PV): 80 Bytes
analyzeObject - checked .FhemMetaInternals (type: PV): 24 Bytes
analyzeObject - checked .attrminint (type: ARRAY): 44 Bytes
analyzeObject - checked .attraggr (type: ARRAY): 44 Bytes
analyzeObject - checked NAME (type: PV): 47 Bytes
analyzeObject - checked NR (type: PV): 50 Bytes
analyzeObject - checked USER_KEY (type: PV): 64 Bytes
analyzeObject - checked helper (type: HASH): 1794 Bytes
analyzeObject - checked APP_TOKEN (type: PV): 64 Bytes
analyzeObject - checked FUUID (type: PV): 74 Bytes
analyzeObject - checked READINGS (type: HASH): 5617 Bytes
analyzeObject - checked STATE (type: PV): 70 Bytes
analyzeObject - checked VALIDATION_TIMER (type: PV): 76 Bytes
analyzeObject - checked DEF (type: PV): 95 Bytes
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 20 November 2020, 14:32:32
Würde mal sagen da ist noch nichts aufregendes zu sehen.
Am Besten gehst du ein Device nach dem anderen durch (nicht jedes notify oder at).

Z.B. (in Klammern steht der Devicename):

{ analyzeObject("CamHE1") }

Willst du tiefer rein gehen, setzt du ein oder mehrere Unterobjekte mit Leerzeichen dahinter:
{ analyzeObject("CamHE1 HELPER .SNAPHASH") }

Du kannst es dir auch vereinfachen, indem du einen Modultyp angibst, z.B.:
{ analyzeObject("TYPE=SSCam") }

Manche Typen kann man nicht untersuchen (siehe den angegebenen Post).

Wenn du auf verdächtig große Datenmangen stößt, beobachte ob sie permanent wachsen. Das wäre dann ein Ansatz.
Vielleicht hilft das Vorgehen, auch wenn es zeitraubend ist.

Grüße,
Heiko
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 20 November 2020, 14:42:32
ZitatWürde mal sagen da ist noch nichts aufregendes zu sehen.

Ich habe mal hier irgendwo gelesen, wenn bei apptime der average größer 1000 ist, sollte man der Sache nachgehen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 20 November 2020, 14:44:55
Mit apptime misst man im Prinzip das Antwortzeitverhalten des Systems bzw. mögliche Blockierungen.
Du brauchst aber Hinweise für ein Speicherwachstum bei dir. Da hilft dir apptime wenig ... andere Baustelle für einen anderen Zweck Sachverhalt.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: mumpitzstuff am 20 November 2020, 22:34:14
Ich würde mit den Dingen beginnen, die relativ häufig aufgerufen werden. Es ist relativ unwahrscheinlich das etwas die Ursache ist, das nur 2-3 Mal ausgeführt wurde. Wenn das der Fall ist, müsste dein Speicheranstieg relativ starke Stufen aufweisen, die man sehen würde, wenn man relativ häufig den Speicher Wert erfasst.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: en-trust am 21 November 2020, 23:39:39
Hab jetzt seit heute Morgen konstante 385Mb Speicherverbrauch.
Gelöscht habe ich das TVProgramm Device. Darüber hinaus habe ich den Kernel von 7 auf 8 aktualisiert. Ob das aber einen positiven Einfluss hat...
Ich beobachte mal weiter.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: W_Esch am 12 Dezember 2020, 14:14:31
Hallo zusammen,
Hatte auch seit zwei Monaten das Problem mit Memorywachstum. Habe das Modul frezemon, welches inaktiv war, heute aus der config gelöscht. Nach dem Neustart ist der Speicherverbrauch konstant. 
Das war die Lösung. Da mein System 8GB Memory hat ist mir erst gestern das System stehen geblieben. Ein durchforsten der Logs hat gezeigt, dass das Problem seit ca. 4 Wochen existierte.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: vknie am 17 Dezember 2020, 19:58:11
Hallo zusammen,

ich hatte bis eben auch das Problem mit dem Memory-Schwund und den halben Thread bis zum Ende durchgelesen.
Ausgerechnet im derzeit letzten Beitrag von W_Esch steht auch für mich die Lösung und auch der Verlauf war in etwa identisch.
Auch bei mir war das Modul inaktiv, aber eben doch sehr zerstörerisch. Damit rechnet man ja eigentlich nicht.
Hätte ich von einem "inaktiven" Modul nicht erwartet. Muss man mit sowas auch bei "disabled" rechnen.
Danke W_Esch für den Hinweis. 

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: scooty am 18 Dezember 2020, 18:04:20
Und noch eine Kombination, die zu Speicherwachstum führt (zumindest auf meinem System):
Dann kommt so etwas dabei raus:
s. Bild

Rasantes Wachstum der Speicherbelegung, unterbrochen durch Restarts von FHEM im Rahmen meiner Fehlersuche.

Viele Grüße,
Andreas
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 18 Dezember 2020, 20:53:31
Kannst Du bitte im Problemfall die Ausgabe von "list -r TYPE=MQTT2_SERVER" und "list TYPE=MQTT2_DEVIECE" hier anhaengen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CQuadrat am 18 Dezember 2020, 22:41:55
Ich hatte das Problem mit wachsendem Speicherverbrauch seit dem Frühjahr auch. Jetzt habe ich das hie gelesen und vorhin (ca 18:00) mein (deaktiviertes) freezmon gelöscht. Hier das Resultat:
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CQuadrat am 18 Dezember 2020, 22:44:39
So sah es vorher aus. Mit regelmäßigen fhem-Restarts bei den Maxima.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 18 Dezember 2020, 23:20:10
Ich habe freezemon auf 2 Systemen ohne Probleme laufen...

Auf einem System aber erst keine Speicherprobleme mehr nachdem ich fhem und auch das OS von Stretch auf Buster upgedatet habe...

Wobei es lange Zeit auch auf Stretch ohne Probleme lief.
Aber irgendein OS-Update (von Stretch) dann "plötzlich" zu Speicherproblemen geführt hat...

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CQuadrat am 19 Dezember 2020, 10:52:45
Und so sieht es jetzt aus -> Problem scheint gelöst  :)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 19 Dezember 2020, 11:35:19
Was ist das für eine Überwachung? Nach einem FHEM Grafen sieht es nicht aus ....
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: CQuadrat am 19 Dezember 2020, 13:01:43
Mein Fhem läuft auf meinem NAS, das mit Openmediavault betrieben wird. Die Statistik/Grafik stammt daraus.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: scooty am 20 Dezember 2020, 11:23:44
Zitat von: rudolfkoenig am 18 Dezember 2020, 20:53:31
Kannst Du bitte im Problemfall die Ausgabe von "list -r TYPE=MQTT2_SERVER" und "list TYPE=MQTT2_DEVIECE" hier anhaengen?

Hallo Rudolf,

gerne.
Habe gestern zum Test die MQTT2-Übertragung durch die FULLY-App auf den Tablets wieder aktiviert.
Seit dem wieder Speicheranstieg, wenn auch nicht so dramatisch wie die Wochen vorher (s. Bild).

Hier die gewünschten lists:
MQTT2-Server:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server group IO_Devs
attr MQTT2_FHEM_Server room Global

setstate MQTT2_FHEM_Server 2020-12-20 11:02:31 RETAIN {"fully/deviceInfo/1f1df430-2b4174b4":"{\u0022topFragmentTag\u0022:\u0022\u0022,\u0022displayHeightPixels\u0022:800,\u0022isInDaydream\u0022:false,\u0022startUrl\u0022:\u0022http://192.168.0.156:8083/fhem/www/tablet/KUEG_AM_Tablet01.html\u0022,\u0022altitude\u0022:130.12354676056142,\u0022SDK\u0022:19,\u0022maintenanceMode\u0022:false,\u0022sensorInfo\u0022:[],\u0022deviceName\u0022:\u0022B1-810\u0022,\u0022keyguardLocked\u0022:true,\u0022appUsedMemory\u0022:12261752,\u0022batteryLevel\u0022:22,\u0022longitude\u0022:7.130617652045808,\u0022isLicensed\u0022:true,\u0022isMobileDataEnabled\u0022:true,\u0022foreground\u0022:\u0022de.ozerov.fully\u0022,\u0022deviceId\u0022:\u00221f1df430-2b4174b4\u0022,\u0022isMenuOpen\u0022:false,\u0022ip4\u0022:\u0022192.168.0.136\u0022,\u0022ip6\u0022:\u0022FE80::227C:8FFF:FEE2:4C0\u0022,\u0022ramUsedMemory\u0022:630566912,\u0022appTotalMemory\u0022:201326592,\u0022currentPageUrl\u0022:\u0022http://192.168.0.156:8083/fhem/www/tablet/KUEG_AM_Tablet01.html\u0022,\u0022isDeviceOwner\u0022:false,\u0022ramFreeMemory\u0022:296955904,\u0022Mac\u0022:\u002220:7c:8f:e2:04:c0\u0022,\u0022mqttConnected\u0022:true,\u0022manufacturer\u0022:\u0022Acer\u0022,\u0022plugged\u0022:true,\u0022latitude\u0022:50.82140984790043,\u0022isRooted\u0022:false,\u0022motionDetectorStatus\u0022:2,\u0022batteryTemperature\u0022:27,\u0022model\u0022:\u0022B1-810\u0022,\u0022screenOn\u0022:false,\u0022locale\u0022:\u0022de_DE\u0022,\u0022versionCode\u0022:875,\u0022build\u0022:\u0022Acer_AV0K0_B1-810_1.014.00_WW_GEN1\u0022,\u0022ramTotalMemory\u0022:927522816,\u0022kioskMode\u0022:false,\u0022version\u0022:\u00221.42.5\u0022,\u0022internalStorageTotalSpace\u0022:11549261824,\u0022hostname6\u0022:\u0022fe80::227c:8fff:fee2:4c0%wlan0\u0022,\u0022hostname4\u0022:\u0022KUEG-Tablet01.fritz.box\u0022,\u0022wifiSignalLevel\u0022:7,\u0022androidVersion\u0022:\u00224.4.4\u0022,\u0022isPlugged\u0022:true,\u0022isInForcedSleep\u0022:false,\u0022screenOrientation\u0022:90,\u0022isDeviceAdmin\u0022:true,\u0022appStartTime\u0022:\u002218.12.2020 14:09:18\u0022,\u0022displayWidthPixels\u0022:1280,\u0022currentTabIndex\u0022:0,\u0022locationProvide\u0022:\u0022gps\u0022,\u0022screenBrightness\u0022:106,\u0022SSID\u0022:\u0022\u005c\u0022HYAKNET\u005c\u0022\u0022,\u0022kioskLocked\u0022:false,\u0022appFreeMemory\u0022:189064784,\u0022isInScreensaver\u0022:false,\u0022internalStorageFreeSpace\u0022:1056931840,\u0022webviewUA\u0022:\u0022Mozilla/5.0 (Linux;; Android 4.4.4;; B1-810 Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 Safari/537.36\u0022,\u0022serial\u0022:\u002245240683569\u0022,\u0022screenLocked\u0022:true}","fully/deviceInfo/57eedf5d-b53c8259":"{\u0022deviceId\u0022:\u002257eedf5d-b53c8259\u0022,\u0022deviceName\u0022:\u0022SZOG_TABLET01\u0022,\u0022batteryLevel\u0022:59,\u0022isPlugged\u0022:false,\u0022SSID\u0022:\u0022\u005c\u0022HYAKNET\u005c\u0022\u0022,\u0022Mac\u0022:\u002278:e1:03:ae:23:91\u0022,\u0022ip4\u0022:\u0022192.168.0.172\u0022,\u0022ip6\u0022:\u0022FE80::7AE1:3FF:FEAE:2391\u0022,\u0022hostname4\u0022:\u0022SZOG-Tablet01.fritz.box\u0022,\u0022hostname6\u0022:\u0022fe80::7ae1:3ff:feae:2391%wlan0\u0022,\u0022wifiSignalLevel\u0022:4,\u0022isMobileDataEnabled\u0022:false,\u0022screenOrientation\u0022:90,\u0022screenBrightness\u0022:0,\u0022screenLocked\u0022:false,\u0022screenOn\u0022:true,\u0022batteryTemperature\u0022:21,\u0022plugged\u0022:false,\u0022keyguardLocked\u0022:false,\u0022locale\u0022:\u0022de_DE\u0022,\u0022serial\u0022:\u0022G0W0MA07729705HF\u0022,\u0022version\u0022:\u00221.42.4-fire\u0022,\u0022versionCode\u0022:100866,\u0022build\u0022:\u0022LVY48F\u0022,\u0022model\u0022:\u0022KFAUWI\u0022,\u0022manufacturer\u0022:\u0022Amazon\u0022,\u0022androidVersion\u0022:\u00225.1.1\u0022,\u0022SDK\u0022:22,\u0022webviewUA\u0022:\u0022Mozilla/5.0 (Linux;; Android 5.1.1;; KFAUWI Build/LVY48F;; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/84.0.4147.125 Safari/537.36\u0022,\u0022foreground\u0022:\u0022de.ozerov.fully\u0022,\u0022motionDetectorStatus\u0022:2,\u0022isDeviceAdmin\u0022:true,\u0022isDeviceOwner\u0022:false,\u0022internalStorageFreeSpace\u0022:1167949824,\u0022internalStorageTotalSpace\u0022:6045392896,\u0022externalStorageFreeSpace\u0022:3960471552,\u0022externalStorageTotalSpace\u0022:3972005888,\u0022ramUsedMemory\u0022:695414784,\u0022ramFreeMemory\u0022:238694400,\u0022ramTotalMemory\u0022:934109184,\u0022appUsedMemory\u0022:13069946,\u0022appFreeMemory\u0022:87593302,\u0022appTotalMemory\u0022:100663296,\u0022displayHeightPixels\u0022:600,\u0022displayWidthPixels\u0022:1024,\u0022isMenuOpen\u0022:false,\u0022topFragmentTag\u0022:\u0022\u0022,\u0022isInDaydream\u0022:false,\u0022appStartTime\u0022:\u002218.12.2020 5:40:09 nachm.\u0022,\u0022isRooted\u0022:false,\u0022isLicensed\u0022:true,\u0022isInScreensaver\u0022:true,\u0022kioskLocked\u0022:false,\u0022isInForcedSleep\u0022:false,\u0022maintenanceMode\u0022:false,\u0022kioskMode\u0022:false,\u0022startUrl\u0022:\u0022http://192.168.0.156:8083/fhem/tablet/SZOG_AM_Tablet01.html\u0022,\u0022currentTabIndex\u0022:0,\u0022mqttConnected\u0022:true,\u0022currentPageUrl\u0022:\u0022http://192.168.0.156:8083/fhem/tablet/SZOG_AM_Tablet01.html\u0022,\u0022sensorInfo\u0022:[]}","fully/deviceInfo/a17cf0e9-4d10a267":"{\u0022deviceId\u0022:\u0022a17cf0e9-4d10a267\u0022,\u0022deviceName\u0022:\u0022KUOG_Tablet01\u0022,\u0022batteryLevel\u0022:56,\u0022isPlugged\u0022:false,\u0022SSID\u0022:\u0022\u005c\u0022HYAKNET\u005c\u0022\u0022,\u0022Mac\u0022:\u002218:74:2e:a5:eb:0e\u0022,\u0022ip4\u0022:\u0022192.168.0.168\u0022,\u0022ip6\u0022:\u0022FE80::1874:2EFF:FEA5:EB0E\u0022,\u0022hostname4\u0022:\u0022KUOG-Tablet01.fritz.box\u0022,\u0022hostname6\u0022:\u0022fe80::1874:2eff:fea5:eb0e%p2p0\u0022,\u0022wifiSignalLevel\u0022:4,\u0022isMobileDataEnabled\u0022:false,\u0022screenOrientation\u0022:90,\u0022screenBrightness\u0022:0,\u0022screenLocked\u0022:false,\u0022screenOn\u0022:true,\u0022batteryTemperature\u0022:26,\u0022plugged\u0022:false,\u0022keyguardLocked\u0022:false,\u0022locale\u0022:\u0022de_DE\u0022,\u0022serial\u0022:\u0022G090MJ0572720W08\u0022,\u0022version\u0022:\u00221.42.4-fire\u0022,\u0022versionCode\u0022:100866,\u0022build\u0022:\u0022LVY48F\u0022,\u0022model\u0022:\u0022KFDOWI\u0022,\u0022manufacturer\u0022:\u0022Amazon\u0022,\u0022androidVersion\u0022:\u00225.1.1\u0022,\u0022SDK\u0022:22,\u0022webviewUA\u0022:\u0022Mozilla/5.0 (Linux;; Android 5.1.1;; KFDOWI Build/LVY48F;; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/70.0.3538.110 Safari/537.36\u0022,\u0022foreground\u0022:\u0022de.ozerov.fully\u0022,\u0022motionDetectorStatus\u0022:2,\u0022isDeviceAdmin\u0022:true,\u0022isDeviceOwner\u0022:false,\u0022internalStorageFreeSpace\u0022:22885552128,\u0022internalStorageTotalSpace\u0022:28432666624,\u0022externalStorageFreeSpace\u0022:63776096256,\u0022externalStorageTotalSpace\u0022:63831015424,\u0022ramUsedMemory\u0022:1052565504,\u0022ramFreeMemory\u0022:387846144,\u0022ramTotalMemory\u0022:1440411648,\u0022appUsedMemory\u0022:15642188,\u0022appFreeMemory\u0022:118575492,\u0022appTotalMemory\u0022:134217728,\u0022displayHeightPixels\u0022:800,\u0022displayWidthPixels\u0022:1280,\u0022isMenuOpen\u0022:false,\u0022topFragmentTag\u0022:\u0022\u0022,\u0022isInDaydream\u0022:false,\u0022appStartTime\u0022:\u002219.12.2020 11:21:53 nachm.\u0022,\u0022isRooted\u0022:false,\u0022isLicensed\u0022:true,\u0022isInScreensaver\u0022:true,\u0022kioskLocked\u0022:false,\u0022isInForcedSleep\u0022:false,\u0022maintenanceMode\u0022:false,\u0022kioskMode\u0022:false,\u0022startUrl\u0022:\u0022http://192.168.0.156:8083/fhem/tablet/KUOG_AM_Tablet01.html\u0022,\u0022currentTabIndex\u0022:0,\u0022mqttConnected\u0022:true,\u0022currentPageUrl\u0022:\u0022http://192.168.0.156:8083/fhem/tablet/KUOG_AM_Tablet01.html\u0022,\u0022sensorInfo\u0022:[{\u0022type\u0022:8,\u0022name\u0022:\u0022PROXIMITY\u0022,\u0022vendor\u0022:\u0022MTK\u0022,\u0022version\u0022:1,\u0022accuracy\u0022:-1},{\u0022type\u0022:5,\u0022name\u0022:\u0022LIGHT\u0022,\u0022vendor\u0022:\u0022MTK\u0022,\u0022version\u0022:1,\u0022accuracy\u0022:3,\u0022values\u0022:[138,0,0],\u0022lastValuesTime\u0022:1608458527704,\u0022lastAccuracyTime\u0022:1608416514268}]}","fully/deviceInfo/c116af5d-1a03be9b":"{\u0022deviceId\u0022:\u0022c116af5d-1a03be9b\u0022,\u0022deviceName\u0022:\u0022XXDG_Tablet01\u0022,\u0022altitude\u0022:77.61830139160156,\u0022longitude\u0022:7.130436779991811,\u0022latitude\u0022:50.82118053915346,\u0022locationProvide\u0022:\u0022gps\u0022,\u0022batteryLevel\u0022:81,\u0022isPlugged\u0022:false,\u0022SSID\u0022:\u0022\u005c\u0022HYAKNET\u005c\u0022\u0022,\u0022Mac\u0022:\u0022D8:5B:2A:A6:2B:2F\u0022,\u0022ip4\u0022:\u0022192.168.0.126\u0022,\u0022ip6\u0022:\u00222003:DC:7F2F:7000:68D6:297:7E4A:5A50\u0022,\u0022hostname4\u0022:\u0022XXDG-Tablet01.fritz.box\u0022,\u0022hostname6\u0022:\u00222003:dc:7f2f:7000:68d6:297:7e4a:5a50%14\u0022,\u0022wifiSignalLevel\u0022:0,\u0022isMobileDataEnabled\u0022:false,\u0022screenOrientation\u0022:270,\u0022screenBrightness\u0022:53,\u0022screenLocked\u0022:true,\u0022screenOn\u0022:false,\u0022batteryTemperature\u0022:22,\u0022plugged\u0022:false,\u0022keyguardLocked\u0022:true,\u0022locale\u0022:\u0022de_DE\u0022,\u0022serial\u0022:\u002252034eaefe3c9385\u0022,\u0022version\u0022:\u00221.42.5\u0022,\u0022versionCode\u0022:875,\u0022build\u0022:\u0022ULTRA LEAN ROM FOR T580 WIFI\u0022,\u0022model\u0022:\u0022SM-T580\u0022,\u0022manufacturer\u0022:\u0022samsung\u0022,\u0022androidVersion\u0022:\u00226.0.1\u0022,\u0022SDK\u0022:23,\u0022webviewUA\u0022:\u0022Mozilla/5.0 (Linux;; Android 6.0.1;; SM-T580 Build/MMB29K;; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/87.0.4280.101 Safari/537.36\u0022,\u0022foreground\u0022:\u0022de.ozerov.fully\u0022,\u0022motionDetectorStatus\u0022:2,\u0022isDeviceAdmin\u0022:true,\u0022isDeviceOwner\u0022:false,\u0022internalStorageFreeSpace\u0022:7159463936,\u0022internalStorageTotalSpace\u0022:11317514240,\u0022ramUsedMemory\u0022:996311040,\u0022ramFreeMemory\u0022:1043574784,\u0022ramTotalMemory\u0022:2039885824,\u0022appUsedMemory\u0022:13339728,\u0022appFreeMemory\u0022:120878000,\u0022appTotalMemory\u0022:134217728,\u0022displayHeightPixels\u0022:1200,\u0022displayWidthPixels\u0022:1920,\u0022isMenuOpen\u0022:false,\u0022topFragmentTag\u0022:\u0022\u0022,\u0022isInDaydream\u0022:false,\u0022appStartTime\u0022:\u002218.12.20 17:09:44\u0022,\u0022isRooted\u0022:false,\u0022isLicensed\u0022:true,\u0022isInScreensaver\u0022:false,\u0022kioskLocked\u0022:false,\u0022isInForcedSleep\u0022:false,\u0022maintenanceMode\u0022:false,\u0022kioskMode\u0022:false,\u0022startUrl\u0022:\u0022http://192.168.0.156:8083/fhem/www/tablet/XXDG_Tablet01_index.html\u0022,\u0022currentTabIndex\u0022:0,\u0022mqttConnected\u0022:true,\u0022currentPageUrl\u0022:\u0022http://192.168.0.156:8083/fhem/www/tablet/XXDG_Tablet01_index.html\u0022,\u0022sensorInfo\u0022:[{\u0022type\u0022:5,\u0022name\u0022:\u0022CM3323E Light Sensor\u0022,\u0022vendor\u0022:\u0022Capella Microsystems, Inc.\u0022,\u0022version\u0022:1,\u0022accuracy\u0022:-1,\u0022values\u0022:[7,4315,0],\u0022lastValuesTime\u0022:1608458525558,\u0022lastAccuracyTime\u0022:-1}]}","fully/deviceInfo/dd972e4-774a5b19":"{\u0022deviceId\u0022:\u0022dd972e4-774a5b19\u0022,\u0022deviceName\u0022:\u0022ATablet06\u0022,\u0022altitude\u0022:92.2540717581287,\u0022longitude\u0022:7.130413189568813,\u0022latitude\u0022:50.82105270346202,\u0022locationProvide\u0022:\u0022gps\u0022,\u0022batteryLevel\u0022:85,\u0022isPlugged\u0022:false,\u0022SSID\u0022:\u0022\u005c\u0022HYAKNET\u005c\u0022\u0022,\u0022Mac\u0022:\u00220C:70:4A:59:89:F4\u0022,\u0022ip4\u0022:\u0022192.168.0.116\u0022,\u0022ip6\u0022:\u0022FE80::D76C:E8A6:EC38:D64\u0022,\u0022hostname4\u0022:\u0022ATablet06.fritz.box\u0022,\u0022hostname6\u0022:\u0022fe80::d76c:e8a6:ec38:d64%wlan0\u0022,\u0022wifiSignalLevel\u0022:8,\u0022isMobileDataEnabled\u0022:true,\u0022screenOrientation\u0022:90,\u0022screenBrightness\u0022:11,\u0022screenLocked\u0022:true,\u0022screenOn\u0022:false,\u0022batteryTemperature\u0022:21,\u0022plugged\u0022:false,\u0022keyguardLocked\u0022:true,\u0022locale\u0022:\u0022de_DE\u0022,\u0022serial\u0022:\u0022unknown\u0022,\u0022version\u0022:\u00221.42.5\u0022,\u0022versionCode\u0022:875,\u0022build\u0022:\u0022CMR-W09 9.1.0.335(C432E5R1P3)\u0022,\u0022model\u0022:\u0022CMR-W09\u0022,\u0022manufacturer\u0022:\u0022HUAWEI\u0022,\u0022androidVersion\u0022:\u00229\u0022,\u0022SDK\u0022:28,\u0022webviewUA\u0022:\u0022Mozilla/5.0 (Linux;; Android 9;; CMR-W09 Build/HUAWEICMR-W09;; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/87.0.4280.101 Safari/537.36\u0022,\u0022foreground\u0022:\u0022com.android.chrome\u0022,\u0022foregroundActivity\u0022:\u0022com.android.chrome/org.chromium.chrome.browser.ChromeTabbedActivity\u0022,\u0022motionDetectorStatus\u0022:0,\u0022isDeviceAdmin\u0022:true,\u0022isDeviceOwner\u0022:false,\u0022internalStorageFreeSpace\u0022:20059983872,\u0022internalStorageTotalSpace\u0022:55090069504,\u0022ramUsedMemory\u0022:2684473344,\u0022ramFreeMemory\u0022:1368399872,\u0022ramTotalMemory\u0022:4052873216,\u0022appUsedMemory\u0022:6707904,\u0022appFreeMemory\u0022:395945280,\u0022appTotalMemory\u0022:402653184,\u0022displayHeightPixels\u0022:1600,\u0022displayWidthPixels\u0022:2560,\u0022isMenuOpen\u0022:false,\u0022topFragmentTag\u0022:\u0022\u0022,\u0022isInDaydream\u0022:false,\u0022appStartTime\u0022:\u002218.12.20 14:06:00\u0022,\u0022isRooted\u0022:false,\u0022isLicensed\u0022:true,\u0022isInScreensaver\u0022:false,\u0022kioskLocked\u0022:false,\u0022isInForcedSleep\u0022:false,\u0022maintenanceMode\u0022:false,\u0022kioskMode\u0022:false,\u0022startUrl\u0022:\u0022http://forum.micro-roadster.de\u0022,\u0022currentTabIndex\u0022:0,\u0022mqttConnected\u0022:true,\u0022currentPageUrl\u0022:\u0022https://www.micro-roadster.de/wbb/\u0022,\u0022sensorInfo\u0022:[{\u0022type\u0022:5,\u0022name\u0022:\u0022als-bh1745\u0022,\u0022vendor\u0022:\u0022rohm\u0022,\u0022version\u0022:1,\u0022accuracy\u0022:-1,\u0022values\u0022:[39,3579,5],\u0022lastValuesTime\u0022:1608458540884,\u0022lastAccuracyTime\u0022:-1}]}"}
setstate MQTT2_FHEM_Server 2020-12-19 12:40:41 lastPublish fully/deviceInfo/dd972e4-774a5b19:
setstate MQTT2_FHEM_Server 2020-12-20 11:02:29 nrclients 5
setstate MQTT2_FHEM_Server 2020-12-19 13:43:58 state Initialized


list TYPE=MQTT2_DEVICE:
GTEG_SENW
MQTT2_KUEG_TABLET01_FULLY
MQTT2_KUOG_TABLET01_FULLY
MQTT2_SZOG_TABLET01_FULLY
MQTT2_XXDG_TABLET01_FULLY
MQTT2_XXOG_ATABLET06_FULLY


Aber vielleicht meintest Du eher ein "list-r" eines der Tablets:
define MQTT2_XXDG_TABLET01_FULLY MQTT2_DEVICE XXDG_TABLET01_FULLY
attr MQTT2_XXDG_TABLET01_FULLY IODev MQTT2_FHEM_Server
attr MQTT2_XXDG_TABLET01_FULLY event-min-interval deviceId:180
attr MQTT2_XXDG_TABLET01_FULLY event-on-change-reading .*Memory:100000000,internalStorageFreeSpace:10000000,.*
attr MQTT2_XXDG_TABLET01_FULLY readingList XXDG_TABLET01_FULLY:fully/deviceInfo/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/screenOn/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/screenOff/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/pluggedAC/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/pluggedUSB/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/pluggedWireless/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/unplugged/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/networkReconnect/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/networkDisconnect/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/internetReconnect/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/internetDisconnect/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/powerOn/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/powerOff/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/showKeyboard/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/hideKeyboard/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/onMotion/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/onDarkness/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/onMovement/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/volumeUp/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/volumeDown/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/onQrScanCancelled/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/onBatteryLevelChanged/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/onScreensaverStart/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/onScreensaverStop/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }\
XXDG_TABLET01_FULLY:fully/event/mqttConnected/c116af5d-1a03be9b:.* { json2nameValue($EVENT) }
attr MQTT2_XXDG_TABLET01_FULLY room MQTT2_DEVICE
attr MQTT2_XXDG_TABLET01_FULLY stateFormat Last Update: lastUpdate
attr MQTT2_XXDG_TABLET01_FULLY userReadings lastUpdate:.* {\
   return ReadingsTimestamp($name, "deviceId", 0);;\
}

setstate MQTT2_XXDG_TABLET01_FULLY Last Update: 2020-12-20 11:18:42
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 Mac D8:5B:2A:A6:2B:2F
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 SDK 23
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 SSID "HYAKNET"
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 altitude 69.51599884033203
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 androidVersion 6.0.1
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 appFreeMemory 121239928
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 appStartTime 18.12.20 17:09:44
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 appTotalMemory 134217728
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 appUsedMemory 12977800
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 batteryLevel 81
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 batteryTemperature 22
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 build ULTRA LEAN ROM FOR T580 WIFI
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 currentPageUrl http://192.168.0.156:8083/fhem/www/tablet/XXDG_Tablet01_index.html
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 currentTabIndex 0
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 deviceId c116af5d-1a03be9b
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 deviceName XXDG_Tablet01
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 displayHeightPixels 1200
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 displayWidthPixels 1920
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 10:58:38 event onBatteryLevelChanged
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 foreground de.ozerov.fully
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 hostname4 XXDG-Tablet01.fritz.box
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 hostname6 2003:dc:7f2f:7000:68d6:297:7e4a:5a50%14
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 internalStorageFreeSpace 7159205888
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 internalStorageTotalSpace 11317514240
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 ip4 192.168.0.126
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 ip6 2003:DC:7F2F:7000:68D6:297:7E4A:5A50
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 isDeviceAdmin true
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 isDeviceOwner false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 isInDaydream false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 isInForcedSleep false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 isInScreensaver false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 isLicensed true
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 isMenuOpen false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 isMobileDataEnabled false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 isPlugged false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 isRooted false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 keyguardLocked true
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 kioskLocked false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 kioskMode false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 lastUpdate 2020-12-20 11:18:42
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 latitude 50.82115854853
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 10:58:38 level 81
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 locale de_DE
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 locationProvide gps
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 longitude 7.130559416597298
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 maintenanceMode false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 manufacturer samsung
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 model SM-T580
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 motionDetectorStatus 2
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 mqttConnected true
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 plugged false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 ramFreeMemory 1097011200
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 ramTotalMemory 2039885824
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 ramUsedMemory 942874624
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 screenBrightness 53
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 screenLocked true
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 screenOn false
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 screenOrientation 270
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 sensorInfo_1_accuracy -1
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 sensorInfo_1_lastAccuracyTime -1
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 sensorInfo_1_lastValuesTime 1608459522557
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 sensorInfo_1_name CM3323E Light Sensor
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 sensorInfo_1_type 5
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 sensorInfo_1_values_1 8
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 sensorInfo_1_values_2 4217
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 sensorInfo_1_values_3 0
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 sensorInfo_1_vendor Capella Microsystems, Inc.
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 sensorInfo_1_version 1
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 serial 52034eaefe3c9385
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 startUrl http://192.168.0.156:8083/fhem/www/tablet/XXDG_Tablet01_index.html
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 topFragmentTag
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 version 1.42.5
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 versionCode 875
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 webviewUA Mozilla/5.0 (Linux;; Android 6.0.1;; SM-T580 Build/MMB29K;; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/87.0.4280.101 Safari/537.36
setstate MQTT2_XXDG_TABLET01_FULLY 2020-12-20 11:18:42 wifiSignalLevel 0


Infos zur Implementierung von MQTT in der FULLY-App:
https://www.fully-kiosk.com/de/#mqtt (https://www.fully-kiosk.com/de/#mqtt)
Wobei der angegebene 60sec Abstand stark untertrieben ist, Messages kommen weit häufiger (eher 20 sec, sehr oft aber auch nur im Abstand von 3-4sec), daher die even-on-... Einstellungen an den MQTT2-Tablet-Devices.

Systeme ist mit:
Debian GNU/Linux 9.13 (stretch)
fhem.pl:23306/2020-12-07 perl:5.026000

Stehe für weitere Infos gerne zur Verfügung.

Vielen Dank und Grüße,
Andreas


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 20 Dezember 2020, 17:24:32
Leider keine relevante Idee.
Koenntest du bitte mit "attr MQTT2_FHEM_Server verbose 5" fuer 15-30 Minuten den MQTT-Verkehr mitschneiden, und die "MQTT2_FHEM_Server: dispatch autocreate=..." Zeilen mir hier (komprimiert) anhaengen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: scooty am 29 Dezember 2020, 09:40:49
Hallo Rudolf,

anbei die von Dir vorgeschlagenen Infos.
verbose 5 lief für ca. eine halbe Stunde, die Speicherbelegung erhöhte sich in diesem Zeitraum um ca. 50MB.

Hoffe, es hilft weiter?

Vielen Dank und Grüße,
Andreas
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 29 Dezember 2020, 11:42:32
Ich habe die Daten bei mir eingespielt, nachdem ich im JSON latitude:XX.X durch 00.0 ersetzt habe, sonst gibt es syntax Fehler.

Bei der ersten Variante habe ich die Daten via in perl gebauten Perl-Funktion eingelesen, und die Dispatch() Funktion in fhem.pl aufgerufen. Beim ersten Laden der Daten ist mein FHEM um ca 7.5MB gewachsen (es wurden 6 Geraete samt Readings und Attributen erzeugt), danach gar nicht mehr, obwohl ich die gleichen Daten noch 10-mal geladen habe.

Danach habe ich einen Shellskript gebaut, was die gleichen Zeilen per mosquitto_pub laedt: diesmal ist FHEM beim ersten mal 0.5MB gewachsen, danach (auch 10-mal geladen) nicht mehr. Dann noch ne Runde mit retain Flag: kein Unterschied, 0.5MB und dann konstant.

Den Unterschied der beiden Versionen von 7MB beim ersten Laden kann ich nicht erklaeren, vmtl. ist es ein Zufall bei der Alloc--Reihenfolge.


Ich folgere daraus, dass das Problem nicht direkt am fhem.pl, MQTT2_SERVER oder MQTT2_DEVICE Modul liegt, sondern entweder an der Perl Version (ich habe 5.32) oder an einem der anderen, indirekt getriggerten Module, wie freezemon, apptime, etc.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: scooty am 29 Dezember 2020, 12:35:20
Hallo Rudolf,

vielen Dank für Deine ausführliche Analyse und Ergebnisse.
Gut zu wissen, dass es nicht an MQTT2 liegt, werde dann 'mal versuchen, die anderen von Dir erwähnten Komponenten genauer anzuschauen.

Viele Grüße,
Andreas

PS:
Sorry für den Mehraufwand durch meine versuchte Anonymisierung der Daten, hast Recht, wenn man anonymisiert, sollte man schon der gleichen Datentyp verwenden.  :-[
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Lobot am 22 Januar 2021, 11:02:52
Hallo Leute!

Ich auch ein sich verschärfendes "Cannot fork" Problem durch sich schnell füllenden SWAP.

Kurzer Überblick über mein System:
- Raspberry A: Pi 3b+ mit Stretch als Haupt-System für zeitkritische Systeme der Hausautomation (Aktoren, Bewegungsmelder...)
- Raspberry B: Pi 3b mit Buster als Nebensystem für die Abfrage von Heizung, PV, Wetter, 1Wire, Telegram, usw... gekoppelt mit A via RFEHM
- bei beiden wird täglich nachts ein Backup von FHEM mit der angehängten backup.sh aus dem Forum auf mein NAS geschoben

Raspberry B hat schon immer das Problem, dass langsam der SWAP voll läuft, sodass ca. alle 14 Tage ein reboot nötig ist.

Raspberry A hatte seit Anfang 2020 kein Update für FHEM oder Betriebssystem bekommen (never change a running system...), da hat sich der SWAP so langsam gefüllt, dass das System nur alle 4-6 Wochen mal neu gestartet werden musste.

Nun dachte ich, dass es bei Raspberry A durchaus mal wieder Zeit für ein Update wird und habe Stretch und FHEM auf den neusten Stand gebracht.

Und seit dem Update läuft mir der 100mb swap innerhalb von 2-3 Tagen voll, trotz RAM Auslastung von 15-20% :o

Ich habe den Zustand des Speichers mit SYSMON über den Tag beobachtet. Nach Neustart blieb der swap den kompletten Tag bei 0,25mb.

Am nächsten Morgen dann die Überraschung: swap plötzlich bei 24mb  :o

Mein Verdacht viel daher auf die Backup-Routine über die backup.sh.

Diese habe ich dann zum Testen nochmal angestoßen und nach Abschluss war der swap auf 39mb gestiegen.

Beim Raspberry B unter Buster war der Anstieg des swap nach einem Backup etwas moderater von 27 auf 32mb (der lief schon länger).

Ich kann nun natürlich wieder das ein Jahr alte Backup wieder einspielen, aber ich würde doch lieber rausfinden, was da los ist, um mein System auf einem aktuellen Stand halten zu können.

Hat jemand eine Idee, was den Anstieg des swap in der Backup-Routine auslöst?

Ich freue mich auf eure Rückmeldung.

Martin
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 22 Januar 2021, 11:24:21
ZitatUnd seit dem Update läuft mir der 100mb swap innerhalb von 2-3 Tagen voll, trotz RAM Auslastung von 15-20% :o
Ist dein Problem, dass swap voll ist, oder dass FHEM nicht forken kann (wie im Betreff angesprochen)
Wenn Ersteres: swap entfernen, ich verwende seit ca 20 Jahren kein swap mehr, es stoert nur.
Wenn Letzteres: ich habe keine einfache Loesung. Ich wuerde erst mehrere Perl Versionen ausprobieren (ganz alt, ganz neu), und dann ueber Binaersuche die benutzten FHEM-Module deaktivieren, bis das schuldige Modul gefunden wurde.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 22 Januar 2021, 11:25:49
Während das Script läuft, braucht der PI mehr speicher ... deshalb swapt er.

Optimierungsvorschläge:
Anstatt /opt/fhem/fhem.pl nc verwenden (Speichersparender), gibt genug Infos im Forum
tar ohne komprimierung (z)

Ansonsten könntest DU mal die Swappiness ändern
https://www.tecchannel.de/a/festplatten-fuer-linux-im-leistungs-check,3198536,2 (https://www.tecchannel.de/a/festplatten-fuer-linux-im-leistungs-check,3198536,2)

Edit:
Swap hat auch durchaus Vorteile ..... pauschal würde ich die Aussage "Swap Ausschalten" nicht so unterschreiben ....
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 06 März 2021, 09:16:03
Frage in die Runde.
War seit Anfang dabei bzgl. den Speicherproblemen und hatte damals mit perl >5.20 massive Probleme (auf meinem PI3, jetzt 4 mit damals stretch und jetzt buster).
Bin dann zurück auf Perl 5.20 und es läuft seitdem ohne Probleme. Im Anhang der Graph.

Irgendwie habe ich "schiss" davor (fhem hängt sich nach paar STunden immer auf, teilw. Nachts) das perl 5.20 endlich zu begraben und mein System auf eine aktuelle Perl Version hochzuziehen.

Wie ist eure Erfahrung mit buster und neuen perls?

Danke
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: tomcat.x am 06 März 2021, 11:49:15
Meine Erfahrung mit buster und Perl 5.28.1 sind gut. Aber die Speicher-Probleme waren halt auch immer sehr spezifisch. Bei mir war der Verursacher Freezemon in Verbindung mit apptime.

Viele Grüße
Thomas
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 06 März 2021, 16:58:01
Danke, werde jetzt mal das aktuelle 3.28 testen.
Hoffe es läuft gut.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 06 März 2021, 17:56:32
Danke, werde jetzt mal das aktuelle 3.28 testen.

Wenn Du 5.28 meinst: das ist zwei Jahre alt.
Aktuell waere 5.32.1 oder 5.33.6
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 06 März 2021, 17:58:34
Ja, genau  5.28.1.
Hmm, das hat er mir mit "sudo apt-get upgrade" gemacht!?

Sollte ich bei der bleiben oder (wie?) eine neuere installieren?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 06 März 2021, 18:11:17
ZitatSollte ich bei der bleiben oder (wie?) eine neuere installieren?
Wenn Du schon so fragst :), dann empfehle ich den buster-eigenen 5.28.1 zu nehmen.
Ansonsten gibt es perlbrew. Selbst zu uebersetzen erfordert auch keine tieferen Kenntnisse, hoechstens Geduld.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 06 März 2021, 18:21:41
Ahh ok, hatte das 5.20 mit perlbrew installiert.
Dachte es gibt für linux/debian ev. schon eine bessere Möglichkeit  ;)
Dann bleibe ich mal bei 5.28.1.

Danke
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Homalix99 am 21 März 2021, 19:14:52
Hallo,

heute ist es mir auch passiert. Ab 01:14 Uhr stand fhem fast still. Logfile mit der besagten Fehlermeldung  zugemüllt.
Stand: RPi 3 , Deb. stretch, perl (v5.24.1).
Perl VM Logsize chart nachgesehen. Speicherzuwachs ab 19.3., nach 15:00 Uhr konstant.
Was war passiert? Habe als Objekt einen 2. HM-CFG-LAN Adapter definiert, aber nicht angeschlossen, da dieser scheinbar defekt ist. Das Interface war die ganze Zeit auf "closed" und somit keine Probleme.
Nach einem Fhem Neustart (wegen einem anderen Thema), waren delays im fhem- Handling festzustellen.
Wenn das HMLAN Device nicht explizit disabled wird, verursacht es scheinbar delays => Massenweise Perfmon: possible freeze ... Meldungen mit delays von jeweils knapp 3 Sek.
Habe dann erstmal mit apptime nach dem Verursacher gesehen und dann war klar, dass es das HMLAN war. Das Interface des Teils dann mit set close geschlossen und die delays waren weg. Keine Perfmon Logeinträge mehr.
ABER: Seit dem Zeitpunkt wuchs der Speicherverbrauch des perl-Prozesses konstant an (siehe Anhang). Und heute nacht war es dann soweit. Nur ein RPi restart hilft da weiter.

Vielleicht ist das ein nützlicher Hinweis oder diese Art des Problems ist schon bekannt.

VG

Alex
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 21 März 2021, 19:24:13
Bei 5.24 hatte ich auch massive Speicherprobleme (damals stretch).
Nach downgrade auf 5.20 (perlbrew) lief die Kiste stabil wie nie.
Nach buster upgrade habe ich 5.20 belassen.
Bin grad am testen von 5.28 (auf buster), schaut soweit gut aus:

08.03 VM Akt 348.00
09.03 VM Akt 358.00
09.03 AB Akt  353.84
10.03 VM Akt 354.80
10.03 AB Akt  358.27
11.03 VM Akt 339.48
12.03 M   Akt 358.88
13.03 M   Akt 368.00
14.03 M   Akt 350.00
15.03 M   Akt 372.00
16.03 M   Akt 374.00
17.03 M   Akt 378.00
18.03 M   Akt 382.82
19.03 M   Akt 378.41

Schon ein Anstieg aber nicht so plötzlch bis zum bitteren Ende  ;)

Wenn du auf 5.20 willst, ist nicht trivial, hier eine Anleitung: https://forum.fhem.de/index.php/topic,84372.msg861586.html#msg861586
Das siwtchen zw. der aktuellen (vom OS) und perlbrew ist dann nur ein Eintrag im /etc/init.d/fhem services

pOpY
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Homalix99 am 21 März 2021, 22:12:08
Hi,
Ich weiß ja wie ich das Verhalten reproduzieren kann und es auch vermeiden.
Ziel ist die Umstellung auf ububtu 64 Bit in Docker Container.

Gruß
Alex
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 22 März 2021, 14:21:23
Imer Docker-Container hast Du den Vorteil  einfacher die perl-Version tauschen zu können ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: popy am 22 März 2021, 15:13:20
Das ist ja interessant, macht docker auf einem RPI4b mit 4GB Ram Sinn?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Homalix99 am 22 März 2021, 18:11:27
Habe ich so am Laufen, allerdings noch nicht mein Produktivsystem.
Für Fhem habe ich 3 Container, neben dem eigentlichen fhem noch Mariadb und MQTT. Aber noch nicht alles getestet.

Gruß

Alex
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 22 März 2021, 18:36:17
Also DB und Pi .. würde ich nicht so machen ...

Docker hat den Vorteil, die Software zu kapseln. Damit kannst Du im Docker andere Versionen als Außen fahren. Nachteil ist die erhöhte Komplexität und das verschieden Versionen von libarys parallel im Speicher gehalten werden müssen ...

Persönlich habe ich mich gegen den Pi entschieden, aber mein Hauptserver macht auch mehr als "nur" FHEM. Dort läuft aber (fast) alles in Docker. Habe nur beruflich auch viel mit Docker zu tuen.

Btw: Wenn Dir der Offizielle Container für FHEM in Docker nicht gefällt, da Du nur etwas "leichtes" brauchst, kann ich Dir gerne mein Docker-File geben ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Homalix99 am 22 März 2021, 18:58:25
Hallo,

bisher läuft fhem mit dem offiziellen image, kann aber theoretisch sein, dass es letztendlich vielleicht doch nicht so passt. Von da her wäre Dein Dockerfile evtl. eine Option.
Kannst mir ja per PM senden, wenn ok.

VG

Alex
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Tungsten am 23 März 2021, 12:49:32
Zitat von: Homalix99 am 21 März 2021, 19:14:52
Stand: RPi 3 , Deb. stretch, perl (v5.24.1).
Perl VM Logsize chart nachgesehen.


Habe das gleiche Setup und Problem.
Wie hast du nur den Perl Speicherverbrauch geloggt? Hast du mal ein define dafür?
Im Sysmon ist nur der Perl Speicher ja nicht enthalten.

Bringt ein Update von Stretch auf Buster etwas?


Danke Dir
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 23 März 2021, 13:15:26
Zitat von: Tungsten am 23 März 2021, 12:49:32

Bringt ein Update von Stretch auf Buster etwas?


Bei mir: ja!

ABER: wie du diesem (und weiteren) Thread(s) entnehmen kannst gibt es (wohl) nicht DIE Ursache für den Speicherzuwachs...
...daher auch (wohl) nicht DIE Lösung. :-\

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Homalix99 am 23 März 2021, 13:52:28
@Tungsten:
Zitat
Wie hast du nur den Perl Speicherverbrauch geloggt? Hast du mal ein define dafür?

Mein Def. Erzeugt eine Logdatei, welche über svg-Grafik visualisiert werden kann.

defmod a_pSize at +*00:05 {`echo \`date +"%Y-%m-%d_%H:%M:%S"\` size \`awk '/VmSize/{print \$2}' /proc/$$/status\` >> /opt/fhem/log/perlsize.log`}
attr a_pSize DbLogExclude .*
attr a_pSize comment Dient zum Loggen der Speichergröße vom perl Prozess (fhem)\
Logfile unter /opt/fhem/log/perlsize.log
attr a_pSize group Steuerung
attr a_pSize icon clock
attr a_pSize room System


Grafik:

defmod SVG_Fhem_VM SVG log_fhem_VM_size:SVG_log_fhem_VM_size_1:CURRENT
attr SVG_Fhem_VM DbLogExclude .*
attr SVG_Fhem_VM plotWeekStartDay 0
attr SVG_Fhem_VM room SVG
attr SVG_Fhem_VM sortby 08


chart im Anhang

Gruß

Alex
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Tungsten am 25 März 2021, 08:32:28
Hallo Zusammen,

ich habe jetzt auch mal angefangen den Speicherverbrauch mit zu loggen.

defmod a_pSize at +*00:05 {`echo \`date +"%Y-%m-%d_%H:%M:%S"\` size \`awk '/VmSize/{print \$2}' /proc/$$/status\` >> /opt/fhem/log/perlsize.log`}
attr a_pSize DbLogExclude .*
attr a_pSize comment Dient zum Loggen der Speichergröße vom perl Prozess (fhem)\
Logfile unter /opt/fhem/log/perlsize.log
attr a_pSize group Steuerung
attr a_pSize icon clock
attr a_pSize room System



Ist ja wirklich erschreckend wenn man das beobachtet...
Es hilft ein FHEM shutdown+restart.

Ich hätte folgende Fragen/Ideen.

Wäre es möglich im Sysmon den Perl Speicherverbrauch als Reading zu integrieren?
Dann hätte man ein Reading auf das man automatisch reagieren kann.

Wie kann man beitragen das Problem grundsätzlich einzugrenzen?
Es scheinen ja viele betroffen zu sein.

Perl Version ist auch bei mir v5.24.1 auf Pi3 mit Stretch.

Die RAM Speicherauslastung scheint konstant zu sein im gleichen Zeitraum.

Danke Euch!
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 25 März 2021, 09:04:39
Die Frage ist, ob Du den Speicherverbrauch von FHEM oder vom System loggst.

Es gibt einen gravierenden Unterschied von linux zu Windows: bei Windows wird nur der Speicherverbrauch der Programme angezeigt. bei Linux (und anderen "echten" Unixen) aber den incl. der Cache. Da der Cache aber dynamisch verwaltet wird, wenn mehr Speicher frei wird mehr geached, geht damit bei Unix-Systemen der Speicherverbrauch immer hoch. Auch wenn wenig Speicher gebraucht wird.

Wenn Du dagegen den Speicherverbrauch von FHEM (also des FHEM-Prozess) loggst, ist es dagegen aussagekräftig ....
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Tungsten am 25 März 2021, 09:11:31
Ich habe meinen Beitrag ergänzt, dass ich wie von Homalix99 vorgeschlagen logge.

Sollte dies ungeeignet sein, dann wäre ich für einen Hinweis und ein define zum richtigen Loggen ins DBlog dankbar.

Evtl hilft es ja das Problem einzugrenzen wenn möglichst viele vergleichbare Daten liefern.


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 25 März 2021, 09:26:28
ZitatWäre es möglich im Sysmon den Perl Speicherverbrauch als Reading zu integrieren?
Das bitte dem Sysmon Maintainer vortragen, am besten als Patch :)
Haette den Vorteil, dass frueher oder spaeter der richtige Verbrauch angezeigt wird.
Viele Anfaenger verwenden sowas wie free/used, was irrefuehrend ist.

ZitatWie kann man beitragen das Problem grundsätzlich einzugrenzen?
Alle verwendeten Module einzeln deaktivieren, und schauen, wann es aufhoert. Dann fuer das zuletzt deaktivierten Modul ein Thema im passenden Forumsbereich oeffnen. Wiederholen, bis alle Module wieder integriert sind, und kein Speicherzuwachs zu beobachten ist.

ZitatPerl Version ist auch bei mir v5.24.1 auf Pi3 mit Stretch.
5.24 ist bekannt fuer ein Speicherloch in der Regexp-Bibliothek.
Bevor ich mit der Prozedur im vorherigen Absatz anfangen wuerde, wuerde ich eine andere Perl-Version installieren, entweder durch OS-Upgrade oder durch perlbrew.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Tungsten am 25 März 2021, 09:44:58
Danke dir, somit überlasst ihr es dem Zufall und einzelnen Usern dem scheinbar generellen Problem individuell nachzugehen.

Kein Wunder dass der Beitrag letzte Woche 3. Geburtstag hatte und 60 Seiten lang ist, ohne eine Lösung zu haben.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Frank_Huber am 25 März 2021, 09:57:18
Zitat von: Tungsten am 25 März 2021, 09:44:58
Danke dir, somit überlasst ihr es dem Zufall und einzelnen Usern dem scheinbar generellen Problem individuell nachzugehen.

Kein Wunder dass der Beitrag letzte Woche 3. Geburtstag hatte und 60 Seiten lang ist, ohne eine Lösung zu haben.

Nein, es überlässt hier niemanden etwas dem Zufall.
Es gibt hier aber nicht DAS EINE Problem, es ist bei jedem Betroffenen individuell.
Denke Rudi hätte das längst gefixt wenn es so einfach wäre...
Aber jedes Problem ist anderst, so muss jeder für sich seine Ursache finden und beheben.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 25 März 2021, 10:12:11
ZitatDanke dir, somit überlasst ihr es dem Zufall und einzelnen Usern dem scheinbar generellen Problem individuell nachzugehen.
Das Problem ist nicht generell, die meisten (mich inklusive) haben kein Problem mit Speicherzuwachs. Ich habe in dieses Problem schon viele Stunden investiert, und waere sehr froh, wenn es nicht mehr auftaucht. Wenn Du uns zeigen kannst, wie man das Problem loest: ich lerne gerne was dazu.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: JoWiemann am 25 März 2021, 10:25:22
Zitat von: Tungsten am 25 März 2021, 09:44:58
Danke dir, somit überlasst ihr es dem Zufall und einzelnen Usern dem scheinbar generellen Problem individuell nachzugehen.

Es gibt leider keine wirkliche "Regel". Ich habe zwie Fhem Instanzen laufen. Eine auf einem RPi 3b und eine auf einem Cubie. Beide haben die selben Devices und sind per Fhem2Fhem verbunden. Der RPi ist für die Steuerung zuständig. Der Cubie für Visualisierung und Logging. Auf dem RPi war Sysmon der Verursacher für Speicherverbrauch. Nach dem deaktivieren läuft er nun stabil. Auf dem Cubie war es die Perl Version. Nach dem letzen upgrade auf buster läuft er auch mit SysMon stabil.

Mein Test RPi, identisch zum RPi 3b allerdings ein RPi 2, läuft ohne jedwedes Problem.

Grüße Jörg
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 25 März 2021, 10:34:57
Btw: Was ich jetzt gar nicht gefunden habe (oder überlesen)(und sorry fürs Kapern):
Mit welchen Perl Versionen ist eigentlich FHEM getestet?

Da hier fhem im Docker läuft, wäre ein testen in Verschiedenen Versionen ziemlich einfach möglich ..... (Eventuell sogar automatisch)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: frank am 25 März 2021, 11:07:17
ich kann im plot von @Tungsten gar kein speicherleck erkennen.
wenn bei unter 120MB bereits "cannot fork" erscheint, hat die hardware nicht genügend freien speicher.
eventuell zu viel andere sw am laufen?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Tungsten am 25 März 2021, 11:27:40
Zitat von: frank am 25 März 2021, 11:07:17
ich kann im plot von @Tungsten gar kein speicherleck erkennen.
wenn bei unter 120MB bereits "cannot fork" erscheint, hat die hardware nicht genügend freien speicher.
eventuell zu viel andere sw am laufen?

RAM Auslastung ist einigermaßen stabil bei 65-70%

Total: 926.08 MB, Used: 649.87 MB, 70.17 %, Free: 121.87 MB

Wie deaktiviert man einzelne Module zum Testen? Meint ihr damit über 'attr disable = 1'?


Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 25 März 2021, 11:32:55
ZitatWie deaktiviert man einzelne Module zum Testen? Meint ihr damit über 'attr disable = 1'?
disable=1 ist nicht zuverlaessig, je nach Modul ist es nicht implementiert, oder unterbindet nur bestimmte Funktionen.
Ich meine eine Kopie der Konfiguration ohne irgendeine Definition eines Modul-Typs, und FHEM damit starten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Homalix99 am 25 März 2021, 11:42:30
Zitat
ich kann im plot von @Tungsten gar kein speicherleck erkennen.
wenn bei unter 120MB bereits "cannot fork" erscheint, hat die hardware nicht genügend freien speicher.
eventuell zu viel andere sw am laufen?

Bei mir ging es bei 540 MB für den perl prozess los mit den Meldungen, bei RPi 3 und 1 GB RAM.

Auf die Frage von Tungsten, ob man das als Reading (z. B. in SYSMON integriert) zur weiteren Auswertung und Möglichkeit darauf zu reagieren, machen kann:
Meine Lösung:
1. in 99_myUtil:

sub psize($) {
    my ($name) = @_;
    my $ret;
    my $v   = `awk '/VmSize/{print \$2}' /proc/$$/status`;
    $ret = sprintf("%.2f",(rtrim($v)/1024));
    fhem ("setreading $name state $ret");
   return;
}


2. Dummy:

defmod Speicherauslastung dummy
attr Speicherauslastung DbLogExclude .*
attr Speicherauslastung comment Wert gibt die perl-Speicherbelegung durch fhem  an
attr Speicherauslastung event-on-change-reading state
attr Speicherauslastung group Info
attr Speicherauslastung readingList Alarm_PerlsizeLimit Alarm_MEM_Avail
attr Speicherauslastung room System
attr Speicherauslastung setList Alarm_MEM_Avail:slider,100,10,900\
Alarm_PerlsizeLimit:slider,120,10,800
attr Speicherauslastung stateFormat { sprintf("%.2f MB",,(ReadingsVal($name,"state",0)))}


3. AT:

psize("Speicherauslastung");;\
my $ram_avail = ReadingsVal("RPI_Stat","ram_avail",0);;\
fhem("setreading Speicherauslastung ram_avail $ram_avail");;\
}
attr a_pSize DbLogExclude .*
attr a_pSize group Steuerung
attr a_pSize room System

Ruft alle 5 Min. die Sub auf, welche den Speicherverbrauch des Perl-Prozess direkt in den Dummy schreibt, sowie aus Sysmon (wenn gewünscht, Ram Available abfrägt und als Reading ram_avail in den Dummy kopiert.
Im Dummy kann man dann Grenzwerte setzen und mit weiterer Routine darauf reagieren (z. B. sich eine mail senden lassen, etc.
oder den state des Dummy in DBLog laufen lassen.


Gruß

Alex

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Tungsten am 31 März 2021, 08:56:51
Kurzes Update von mir. Nach Update von Stretch auf Buster und somit auch Perl v5.28.1 ist das Problem bei mir nicht mehr aufgetreten.

Es hat auch den positiven Nebeneffekt, dass Radiostreams, die ich über FTUI auf einem BT Lautsprecher ausgebe, keine Aussetzer mehr haben.
Den Grund dafür habe ich immer an anderer Stelle gesucht, aber nicht wirklich fixen können.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: cortmen am 10 April 2021, 19:15:10
Ich bekomme diese Meldung öfters, wenn ich über "hm" meine Temperaturlisten ab und zu neu verteile.
Immer dann wenn 3-4 Devices betroffen sind.
Und es läuft ein:

HMinfo hm get:configCheck :-f

Am RAM Speicher liegt es nicht:
KiB Spch :  1768824 gesamt,   904336 frei,   715436 belegt,   149052 Puff/Cache
KiB Swap:        0 gesamt,        0 frei,        0 belegt.  1027560 verfü Spch

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     ZEIT+ BEFEHL
23526 root      20   0    7844   3580   2908 R  10,0  0,2   0:00.63 top
  739 fhem      20   0  371448 313584   8532 S   5,0 17,7 441:06.17 perl



Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: xgadscu am 17 April 2021, 19:37:10
Ich lese gerade den Hinweis auf hminfo und kann folgende Beobachtung beitragen:

Beim Pairen und Peeren neuer Homematic-Fensterkontakte hatte sich mein System immer wieder total aufgehängt. Danach fand ich im Log Cannot fork: Cannot allocate memory.

Eben habe ich wieder einen set-Befehl gegen einen Fensterkontakt abgesetzt und siehe da:


2021.04.17 18:46:49 2: HMinfo hminfo get:configCheck :
2021.04.17 18:48:14 3: CUL_HM set HM_Fensterkontakt_EW_Bad regSet exec peerNeedsBurst on HM_HKV_EW_Bad_WindowRec
2021.04.17 18:48:14 2: HMinfo hminfo get:configCheck :-f,^(HM_Fensterkontakt_EW_Bad|HM_Fensterkontakt_EW_Bad)$
2021.04.17 18:52:54 3: CUL_HM set HM_Fensterkontakt_EW_Bad getConfig noArg
2021.04.17 18:54:30 2: HMinfo hminfo get:configCheck :-f,^(HM_Fensterkontakt_EW_Bad|HM_Fensterkontakt_EW_Bad)$
2021.04.17 18:56:41 3: HMinfo hminfo get:update :
2021.04.17 18:56:42 3: CUL_HM set ActionDetector update noArg
2021.04.17 18:57:16 1: Cannot fork: Cannot allocate memory


Schon stand wieder alles still...

Gruß xgadscu
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: burgi110 am 29 Juni 2021, 17:29:47
Ich habe mir einen crontab mit script gebastelt welcher meine rasperry neu bootet


#### reboot script (reboot.sh)
#!/bin/bash
#sudo
################################
## Fhem Reeboot
## wird aus fhem gestartet
################################


DATEX=$(date +%H:%M)
sudo chmod 0777 /var/log/fhem/*
sudo chown -R fhem: /opt/fhem/
sudo chown -R fhem:dialout /opt/fhem/

sudo chown -R fhem: /var/log/fhem
sudo chown -R fhem:dialout /var/log/fhem/
echo $DATEX "reboot gestartet "

sleep 10

echo $DATEX "fhem_stopped"


sudo service mosquitto stop &
sudo /etc/init.d/fhem stop &
echo $DATEX "reboot in 60 sekunden"
sleep 60
sudo  reboot
exit
###############
fork script :

#!/bin/bash

echo "########################################";
echo "# Cannot fork: Cannot allocate memory  #";
echo "########################################";
## wenn der fehler auftritt wird fhem neu gebootet fehler umbenannt
## script läuft mit cron

sudo chown -R fhem:dialout /var/log/fhem/*
sudo chmod -R 777   /var/log/fhem/*
LOGFILE=/var/log/fhem/network-monitor.log
LOGFILE1=/var/log/fhem/tomisLog-$(date +%d).log
#clear variable
OUT=


OUT=$(grep -a "Cannot fork: Cannot allocate memory" /var/log/fhem/fhem-$(date +%d).log | tail -1);
echo  $OUT;


   
if [ -z "${OUT}" ];


then
   echo "kein fork error gefunden" >> $LOGFILE1
else

   echo "fork error  gefunden Fhem  wird gebootet" >> $LOGFILE1
   sudo sed -i 's/Cannot fork: Cannot allocate memory/forkerror_gefunden/g' /var/log/fhem/fhem-$(date +%d).log



   sudo chmod -R 777   /var/log/fhem/*
   sudo chown -R fhem:dialout /var/log/fhem/*
   sudo /opt/fhem/mycfg/NAS/reboot.sh
fi




#############Das script sucht nach dem fork fehler im logging > und erstetz den fehler durch xxx , dannach reboot fhem

#############

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 29 Juni 2021, 17:44:30
ZitatIch habe mir einen crontab mit script gebastelt welcher meine rasperry neu bootet
Das kriegt man auch mit FHEM-Mitteln hin, indem man das reboot per notify auf global:CANNOT_FORK ausloest.
Wobei bei einem FHEM Speicherloch auch ein FHEM "shutdown restart" reicht.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 29 Juni 2021, 17:58:25
Genau so würde ich es auch sehen.

kan-not-folk ist schließlich in Anwendungs und kein Betriebsystemproblem.

Wir leben hier in der Linux-Welt, reboot wirklich nur, wenn es nötig ist ...
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: dancatt am 02 Juli 2021, 13:20:09
Hallo,

ich gehöre nun auch dem Club bei :-(
Seit Mai hat sich immer wöchentlich in der Nacht auf Sonntag fhem verabschiedet. Immer um kurz nach 4 Uhr.
Dachte erst es hängt an set dbLog userCommand VACUUM da ich dies immer Sonntags um 4 Uhr gemacht habe.
Daran liegt es aber nicht.

Kurz vor dem Problem habe ich das Modul "vitoconnect" angebunden. Dies werde ich nach dem nächsten freeze mal abschalten.

Seit gestern hat sich das System nun schon 3mal verabschiedet.
Gestern habe ich auch folgendes durchgeführt da meine Ikea Lampen nicht mehr gingen:
https://forum.fhem.de/index.php/topic,96125.msg1164785.html#msg1164785

Perl hat bei mir die Version 5.28.1
                                           
Folgendes mit "{`echo \`date +"%Y-%m-%d_%H:%M:%S"\` size \`awk '/VmSize/{print \$2}' /proc/$$/status\` >> /opt/fhem/log/perlsize.log`}" seit dem letzten Freeze geloggt:
2021-07-02_11:03:28 size 359204
2021-07-02_11:08:28 size 367692
2021-07-02_11:13:28 size 377932
2021-07-02_11:18:31 size 386124
2021-07-02_11:23:28 size 395340
2021-07-02_11:28:28 size 404908
2021-07-02_11:33:28 size 414124
2021-07-02_11:38:29 size 422316
2021-07-02_11:43:28 size 430508
2021-07-02_11:48:28 size 440748
2021-07-02_11:53:28 size 449964
2021-07-02_11:58:30 size 458584
2021-07-02_12:03:28 size 468824
2021-07-02_12:08:28 size 479064
2021-07-02_12:13:28 size 488280
2021-07-02_12:18:28 size 497496
2021-07-02_12:23:28 size 504664
2021-07-02_12:28:28 size 514904
2021-07-02_12:33:28 size 524632
2021-07-02_12:38:28 size 533848
2021-07-02_12:43:28 size 542040
2021-07-02_12:48:28 size 551256
2021-07-02_12:53:28 size 561496
2021-07-02_12:58:31 size 571736
2021-07-02_13:03:29 size 583000
2021-07-02_13:08:28 size 592832
2021-07-02_13:13:28 size 603072


Der letzte Freeze war bei 1399.42 MB
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: dancatt am 03 Juli 2021, 06:54:41
Moin,

an vitoconnect und tradfri scheint es mal nicht zu liegen.
Ich habe immer noch einen Anstieg von 10 MB innerhalb 5 Minuten.
Ich werde dann mal noch weiter Devices löschen.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: tobi01001 am 05 August 2021, 14:31:32
Hi zusammen,

nachdem ich nun mehrere Probleme mit Memory Leaks hatte (und sich das immer nur durch Trial and Error lösen lies), will ich meine letzten Erfahrungen hier einfach mal dalassen. Vielleicht hilft es dem ein oder anderen:

Jedenfalls hatte ich ab und an nach Updates mit Speicherproblemen zu kämpfen (siehe Anhang). Seltsamerweise in letzter Zeit ohne "Cannot fork..." - aber ich habe auch ab einer gewissen Grenze Fhem neu gestartet damit zumindest das System weiter läuft.

Ich habe mit perlbrew experimentiert, verschiedenste Module disabled bzw ganz gelöscht. Das konnte den Anstieg abflachenund etwas verzögern aber hatte das Problem nicht beseitigt. (Alle Module wollte ich noch nicht rausnehmen). Ich war schon kurz vor einem "des Raspi komplett neu aufsetzen", habe aber nochmal genauer darüber nachgedacht wie und wann dieses Speicherleck aufgetreten war.
-> Ich hatte einen harten Reset des pi (power loss) und danach fingen die Probleme (wieder an).

Durch einen anderen Thread wurde ich darauf aufmerksam, dass fhem.save nur bei "save" und beim regulären shutdown geschrieben wird... Was wäre also, wenn die device states in fhem.save beim reset vergleichsweise alt waren und fhem bei diesen irgendwie schluckauf bekommt?
Also:
... und das memory leak ist vorerst Geschichte. Ein paar Werte / Einstellungen musste ich händisch wieder setzten da ich ziemlich optimistisch gelöscht hatte (dummys mit werten / einstellungen z.B.).

Ich werde das beim nächsten Auftreten nochmal "verifizieren". Man müsste ja durch Wechsel zwischen "alter" und "entschlackter" fhem.save ebenso zwischen Speicherleck Ja/Nein umschalten können.

Das jedenfalls meine jüngste Erfahrung die ich zumindest mal teilen wollte.

Gruß,
Tobias

Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: MadMax-FHEM am 05 August 2021, 14:50:51
Zitat von: tobi01001 am 05 August 2021, 14:31:32

  • sudo /etc/init.d/fhem start

Danke.

Aber das ist verm. auch nur eine weitere Ursache(nmöglichkeit)...

Bei mir war immer "nur" Backup-Restore (fhem Bordmittel).

Wheezy -> keine Leaks

Jessie -> hmm, glaube auch keine ;)

Stretch -> Leaks

Buster -> keine Leaks

Ansonsten hat sich das System halt "normal" (marginal) "Weiterentwickelt"...


ABER: sudo /etc/init.d/fhem start ? Wirklich noch?

Evtl. doch mal auch die Basis aktualisieren ;)

Seit Stretch ist statt initd nämlich systemd 8)

Gruß, Joachim
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: tobi01001 am 05 August 2021, 17:09:44
Zitat von: MadMax-FHEM am 05 August 2021, 14:50:51
Aber das ist verm. auch nur eine weitere Ursache(nmöglichkeit)...
Ja sicher. Und wie man an den vielen Posts sieht, sind die Ursachen sehr vielfältig und individuell. Daher wollte ich auch "nur" einen weiteren Anhaltspunkt da lassen. Ich vermute die eigentliche Ursache auch nicht in der fhem.save. Das war wohl nur das Pflaster was mich vorm Neu-Aufsetzen bewahrt hat....

Zitat von: MadMax-FHEM am 05 August 2021, 14:50:51
ABER: sudo /etc/init.d/fhem start ? Wirklich noch?

Evtl. doch mal auch die Basis aktualisieren ;)

Seit Stretch ist statt initd nämlich systemd 8)

Ich mag die Init.d scripte :-D Die Basis ist aktuell (migriert)... Meine Gewohnheiten lassen sich leider nur schwer migrieren. Und daher sind die init.d scripte auch noch da. Falls ich mal auf neuere HW umziehe, wird das bestimmt nachgezogen ;-)
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 05 August 2021, 17:48:13
Zitatin der fhem.save nahezu alles gelöscht [...] und das memory leak ist vorerst Geschichte
Dieses Speicherloch mit 30MB+/Stunde ist so gross, dass man hier mit kurzen (5min?) Modul-Abschaltungen experimentieren kann.
In einem anderen mir bekannten Fall ist das Loch 1MB/Woche, da sind Experimente dieser Art schwieriger.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: tobi01001 am 06 August 2021, 16:39:03
Zitat von: rudolfkoenig am 05 August 2021, 17:48:13
Dieses Speicherloch mit 30MB+/Stunde ist so gross, dass man hier mit kurzen (5min?) Modul-Abschaltungen experimentieren kann.
In einem anderen mir bekannten Fall ist das Loch 1MB/Woche, da sind Experimente dieser Art schwieriger.
Ja genau. Das habe ich ein Stück weit getan, konnte aber nur den Anstieg verringern. D.h. es war nicht dieses oder jenes Modul sondern irgendwie die Kombination.... Hab auch die zyklischen Timer angeschaut, weil es stündlich einen Sprung gibt. Letztendlich hab ich es aber nicht auf die "Schnelle" in den Griff bekommen.

Wie gesagt, beim nächsten Auftreten (oder wenn mir mal arg langweilig ist  :) ), werde ich mal mit den Daten in der fhem.save experimentieren um so eventuell das Modul und order den Verursacher identifizieren zu können.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: vbs am 12 Oktober 2021, 23:14:37
Ich leide momentan auch an einem Memory Leak. Ca. so 1MB pro Minute. Auch bei mir würde es offenbar helfen, die fhem.save zu löschen, was natürlich weh täte. Hat da jemand eine Idee, wie das zusammen hängen könnte bzw. wie man die fhem.save erhalten könnte und trotzdem das Memory Leak weg bekommen könnte?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: rudolfkoenig am 13 Oktober 2021, 08:01:48
Ich wuerde fhem.cfg und fhem.save sichern, und danach die Definitionen eins nach dem anderen entfernen.
Mit 1MB/min sollte es nicht lange dauern, bis man durch Binaere Suche den (die?) Schuldigen findet.
Danach kann man fhem.save und fhem.cfg wieder restaurieren.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: vbs am 13 Oktober 2021, 09:38:30
Hi Rudi, hatte ich im Prinzip so gemacht. Ich hab nach und nach alle Geräte gelöscht (erst alle CUL_HM, dann alle PRESENCE usw. usw.). Jedoch hatte ich noch meine originale fhem.save verwendet. Ich hab dabei nicht denen einen Schuldigen gefunden, aber je mehr ich Geräte entfernt habe, desto langsamer wurde der Speicherverlust.
Dann mit dem Löschen von fhem.save war das Problem sofort beseitigt. Auch unter Beibehaltung der originalen fhem.cfg  :o

Ich würde sonst als nächstes mal nach und nach Sachen aus der fhem.save entfernen und gucken, ob man da etwas rausfinden kann.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: vbs am 13 Oktober 2021, 21:19:26
Also bei mir scheint es an freezemon gelegen zu haben. Dessen state zu löschen behebt das Problem und das Device zu löschen hilft auch (logisch):
setstate sys_freezemon inactive
setstate sys_freezemon 2021-09-08 22:12:51 .fm_freezes
setstate sys_freezemon 2021-09-08 22:12:51 .lastDay
setstate sys_freezemon 2021-09-08 22:12:51 fcDay 0
setstate sys_freezemon 2021-09-08 22:12:51 fcDayLast 0
setstate sys_freezemon 2021-09-08 22:12:51 freezeDevice
setstate sys_freezemon 2021-09-08 22:12:51 freezeTime 0
setstate sys_freezemon 2021-09-08 22:12:51 ftDay 0
setstate sys_freezemon 2021-09-08 22:12:51 ftDayLast 0
setstate sys_freezemon 2021-09-08 22:11:58 perfmon not active
setstate sys_freezemon 2021-09-08 22:12:40 state inactive


Werde ich jetzt weiter beobachten.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: vbs am 14 Oktober 2021, 19:22:36
Also bei mir scheint das Problem gelöst. In den letzten 20 Stunden nur ca. 2MB dazu gekommen, was ich mal als normal verbuchen würde.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: KölnSolar am 15 Oktober 2021, 06:36:19
Ich hab freezemon im Einsatz u. empfehle es auch gern. Bei mir kann ich kein memory leak erkennen. sysmon berichtet nach 10 Tagen uptime 31% RAM usage. Ich beobachte mal den Verlauf.

Ich spekuliere auch in diese Richtung
ZitatD.h. es war nicht dieses oder jenes Modul sondern irgendwie die Kombination....
Grüße Markus

Edit: Nach weiteren 10 Tagen uptime und zwischenzeitlichem update/upgrade immer noch nur 30%.
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: vuffiraa am 10 November 2022, 16:15:18
Zitat von: vbs am 13 Oktober 2021, 21:19:26
Also bei mir scheint es an freezemon gelegen zu haben. Dessen state zu löschen behebt das Problem und das Device zu löschen hilft auch (logisch):
setstate sys_freezemon inactive
setstate sys_freezemon 2021-09-08 22:12:51 .fm_freezes
setstate sys_freezemon 2021-09-08 22:12:51 .lastDay
setstate sys_freezemon 2021-09-08 22:12:51 fcDay 0
setstate sys_freezemon 2021-09-08 22:12:51 fcDayLast 0
setstate sys_freezemon 2021-09-08 22:12:51 freezeDevice
setstate sys_freezemon 2021-09-08 22:12:51 freezeTime 0
setstate sys_freezemon 2021-09-08 22:12:51 ftDay 0
setstate sys_freezemon 2021-09-08 22:12:51 ftDayLast 0
setstate sys_freezemon 2021-09-08 22:11:58 perfmon not active
setstate sys_freezemon 2021-09-08 22:12:40 state inactive


Werde ich jetzt weiter beobachten.

Die Diskussion hier ist zwar schon etwas älter, aber das mir gerade geholfen.
Nach einem Neustart meiner Fhem-Instanz ist der Speicherverbrauch des Fhem-Prozesses nach kurzer Zeit durch die Decke gegangen.
Beim Neustart hat es eigentlich keine Änderungen in meiner Fhem-Konfiguration gegegben.

Ich habe Freezemon im Einsatz und hatte es kurz vor dem Neustart deaktiviert. In fhem.save standen ähnliche Dinge, wie bei dir.
Es hat geholfen Freezemon wieder zu aktivieren und alle Statistiken im Modul aufzuräumen. fhem.save musste ich nicht direkt ändern.

VG
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: sTaN am 05 Januar 2023, 14:00:32
Hallo Zusammen,

erstaunlich, dass sich dieser Thread so lange hält.  ;D
Ich habe gestern seit langer Zeit mal wieder sysmon aktiviert und weiß nun auch wieder, warum ich bei dem device das Attribut disable = 1 hatte.
Denn seitdem tritt wieder der Fehler Cannot fork: Cannot allocate memory auf.

Im Logfile sieht es dann wie folgt aus:

2023.01.05 13:50:25 1: Cannot fork: Cannot allocate memory
2023.01.05 13:50:25 1: Cannot fork: Cannot allocate memory
2023.01.05 13:48:18 2: harmonyhub: disconnect
2023.01.05 13:48:18 1: Cannot fork: Cannot allocate memory
2023.01.05 13:48:18 1: Cannot fork: Cannot allocate memory
2023.01.05 13:47:40 2: hueBridge1: http request failed: http://192.168.1XX.XXX/api/XXXXXXXXXXXXXXXXXXXXXXXXXXXX/sensors/10: empty answer received
2023.01.05 13:47:39 2: hueBridge1: http request failed: read from http://192.168.1XX.XXX:80 timed out
2023.01.05 13:47:39 2: hueBridge1: http request failed: read from http://192.168.1XX.XXX:80 timed out
2023.01.05 13:47:39 2: hueBridge1: http request failed: read from http://192.168.1XX.XXX:80 timed out
2023.01.05 13:47:14 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_SYSMON.pm line 2911.
2023.01.05 13:47:00 1: Cannot fork: Cannot allocate memory
2023.01.05 13:47:00 1: Cannot fork: Cannot allocate memory
2023.01.05 13:47:00 1: Cannot fork: Cannot allocate memory
2023.01.05 13:47:00 1: Cannot fork: Cannot allocate memory
2023.01.05 13:46:57 1: Cannot fork: Cannot allocate memory
2023.01.05 13:46:57 1: Cannot fork: Cannot allocate memory
2023.01.05 13:46:12 1: Cannot fork: Cannot allocate memory
2023.01.05 13:46:10 1: Cannot fork: Cannot allocate memory
2023.01.05 13:46:10 1: Cannot fork: Cannot allocate memory
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2313.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2312.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2225.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $val in int at ./FHEM/42_SYSMON.pm line 1804.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/42_SYSMON.pm line 1657.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $string in substitution (s///) at ./FHEM/99_Utils.pm line 130.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $string in substitution (s///) at ./FHEM/99_Utils.pm line 129.
2023.01.05 13:37:24 1: Cannot fork: Cannot allocate memory
2023.01.05 13:37:20 1: Cannot fork: Cannot allocate memory
2023.01.05 13:37:20 1: Cannot fork: Cannot allocate memory
2023.01.05 13:36:08 1: Cannot fork: Cannot allocate memory
2023.01.05 13:36:08 1: Cannot fork: Cannot allocate memory
2023.01.05 13:36:07 1: Cannot fork: Cannot allocate memory
2023.01.05 13:35:57 1: Cannot fork: Cannot allocate memory
2023.01.05 13:35:57 1: Cannot fork: Cannot allocate memory
2023.01.05 13:35:57 1: Cannot fork: Cannot allocate memory
2023.01.05 13:35:57 1: Cannot fork: Cannot allocate memory
2023.01.05 13:35:57 1: Cannot fork: Cannot allocate memory
2023.01.05 13:35:57 1: Cannot fork: Cannot allocate memory
2023.01.05 13:35:37 1: Cannot fork: Cannot allocate memory
2023.01.05 13:35:35 1: Cannot fork: Cannot allocate memory
2023.01.05 13:35:34 1: Cannot fork: Cannot allocate memory
2023.01.05 13:31:54 1: Cannot fork: Cannot allocate memory
2023.01.05 13:31:54 1: Cannot fork: Cannot allocate memory


Mein sysmon device sieht wie folgt aus:

Internals:
   DEF        1 1 1 10
   FUUID      5fc19a07-f33f-1bd5-70bc-bf235043772ac0b5
   INTERVAL_BASE 60
   INTERVAL_MULTIPLIERS 1 1 1 10
   MODE       local
   NAME       sysmon
   NOTIFYDEV  global,TYPE=SYSMON
   NR         693
   NTFY_ORDER 50-sysmon
   STATE      Inactive
   TYPE       SYSMON
   eventCount 845
   READINGS:
     2023-01-05 13:51:25   cpu0_freq       600
     2023-01-05 13:51:25   cpu0_freq_stat  600.00 1200.00 890.28
     2023-01-05 13:51:26   cpu0_idle_stat  0.00 99.90 69.02
     2023-01-05 13:51:25   cpu1_freq       600
     2023-01-05 13:51:25   cpu1_freq_stat  600.00 1200.00 890.28
     2023-01-05 13:51:26   cpu1_idle_stat  0.00 99.95 72.22
     2023-01-05 13:51:25   cpu2_freq       600
     2023-01-05 13:51:25   cpu2_freq_stat  600.00 1200.00 890.28
     2023-01-05 13:51:26   cpu2_idle_stat  0.00 100.00 71.98
     2023-01-05 13:51:25   cpu3_freq       600
     2023-01-05 13:51:25   cpu3_freq_stat  600.00 1200.00 890.28
     2023-01-05 13:51:26   cpu3_idle_stat  14.78 99.97 72.89
     2023-01-04 23:46:04   cpu_bogomips    76.80
     2023-01-05 13:51:26   cpu_core_count  4
     2023-01-05 13:51:25   cpu_freq        600
     2023-01-05 13:51:25   cpu_freq_stat   600.00 1200.00 890.28
     2023-01-05 13:51:26   cpu_idle_stat   14.47 98.34 71.55
     2023-01-04 23:46:04   cpu_model_name  ARMv7 Processor rev 4 (v7l)
     2023-01-05 13:51:26   cpu_temp        58.53
     2023-01-05 13:51:26   cpu_temp_avg    52.9
     2023-01-05 13:51:26   cpu_temp_stat   0.00 68.76 52.88
     2023-01-05 13:51:26   eth0            RX: 48989.46 MB, TX: 65126.04 MB, Total: 114115.5 MB
     2023-01-05 13:51:26   eth0_diff       RX: 1.06 MB, TX: 0.67 MB, Total: 1.73 MB
     2023-01-05 13:51:26   eth0_ip         192.168.188.155
     2023-01-05 13:51:26   eth0_rx         51369170153
     2023-01-05 13:51:26   eth0_speed      100
     2023-01-05 13:51:26   eth0_tx         68289602565
     2023-01-05 13:51:26   fhemstarttime   1672872289
     2023-01-05 13:51:26   fhemstarttime_text 04.01.2023 23:44:49
     2023-01-05 13:51:26   fhemuptime      50797
     2023-01-05 13:51:26   fhemuptime_text 0 days, 14 hours, 06 minutes
     2023-01-05 13:40:58   fs_boot         Total: 41 MB, Used: 23 MB, 55 %, Available: 19 MB at /boot
     2023-01-05 13:40:58   fs_root         Total: 14885 MB, Used: 3958 MB, 28 %, Available: 10291 MB at /
     2023-01-05 13:40:58   fs_usb1         Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /media/usb1 (not available)
     2023-01-05 13:51:26   idletime        1140112 95.54 %
     2023-01-05 13:51:26   idletime_text   13 days, 04 hours, 41 minutes (95.54 %)
     2023-01-05 13:51:26   loadavg         3.19 4.13 2.46
     2023-01-04 23:46:04   perl_version    v5.24.1
     2023-01-05 13:51:26   ram             Total: 926.08 MB, Used: 455.68 MB, 49.21 %, Free: 411.52 MB
     2023-01-05 13:51:26   ram_used_stat   116.83 757.85 489.72
     2023-01-05 13:51:26   starttime       1671729811
     2023-01-05 13:51:26   starttime_text  22.12.2022 18:23:31
     2023-01-05 13:51:26   stat_cpu        8180878 343594 2703200 456044893 1503178 0 285918
     2023-01-05 13:51:26   stat_cpu0       2679976 83400 898775 107441018 446813 0 282711
     2023-01-05 13:51:26   stat_cpu0_diff  580 515 578 8984 1420 0 45
     2023-01-05 13:51:26   stat_cpu0_percent 4.78 4.25 4.77 74.11 11.71 0.00 0.37
     2023-01-05 13:51:26   stat_cpu0_text  user: 4.78 %, nice: 4.25 %, sys: 4.77 %, idle: 74.11 %, io: 11.71 %, irq: 0.00 %, sirq: 0.37 %
     2023-01-05 13:51:26   stat_cpu1       1826802 90187 601958 116243502 344809 0 1042
     2023-01-05 13:51:26   stat_cpu1_diff  126 857 572 9709 1404 0 0
     2023-01-05 13:51:26   stat_cpu1_percent 0.99 6.77 4.52 76.64 11.08 0.00 0.00
     2023-01-05 13:51:26   stat_cpu1_text  user: 0.99 %, nice: 6.77 %, sys: 4.52 %, idle: 76.64 %, io: 11.08 %, irq: 0.00 %, sirq: 0.00 %
     2023-01-05 13:51:26   stat_cpu2       1926000 87005 633616 116003859 355480 0 1160
     2023-01-05 13:51:26   stat_cpu2_diff  86 610 500 9979 1515 0 0
     2023-01-05 13:51:26   stat_cpu2_percent 0.68 4.81 3.94 78.64 11.94 0.00 0.00
     2023-01-05 13:51:26   stat_cpu2_text  user: 0.68 %, nice: 4.81 %, sys: 3.94 %, idle: 78.64 %, io: 11.94 %, irq: 0.00 %, sirq: 0.00 %
     2023-01-05 13:51:26   stat_cpu3       1748100 83002 568851 116356512 356074 0 1005
     2023-01-05 13:51:26   stat_cpu3_diff  569 848 545 9571 1183 0 2
     2023-01-05 13:51:26   stat_cpu3_percent 4.47 6.67 4.29 75.26 9.30 0.00 0.02
     2023-01-05 13:51:26   stat_cpu3_text  user: 4.47 %, nice: 6.67 %, sys: 4.29 %, idle: 75.26 %, io: 9.30 %, irq: 0.00 %, sirq: 0.02 %
     2023-01-05 13:51:26   stat_cpu_diff   1361 2830 2195 38244 5522 0 47
     2023-01-05 13:51:26   stat_cpu_percent 2.71 5.64 4.37 76.18 11.00 0.00 0.09
     2023-01-05 13:51:26   stat_cpu_text   user: 2.71 %, nice: 5.64 %, sys: 4.37 %, idle: 76.18 %, io: 11.00 %, irq: 0.00 %, sirq: 0.09 %
     2023-01-05 13:51:26   swap            Total: 100.00 MB, Used: 99.99 MB,  99.99 %, Free: 0.01 MB
     2023-01-05 13:51:26   swap_used_stat  40.19 100.00 99.98
     2023-01-05 13:51:26   uptime          1193274
     2023-01-05 13:51:26   uptime_text     13 days, 19 hours, 27 minutes
     2023-01-05 13:51:26   wlan0           RX: 0.00 MB, TX: 0.00 MB, Total: 0 MB
     2023-01-05 13:51:26   wlan0_diff      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
     2023-01-05 13:51:26   wlan0_rx        0
     2023-01-05 13:51:26   wlan0_tx        0
   helper:
     net_eth0_stat_class 1
     net_wlan0_stat_class 1
     proc_fs    1
     sys_cpu0_freq 1
     sys_cpu0_temp 0
     sys_cpu1_freq 1
     sys_cpu1_temp 0
     sys_cpu2_freq 1
     sys_cpu2_temp 0
     sys_cpu3_freq 1
     sys_cpu3_temp 0
     sys_cpu4_freq 0
     sys_cpu4_temp 0
     sys_cpu5_freq 0
     sys_cpu5_temp 0
     sys_cpu6_freq 0
     sys_cpu6_temp 0
     sys_cpu7_freq 0
     sys_cpu7_temp 0
     sys_cpu_core_num 4
     sys_cpu_freq_rpi_bbb 1
     sys_cpu_num 1
     sys_cpu_temp_bbb 0
     sys_cpu_temp_rpi 1
     sys_fb     0
     sys_power_ac 0
     sys_power_bat 0
     sys_power_usb 0
     u_first_mark 1
     cur_readings_map:
       cpu0_freq  CPU frequency (core 0)
       cpu0_freq_stat CPU frequency (core 0) stat
       cpu0_idle_stat CPU0 min/max/avg (idle)
       cpu1_freq  CPU frequency (core 1)
       cpu1_freq_stat CPU frequency (core 1) stat
       cpu1_idle_stat CPU1 min/max/avg (idle)
       cpu2_freq  CPU frequency (core 2)
       cpu2_freq_stat CPU frequency (core 2) stat
       cpu2_idle_stat CPU2 min/max/avg (idle)
       cpu3_freq  CPU frequency (core 3)
       cpu3_freq_stat CPU frequency (core 3) stat
       cpu3_idle_stat CPU3 min/max/avg (idle)
       cpu4_idle_stat CPU4 min/max/avg (idle)
       cpu5_idle_stat CPU5 min/max/avg (idle)
       cpu6_idle_stat CPU6 min/max/avg (idle)
       cpu7_idle_stat CPU7 min/max/avg (idle)
       cpu_bogomips BogoMIPS
       cpu_core_count Number of CPU cores
       cpu_freq   CPU frequency
       cpu_freq_stat CPU frequency stat
       cpu_idle_stat CPU min/max/avg (idle)
       cpu_model_name CPU model name
       cpu_temp   CPU temperature
       cpu_temp_avg Average CPU temperature
       cpu_temp_stat CPU temperature stat
       date       Date
       eth0       Network adapter eth0
       eth0_diff  Network adapter eth0 (diff)
       eth0_ip    Network adapter eth0 (IP)
       eth0_ip6   Network adapter eth0 (IP6)
       eth0_rx    Network adapter eth0 (RX)
       eth0_speed Network adapter eth0 (speed)
       eth0_tx    Network adapter eth0 (TX)
       fhemstarttime Fhem start time
       fhemstarttime_text Fhem start time
       fhemuptime System up time
       fhemuptime_text FHEM up time
       fs_boot    Filesystem /boot
       fs_boot_free Filesystem /boot (free)
       fs_boot_used Filesystem /boot (used)
       fs_boot_used_percent Filesystem /boot (used %)
       fs_root    Root
       fs_root_free Root (free)
       fs_root_used Root (used)
       fs_root_used_percent Root (used %)
       fs_usb1    USB-Stick
       fs_usb1_free USB-Stick (free)
       fs_usb1_used USB-Stick (used)
       fs_usb1_used_percent USB-Stick (used %)
       idletime   Idle time
       idletime_text Idle time
       io_sda     TEST
       io_sda_diff TEST
       io_sda_raw TEST
       loadavg    Load average
       loadavg_1  Load average 1
       loadavg_15 Load average 15
       loadavg_5  Load average 5
       perl_version Perl Version
       ram        RAM
       ram_free   RAM free
       ram_free_percent RAM free %
       ram_total  RAM total
       ram_used   RAM used
       ram_used_stat RAM used stat
       starttime  System start time
       starttime_text System start time
       stat_cpu   CPU statistics
       stat_cpu0  CPU0 statistics
       stat_cpu0_diff CPU0 statistics (diff)
       stat_cpu0_percent CPU0 statistics (diff, percent)
       stat_cpu0_text CPU0 statistics (text)
       stat_cpu1  CPU1 statistics
       stat_cpu1_diff CPU1 statistics (diff)
       stat_cpu1_percent CPU1 statistics (diff, percent)
       stat_cpu1_text CPU1 statistics (text)
       stat_cpu2  CPU2 statistics
       stat_cpu2_diff CPU2 statistics (diff)
       stat_cpu2_percent CPU2 statistics (diff, percent)
       stat_cpu2_text CPU2 statistics (text)
       stat_cpu3  CPU3 statistics
       stat_cpu3_diff CPU3 statistics (diff)
       stat_cpu3_percent CPU3 statistics (diff, percent)
       stat_cpu3_text CPU3 statistics (text)
       stat_cpu4  CPU4 statistics
       stat_cpu4_diff CPU4 statistics (diff)
       stat_cpu4_percent CPU4 statistics (diff, percent)
       stat_cpu4_text CPU4 statistics (text)
       stat_cpu5  CPU5 statistics
       stat_cpu5_diff CPU5 statistics (diff)
       stat_cpu5_percent CPU5 statistics (diff, percent)
       stat_cpu5_text CPU5 statistics (text)
       stat_cpu6  CPU6 statistics
       stat_cpu6_diff CPU6 statistics (diff)
       stat_cpu6_percent CPU6 statistics (diff, percent)
       stat_cpu6_text CPU6 statistics (text)
       stat_cpu7  CPU7 statistics
       stat_cpu7_diff CPU7 statistics (diff)
       stat_cpu7_percent CPU7 statistics (diff, percent)
       stat_cpu7_text CPU7 statistics (text)
       stat_cpu_diff CPU statistics (diff)
       stat_cpu_idle_percent CPU statistics idle %
       stat_cpu_io_percent CPU statistics io %
       stat_cpu_irq_percent CPU statistics irq %
       stat_cpu_nice_percent CPU statistics nice %
       stat_cpu_percent CPU statistics (diff, percent)
       stat_cpu_sirq_percent CPU statistics sirq %
       stat_cpu_sys_percent CPU statistics sys %
       stat_cpu_text CPU statistics (text)
       stat_cpu_user_percent CPU statistics user %
       swap       swap
       swap_free  swap free
       swap_total swap total
       swap_used  swap used
       swap_used_percent swap used %
       swap_used_stat swap used stat
       uptime     System up time
       uptime_text System up time
       wlan0      Network adapter wlan0
       wlan0_diff Network adapter wlan0 (diff)
       wlan0_ip   Network adapter wlan0 (IP)
       wlan0_ip6  Network adapter wlan0 (IP6)
       wlan0_rx   Network adapter wlan0 (RX)
       wlan0_speed Network adapter wlan0 (speed)
       wlan0_tx   Network adapter wlan0 (TX)
     excludes:
     shadow_map:
       cpu0_idle_stat 0.00 99.90 76.07
       cpu1_idle_stat 0.00 99.95 78.07
       cpu2_idle_stat 0.00 100.00 78.03
       cpu3_idle_stat 14.78 99.97 79.44
       cpu_core_count 4
       cpu_idle_stat 14.47 98.34 77.92
       cpu_temp   55.31
       cpu_temp_avg 53.5
       cpu_temp_stat 0.00 68.76 53.49
       eth0       RX: 48992.33 MB, TX: 65126.78 MB, Total: 114119.11 MB
       eth0_diff  RX: 2.87 MB, TX: 0.74 MB, Total: 3.61 MB
       eth0_ip    192.168.188.155
       eth0_rx    51372181310
       eth0_speed 100
       eth0_tx    68290380092
       fhemstarttime 1672872289
       fhemstarttime_text 04.01.2023 23:44:49
       fhemuptime 51158
       fhemuptime_text 0 days, 14 hours, 12 minutes
       fs_boot    Total: 41 MB, Used: 23 MB, 55 %, Available: 19 MB at /boot
       fs_root    Total: 14885 MB, Used: 3959 MB, 28 %, Available: 10290 MB at /
       fs_usb1    Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /media/usb1 (not available)
       idletime   1140457 95.54 %
       idletime_text 13 days, 04 hours, 47 minutes (95.54 %)
       loadavg    0.30 1.38 1.73
       ram        Total: 926.08 MB, Used: 408.68 MB, 44.13 %, Free: 436.55 MB
       ram_used_stat 116.83 757.85 469.46
       starttime  1671729811
       starttime_text 22.12.2022 18:23:31
       stat_cpu   8184052 343594 2703831 456183063 1503556 0 285959
       stat_cpu0  2680493 83400 898965 107474138 447007 0 282751
       stat_cpu0_diff 517 0 190 33120 194 0 40
       stat_cpu0_percent 1.52 0.00 0.56 97.24 0.57 0.00 0.12
       stat_cpu0_text user: 1.52 %, nice: 0.00 %, sys: 0.56 %, idle: 97.24 %, io: 0.57 %, irq: 0.00 %, sirq: 0.12 %
       stat_cpu1  1828186 90187 602131 116277998 344839 0 1042
       stat_cpu1_diff 1384 0 173 34496 30 0 0
       stat_cpu1_percent 3.84 0.00 0.48 95.60 0.08 0.00 0.00
       stat_cpu1_text user: 3.84 %, nice: 0.00 %, sys: 0.48 %, idle: 95.60 %, io: 0.08 %, irq: 0.00 %, sirq: 0.00 %
       stat_cpu2  1927073 87005 633778 116038588 355617 0 1161
       stat_cpu2_diff 1073 0 162 34729 137 0 1
       stat_cpu2_percent 2.97 0.00 0.45 96.20 0.38 0.00 0.00
       stat_cpu2_text user: 2.97 %, nice: 0.00 %, sys: 0.45 %, idle: 96.20 %, io: 0.38 %, irq: 0.00 %, sirq: 0.00 %
       stat_cpu3  1748300 83002 568957 116392338 356091 0 1005
       stat_cpu3_diff 200 0 106 35826 17 0 0
       stat_cpu3_percent 0.55 0.00 0.29 99.11 0.05 0.00 0.00
       stat_cpu3_text user: 0.55 %, nice: 0.00 %, sys: 0.29 %, idle: 99.11 %, io: 0.05 %, irq: 0.00 %, sirq: 0.00 %
       stat_cpu_diff 3174 0 631 138170 378 0 41
       stat_cpu_percent 2.23 0.00 0.44 97.03 0.27 0.00 0.03
       stat_cpu_text user: 2.23 %, nice: 0.00 %, sys: 0.44 %, idle: 97.03 %, io: 0.27 %, irq: 0.00 %, sirq: 0.03 %
       swap       Total: 100.00 MB, Used: 99.99 MB,  99.99 %, Free: 0.01 MB
       swap_used_stat 40.19 100.00 99.98
       uptime     1193636
       uptime_text 13 days, 19 hours, 33 minutes
       wlan0      RX: 0.00 MB, TX: 0.00 MB, Total: 0 MB
       wlan0_diff RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       wlan0_rx   0
       wlan0_tx   0
Attributes:
   disable    1
   event-on-update-reading cpu_temp,cpu_temp_avg,ram,loadavg
   filesystems fs_boot:/boot,fs_root:/:Root,fs_usb1:/media/usb1:USB-Stick
   group      RPi
   room       Zentral


Ich verwende auch nur zwei Plots:

Internals:
   DEF        FileLog_sysmon:SM_RAM:CURRENT
   FUUID      63b5f0ef-f33f-1bd5-5104-06e6f785390d50f6
   GPLOTFILE  SM_RAM
   LOGDEVICE  FileLog_sysmon
   LOGFILE    CURRENT
   NAME       wl_sysmon_ram
   NR         773
   STATE      initialized
   TYPE       SVG
Attributes:
   group      RPi
   label      "RAM-Nutzung Total: $data{max1}, Min: $data{min2}, Max: $data{max2}, Aktuell: $data{currval2}"
   room       Zentral


Internals:
   DEF        FileLog_sysmon:SM_CPUTemp:CURRENT
   FUUID      63b5f087-f33f-1bd5-298a-eccbac96a0f1a88f
   GPLOTFILE  SM_CPUTemp
   LOGDEVICE  FileLog_sysmon
   LOGFILE    CURRENT
   NAME       wl_sysmon_temp
   NR         772
   STATE      initialized
   TYPE       SVG
Attributes:
   group      RPi
   label      "CPU Temperatur: Min $data{min2}, Max $data{max2}, Last $data{currval2}"
   room       Zentral


Wäre das eine Baustelle für den Modulauthor?

Gruß
sTaN
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Wernieman am 05 Januar 2023, 14:21:34
Die Frage währe, wie sieht der Speicher vor und nach der Aktivierung aus ...

z.B. wenn ein Glas fast voll mit Wasser und der nächste Tropfen bring das Glas zum Überlauf ..  ist der Tropfen Schuld oder der Vorherige Inhalt des Glases?
Titel: Antw:Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: sTaN am 05 Januar 2023, 17:26:05
Zitat von: Wernieman am 05 Januar 2023, 14:21:34
Die Frage währe, wie sieht der Speicher vor und nach der Aktivierung aus ...

z.B. wenn ein Glas fast voll mit Wasser und der nächste Tropfen bring das Glas zum Überlauf ..  ist der Tropfen Schuld oder der Vorherige Inhalt des Glases?

Der Speicherverbauch dümpelt vor der Aktivierung immer um die 45-47% herum. Nach Aktivierung nimmt man eine leichte Steigerung war. Derzeit bei 48% nach ca. 30-45 Minuten.
Was man beobachten kann, ist dass MemFree kontinuierlich sinkt und Inactive steigt. Hab mal über SimplePi auf meinem iPhone ein kurzes Video gemacht und ein Bild (vor dem Start mit ca. 15 Minuten Verzug) angehängt. Wenn das überhaupt nach so kurzer Zeit aussagekräftig ist?!

EDIT: Ich glaube das ist es nicht und sieht unauffällig aus, nach knapp einer Stunde ist MemFree wieder bei 445MB und die Auslastung bei 46%...

Ich dachte eher die Fehler im Logfile könnten eine mögliche Ursache des Moduls sein:

2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $free_version in numeric gt (>) at ./FHEM/42_SYSMON.pm line 2313.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $free_version in substitution (s///) at ./FHEM/42_SYSMON.pm line 2312.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $entry in index at ./FHEM/42_SYSMON.pm line 2225.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $val in int at ./FHEM/42_SYSMON.pm line 1804.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/42_SYSMON.pm line 1657.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $string in substitution (s///) at ./FHEM/99_Utils.pm line 130.
2023.01.05 13:45:58 1: PERL WARNING: Use of uninitialized value $string in substitution (s///) at ./FHEM/99_Utils.pm line 129.


Nach dem enablen habe ich auch folgenden Fehler im Logfile:
PERL WARNING: Use of uninitialized value $val in int at ./FHEM/42_SYSMON.pm line 1804.

Gruß
sTaN
Titel: Aw: Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: Tom S am 19 Mai 2023, 22:19:07
Hallo,
ich hatte ebenfalls SYSMON aktiviert und Probleme mit einem stetig zunehmenden Verlust an RAM-Speicher. Auch Meldungen im Log wie zuletzt sTaN sie beschrieben hatte.
Das ging soweit, dass FHEM sich alle paar Tage aufhängte.

Nach disable = 1 ist das Speicherleck verschwunden und auch die merkwürdigen Meldungen im Log.

Merkwürdig: der Filelog, mit dem ich zuvor SYSMON-RAM und —TEMP sowie den wlan0-Datenverkehr geloggt habe wird trotzdem weiter im gleichen Intervall beschrieben wie zuvor, so als ob trotz "disable" da noch etwas abläuft.
Kann mir dazu jemand eine Erklärung geben?

Danke vorab!
Titel: Aw: Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: bismosa am 28 Mai 2023, 18:12:47
Hallo!

Heute Morgen wurde mein FHEM auch aufgrund eines Speichermangels auf meinem Raspberry gekillt. Nach 28 Tagen Laufzeit.
Da die letzten Logeinträge diese sind:
2023.05.28 06:43:14 1: BlockingInformParent (BlockingStart): Can't connect to 127.0.0.1:7072: IO::Socket::INET: connect: Connection refused
2023.05.28 06:43:15 1: BlockingInformParent (BlockingStart): Can't connect to 127.0.0.1:7072: IO::Socket::INET: connect: Connection refused
2023.05.28 06:43:15 1: BlockingInformParent (RPI_1Wire_FinishFn): Can't connect to 127.0.0.1:7072: IO::Socket::INET: connect: Connection refused
2023.05.28 06:43:15 1: BlockingInformParent (RPI_1Wire_FinishFn): Can't connect to 127.0.0.1:7072: IO::Socket::INET: connect: Connection refused
gehe ich davon aus, das dies beim fork passiert sein müsste. Evtl. waren es zu viele gleichzeitig. Wobei ich blockingCallMax auf 3 gesetzt habe.
Generell liege ich aktuell bei ca. 19% Speicherauslastung von FHEM. Also 185MB Reservierten Speicher. Sollte nicht allzu viel sein.
Da muss ich jetzt mal beobachten, ob es einen Speicheranstieg gibt.

Ich habe jetzt hier von analyzeObject gelesen. Scheint mir eine interessante Funktion zu sein, den Speicherbedarf der Module anzeigen zu lassen? Leider finde ich darüber keine weiteren Infos wäre aber sehr interessiert  :) Vielleicht komme ich dann dahinter, wer den meisten Speicher verbraucht...und was ich optimieren kann.
Kann mir jemand weitere Infos dazu geben?
Oder gibt es noch eine andere tolle Möglichkeit den Speicherbedarf zu analysieren?

Gruß
Bismosa
Titel: Aw: Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: DS_Starter am 03 Juni 2023, 08:19:31
Hallo bismosa,

das Modul 98_Analyze.pm kannst du dir aus meinem contrib (Fußtext) downloaden.
Definition einfach mit

 define analyzeData Analyze

Möglicherweise musst du noch Perl Module nachinstallieren.

Dann führst du ein "set analyzeData deviceType <deine Auswahl>" aus und bekommst eine Analyseseite mit den Ergebnsissen. Die ist evtl. sehr unübersichtlich. Beim Schritt mit dem Browser zurück findest du in den Readings die 5 größten Objekte/Hashes sortiert angezeigt.

z.B.
   READINGS:
     2023-06-03 08:04:51   1_largestObject 73151, $defs{Report}
     2023-06-03 08:04:51   2_largestObject 66305, $defs{Report}{READINGS}
     2023-06-03 08:04:51   3_largestObject 26474, $defs{Rep.Show.DbSize}
     2023-06-03 08:04:51   4_largestObject 17197, $defs{Rep.Bezug.Monat.Januar}
     2023-06-03 08:04:51   5_largestObject 13891, $defs{Rep.Show.DbSize}{READINGS}
     2023-06-03 08:04:51   state           done

Was dich interessiert (z.B. $defs{Report} als größtes Objekt) kopierst du und führst damit ein

  set ... xHashDetail $defs{Report}

aus. Dann bekommt man wieder die Ergebnisseite mit Deteilinfomationen. In den Reading hat man dann evtl. weitere Hashes in die man hineingehen kann.

Mit mainHash kann man die Standardhashes wie $attr analysieren. $data wird auch häufig vergessen, läuft etwas unter dem Radar.
Mit dem Attr largeObjectNum kannst du steuern wieviel größte Objekte du dir in den Readings anzeigen lassen willst.

Das Ganze ist etwas experimentell, FHEM kann also auch mal abstürzen. Also bisschen Vorsicht.
set .. allDevices kann u.U. FHEM in die Knie zwingen.
Vielleicht hast du Lust das Modul weiterzuentwickeln, kann ja wirklich hilfreich sein.

Grüße,
Heiko
Titel: Aw: Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: bismosa am 03 Juni 2023, 09:14:16
Moin Heiko,

danke für die Erklärung!
Ich finde das ist ein spannendes Modul und bei der Suche nach Resourcenverschwendern echt hilfreich.

Ich habe bei mir die Squeezebox Player schon länger im Verdacht...da habe ich das mal als erstes ausprobiert:
1_largestObject 1125421, $defs{SB_2}
2_largestObject 1124857, $defs{SB_1}
3_largestObject 1124530, $defs{SB_PLAYER_00042022916d}
4_largestObject 1123967, $defs{SB_3}
5_largestObject 1122418, $defs{SB_4}

Über 1MB pro Gerät. Bei 19 Devices (leider werden die gelegentlich unter einer neuen ID neu angelegt) sind das vermutlich 10% der Speicherauslastung von FHEM  :o

Danke auch für den Hinweis der Abstürze. Ein "get allDevices" lässt mein FHEM sofort neu starten. Dafür ist die Hardware vielleicht zu schwach.

Ich werde mal ein wenig weiter experimentieren.

Gruß
Bismosa
Titel: Aw: Cannot fork: Cannot allocate memory | BlockingInformParent
Beitrag von: bismosa am 07 Juli 2023, 15:32:31
Hallo!

Zitat von: DS_Starter am 03 Juni 2023, 08:19:31Vielleicht hast du Lust das Modul weiterzuentwickeln, kann ja wirklich hilfreich sein.
challenge accepted  8)
Allerdings mehr oder weniger gescheitert.

Ich wollte das Modul ein wenig anders aufziehen. Gerade auch mit dem Hintergrund, das FHEM sehr gerne abstürzt, wenn man mit Devel::Size etwas einliest.
Alle meine Versuche haben hier aber keinen richtigen Erfolg gehabt. Ob nun über eval oder mit nonblocking...wenn dann bleibt es gerne richtig hängen.
Unter Windows funktioniert Devel::Size auch so gut wie nie und stürzt sehr gerne ab.

Entstanden ist ein erster Entwurf, den ich aber vermutlich auch nicht weiterentwickeln werde:
https://github.com/bismosa/FHEM/blob/master/FHEM/98_meminfo.pm

Was ich aber auch eingebaut habe, ist ein Summieren der Variablen-Inhalte (wenn UseDevelSize = 0 gesetzt ist). Das sollte meist proportional zum belegten Speicherplatz sein. Das könnte dann schon einige Hinweise liefern und funktioniert bei mir jetzt ganz ohne Abstürze.

Ein bisschen was kann das Modul aber schon:
DeviceInfo: Hash-Größe von einem Device
TypeInfo: Hash-Größe von allen Devices eines Typs
all: Alle Geräte
- Anzeigen der Variablen-Inhalte-Größe
- Anzeigen der Variablen-Größe (mit Devel::Size wenn aktiviert)
erzeugt in allen Fällen ein nach Größe sortiertes Reading

Dump-Device: Erzeugt ein reading (dump) mit dem hash-Inhalt eines gewählten Gerätes
RAM_Usage: Größe des aktuell verwendeten RAMs in ein Reading schreiben
pmap: Ausgabe des Befehls 'pmap $processID' in ein Reading (Kann auch interessante Hinweise geben!)

Gerne mal auf einem Testsystem ausprobieren! Aber Vorsicht...abstürze sind nicht selten.

Aber: Die Speicherbelegung durch die Geräte ist nur ein sehr kleiner Teil. Sicherlich kann man bei dem ein oder anderem Device (s.o.) ein paar MB sparen.
Deswegen gehe ich gerade einen ganz anderen Weg, der mir mit etwas mühe wesentlich bessere Ergebnisse bereits erbracht hat:
Ich lasse mit dem Modul über "get <device> WriteDEFtoFiles" alle Definitionen als Gerätegruppe in Textdateien schreiben.
Auf einem Testsystem (!!!) habe ich dann mit einer "leeren" Config gestartet und dann Gruppe für Gruppe über RAW-Definition die Geräte hinzugefügt.
Während dessen habe ich mir eine Excel-Tabelle erstellt und den Speicherbedarf (htop) protokolliert.
Da kam dann für mich raus, das z.B. FUIP und RSS (beide eigentlich gar nicht mehr in Verwendung) viel RAM benötigen.
Die Geräte habe ich dann in meinem Produktiv-System entfernt, FHEM neu gestartet und alleine dadurch 61MB weniger Speicherverbrauch. Von 222 auf 168MB runter. Das hilft bei 1GB RAM schon gewaltig.  8)
Zusätzlich gibt es noch optimierungen beim Kalender, SB_Player etc. Da werde ich bestimmt noch ein bisschen was finden.

Vermutlich hätte ich, wenn ich die Ausgabe mittels pmap protokolliert hätte, noch weitere Infos bekommen, warum der Speicherverbrauch bei einigen Modulen so sprunghaft ansteigt.

Weitere Optimierungen muss ich noch testen...aber es spielt wohl auch eine Rolle, welche Abhängigkeiten die einzelnen Geräte zu PERL Modulen ggf. haben. Z.B. hatte ich bei der Testdefinition vom "Installer" einen Sprung von 67MB. Nach entfernen aus meinem System war es nur 1MB.

Interessant wäre es, wenn man beim starten von FHEM nach jedem Device protokollieren könnte, wie viel Speicher in Verwendung ist. Aber soweit ich weiß, werden alle Geräte gleichzeitig definiert...

Aber das wichtigste...nicht mehr benötigte Geräte auch wirklich entfernen und FHEM gelegentlich aufräumen. Das spart am meisten Resourcen  ;)

Gruß
Bismosa