El journal de systemd es el sistema centralizado de logging que reemplaza la colección fragmentada de archivos en /var/log/ para todo lo que pasa por systemd. Cuando un servicio arranca, falla, o emite cualquier mensaje, ese evento va al journal junto con metadatos estructurados: timestamp con precisión de microsegundos, identificador del servicio, PID, UID, prioridad, y en el caso del kernel, el número de secuencia del boot. Todo esto en un formato binario indexado, no en texto plano.
El diseño binario no es capricho: permite búsquedas por campos estructurados sin parsear texto, compresión nativa de entradas repetitivas, y checksums para detectar corrupción. La contrapartida es que no puedes abrir el journal con vim o grep directamente sobre el archivo; toda interacción pasa por journalctl, que actúa como interfaz de consulta sobre ese almacén de datos.
Usas journalctl cuando necesitas correlacionar eventos entre servicios, acotar un fallo en un rango de tiempo concreto, o filtrar por severidad sin procesar texto manualmente. El equivalente anterior —revisar /var/log/syslog, /var/log/daemon.log, y los logs propios de cada aplicación por separado— requería conocer qué archivo miraba cada servicio, que no siempre es obvio. El journal lo unifica.
Equivocarse aquí suele significar dos cosas: configurar una retención demasiado pequeña y perder contexto justo cuando lo necesitas, o al revés, no configurarla en absoluto y descubrir que el journal ha consumido gigabytes en un servidor con mucha actividad.
# Ver los últimas 50 líneas del journal del boot actual journalctl -b -n 50 # Seguir los logs en tiempo real de nginx (equivalente a tail -f) journalctl -u nginx.service -f # Solo errores y mensajes más graves de las últimas 2 horas journalctl -p err --since "2 hours ago" # Rango de tiempo preciso — útil cuando ya sabes cuándo ocurrió algo journalctl --since "2025-05-01 10:00:00" --until "2025-05-01 10:15:00" # Mensajes del kernel del boot anterior — para diagnosticar arranques fallidos journalctl -k -b -1 # Ver cuánto espacio ocupa el journal en disco journalctl --disk-usage # Configurar retención máxima (editar como root y recargar) # El archivo ya existe; solo hay que descomentar o añadir la línea grep -n SystemMaxUse /etc/systemd/journald.conf || \ echo "SystemMaxUse=500M" >> /etc/systemd/journald.conf # Aplicar el cambio sin reiniciar systemctl kill --kill-who=main --signal=SIGUSR2 systemd-journald
Fíjate en -b sin argumento adicional: delimita la consulta al boot actual. Con -b -1 retrocedes un boot. Esto es posible porque el journal marca cada entrada con un identificador de sesión de arranque, lo que convierte la correlación temporal en algo trivial. Si tienes una máquina que se reinició inesperadamente a las 3 de la mañana, -b -1 combinado con -p err te da exactamente los errores del ciclo de vida anterior sin filtrar manualmente por fecha.
El flag -p err acepta nombres de prioridad syslog (emerg, alert, crit, err, warning, notice, info, debug) o sus equivalentes numéricos del 0 al 7. Cuando especificas una prioridad, journalctl muestra esa prioridad y todas las superiores (más graves). Así, -p warning incluye también err, crit, alert, y emerg. El error más frecuente es esperar que -p warning muestre solo los warnings.
El bloque de configuración usa SIGUSR2 en lugar de systemctl restart systemd-journald por una razón importante: reiniciar el proceso de journald tiene una pequeña ventana donde se pueden perder mensajes. La señal SIGUSR2 le indica al proceso que rote y recargue la configuración en caliente. Eso es lo que hace la línea systemctl kill --kill-who=main --signal=SIGUSR2.
El parámetro SystemMaxUse=500M en /etc/systemd/journald.conf establece el límite absoluto de espacio que puede ocupar el journal persistente. Cuando se alcanza, journald elimina los archivos de journal más antiguos automáticamente. Hay un parámetro complementario, SystemKeepFree=, que reserva espacio libre mínimo en el sistema de archivos; si no lo defines, el valor por defecto es el 15% del volumen, lo que en particiones pequeñas puede ser más restrictivo que SystemMaxUse. En sistemas con alta rotación de logs —un servidor de aplicaciones con logging verbose— lo razonable es definir ambos explícitamente.
El journal por defecto en Debian Bookworm es persistente si existe el directorio /var/log/journal/. Si ese directorio no existe, el journal opera en modo volátil (/run/log/journal/) y se pierde en cada reinicio. Puedes crear el directorio con mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal para activar la persistencia sin cambiar configuración.
N° 69