Troubleshooting · Linux Foundation Certified IT Associate

Resolución de problemas

Resumen

Esta guía de estudio independiente presenta un método para diagnosticar fallos en Linux sin cambiar cosas al azar. Parte de describir la diferencia entre lo esperado y lo observado, delimitar el alcance y buscar evidencia en registros, servicios y recursos. Después se formula una hipótesis, se prueba con una variable y se documenta. La velocidad llega de la disciplina, no de ejecutar más comandos.

No es material oficial ni está afiliada a la Linux Foundation.

Objetivos de aprendizaje

Aplicar un método reproducible antes de reiniciar o reinstalar.
Interpretar una unidad y sus registros en systemd.
Correlacionar errores con hora, arranque y cambios recientes.
Distinguir presión de CPU, memoria, disco y red.
Verificar hipótesis y registrar el incidente.

Prerrequisitos y conexiones

Necesitas conocer servicios, paquetes y tareas programadas; repasa Administración de sistemas. También ayuda manejar rutas y sockets, tratados en Redes en Linux. Conecta con Mejores prácticas para documentar el incidente y con Recuperación ante desastres.

Método: delimitar antes de tocar

Escribe el síntoma observable: "el sitio devuelve 502 desde las 09:10", no "el servidor está mal". Indica qué se esperaba, qué ocurre, desde cuándo, a quién afecta y si es reproducible. Comprueba el alcance: un usuario, un host, una subred o todos los clientes. Esa delimitación descarta hipótesis antes de invertir tiempo. Si es intermitente, registra frecuencia y condiciones.

Pregunta qué cambió: despliegue, actualización, firewall, certificado, contraseña o DNS. No asumas que el último cambio es la causa, pero es una hipótesis barata. Revisa hora y zona horaria: un desfase entre servidor y registros impide correlacionar. timedatectl muestra la sincronización y date -u da una referencia UTC.

Formula una hipótesis refutable y elige una prueba que la confirme o descarte. Cambia una variable cada vez y anota el resultado. Reiniciar puede restaurar el acceso, pero destruye evidencia: antes captura systemctl status, los registros y los puertos en escucha. Si reinicias, que sea una decisión consciente y registrada.

Bitácora del diagnóstico

Mientras se investiga, anota cada paso en una tabla con cuatro columnas: hora en UTC, hipótesis, prueba ejecutada y resultado observado. El formato obliga a enunciar la hipótesis antes de tocar el sistema y deja escrito qué devolvió cada comando, de modo que un compañero que llegue después no repita pruebas ya hechas ni pierda el rastro de lo descartado.

Hora (UTC)	Hipótesis	Prueba	Resultado
09:14	El servicio no está activo	`systemctl --failed`	Ninguna unidad en estado fallido
09:19	El nombre del cliente no resuelve	`getent hosts tienda.test`	Devuelve la dirección esperada
09:26	El backend contesta mal	`curl --max-time 5 -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/health`	Código 500 con respuesta vacía
09:33	El fallo empezó con el último arranque	`uptime -s`	El equipo lleva activo desde las 06:02, antes del primer aviso

La bitácora también protege contra el sesgo de confirmación: cuando el resultado contradice la hipótesis, la fila escrita obliga a revisar el planteamiento en lugar de repetir la misma prueba con otro comando. Al cerrar el incidente, el documento ya contiene la cronología y las pruebas fallidas, así que alimenta directamente el informe final y la revisión posterior.

Servicios y registros

systemctl status nginx resume estado, PID, arranque y últimas entradas del journal. systemctl --failed lista unidades fallidas. systemctl cat nginx muestra la unidad y sus drop-ins, útil para detectar directivas olvidadas. systemctl list-dependencies nginx revela dependencias que deben estar activas.

systemctl status nginx --no-pager
systemctl --failed
journalctl -u nginx -b --no-pager
journalctl -u nginx --since "2026-10-21 08:00" --no-pager

journalctl -u nginx -b limita a la unidad y al arranque actual; --since acota por tiempo y -p err muestra errores. -x añade explicaciones y -o short-precise conserva precisión. Si el fallo precede al último reinicio, journalctl -b -1 consulta el arranque anterior si hay retención. journalctl --disk-usage indica el espacio ocupado.

Un servicio falla por configuración inválida, permisos, dependencia, puerto ocupado o falta de recursos. Valida con nginx -t o sshd -t antes de reiniciar. En systemctl status, status=203/EXEC sugiere un ejecutable inexistente o no ejecutable; status=1 es genérico y obliga a leer el registro. active (running) no prueba que la aplicación responda: confirma con una petición o con ss.

journalctl en profundidad

El journal reúne mensajes de systemd, de las aplicaciones y del kernel en un único almacén consultable, así que casi todo fallo deja rastro ahí antes que en ficheros sueltos. La disciplina está en acotar: una consulta sin filtros devuelve miles de líneas y enturbia el momento relevante.

Situación	Comando	Qué debe aparecer
Historial de una unidad desde el arranque	`journalctl -u nginx -b --no-pager`	Entradas desde el arranque actual hasta ahora
Comparación con el arranque anterior	`journalctl -b -1 -u nginx --no-pager`	Cómo se comportaba antes del reinicio
Seguimiento en vivo durante una prueba	`journalctl -u nginx -f`	Líneas nuevas conforme se producen
Solo errores de esa unidad	`journalctl -u nginx -p err`	Prioridad `err` o más grave
Búsqueda de un texto concreto	`journalctl -u nginx -g timeout`	Líneas que contienen la palabra buscada
Mensajes del kernel	`journalctl -k --since today`	Arranque, dispositivos, errores de E/S y bloqueos de memoria
Ventana horaria cerrada	`journalctl --since "10:00" --until "10:30"`	Únicamente lo ocurrido entre esas marcas
Arranques conservados	`journalctl --list-boots`	Índice y fecha de cada arranque retenido

La prioridad de -p recorre emerg, alert, crit, err, warning, notice, info y debug; subir el nivel descarta el ruido informativo cuando se busca una causa concreta. -o short-precise añade fracciones de segundo a cada marca, útil cuando hay que ordenar eventos separados por milisegundos entre el proxy y la aplicación.

--list-boots muestra qué arranques siguen disponibles y con qué índice; el anterior aparece como -1 mientras la retención lo conserve. Esa retención depende de journald, con opciones como Storage y SystemMaxUse en /etc/systemd/journald.conf; sin espacio asignado, los arranques antiguos desaparecen y la comparación deja de ser posible. -f actúa como un seguimiento continuo, cómodo durante una reproducción controlada del fallo, y journalctl -u nginx -n 50 devuelve las últimas cincuenta líneas de la unidad sin abrir el fichero con otro programa.

Recursos y rendimiento

top muestra carga media, CPU, memoria y procesos. La carga cuenta procesos ejecutables y bloqueados; compárala con los núcleos y la tendencia, no con un valor aislado. Mucho wa indica espera por E/S; si y so altos en vmstat sugieren paginación y presión de memoria. vmstat 1 5 ofrece cinco muestras, mejor que una instantánea.

top -b -n 1 | head -25
vmstat 1 5
iostat -xz 1
free -h
df -h
df -i

iostat -xz 1 muestra operaciones por segundo, latencia (await), cola (aqu-sz) y utilización por dispositivo. Utilización alta con latencia creciente indica saturación; latencia alta con poca utilización puede apuntar a un disco lento o al backend. No compares discos sin conocer tipo y carga. free -h distingue memoria disponible de caché; df -h muestra espacio y df -i, inodos. Con espacio libre pero inodos agotados no se crean archivos.

Si el disco se llena, localiza el crecimiento antes de borrar: du -xhd1 /var resume el uso sin cruzar sistemas de archivos. Revisa /var/log, el journal y las aplicaciones. journalctl --vacuum-size=500M reduce el journal, pero no corrige la causa; ajusta retención o logrotate. Un archivo eliminado y aún abierto mantiene el espacio ocupado: identifica el proceso antes de reiniciarlo.

Firmas que la aplicación no registra

Ciertas averías solo dejan rastro en fuentes ajenas al proceso: los mensajes del kernel, los límites del sistema operativo y el estado de los recursos. Buscarlas dentro del registro de la aplicación consume tiempo sin premio, porque ese registro nunca las escribe.

Señal	Qué significa	Dónde se confirma
Terminación de un proceso por escasez de memoria	El kernel mató al candidato con mayor consumo	`journalctl -k` y `free -h`
Aviso de sistema de archivos de solo lectura	Una operación de E/S falló y el kernel restringió las escrituras	`dmesg` y el estado del montaje
Error de dispositivo en los mensajes del kernel	El soporte presenta fallos de lectura o escritura	`dmesg` y los contadores de error del equipo
`Too many open files` al iniciar o atender	Se agotaron los descriptores permitidos	`ulimit -n` y el límite declarado en la unidad
`Permission denied` al abrir un socket o un fichero	El proceso no tiene privilegio para ese puerto o esa ruta	Usuario de la unidad y propietario del recurso
Reinicio continuo con contador de reinicios creciente	systemd lanza el servicio porque el proceso termina cada vez	Registro de la unidad, empezando por la línea previa al fallo

Un contador de reinicios en aumento no es la causa sino la consecuencia: la unidad reinicia porque algo obliga al proceso a terminar, y la línea inmediatamente anterior al error suele contenerlo. Conviene leer hacia atrás desde el último reinicio en lugar de fiarse del aviso de systemd.

Las columnas de estado de ps aux añaden dos señales más. D marca procesos detenidos en una operación de entrada o salida que no completa, y los marcados así suelen acompañar a los problemas de almacenamiento de la tabla anterior; Z marca procesos terminados cuyo padre no ha recogido el estado, inofensivos de uno en uno pero molestos cuando se acumulan porque apuntan a un padre que gestiona mal sus hijos.

Red y sockets en el diagnóstico

Con el servicio activo pero clientes que fallan, separa resolución, conectividad y aplicación. ss -tulpn confirma dirección y puerto de escucha; ss -tan state established muestra conexiones y ss -s resume sockets. Si el puerto no aparece, el problema es del servicio; en 127.0.0.1 no acepta clientes remotos; en 0.0.0.0 revisa firewall, rutas y aplicación.

ss -tulpn
ss -tan state established
ss -s
ping -c 3 192.0.2.1
traceroute -n 198.51.100.20

Prueba con el mismo nombre, puerto y protocolo que usa el cliente. Un ping exitoso solo demuestra ICMP; no prueba que TCP/443 acepte conexiones. Probar primero el puerto y luego la resolución evita conclusiones prematuras. Si el cliente usa un nombre, comprueba que resuelve a la dirección esperada; un balanceador o una entrada antigua en /etc/hosts pueden enviar el tráfico a otro host.

La conexión rechazada y la conexión que agota su tiempo no son el mismo síntoma. La primera significa que el paquete llegó a un host sin proceso escuchando en ese puerto; la segunda significa que la respuesta nunca llegó, filtrada o interrumpida en el camino. Connection refused orienta la investigación hacia el servicio y su dirección de escucha, mientras que Connection timed out la desplaza hacia las reglas de filtrado, el enrutamiento y el equipo de red; tratarlos como un error genérico retrasa la reparación.

Resolución, certificado TLS y códigos de estado

Cuando el servicio responde pero el cliente insiste en fallar, separa la resolución de nombres, la negociación TLS y el código que devuelve la aplicación. getent hosts tienda.test consulta el sistema de nombres del host, incluido /etc/hosts, y devuelve la dirección asociada; si aquí resuelve y la aplicación no, su mecanismo de resolución propio o los sufijos de dominio son el siguiente sospechoso. resolvectl status muestra qué servidores de nombres usa el sistema y qué sufijos aplica a las consultas.

El certificado que recibe el cliente se inspecciona sin abrir un navegador:

openssl s_client -connect tienda.test:443 -servername tienda.test </dev/null 2>/dev/null | openssl x509 -noout -enddate

La fecha devuelta pertenece al certificado presentado durante el apreton TLS, que puede no ser el esperado cuando hay varios certificados o un balanceador por delante. Un vencimiento cercano explica avisos que el servidor no registra, porque la comprobación se realiza en el cliente y no escribe en ningún registro del host.

curl --max-time 5 -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/ devuelve únicamente el código de estado, cómodo para comparar respuestas antes y después de cada ajuste. Cada código apunta a un problema distinto: 401 indica que falta autenticación, 403 que la identificación existe pero no tiene permiso, 404 que el recurso no está en esa ruta, y 502 o 504 que el intermediario no obtuvo una respuesta válida del origen. Agruparlos como un error genérico desdibuja el equipo que debe actuar.

Correlación temporal y cierre

Construye una línea de tiempo con la primera señal, los cambios y la recuperación. last muestra inicios de sesión y journalctl --since acota. En Debian y Ubuntu, /var/log/apt/history.log registra instalaciones; con dnf, dnf history lista transacciones. Compara esas horas con el síntoma y los despliegues. Correlación no implica causalidad, pero orienta la siguiente prueba.

Cierra con causa raíz, acción aplicada, verificación y prevención. Si reiniciaste sin identificar la causa, registra la limitación y define una comprobación posterior. Añade una alerta o prueba automatizada si el fallo pudo detectarse antes. El objetivo es recuperar el servicio y reducir el tiempo de diagnóstico futuro.

Cuándo escalar y qué enviar

Hay averías cuya causa depende de terceros: el almacenamiento del proveedor, una ruta externa o un defecto del fabricante. Escalar con evidencia recorta el intercambio de correos y sitúa la conversación sobre datos que ambas partes pueden comprobar.

El expediente de escalado incluye la línea de tiempo con marcas en UTC, el síntoma con los pasos exactos para reproducirlo, las capturas de systemctl status, journalctl, ss y df, la lista de cambios recientes y las pruebas ya descartadas con el resultado de cada una. Añade el impacto medido: clientes afectados, operaciones detenidas o tiempo acumulado de degradación. Registra también a quién se contactó y a qué hora, porque ese intervalo forma parte del plazo de recuperación y sirve para reclamar según el acuerdo de servicio.

Escalar no libera al equipo de su responsabilidad. Mientras el proveedor investiga, conviene mantener la observación del sistema, seguir registrando hallazgos y preparar una alternativa por si el plazo estimado supera lo tolerable. Si esa alternativa llega a activarse, el mismo expediente justifica la decisión y documenta qué se probó antes de recurrir a ella.

Ejemplos prácticos

Un servicio web devuelve 502 y systemd lo muestra activo. ss -tulpn revela que la aplicación escucha en 127.0.0.1:8000, mientras el proxy espera 127.0.0.1:8080. journalctl -u app --since "10 min ago" confirma que arrancó con otra configuración. Corrige el puerto, valida, recarga y prueba en local antes de repetir la prueba externa.

Otro servidor tiene carga alta y respuesta lenta. uptime muestra carga creciente, top revela procesos en estado D y vmstat muestra wa elevado. iostat -xz 1 identifica un dispositivo con latencia y cola altas. El equipo comprueba si el almacenamiento está degradado, mueve la carga y programa una revisión. No reinicia a ciegas: conserva muestras y hora para el proveedor.

Un portal muestra un aviso de certificado inválido justo después de una rotación automática. El proxy está activo y sus registros no reflejan fallos de la negociación. La comprobación con openssl s_client y x509 devuelve una fecha ya vencida, y systemctl cat proxy revela que la ruta del certificado apunta al directorio que no recibe la rotación. Se corrige la ruta, se recarga el servicio y se programa una alerta con antelación al próximo vencimiento.

Una aplicación se reinicia sola cada cierto tiempo sin errores en su propio registro. journalctl -k --since "2 hours ago" muestra que el kernel terminó el proceso con mayor consumo de memoria, y ps aux --sort=-%mem | head confirma que ese proceso ocupaba la mayor parte de la memoria asignada. El equipo ajusta MemoryMax= en la unidad, reinicia en ventana controlada y observa el comportamiento durante el siguiente periodo. El síntoma aparecía en una capa que la aplicación no escribe.

Errores frecuentes

Reiniciar antes de capturar estado y registros, perdiendo evidencia.
Cambiar varias variables e ignorar cuál produjo el efecto.
Leer solo el último error y no la secuencia previa.
Suponer que active (running) equivale a servicio funcional.
Confundir espacio libre con inodos disponibles.
Borrar registros sin corregir la causa del crecimiento.
Comparar registros en zonas horarias distintas.
Tratar Connection refused y Connection timed out como el mismo síntoma.
Confiar en el aviso del navegador sin reproducir la petición con la misma ruta y nombre.
Buscar en la aplicación un mensaje que solo aparece en los mensajes del kernel.

Puntos clave para el examen

Define síntoma, alcance, inicio y cambios antes de actuar.
systemctl status, systemctl --failed y journalctl -u son la primera evidencia.
Sin retención suficiente, journalctl -b -1 no encuentra el arranque anterior; la directiva Storage= de journald.conf decide hasta dónde se puede mirar atrás.
top, vmstat, iostat, free y df describen dimensiones distintas.
ss -tulpn distingue puerto cerrado, escucha local y escucha global.
La prueba debe usar el mismo nombre, puerto y protocolo que el cliente.
journalctl -k consulta el kernel y journalctl --list-boots los arranques retenidos.
La bitácora fija hora, hipótesis, prueba y resultado, y alimenta el informe final.
401, 403 y 404 distinguen credenciales, permisos y recurso inexistente.
Un vencimiento de certificado no aparece en los registros del servidor.
El expediente de escalado lleva cronología, reproducción, capturas, cambios y pruebas descartadas.

Recursos externos

Autoevaluación

¿Cuál es la primera acción ante un servicio que falla y por qué? Respuesta: Capturar systemctl status y los registros antes de reiniciar. El reinicio puede restaurar el servicio, pero borra el estado que explica la causa.
¿Qué muestra journalctl -u nginx -b -1? Respuesta: Los registros de nginx durante el arranque anterior. Sirve para investigar un fallo previo al reinicio si se conservaron los registros.
¿Qué indica una latencia alta con utilización baja en iostat? Respuesta: Puede señalar un dispositivo lento o un backend con problemas, no necesariamente saturación. Correlaciónalo con la carga y el tipo de almacenamiento.
¿Por qué un disco con espacio libre puede impedir crear archivos? Respuesta: Porque los inodos pueden estar agotados. df -i lo comprueba; df -h solo muestra bloques.
¿Qué prueba confirma que un servicio acepta tráfico remoto? Respuesta: Conectar con el mismo nombre, puerto y protocolo del cliente, y ver con ss -tulpn la dirección de escucha. ping no lo demuestra.
¿Qué distingue una conexión rechazada de una que agota su tiempo? Respuesta: La rechazada llega a un host sin proceso escuchando en el puerto; la que agota el tiempo no recibe respuesta porque el filtrado o una ruta interrumpida lo impiden. La primera se investiga en el servicio, la segunda en la red.
¿Qué aporta journalctl -k que journalctl -u nginx no? Respuesta: Los mensajes del kernel —arranque, dispositivos, errores de E/S y terminaciones por memoria— con independencia de cualquier unidad de systemd.
¿Qué comprueba resolvectl status que getent hosts no? Respuesta: Los servidores de nombres que usa el sistema y los sufijos de dominio que aplica; getent devuelve solo la dirección resultante de la consulta.
¿Para qué sirve la bitácora con hora, hipótesis, prueba y resultado? Respuesta: Para no repetir pruebas al cambiar de turno, detectar cuando un resultado contradice la hipótesis y reconstruir el incidente en la revisión sin depender de la memoria.