Seite 5 von 5
Re: Webserver bzw. Problem mit SendNetworkData()
Verfasst: 30.07.2020 10:19
von HeX0R
Ich kann das nicht bestätigen.
Bei mir läuft seit Jahren ein PB-Tool unter Debian auf nem VServer (als SMTP tunnel), das ist weder jemals abgestürzt, noch war der Port geblockt, wenn ich es mal neu gestartet habe (also richtig beendet und neu gestartet, nicht "abgeschossen").
Re: Webserver bzw. Problem mit SendNetworkData()
Verfasst: 30.07.2020 12:50
von mk-soft
Bei macOS habe ich es auch manchmal das der Server-Port nicht sofort verfügbar ist.
Einfach eine loop mit Delay programmieren bis das System den Port wieder frei gibt.
War schon irgendwo als Bug gemeldet.
Re: Webserver bzw. Problem mit SendNetworkData()
Verfasst: 02.08.2020 22:56
von stevie1401
Ich habe das heute einmal mit einer loop-Schleife getestet. Aber als der Server nach 10 Minuten immer noch nicht wollte, gab ich auf. Erst als Linux neu gestartet war, ging der Port wieder.
Re: Webserver bzw. Problem mit SendNetworkData()
Verfasst: 03.08.2020 12:21
von mk-soft
Das is eine anderes Problem und hat nichts mit PB zu tun ...
Eventuell das Program lief im Hintergrund weiter, oder der Port wird von etwas anderen benutzt.
Das System räumt normaler weise dieses innerhalb einer Minute auf ...
Re: Webserver bzw. Problem mit SendNetworkData()
Verfasst: 03.08.2020 12:49
von NicTheQuick
stevie1401 hat geschrieben:Ich habe das heute einmal mit einer loop-Schleife getestet. Aber als der Server nach 10 Minuten immer noch nicht wollte, gab ich auf. Erst als Linux neu gestartet war, ging der Port wieder.
Ich glaube das Standard-Timeout ist hierfür 120 Sekunden. Spätestens dann sollte der Port also wieder frei sein. Falls das nicht der Fall ist, dann läuft der Prozess definitiv noch im Hintergrund. Gib dazu im Terminal folgenden Befehl ein: netstat -tlnp
Dann siehst du sowas:
Code: Alles auswählen
(Es konnten nicht alle Prozesse identifiziert werden; Informationen über
nicht-eigene Processe werden nicht angezeigt; Root kann sie anzeigen.)
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1779827/nc
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:5943 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN -
tcp6 0 0 :::1716 :::* LISTEN 15113/kdeconnectd
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:631 :::* LISTEN -
tcp6 0 0 ::1:25 :::* LISTEN -
tcp6 0 0 :::873 :::* LISTEN -
In der vierten Spalte siehst du Adresse und Port eines lauschenden Serverprozesses und in der letzten Spalte der dazugehörige Prozess. Bei mir lauscht zum Beispiel gerade netcat (nc) auf Port 8080 auf allen IPv4-Interfaces (0.0.0.0). Die Prozessnamen siehst du aber nur, wenn du die Prozesse auch mit den Rechten deines aktuellen Nutzers gestartet hast. Ansonsten siehst du als root auch alles.
Re: Webserver bzw. Problem mit SendNetworkData()
Verfasst: 14.04.2022 10:05
von stevie1401
Mit Purebasic6 Beta 6 ist das Problem leider nicht behoben.
Hat jemand inzwischen eine Lösung gefunden?
Gibt es nicht einen Linux-Befehl, der den blockierten Port wieder freigeben kann?
Re: Webserver bzw. Problem mit SendNetworkData()
Verfasst: 23.01.2024 20:23
von NicTheQuick
Anfang des Jahres hat Fred zu dem Problem geschrieben, dass er sich das anschauen muss:
https://www.purebasic.fr/english/viewto ... 37#p614237
Re: Webserver bzw. Problem mit SendNetworkData()
Verfasst: 11.02.2024 13:00
von stevie1401
Der Fehler ist mit Version 6.10 beta 6 endlich behoben
Re: Webserver bzw. Problem mit SendNetworkData()
Verfasst: 11.02.2024 17:18
von mk-soft
War kein Fehler sondern eine Standard Eigenschaft von Linux und macOS die man ändern kann