Hallo zusammen,
ich habe jeden ein Fhemabsturz. Wenn ich dann in die Lagdatei reinschauen steht dort stundenlang diese
2014.01.25 08:47:50 1: Accept failed (WEB: Too many open files)
Fehlermeldung drin. Das läuft dann durch bis ca. kurz vor 9 Uhr und danach scheint es wohl abzustürzen. Habe das jetzt den zweiten Tag. Könnt ihr mir hiermit weiterhelfen? Braucht ihr noch weitere Daten?
Wenn das FHEM-Log recht groß wird, stürzt FHEM ab. Such mal nach der Ursache, warum er dir das Log so vollmüllt.
Hallo,
ZitatWenn das FHEM-Log recht groß wird, stürzt FHEM ab.
Sorry kann ich so nicht zustimmen.
Ich mach ein monatliches FHEM-LogFile das mitunter recht "umfangreich" wird aber FHEM stürzt deswegen bei mir nicht ab.
Ok. FHEM stürzt bei mir auch so nicht ab.
@holzwurm
Hier wäre nun eine Signatur mit deiner Hardware und FHEM-Installation interessant.
Grüße
Hallo Puschel74, was meinst du damit genau? Kann dir nicht ganz folgen.
Sent from my iPod touch using Tapatalk
Lies dir mal Puschels Beitrag durch.
Besonders die letzten Zeilen.
Damit weiß jeder, was er für Hardware einsetzt.
Wenn du bei deinem Benutzprofil in die Signatur (das ist das nämlich), die gleichen Infos von dir preis gibst, muss man nicht raten was du benutzt. Das könnte bei der Fehlersuche echt helfen.
Übrigens habe ich auch keine Probleme mit großen Logfiles.
Deine Fehlermeldung deutet auch nicht auf eine zu große Datei hin! Sondern auf zu viele???
Hallo,
Zitat2014.01.25 08:47:50 1: Accept failed (WEB: Too many open files)
Ich weiß aber nicht ob das auf Logfiles hindeutet.
Ich würde eher sagen irgendwer oder irgendwas öffnet einfach zuviele Files.
Welche das aber sind erschliesst sich mir nicht.
Vielleicht wären auch hier mal mehr als eine Zeile aus dem Logfile interessant - aber nicht unbedingt das gesamte! Logfile.
Da wir aber noch nicht wissen auf welcher Hardware mit welcher Installation FHEM läuft ist hier erstmal Rätselraten angesagt.
Grüße
Ok, danke! Jetzt hab ich es verstanden! Daten kommen gleich!
Sent from my iPod touch using Tapatalk
Ich habe Fhem 5.5 mit allen aktuellen updates am lauen. Hatte als erstes ein update durchgeführt als das Problem aufkam.
Hardware habe ich folgendes:
- Fhem auf einem MacMini Server mit DBLog
- CULHM
- CUNO2 für FS20
- HM485 Wired von Dirk
Das Log-File liegt jetzt bei 900 MB für diesen Monat.
Einmal gibt es wohl das Problem das irgendwas in die DB Loggen will aber nicht kann da die Zeile zu kurz ist. Ich habe die Zeichen bereits auf 16884 erweitert.
2014.01.26 07:34:45 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2014.01.26 07:34:45 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 620
2014.01.26 07:34:45 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2014.01.26 07:34:59 2: DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'VALUE' at row 1 at /Users/mediaserver/fhem/FHEM/93_DbLog.pm line 433.
2014.01.26 07:34:59 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2014.01.26 07:34:59 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 620
2014.01.26 07:34:59 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2014.01.26 07:35:05 2: DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'VALUE' at row 1 at /Users/mediaserver/fhem/FHEM/93_DbLog.pm line 433.
2014.01.26 07:35:05 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2014.01.26 07:35:05 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 620
2014.01.26 07:35:05 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2014.01.26 07:35:15 2: DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'VALUE' at row 1 at /Users/mediaserver/fhem/FHEM/93_DbLog.pm line 433.
2014.01.26 07:35:15 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2014.01.26 07:35:15 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 620
2014.01.26 07:35:15 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2014.01.26 07:35:53 2: DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'VALUE' at row 1 at /Users/mediaserver/fhem/FHEM/93_DbLog.pm line 433.
Dann geht es irgendwann los mit folgendem Log
2014.01.26 06:35:57 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:58 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:58 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:58 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:58 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:58 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:58 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:58 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:58 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:58 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:59 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:59 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:59 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:59 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:59 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:59 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:59 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:59 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:35:59 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:36:00 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:36:00 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:36:00 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:36:00 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:36:00 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:36:00 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:36:00 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:36:00 1: Accept failed (WEBtablet: Too many open files)
2014.01.26 06:36:00 1: Accept failed (WEBtablet: Too many open files)
Das war heute morgen zum ersten mal auffällig
2014.01.26 06:37:59 1: readingsUpdate(iTunes,currentAlbumArtURI,) missed to call readingsBeginUpdate first.
2014.01.26 06:38:59 4: iTunes: updater Disconnected
2014.01.26 06:38:59 3: $VAR1 = 'error:404';
2014.01.26 06:38:59 3: iTunes: updater connected to 192.168.6.10:3689
2014.01.26 06:38:59 5: 1
2014.01.26 06:38:59 4: $VAR1 = {
'cmst' => {
'cavs' => 0,
'cafs' => 0,
'ceQu' => 0,
'caar' => 0,
'cafe' => 0,
'caps' => 2,
'cave' => 0,
'caas' => 0,
'mstt' => 200,
'carp' => 2,
'casu' => 0,
'cmsr' => 18,
'cash' => 0,
'cavc' => 1
}
};
2014.01.26 06:38:59 1: readingsUpdate(iTunes,currentAlbumArtURI,) missed to call readingsBeginUpdate first.
2014.01.26 06:38:59 1: readingsUpdate(iTunes,state,stop) missed to call readingsBeginUpdate first.
2014.01.26 06:38:59 4: iTunes: updater Disconnected
2014.01.26 06:38:59 3: iTunes: updater connected to 192.168.6.10:3689
2014.01.26 06:38:59 5: 18
2014.01.26 06:38:59 4: $VAR1 = {};
Du versucht nicht zufällig deine Musiksammlung in die Datenbank mit auf zu nehmen?
Außerdem sin 900MB Lgfile echt zu viel :)
Irgend etwas das du in deimer fhem.cfg konfiguriert hast, scheint unglaublich viel in dblog schreiben zu wollen, und obendrein zu viel.
Ohne fhem.cfg wird es schwierig fürchte ich.
Und, wenn du deine Daten in die Signatur tust, muss man nicht diesen Thread suchen wenn man sie mal wieder wissen will :)
das iTunes Modul läuft schon seit Monaten bei mir. Daran habe ich nichts bewusst geändert.
Ich poste mal meine fhem.cfg
Die Signatur werde ich anpassen!
hab jetzt mal bei dem iTunes Modul DbLogExclude gesetzt, aber der lange Log ist immer noch da.
Hallo,
da ich weder einen Mac habe noch iTunes benutze bin ich leider raus - sorry.
Evtl. hat ja noch jemand anders eine Idee für dich.
Grüße
Hallo Holzwurm,
Hast du das Problem mittlerweile schon gelöst?
Ich hab seit heute Morgen auch solche Meldungen im Log. FHEM macht im Hintergrund weiter, FHEMWEB und telnet funktionieren aber nicht mehr. Ich muss dann, wenn ich unterwegs bin, den MacMini per ssh neustarten.
2014.02.25 06:22:11.265 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:11.542 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:11.607 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:11.669 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:11.731 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:11.788 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:11.844 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:24.748 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:24.887 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:24.948 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:25.005 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:25.062 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:26.000 3: ENIGMA2 device wzReceiver is unavailable
2014.02.25 06:22:56.000 3: ENIGMA2 device wzReceiver is unavailable
2014.02.25 06:22:56.828 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:56.963 1: Accept failed (WEBphone: Too many open files)
2014.02.25 06:22:57.027 1: Accept failed (WEBphone: Too many open files)
Eventuell hängt es bei mir mit dem enigma Modul zusammen. Hab da auch schon mal nachgefragt. (http://forum.fhem.de/index.php/topic,14792.msg142441.html#msg142441)
Grüße
Ich habe das Problem nicht mehr, aber so richtig rausgefunden woran das lag habe ich auch nicht. Ich hatte die Vermutung das es an der Fullscreen Browser App von Dirk lag, da ich Sie immer offen hatte.
Ich habe auch immer in eine Datenbank geloggt und hatte da auch Probleme. Die Datenbank liegt bei mir momentan auf Eis.
So richtig kann ich dir da nichts sagen. Ich habe die aktuelle Fullscreen Browser App am laufen und habe sonst jetzt keine Probleme.
Hallo,
webViewControl läuft bei mir 24/7 am Tablet und in die DB logge ich auch ALLE Daten die anfallen.
Aber mein FHEM hat sich deswegen noch nie verabschiedet.
Zwischendurch greife ich per Laptop, PC und Tablet auf FHEM (am RasPi) zu und ich habe absolut keine Probleme.
Grüße
So, habe gerade mal meine Datenbank wieder eingeschaltet. Bis jetzt sieht es gut aus. Wenn es jetzt laufen sollte, muss es irgendwo ein Bug gewesen sein, da ich nur alles aktualisiert habe.
Anstatt Neustart würde ich nach einem Absturz empfehlen, ich durch die einschlägigen Logfiles zu grappen. Alternativ per sysmon sich die Auslastung des Servers mitloggen lassen ....
An der Auslastung kann es nicht liegen. FHEM läuft auf einem Quadcore i7 MacMini mit 16GB RAM.
Naja ich hoffe das es an dem enigma Modul lag, den fix für den log gibts seit heute morgen mit dem update.
Wenn kurz vor dem Absturz z.B. die CPU-Last hochging (kurzer, kleiner Peak reicht), weist Du auch schon etwas. Wenn nicht in der Richtung passiert .... habe hier deshalb auf einem AMD 5050x Doppelprozi es auch laufen.
Ich beobachte das Problem seit ein paar Tagen jetzt auch auf einer Installation auf einer Fritzbox 7490.
Im Log scheint alles unauffällig. Plötzlich kommen 3 Meldungen der HUEBridge, dass man sich nicht verbinden könne, und dann geht es schon los:
2014.03.03 19:17:02 1: HUEBridge_HTTP_Request http://192.168.50.91/api/c10b113d24164b4cde27858f65bbb50c/lights/1: Can't connect to http://192.168.50.91:80
2014.03.03 19:17:02 1: HUEBridge_HTTP_Request http://192.168.50.91/api/c10b113d24164b4cde27858f65bbb50c/lights/2: Can't connect to http://192.168.50.91:80
2014.03.03 19:17:03 1: HUEBridge_HTTP_Request http://192.168.50.91/api/c10b113d24164b4cde27858f65bbb50c/lights/3: Can't connect to http://192.168.50.91:80
2014.03.03 19:17:45 1: Accept failed (telnetPort: Too many open files)
2014.03.03 19:17:45 1: Accept failed (telnetPort: Too many open files)
2014.03.03 19:17:45 1: Accept failed (telnetPort: Too many open files)
Das Logfile wächst dann innerhalb kürzester Zeit enorm an, bei 18 MB ist wohl irgendwie Schluss...
Da ich gestern erst das Logfile gelöscht habe kann ich sagen: Die Accept Failed Meldungen machen 99,9999% der Größe aus.
Hat jemand schon eine Lösung? :-(
PS: Was ich vor kurzem eingefügt habe, ist ein AT-Job mit einem simplen "save" Kommando alle 15 Minuten. Was kann das damit zu tun haben?
Hallo Loredo,
ich hatte jetzt Testweise das Enigma Modul einige Tage deaktiviert. Keine Ausfälle. Gestern Nacht hab ich das Modul wieder reingenommen und geraden eben
2014.03.04 13:53:38.211 1: Accept failed (WEB: Too many open files)
2014.03.04 13:53:38.216 1: Accept failed (WEB: Too many open files)
2014.03.04 13:53:38.221 1: Accept failed (WEB: Too many open files)
Meinst du das hängt irgendwie zusammen?
Grüße
Too many open files
was sagen denn die Linux-Logfiles?
Zitat von: Wernieman am 04 März 2014, 14:09:07
was sagen denn die Linux-Logfiles?
Keine Ahnung, verwende einen MacMini. Weisst du wo ich die finde?
Auf einem RaspberryPi habe ich das Problem nicht.
Ich könnte mir nicht erklären, wie das ENIGMA2 Modul dazu beitragen könnte. Es schreibt keine Dateien und inzwischen pollt es auch non-blocking. Andere Module pollen ebenso, ich denke nicht, dass es am Modul liegt. Vielleicht an den HttpUtils von FHEM, erscheint mir aber auch unwahrscheinlich...
Ok. Eigenartig. Die abstürze hatte ich immer nur wenn das enigma Modul definiert war, Fehlermeldungen gibts aber keine mehr.
Hab jetzt erstmal das Modul wieder rausgenommen. Ich bin von morgen bis Samstag nicht da, anschließend werde ich das nochmal testen.
Grüße
Die Logfiles für MAC kenne ich auch nicht. Würde aber auf die Unix-Typischen /var/log tippen ... oder Apple macht mal wieder was eigenes
Zitat von: Wernieman am 04 März 2014, 15:03:18
Die Logfiles für MAC kenne ich auch nicht. Würde aber auf die Unix-Typischen /var/log tippen ... oder Apple macht mal wieder was eigenes
Es sind die gleichen. Man Kann sie aber bequem im Programm "Konsole" bzw. "Console" betrachten.
Ähnliche Situationen habe ich schon oft gesehen, wenn die Programme nicht sauber Dateien wieder geschlossen haben (ob nur Lesen oder auch Schreibzugriff ist egal).
Unter Linux hätte ich mit sudo lsof -p <PID des FHEM-Prozesses> nachgesehen, welche Datein der Prozess offen hält. k.A. ob dieses Prog. auch für Apfel verfügbar ist...
Es ist.
Zitat von: fhainz am 04 März 2014, 14:11:13
Keine Ahnung, verwende einen MacMini. Weisst du wo ich die finde?
In Spotlight "Konsole" eingeben, dann sollte unter Programme das selbige erscheinen. Wenn du die Konsole geöffnet hast, kannst Du dich durch zig Logfiles pflügen. Glück auf.
ZitatUnter Linux hätte ich mit sudo lsof -p <PID des FHEM-Prozesses> nachgesehen, welche Datein der Prozess offen hält. k.A. ob dieses Prog. auch für Apfel verfügbar ist...
Dafür gibt's die Aktivitätsanzeige.
Zitat von: dafex am 04 März 2014, 17:36:08
Dafür gibt's die Aktivitätsanzeige.
für Weicheier und Mausschubser... 8)
Zitat von: betateilchen am 04 März 2014, 19:17:24
für Weicheier und Mausschubser... 8)
Für Weicheier vielleicht. Mein Mäuschen darf sich aber meistens ausruhen. Das meiste geht ohne. Wie im richtigen Leben auch ... 8)
Was das ENIGMA2 Modul angeht: Ich habe nochmals nachgedacht und geschaut. Es wäre möglich, dass die Nutzung von noshutdown=1 auf der Fritzbox dazu führt, dass geöffnete TCP Verbindungen nicht geschlossen werden und es somit irgendwann zu einem Überlauf kommt. Auf normalen Linux Plattformen ist ein explizites Shutdown der Verbindung nicht unbedingt notwendig. Das muss also irgendwie auch mit dem Netzwerk Stack zusammen hängen.
Ich habe in das ENIGMA2 Modul jetzt gerade ein entsprechendes Attribut "http-noshutdown" eingebaut, so dass man das Verhalten beeinflussen kann. Der Standardwert ist nach wie vor 1, auf einer Fritzbox wird er jedoch automatisch auf 0 gesetzt. Mal sehen ob es was hilft.
Jetzt wird hier vermutlich nicht jeder der Betroffenen das ENIGMA2 Modul einsetzen. Schaut doch deshalb mal, welche Module ihr einsetzt, die ein Gerät von euch per HTTP abfragen und bittet den Modulautor, sein Modul im Bezug auf noshutdown zu bewerten.
Gruß
Julian
Zitat von: Loredo am 04 März 2014, 20:28:27Auf normalen Linux Plattformen ist ein explizites Shutdown der Verbindung nicht unbedingt notwendig.
ui ui ui... VORSICHT...
Zitat von: betateilchen am 04 März 2014, 20:30:51
ui ui ui... VORSICHT...
Klugscheißer :P
Ich gebe nur wieder, was man im FHEM Quellcode nachlesen kann 8)
Das noshutdown ist nicht nur von der Hardwareplattform abhängig auf der fhem läuft, sondern auch vom Verhalten der Gegenstelle bei der http-Kommunikation.
Die daraus resultierenden Probleme kannst Du in diversen Threads nachlesen, in denen eine http-Kommunikation seit der Neufassung der HttpUtils zum Jahreswechsel 2013/14 nicht mehr funktioniert. Speziell macht sich das im Kalendermodul bemerkbar. Auf 2 von 3 meiner fhem-Installation hab ich da Probleme, auf der dritten läuft es problemlos. Und keine der drei Plattformen ist eine Fritzbox.
Ich habe bisher nicht in Frage gestellt, warum Rudi sich entschieden hat, dass der Standard ist eine Verbindung nicht sauber zu schließen. Ich glaube ich hatte mal den Ansatz eines Versuches in einem Beitrag gemacht und wurde förmlich zerschmettert *g*
Daher war es mir dann egal :-)
Zitat von: Loredo am 04 März 2014, 20:39:24und wurde förmlich zerschmettert *g*
nicht nur Du. Er ist nach wie vor von der Richtigkeit seiner HttpUtils überzeugt, obwohl ich ihm jederzeit reproduzierbar das Gegenteil vorführen kann (und das auch explizit beschrieben habe).
Zitat von: betateilchen am 04 März 2014, 20:40:52
obwohl ich ihm jederzeit reproduzierbar das Gegenteil vorführen kann (und das auch explizit beschrieben habe).
Hast du ihm einen Patch gegeben? Ich glaub er ist da auch oft Faul (was ich verstehen kann, wenn man da viel Hirnschmalz reingesteckt hat und froh ist, dass man es eigentlich fertig hatte). Und dann kommt da irgend wo ein daher gespaltenes Betateilchen geflogen und meckert daran rum ;)
Ich kann ihm dazu keinen Patch geben, da ich für das Problem keine Lösung habe, ausser die alten HttpUtils zu verwenden oder das Calendermodul mit LWP::ua zu nutzen statt mit HttpUtils.
Die HttpUtils sind für mich sowas von abstrus und die Wurzel vielen Übels, dass ich die in meinen Modulen nicht verwende.
Da war ich wohl etwas voreilig. Ich habe meinen Patch gerade zurück genommen aus dem SVN, denn es stellt mich dann wieder für alle Fritzbox Installationen vor dieses Problem hier, was zunächst in FHEM gelöst werden muss:
http://forum.fhem.de/index.php/topic,20083.0.html
Ich denke generell, dass wir unseren Übeltäter gefunden haben und die Ursache in der genannten Diskussion zu suchen ist.
soso, aber mich hier als Klugscheißer bezeichnen... 8)
Zitat von: betateilchen am 04 März 2014, 21:54:29
soso, aber mich hier als Klugscheißer bezeichnen... 8)
Dabei bleibe ich auch, denn deine Formulierung kommt so rüber 8)
Sie hat dich aber zumindest zum Nachdenken über Deine Aussage und Dein vorschnelles Tun angeregt - und letztendlich war sie klug und richtig, und nicht geschissen :P
Zitat von: betateilchen am 04 März 2014, 21:59:22
Sie hat dich aber zumindest zum Nachdenken über Deine Aussage und Dein vorschnelles Tun angeregt - und letztendlich war sie klug und richtig, und nicht geschissen :P
Nö, zum Nachdenken hat sie mich nicht gebracht. Vielmehr habe ich die Version erst nach dem Submit auf der Fritzbox ausgetestet und dann festgestellt, dass ich einst schonmal als seltsam eingestuftes Verhalten auf der Fritzbox jetzt wieder habe. Sonst nix.
jaja, schon gut.
Hallo,
habe das Problem jetzt auch. Das Modul 70_Enigma2.pm habe ich schon länger erfolgreich im Einsatz. Es fing mit dem neuen Modul PHTV.pm an. Für beide Module lasse ich keine Logfiles erzeugen. Woran kann es liegen?
...
2014.03.12 08:55:41 1: Accept failed (WEB: Too many open files)
...
Gruß,
Matscher
Zitat von: Matscher am 12 März 2014, 11:37:18
Woran kann es liegen?
Beide Module nutzen sehr fleißig die HttpUtils von FHEM. Viele glauben, diese sind nach einem Update selbiger irgendwo fehlerhaft.
HttpUtils fehlerhaft? Du willst wohl das Volk aufwiegeln (sag Bescheid, ich mach mit)?
Wenn der König sagt, die HttpUtils sind in Ordnung, dann muss das per dessen Dekret so sein.
Basta. 8)
Zitat von: betateilchen am 12 März 2014, 11:43:39
HttpUtils fehlerhaft? Du willst wohl das Volk aufwiegeln (sag Bescheid, ich mach mit)?
Wenn der König sagt, die HttpUtils sind in Ordnung, dann muss das per dessen Dekret so sein.
Basta. 8)
Ja, du kannst helfen und eine Dreambox oder einen Philips Fernseher in den Palast zu schaffen ;)
(nee ich mag nicht auf Menschen rum trampeln und höre jetzt auch wieder auf)
Achso, um @Matscher noch einen Workaround zu geben: Ich konnte das fehlerhafte Verhalten hauptsächlich bei der Nutzung einer Fritzbox beobachten. Bei einem RaspberryPi habe ich nichts auffälliges sehen können. Ist natürlich trotzdem ärgerlich (und ich weiß auch, dass Rudi für dieses Mistvieh schon sehr viele Workarounds einbauen musste, es aber auch aus Eigennutz immer wieder gerne tut)
Zitat von: Loredo am 12 März 2014, 11:56:05Ja, du kannst helfen und eine Dreambox oder einen Philips Fernseher in den Palast zu schaffen
Unnötig. Um einen Calendar einzurichten, damit man den Fehler reproduzieren kann, bedarf es keiner materiellen Investition ;)
Und ich weiss, dass trotz aller Workarounds der Fehler nicht nur auf der Fritzkotz auftritt, sondern auch auf anderen Plattformen.
Deshalb verzichte ich inzwischen wo immer möglich (vor allem in meinen eigenen Modulen) auf die HttpUtils, Auch mit dem Risiko, dass dann ein Modul auf den AVM Kisten eben mal nicht funktioniert.
Zitat von: Loredo am 12 März 2014, 11:59:32
Achso, um @Matscher noch einen Workaround zu geben: Ich konnte das fehlerhafte Verhalten hauptsächlich bei der Nutzung einer Fritzbox beobachten. Bei einem RaspberryPi habe ich nichts auffälliges sehen können. Ist natürlich trotzdem ärgerlich (und ich weiß auch, dass Rudi für dieses Mistvieh schon sehr viele Workarounds einbauen musste, es aber auch aus Eigennutz immer wieder gerne tut)
Okay, dann ist das Verhalten auf dem "Mistvieh" wohl ähnlich wie auf einen Win PC. :) Da läuft im Moment bei mir FHEM drauf. Weil es hier mal angesprochen wurde, welche ältere Version der HttoUtils "funktionierte" noch? :)
Ende Dezember 2013, die letzte Version in SVN vor dem Eintrag "complete rewrite"
Danke... :) Die passt dann nur nicht mehr zum Enigma2 Modul...(benötigt NonblockingGet(..)) :(
Ich probiere jetzt genau die Version r4514 "..rewrite" mal aus. Da ich eigentlich regelmäßig Updates durchgeführt hatte, auch nach dem rewrite der Utils, funktioniert es zumindest mit dem Enigma Modul.
Hi,
Sobald das phtv Modul mit aktiv ist, dauert es nicht lang und es hängt.
Gruß,
Matscher
Es mag ja an meiner Implementierung/Nutzung von NonBlockingGet() liegen; wenn dem so sei, müsste mir das aber mal jemand sagen/bestätigen... ich wüsste derzeit nicht, was ich da anders machen sollte...
Bisher sträube ich mich dagegen noch alternative Abfragemethoden über LWP o.ä. einzubauen, zumal ich da das NonBlocking selbst neu erfinden müsste (drauf verzichten möchte ich nicht mehr). Das kann aber auch nicht im Sinne des Erfinders von HttpUtils sein... die sollten gefixt werden
Das ist verständlich. :) wollte erstmal nur berichten, was der stand ist.
Vielleicht schaut der Erfinder nochmal über die utils, auch für die Zukunft. Es werden ja schließlich nicht die einzigen module sein/bleiben, die das nutzen. :)
Gibt es hier schon weitere Erkenntnisse zu dem Problem? Bei mir ist es aktuell auch so, dass die Anzahl der offenen Handles kontinuierlich steigt, bis dann irgendwann die "too many open files"-Meldungen im Log kommen und dann geht gar nichts mehr (so nach ca. 48 Stunden) :(
Irgendwas scheint da zu vergessen, seine Handles wieder zu schließen -> handle leak
Die meisten hier sind der Meinung, dass wir den Ursprung des Fehlers bei den HttpUtils von FHEM identifiziert haben.
Rudi sieht das allerdings anders und so passiert hier eben aktuell gar nichts.
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.
Allerdings macht keines der betroffenen Module I/O auf andere Weise... Keiner schreibt Files oder macht andere Sockets auf.
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...
Zitat von: vbs am 14 April 2014, 19:26:14
Hm, ich glaub, ich ziehe meine Aussage zurück und glaube jetzt auch an httputils.
Irgendwann kommt jeder drauf. Bestimmt auch Rudi irgendwann 8)
Fehlt denn in HttpUtils_Connect2 nicht sowas wie
$hash->{conn}->close();
undef $hash->{conn};
am Ende?
Ich meine da steht zwar ein
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?
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.
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:
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.
@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.
Zitat von: rudolfkoenig am 15 April 2014, 09:52:18
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.
Zitat von: rudolfkoenig am 15 April 2014, 09:52:18@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?
Ehrlich gesagt, sind manche der Diskussionen hier schon eher traurig als amüsant.
das stimmt leider.
Hallo zusammen, seit einigen Tagen habe ich das gleiche Problem.
Das log-file wird zugemüllt und nichts geht mehr.
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?
Wuesste gerne was schiefgeht, kannst Du bitte die Ausgabe von
list .* FD
hier anhaengen?
Falls die meisten Eintraege mit FHEMWEB anfangen, dann koennte "attr TYPE=FHEMWEB closeConn" helfen.
O.K.
anbei der Auszug
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?
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.
Wir gemacht.
Ich melde mich sobald es wieder Auftritt.
So Fhem wieder down, anbei die Liste.
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?
Falls FHEM noch antwortet:
{ $$ }
Sonst je nach OS anders, z.Bsp. Linux und OSX:
ps -ef | grep fhem
Zitat von: cornelius fillmore am 13 August 2014, 20:13:43
Wo bekomme ich die denn her?
Das hast Du heute morgen doch schon in einem eigenen Thread gefragt - und Antworten bekommen?
http://forum.fhem.de/index.php/topic,26114.0.html
Zitat von: rudolfkoenig am 11 August 2014, 11:12:28
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.
So heute morgen geht wieder gar nichts mehr
Anbei die Liste
root@raspberrypi:/home/pi# ls /proc/1953/fd
0 134 192 25 307 365 422 480 538 596 653 710 769 826 884 941
1 135 193 250 308 366 423 481 539 597 654 711 77 827 885 942
10 136 194 251 309 367 424 482 54 598 655 712 770 828 886 943
100 137 195 252 31 368 425 483 540 599 656 713 771 829 887 944
1000 138 196 253 310 369 426 484 541 6 657 714 772 83 888 945
1001 139 197 254 311 37 427 485 542 60 658 715 773 830 889 946
1002 14 198 255 312 370 428 486 543 600 659 716 774 831 89 947
1003 140 199 256 313 371 429 487 544 601 66 717 775 832 890 948
1004 141 2 257 314 372 43 488 545 602 660 718 776 833 891 949
1005 142 20 258 315 373 430 489 546 603 661 719 777 834 892 95
1006 143 200 259 316 374 431 49 547 604 662 72 778 835 893 950
1007 144 201 26 317 375 432 490 548 605 663 720 779 836 894 951
1008 145 202 260 318 376 433 491 549 606 664 721 78 837 895 952
1009 146 203 261 319 377 434 492 55 607 665 722 780 838 896 953
101 147 204 262 32 378 435 493 550 608 666 723 781 839 897 954
1010 148 205 263 320 379 436 494 551 609 667 724 782 84 898 955
1011 149 206 264 321 38 437 495 552 61 668 725 783 840 899 956
1012 15 207 265 322 380 438 496 553 610 669 726 784 841 9 957
1013 150 208 266 323 381 439 497 554 611 67 727 785 842 90 958
1014 151 209 267 324 382 44 498 555 612 670 728 786 843 900 959
1015 152 21 268 325 383 440 499 556 613 671 729 787 844 901 96
1016 153 210 269 326 384 441 5 557 614 672 73 788 845 902 960
1017 154 211 27 327 385 442 50 558 615 673 730 789 846 903 961
1018 155 212 270 328 386 443 500 559 616 674 731 79 847 904 962
1019 156 213 271 329 387 444 501 56 617 675 732 790 848 905 963
102 157 214 272 33 388 445 502 560 618 676 733 791 849 906 964
1020 158 215 273 330 389 446 503 561 619 677 734 792 85 907 965
1021 159 216 274 331 39 447 504 562 62 678 735 793 850 908 966
1022 16 217 275 332 390 448 505 563 620 679 736 794 851 909 967
1023 160 218 276 333 391 449 506 564 621 68 737 795 852 91 968
103 161 219 277 334 392 45 507 565 622 680 738 796 853 910 969
104 162 22 278 335 393 450 508 566 623 681 739 797 854 911 97
105 163 220 279 336 394 451 509 567 624 682 74 798 855 912 970
106 164 221 28 337 395 452 51 568 625 683 740 799 856 913 971
107 165 222 280 338 396 453 510 569 626 684 741 8 857 914 972
108 166 223 281 339 397 454 511 57 627 685 742 80 858 915 973
109 167 224 282 34 398 455 512 570 628 686 743 800 859 916 974
11 168 225 283 340 399 456 513 571 629 687 744 801 86 917 975
110 169 226 284 341 4 457 514 572 63 688 745 802 860 918 976
111 17 227 285 342 40 458 515 573 630 689 746 803 861 919 977
112 170 228 286 343 400 459 516 574 631 69 747 804 862 92 978
113 171 229 287 344 401 46 517 575 632 690 748 805 863 920 979
114 172 23 288 345 402 460 518 576 633 691 749 806 864 921 98
115 173 230 289 346 403 461 519 577 634 692 75 807 865 922 980
116 174 231 29 347 404 462 52 578 635 693 750 808 866 923 981
117 175 232 290 348 405 463 520 579 636 694 751 809 867 924 982
118 176 233 291 349 406 464 521 58 637 695 752 81 868 925 983
119 177 234 292 35 407 465 522 580 638 696 753 810 869 926 984
12 178 235 293 350 408 466 523 581 639 697 754 811 87 927 985
120 179 236 294 351 409 467 524 582 64 698 755 812 870 928 986
121 18 237 295 352 41 468 525 583 640 699 756 813 871 929 987
122 180 238 296 353 410 469 526 584 641 7 757 814 872 93 988
123 181 239 297 354 411 47 527 585 642 70 758 815 873 930 989
124 182 24 298 355 412 470 528 586 643 700 759 816 874 931 99
125 183 240 299 356 413 471 529 587 644 701 76 817 875 932 990
126 184 241 3 357 414 472 53 588 645 702 760 818 876 933 991
127 185 242 30 358 415 473 530 589 646 703 761 819 877 934 992
128 186 243 300 359 416 474 531 59 647 704 762 82 878 935 993
129 187 244 301 36 417 475 532 590 648 705 763 820 879 936 994
13 188 245 302 360 418 476 533 591 649 706 764 821 88 937 995
130 189 246 303 361 419 477 534 592 65 707 765 822 880 938 996
131 19 247 304 362 42 478 535 593 650 708 766 823 881 939 997
132 190 248 305 363 420 479 536 594 651 709 767 824 882 94 998
133 191 249 306 364 421 48 537 595 652 71 768 825 883 940 999
Hilft das?
Daraus geht hervor, dass FHEM wirklich zu viele offene FDs hat (was die Fehlermeldung ja auch gesagt hat).
Fuer etwas mehr Detail sorgt
ls -l /proc/<fhempid>/fd
Ich vermute aber, dass die meisten Zeilen "socket:XXX" sind, und damit wir nur einen kleinen Schritt weiterkommen.
Deutlich besser ist "lsof -p <fhempid>", da hier auch die Zieladressen der Netzwerkverbindungen angezeigt werden.
Alternativ regelmaessig ein "list .* FD" mit einem FHEM-at einmal in der Stunde einplanen. Noch besser ist es alle Vorschlaege durchzuprobieren.
Anbei der aktuelle Auszug
root@raspberrypi:/home/pi# ps -ef | grep fhem
fhem 1934 1 0 10:45 ? 00:01:12 perl fhem.pl fhem.cfg
root 1935 1 0 10:45 ? 00:00:00 startpar -f -- fhem
root 4393 4345 0 14:52 pts/0 00:00:00 grep fhem
root@raspberrypi:/home/pi# ls -l /proc/1934/fd
insgesamt 0
lrwx------ 1 root root 64 Aug 14 10:45 0 -> /dev/console
lrwx------ 1 root root 64 Aug 14 11:09 1 -> /dev/pts/1
l-wx------ 1 root root 64 Aug 14 11:09 10 -> /opt/fhem/log/fhem-2014-08.log
lrwx------ 1 root root 64 Aug 14 11:09 11 -> /dev/ttyAMA0
lrwx------ 1 root root 64 Aug 14 11:09 12 -> socket:[2567]
l-wx------ 1 root root 64 Aug 14 11:09 13 -> /opt/fhem/log/FHT_WZ-2014-08.log
l-wx------ 1 root root 64 Aug 14 11:09 14 -> /opt/fhem/log/FHT_Bad-2014-08.log
l-wx------ 1 root root 64 Aug 14 11:09 15 -> /opt/fhem/log/FHT_Essen-2014-08.log
l-wx------ 1 root root 64 Aug 14 11:09 16 -> /opt/fhem/log/FHT_Moritz-2014-08.log
lrwx------ 1 root root 64 Aug 14 11:09 17 -> socket:[2736]
lrwx------ 1 root root 64 Aug 14 11:09 18 -> socket:[2737]
lrwx------ 1 root root 64 Aug 14 11:09 19 -> socket:[2933]
lrwx------ 1 root root 64 Aug 14 11:09 2 -> /dev/pts/1
lrwx------ 1 root root 64 Aug 14 11:09 20 -> socket:[2934]
lrwx------ 1 root root 64 Aug 14 11:09 21 -> socket:[2935]
lrwx------ 1 root root 64 Aug 14 11:09 22 -> socket:[2936]
lrwx------ 1 root root 64 Aug 14 11:09 23 -> socket:[3531]
lrwx------ 1 root root 64 Aug 14 11:09 24 -> socket:[2938]
lrwx------ 1 root root 64 Aug 14 11:09 25 -> socket:[3195]
lrwx------ 1 root root 64 Aug 14 11:09 26 -> socket:[3196]
lrwx------ 1 root root 64 Aug 14 11:09 27 -> socket:[3197]
lrwx------ 1 root root 64 Aug 14 11:09 28 -> socket:[3249]
lrwx------ 1 root root 64 Aug 14 11:09 29 -> socket:[3250]
lr-x------ 1 root root 64 Aug 14 11:09 3 -> /etc/group
lrwx------ 1 root root 64 Aug 14 11:09 30 -> socket:[3251]
lrwx------ 1 root root 64 Aug 14 11:09 31 -> socket:[3280]
lrwx------ 1 root root 64 Aug 14 11:09 32 -> socket:[3281]
lrwx------ 1 root root 64 Aug 14 11:09 33 -> socket:[3282]
lrwx------ 1 root root 64 Aug 14 11:09 34 -> socket:[3334]
lrwx------ 1 root root 64 Aug 14 11:09 35 -> socket:[3335]
lrwx------ 1 root root 64 Aug 14 11:09 36 -> socket:[3336]
lrwx------ 1 root root 64 Aug 14 11:09 37 -> socket:[3390]
lrwx------ 1 root root 64 Aug 14 11:09 38 -> socket:[3391]
lrwx------ 1 root root 64 Aug 14 11:09 39 -> socket:[3392]
l-wx------ 1 root root 64 Aug 14 11:09 4 -> /opt/fhem/log/fhem-2014-08.log
lrwx------ 1 root root 64 Aug 14 11:09 40 -> socket:[3444]
lrwx------ 1 root root 64 Aug 14 11:09 41 -> socket:[3445]
lrwx------ 1 root root 64 Aug 14 11:09 42 -> socket:[3446]
lrwx------ 1 root root 64 Aug 14 11:09 43 -> socket:[3474]
lrwx------ 1 root root 64 Aug 14 11:09 44 -> socket:[3475]
lrwx------ 1 root root 64 Aug 14 11:09 45 -> socket:[3476]
lrwx------ 1 root root 64 Aug 14 11:09 46 -> socket:[3749]
lrwx------ 1 root root 64 Aug 14 11:09 47 -> socket:[3785]
lrwx------ 1 root root 64 Aug 14 11:09 48 -> socket:[3786]
lrwx------ 1 root root 64 Aug 14 11:09 49 -> socket:[3787]
lrwx------ 1 root root 64 Aug 14 11:09 5 -> socket:[2932]
lrwx------ 1 root root 64 Aug 14 11:39 50 -> socket:[5589]
lrwx------ 1 root root 64 Aug 14 11:09 51 -> socket:[3844]
lrwx------ 1 root root 64 Aug 14 11:09 52 -> socket:[3845]
lrwx------ 1 root root 64 Aug 14 11:09 53 -> socket:[3846]
lrwx------ 1 root root 64 Aug 14 11:09 54 -> socket:[4246]
lrwx------ 1 root root 64 Aug 14 11:09 55 -> socket:[4247]
lrwx------ 1 root root 64 Aug 14 11:09 56 -> socket:[4248]
lrwx------ 1 root root 64 Aug 14 11:39 57 -> socket:[5375]
lrwx------ 1 root root 64 Aug 14 11:39 58 -> socket:[5376]
lrwx------ 1 root root 64 Aug 14 11:39 59 -> socket:[5377]
lrwx------ 1 root root 64 Aug 14 11:09 6 -> socket:[2536]
lrwx------ 1 root root 64 Aug 14 11:39 60 -> socket:[5537]
lrwx------ 1 root root 64 Aug 14 11:39 61 -> socket:[5538]
lrwx------ 1 root root 64 Aug 14 11:39 62 -> socket:[5539]
lrwx------ 1 root root 64 Aug 14 14:09 66 -> socket:[12156]
lrwx------ 1 root root 64 Aug 14 11:09 7 -> socket:[2551]
lrwx------ 1 root root 64 Aug 14 11:09 8 -> socket:[2552]
lrwx------ 1 root root 64 Aug 14 11:09 9 -> socket:[2553]
root@raspberrypi:/home/pi# ps -ef | grep fhem
Hatte aber zwischenzeitlich das Logfile gelöscht und fhem neu gestartet
Das sind jetzt schon zuviele sockets.
Kannst Du (wie gebeten) auch die anderen beiden Outputs (list .* FD und lsof) hier posten?
Zitat von: rudolfkoenig am 14 August 2014, 15:37:28
Das sind jetzt schon zuviele sockets.
Kannst Du (wie gebeten) auch die anderen beiden Outputs (list .* FD und lsof) hier posten?
list .* FD
COC 12
CUNO 13
FHEMWEB:192.168.0.36:56267 6
WEB 8
WEBphone 9
WEBtablet 10
telnetPort 7 Aber bei der Abfrage "lsof -p <fhempid>" bekomme ich díe Fehlermeldung
lsof: Kommando nicht gefunden.
Installiere es einfach ;)
Die Ausgabe von "list .* FD" besagt, dass das Problem nicht von einem "normalen" FHEM Modul wie FHEMWEB/CUL/etc stammt. Bleibt nur noch die Hoffnung auf lsof, bitte mit "apt-get install lsof" (oder grafisch oder sonstwie) installieren.
so da ist sie
lroot@raspberrypi:/home/pi# lsof -p 1934
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
perl 1934 fhem cwd DIR 179,2 4096 67894 /opt/fhem
perl 1934 fhem rtd DIR 179,2 4096 2 /
perl 1934 fhem txt REG 179,2 9800 65445 /usr/bin/perl
perl 1934 fhem mem REG 179,2 87792 5150 /lib/arm-linux-gnueabihf/libz.so.1.2.7
perl 1934 fhem mem REG 179,2 75620 65256 /usr/lib/perl/5.14.2/auto/Compress/Raw/Zlib/Zlib.so
perl 1934 fhem mem REG 179,2 18040 65429 /usr/lib/perl/5.14.2/auto/File/Glob/Glob.so
perl 1934 fhem mem REG 179,2 135656 16409 /lib/arm-linux-gnueabihf/libexpat.so.1.6.0
perl 1934 fhem mem REG 179,2 127520 146902 /usr/lib/perl5/auto/XML/Parser/Expat/Expat.so
perl 1934 fhem mem REG 179,2 30496 65269 /usr/lib/perl/5.14.2/auto/Encode/Encode.so
perl 1934 fhem mem REG 179,2 30384 65264 /usr/lib/perl/5.14.2/auto/Data/Dumper/Dumper.so
perl 1934 fhem mem REG 179,2 71528 68029 /lib/arm-linux-gnueabihf/libresolv-2.13.so
perl 1934 fhem mem REG 179,2 18040 68034 /lib/arm-linux-gnueabihf/libnss_dns-2.13.so
perl 1934 fhem mem REG 179,2 13784 65069 /usr/lib/perl/5.14.2/auto/MIME/Base64/Base64.so
perl 1934 fhem mem REG 179,2 22128 65440 /usr/lib/perl/5.14.2/auto/List/Util/Util.so
perl 1934 fhem mem REG 179,2 42692 68023 /lib/arm-linux-gnueabihf/libnss_files-2.13.so
perl 1934 fhem mem REG 179,2 38604 68044 /lib/arm-linux-gnueabihf/libnss_nis-2.13.so
perl 1934 fhem mem REG 179,2 71624 68037 /lib/arm-linux-gnueabihf/libnsl-2.13.so
perl 1934 fhem mem REG 179,2 26484 68039 /lib/arm-linux-gnueabihf/libnss_compat-2.13.so
perl 1934 fhem mem REG 179,2 84480 65439 /usr/lib/perl/5.14.2/auto/POSIX/POSIX.so
perl 1934 fhem mem REG 179,2 13840 65433 /usr/lib/perl/5.14.2/auto/Fcntl/Fcntl.so
perl 1934 fhem mem REG 179,2 26632 68018 /lib/arm-linux-gnueabihf/librt-2.13.so
perl 1934 fhem mem REG 179,2 22080 65059 /usr/lib/perl/5.14.2/auto/Time/HiRes/HiRes.so
perl 1934 fhem mem REG 179,2 30312 69104 /usr/lib/perl5/auto/Socket/Socket.so
perl 1934 fhem mem REG 179,2 13880 65432 /usr/lib/perl/5.14.2/auto/IO/IO.so
perl 1934 fhem mem REG 179,2 131372 1247 /lib/arm-linux-gnueabihf/libgcc_s.so.1
perl 1934 fhem mem REG 179,2 30276 68032 /lib/arm-linux-gnueabihf/libcrypt-2.13.so
perl 1934 fhem mem REG 179,2 1200240 68033 /lib/arm-linux-gnueabihf/libc-2.13.so
perl 1934 fhem mem REG 179,2 116462 68026 /lib/arm-linux-gnueabihf/libpthread-2.13.so
perl 1934 fhem mem REG 179,2 427628 68043 /lib/arm-linux-gnueabihf/libm-2.13.so
perl 1934 fhem mem REG 179,2 9812 68040 /lib/arm-linux-gnueabihf/libdl-2.13.so
perl 1934 fhem mem REG 179,2 1347628 65444 /usr/lib/libperl.so.5.14.2
perl 1934 fhem mem REG 179,2 8624 67923 /usr/lib/perl5/auto/Device/SerialPort/SerialPort.so
perl 1934 fhem mem REG 179,2 10170 13109 /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
perl 1934 fhem mem REG 179,2 126236 68027 /lib/arm-linux-gnueabihf/ld-2.13.so
perl 1934 fhem mem REG 179,2 682 63811 /etc/group
perl 1934 fhem 0u CHR 5,1 0t0 28 /dev/console
perl 1934 fhem 1u CHR 136,1 0t0 4 /dev/pts/1
perl 1934 fhem 2u CHR 136,1 0t0 4 /dev/pts/1
perl 1934 fhem 3r REG 179,2 682 63811 /etc/group
perl 1934 fhem 4w REG 179,2 12913 78 /opt/fhem/log/fhem-2014-08.log
perl 1934 fhem 5u IPv4 2932 0t0 TCP Raspi.fritz.box:45099->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 6u IPv4 18346 0t0 TCP Raspi.fritz.box:8083->Gockel.fritz.box:56658 (ESTABLISHED)
perl 1934 fhem 7u IPv4 14779 0t0 TCP *:7072 (LISTEN)
perl 1934 fhem 8u IPv4 14780 0t0 TCP *:8083 (LISTEN)
perl 1934 fhem 9u IPv4 14781 0t0 TCP *:8084 (LISTEN)
perl 1934 fhem 10u IPv4 14782 0t0 TCP *:8085 (LISTEN)
perl 1934 fhem 11w REG 179,2 12913 78 /opt/fhem/log/fhem-2014-08.log
perl 1934 fhem 12u CHR 204,64 0t0 9 /dev/ttyAMA0
perl 1934 fhem 13u IPv4 14783 0t0 TCP Raspi.fritz.box:40238->192.168.0.223:2323 (ESTABLISHED)
perl 1934 fhem 14w REG 179,2 301534 15418 /opt/fhem/log/FHT_WZ-2014-08.log
perl 1934 fhem 15w REG 179,2 882026 6356 /opt/fhem/log/FHT_Bad-2014-08.log
perl 1934 fhem 16w REG 179,2 638679 28644 /opt/fhem/log/FHT_Essen-2014-08.log
perl 1934 fhem 17u sock 0,6 0t0 2736 can't identify protocol
perl 1934 fhem 18u sock 0,6 0t0 2737 can't identify protocol
perl 1934 fhem 19u IPv4 2933 0t0 TCP Raspi.fritz.box:45100->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 20u IPv4 2934 0t0 TCP Raspi.fritz.box:45101->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 21u IPv4 2935 0t0 TCP Raspi.fritz.box:45102->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 22u IPv4 2936 0t0 TCP Raspi.fritz.box:45103->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 23u IPv4 3531 0t0 TCP Raspi.fritz.box:45543->dm800se.fritz.box:http (ESTABLISHED)
perl 1934 fhem 24u IPv4 2938 0t0 TCP Raspi.fritz.box:45105->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 25u IPv4 3195 0t0 TCP Raspi.fritz.box:45319->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 26u IPv4 3196 0t0 TCP Raspi.fritz.box:45320->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 27u IPv4 3197 0t0 TCP Raspi.fritz.box:45321->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 28u IPv4 3249 0t0 TCP Raspi.fritz.box:45352->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 29u IPv4 3250 0t0 TCP Raspi.fritz.box:45353->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 30u IPv4 3251 0t0 TCP Raspi.fritz.box:45354->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 31u IPv4 3280 0t0 TCP Raspi.fritz.box:45382->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 32u IPv4 3281 0t0 TCP Raspi.fritz.box:45383->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 33u IPv4 3282 0t0 TCP Raspi.fritz.box:45384->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 34u IPv4 3334 0t0 TCP Raspi.fritz.box:45415->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 35u IPv4 3335 0t0 TCP Raspi.fritz.box:45416->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 36u IPv4 3336 0t0 TCP Raspi.fritz.box:45417->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 37u IPv4 3390 0t0 TCP Raspi.fritz.box:45448->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 38u IPv4 3391 0t0 TCP Raspi.fritz.box:45449->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 39u IPv4 3392 0t0 TCP Raspi.fritz.box:45450->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 40u IPv4 3444 0t0 TCP Raspi.fritz.box:45481->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 41u IPv4 3445 0t0 TCP Raspi.fritz.box:45482->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 42u IPv4 3446 0t0 TCP Raspi.fritz.box:45483->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 43u IPv4 3474 0t0 TCP Raspi.fritz.box:45511->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 44u IPv4 3475 0t0 TCP Raspi.fritz.box:45512->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 45u IPv4 3476 0t0 TCP Raspi.fritz.box:45513->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 46u IPv4 3749 0t0 TCP Raspi.fritz.box:45740->dm800se.fritz.box:http (ESTABLISHED)
perl 1934 fhem 47u IPv4 3785 0t0 TCP Raspi.fritz.box:45748->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 48u IPv4 3786 0t0 TCP Raspi.fritz.box:45749->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 49u IPv4 3787 0t0 TCP Raspi.fritz.box:45750->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 50u sock 0,6 0t0 5589 can't identify protocol
perl 1934 fhem 51u IPv4 3844 0t0 TCP Raspi.fritz.box:45786->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 52u IPv4 3845 0t0 TCP Raspi.fritz.box:45787->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 53u IPv4 3846 0t0 TCP Raspi.fritz.box:45788->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 54u IPv4 4246 0t0 TCP Raspi.fritz.box:46079->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 55u IPv4 4247 0t0 TCP Raspi.fritz.box:46080->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 56u IPv4 4248 0t0 TCP Raspi.fritz.box:46081->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 57u IPv4 5375 0t0 TCP Raspi.fritz.box:46471->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 58u IPv4 5376 0t0 TCP Raspi.fritz.box:46472->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 59u IPv4 5377 0t0 TCP Raspi.fritz.box:46473->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 60u IPv4 5537 0t0 TCP Raspi.fritz.box:46633->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 61u IPv4 5538 0t0 TCP Raspi.fritz.box:46634->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 62u IPv4 5539 0t0 TCP Raspi.fritz.box:46635->dm800se.fritz.box:http (CLOSE_WAIT)
perl 1934 fhem 63w REG 179,2 905391 28633 /opt/fhem/log/FHT_Moritz-2014-08.log
perl 1934 fhem 64u IPv4 19042 0t0 TCP Raspi.fritz.box:50520->dm800se.fritz.box:http (SYN_SENT)
perl 1934 fhem 65u sock 0,6 0t0 16786 can't identify protocol
perl 1934 fhem 66u IPv4 19043 0t0 TCP Raspi.fritz.box:49242->dm800se.fritz.box:http (SYN_SENT)
perl 1934 fhem 69u sock 0,6 0t0 14418 can't identify protocol
root@raspberrypi:/home/pi#
Dein FHEM@RPi macht immer wieder eine Verbindung zum HTTP Port (==Webserver) der dm800se.fritz.box (ist das ein Dreambox?) auf, und macht diese Verbindung auch zu, aber die dm800se beantwortet die Aufforderung zum Schliessen nicht, und damit kann dein RPi die Netzwerk-Verbindung nicht komplett wegraeumen (es bleibt in CLOSE_WAIT).
Wie greifst Du auf die dm800se zu?
Nur über das Enigma 2-Modul
## Linux Receiver ##
#Dreambox 1#
define Dream ENIGMA2 192.168.0.10 80
attr Dream bouquet-radio 1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio_deutsch.radio" ORDER BY bouquet
attr Dream bouquet-tv 1:7:1:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.mein_tv.tv" ORDER BY bouquet
attr Dream devStateIcon on:rc_GREEN:off off:rc_YELLOW:on absent:rc_STOP:on
attr Dream http-method GET
attr Dream icon dreambox
attr Dream room Wohnzimmer
attr Dream webCmd channel:input
#Dreambox 2#
define Dream2 ENIGMA2 192.168.0.14 80
attr Dream2 bouquet-radio 1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio_deutsch.radio" ORDER BY bouquet
attr Dream2 bouquet-tv 1:7:1:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.mein_tv.tv" ORDER BY bouquet
attr Dream2 devStateIcon on:rc_GREEN:off off:rc_YELLOW:on absent:rc_STOP:on
attr Dream2 http-method GET
attr Dream2 icon dreambox
attr Dream2 room Schlafzimmer
attr Dream2 webCmd channel:input
Und welcher der beiden ist dm800se? Ich finde es interessant, dass nur der eine die Probleme zeigt, und der andere nicht. Wie auch immer, man sollte eine neue Diskussion mit passenden Titel oeffnen, damit der Modulautor darauf aufmerksam wird.
Das ist eine gute Frage:
Beides sind baugleiche Dreamboxen aber keine heißt im fhem dm800se?
Wie soll ich denn den neuen thread im Multimedia-Bereich nennen?
Ich habe noch mal meine fhem.cfg eingefügt, vielleicht hilft das
attr global autoload_undefined_devices 1
attr global exclude_from_update HttpUtils.pm
attr global holiday2we Hessen_Feiertag
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
\
WEB,WEBphone,WEBtablet has no basicAuth attribute.\
telnetPort has no password/globalpassword attribute.\
\
Restart FHEM for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\
attr global statefile ./log/fhem.save
attr global uniqueID ./FHEM/FhemUtils/uniqueID
attr global userattr devStateIcon devStateStyle fp_Aussen fp_EG icon room_map sortby structexclude webCmd widgetOverride
attr global verbose 3
define telnetPort telnet 7072 global
define WEB FHEMWEB 8083 global
attr WEB stylesheetPrefix dark
define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix darksmallscreen
define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix darksmallscreen
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog ./log/%NAME-%Y-%m.log
attr autocreate weblink 1
attr autocreate weblink_room Plots
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
# If the above notify did not helped, then you probably have to enable some of
# the following lines. Verify first that /dev/xxx ist correct.
#define FHZ FHZ /dev/USB0
#define CUL CUL /dev/ttyACM0@9600 1234
#define EUL TCM 310 /dev/ttyACM0@57600
#define BscBor TCM 120 /dev/ttyUSB0@9600
#define BscSmartConnect TCM 310 /dev/ttyUSB0@57600
define COC CUL /dev/ttyAMA0@38400 1234
define CUNO CUL 192.168.0.223:2323 0c00
### FHT ###
## Wohnzimmer ##
define FHT_WZ FHT 230f
attr FHT_WZ IODev CUNO
attr FHT_WZ lazy 1
attr FHT_WZ retrycount 1
attr FHT_WZ room FHT
define FileLog_FHT_WZ FileLog ./log/FHT_WZ-%Y-%m.log FHT_WZ
attr FileLog_FHT_WZ logtype fht1:Temp/Act,text
attr FileLog_FHT_WZ room FHT
define weblink_FHT_WZ SVG FileLog_FHT_WZ:fht1:CURRENT
attr weblink_FHT_WZ label "Wohnzimmer Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_FHT_WZ room Plots
## Bad ##
define FHT_Bad FHT 065b
attr FHT_Bad IODev COC
attr FHT_Bad lazy 1
attr FHT_Bad retrycount 1
attr FHT_Bad room FHT
#define Bd.FHT.Thermostat FHT 280c
define FileLog_FHT_Bad FileLog ./log/FHT_Bad-%Y-%m.log FHT_Bad
attr FileLog_FHT_Bad logtype fht2:Temp/Act,text
attr FileLog_FHT_Bad room FHT
define weblink_FHT_Bad SVG FileLog_FHT_Bad:fht2:CURRENT
attr weblink_FHT_Bad label "Bad Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_FHT_Bad room Plots
## Esszimmer##
define FHT_Essen FHT 2c50
attr FHT_Essen IODev CUNO
attr FHT_Essen lazy 1
attr FHT_Essen retrycount 1
attr FHT_Essen room FHT
define FileLog_FHT_Essen FileLog ./log/FHT_Essen-%Y-%m.log FHT_Essen
attr FileLog_FHT_Essen logtype fht3:Temp/Act,text
attr FileLog_FHT_Essen room FHT
define weblink_FHT_Essen SVG FileLog_FHT_Essen:fht3:CURRENT
attr weblink_FHT_Essen label "Esszimmer Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_FHT_Essen room Plots
##Moritz##
define FHT_Moritz FHT 4837
attr FHT_Moritz IODev COC
attr FHT_Moritz lazy 1
attr FHT_Moritz retrycount 1
attr FHT_Moritz room FHT
define FileLog_FHT_Moritz FileLog ./log/FHT_Moritz-%Y-%m.log FHT_Moritz
attr FileLog_FHT_Moritz logtype fht4:Temp/Act,text
attr FileLog_FHT_Moritz room FHT
define weblink_FHT_Moritz SVG FileLog_FHT_Moritz:fht4:CURRENT
attr weblink_FHT_Moritz label "Moritz Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_FHT_Moritz room Plots
## Watchdog FHTs ##
define wd_FHT_Bad watchdog FHT_Bad:measured-temp.* 12:00 SAME set FHT_Bad time
define wd_FHT_WZ watchdog FHT_WZ:measured-temp.* 12:00 SAME set FHT_WZ time
define wd_FHT_Essen watchdog FHT_Essen:measured-temp.* 12:00 SAME set FHT_Essen time
define wd_FHT_Moritz watchdog FHT_Moritz:measured-temp.* 12:00 SAME set FHT_Moritz time
#define fht_sync at +*04:00 set TYPE=FHT date
### jede Stunde einen Eintrag für FHT actuator
#define desired_temp_Bad at +*0:30 {addLog("FHT_Bad","desired-temp")}
#attr desired_temp_Bad room 99_System
#define desired_temp_Essen at +*0:30 {addLog("FHT_Essen","desired-temp")}
#attr desired_temp_Essen room 99_System
#define desired_temp_WZ at +*0:30 {addLog("FHT_WZ","desired-temp")}
#attr desired_temp_WZ room 99_System
#define desired_temp_Moritz at +*0:30 {addLog("FHT_Moritz","desired-temp")}
#attr desired_temp_Moritz room 99_System
## Heizplan ##
### Wohnzimmer ###
define FHT_WZ_dofr Heating_Control FHT_WZ 45|08:00|22 45|22:00|17
attr FHT_WZ_dofr room Wohnzimmer
define FHT_WZ_modimi Heating_Control FHT_WZ 123|12:00|22 123|22:00|17
attr FHT_WZ_modimi room Wohnzimmer
define FHT_WZ_we Heating_Control FHT_WZ 67|08:00|22 67|23:00|17
attr FHT_WZ_we room Wohnzimmer
# Bad #
define FHT_Bad_mo_fr Heating_Control FHT_Bad mo-fr|04:45|23 mo-fr|06:45|20 mo-fr|19:15|23 mo-fr|20:15|20
attr FHT_Bad_mo_fr room Bad
define FHT_Bad_sa Heating_Control FHT_Bad 6|06:00|23 6|08:00|20 6|19:00|23 6|20:00|20
attr FHT_Bad_sa room Bad
define FHT_Bad_so Heating_Control FHT_Bad 7|07:00|23 7|08:30|20 7|19:00|23 7|20:30|20
attr FHT_Bad_so room Bad
# Essen#
define FHT_Essen_dofr Heating_Control FHT_Essen 45|05:00|22 45|21:00|17
attr FHT_Essen_dofr room Esszimmer
define FHT_Essen_modimi Heating_Control FHT_Essen 123|05:00|22 123|08:00|17 123|13:00|22 123|22:00|17
attr FHT_Essen_modimi room Esszimmer
define FHT_Essen_we Heating_Control FHT_Essen 67|07:00|22 67|21:00|17
attr FHT_Essen_we room Esszimmer
# Moritz#
define FHT_Moritz_mo_do Heating_Control FHT_Moritz 1234|15:00|22 1234|20:30|17
attr FHT_Moritz_mo_do room Moritz
define FHT_Moritz_fr Heating_Control FHT_Moritz 5|15:00|22 5|22:00|17
attr FHT_Moritz_fr room Moritz
define FHT_Moritz_sa Heating_Control FHT_Moritz 6|09:00|22 6|23:00|17
attr FHT_Moritz_sa room Moritz
define FHT_Moritz_so Heating_Control FHT_Moritz 7|09:00|22 7|20:30|17
attr FHT_Moritz_so room Moritz
## FHT-Bost ##
## Bad ##
# Boostfunktion zum schnellen Aufheizen
# Wenn Sollwert geäandert und Differenz > 1.5 -> Boost an
# Wenn Differenz < 1 -> Boost aus
# Einstellung 30.0°C Ventile voll auf für 10 min.
define Bad_Boost_Notify notify FHT_Bad.* {\
my $boostStart = 1.5;;\
my $boostStop = 1;;\
my $timeComfortBoost = "00:10:00";;\
\
my ($param,$value) = split(": ", "%");;\
my $target=Value("Bad_Boost_Zieltemp");;\
\
if("$param" eq "desired-temp"){\
if($value lt 30.0){\
fhem "set Bad_Boost_Zieltemp $value";;\
if(Value("Bad_Boost_Status") eq "on-for-timer"){\
fhem "delete Bad.Boost.Comfort;;set Bad_Boost_Status off";;\
}\
my $ist=ReadingsVal("FHT_Bad", "measured-temp", 0);;\
if((($value-$ist) gt $boostStart) && (Value("Bad_Boost_Status") ne "on")){\
fhem "set FHT_Bad desired-temp on";;\
fhem "set Bad_Boost_Status on";;\
}\
if((($value-$ist) lt $boostStop) && (Value("Bad_Boost_Status") eq "on")){\
fhem "set Bad_Boost_Status off";;\
}\
}\
else{\
if((Value("Bad_Boost_Status") ne "on-for-timer") && ($value ne "on")){\
fhem "set Bad_Boost_Status on-for-timer";;\
fhem "define Bad.Boost.Comfort at +$timeComfortBoost set FHT_Bad desired-temp $target;;;;set Bad_Boost_Status off;;attr Bad.Boost.Comfort room Bad";;\
}\
}\
}\
\
elsif(("$param" eq "measured-temp") && (Value("Bad_Boost_Status") eq "on")){\
if(($target-$value) lt $boostStop){\
fhem "set FHT_Bad desired-temp $target";;\
fhem "set Bad_Boost_Status off";;\
}\
}\
}
# Status speichert ob Boost an oder aus
define Bad_Boost_Status dummy
# Zielsollwert merken
define Bad_Boost_Zieltemp dummy
#define Bd.Boost.State dummy
#define Bd.Boost.Target dummy
#attr Bd.Boost.Check disable 1
#attr Bad_norm disable 0
#attr Bad_norm room Bad
#attr boost_Bad room Bad
##Twilight##
define Daemmerung Twilight 50.694900 8.474442 3 12833740
attr Daemmerung room Aussenbeleuchtung
### FS 20 ###
## Aussenbeleuchtung ##
define Auffahrt FS20 1235 21
attr Auffahrt IODev COC
attr Auffahrt model fs20st
attr Auffahrt room Aussenbeleuchtung
define Treppe FS20 1234 11
attr Treppe IODev COC
attr Treppe model fs20st
attr Treppe room Aussenbeleuchtung
## Log-Datei fürs Aussenlicht ##
#define FileLog_Treppe FileLog ./log/Treppe-%Y-%m.log Treppe
#attr FileLog_Treppe logtype text
#attr FileLog_Treppe room Aussenbeleuchtung
#define wl_FileLog_Treppe SVG FileLog_Treppe:wl_FileLog_Treppe_1:CURRENT
#attr wl_FileLog_Treppe room Plots
## Aussen mit einem Klick ##
define Aussen_kpl structure room Treppe Auffahrt
attr Aussen_kpl room Aussenbeleuchtung
## Zeitschaltuhren FS 20 ##
## Aussen ##
define ZSU_Aussen_kpl at *{sunset(0,"17:00","22:00")} set Aussen_kpl on-till 23:55
attr ZSU_Aussen_kpl room Aussenbeleuchtung
## Twilight für Aussen ##
#define TW_Aussen_kpl at *{ReadingsVal("Daemmerung","ss_civil","18:30:00")} set Aussen_kpl on-till 23:59
#attr TW_Aussen_kpl room Aussenbeleuchtung
## EGPM-Steckdosenleiste ##
define Leiste_HAS EGPM2LAN 192.168.0.61 1
attr Leiste_HAS room HAS
define Leiste_HAS_CS EGPM Leiste_HAS 1
attr Leiste_HAS_CS room HAS
define Leiste_HAS_WebCam EGPM Leiste_HAS 2
attr Leiste_HAS_WebCam room HAS
define Leiste_HAS_Test EGPM Leiste_HAS 3
attr Leiste_HAS_Test room HAS
define Leiste_HAS_TEST EGPM Leiste_HAS 4
attr Leiste_HAS_TEST room HAS
#Sunrise schaltet WebCam
define ZSU_WebCam_an at *{sunrise(60)} set Leiste_HAS_WebCam on
attr ZSU_WebCam_an room HAS
define ZSU_WebCam_aus at *{sunset(0)} set Leiste_HAS_WebCam off
attr ZSU_WebCam_aus room HAS
## ELRO-Steckdosen ##
define IT001 IT 00FFFFFFF0 FF F0
attr IT001 IODev CUNO
attr IT001 devStateIcon on:black_Steckdose.on off:black_Steckdose.off
attr IT001 room Flur
#define IT002 IT 00FFFFFF00 FF F0
#attr IT002 IODev CUNO
#attr IT002 devStateIcon on:black_Steckdose.on off:black_Steckdose.off
#attr IT002 room HAS
define IT003 IT 00FFFFF0FF FF F0
attr IT003 IODev CUNO
attr IT003 devStateIcon on:black_Steckdose.on off:black_Steckdose.off
attr IT003 room Esszimmer
define IT004 IT 00FFFF0FFF FF F0
attr IT004 IODev CUNO
attr IT004 devStateIcon on:black_Steckdose.on off:black_Steckdose.off
attr IT004 room Wohnzimmer
define Achims_AP IT 0FFFFF0FFF FF F0
attr Achims_AP IODev CUNO
attr Achims_AP devStateIcon on:black_Steckdose.on off:black_Steckdose.off
attr Achims_AP room Arbeitszimmer
define Andreas_AP IT 0FFFF0FFFF FF F0
attr Andreas_AP IODev COC
attr Andreas_AP devStateIcon on:black_Steckdose.on off:black_Steckdose.off
attr Andreas_AP room Arbeitszimmer
define WLAN IT 0FFFFFF0FF FF F0
attr WLAN IODev CUNO
attr WLAN devStateIcon off:black_Steckdose.off on:black_Steckdose.on
attr WLAN room Arbeitszimmer
define Drucker IT 0FFFFFFF0F FF F0
attr Drucker IODev CUNO
attr Drucker devStateIcon off:black_Steckdose.off on:black_Steckdose.on
attr Drucker room Arbeitszimmer
#Lüftungsanlage#
define Lueftung IT FFF0FFFFFF FF F0
attr Lueftung IODev COC
attr Lueftung room Lüftung
#attr Lueftung model fs20st
## Lüftung ##
define Lueftung_an at *06:00:00 {\
if ((!$we) && (!Value("Hessen_Ferientag"))){ \
fhem("set Lueftung on-till 22:30") } \
else { \
fhem ("define Lueftung_an_2 at +01:30 set Lueftung on-till 23:00")\
}\
}
attr Lueftung_an room Lüftung
## Weihnachten mit einem Klick ##
define Weihnachten_kpl structure room IT001 IT002 IT004
attr Weihnachten_kpl room Weihnachtsbeleuchtung
### Zeitschaltuhren ###
## W-LAN ##
define WLAN_an at *06:00:00 {\
if ((!$we) && (!Value("Hessen_Ferientag"))){ \
fhem("set WLAN on") } \
else { \
fhem ("define WLAN_an_2 at +01:00 set WLAN on")\
}\
}
attr WLAN_an room Arbeitszimmer
## Arbeitszimmer kompl. ##
define AP_kpl structure room Andreas_AP Achims_AP Drucker WLAN
attr AP_kpl room Arbeitszimmer
define AP_kpl_aus at *23:00 set AP_kpl off
attr AP_kpl_aus room Arbeitszimmer
## Weihnachten ##
## an ##
define ZSU_Weihnachten_kpl_an_sunset at *{sunset(0)} set Weihnachten_kpl on-till 23:00
attr ZSU_Weihnachten_kpl_an_sunset room Weihnachtsbeleuchtung
## aus ##
#define ZSU_Weihnachten_kpl_an_sunrise at *05:45 set Weihnachten_kpl on-till {sunrise(0)}
#attr ZSU_Weihnachten_kpl_an_sunrise room Weihnachtsbeleuchtung
## Linux Receiver ##
#Dreambox Wohnzimmer#
#define Dream ENIGMA2 192.168.0.10 80
#attr Dream bouquet-radio 1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio_deutsch.radio" ORDER BY bouquet
#attr Dream bouquet-tv 1:7:1:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.mein_tv.tv" ORDER BY bouquet
#attr Dream devStateIcon on:rc_GREEN:off off:rc_YELLOW:on absent:rc_STOP:on
#attr Dream http-method GET
#attr Dream icon dreambox
#attr Dream room Wohnzimmer
#attr Dream webCmd channel:input
#Dreambox Schlafzimmer#
#define Dream2 ENIGMA2 192.168.0.14 80
#attr Dream2 bouquet-radio 1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio_deutsch.radio" ORDER BY bouquet
#attr Dream2 bouquet-tv 1:7:1:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.mein_tv.tv" ORDER BY bouquet
#attr Dream2 devStateIcon on:rc_GREEN:off off:rc_YELLOW:on absent:rc_STOP:on
#attr Dream2 http-method GET
#attr Dream2 icon dreambox
#attr Dream2 room Schlafzimmer
#attr Dream2 webCmd channel:input
#Kathrein#
#define Kathi ENIGMA2 192.168.0.51 80
#attr Kathi devStateIcon on:rc_GREEN:off off:rc_YELLOW:on absent:rc_STOP:on
#attr Kathi http-method GET
#attr Kathi icon dreambox
#attr Kathi room Moritz
#attr Kathi webCmd channel:input
#define Kathi_Status dummy
#attr Kathi_Status devStateIcon on:Restart off:Shutdown
#attr Kathi_Status room Moritz
#attr Kathi_Status setList on off
#Linux-Boxen schalten CS_Steckdosenleiste#
#define Leiste_HAS_CS_on notify (Dream|Dream2) {\
if (Value("Dream") eq "absent" && Value("Dream2") eq "absent") {\
fhem "set Leiste_HAS_CS off"\
} else {\
fhem "set Leiste_HAS_CS on"\
}\
}
#Waschmaschine#
define Waschmaschine FS20 91ff 00
attr Waschmaschine IODev CUNO
attr Waschmaschine model fs20sms
attr Waschmaschine room Waschküche
#define FileLog_Waschmaschine FileLog ./log/FS20_91ff00-%Y-%m.log Waschmaschine
#attr FileLog_Waschmaschine logtype text
#attr FileLog_Waschmaschine room Waschküche
## Klingel Waschmaschine ##
define WM watchdog Waschmaschine:off 00:08:00 Waschmaschine:on {FBCall("**610")};; setstate WM defined
attr WM room Waschküche
#Garage#
#define Garagentor CUL_HOERMANN
#attr Garagentor room Garage
# freie Tage #
define Hessen_Feiertag holiday
attr Hessen_Feiertag room Kalender
# Schulferien Hessen #
define Hessen_Ferientag dummy
define Hessen_Ferien Calendar ical url http://www.schulferien.org/iCal/Ferien/icals/Ferien_Hessen_2014.ics 86400
attr Hessen_Ferien room Kalender
define Job_Hessen_Ferien_Check notify Hessen_Ferien { \
fhem "set Hessen_Ferientag " . (ReadingsVal("Hessen_Ferien", "modeStart", "") =~ "schulferien" ? 1: 0) }
## Sonstige ##
## Wetterbericht ##
#define Wetter weblink iframe http://www.wetteronline.de/cgi-bin/hpweather?PLZ=35644
#attr Wetter htmlattr width="200" height="400"
####Floorplan####
#define Aussen FLOORPLAN
#attr Aussen commandfield 1
#attr Aussen fp_arrange 1
#define EG FLOORPLAN
#attr EG commandfield 1
#attr EG fp_arrange 1
####Floorplan####
#attr Aussen commandfield 1
#attr Aussen fp_arrange 1
Nich in FHEM heisst es dm800se, sondern dein FritzBox hat es so genannt.
Verlinke das neue Thread hierher, und erwaehne im Titel, dass es um das ENIGMA2 Modul handelt.
Ja mache ich.
Aber wie bekomme ich diese "close-wait" Anfragen denn gelöscht bzw. in den Griff?
Hallo,
ich weiß, dass das Thema schon etwas älter ist, aber ich habe ein ähnliches Problem.
Danke schonmal für die Hinweise zur Ursachenforschung. Ich vermute, das bei mir das Problem die Funktion GoogleTalk ist. Könnt ihr mir da vielleicht weiterhelfen?
Anbei der Code der Funktion:
sub GoogleTalk($$) {
my ($message, $recipient) = @_;
use Net::XMPP;
my $conn = Net::XMPP::Client->new;
# individuelles Google-Konto zum Versenden
my $username = 'username';
my $domain = 'gmail.com';
my $password = 'password';
my $resource = 'FHEM';
my $status = $conn->Connect(
hostname => 'talk.google.com',
port => 5222,
componentname => $domain,
connectiontype => 'tcpip',
tls => 1,
);
die "Connection failed: $!" unless defined $status;
my ($res,$msg) = $conn->AuthSend(
username => $username,
password => $password,
resource => $resource,
);
die "Auth failed ", defined $msg ? $msg : '', " $!" unless defined $res and $res eq 'ok';
$conn->MessageSend(
to => $recipient,
resource => $resource,
subject => 'message via ' . $resource,
type => 'chat',
body => $message,
);
}
lsof hatte mir folgende endlossliste angezeigt:
perl 21360 fhem 995u IPv4 2171526 0t0 TCP FHEMPi.fritz.box:44043->ea-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 996u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 997u IPv4 2171553 0t0 TCP FHEMPi.fritz.box:44048->ea-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 998u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 999u IPv4 2171579 0t0 TCP FHEMPi.fritz.box:45388->ee-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1000u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1001u IPv4 2171605 0t0 TCP FHEMPi.fritz.box:45393->ee-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1002u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1003u IPv4 2171631 0t0 TCP FHEMPi.fritz.box:45398->ee-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1004u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1005u IPv4 2171657 0t0 TCP FHEMPi.fritz.box:45403->ee-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1006u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1007u IPv4 2171683 0t0 TCP FHEMPi.fritz.box:45408->ee-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1008u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1009u IPv4 2171715 0t0 TCP FHEMPi.fritz.box:45414->ee-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1010u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1011u IPv4 2171743 0t0 TCP FHEMPi.fritz.box:45420->ee-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1012u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1013u IPv4 2171769 0t0 TCP FHEMPi.fritz.box:44090->ea-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1014u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1015u IPv4 2171802 0t0 TCP FHEMPi.fritz.box:44098->ea-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1016u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1017u IPv4 2171828 0t0 TCP FHEMPi.fritz.box:44103->ea-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1018u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1019u IPv4 2171854 0t0 TCP FHEMPi.fritz.box:44108->ea-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1020u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1021u IPv4 2171889 0t0 TCP FHEMPi.fritz.box:44113->ea-in-f125.1e100.net:xmpp-client (ESTABLISHED)
perl 21360 fhem 1022u CHR 136,1 0t0 4 /dev/pts/1
perl 21360 fhem 1023u IPv4 2171911 0t0 TCP FHEMPi.fritz.box:44118->ea-in-f125.1e100.net:xmpp-client (ESTABLISHED)