[gelöst] FHEM: Prozesse starten nicht

[alru]

Moin,

Seit ein paar Wochen hat meine Fhem Instanz Probleme bei der Ausführung von folgenden Prozessen:

• Shutdown reboot (es wird nur das shutdown ausgeführt, nicht das reboot, der Fhem Prozess muss dann über die Konsole gestartet werden)
• Fhem backup (Das Backup wird gestartet, aber keine Datei erzeugt, im Log erscheint auch kein "Backup done", der Pfad ist auch beschreibbar)
• Shell Script mit Perl-Befehl "system" starten (es wird nur –1 zurück gegeben)

Nach einem Fhem-Reboot geht immer wieder alles, nach ein paar Tagen merke ich dann (bez. meine Backup-Überwachung), dass es wieder nicht läuft.

Das Fhem-Log und die Raspi-Logs geben keinerlei Hinweise. Ich habe die Version 16813 (vom 3.6.18) am Laufen. Alle anderen Funktionen in FHEM laufen ohne erkennbare Probleme.

Jemand eine Idee?

[betateilchen]

klingt mir nach einem Rechte-Problem.

[alru]

klingt mir nach einem Rechte-Problem.

Das war auch mein erster Gedanke. Die wurden nach dem ersten Ausfall auch überprüft, obwohl sie nie geändert wurden, war aber alles i.O. Außerdem: Wieso geht dann nach einem FHEM Reboot wieder alles? Wo und wie gehen denn dadurch Rechte verloren und werden wieder gesetzt?

[Amenophis86]

Von FHEM aus werden keine Rechte geändert, daher müsste der Fehler woanders liegen. Aber mit den vorhandenen Infos lässt sich da wenig machen.

[alru]

... Aber mit den vorhandenen Infos lässt sich da wenig machen.

Welche Infos würden denn helfen?

[Amenophis86]

https://tty1.net/smart-questions_de.html#intro
https://forum.fhem.de/index.php/topic,71806.0.html
Was steht im FHEM Log, was steht im Log des Geräts auf dem FHEM läuft?
Wie sehen die Rechte aktuell aus?
"(bez. meine Backup-Überwachung), dass es wieder nicht läuft. " was genau heißt das?

Du beschriebst zwar was wo sein sollte bzw. stehen könnte, aber oft hilft es die Fehler / Meldungen hier zu posten und nicht nur zu sagen "Kein Hinweis" / "Steht nichts". Vielleicht für dich kein Hinweis, aber für andere zu erkennen

[alru]

Moin,

ok, ich versuche dann mal mehr Infos zu geben:

FHEM-Log:

Eintrag für den Backup-Befehl:

Code Auswählen Erweitern

2018.07.01 01:00:00 2: Backup with command: tar -cf - "./certs" "./CHANGED" "./configDB.pm" "./contrib" "./demolog" "./docs" "./FHEM" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.pl" "./FRITZ.Box_Telefonbuch.xml" "./lescan.sh" "./log" "./MAINTAINER.txt" "./README_DEMO.txt" "./regSave.cfg" "./restoreDir" "./unused" "./www" |gzip > ./backup/FHEM-20180701_010000.tar.gz
2018.07.01 01:00:00 3: fhem_backup: Started the backup in the background, watch the log for details

Danach kommt nix mehr zum Thema Backup und es liegt auch keine Datei im Pfad

Notify für eine Shell-Script Ausführung:

Code Auswählen Erweitern

1.Treppe.Post2:open.*
{
sleep(0.8);
system('sudo /home/pi/scripts/wc2copy&');
}

Erzeugt folgenden Log-Eintrag:

Code Auswählen Erweitern

2018.07.01 14:18:45 3: 1.Treppe.Post2.wc2copy return value: -1

Das Script hat die Rechte pi/pi (Standard-User). In der sudoers sind fhem/dialout eingetragen, um dieses Script ausführen zu dürfen.

Meine "Backup-Überwachung" sieht ganz einfach so aus, dass ich jede Nacht ein Script laufen habe, dass das lokal gespeicherte FHEM-Backup-File auf meinen NAS verschiebt. Wenn keine Datei vorliegt, dann bekomme ich eine Notification.

An die Raspi-Logs komme ich aus Zeitgründen gerade nicht ran, das versuche ich heute Abend noch mal.

Wenn das nicht hilft, bitte noch mal einen kurzen Tip geben, was nötig ist. Danke!

[betateilchen]

Der return Wert -1 bei einem Shell Aufruf ist völlig normal.

[frank]

fhem.log wird ggf informativer, wenn du global verbose erhöhst.

[alru]

Moin,

ich hab jetzt erst mal den global verbose Level auf 5 gesetzt. Den Zeitpunkt vom letzten Ausfall konnte ich nicht mehr genau genug eingrenzen. Ich warte jetzt also auf den nächsten Ausfall...

[alru]

Moin,

so, die Fehlermeldung im fhem Log

Code Auswählen Erweitern

Cannot fork: Cannot allocate memory
hat mich dann zur Ursache geführt: Der Speicher vom Raspi war knapp 50% mit dem fhem-perl Prozess gefüllt. Da dieser alle paar Minuten noch einen zweiten Prozess startet, mit der gleichen Speicheranforderung, ging dann nix mehr.

Ich habe dann nacheinander die zuletzt installierten Module deaktiviert, bis ich den "Schuldigen" gefunden habe: 17_SIRD.pm , der noch zu den "inoffiziellen" Modulen gehört und bei dem ich zeitweise mit teste (soll man ja auch nicht machen, auf einem Produktionssystem, weiß ich ...). Das Modul hat pro Tag einen Zuwachs von ca. 8% an Speicherbelegung erzeugt.

Ich werde jetzt mal mit meinem Problem im Thread https://forum.fhem.de/index.php/topic,79168.0.html weiter machen.