Gateway

Verrou du Gateway

Pourquoi

Un seul processus Gateway doit gérer une configuration et un port donnés sur un hôte ; exécutez les Gateway supplémentaires avec des profils isolés et des ports uniques.
Résister aux plantages/SIGKILL sans laisser de fichiers de verrouillage obsolètes.
Échouer rapidement avec une erreur claire lorsqu’un autre Gateway gère déjà le port.

Au démarrage, la propriété de l’instance unique est garantie en deux étapes indépendantes, dans l’ordre suivant :

Le verrouillage de fichier acquiert un fichier de verrouillage propre à la configuration dans le répertoire des verrous d’état. Lors de cette acquisition, le démarrage sonde le port configuré pour détecter un processus à l’écoute et identifier un propriétaire de verrou obsolète à la suite d’un plantage.
La liaison de socket lie le point d’écoute HTTP/WebSocket (par défaut ws://127.0.0.1:18789) en tant que point d’écoute TCP exclusif.

Chaque niveau peut échouer indépendamment et lève sa propre erreur GatewayLockError.

Si le fichier de verrouillage est absent, si le processus propriétaire enregistré n’existe plus ou si la sonde du port du propriétaire ne détecte aucun processus à l’écoute, le démarrage récupère le verrou et se poursuit.
Si le verrou est activement détenu et qu’aucune des conditions ci-dessus ne s’applique, le démarrage réessaie pendant un maximum de 5 secondes (par défaut) avant d’abandonner :
text
```
GatewayLockError("gateway already running (pid <pid>); lock timeout after <ms>ms")
```

En cas de EADDRINUSE, le démarrage réessaie la liaison jusqu’à 20 fois à intervalles de 500 ms (environ 10 secondes au total) afin de laisser expirer une période TIME_WAIT après l’arrêt récent d’un processus.

Si le port est toujours utilisé après les nouvelles tentatives :

text

GatewayLockError("another gateway instance is already listening on ws://127.0.0.1:<port>")

Autres échecs de liaison :

text

GatewayLockError("failed to bind gateway socket on ws://127.0.0.1:<port>: <cause>")

Lors de l’arrêt, le Gateway ferme le serveur HTTP/WebSocket et supprime le fichier de verrouillage.

Si le port est occupé par un processus différent qui n’est pas un Gateway, l’erreur est la même ; libérez le port ou choisissez-en un autre avec openclaw gateway --port <port>.
Sous la supervision d’un gestionnaire de services, un nouveau processus Gateway qui rencontre l’une des erreurs ci-dessus sonde d’abord /healthz sur le processus existant. Si ce processus est sain, le nouveau processus lui laisse le contrôle au lieu d’échouer. Sous systemd, il se termine avec le code 78 ; le paramètre RestartPreventExitStatus=78 de l’unité empêche Restart=always de boucler en cas de conflit de verrouillage ou de EADDRINUSE. Si le processus existant ne devient jamais sain, les nouvelles tentatives de sondage d’intégrité sont limitées dans le temps, puis le démarrage échoue avec l’erreur de verrouillage ci-dessus au lieu de boucler indéfiniment.
L’application macOS conserve son propre contrôle léger du PID avant de lancer le Gateway ; le verrouillage de fichier et la liaison de socket décrits ci-dessus constituent les véritables mécanismes d’application à l’exécution.

Was this useful?