Solución de problemas

Esta guía organiza el diagnóstico por síntomas. Principio general: recopila primero evidencias mediante consultas de solo lectura y realiza cambios después. En cada paso, registra lo observado, los comandos y códigos de salida, y las diferencias entre el resultado esperado y el real.

Dispositivo inaccesible por SSH

Diagnostica cada capa por separado:

1. Contrasta la dirección con el inventario del dispositivo; direcciones similares no son intercambiables;
2. Comprueba sucesivamente la resolución de direcciones, el enrutamiento, la conectividad del puerto SSH y el método de autenticación;
3. Si un dispositivo antes accesible se desconecta de repente, correlaciona el fallo con las últimas actualizaciones o reinicios. Si es necesario, solicita una comprobación local del puerto serie o del estado físico.

Fallo de arranque o reinicios repetidos

1. Recopila la salida de arranque, los registros del arranque anterior mediante journalctl -b -1, la causa de reinicio del watchdog y los errores del sistema de archivos;
2. Identifica la etapa: cargador de arranque, kernel, conmutación del sistema, inicio de servicios, reinicio del watchdog o activación por una aplicación;
3. Consulta bootcount: los fallos consecutivos activan la recuperación automática y, al alcanzar el umbral, el modo de recuperación y la reversión de particiones; véase Sistema dual A/B y conmutación;
4. Consulta el estado de recuperación con jelina-info y jelina-auto-recovery --state.

No cambies particiones ni reviertas manualmente antes de identificar la causa, para no interferir con la recuperación automática.

Sistema en estado degraded

systemctl is-system-running
systemctl --failed --no-pager

Revisa los servicios fallidos uno por uno y después los servicios principales. El fallo de un servicio opcional específico de una plataforma no implica necesariamente un fallo del sistema; también es normal que un servicio de ejecución única quede inactivo después de completarse.

Actualización aparentemente detenida

1. Consulta el estado y el progreso con jelina-info --get ota_status --json y jelina-local-ota -s;
2. Comprueba si hay actualizaciones pendientes de confirmación: esperar confirmación es un estado previsto por la política, no un bloqueo;
3. Revisa el servicio y los registros del agente;
4. Comprueba el espacio en disco y el estado y los procesos del instalador;
5. Comprueba el acceso al paquete, el reloj del sistema, la resolución de nombres y los certificados;
6. Determina si la instalación ya ha terminado y solo espera un reinicio o un nuevo montaje para activarse.

Durante el diagnóstico, no vuelvas a enviar o confirmar la actualización ni borres indicadores de reinicio pendiente.

Aplicación o contenedor no disponible

Comprueba por separado el estado deseado, la descarga de imágenes, la creación del contenedor, el estado del proceso, los puertos, el cortafuegos y la aplicación. Comandos habituales:

docker ps                # Estado de contenedores
docker logs <nombre-del-contenedor>      # Registros de contenedores

No recrees manualmente contenedores o servicios administrados por el sistema antes de conservar las evidencias.

Disco lleno o raíz de solo lectura

1. Compara el espacio y el uso de inodos de las particiones raíz y de datos con df -hT y df -i;
2. Comprueba si se ha activado la raíz temporal con jelina-enter-tmpfs-root --status; véase Almacenamiento y partición de datos;
3. Distingue entre el diseño normal de la partición del sistema de solo lectura, un fallo en la partición de datos y una capa superpuesta mal montada.

No borres directorios del sistema o de paquetes que no conozcas. No realices operaciones de negocio desde la raíz temporal.

Error de registro o desconexión de la nube

1. Consulta el registro con jelina-manual-register --check; véase Registro y conexión de dispositivos;
2. Comprueba si está activado el modo sin conexión;
3. Revisa el reloj, la resolución de nombres, las rutas, los certificados y el acceso a los puntos de conexión de la nube;
4. Revisa el estado y los errores de los servicios de registro y del agente;
5. Identifica la categoría: activación inicial incompleta, credenciales caducadas o inválidas, fallo de red o rechazo de la nube.

Servicio que no arranca

Comprueba en orden las condiciones de inicio, la existencia y permisos del ejecutable, el intérprete del script y la disponibilidad de los montajes necesarios.

Problemas de hora o resolución de nombres

• Los errores de hora suelen manifestarse como fallos de certificados o autenticación en la nube: compara la hora del sistema, el reloj de hardware y los registros de sincronización;
• Ante errores de resolución, revisa el servicio y la configuración de red. No sobrescribas manualmente los archivos de resolución generados por el sistema.

Interfaz gráfica no disponible

Una terminal SSH normalmente no dispone del entorno de una sesión de escritorio. Una variable de pantalla vacía no indica por sí sola un fallo gráfico:

1. Comprueba el ajuste global de la interfaz y el alcance de su desactivación;
2. Consulta instancias y sesiones mediante jelina-ui-ctl list y jelina-ui-ctl sessions;
3. Comprueba la sesión gráfica activa y consulta el estado y los registros de la interfaz en el entorno del usuario correspondiente.

Evidencias históricas de reinicios

Algunos dispositivos conservan archivos históricos de rendimiento y registros persistentes para investigar el estado previo al reinicio:

journalctl --list-boots              # Lista de arranques
journalctl -b -1 -p warning..alert   # Advertencias del arranque anterior
ls -1t /var/log/atop | head          # Archivos históricos de rendimiento

Para atribuir un reinicio inesperado, correlaciona la lista de arranques, los registros anteriores, la causa del watchdog, el tiempo de actividad y el historial de actualizaciones y cambios de partición.

Documentación relacionada

• Preguntas frecuentes — respuestas a consultas habituales
• Sistema dual A/B y conmutación — contador de arranques y reversión
• Watchdog — supervisión del sistema
• Estado e información del sistema — comandos de consulta