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
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.
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).
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.
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.
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.
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.
OK - dann werde ich wohl erst einmal mit dem Workaround leben müssen.
Gruß Romoker