hab gerade Zeit gefunden, ein Problem zu debuggen, welches seit ein paar Tagen auffällig war.
Und zwar zog bei Aufruf des pihole dashboards php-cgi volle CPU.
Im error-log von lighttpd mehrfach pro Sekunde:
FastCGI-stderr: PHP Warning: socket_read(): unable to read from socket [104]: Connection reset by peer in /var/www/html/admin/scripts/pi-hole/php/FTL.php on line 107
(Hat mir nebenbei die HDD gefüllt... :-))
Als Grund stellt sich raus, dass pihole-FTL sich nicht auf Port 4711 binden kann.
(Korrekt, den dort lauft ein anderer Prozess, der früher startet)
2018-03-31 08:55:18.475] Error listening on IPv4 port 4711: Address already in use (98)
[2018-03-31 08:55:18.475] Listening on port 4711 for incoming IPv6 telnet connections
Soweit ich hier richtig bezügl. Port 4711 recherchiert habe, sollte bei Binding-Problemen auf 4711
4712, 4713 ... usw probiert werden, bzw. haben ältere Versionen das gemacht.
Workaround für mich: Der andere Prozess läuft jetzt woanders...
Sollte uns das zu denken geben? Port 4711 wurde gewählt, da es in FTLs Heimat (Köln) eine wohlbekannte Zahl ist. Ist Dein anderer Prozess dort per Standard beheimatet? Wenn ja, was ist es (haben wir noch nie von gehört)?
Ist Dein anderer Prozess dort per Standard beheimatet? Wenn ja, was ist es (haben wir noch nie von gehört)?
Ja. Auf der virtuellen Maschine läuft noch mein FHEM.
Das Sonos-Modul erstellt einen Prozess, der ohne weitere definition auf Port 4711 lauscht. https://wiki.fhem.de/wiki/SONOS
Das ist aber PHPs Problem. Mal schauen wie man das verbessern kann.
... naja, das scheint glücklicherweise nicht allzu weit verbreitet zu sein, denn sonst hätten wir da schon vorher von gehört, Danke für den Hinweis.
Ja, es hat sich als umständlich herausgestellt (und man wusste im zweifel nie wo FTL anzutreffen ist, wenn man von extern Anfragen gestellt hat), wird jetzt aber möglicherweise wieder eine Option werden...
Das kann man z.Zt. nicht mehr offiziell, denn es hat zu viel Verwirrungen geführt und man muss es in Pi-hole dann an vielen Stellen (Web API, Chronometer Skript, ...) ändern. Ist es nicht möglich die Alexa Bridge auf einen anderen Port zu setzen?
schade eigentlich, sowas paremetierbar zu machen ist doch immer besser, der liebe Kollege hat mir den Parameter in der Alexa Bridge eingebaut, ich bin somit versorgt...
aber 4711 ist wie 0815, eher suboptimale Lösung 8-:
Dieser Port ist nicht offiziell registriert und somit frei verfügbar (815 ist ipcserver )
4711 hat eine Bedeutung in der Heimat von FTL (Köln)
Und ja, so etwas könnte parametrierbar sein, ist es aber z.Zt. nicht. Unser langfristiger Plan ist eh von einem Port wegzugehen und auf Unix Sockets umzusteigen (FTL bietet das bereits an), das ist aber noch nicht passiert.
Welcher "liebe Kollege"? Sollte ich den kennen? Wenn nein, woher kommt die Besorgnis? Hat er den Port frei erfunden oder hast Du ihm gesagt, dass Pi-hole dort läuft? Wir sagen an mehreren Punkten offiziell, dass Pi-hole 53, 80 und 4711 braucht.
Scherz beiseite: ich kannte es wirklich nicht bis es ein Nutzer hier erwähnt hatte (warst Du das vielleicht sogar?).
Ja, lightppd ist ziemlich lästig was das angeht. Ich habe z.Zt. eine Verbesserung hierfür in Arbeit, wir werden uns aber eh bald von lighttpd und PHP verabschieden, dann wird auch Port 4711 wegfallen oder zumindest optional werden.
Ich hab das jetzt mal absichtlich nachgestellt und einfach 3 Stunden laufen lassen... die Logs sind dabei um die 2 GB... Man muss hier allerdings berücksichtigen dass das nicht die pihole logs sind sondern PHP Logs! Für die Entwicklung von PHP sind die Jungs hier schlichtweg nicht zuständig und welches Loglevel du auf Webserver / PHP Ebene verwendest obliegt ja jedem selbst.
Wenn das entsprechend reduziert wird im Loglevel dann hast du das auch nicht in den Logs.
Selbst welchen Webserver du verwendest ist allein die Entscheidung des Admins. Pihole gibt hier nur eine Variante vor die Ressourcenschonend ist.
Damit obliegt dein hauptsächliches Problem bei dir selbst?
Ob pihole oder FHEM sich gegenseitig kennen ist auch zweitrangig denn für die Portnutzung ist doch jeder Admin selbst verantwortlich. Einen Port der weltweit in keiner Software genutzt wird gibt es schlichtweg nicht und die einzige Lösund sind Unix Sockets, das kommt mit v4.
Das einzige was hier wirklich schief läuft ist die fehlende Doku über die Portangabe denn diese Option findet man nur wenn man direkt im Code sucht. Hier muss man dann allerdings wissen wonach man sucht.
Alles in allem liegt trotz der bequemen installer und configs immer noch das Hauptaugenmerk beim Admin
Sorry, aber davon musst du dich mal lösen, 4711 ist wohl Bundesweit das gleiche (im Sprachgebrauch ) wie 0815... zumindest hier im Frankfurter Raum... also Konflike durchaus wahrscheinlich...
wie auch immer :Parametriesierbar ist doch perfekt...
Wieso? Mir ist schon klar, dass 4711 über die Stadtgrenzen hinaus bekannt ist, aber wieso sollte es wahrscheinlicher sein als 4986 oder 5531 oder dergleichen? Wenn wir jetzt den Port ändern, dann dauert es vermutlich nur kurze Zeit und ein neuer Konflikt tritt auf. Wir haben 4711 nun schon deutlich über ein Jahr im Einsatz und die erste Beschwerde ist immer noch recht neu.
Es darauf ankommen lassen, dass Leute dieses FHEM auf dem gleichen Gerät installieren ist denke ich wesentlich sinnvoller als irgendwas ändern. Und wie Du sagtest, parametrierbar ist es schon.
Das Problem/der Bug ist, das Pihole trotz des Bindungproblems startet.
Imho müsste der Start von pihole mit einer entsprechenden Meldung unterbunden werden.
Mir ist das Problem nur durch die Seiteneffekte aufgefallen.
Die langsamen DNS antworten habe ich noch auf die Telekom geschoben.
Als mir dann auffiel, dass die FHEM weboberfläche nix mehr tat, hab ich mal ne Konsole aufgemacht...
Ich bin ja gerne bereit das Problem für uns alle zu minimieren und habe nicht vor es mit so etwas wie "die nächste Generation des Webinterfaces wird das Problem lösen" abzuspeisen.
Aktuell gibt es folgende Vorkehrung: Noch bevor versucht wird den Port zu erreichen, ermittelt das PHP Skript ob eine Anwendung mit dem Namen "pihole-FTL" läuft. Ist dies nicht der Fall, wird das Skript sofort abgebrochen!
Nun: Hat jemand einen Tipp wie ich den PHP Fehler nachstellen kann? Meine Experimente waren diesbezüglich nicht sonderlich erfolgreich und haben im wesentlichen bestätigt, dass die bereits installierte Vorkehrung für mich funktioniert:
Läuft FTL, dann kommt der Fehler logischerweise nicht.
Lasse ich ein Dummy-Programm auf Port 4711 laufen und versuche dann FTL zu starten, beendet sich FTL selbstständig und die gleiche Situation wie bei gestopptem FTL liegt vor (ebenfalls keine Fehler im lighttpd log).
Nachstellen kann ich es nur wenn ich pihole-FTL im Debugger laufen lasse und dort per SIGINT o.Ä. anhalte. Das ist aber wohl eher eine unübliche Konfiguration gegen die wir uns vielleicht auch gar nicht schützen können.
)
Scherz beiseite: ich kannte es wirklich nicht bis es ein Nutzer hier erwähnt hatte (warst Du das vielleicht sogar?).