Cannot fork: Cannot allocate memory | BlockingInformParent

Begonnen von Burny4600, 14 Februar 2018, 10:33:06

Vorheriges Thema - Nächstes Thema

xgadscu

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
FHEM auf ODROID-HC1 (Docker-Container) - HMLAN, CUL433, CUNX mit Pigator (868 + 433 MHZ).
HomeMatic Schalter, Heizkörperventile, Sensoren, Rauchmelder
Shelly Schalter, Steckdosen, Flood
IT Funkschalter und Schaltsteckdosen (V1 und V3)
Sonos, Somfy Rolladen

burgi110

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

#############


rudolfkoenig

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.

Wernieman

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 ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dancatt

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
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

dancatt

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.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

tobi01001

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:

  • in Fhem: shutdown
  • in der fhem.save nahezu alles gelöscht (bis auf states die mir wichitg erschienen und nicht durch ein moduel/device wieder aktuell gesetzt werden
  • sudo /etc/init.d/fhem start
... 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

FHEM@UbuntuServer on Lenovo ThinkCentre M900 [i5-6500T / 8GB RAM] MySQL-DbLog, Grafana, FTUI3 / HmIP incl. CCU3 / LGESS / Wärempumpe über TA CMI und CANoE / Shellies u.v.m.

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

tobi01001

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 ;-)
FHEM@UbuntuServer on Lenovo ThinkCentre M900 [i5-6500T / 8GB RAM] MySQL-DbLog, Grafana, FTUI3 / HmIP incl. CCU3 / LGESS / Wärempumpe über TA CMI und CANoE / Shellies u.v.m.

rudolfkoenig

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.

tobi01001

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.
FHEM@UbuntuServer on Lenovo ThinkCentre M900 [i5-6500T / 8GB RAM] MySQL-DbLog, Grafana, FTUI3 / HmIP incl. CCU3 / LGESS / Wärempumpe über TA CMI und CANoE / Shellies u.v.m.

vbs

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?

rudolfkoenig

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.

vbs

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.

vbs

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.