Saltar al contenido principal

​
Bloqueo del Gateway

​
Por qué

  • Garantizar que solo se ejecute una instancia del gateway por puerto base en el mismo host; los gateways adicionales deben usar perfiles aislados y puertos únicos.
  • Sobrevivir a fallos/SIGKILL sin dejar archivos de bloqueo obsoletos.
  • Fallar rápidamente con un error claro cuando el puerto de control ya está ocupado.

​
Mecanismo

  • El gateway vincula el listener WebSocket (predeterminado ws://127.0.0.1:18789) inmediatamente al iniciar usando un listener TCP exclusivo.
  • Si el bind falla con EADDRINUSE, el inicio lanza GatewayLockError("another gateway instance is already listening on ws://127.0.0.1:<port>").
  • El sistema operativo libera el listener automáticamente al salir cualquier proceso, incluidos fallos y SIGKILL; no se necesita un archivo de bloqueo independiente ni un paso de limpieza.
  • Al apagarse, el gateway cierra el servidor WebSocket y el servidor HTTP subyacente para liberar el puerto con rapidez.

​
Superficie de error

  • Si otro proceso mantiene el puerto, el inicio lanza GatewayLockError("another gateway instance is already listening on ws://127.0.0.1:<port>").
  • Otros fallos de bind aparecen como GatewayLockError("failed to bind gateway socket on ws://127.0.0.1:<port>: …").

​
Notas operativas

  • Si el puerto está ocupado por otro proceso, el error es el mismo; libera el puerto o elige otro con openclaw gateway --port <port>.
  • La app de macOS sigue manteniendo su propia protección ligera por PID antes de iniciar el gateway; el bloqueo de tiempo de ejecución se aplica mediante el bind de WebSocket.

​
Relacionado