Problème de port déjà utilisé

[AmC]

Pour ceux qui seraient confrontés aux problèmes, lors d'un rehash ou restart de l'eggdrop suivant :

this port is already bound to a specific IP on this machine, remove it before trying to bind to all interfaces

Voici une modification à apporter dans la conf de l'eggdrop à l'emplacement du listen :

Si on prends pour exemple : 

tcl

listen 3334 all

Il faut ajouter une petite condition pour éviter que le bot se crash en essayent de ré utiliser un port déjà utilisé.

tcl

if { ![string match *3334* [dcclist telnet]] } {
    listen 3334 all
}

[CrazyCat]

Le souci est bien que l'eggdrop tente de remettre ce port en écoute trop vite (avant de l'avoir fermé ?)
Je ne l'ai jamais reproduit, mais je n'utilise jamais les ports en all, ce qui peut être une des causes, quelle que soit la version d'eggdrop (de 1.6.21 à 1.9).

Question à 0.30€ : avec cette modification, est-ce que le port reste accessible pour les nouvelles connexions après le rehash/restart ?

[AmC]

Je vois pas comment répondre avec exactitude à ta question, mais oui le port est toujours accessible, je n'ai plus aucune erreur, l'eggdrop ne plante plus.

[ZarTek]

Question à 0.30€ : avec cette modification, est-ce que le port reste accessible pour les nouvelles connexions après le rehash/restart ?

La question qui me viens dans le cadre du "bug" est si cette méthode corrige le bug si le soucis est :

Le souci est bien que l'eggdrop tente de remettre ce port en écoute trop vite (avant de l'avoir fermé ?)

car si le port ce remet en ecoute trop vite lors du rehash, nous pouvons imaginer que le port qui est déjà en écoute ce ferme peu apres.
Lorsque

tcl

if { ![string match *3334* [dcclist telnet]] } {
    listen 3334 all
}

est exécuté, si le port est "encore ouvert" il ne le réouvrira pas a ca fermeture un peu plus tard.

si ce n'ai pas le cas; il est possible que eggdrop essaye d'ouvrire les listens avant de charger la conf/tcl

[CrazyCat]

En fait, il y a deux cas de figure:
1. Lors d'un rehash/restart, si le port est en cours d'utilisation (utilisateur connecté sur le port), l'eggdrop ne le referme pas. Dans ce cas, l'astuce donnée par AmC est ok.
2. L'eggdrop ferme le port "trop tard", et dans ce cas il n'est plus ouvert ensuite. Dans ce cas, je serai d'avis de dupliquer l'astuce: l'avoir où elle est et aussi dans la procédure evnt:init_server pour ouvrir le port lorsque l'eggdrop est connecté sur le serveur

Quitte à créer une (ou des) variable(s) pour les ports, comme je l'ai fait dans ma configuration multi-eggdrops