Qué actualizaciones requieren reinicio en Rocky y Alma

Qué actualizaciones requieren un reinicio en Rocky Linux y AlmaLinux

En Rocky Linux y AlmaLinux, dnf update escribe archivos nuevos en el disco y se detiene ahí. El kernel con el que arrancó sigue ejecutándose. Cada proceso que ya abrió una biblioteca continúa usando la copia que abrió, porque Linux mantiene el archivo antiguo en el disco hasta que termina el último proceso que lo mantiene abierto. Por eso, el equipo puede informar de que no hay actualizaciones disponibles aunque siga ejecutando el código que esas actualizaciones reemplazaron. Esto no cambia entre ambas distribuciones, porque las dos reconstruyen las mismas fuentes de Red Hat, y la elección entre Rocky y Alma depende de las garantías de compatibilidad y de la compatibilidad con la CPU, no de nada de lo que verá aquí. Los comandos siguientes también son los mismos que usaba un equipo con CentOS. No es una coincidencia: ambos proyectos se crearon como reemplazos de CentOS después del anuncio de Stream en 2020.

Qué actualizaciones requieren un reinicio y cuáles sólo requieren reiniciar un servicio es una pregunta que debe hacerle al equipo. El comando que responde es needs-restarting. Las actualizaciones se dividen en tres niveles. El kernel y una lista breve de paquetes principales requieren un reinicio completo. Las actualizaciones normales de bibliotecas requieren reiniciar los servicios que las usan. Todo lo demás ya está aplicado en cuanto RPM termina.

Instalar needs-restarting

needs-restarting es un complemento de DNF. El complemento se incluye en dnf-plugins-core, que ya está presente en la mayoría de las instalaciones de Rocky y Alma. El comando /usr/bin/needs-restarting es un envoltorio pequeño incluido en dnf-utils.

sudo dnf install -y yum-utils
needs-restarting --help

Ambas formas ejecutan el mismo código porque el envoltorio llama al subcomando de DNF:

needs-restarting -r
dnf needs-restarting -r

Ambos paquetes proceden de los repositorios propios de la distribución, por lo que no es necesario habilitar EPEL ni el repositorio CRB.

En Rocky Linux 10 y AlmaLinux 10, dnf es DNF 5 y needs-restarting es uno de sus comandos propios, incluido en el paquete dnf5-plugins. En esas versiones, dnf needs-restarting sin opciones muestra directamente si es necesario reiniciar. -r todavía se acepta, pero el manual indica que no tiene ningún efecto y que sólo existe para mantener la compatibilidad con los scripts de DNF 4.

Nivel 1: las actualizaciones que requieren un reinicio

Ejecute primero la comprobación de reinicio. Lee la base de datos RPM y la hora de arranque del sistema, y nada más. Por eso es rápida y no necesita root.

needs-restarting -r

Cuando no ha cambiado nada importante desde el arranque, muestra dos líneas:

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

Cuando ha cambiado algo, muestra Core libraries or services have been updated since boot-up:, después los nombres de los paquetes encontrados y, a continuación:

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943

El código de salida proporciona la misma respuesta: 0 cuando no se necesita reiniciar y 1 cuando sí. Esa es la parte que debe usar en los scripts.

if ! needs-restarting -r >/dev/null; then
  logger -t updates "reboot pending on $(hostname -s)"
fi

El código de salida 1 es una respuesta normal, no un error. Con set -e, un needs-restarting -r sin protección termina el script en esa línea. Por eso el ejemplo anterior lo incluye dentro de if.

Los paquetes que activan la respuesta de reinicio forman una lista corta definida directamente en el plugin. En las versiones actuales contiene kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon y microcode_ctl. Las versiones anteriores del plugin incluyen una lista ligeramente más corta. Compruebe la suya en lugar de dar por hecho que son iguales.

Cada entrada está en esa lista por un motivo que se puede explicar claramente. Un paquete kernel nuevo sólo escribe archivos en /boot y /lib/modules. El kernel en ejecución no puede sustituirse mientras está activo, por lo que no cambia nada hasta el siguiente arranque. Todos los procesos del equipo enlazan glibc. Esto significa que «reiniciar los servicios afectados» también implicaría reiniciar PID 1, y un reinicio del sistema es la forma segura de hacerlo. dbus y dbus-broker gestionan todas las conexiones de cliente del sistema. Detener el bus en un equipo activo interrumpe los clientes que se están comunicando con él. linux-firmware y microcode_ctl se cargan durante el arranque. En una VPS, la parte del microcódigo normalmente no cambia nada que pueda observar, porque el host del hipervisor controla la CPU física.

Puede añadir sus propios paquetes. Cualquier archivo .conf ubicado en /etc/dnf/plugins/needs-restarting.d/ se lee como una lista de nombres de paquetes, uno por línea. Esos nombres se incorporan a la lista de reinicio.

echo 'openssl-libs' | sudo tee /etc/dnf/plugins/needs-restarting.d/openssl.conf

Es una decisión de política, no una corrección. Significa: «cuando cambia la biblioteca TLS, prefiero reiniciar en lugar de localizar todos los servicios que la cargaron».

De qué se deriva realmente el aviso de reinicio

needs-restarting -r no compara la versión del kernel en ejecución con la versión más reciente del kernel instalado. Compara marcas de tiempo. Para cada paquete de esa lista principal, lee la hora de instalación de RPM y la compara con la hora de arranque del sistema. Si un paquete principal se instaló después del último arranque, la respuesta es "reboot required". La hora de arranque se obtiene de UnitsLoadStartTimestamp de systemd mediante D-Bus cuando está disponible. De lo contrario, se obtiene del valor posterior entre la hora de modificación de /proc/1 y el campo btime de /proc/stat.

Este mecanismo tiene una consecuencia que conviene conocer. Si instala un kernel, reinicia y vuelve a arrancar con un kernel anterior porque el valor predeterminado de arranque está fijado, la hora de instalación pasa a ser anterior a la hora de arranque y needs-restarting -r deja de mostrar avisos. Está respondiendo correctamente a su propia pregunta. No está respondiendo a la pregunta que usted hizo. Compruebe el kernel por separado.

uname -r
rpm -q --last kernel
sudo grubby --default-kernel

El primer comando muestra qué kernel está en ejecución. La primera línea de rpm -q --last kernel corresponde al kernel instalado más recientemente. grubby --default-kernel muestra cuál elegirá el cargador de arranque la próxima vez. Si esos tres valores no coinciden, corrija el valor predeterminado de arranque antes de reiniciar una máquina a la que no pueda acceder mediante una consola.

Nivel 2: las actualizaciones que requieren reiniciar un servicio

Cuando RPM reemplaza una biblioteca compartida, desvincula el archivo antiguo y escribe uno nuevo. Un proceso que ya había asignado el archivo antiguo mantiene activo el inode anterior y sigue ejecutando el código antiguo. openssl-libs es el caso más importante: una corrección en libcrypto sólo llega al servidor web después de reiniciar ese servidor web.

sudo needs-restarting -s

Esto muestra los servicios de systemd cuyos propios archivos, o los archivos de sus dependencias, se actualizaron después de que se iniciara el servicio. Use sudo. Sin root, la herramienta sólo puede leer las entradas /proc correspondientes a sus propios procesos, por lo que informa menos procesos de los reales y la lista corta parece una buena noticia.

sudo needs-restarting
sudo needs-restarting --exclude-services

El primero muestra el PID y la línea de comandos de cada proceso afectado. El segundo descarta los procesos que ya están cubiertos por un servicio de systemd, por lo que deja shells de inicio de sesión, sesiones de tmux, trabajos de cron y todo lo que haya iniciado manualmente. Esos procesos nunca se reinician por sí solos.

Si un servicio de la lista también pertenece a un paquete de nivel de reinicio, la herramienta muestra Warning: The following services should not be restarted but require a reboot: encima de él. Tómelo literalmente y reinicie el sistema.

Reinicie el resto uno por uno y compruebe cada servicio antes de pasar al siguiente.

sudo systemctl restart nginx
systemctl status nginx

No canalice la lista a systemctl restart. La causa es su propia sesión SSH. En la familia RHEL, sshd.service se distribuye con KillMode=process, por lo que reiniciarlo envía una señal al daemon que escucha y deja intactos los procesos por conexión; una sesión abierta sobrevive. Confírmelo en su propio equipo con systemctl cat sshd | grep KillMode y, de todos modos, mantenga abierta una segunda sesión la primera vez.

También puede encontrar los mismos procesos sin DNF. Esto resulta útil cuando quiere ver las rutas de los archivos implicados:

sudo dnf install -y lsof
sudo lsof -n +c 0 2>/dev/null | grep -w DEL

DEL identifica un archivo asignado que se eliminó del disco. Lea las rutas antes de actuar. Los archivos temporales eliminados y los archivos respaldados por memoria también aparecen aquí, pero no son motivo para reiniciar nada.

Nivel 3: todo lo demás

La mayoría de las actualizaciones pertenecen a este nivel y no requieren ninguna acción. Un paquete cuyos archivos sólo se leen cuando se inicia un comando, como curl, tar, vim o el propio dnf, queda aplicado por completo cuando RPM termina, porque la siguiente ejecución lee el binario nuevo. Los archivos de configuración, los scripts, la documentación y los paquetes de datos funcionan de la misma manera. needs-restarting no mencionará ninguno de ellos, y ese silencio es la respuesta correcta, no una detección omitida.

La única particularidad de este nivel es la duración de los procesos. Un proceso iniciado antes de la actualización sigue ejecutando su ejecutable antiguo hasta que termina, por trivial que fuera el paquete. Para eso sirve exactamente sudo needs-restarting --exclude-services.

Por qué una máquina con dnf-automatic puede acumular correcciones sin aplicar durante semanas

Aquí es donde los tres niveles dejan de ser una cuestión trivial. Actualizaciones automáticas con dnf-automatic instala paquetes según un temporizador, y el valor predeterminado de reboot en /etc/dnf/automatic.conf es never. Con apply_updates = yes y reboot = never, una máquina puede instalar seis actualizaciones del kernel y una corrección de glibc durante seis semanas y seguir ejecutando el kernel y la biblioteca C con los que arrancó en la semana cero. El registro de actualizaciones parece perfecto. El sistema en ejecución no tiene ninguna de esas actualizaciones.

La solución son tres líneas en /etc/dnf/automatic.conf:

[commands]
upgrade_type = security
apply_updates = yes
reboot = when-needed
reboot_command = "shutdown -r +5 'Rebooting after applying package updates'"

reboot acepta never, when-changed y when-needed. never es el valor predeterminado y deja todas las decisiones en sus manos. when-changed reinicia después de cualquier transacción que haya cambiado un paquete. Es una opción poco selectiva, pero predecible. when-needed pregunta a DNF si la transacción que acaba de aplicar requiere un reinicio, por lo que una noche de actualizaciones que sólo afecta al espacio de usuario termina sin reiniciar. reboot_command es lo que se ejecuta realmente, y el valor predeterminado avisa durante cinco minutos a los usuarios conectados. Configure random_sleep y el horario del temporizador para que esto ocurra dentro de una ventana en la que pueda supervisar el reinicio de la máquina.

Compruebe qué unidad habilitó con systemctl list-timers 'dnf-*'. dnf-automatic incluye varias variantes y no todas se comportan igual, por lo que el archivo de configuración por sí solo no indica qué se ejecuta.

Después de una ejecución programada, consulte la máquina en lugar del registro:

needs-restarting -r; echo "exit: $?"
uname -r
rpm -q --last kernel | head -1

Si no puede programar el reinicio, el parcheo activo del kernel en un VPS es la otra opción. Aplica determinadas correcciones del kernel al kernel en ejecución sin reiniciar. Sólo cubre un subconjunto de problemas del kernel y no afecta a glibc ni a sus servicios, así que considérelo una forma de espaciar los reinicios, no de dejar de hacerlos. Cuando reinicie, hágalo de forma deliberada y mantenga la sesión iniciada hasta que la máquina responda, porque una actualización del kernel es la causa más habitual de que una máquina no vuelva a estar disponible. Lea qué hacer cuando un VPS no arranca después de una actualización del kernel antes de reiniciar un servidor sin acceso a la consola, e incluya la comprobación del reinicio en una lista periódica de mantenimiento del servidor para no acordarse de ella sólo después de un incidente.

El mismo trabajo en Ubuntu y Debian

Una flota mixta necesita los equivalentes. En Ubuntu y Debian, la marca de reinicio es un archivo, no un comando: los scripts de los paquetes crean /run/reboot-required, y /run/reboot-required.pkgs muestra qué paquetes la solicitaron, por lo que [ -f /run/reboot-required ] es el equivalente directo de needs-restarting -r. La documentación antigua usa /var/run/reboot-required, que corresponde al mismo archivo, porque /var/run es un enlace simbólico a /run. La parte del servicio es needrestart, instalado de forma predeterminada en las versiones recientes de Ubuntu Server. Se ejecuta durante apt upgrade y puede ejecutarse por separado con sudo needrestart -r l para mostrar qué necesita reiniciarse sin modificar nada. La carencia de actualizaciones automáticas es la misma allí, y la solución también: actualizaciones desatendidas en Ubuntu toma Unattended-Upgrade::Automatic-Reboot "true"; y Unattended-Upgrade::Automatic-Reboot-Time "02:00"; en /etc/apt/apt.conf.d/50unattended-upgrades.

Modos de fallo y qué verá

• needs-restarting: command not found significa que yum-utils no está instalado. Instálelo o llame a dnf needs-restarting, que funciona en cuanto dnf-plugins-core está disponible.
• Si un script se detiene en la comprobación del reinicio sin mostrar un mensaje de error, está recibiendo el código de salida 1 de set -e. Ese código significa «es necesario reiniciar». Gestione ese resultado en una condición en lugar de dejar que termine el script.
• Si needs-restarting -s no muestra nada justo después de actualizar una biblioteca, normalmente significa que lo ejecutó sin sudo. Sin root, sólo puede ver sus propios procesos.
• Si needs-restarting -r indica que no es necesario reiniciar, pero uname -r muestra una versión antigua, arrancó con un kernel anterior. La comprobación compara la hora de instalación con la hora de arranque, y ambas ya son posteriores al momento relevante. Consulte grubby --default-kernel.
• Si un servicio vuelve a aparecer en la siguiente ejecución, pocos minutos después de reiniciarlo, normalmente otro componente lo está reiniciando o la unidad no ha podido volver a iniciarse. Consulte systemctl status para esa unidad antes de reiniciarla por segunda vez.

FAQ

¿dnf update reinicia servicios en Rocky Linux?

Como regla general, no. La transacción escribe los archivos y termina. Algunos paquetes incluyen un scriptlet de RPM que reinicia su propio servicio durante la actualización, por lo que el comportamiento depende de cada paquete y no es una garantía para todo el sistema. Considere sudo needs-restarting -s como la fuente de verdad: muestra los servicios cuyos archivos, o los archivos de sus dependencias, cambiaron después de que se iniciara el servicio, independientemente de lo que hicieran los scriptlets.

¿Por qué needs-restarting -r indica que no es necesario reiniciar cuando se instala un kernel más reciente?

Porque compara la hora de instalación de RPM de una lista corta de paquetes esenciales con la hora de arranque del sistema. Nunca compara la versión del kernel en ejecución con la versión más reciente instalada. Si instaló un kernel, reinició y volvió a iniciar con un kernel anterior porque el valor predeterminado del cargador de arranque apunta a él, la hora de instalación es anterior a la hora de arranque y la comprobación no detecta nada. Ejecute uname -r, rpm -q --last kernel y sudo grubby --default-kernel para ver la situación real.

¿Qué paquetes activan el aviso de reinicio en Rocky y Alma?

Una lista codificada en el plugin que, en las versiones actuales, contiene kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon y microcode_ctl. Puede ampliarla: coloque un archivo .conf en /etc/dnf/plugins/needs-restarting.d/ con nombres de paquetes, uno por línea, y esos nombres también se tendrán en cuenta para determinar si es necesario reiniciar.

¿Puede dnf-automatic reiniciar el servidor por sí solo?

Sí. Configure reboot = when-needed en la sección [commands] de /etc/dnf/automatic.conf y sólo reiniciará cuando la transacción aplicada lo requiera. when-changed reinicia después de cualquier cambio de paquetes, y never es el valor predeterminado. reboot_command controla el método, y su valor predeterminado avisa durante cinco minutos a los usuarios conectados. Active esta opción sólo en una máquina cuyo arranque pueda recuperar, porque un reinicio desatendido en un VPS sin acceso a la consola puede dejar el sistema inutilizable.

¿needs-restarting detecta los procesos dentro de los contenedores?

No de forma útil. Compara los procesos en ejecución con la base de datos de RPM del host, y los paquetes incluidos en una imagen de contenedor no están en esa base de datos, por lo que una biblioteca obsoleta integrada en una imagen no aparecerá. Vuelva a crear la imagen y vuelva a desplegarla. El host sigue siendo relevante: el runtime de contenedores y el kernel que comparte son paquetes del host, y esos sí aparecen.