Ubuntu 24.04: Requiere reinicio… pero no puedes reiniciar — formas inteligentes de planificar el mantenimiento

octubre 30, 2025 • febrero 3, 2026 • Lectura: 24 min • Views: 6

¿Te fue útil?

Aplicaste un parche por un CVE. Ejecutaste las actualizaciones. Ahora Ubuntu te informa educadamente que se requiere reinicio, como si te pidiera regar una planta de interior.
Mientras tanto estás frente a una máquina de producción que genera ingresos, gestiona identidades o actúa como cabecera de almacenamiento.

Aquí es donde muchos equipos cometen una de dos malas decisiones: reiniciar impulsivamente y provocar una interrupción, o posponerlo indefinidamente y llamarlo “aceptación del riesgo”.
La respuesta correcta suele ser ninguna de las dos. Es aplazamiento controlado con un plan, un radio de impacto estrecho y decisiones basadas en evidencia.

Qué significa realmente “reboot required” en Ubuntu 24.04

En Ubuntu, “reboot required” no es una condición única. Es un conjunto de señales que a menudo se colapsan en una sola insignia roja en un panel.
Tu tarea es volver a dividirlo en categorías y decidir qué es realmente un bloqueador y qué es manejable.

“Reboot required” normalmente significa una de estas cosas

Kernel actualizado: Se instaló un paquete de kernel nuevo pero estás ejecutando el kernel antiguo. Las correcciones de seguridad pueden no estar activas hasta el reinicio.
glibc o cargador central actualizado: glibc, el cargador dinámico u otras bibliotecas fundamentales se actualizaron. Los procesos de larga duración mantienen los mapeos antiguos.
Firmware/microcode actualizado: Las actualizaciones de microcode de Intel/AMD pueden requerir reinicio para cargarse en el arranque temprano.
Bibliotecas del sistema actualizadas: Algunos servicios necesitan reiniciarse; el reinicio es el instrumento contundente que lo garantiza.
Actualizaciones de stack de filesystem/almacenamiento: Módulos de ZFS, multipath, quirks NVMe o cambios de drivers pueden requerir reinicio para cargar nuevos módulos limpiamente.

Ubuntu 24.04 (Noble) es lo bastante moderno como para que el enfoque de “simplemente reinicia todo” sea a la vez más posible y más peligroso.
Más posible, porque systemd y needrestart pueden identificar procesos afectados. Más peligroso, porque las cargas son más estado-dependientes,
más distribuidas y más acopladas que cuando “ventana de mantenimiento” significaba “domingo a las 2 AM, a nadie le importa”.

Si no puedes reiniciar ahora, tu objetivo es responder tres preguntas con evidencia:

¿Qué cambió? Kernel, libc, OpenSSL, systemd, drivers de almacenamiento—sé específico.
¿Qué está actualmente vulnerable o inconsistente? Versión del kernel en ejecución, módulos cargados, demonios de larga vida.
¿Cuál es tu acción interina más segura? Reiniciar servicios selectos, drenar nodos, hacer failover o aplicar live patches.

Si esto parece trabajo, lo es. Ese es el trabajo. La alta disponibilidad no es gratis; es una suscripción que pagas con planificación y disciplina.

Hechos y contexto histórico que cambian cómo planificas reinicios

Unos pocos hechos pequeños valen la pena recordarlos porque cambian la decisión por defecto de “reiniciar cuando sea” a “reiniciar deliberadamente”.
No son trivia; son las razones por las que tu parque se comporta como lo hace.

El directorio /var/run ahora es /run (un tmpfs) en Linux moderno. Reinicios e incluso algunos reinicios de servicio efectivamente “olvidan” estado de runtime.
unattended-upgrades de Ubuntu existe desde hace años y es bueno instalando actualizaciones de seguridad, pero no hace que los procesos en ejecución recarguen mágicamente nuevas bibliotecas.
El live patching del kernel se volvió mainstream en la década de 2010 a medida que las flotas crecieron; reduce riesgo para algunos CVE pero no para todos los cambios.
El auge de systemd cambió el comportamiento de reinicio: los grafos de dependencias y la activación por sockets pueden ocultar o revelar tiempo de inactividad según la configuración de los servicios.
“Reboot required” suele ser una comprobación de archivo: en Ubuntu, /var/run/reboot-required (o /run/reboot-required) es creado por paquetes. Es una pista, no un oráculo.
Las actualizaciones de glibc son infames porque los procesos de larga duración pueden mantener versiones antiguas en memoria; puedes “parchear” el disco y seguir ejecutando código antiguo durante semanas.
Las actualizaciones de microcode se normalizaron tras vulnerabilidades de CPU de alto impacto; ya no son exóticas y deben formar parte del diseño rutinario de mantenimiento.
La contenedorización no eliminó los reinicios: tus contenedores siguen dependiendo del kernel del host. Puedes redeployar pods todo el día y aun así ejecutar un kernel antiguo.
ZFS on Linux (OpenZFS) maduró dramáticamente en la última década, pero el acoplamiento módulo-kernel sigue haciendo que los cambios de kernel merezcan especial cuidado en hosts de almacenamiento.

Guía de diagnóstico rápido: encuentra el verdadero bloqueo en minutos

Cuando suena la alarma: “El servidor muestra reboot required; ¿podemos posponerlo?” no empiezas con un debate filosófico.
Empiezas con triage. La meta es identificar el cuello de botella y la categoría de riesgo rápidamente.

Primero: confirma qué disparó la marca reboot-required

¿Es kernel, microcode o solo reinicios de servicios?
¿Es el host parte de un par HA o es un singleton?
¿Existe un exploit conocido en el entorno real para el componente actualizado?

Segundo: determina si puedes reiniciar servicios en lugar de reiniciar todo

Reinicia los demonios afectados en orden de dependencias.
Valida health checks, latencia y presupuestos de error.
Confirma que ninguna carga con estado se verá interrumpida (bases de datos, controladores de almacenamiento).

Tercero: planifica la ruta de reinicio con el menor radio de impacto

Drena/evacúa tráfico, haz failover, cordona nodos o mueve VIPs.
Confirma que tienes acceso a consola (fuera de banda).
Define rollback: kernel anterior en GRUB, snapshot o imagen conocida buena.

No intentas ser ingenioso. Intentas ser predecible.

Tareas prácticas: comandos, salidas y la decisión que tomas

A continuación hay tareas probadas en campo para Ubuntu 24.04. Cada una incluye (1) un comando, (2) qué significa su salida y (3) la decisión que tomas.
Ejecútalas en secuencia; están diseñadas para estrechar progresivamente el problema.

Task 1: Check whether Ubuntu thinks a reboot is required

cr0x@server:~$ ls -l /run/reboot-required /run/reboot-required.pkgs
-rw-r--r-- 1 root root  0 Dec 30 10:12 /run/reboot-required
-rw-r--r-- 1 root root 73 Dec 30 10:12 /run/reboot-required.pkgs

Significado: La presencia de /run/reboot-required es una pista instalada por paquetes de que algo necesita reinicio.
El archivo .pkgs lista los paquetes que lo desencadenaron.

Decisión: No reinicies todavía. Lee primero la lista de paquetes para clasificar el riesgo.

Task 2: Read which packages requested the reboot

cr0x@server:~$ cat /run/reboot-required.pkgs
linux-image-6.8.0-55-generic
linux-modules-6.8.0-55-generic
intel-microcode

Significado: Este es un conjunto real que desencadena reinicio: kernel nuevo + módulos + microcode.
Reiniciar servicios no cargará el kernel nuevo. El microcode normalmente se aplica en el arranque también.

Decisión: Trátalo como “se requiere reinicio para la corrección completa”. Si debes aplazarlo, documenta la ventana de exposición y considera live patching.

Task 3: Confirm the running kernel vs installed kernels

cr0x@server:~$ uname -r
6.8.0-49-generic

cr0x@server:~$ dpkg -l 'linux-image-*generic' | awk '/^ii/{print $2,$3}'
linux-image-6.8.0-49-generic 6.8.0-49.49
linux-image-6.8.0-55-generic 6.8.0-55.57

Significado: Estás ejecutando 6.8.0-49 pero 6.8.0-55 está instalado.

Decisión: Se requiere reinicio (o kexec, raramente) para ejecutar el kernel parcheado. Planifícalo; no lo ignores.

Task 4: Check uptime and reboot history (detect “forever defer” patterns)

cr0x@server:~$ uptime -p
up 97 days, 4 hours, 18 minutes

cr0x@server:~$ last reboot | head -3
reboot   system boot  6.8.0-49-gene Tue Sep 24 06:11   still running
reboot   system boot  6.8.0-41-gene Mon Aug 12 02:03 - 06:10 (42+04:07)
reboot   system boot  6.8.0-31-gene Sun Jun 30 01:58 - 02:02  (00:04)

Significado: Uptime largos no son automáticamente buenos. A menudo significan que cargas riesgo latente y deriva de configuración.

Decisión: Si ves meses de uptime en sistemas con muchos parches, programa reinicios controlados y hazlos rutinarios, no una crisis.

Task 5: Identify services that should be restarted because of upgraded libraries (needrestart)

cr0x@server:~$ sudo needrestart -r l
NEEDRESTART-VER: 3.6
Services to be restarted:
  ssh.service
  systemd-journald.service
  cron.service
No containers need to be restarted.

Significado: Estos demonios están usando bibliotecas o binarios desactualizados y deberían reiniciarse para recoger las actualizaciones.
También te indica si los contenedores están implicados.

Decisión: Si un reinicio es imposible hoy, reinicia estos servicios durante un período tranquilo y vuelve a comprobar. Esto reduce la exposición sin mentirte sobre el kernel.

Task 6: Verify whether a critical process is still mapped to deleted libraries

cr0x@server:~$ sudo lsof | awk '/DEL/{print $1,$2,$9}' | head
systemd 1 /usr/lib/x86_64-linux-gnu/libssl.so.3 (deleted)
nginx 2154 /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (deleted)
php-fpm8 3011 /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (deleted)

Significado: Procesos siguen usando versiones antiguas de bibliotecas que fueron reemplazadas en disco.
Esta es una situación clásica de “parchado pero corriendo código viejo”.

Decisión: Reinicia los servicios afectados (o el host) según criticidad y redundancia. Si es systemd o plumbing central, prefiere una ventana de reinicio.

Task 7: Confirm microcode package status (why the reboot flag won’t clear)

cr0x@server:~$ dpkg -l intel-microcode amd64-microcode | awk '/^ii/{print $2,$3}'
intel-microcode 3.20241112.0ubuntu0.24.04.1

Significado: Microcode está instalado; típicamente se aplicará en el arranque. La marca de reinicio es esperable.

Decisión: Si operas entornos regulados, las actualizaciones de microcode pueden considerarse relevantes para seguridad; agenda el reinicio como evento de cumplimiento.

Task 8: Inspect what unattended-upgrades did (change control without the drama)

cr0x@server:~$ sudo tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log
2025-12-30 09:58:12,219 INFO Installing linux-image-6.8.0-55-generic:amd64 (6.8.0-55.57) ...
2025-12-30 10:02:41,887 INFO Installing linux-modules-6.8.0-55-generic:amd64 (6.8.0-55.57) ...
2025-12-30 10:06:09,014 INFO Installing intel-microcode:amd64 (3.20241112.0ubuntu0.24.04.1) ...
2025-12-30 10:06:10,120 INFO Packages that were upgraded: linux-image-6.8.0-55-generic linux-modules-6.8.0-55-generic intel-microcode

Significado: El sistema hizo lo que pediste: instaló actualizaciones. No reinició porque esa es una decisión de política.

Decisión: Usa este log como tu registro de cambio. No adivines qué cambió cuando redactes el ticket de mantenimiento.

Task 9: Check for pending initramfs or bootloader changes

cr0x@server:~$ sudo grep -E "update-initramfs|update-grub" -n /var/log/dpkg.log | tail -n 5
184392:2025-12-30 10:03:12 status half-configured linux-image-6.8.0-55-generic:amd64 6.8.0-55.57
184411:2025-12-30 10:03:28 status installed linux-image-6.8.0-55-generic:amd64 6.8.0-55.57
184412:2025-12-30 10:03:28 trigproc initramfs-tools:amd64 0.142ubuntu25.3 <none>
184413:2025-12-30 10:03:28 status half-configured initramfs-tools:amd64 0.142ubuntu25.3
184420:2025-12-30 10:03:42 status installed initramfs-tools:amd64 0.142ubuntu25.3

Significado: Los triggers de initramfs se ejecutaron; tus artefactos de arranque se actualizaron.
Si este host arranca desde un almacenamiento inusual o tiene hooks de initramfs personalizados, aquí es donde surgen sorpresas.

Decisión: Para stacks de arranque complejos (LUKS, ZFS root, multipath), prueba el procedimiento de reinicio en un nodo hermano primero.

Task 10: Check ZFS/OpenZFS status if this is a storage host

cr0x@server:~$ sudo zpool status
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Upgrade the pool to enable all features.
  scan: scrub repaired 0B in 01:12:33 with 0 errors on Sun Dec 29 03:10:01 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          sda3      ONLINE       0     0     0
          sdb3      ONLINE       0     0     0

errors: No known data errors

Significado: El pool está sano. El mensaje “Some supported features are not enabled on the pool” se refiere a flags de características del pool, no a salud inmediata.

Decisión: Si debes reiniciar una cabecera de almacenamiento, hazlo solo cuando el pool esté limpio y no haya resilver/scrub en curso en una fase riesgosa.

Task 11: Confirm whether ZFS modules match the running kernel

cr0x@server:~$ dkms status | grep -E '^zfs'
zfs/2.2.2, 6.8.0-49-generic, x86_64: installed
zfs/2.2.2, 6.8.0-55-generic, x86_64: installed

Significado: DKMS compiló ZFS para ambos kernels, que es lo que quieres antes de reiniciar.
Si la entrada del kernel nuevo falta o muestra “build error”, tu reinicio se convierte en un incidente de almacenamiento.

Decisión: Si DKMS no compiló para el kernel nuevo, arregla eso antes de reiniciar. De lo contrario arriesgas arrancar en un kernel sin tu módulo de almacenamiento.

Task 12: Validate systemd failed units before you touch anything

cr0x@server:~$ systemctl --failed
  UNIT                    LOAD   ACTIVE SUB    DESCRIPTION
● multipathd.service       loaded failed failed Device-Mapper Multipath Device Controller

1 loaded units listed.

Significado: Ya tienes una unidad crítica fallida. Reiniciar podría “arreglarla” o podría dejar inservible tu ruta de arranque, dependiendo de cuál sea.

Decisión: Resuelve unidades fallidas que afecten almacenamiento/red antes de programar un reinicio. Si dependes de multipath, trátalo como una señal de stop.

Task 13: Check whether critical services are restartable without downtime

cr0x@server:~$ systemctl show nginx --property=CanReload,CanRestart,ActiveState,SubState
CanReload=yes
CanRestart=yes
ActiveState=active
SubState=running

Significado: systemd cree que nginx puede recargarse y reiniciarse. Recargar suele ser menos riesgoso que reiniciar, pero solo si la configuración es válida.

Decisión: Prefiere reload cuando sea posible, valida la configuración primero y solo reinicia cuando necesites recoger cambios de binario/biblioteca.

Task 14: Validate configuration before restarting (avoid self-inflicted outage)

cr0x@server:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Significado: La configuración es sintácticamente válida; recargar/reiniciar es menos probable que falle.

Decisión: Si la validación de configuración falla, arréglala primero. Un “reinicio de mantenimiento” que se convierte en interrupción es como perder fines de semana.

Task 15: Check journald and kernel logs for boot-related warnings before scheduling reboot

cr0x@server:~$ sudo journalctl -p warning -b | tail -n 10
Dec 30 07:11:02 server kernel: nvme nvme0: missing or invalid SUBNQN field.
Dec 30 07:11:03 server systemd[1]: Failed to start Device-Mapper Multipath Device Controller.
Dec 30 07:11:05 server kernel: xhci_hcd 0000:00:14.0: BIOS handoff failed (BIOS bug?)

Significado: Tienes advertencias que podrían importar durante el reinicio (quirks NVMe, multipath).
Estas son las pistas de que el reinicio no es “solo un reinicio”.

Decisión: Si existen advertencias de arranque/almacenamiento, haz un reinicio controlado con acceso a consola y un plan de rollback. No reinicies en remoto sin precauciones.

Task 16: Confirm what will boot by default (GRUB) and ensure fallback is available

cr0x@server:~$ grep -E '^GRUB_DEFAULT=|^GRUB_TIMEOUT=' /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5

Significado: La entrada por defecto arrancará el primer ítem del menú; el timeout es corto. Está bien hasta que necesites selección manual.

Decisión: Si has tenido regresiones de kernel antes, considera timeout más largo en sistemas críticos, o asegura que la consola fuera de banda pueda interactuar con GRUB.

Aplazamiento inteligente: cómo estar seguro mientras no puedes reiniciar

A veces realmente no puedes reiniciar: fin de trimestre, congelación de migración en vivo, demo a clientes, migración de base de datos, o simplemente sin redundancia.
“No reiniciar” no debe significar “ignorar”. Debe significar: reduce la exposición, prepara el reinicio y prográmalo.

Sabe qué estás aplazando

Si la lista de paquetes en reboot-required contiene un kernel, estás aplazando correcciones de seguridad del kernel. Eso es una exposición real.
Si contiene solo bibliotecas de espacio de usuario, a menudo puedes reducir el riesgo reiniciando servicios específicos.

El live patching puede ayudar para ciertos CVE del kernel. Pero no es un pase libre. Es un cinturón de seguridad, no una jaula antivuelco.

Primera broma (y solo porque todos lo hemos hecho): Un aplazamiento de reinicio “temporal” es como una regla temporal de firewall—eventualmente se vuelve parte de la arquitectura.

Estrategia de reinicio de servicios (la versión sobria)

Un plan de reinicio dirigido es legítimo cuando:

Tienes redundancia o balanceo de carga, de modo que reiniciar un nodo no corta tráfico.
Los componentes actualizados son bibliotecas de usuario o demonios, no el kernel.
Puedes validar la salud después de cada reinicio con chequeos reales (no intuiciones).

Un plan de reinicio dirigido es peligroso cuando:

El host es un punto único de falla (SPOF).
Están involucrados stacks de almacenamiento y red (multipath, iSCSI, módulos ZFS).
No tienes un backout probado o no puedes acceder a la consola.

Enmarcar el riesgo que funciona en entornos maduros

No le digas a los stakeholders “no podemos reiniciar.” Diles:

Qué está parcheado en disco vs qué está en memoria (kernel y procesos afectados).
Cuál es el riesgo conocido (clase de componente, explotabilidad, exposición).
Qué mitigación estás aplicando ahora (reinicios de servicios, reglas WAF, restricciones de acceso).
Cuándo se hará el reinicio (ventana, dependencias, plan de fallback).

Esa es honestidad operativa. Y es cómo evitas el postmortem de “pensamos que estaba bien”.

Diseñar ventanas de mantenimiento que no hagan tanto daño

La solución real para “no puedo reiniciar” es dejar de construir sistemas que no puedan reiniciarse.
No porque reiniciar sea divertido—no lo es—sino porque la seguridad y la fiabilidad requieren que puedas ciclar la máquina.

Haz los reinicios aburridos con redundancia

Si estás ejecutando un solo nodo de producción porque “es más barato”, ya estás pagando.
Pagas en riesgo, en parches demorados, en heroísmos frágiles y en la clase de ansiedad on-call que acorta carreras.

Tier web: al menos dos nodos detrás de un balanceador de carga, con health checks que realmente fallen cuando la app está rota.
Bases de datos: replicación con failover probado, o servicios gestionados si no puedes disponer del personal.
Almacenamiento: controladores duales o almacenamiento en clúster; si no es posible, sé honesto en que los reinicios de cabecera de almacenamiento son interrupciones.
Identidad/plano de control: trátalo como infraestructura crítica; la redundancia no es opcional.

Diseña el flujo de trabajo de reinicio, no solo la ventana

Las ventanas de mantenimiento fallan cuando se consideran un espacio de tiempo en lugar de un procedimiento.
Un buen procedimiento de reinicio incluye:

Pre-checks (salud del pool, lag de replicación, espacio en disco, unidades fallidas).
Drenado de tráfico (cordon, mover VIP, deshabilitar en LB o failover manual).
Ejecución del reinicio con acceso a consola.
Post-checks (salud de servicios, verificación de versión, logs, chequeo de regresión de rendimiento).
Rollback documentado (kernel previo, snapshot o plan de reversión).

Actualizaciones de kernel: trátalas como rutina, no emergencias

El reinicio de kernel más difícil es el primero después de haber aplazado durante meses.
No solo aplicas un cambio; saltas sobre un montón de cambios, esperando que ninguno toque las peculiaridades de tu hardware.

El mejor patrón es la cadencia: reiniciar mensualmente (o más a menudo si tu modelo de amenaza lo requiere) y mantenerlo consistente.
La cadencia lo vuelve aburrido. Ser aburrido es la meta.

Segunda broma (la última, lo prometo): Lo único más caro que un reinicio planificado es un reinicio no planificado con audiencia.

Una cita de fiabilidad que deberías interiorizar

La idea parafraseada de Gene Kim de la cultura DevOps encaja aquí: haz cambios pequeños y frecuentes para que las fallas sean más pequeñas y más fáciles de recuperar.
Eso no es solo para despliegues; también aplica para reinicios de kernel.

Tres mini-historias del mundo corporativo (anonimizadas)

Mini-historia 1: Un incidente causado por una suposición equivocada

Una compañía SaaS mediana ejecutaba flotas Ubuntu con actualizaciones automáticas de seguridad. Recientemente migraron a una nueva pila de monitorización
que marcaba /run/reboot-required como una “alerta crítica.” Buena idea. Mala implementación.

Un ingeniero vio un clúster de alertas “reboot required” y asumió que eran mayormente paquetes de espacio de usuario.
Decidió “limpiar la alerta” reiniciando los servicios listados por needrestart, lo cual parecía seguro.
Los servicios se reiniciaron limpiamente, la alerta permaneció y se encogieron de hombros.

La suposición equivocada fue sutil: creyeron que la alerta significaba “los servicios están obsoletos” y que reiniciar algunos demonios lo resolvería.
Pero la lista de paquetes incluía una actualización de kernel y microcode. El kernel en ejecución tenía meses de atraso.
Su modelo de amenaza incluía cargas expuestas a Internet. Esa brecha importaba.

Dos semanas después, un ejercicio de respuesta a incidentes descubrió que los hosts de producción no estaban ejecutando el kernel parcheado a pesar de estar “actualizados”.
No hubo brecha, pero se convirtió en un problema de cumplimiento: “instalado” no significaba “efectivo”.
La solución no fue técnica—fue de proceso. Actualizaron la alerta para incluir la lista de paquetes y la delta de versión del kernel, y añadieron un SLA para la finalización del reinicio.

Mini-historia 2: Una optimización que salió mal

Una empresa financiera odiaba los reinicios porque sus jobs por lotes duraban mucho. Alguien propuso un plan “ingenioso”:
reiniciar agresivamente solo los servicios afectados después del parcheo, y reiniciar solo una vez por trimestre. Lo automatizaron.

Durante un tiempo, pareció funcionar. Menos tiempo de inactividad, menos tickets de mantenimiento, stakeholders felices. Hasta que falló.
Parchearon OpenSSL y reiniciaron “todos los servicios” con un script que iteraba unidades systemd.
El script no entendía dependencias y reinició la capa reverse-proxy antes que la capa de aplicación.

Resultado: interrupciones breves pero repetidas—picos de HTTP 502 que no activaban una página completa porque el balanceador aún veía nodos sanos.
Los clientes vieron fallos intermitentes. Soporte recibió tickets. Los SREs obtuvieron gráficos con picos en forma de peine.

El postmortem fue incómodo porque nada “se cayó.” La optimización creó un nuevo modo de fallo: reinicios inconsistente en la pila.
Reemplazaron el script por un flujo controlado de drain-and-restart por rol (proxy/app/worker), y acortaron la cadencia de reinicio del kernel.
La idea de “reinicio trimestral” murió en silencio, como debía.

Mini-historia 3: Una práctica aburrida pero correcta que salvó el día

Una compañía con cargas pesadas de almacenamiento (ZFS en Ubuntu) tenía una regla estricta: no reiniciar sin tres luces verdes:
zpool status limpio, módulos DKMS compilados para el kernel objetivo y acceso a consola probado.
Sonaba lento. Lo era.

Un mes, unattended-upgrades instaló un kernel nuevo durante la noche. Se programó una ventana de reinicio para la noche siguiente.
Los pre-checks mostraron que DKMS había fallado al compilar ZFS para el kernel nuevo debido a un paquete de headers faltante (un glitch del mirror del repositorio).

Si hubieran reiniciado según lo programado sin mirar, habrían arrancado en un kernel sin módulo ZFS.
En una cabecera de almacenamiento, eso no es “degradado.” Eso es “tu pool no se importó y ahora todos aprenden palabras nuevas.”

En cambio arreglaron el paquete, recompilaron DKMS, verificaron la presencia del módulo y luego reiniciaron.
Nadie fuera del equipo de infraestructura notó nada. Ese es el punto de la práctica aburrida y correcta: no pasa nada, y te vas a casa.

Errores comunes: síntoma → causa raíz → solución

Estos son patrones que aparecen en flotas reales. No son teóricos.

1) Síntoma: “Reboot required” no desaparece después de reiniciar servicios

Causa raíz: La marca de reinicio fue disparada por una actualización de kernel o microcode; reiniciar servicios no puede cargar un kernel nuevo.

Solución: Confirma con cat /run/reboot-required.pkgs y uname -r. Programa un reinicio, o aplica live patching mientras lo planificas.

2) Síntoma: El reinicio borra la marca, pero los servicios se comportan de forma extraña después

Causa raíz: Deriva de configuración y reinicios no probados. El sistema ha estado tanto tiempo en ejecución que el reinicio activa suposiciones de arranque antiguas (nombres de red, mounts, dependencias).

Solución: Haz que los reinicios sean frecuentes y rutinarios. Añade chequeos de validación post-reinicio y corrige el orden de las unidades de arranque, mounts y configuración de red.

3) Síntoma: Tras el reinicio, el almacenamiento falta o el pool no se importa

Causa raíz: Mismatch de módulo-kernel (DKMS de ZFS no compilado), o servicios multipath/iSCSI fallando al inicio.

Solución: Pre-check del estado DKMS para el kernel objetivo; verifica que systemctl --failed esté limpio; asegúrate de que initramfs contenga los módulos necesarios si aplica.

4) Síntoma: Reiniciar servicios causa 502s breves o timeouts

Causa raíz: Orden de reinicio y desconocimiento de dependencias; health checks del balancer demasiado permisivos; capacidad insuficiente.

Solución: Drena el nodo primero; reinicia en orden por rol; ajusta health checks para reflejar la verdadera readiness; mantiene capacidad N+1.

5) Síntoma: El equipo de seguridad dice “parchado”, SRE dice “aún vulnerable”

Causa raíz: Confusión entre “paquete instalado” y “código en ejecución.” Procesos de larga duración y kernels antiguos persisten.

Solución: Reporta versiones instaladas y en ejecución. Usa needrestart y deltas de versión del kernel como evidencia de cumplimiento.

6) Síntoma: El reinicio provoca tiempo de inactividad prolongado porque el host no vuelve

Causa raíz: No hay consola fuera de banda, configuración del bootloader rota o acceso solo remoto con una pila de red que depende de que el reinicio funcione.

Solución: Verifica siempre el acceso a consola antes del mantenimiento. Asegura kernels de fallback. No programes reinicios riesgosos sin manos en el volante.

Listas de verificación / plan paso a paso

Checklist A: Cuando ves “reboot required” y no puedes reiniciar hoy

Lee /run/reboot-required.pkgs y clasifica: kernel/microcode vs espacio de usuario.
Registra el kernel en ejecución (uname -r) y el kernel objetivo instalado (lista dpkg).
Ejecuta needrestart -r l; reinicia servicios de bajo riesgo si procede.
Comprueba mapeos de bibliotecas borradas (lsof | ... DEL); reinicia los demonios afectados en orden controlado.
Aplica mitigaciones si aplazas correcciones de kernel: restringe exposición de red, limita tasas, reglas WAF, reduce rutas de acceso administrativas.
Crea un ticket de reinicio con: motivo, lista de paquetes, riesgo, ventana propuesta, rollback y pasos de validación.

Checklist B: Chequeos de seguridad pre-reinicio (15 minutos que ahorran horas)

Confirma que el acceso a consola funciona (IPMI/iDRAC/console de la VM).
systemctl --failed debe estar vacío para unidades críticas de almacenamiento/red.
Hosts de almacenamiento: zpool status debe estar limpio; no debe haber resilver/scrub en una fase arriesgada.
Módulos DKMS compilados para el kernel nuevo (dkms status incluye el kernel objetivo).
Sanidad de espacio en disco: asegura que /boot no esté lleno; asegura que operaciones de paquetes no estén a medio configurar.
Confirma la ruta de rollback: el kernel previo sigue instalado; GRUB puede seleccionarlo.

Checklist C: Ejecución del reinicio con radio de impacto mínimo

Drena tráfico o haz failover (deshabilitar en LB, mover VIP, cordon del nodo, etc.).
Detén o quiesce cargas con estado si es necesario (bases de datos, exports de almacenamiento).
Reinicia usando systemd y observa la consola.
Verifica la versión del kernel tras el arranque, luego verifica servicios críticos y después restaura el tráfico.

Checklist D: Validación post-reinicio (no te quedes en “hace ping”)

Confirma que el kernel en ejecución es el esperado.
Confirma que los servicios críticos están activos y saludables.
Revisa logs por nuevas advertencias/errores desde el arranque.
Verifica mounts/pools de almacenamiento y rutas de red.
Ejecuta una transacción sintética (login, llamada API, lectura/escritura) por la ruta real.
Cierra el ciclo: borra la alerta, documenta la finalización y programa la siguiente cadencia.

Preguntas frecuentes

1) ¿“reboot required” siempre se refiere al kernel?

No. A menudo es kernel o microcode, pero también puede ser provocado por otros paquetes.
Comprueba /run/reboot-required.pkgs para ver qué lo solicitó realmente.

2) Si reinicio todos los servicios, ¿estoy seguro sin reiniciar todo?

Puedes reducir el riesgo para actualizaciones de espacio de usuario, pero no recogerás los arreglos del kernel sin reiniciar (o sin un mecanismo de live patch para CVE específicos).
Trata los “reinicios de servicios” como mitigación, no como resolución.

3) ¿Qué es lo más seguro cuando no puedo reiniciar un servidor crítico?

Sé honesto: es un SPOF, así que cualquier cambio significativo es arriesgado. Minimiza la exposición (restricciones de red, endurecimiento de accesos),
programa una ventana de mantenimiento y prioriza construir redundancia para que la próxima vez puedas reiniciar sin drama.

4) ¿Puedo simplemente borrar /run/reboot-required para quitar la alerta?

Puedes hacerlo, y borrará la alerta basada en archivo. No cambiará la realidad.
Es como quitar la pila del detector de humo porque la cocina está ruidosa.

5) ¿Cómo sé qué procesos aún usan bibliotecas antiguas?

Usa needrestart para una lista curada y lsof para detectar mapeos de bibliotecas borradas.
La decisión es entonces: reiniciar servicios individualmente ahora, o programar un reinicio si el alcance es demasiado amplio.

6) ¿Qué diferencia tiene Ubuntu 24.04 en este contexto?

Los fundamentos son los mismos, pero Ubuntu 24.04 tiende a desplegarse con kernels modernos, comportamiento de systemd,
contenedores y módulos basados en DKMS (como ZFS) que hacen que los cambios de kernel sean más relevantes operacionalmente.

7) ¿Con qué frecuencia deberíamos reiniciar servidores de producción?

Lo suficiente para que sea rutinario. Mensualmente es una base común para muchos entornos; entornos de mayor riesgo van más rápido.
La clave es consistencia: una cadencia predecible vence a reinicios esporádicos y de pánico.

8) Ejecutamos Kubernetes. ¿Reiniciar un nodo es solo “cordon y drain”?

En su mayor parte sí, pero los detalles importan: PodDisruptionBudgets, statefulsets, almacenamiento local, daemonsets y agentes de red pueden complicar los drains.
El concepto se mantiene: evacua cargas, reinicia, valida, des-cordon.

9) ¿Qué pasa si el kernel nuevo causa una regresión?

Por eso mantienes al menos un kernel conocido bueno instalado y aseguras que puedes seleccionarlo vía consola.
Prueba primero en un nodo canario. Las regresiones de kernel son raras, pero “raro” no es “nunca”.

10) ¿Los servidores de almacenamiento necesitan manejo especial para reinicios?

Sí. Cualquier cosa con ZFS, multipath, iSCSI o hooks de initramfs personalizados merece pre-checks (salud del pool, compilación de módulos, unidades fallidas)
y un reinicio cuidadoso observado por consola.

Conclusión: siguientes pasos que realmente reducen el riesgo

“Reboot required” no es Ubuntu molestándote. Es Ubuntu diciéndote la verdad: algunos arreglos no tienen efecto hasta que el sistema en ejecución cambia.
Tu trabajo es decidir cuándo y cómo, no si la realidad se aplica a ti.

Haz esto a continuación:

En cada host marcado, registra: /run/reboot-required.pkgs, uname -r y needrestart -r l.
Si es kernel/microcode: programa un reinicio con un plan de rollback y acceso a consola. Si es espacio de usuario: reinicia servicios impactados de forma segura.
Construye una cadencia: reinicios mensuales, canario primero y luego desplegar por la flota. Hazlo aburrido.
Elimina sistemas “no reiniciables” por diseño: redundancia, failover y procedimientos que conviertan reinicios en operaciones de rutina.

No ganas fiabilidad por no reiniciar nunca. Ganas fiabilidad siendo capaz de reiniciar cuando lo necesites—y demostrando que lo haces regularmente.