AW: Avanti: bind() failed

[Thomas Berger]

Lieber Herr Fischer,

> mein Problem mit dem "bind() failed" besteht leider weiterhin.
> Seit wir den neuen Avanti-Server nutzen (etwa zwei Monate), ist er meines Wissens erst zwei Mal abgestürzt (vorher eher zweimal die Woche), aber etwa alle ein bis zwei Wochen tritt der  "bind() failed" auf, was den Server dann auch stilllegt bis zum Neustart.
> Da dies eindauerndes Ärgernis ist, möchte ich dem doch näher auf den Grund gehen.
> Ich gehe derzeit davon aus, dass
> - die Meldung zeigt, dass bei Neustart von Avanti der Port 4949 nicht verfügbar war,
> - das Problem behoben ist, wenn man den Server nach kurzer Pause (ca. 2 Min.) neu startet.
> 
> Aber der Grund des Auftretens liegt im Dunkel. Liegt es an den Avanti-Programmen, so sollte es auch bei anderen Intensiv-Nutzern regelmäßig auftreten, wenn nicht, gibt es vielleicht irgendein Problem in unseren Skripten.

...

In < http://www.gymel.com/bugzilla/show_bug.cgi?id=288 >
habe ich einen konkreten Fall beschrieben, in dem avanti-w
sich nicht neu starten kann: Kurz gesagt startet sich avanti
neu, obwohl er weiss, dass noch Verbindungen an den Socket
gebunden sind, dementsprechend scheitert dann das bind()
des Nachfolgeprozesses. (zugrunde liegt u.a. das avanti-Misfeature, 
dass "gesunde" Verbindungen beendet, "ungesunde" aber leben
gelassen werden. Selbst wenn der Client Verbindungen mittels 
Timeouts von sich aus ueberwachen und abbrechen wuerde, was etwas
elaboriertere Programmierung in Perl erforderte, liesse sich
dieses Serverseitige Fehlverhalten nicht komplett umgehen.
Allerdings ist es ohne Ueberwachung durch den Client wirklich
extrem: Sofern irgendein avanti-Job ein Timeout erfaehrt,
ist *garantiert*, dass der naechste Restart nicht funktionieren
wird)

Generell halte ich es fuer ausserordentlich schwierig,
einen selbst-restartenden Server zu programmieren, die
Beispiele, die mir einfallen, sind pre-forkende Server,
die bei einem Restart-Kommando nach und nach ihre
Subprozesse toeten und mit neuer Konfiguration neu
aufstarten. Selbst wenn das oben beschriebene Problem
behoben ist, gibt es immer noch das Problem, dass zwischen
Beenden und Neustart von avanti eine zeitliche Luecke besteht,
in der Clients keinen Server sehen koennen und ebenfalls
Fehler melden: Avanti muesste also schon "vorab" seinen
Nachfolger starten, und diesem dann nach einiger Zeit
mitteilen, dass er zu uebernehmen hat (dafuer koennte man
Shared Memory im Sinne von Semaphoren wirklich sinnvoll
einsetzen, muss aber nicht): Erst in diesem Moment wuerde
der Nachfolger dann versuchen, sich an den Socket zu binden
(bzw. noch besser: die Bindung des alten Prozesses uebernehmen).
Das wird dann allers so schwierig auf die unterschiedlichen
Plattformen portierbar sein, dass man vielleicht doch lieber
das Memory-Leak, das der Grund fuer die Implementierung des
Restart-Features war, ausfindig macht...

viele Gruesse
Thomas Berger