DevIo_Disconnected problem

[justme1968]

du wirst dich sicher noch an die diskussion um das schliessen der offenen filedescriptoren beim BockingCall erinnern und das mit meinem patch erst mal nur die sockets geschlossen werden weil du der meinung warst alles andere würde kein tatsächlich existierendes problem beheben.

ich habe in letzter zeit zufällig folgendes verhalten beobachtet und erste tests deuten darauf hin das es daran liegt das die offenen usb devices nach einem fork nicht geschlossen werden.

beim abziehen eines cul oder panstamp und ich vermute jedes anderen usb devices merkt fhem das keine daten mehr kommen und ruft DevIo_Disconnected auf. es gibt dann die meldung das fhem darauf wartet das das device wieder erscheint. das funktioniert zu 100% nicht wenn gleichzeitig ein BlockingCall läuft. in diesem fall wird beim wieder ein stecken unter linux nämlich nicht mehr das gleiche usb device vergeben sondern das nächste freie. ich bin mir ziemlich sicher das es daran liegt das das ursprüngliche device im child noch geöffnet ist. wenn kein BlockingCall läuft funktioniert das reconnect einwandfrei.

würdest du einen patch der die usb devices nach dem fork schliesst akzeptieren? wenn nicht muss ich mich auch nicht weiter ans debuggen und patchen machen :) wenn ja wäre es hilfreich eine zentrale liste mit den geöffneten devices zu haben. so wie ähnlich wie es sie bei den TcpServerUtils gibt.

eine globale lösung könnte so aussehen das jedes modul seine filedescriptoren zentral zum schliessen registrieren könnte. und optional einen callback der das schliessen und neu öffnen übernehmen kann wenn es komplizierter wird als nur close aufzurufen. damit könnte man dann auch plotfork mit sqlite zum laufen bekommen (Link)

[rudolfkoenig]

Seufz, Du hast mit deiner Vermutung recht.

Man koennte die Schleife in Blocking.pm umbauen nach

Code Auswählen Erweitern

 # Child here
  foreach my $d (sort keys %defs) {   # Close all kind of FD
    my $h = $defs{$d};
    TcpServer_Close($h) if($h->{SERVERSOCKET});
    DevIo_CloseDev($h)  if($h->{DeviceName});
  }

hoffentlich hat es keine Nebeneffekte.
Koennt Ihr das bitte testen bevor ich das einchecke?

Alternativ ueberzeugen wir Markus (sonst verwendet keiner BlockingCall), dass er auf BlockingCall verzichtet :), und statt
- sleep() den InternalTimer von fhem werwendet
- statt qx() eine eigene Funktion verwendet, was das Programm startet, und mit dem globalen select auf dessen Aufgabe wartet.
Ok, es war nicht ganz ernst gemeint, da er dafuer einiges umbauen muesste.

[justme1968]

ich teste das heute abend oder morgen.

ich hatte gedacht das owserver auch BlockingCall verwendet. beim nachschauen eben hab ich aber gesehen das es selber forkt. da müsste man die beiden close eigentlich auch einbauen.

weiterhin fällt mir dann noch die gerade in arbeit befindliche asynchrone owx version ein. ich habe aber noch nicht geschaut ob dort BlockingCall oder fork direkt oder keins von beiden verwendet wird.

[Dirk]

Hallo Zusammen,

meine derzeitige Version von HM485 nutzt auch BlockingCall.
Ich sehe hier im Moment auch keine Alternative.

Gruß
Dirk

[Markus Bloch]

Hallo zusammen,

ich habe gerade mal Rudi's Vorschlag bei mir getestet. Gott sei Dank hat er funktioniert, somit bleibt mir ein umschreiben erspart ;-)

Jetzt müsste Andre das ganze mit seinem CUL ausprobieren.

Viele Grüße

Markus

[justme1968]

der vorschlag scheint ohne nebeneffekte zu funktionieren. zumindest bei mir und für BlockingCall.

ich musste noch die module die direkt forken deaktivieren (beim mir sind das owserver und xbmc) sonst funken die noch dazwischen.

[ntruchsess]

weiterhin fällt mir dann noch die gerade in arbeit befindliche asynchrone owx version ein. ich habe aber noch nicht geschaut ob dort BlockingCall oder fork direkt oder keins von beiden verwendet wird.

Das Asynchrone OWX verwendet Threads für die Bedienung der Seriellen Schnittstelle (passiever Adapter oder DS2480 Busmaster). Die Frage ist, wie perl das mit den File-descriptoren bei Threads intern handhabt. Es werden beim Starten eines neuen Threads ja alle Kopieen aller Variablen angelegt. Eine perl-variable sollte unabhängig vom tatsächlich belegten File-descriptor auf OS-ebene existieren, wenn ein Tread nun einen File-descriptor schließt, sollten die Kopieen in den anderen Threads zwar erhalten, aber nicht mehr auf einen gültigen Filedescriptor verweisen. Könnte ggf. ein Problem werden, wenn ein solcher Thread versucht den schon geschlossenen FD weiter zu verwenden. Genauer untersucht habe ich das jedenfalls noch nicht, habe aber schon bemerkt, dass der Reconnect beim Abziehen und Wiederanschließen eines über FT232RL am USB angeschlossenen DS2480 nicht immer zuverlässig funktioniert.

Gruß,

Norbert