Der Tunneldigger Client selbst ist Single threaded, einzig die DNS Auflösung ist multi threaded. Aber es ist vermutlich die DNS Auflösung die das Problem darstellt.
Daher checke ich nachher mal die Zahl der Threads.
Schon klar…
ich hatte nur bisweilen (früher) auch mal Probleme mit einem restartenden Tunneldigger obwohl der Restart gar nicht nötig gewesen wäre… Oder aber der alte als Semi-Zomi noch im Speicher hing und wegen Fehlern im Init-Script nicht terminiert wurde.
Ja, deshalb ist der Watchdog ja anscheinend bereits ins Tunneldigger Hauptpaket gewandert und ist nicht mehr gesondert paketiert.
Der Code ist aus meiner Sicht recht anfällig für undefinierte Zustände.
Ich fürchte meine Änderungen könnten einen Zustand zulassen bei dem bei der DNS Auflösung was schiefläuft und dann die Dauerschleife bei 100% CPU anschlägt.
Ein Rewrite wäre sicherlich nicht unangebracht, für mich aber nicht auf einem definierten Zeithorizont machbar (soll heißen: selbst wenn ich anfange weiß ich nicht wann es fertig würde). Wobei ich aber schon gerne mal eine Sprache wie Rust ausprobieren will, die es angeblich einfacher macht sicheren und speichereffizienten Code zu schreiben.
Es häufen sich aktuell die Problemmeldungen bei uns im Netzwerk, dass zwar eine IP per DHCP kommt aber kein Internetzugang möglich ist. Ich rolle jetzt also nochmal eine Version aus ohne IPv6 Support um zu schauen ob das Problem dadurch gelöst werden kann.
Interessanterweise habe ich mit iperf durch den Tunnel über IPv6 keinerlei Bandbreitenprobleme und auch keine Unterschiede zwischen v4 und v6 Tunneln entdecken können.
Auch mein Knoten hier zuhause hat über v6 keinerlei Probleme. Ich bekomme hier bis zu 40-50 MBit/s durch, was für Tunnel über den großen Teich kein schlechter Wert ist.
Vielleicht können noch mehr Leute das mal testen? Wir scheinen hauptsächlich mit NetCologne Anschlüssen Probleme.