Resolución de problemas
Síntoma, causa, solución
| Síntoma | Causa | Solución |
|---|---|---|
Connection refused en SSH | Usó el puerto 22, o la instancia todavía no está en running | Copie el comando desde la pestaña Conectar; espere la insignia running |
Connection refused en un servicio que usted inició | El puerto nunca se publicó en el lanzamiento | Reenvíelo por SSH, o declárelo en la plantilla y vuelva a desplegar |
Permission denied (publickey) | No se adjuntó ninguna clave al desplegar, o su cliente ofreció otra clave | Vuelva a desplegar con una clave adjunta; o apunte a la clave correcta con -i y IdentitiesOnly=yes |
REMOTE HOST IDENTIFICATION HAS CHANGED | Un host y puerto reciclados ahora pertenecen a una instancia nueva | ssh-keygen -R "[host]:port", luego conéctese de nuevo |
La instancia se queda en creating | Todavía se está descargando una imagen grande | Observe la pestaña Logs; si termina en error, destruya y vuelva a desplegar |
La instancia está en error | La carga de trabajo no logró arrancar, falló o se perdió mientras se ejecutaba, o terminó por su cuenta. Qué salió mal, en la página de la instancia, indica cuál, igual que el error_code de la API; vea Por qué falló una instancia | Lea los logs, destrúyala y despliegue de nuevo: no se puede iniciar ni detener |
JupyterLab devuelve 403 Forbidden | La solicitud no llevaba token, o llevaba uno obsoleto | Vuelva a la consola y use Abrir JupyterLab otra vez |
La interfaz web o la API de una plantilla responde 401 | El puerto exige el token de acceso de la instancia, y la solicitud no llevaba ni el token ni la cookie que establece el botón Abrir | Ábrala con el botón Abrir, o envíe Authorization: Bearer <token de acceso> desde los scripts. Consulte El token de acceso de la instancia |
| El navegador advierte que el certificado no es de confianza | JupyterLab sirve HTTPS con un certificado autofirmado | Es esperable; continúe pese a la advertencia |
No space left on device | El disco que eligió al desplegar está lleno | Libere espacio, o vuelva a desplegar en un disco mayor: los discos no se pueden redimensionar |
| La instancia se detuvo sola | El saldo de la organización llegó a $0. Esa detención también liberó sus GPU, donde la máquina lo permite | Agregue créditos hasta que el saldo cubra una hora de lo que la organización tiene en marcha y luego iníciela de nuevo |
La instancia volvió a running después de una detención | El host no confirmó la detención en 30 minutos; el contenedor sigue activo y facturando. La página de la instancia muestra La última acción no se completó, y el error_code de la API indica stop_timed_out | Nada: la detención se reintenta sola. Destruya la instancia si no la necesita |
Inicio rechazado con HOST_UNREACHABLE, START_REFUSED o START_UNAVAILABLE | El host no pudo aceptar el inicio; la instancia sigue stopped | Iníciela de nuevo más tarde. Si START_REFUSED sigue apareciendo, destruya la instancia y vuelva a desplegar |
Inicio rechazado con CAPACITY_UNAVAILABLE | Las GPU de la instancia se liberaron —el saldo llegó a $0, o una disputa de pago congeló los pagos— y otro cliente está usando una de ellas ahora. La página de la instancia muestra GPU liberadas | Iníciela de nuevo más tarde. Si no puede esperar, copie sus datos y destrúyala |
Una instancia detenida pasó a error con workload_gone | Su contenedor desapareció de la máquina mientras estaba detenida | Ya no se le factura nada. Destrúyala y vuelva a desplegar; si no lo hace, se destruye automáticamente alrededor de una hora después |
| La instancia desapareció por completo | El saldo permaneció en $0 o por debajo durante 24 horas y llegó a −$5, y las instancias detenidas se destruyeron | El disco ya no existe; agregue créditos y despliegue de nuevo |
409 INVALID_STATE desde la API | La instancia está a mitad de una transición | Espere a que termine el estado de transición y reintente |
402 INSUFFICIENT_BALANCE al desplegar o iniciar | El saldo no cubre una hora del consumo de la organización con esta instancia en marcha: su GPU y su disco más lo que cuestan las demás. Estar por encima de cero no basta. El error incluye balance_micro y required_micro | Un admin agrega créditos; los miembros no pueden |
Connection refused
Dos problemas distintos llevan el mismo mensaje.
Si se trata de SSH en sí, casi con seguridad está en el puerto equivocado. El sshd de la instancia se publica en un puerto del host asignado en el lanzamiento, nunca el 22, y el número puede cambiar después de detener e iniciar. Copie el comando de nuevo desde la pestaña Conectar.
Si se trata de un servicio que usted inició dentro de la instancia, el puerto no está publicado. Los puertos quedan fijos cuando la instancia se lanza, así que iniciar un servidor después no expone nada. Reenvíelo a través de la sesión SSH que ya tiene:
ssh -N -L 8000:localhost:8000 -p 40123 root@203.0.113.14
Confirme también que el proceso está enlazado a 0.0.0.0 y no a 127.0.0.1, salvo que el puerto esté detrás del proxy de acceso, donde la aplicación debe estar en 127.0.0.1. Consulte Puertos y el botón Abrir.
Permission denied (publickey)
La autenticación por contraseña está desactivada, así que esto siempre significa que la clave que ofreció su cliente no es la que está en authorized_keys.
ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes -p 40123 root@203.0.113.14
Si aun así falla, lo más probable es que la instancia no tenga ninguna clave: el selector de clave SSH en la página Desplegar quedó en Sin clave. No hay forma de adjuntar una clave a una instancia en ejecución. Agregue la clave en Claves SSH y luego despliegue de nuevo. Consulte Agregar una clave.
Atascada en creating
creating normalmente termina en bastante menos de un minuto. Lo que lo alarga es la descarga de la imagen: una imagen de varios gigabytes en un host que nunca la ha visto tarda lo que tarda. La pestaña Logs muestra la línea de la descarga y luego image ready, creating container.
Si la carga de trabajo nunca levanta, la instancia pasa a error por sí sola. No se quedará en creating para siempre.
Una instancia en error
error significa que el contenedor no logró arrancar. Los logs son el único lugar donde vive la razón, así que léalos antes de limpiar:
- Una imagen o etiqueta que no existe, o una imagen privada cuyas credenciales de registro son incorrectas.
- Una plantilla fijada a una imagen que no corresponde al modo de lanzamiento. Los modos
sshyjupyternecesitan una imagen construida a partir de la imagen base de Superheat. - Una carga de trabajo que nunca quedó lista dentro de la ventana de arranque de la plataforma.
Un onstart que falla no es una de las causas. La imagen base lo ejecuta en un subshell, escribe la falla en /var/log/superheat/onstart.log y deja el contenedor levantado para que usted pueda conectarse y arreglarlo.
Desde error la única acción disponible es Destruir. Corrija la plantilla y despliegue de nuevo. Consulte Leer los logs.
JupyterLab devuelve 403
El servidor de notebooks acepta una sola credencial, un token generado por la plataforma al desplegar. Un 403 significa que el navegador envió el token equivocado o ninguno, lo que suele indicar que la pestaña vino de un marcador o de una dirección copiada y no de la consola.
Vuelva a la instancia en la consola y presione Abrir JupyterLab. Ese botón lleva el token que la plataforma generó para la instancia; una dirección armada a mano no. Consulte Abrir JupyterLab.
Sin espacio en disco
df -h /
du -sh /workspace/* | sort -h | tail
Los culpables habituales son los checkpoints acumulados y las cachés de paquetes:
rm -rf ~/.cache/pip ~/.cache/huggingface
El disco no se puede agrandar. Si el trabajo realmente necesita más espacio, copie lo que tiene fuera de la instancia, destrúyala y despliegue de nuevo con un disk_gb mayor. Consulte Disco y almacenamiento.
La instancia se detuvo sola
Las instancias en ejecución se detienen automáticamente cuando el saldo de la organización llega a $0. No se pierde nada: el disco se conserva y puede volver a iniciar la instancia en cuanto el saldo cubra una hora de ella, GPU más disco, además de una hora de todo lo demás que la organización tenga en marcha. Los cargos de almacenamiento siguen corriendo contra el saldo vacío mientras permanece detenida, así que sigue bajando.
Esa detención también libera las GPU de la instancia de vuelta a la máquina, donde la máquina lo permite, y un saldo cero hace lo mismo con las instancias que usted había detenido. Un inicio posterior tiene que recuperar las mismas GPU: si otro cliente está usando una de ellas, se rechaza con 409 CAPACITY_UNAVAILABLE y la instancia sigue detenida con su disco. Vea Detener vs. destruir.
Si el saldo permanece en $0 o por debajo durante 24 horas y llega a −$5, las instancias detenidas se destruyen y sus discos se van con ellas. Revise el saldo y el registro de movimientos en la página de facturación, y consulte Detención y destrucción automáticas.
Por debajo de $0 sus datos siguen ahí: al menos durante 24 horas, y hasta que el saldo llegue a −$5. Una vez cumplidas ambas cosas, las instancias detenidas se destruyen, y no hay recuperación posible.