Sonos Probleme mit fhem Log

[Reinerlein]

Hi Claudiu,

aus irgendeinem Grund will dein System den Port nicht sofort wieder hergeben... ich weiss nicht, ob es dazu noch eine Perl-Einstellung gibt? kennst du da was?

Ich habe jetzt noch was an der Reihenfolge der Beendigung gedreht, und ein paar kurze Thread-freigebende Wartezeiten eingebaut... vielleicht bewirkt es ja was...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

hat leider wieder nicht geklappt.

Habe zwar früher recht viel mit Perl gemacht, allerdings kenne ich bzgl. Sockets auch nur close() und shutdown()
Wüsste nicht dass es da noch was anderes gibt, glaube nur mich zu erinnern dass nach einem shutdown() immer noch ein close() notwendig ist.

Allerdings habe ich grad meine Fhem-VM geclont, räum die mal noch bisl auf, richte noch schnell paar NAT Regeln in der Firewall ein, und lass dir mal die Daten zukommen.
Dann kannst du dich mal da draufschalten und Testen, ohne dass was kaputt gehen kann

Gruß Claudiu

[Reinerlein]

Hi Claudiu,

OK, das ging aus der Doku, die ich zu shutdown gelesen hatte, leider nicht so deutlich hervor... Ich habe jetzt noch zu jedem Shutdown ein Close dazugeschrieben...

Strohhalme, überall Strohhalme

Grüße
Reinerlein

P.S: Das mit der Testmaschine klingt gut... da kann man die Turn-Around-Zeiten etwas verringern

[rapster]

Hi Reinerlein,

das hier habe ich noch gefunden, evtl. hilft das?

SO_LINGER
              Sets or gets the SO_LINGER option.  The argument is a linger
              structure.

                  struct linger {
                      int l_onoff;    /* linger active */
                      int l_linger;   /* how many seconds to linger for */
                  };

              When enabled, a close(2) or shutdown(2) will not return until
              all queued messages for the socket have been successfully sent
              or the linger timeout has been reached.  Otherwise, the call
              returns immediately and the closing is done in the background.
              When the socket is closed as part of exit(2), it always
              lingers in the background.

Quelle: http://man7.org/linux/man-pages/man7/socket.7.html

Liegt es vll. daran das Sonos auf der Testmaschine früher geladen wird (weil sonst keine module geladen werden) dass Fhem komplett stirbt?
Wenn man hier evtl. einfach mal irgendein Modul davorstellt damit etwas mehr zeit vergeht, bzw. vll. funktioniert es auch mit einem simplen sleep?

Gruß Claudiu

[Reinerlein]

Hi Claudiu,

interessante Option, aber wir brauchen eigentlich genau das Gegenteil, nämlich blockierendes Warten, bis der Socket wieder freigegeben wurde (egal, ob das was da drin liegt noch abgeholt wird oder nicht).

Hier steht was davon, dass er das Schließen der Kommunikation dann im Hintergrund ausführt. Es fühlt sich so an, als würde er das hier an dieser Stelle auch machen...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

aber genau so versteh ich das ja auch:

When enabled, a close(2) or shutdown(2) will not return until
              all queued messages for the socket have been successfully sent[/b]
              or the linger timeout has been reached.  Otherwise, the call
              returns immediately and the closing is done in the background.

Also wenn man das aktiviert, sollte er quasi so lange das close() ausführen bis der Port wirklich geschlossen ist, bzw. der eingestellte Timeout erreicht ist.

Gruß Claudiu

[Reinerlein]

Hi Claudiu,

gewisse Dinge sollte ich wirklich nicht mehr spätabends machen Du hast wohl recht...
Ich habe es gerade mal eingebaut, und gleich den logischen Fehler gesehen, da es keine Veränderung gebracht hat:
Bei unserem Problem geht es darum, dass der Prozesstarter (die "Fhem-Ebene") erst dann den neuen Prozess anstarten dürfte, wenn der alte sauber weg ist (bzw. der Port wieder frei ist). Das wird aber über diese Option gar nicht gelöst. Zwar geht der SubProzess selbst erst dann weiter (zum exit()), wenn der Port geschlossen ist, aber der Prozessstarter weiß davon nix, und versucht trotzdem sofort einen neuen Subprozess zu starten, der dann doch wieder einen blockierten Port vorfindet...

Ich denke, wir haben es hier mit einer notwendigen Synronisation zu tun, die wir ja gerade in diesem Augenblick trennen wollen (die Verbindung), und der einzig saubere Weg ist da das zyklisch wiederholte Prüfen, ob der Port jetzt endlich frei ist...

Grüße
Reinerlein

[rapster]

Hi Reinerlein,

auf jedenfall schaut es ja jetzt ganz gut aus denk ich 

Grad mal verschiedenes ausprobiert was zuvor zu dem Fehler geführt hat, und das Modul startet einwandfrei!

Danke dir!
Gruß Claudiu