GDS-Modul verursacht zu viele offene Files

Begonnen von Romoker, 13 März 2015, 17:50:50

Vorheriges Thema - Nächstes Thema

Romoker

Hallo zusammen,

das GDS-Modul hat bisher gut funktioniert. Seit ein paar Tagen stelle ich aber fest, dass die Anzahl offener Files permanent ansteigt. Auslöser ist das GDS-Modul:
root@bbb1:/proc/sys/net/ipv4# lsof -p 1274 | grep CLOSE_WAIT
perl    1274 fhem    5u  IPv4      11112      0t0    TCP bbb1.fritz.box:49191->ftp-outgoing2.dwd.de:ftp (CLOSE_WAIT)
perl    1274 fhem   55u  IPv4      11115      0t0    TCP bbb1.fritz.box:51386->ftp-outgoing2.dwd.de:ftp-data (CLOSE_WAIT)
perl    1274 fhem   56u  IPv4      19747      0t0    TCP bbb1.fritz.box:49213->ftp-outgoing2.dwd.de:ftp (CLOSE_WAIT)
perl    1274 fhem   58u  IPv4      19750      0t0    TCP bbb1.fritz.box:45660->ftp-outgoing2.dwd.de:ftp-data (CLOSE_WAIT)
perl    1274 fhem   60u  IPv4      22486      0t0    TCP bbb1.fritz.box:46332->ftp-outgoing2.dwd.de:ftp-data (CLOSE_WAIT)

Wenn die max. Grenze offener Files (hier 1024) für Fhem erreicht ist, wird das Log vollgeschrieben und Fhem ist blockiert.

Auslöser ist die GDS-Instanz, muss aber nicht die Ursache sein.
Fhem ist auf den neuesten Stand und läuft auf einem Beaglebone Black. Als Router fungiert meine FB 7490 (Firmwarelevel 6.24).

Hat jemand eine Idee, wie ich das Problem in den Griff bekommen kann?

Vielen Dank
Romoker
BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

betateilchen

#1
Zitat von: Romoker am 13 März 2015, 17:50:50
Hat jemand eine Idee, wie ich das Problem in den Griff bekommen kann?

ja, schmeiß die Fritzbox in die Tonne...

Oder setze mal das Attribut gdsPassiveFtp in Deiner gds Instanz auf 1 und teste nochmal.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Romoker

ZitatOder setze mal das Attribut gdsPassiveFtp in Deiner gds Instanz auf 1 und teste nochmal.

Das Setzten des Attributes hat keine Verbesserung gebracht. Die Anzahl offener Files wächst weiter. Ich kann natürlich Fhem periodisch neu starten, aber ich würde lieber die Ursache des Problems beseitigen (in die Tonne werfen geht nicht).
BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

betateilchen

Die Ursache des Problems ist die Fritzbox - und das Problem ist nicht neu und nicht auf ftp beschränkt.

http://forum.fhem.de/index.php/topic,28299.0.html

Du kannst Dir einen cronjob definieren, der auf Betriebssysteme die toten Verbindungen beseitigt:

netstat -anp | grep ':21 ' | grep CLOSE_WAIT | awk '{print $7}' | cut -d \/ -f1 | grep -oE "[[:digit:]]{1,}" | xargs kill

das grep ':21' ist der FTP port, eventuell musst Du auch noch den port 20 kontrollieren.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Romoker

Dein Kommando filtert in meiner Umgebung die PID des fhem-Prozesses und schiesst ihn ab. Damit sind die offenen Files beseitigt.
Den Workaround werde ich wohl über eine at-Steuerung realisieren, die bei der Ausführung prüft, ob eine grenzwertige Anzahl offener Files vorhanden ist und dann einen "shutdown reboot" durchführt. Aber Danke für den Tipp.

Was mach Dich so sicher, dass die FB das Problem ist? Ich nutze andere fhemWeb-Module wie HTTPMOD oder Weather, mit denen ich keine Probleme habe.

Ich bin kein Experte, aber im Netz finde ich z.B. als Erklärung von CLOSE_WAIT:
ZitatCLOSE_WAIT means that the local end of the connection has received a FIN from the other end, but the OS is waiting for the program at the local end to actually close its connection.
The problem is your program running on the local machine is not closing the socket. It is not a TCP tuning issue. A connection can (and quite correctly) stay in CLOSE_WAIT forever while the program holds the connection open.
Das hört sich mehr danach an, dass das Program, in meinem Fall fhem.gds, die Verbindung offen hält, vorausgesetzt, die obige Erklärung stimmt.
BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

betateilchen

Wie ich auf die Fritzkotz als Ursache komme, kannst Du in meinem bereits verlinkten Thread nachlesen. Ausserdem habe ich inzwischen ca. 10 Jahre Erfahrungen mit diesen Schrottkisten, bei denen immer wieder die merkwürdigsten Netzwerkprobleme auftraten und letztendlich immer die Hardware die Ursache war.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: Romoker am 14 März 2015, 20:41:30
Das hört sich mehr danach an, dass das Program, in meinem Fall fhem.gds, die Verbindung offen hält,

Das GDS Modul schickt nach Beendigung des Datentransfers wie vorgeschrieben ein ftp->quit(). Da wird nichts offengehalten.

Zitat von: Net::FTP
quit ()
Send the QUIT command to the remote FTP server and close the socket connection.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Romoker

OK - dann werde ich wohl erst einmal mit dem Workaround leben müssen.

Gruß Romoker
BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT