El kernel Linux registra sus mensajes (detección de hardware, errores de drivers, fallos de disco, el OOM killer, avisos de red) en un buffer circular en memoria llamado ring buffer. dmesg lee ese buffer y journalctl -k muestra los mismos mensajes guardados por systemd-journald, incluidos los de arranques anteriores. En este tutorial aprenderás a leer y filtrar los mensajes del kernel en Ubuntu 24.04, a revisar lo que pasó antes de un reinicio y a reconocer los errores más habituales en un servidor.
Requisitos previos
Para seguir esta guía necesitas:
- Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath. Los comandos funcionan igual en Debian 12 y Rocky Linux 9.
- Un usuario no root con privilegios
sudo.
Paso 1: Leer el buffer del kernel con dmesg
En Ubuntu, el parámetro kernel.dmesg_restrict está activado, así que un usuario normal no puede leer el buffer:
dmesg
dmesg: read kernel buffer failed: Operation not permitted
Usa sudo. Como la salida es larga, pásala a less:
sudo dmesg | less
[ 0.000000] Linux version 6.8.0-45-generic (buildd@lcy02-amd64-075) (x86_64-linux-gnu-gcc-13 ...) #45-Ubuntu SMP PREEMPT_DYNAMIC ...
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.8.0-45-generic root=UUID=4f1c2a9e-... ro console=tty1 console=ttyS0
[ 0.412887] PCI: Using configuration type 1 for base memory
El número entre corchetes son los segundos transcurridos desde el arranque. Para verlos como fecha y hora legibles, usa -T:
sudo dmesg -T | tail -n 5
[Thu Sep 25 09:14:02 2026] EXT4-fs (sda1): mounted filesystem 4f1c2a9e-... r/w with ordered data mode.
Notala hora de
dmesg -Tse calcula a partir del tiempo desde el arranque y puede desviarse si el sistema ha estado suspendido o si el reloj se ha ajustado mucho. Para fechas exactas, usajournalctl -k(paso 4).
Otras opciones prácticas:
| Opción | Uso |
|---|---|
-H | Salida legible con colores y paginador |
-w | Sigue los mensajes nuevos en tiempo real, como tail -f |
-x | Muestra la facilidad y el nivel de cada mensaje |
-e | Marca de tiempo relativa legible ([+0.000123]) |
Paso 2: Filtrar por nivel y por facilidad
Cada mensaje tiene un nivel de prioridad, de más a menos grave:
| Nivel | Nombre | Ejemplo |
|---|---|---|
| 0 | emerg | El sistema es inutilizable |
| 1 | alert | Hay que actuar de inmediato |
| 2 | crit | Fallo crítico de hardware |
| 3 | err | Error de E/S, fallo de un driver |
| 4 | warn | Aviso, como un proceso bloqueado |
| 5 | notice | Evento normal pero relevante |
| 6 | info | Información, como la detección de un dispositivo |
| 7 | debug | Depuración |
Para ver solo errores y avisos, que es lo primero que hay que revisar ante un problema:
sudo dmesg -T --level=emerg,alert,crit,err,warn
También puedes filtrar por facilidad. Los mensajes del propio kernel usan kern; algunos procesos de usuario escriben en el buffer con otras facilidades:
sudo dmesg -T --facility=kern --level=err
Y combinar con grep para centrarte en un dispositivo o subsistema:
sudo dmesg -T | grep -iE 'sda|nvme|ext4'
Paso 3: Seguir los mensajes en tiempo real
Mientras reproduces un problema, por ejemplo al conectar un disco o forzar tráfico de red, deja los mensajes nuevos a la vista:
sudo dmesg -Tw
Pulsa Ctrl+C para salir. Para ver solo los errores que vayan llegando:
sudo dmesg -Tw --level=err,warn
Paso 4: Consultar el kernel con journalctl
El ring buffer tiene un tamaño limitado y se pierde al reiniciar. systemd-journald guarda una copia de los mensajes del kernel y, en Ubuntu 24.04, la conserva en disco en /var/log/journal/, así que puedes consultar arranques anteriores.
Los miembros del grupo adm pueden leer el journal sin sudo. El usuario creado al instalar Ubuntu suele pertenecer a él; compruébalo con id.
Mensajes del kernel del arranque actual:
journalctl -k
Solo errores y más graves, con -p (acepta los mismos nombres de nivel):
journalctl -k -p err
Por intervalo de tiempo:
journalctl -k --since "2026-09-25 08:00" --until "2026-09-25 10:00"
journalctl -k --since "1 hour ago"
Revisar un arranque anterior
Esto es lo más útil tras un reinicio inesperado. Lista los arranques guardados:
journalctl --list-boots
IDX BOOT ID FIRST ENTRY LAST ENTRY
-2 5b1d0c3e9a7f4e2b8c61d0f9a2b3c4d5 Mon 2026-09-22 10:02:11 UTC Wed 2026-09-24 23:58:40 UTC
-1 a8e7f6d5c4b3a2918070f6e5d4c3b2a1 Wed 2026-09-24 23:59:30 UTC Thu 2026-09-25 03:12:07 UTC
0 0f1e2d3c4b5a69788796a5b4c3d2e1f0 Thu 2026-09-25 03:13:02 UTC Thu 2026-09-25 09:20:44 UTC
Revisa las últimas líneas del kernel del arranque anterior, justo antes de caer:
journalctl -k -b -1 -n 50
Si lo último que aparece son mensajes normales y luego nada, el servidor probablemente se apagó de golpe (corte de alimentación o reinicio forzado desde fuera). Si hay un Kernel panic, un Out of memory o errores de disco justo antes, ahí tienes la causa.
Paso 5: Reconocer los errores más comunes
Estos son los mensajes que más aparecen en servidores y qué significan.
Falta de memoria (OOM killer)
journalctl -k | grep -iE 'out of memory|oom-kill'
Sep 25 04:11:27 web01 kernel: Out of memory: Killed process 2314 (php-fpm8.3) total-vm:812344kB, anon-rss:602112kB, file-rss:0kB, shmem-rss:0kB, UID:33 pgtables:1480kB oom_score_adj:0
El kernel se quedó sin memoria y mató el proceso indicado para liberarla. La solución es reducir el consumo de la aplicación (menos workers, límites de memoria) o ampliar la RAM; añadir swap solo da margen. Si un servicio de systemd muere de repente, revisa siempre este mensaje.
Errores de disco y de sistema de archivos
journalctl -k -p err | grep -iE 'i/o error|ext4-fs error|xfs|blk_update_request'
Sep 25 05:02:13 db01 kernel: I/O error, dev sda, sector 2048123 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Sep 25 05:02:13 db01 kernel: EXT4-fs error (device sda1): ext4_find_entry:1683: inode #131073: comm mysqld: reading directory lblock 0
Un I/O error indica que el disco no pudo leer o escribir un sector. Si se repite, el disco o el almacenamiento subyacente está fallando: haz copia de seguridad de inmediato. En un VPS, contacta con soporte con la hora y el mensaje exactos. Tras errores de ext4 el sistema de archivos puede pasar a solo lectura (Remounting filesystem read-only) y hay que revisarlo con fsck desde modo de rescate.
Procesos bloqueados
INFO: task jbd2/sda1-8:312 blocked for more than 120 seconds.
Un proceso lleva más de 120 segundos esperando, casi siempre por E/S. Suele acompañar a discos saturados, almacenamiento en red lento o fallos de hardware. Revisa la latencia de disco con iostat -x 1 (paquete sysstat).
Segfaults de aplicaciones
nginx[8421]: segfault at 0 ip 00005581e2a3b1c4 sp 00007ffd4b1e2a80 error 4 in nginx[5581e2a00000+c3000]
La aplicación accedió a memoria no válida y el kernel la terminó. Es un fallo de la aplicación o de una librería, no del kernel. Actualiza el paquete y revisa sus módulos o extensiones.
Red
journalctl -k | grep -iE 'link is (up|down)|nf_conntrack: table full|syn flooding'
| Mensaje | Significado |
|---|---|
Link is Down / Link is Up | La interfaz perdió o recuperó enlace |
nf_conntrack: table full, dropping packet | La tabla de seguimiento de conexiones del firewall está llena y se descartan paquetes |
Possible SYN flooding on port 443. Sending cookies. | Llegan más conexiones nuevas de las que caben en la cola; puede ser un pico de tráfico legítimo o un ataque |
Para nf_conntrack: table full, compara el uso con el límite:
sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
Si el contador está pegado al máximo, sube net.netfilter.nf_conntrack_max en un archivo de /etc/sysctl.d/ y aplícalo con sudo sysctl --system.
Bloqueos de CPU y panics
watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kworker/2:1:1234]
Una CPU no ha podido atender otras tareas durante más de 20 segundos. En máquinas virtuales suele deberse a contención en el host o a una sobrecarga momentánea; si se repite, guarda los mensajes completos para el soporte. Un Kernel panic detiene el sistema; su traza completa aparece en journalctl -k -b -1 si el journal llegó a escribirla.
Paso 6: Vigilar los errores del kernel
No hace falta escribir scripts de monitorización para lo básico. Para revisar rápidamente si ha habido errores del kernel en el último día:
journalctl -k -p err --since yesterday --no-pager
Si no hay nada que mostrar, la salida es -- No entries --. Para una vigilancia continua, envía el journal a tu sistema centralizado de logs o de alertas (por ejemplo, con Promtail, Vector o rsyslog hacia un servidor remoto) y crea alertas sobre priority <= 3 para el identificador kernel.
Solución de problemas
dmesg: read kernel buffer failed: Operation not permitted. Es el comportamiento por defecto de Ubuntu (kernel.dmesg_restrict = 1). Usa sudo dmesg o journalctl -k; no desactives la restricción, porque el buffer del kernel puede revelar direcciones de memoria útiles para un atacante.
journalctl -k -b -1 indica que ese arranque no está disponible. El journal no es persistente. Comprueba que existe /var/log/journal/; si no, créalo con sudo mkdir -p /var/log/journal y reinicia journald con sudo systemctl restart systemd-journald. Solo se guardarán los arranques a partir de ese momento.
Faltan los mensajes del principio del arranque en dmesg. El ring buffer se ha llenado y ha sobrescrito los mensajes más antiguos. Consúltalos con journalctl -k -b, que los guardó al arrancar.
Conclusión
Ahora sabes leer los mensajes del kernel con dmesg, filtrarlos por nivel, seguirlos en tiempo real, revisar arranques anteriores con journalctl -k -b -1 e interpretar los errores más habituales: OOM, disco, procesos bloqueados, red y bloqueos de CPU. Como siguientes pasos, puedes configurar la retención del journal en /etc/systemd/journald.conf, centralizar los logs de varios servidores o ajustar los parámetros del kernel implicados con sysctl.