Bloqueo de Gateway

Última actualización: 2025-12-11

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

• El gateway vincula el listener WebSocket (por defecto ws://127.0.0.1:18789) inmediatamente al inicio usando un listener TCP exclusivo.
• Si el bind falla con <code>EADDRINUSE</code>, el inicio lanza <code>GatewayLockError("otra instancia de gateway ya está escuchando en ws://127.0.0.1:<puerto>")</code>.
• El OS libera el listener automáticamente en cualquier salida del proceso, incluyendo crashes y SIGKILL—no se necesita archivo de bloqueo separado ni paso de limpieza.
• Al apagar, el gateway cierra el servidor WebSocket y el servidor HTTP subyacente para liberar el puerto prontamente.

• Si otro proceso tiene el puerto, el inicio lanza <code>GatewayLockError("otra instancia de gateway ya está escuchando en ws://127.0.0.1:<puerto>")</code>.
• Otros fallos de bind se muestran como <code>GatewayLockError("falló al vincular socket de gateway en ws://127.0.0.1:<puerto>: …")</code>.

• Si el puerto está ocupado por otro proceso, el error es el mismo; libera el puerto o elige otro con <code>openclaw gateway --port <puerto>'</code>.
• La app macOS aún mantiene su propio guardia PID ligero antes de spawnear el gateway; el bloqueo de runtime es aplicado por el bind WebSocket.