Gestiona servicios OpenClaw con daemon: Guía de comandos

¿Alguna vez has sentido que gestionar servicios en segundo plano es un dolor de cabeza? Configurar procesos manualmente suele ser una tarea pesada y llena de errores de permisos.

Si vienes trabajando con versiones anteriores, este comando te resultará familiar. Es básicamente un alias para mantener la compatibilidad mientras migras a la nueva estructura.

openclaw daemon

Alias heredado para los comandos de gestión del servicio Gateway.

openclaw daemon ... se mapea a la misma superficie de control del servicio que los comandos de servicio openclaw gateway ....

Uso

openclaw daemon status
openclaw daemon install
openclaw daemon start
openclaw daemon stop
openclaw daemon restart
openclaw daemon uninstall

Subcomandos

• status: muestra el estado de instalación del servicio y sondea la salud del Gateway
• install: instala el servicio (launchd/systemd/schtasks)
• uninstall: elimina el servicio
• start: inicia el servicio
• stop: detiene el servicio
• restart: reinicia el servicio

Opciones comunes

• status: --url, --token, --password, --timeout, --no-probe, --require-rpc, --deep, --json
• install: --port, --runtime <node|bun>, --token, --force, --json
• ciclo de vida (uninstall|start|stop|restart): --json

Notas:

• status resuelve los SecretRefs de autenticación configurados para el sondeo de autenticación cuando es posible.
• Si un SecretRef de autenticación requerido no se resuelve en esta ruta de comando, daemon status --json informa un rpc.authWarning cuando falla la conectividad o autenticación del sondeo; pasa --token/--password explícitamente o resuelve la fuente del secreto primero.
• Si el sondeo tiene éxito, se suprimen las advertencias de auth-ref no resueltas para evitar falsos positivos.
• En las instalaciones de systemd en Linux, los chequeos de drift del token de status incluyen tanto las fuentes de unidad Environment= como EnvironmentFile=.
• Los chequeos de drift resuelven los SecretRefs de gateway.auth.token usando el entorno de ejecución combinado (primero el entorno del comando del servicio, luego el proceso de respaldo del entorno).
• Si la autenticación por token no está activa de forma efectiva (un gateway.auth.mode explícito de password/none/trusted-proxy, o si el modo no está definido y la contraseña tiene prioridad sin candidatos a token), los chequeos de drift del token omiten la resolución del token de configuración.
• Cuando la autenticación por token requiere un token y gateway.auth.token se gestiona mediante SecretRef, install valida que el SecretRef sea resoluble, pero no guarda el token resuelto en los metadatos del entorno del servicio.
• Si la autenticación por token requiere un token y