Fhem Absturz jeden Morgen

[vbs]

Da bin ich bei Rudi, glaub ich. Ich bin jetzt wieder bei 1800 offenen Handles, jedoch hat perl.exe nur 30 TCP/IP-Verbindungen offen. Wenn es mit httputils zu tun hätte, dann hätte ich erwartet, dass ich die offenen Handles auch als TCP/IP-Verbindungen wiederfinde.

[Loredo]

Allerdings macht keines der betroffenen Module I/O auf andere Weise... Keiner schreibt Files oder macht andere Sockets auf.

[vbs]

Hm, ich glaub, ich ziehe meine Aussage zurück und glaube jetzt auch an httputils. Windows zeigt mir als Name der ganzen Handles "\Device\Afd\Endpoint" an. Wenn ich diese Seite (http://my.safaribooksonline.com/book/networking/security/9780470613030/memory-forensics-network-and-registry/memory_forensics_colon_network_and_regis) richtig verstehe, dann wird ein Handle auf "\Device\Afd\Endpoint" bereits beim Aufruf von "socket" angelegt. Also sozusagen noch die Vorstufe einer TCP-Verbindung. Taucht deshalb wohl auch nicht in den normalen TCP-Listen auf.
Denke also schon, dass es irgwendas mit Sockets und dann auch gerne etwas mit den httputils zu tun haben kann... Werde mal noch ein paar Sachen testen... Hätte da noch ein paar wilde Theorien...

[betateilchen]

Hm, ich glaub, ich ziehe meine Aussage zurück und glaube jetzt auch an httputils.

Irgendwann kommt jeder drauf. Bestimmt auch Rudi irgendwann

[Loredo]

Fehlt denn in HttpUtils_Connect2 nicht sowas wie

Code Auswählen Erweitern



  $hash->{conn}->close();
  undef $hash->{conn};


am Ende?

Ich meine da steht zwar ein

Code Auswählen Erweitern


  shutdown $hash->{conn}, 1 if(!$hash->{noshutdown} && $hash->{protocol} ne "https");


aber das scheint ja irgendwie nicht zu genügen, damit der Socket vollständig freigegeben wird?

[vbs]

Ich denke, ich weiß jetzt was passiert (und habs hoffentlich auch behoben):
Und zwar tritt es auf wenn httputils den Host _nicht_ erreichen kann. Ist mir aufgefallen, dass die Handles nicht mehr werden, wenn die Dreambox an ist. Vermehren sich jedoch, wenn sie aus ist. Ich denke, dass httputils den Socket nicht korrekt abräumt, wenn der Verbindungsversuch fehlschlägt. Wenn er erfolgreich ist, dann ist alles gut.

Leicht zu reproduzieren in dem man eine nicht-existente IP angibt für das ENIGMA Modul. Zb.

Code Auswählen Erweitern

define dm7020hd ENIGMA2 192.168.2.9

Jetzt hab ich noch das verwendete Interval in ENIGMA2_GetStatus auf 1 gesetzt, so dass er sich jede Sekunde verbinden will. Und siehe da: jede Sekunde ein Handle mehr.

Als Fix hab ich jetzt in diese Funktionen ein close eingebaut:

Code Auswählen Erweitern

sub
HttpUtils_ConnErr($)
{
  my ($hash) = @_;
  if(defined($hash->{FD})) {
    delete($hash->{FD});
    delete($selectlist{$hash});
--->$hash->{conn}->close();    <-----------
    $hash->{callback}($hash, "connect to $hash->{addr} timed out", "");
  }
}


(Ich vermute, dass das gleiche Problem in der Funktion "ReadErr" direkt da drunter ebenso besteht, weil es nach kopiertem Code aussieht. Ist aber nur geraten.)

Ich bin ziemlicher perl-Newbie. Ist close überhaupt korrekt? Oder muss es ein undef sein? Klappt beides. Evtl. isses egal
Könnt ihr ja bei euch mal probieren, ob es bei euch auch hilft.

[rudolfkoenig]

@vbs: danke fuer den Patch, habs gerade eingecheckt. shutdown ist kein Ersatz fuer close, s.u. Wenn dieser Fix hilft, dann sollte man aber die naechsten Probleme angehen: es wird nur bei haeufigen Timeouts ausgeloest.

@Loredo: danke fuer den Hinweis auf diese Diskussion, sehr amuesant.

shutdown(1) signalisiert der anderen Seite via TCP Protokoll, dass von meiner Seite nichts mehr kommt, indem mein Schreibkanal (fuer den Server Lesekanal) schliesst, nachdem die Frage an dem Server gestellt wurde. Korrekt gebaute Server beantworten meine Frage, und schliessen danach auch deren Schreibkanal (mein Lesekanal). Dadurch kann FHEM es einfach rausfinden, dass nichts mehr kommt, und dass es nicht laenger warten muss. Ohne diesen Feature muss FHEM die hoeheren Schichten auch kennen, um zu wissen, wie lange die Antwort ist (steht im HTTP Header). Mit shutdown ist HttpUtils einfacher, und funktioniert auch fuer nicht-HTTP Protokolle. HttpUtils hat aber nach dem Rewrite etwas HTTP gelernt, und liest bei noshutdown die Laenge der Antwort aus dem HTTP Header. Also ist der noshutdown Parameter nicht Client sondern Server abhaengig, z.Bsp. ist der Http-Server der Fritzbox fehlerhaft was shutdown betrifft.

Wenn jemand fuer mich reproduzierbar zeigt, dass HttpUtils einen Fehler hat, dann versuche ich das zu fixen, nachvollziehbare patches sind mir natuerlich lieber. Wer jemand was anderes (LWP) verwendet, habe ich auch kein Problem damit. Im Fall von betateilchen wollte ich kein Google-Calendar anlegen (und die Eigenheiten von Google-Calendar+FHEM Modul lernen), insb. wo mind. zwei andere FHEM-Google-Calendar Benutzer kein Problem mit HttpUtils haben. Falls noshutdown betateilchens Problem beheben wuerde, dann haette ich es als Voreinstellung schon gesetzt, das half aber auch nicht.

[betateilchen]

Im Fall von betateilchen wollte ich kein Google-Calendar anlegen (und die Eigenheiten von Google-Calendar+FHEM Modul lernen), insb. wo mind. zwei andere FHEM-Google-Calendar Benutzer kein Problem mit HttpUtils haben.

Es ist ja in der Tat noch schlimmer: Es ist ja nicht so, dass (nur) ich das Problem habe. Ich habe das Problem auf MANCHEN Hardwareplattformen innerhalb meines Netzwerkes. Und das richtig dubiose ist, dass ich auf einer Hardwareplattform das Problem an MEINEM Internetanschluß habe, sobald ich diese Hardware aber mit zu meiner Freundin nehme und dort anschließe, funktionieren auch die HttpUtils.

Ich sage nicht, dass die HttpUtils "schuld" sind - aber sie verursachen das Problem eben dadurch, dass sie fhem-weit genutzt werden (sollen). Die tatsächliche Ursache muss m.E. aber viel tiefer in der Kommunikation liegen. Wie man da wirklich effektiv weiterkommt, weiß ich auch nicht.

@Loredo: danke fuer den Hinweis auf diese Diskussion, sehr amuesant.

Apropos Hinweise auf amüsante Diskussionen - hast Du die Diskussion bezüglich global attr motd schon gelesen?

[marvin78]

Ehrlich gesagt, sind manche der Diskussionen hier schon eher traurig als amüsant.

[betateilchen]

das stimmt leider.

[cornelius fillmore]

Hallo zusammen, seit einigen Tagen habe ich das gleiche Problem.

Das log-file wird zugemüllt und nichts geht mehr.

Code Auswählen Erweitern

2014.08.11 06:45:00 2: FHT set FHT_Bad desired-temp 20.0
2014.08.11 07:00:00 2: IT set WLAN on
2014.08.11 07:30:00 2: IT set Lueftung on
2014.08.11 08:00:00 2: FHT set FHT_Essen desired-temp 17.0
2014.08.11 08:29:48 1: Accept failed (WEBphone: Too many open files)
2014.08.11 08:29:48 1: Accept failed (WEBphone: Too many open files)
2014.08.11 08:29:48 1: Accept failed (WEBphone: Too many open files)
2014.08.11 08:29:48 1: Accept failed (WEBphone: Too many open files)
2014.08.11 08:29:48 1: Accept failed (WEBphone: Too many open files)
2014.08.11 08:29:48 1: Accept failed (WEBphone: Too many open files)
2014.08.11 08:29:48 1: Accept failed (WEBphone: Too many open files)
2014.08.11 08:29:48 1: Accept failed (WEBphone: Too many open files)
2014.08.11 08:29:48 1: Accept failed (WEBphone: Too many open files)
2014.08.11 08:29:48 1: Accept failed (WEBphone: Too many open files)

Hat einer da eine Lösung für parat?

[rudolfkoenig]

Wuesste gerne was schiefgeht, kannst Du bitte die Ausgabe von

Code Auswählen Erweitern

list .* FD
hier anhaengen?
Falls die meisten Eintraege mit FHEMWEB anfangen, dann koennte "attr TYPE=FHEMWEB closeConn" helfen.

[cornelius fillmore]

O.K.

anbei der Auszug

Code Auswählen Erweitern

COC                  11
CUNO                 23
FHEMWEB:192.168.0.36:51122 19
FHEMWEB:192.168.0.36:51167 18
FHEMWEB:192.168.0.36:51168 20
FHEMWEB:192.168.0.36:51169 21
FHEMWEB:192.168.0.36:51170 22
WEB                  7
WEBphone             8
WEBtablet            9
telnetPort           6

Hilft das?

[rudolfkoenig]

Nicht wirklich, 11 benutzte FD's ist nichts besonderes.
Ich korrigiere: ich haette gerne diese Liste in Problemfall. Falls dann mit FHEM nicht zu reden ist, dann ein "lsof -p <fhempid>" oder "ls /proc/<fhempid>/fd" von der Kommandozeile.

[cornelius fillmore]

Wir gemacht.
Ich melde mich sobald es wieder Auftritt.

So Fhem wieder down, anbei die Liste.

Code Auswählen Erweitern


root@raspberrypi:/home/pi# ls -l /proc/10802/fd
insgesamt 0
lr-x------ 1 root root 64 Aug 12 11:09 0 -> /dev/null
l-wx------ 1 root root 64 Aug 12 11:09 1 -> /dev/null
lrwx------ 1 root root 64 Aug 12 11:09 10 -> anon_inode:[eventpoll]
l-wx------ 1 root root 64 Aug 12 11:09 2 -> /var/log/apache2/error.log
lrwx------ 1 root root 64 Aug 12 11:09 3 -> socket:[2562]
lrwx------ 1 root root 64 Aug 12 11:09 4 -> socket:[2564]
lr-x------ 1 root root 64 Aug 12 11:09 5 -> pipe:[2578]
l-wx------ 1 root root 64 Aug 12 11:09 6 -> pipe:[2578]
l-wx------ 1 root root 64 Aug 12 11:09 7 -> /var/log/apache2/other_vhosts_access.log
l-wx------ 1 root root 64 Aug 12 11:09 8 -> /var/log/apache2/access.log
l-wx------ 1 root root 64 Aug 12 11:09 9 -> /run/apache2/ssl_mutex (deleted)
root@raspberrypi:/home/pi# root@raspberrypi:/home/pi# ls -l /proc/10802/fd

Hilft das weiter?

Bzw. wie bekomme ich denn die fhempid heraus?