Curso de Linux / Investigar fallos con journalctl y registros de Linux
Para encontrar la causa de un fallo en los registros, primero defina la hora del fallo y el servicio objetivo, y luego recopile los registros relacionados del mismo arranque/hora para compararlos con los resultados de la reproducción. No confirme la causa solo con una línea de ERROR o el último mensaje; verifique también el contexto anterior y posterior y el estado de otros recursos.
Para el significado básico del estado del servicio, consulte Introducción a systemd. En este artículo, se conectan la hora, el estado y los registros para acotar hipótesis, y en Práctica de reproducción y recuperación de fallos se aplican los mismos procedimientos en un entorno controlado.
El estándar para la práctica de configuración del sistema es Ubuntu 26.04 LTS y VMs de instalación general de la serie Rocky Linux 9. En contenedores, WSL u otras versiones, la configuración de servicios y paquetes puede variar. Preparar primero la recuperación de consola y la verificación de la versión se indica en Crear un entorno de práctica con máquina virtual.
Fijar primero los síntomas, la hora y el historial de cambios
En lugar de “el servidor está raro”, registre algo como “El cliente A recibe un 502 en solicitudes HTTPS desde las 14:03”. Compare las horas y zonas horarias de servidor y cliente, y anote la última operación normal, los despliegues, cambios de configuración y reinicio. Escribir por separado hipótesis sobre la causa y hechos observados ayuda a reducir cambios precipitados influenciados por mensajes de error.
date --iso-8601=seconds
timedatectl
systemctl --failed
journalctl --list-bootsSi un arranque anterior no aparece en la lista, ese registro puede no haberse guardado o ya haberse limpiado. Debe verificar la configuración de almacenamiento volátil y permanente del journal y los límites de retención, y no asumir que no hubo problema solo por la ausencia de registros. Si hay permisos insuficientes, solo algunos elementos podrían ser visibles.
Reducir el journal mediante unidad, arranque y rango de tiempo
Reemplace el siguiente NAME.service con el nombre real del servicio problemático. Primero, consulte el resumen con status y luego lea los registros del mismo arranque, restringiéndolos al rango de tiempo necesario. Es más eficiente guardar un rango reducido para comparar en lugar de volcar todo el registro en un terminal largo.
systemctl status NAME.service --no-pager
journalctl -b -u NAME.service --since "30 minutes ago" --no-pager
journalctl -b -p warning --since "30 minutes ago" --no-pager
journalctl -k -b --since "30 minutes ago" --no-pager-u selecciona una unidad, -b limita el arranque y -k muestra mensajes del kernel. Con -p warning se incluyen las advertencias y todos los niveles de prioridad más graves. Una aplicación puede asignar una prioridad poco útil o escribir por otra vía, por lo que este filtro puede ocultar pistas; compare también el mismo intervalo sin filtrar por prioridad.
Buscar eventos creados por uno mismo con logger
A continuación, registre dos mensajes de práctica con una etiqueta que incluye su identificador de usuario (UID) sin cambiar la configuración del servicio. Se necesita un entorno Linux normal con logger y recopilación de registros conectados. En entornos de contenedores limitados o sin socket syslog, los registros pueden no aparecer, por lo que primero se debe verificar esa diferencia.
tag="linux-course-log-$(id -u)"
logger -t "$tag" "stage=start case=practice"
logger -p user.warning -t "$tag" "stage=check result=sample-warning"
journalctl -t "$tag" --since "5 minutes ago" --no-pagerBusque los dos mensajes y sus horas; añada -p warning a la consulta para comprobar si se excluye el mensaje de prioridad normal. La etiqueta incluye el identificador de usuario y se reutiliza al repetir el ejercicio con la misma cuenta, así que contraste las horas. sample-warning identifica un mensaje de práctica, no un fallo real. Si faltan permisos para leerlo, use únicamente los privilegios de administración autorizados. No borre registros ni reinicie los servicios de recopilación para hacer aparecer el ejemplo.
Comparar con otras pruebas según el mensaje
| Pista | Verificar adicionalmente |
|---|---|
| Permiso denegado | Propiedad, permisos y políticas SELinux o AppArmor aplicables a esa ruta |
| No hay espacio disponible en el dispositivo | df -h y df -i del montaje de destino |
| Dirección ya en uso | Consulta de ss de puertos reales·procesos duplicados |
| Conexión rechazada·tiempo de espera | Dirección de escucha·ruta·cortafuegos·servicios dependientes |
| Reinicio repetido·fallo | Configuración de unidad·estado de terminación·despliegue anterior |
En los registros, “espacio en disco insuficiente” puede no referirse al disco donde se encuentra el archivo de registro, sino a la ruta en la que la aplicación trataba de escribir. “Permiso denegado” también puede referirse no solo al archivo en sí, sino a permisos de exploración del directorio superior o problemas de política. Verifique el objetivo exacto señalado por el error, y no oculte los síntomas con ejecución root o permisos 777.
Verificar archivos de registro y políticas de retención
La aplicación puede registrar en archivos bajo /var/log o en un recolector central aparte además del journal. Verifique la ruta en la configuración real, luego lea las partes necesarias como tail -n 100, grep, etc. También inspeccione archivos rotados y registros antiguos comprimidos, y ajuste el formato de la marca de tiempo y la zona horaria. journalctl --disk-usage muestra el espacio de almacenamiento del journal.
Si ejecuta la limpieza de registros o vacuum durante la investigación, podría perder pistas sobre la causa. Conserve los intervalos necesarios en rutas de acceso restringido y, al compartir, oculte tokens, cookies, información personal y direcciones internas. Después de registrar la causa, los cambios aplicados, las nuevas pruebas bajo las mismas condiciones y la incertidumbre restante, gestione los datos según la política de conservación.
