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 se inició el sistema 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 sale el último proceso que lo tiene abierto. Por eso, el equipo puede informar de que no hay actualizaciones disponibles y seguir 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 se verá aquí. Los comandos siguientes también son los mismos que se usaban en un equipo con CentOS. No es una coincidencia: ambos proyectos se crearon como sustitutos de CentOS tras el anuncio de Stream en 2020.

Para saber qué actualizaciones requieren un reinicio y cuáles sólo requieren reiniciar un servicio, debe consultarlo 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 se aplica 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 yum-utils, que también responde al nombre 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.

Rocky Linux 10 y AlmaLinux 10 siguen usando DNF 4. A fecha de 2026-10-12, ambos repositorios BaseOS contienen dnf 4.20.0 junto con dnf-plugins-core 4.7.0 y yum-utils, y no contienen ningún paquete dnf5. Por tanto, needs-restarting en esas versiones es el mismo complemento dnf-plugins-core que se describe en esta página, y todo lo que sigue es aplicable. Esto incluye -r, que genera la indicación de reinicio y su código de salida, por lo que debe conservarlo en los scripts. Rocky y Alma 9 incluyen la compilación anterior dnf-plugins-core 4.3.0. Las pocas situaciones en las que ambas compilaciones se comportan de forma distinta están marcadas a continuación.

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, pero no consulta 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 en if.

Los paquetes que activan la respuesta de reinicio forman una lista corta y codificada dentro del plugin. En la compilación que incluyen Rocky Linux 10 y AlmaLinux 10, contiene kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon y microcode_ctl. La compilación de Rocky y Alma 9 tiene la misma lista sin kernel-core, lo que es importante por el motivo explicado en la sección siguiente. Compruebe la lista de su sistema en lugar de darla por supuesta.

Cada entrada está en esa lista por un motivo que puede explicarse 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 el cambio no se aplica hasta arrancar el sistema. Casi todos los procesos de espacio de usuario del equipo enlazan con glibc, incluido PID 1. Por tanto, «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 transportan todas las conexiones de cliente del sistema. Detener el bus en un equipo activo interrumpe los clientes que se comunican con él. linux-firmware y microcode_ctl se cargan durante el arranque. En una VPS, la parte relacionada con el microcódigo normalmente no produce ningún cambio observable, porque el hipervisor controla la CPU física.

Puede añadir sus propios paquetes. Cualquier archivo .conf situado bajo /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. Indica que, cuando cambia la biblioteca TLS, prefiere reiniciar el sistema en lugar de localizar todos los servicios que la habían cargado.

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 «se requiere reiniciar». La hora de arranque procede de UnitsLoadStartTimestamp de systemd mediante D-Bus cuando está disponible y, en caso contrario, de la 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 lo que 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.

Rocky y Alma 9 tienen una segunda diferencia. Como la compilación de su plugin supervisa kernel, pero no kernel-core, una transacción que actualiza kernel-core sin el paquete kernel deja instalado un kernel nuevo que todavía no está en ejecución, mientras needs-restarting -r indica que no es necesario reiniciar. Red Hat documenta este comportamiento para Enterprise Linux 9. Un dnf update normal en una máquina que tiene instalado el paquete kernel también actualiza ese paquete, por lo que el aviso sigue apareciendo. Ejecute rpm -q kernel para comprobarlo. Si indica que el paquete no está instalado, el aviso de reinicio no detectará las actualizaciones del kernel en esa máquina y deberá comparar uname -r con rpm -q --last kernel-core.

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 antiguo y sigue ejecutando el código anterior. 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 de sus propios procesos. Por eso informa menos procesos de los reales y la lista corta parece una buena noticia.

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

El primer comando muestra el PID y la línea de comandos de cada proceso afectado. El segundo excluye los procesos que ya están cubiertos por un servicio de systemd. Quedan los shells de inicio de sesión, las sesiones de tmux, los trabajos de cron y todo lo que haya iniciado manualmente. Estos procesos nunca se reinician por sí solos. --exclude-services sólo existe en la compilación de Rocky y Alma 10. En 9 la opción no está disponible. Lea la lista completa de sudo needs-restarting y aparte los procesos que pertenezcan a servicios de la salida de -s.

No reinicie un servicio de la lista que pertenezca a un paquete del nivel de reinicio, como dbus-broker.service. Reinicie el sistema. A fecha de 2026-10-12, las compilaciones que distribuyen Rocky Linux y AlmaLinux todavía muestran ese servicio como cualquier otro. El paquete de CentOS Stream 10 incorporó en julio de 2026 un cambio que elimina esos servicios de la lista y muestra Warning: The following services should not be restarted but require a reboot: en stderr. Cuando su versión incluya ese cambio, tome la advertencia literalmente.

Reinicie los demás servicios de uno en uno. Compruebe cada uno antes de pasar al siguiente.

sudo systemctl restart nginx
systemctl status nginx

No envíe la lista mediante una tubería a systemctl restart. El motivo es su propia sesión SSH. En la familia RHEL, sshd.service se distribuye con KillMode=process. Por tanto, al reiniciarlo se envía una señal al daemon que escucha y se dejan intactos los procesos por conexión. Una sesión abierta sigue funcionando. 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 marca 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í. 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 completamente aplicado 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 se comportan igual. 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 del proceso. Un proceso iniciado antes de la actualización sigue ejecutando su archivo ejecutable antiguo hasta que termina, por trivial que fuera el paquete. Para eso sirve exactamente sudo needs-restarting --exclude-services, o sudo needs-restarting sin opciones en 9.

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 teórica. 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 correcto. 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 modificado 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. Así, una noche de actualizaciones que sólo afecten al espacio de usuario termina sin reiniciar. reboot_command es lo que se ejecuta realmente, y el valor predeterminado avisa a los usuarios conectados con cinco minutos de antelación. Configure random_sleep y el horario del temporizador para que esto ocurra dentro de una ventana en la que pueda supervisar el regreso 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, la aplicación de parches en vivo del kernel en un VPS es la otra opción. Aplica determinadas correcciones del kernel al kernel en ejecución sin reiniciar. Cubre sólo un subconjunto de los problemas del kernel y no hace nada con glibc ni con sus servicios. 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 abierta hasta que la máquina responda, porque una actualización del kernel es el motivo más habitual por el que una máquina no vuelve a estar disponible. Lea qué hacer cuando un VPS no arranca después de una actualización del kernel antes de reiniciar un equipo sin acceso a la consola, e incluya la comprobación del reinicio en una lista de comprobación periódica para el mantenimiento del servidor para no recordarla sólo después de un incidente.

El mismo trabajo en Ubuntu y Debian

Un entorno mixto 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. Para los servicios se usa needrestart, instalado de forma predeterminada en las versiones recientes de Ubuntu Server. Se ejecuta durante apt upgrade y también puede ejecutarse por separado con sudo needrestart -r l para mostrar qué servicios necesitan reiniciarse sin modificar nada. La carencia de actualizaciones automáticas es la misma y la solución también: unattended-upgrades en Ubuntu usa 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 lo que 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.
• Un script que se detiene en la comprobación de reinicio sin mostrar ningún mensaje de error está recibiendo el código de salida 1 de set -e. Ese código significa «se requiere reiniciar». Evalúe ese código en una rama 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 no indica que se requiere reiniciar, mientras uname -r muestra una versión anterior a la del kernel instalado más reciente, normalmente significa que arrancó con un kernel antiguo. La comprobación compara la hora de instalación con la hora de arranque, y ambas ya han quedado atrás. Consulte grubby --default-kernel. En Rocky o Alma 9 existe una segunda causa: la actualización modificó kernel-core sin el paquete kernel, que la compilación de la versión 9 no supervisa. Por tanto, el reinicio sigue pendiente.
• Si needs-restarting --exclude-services falla con un error de argumento no reconocido, significa que está usando la compilación de la versión 9, que no incluye esa opción. Use sudo needs-restarting sin opciones.
• Un servicio que vuelve a aparecer en la siguiente ejecución, pocos minutos después de reiniciarlo, normalmente está siendo reiniciado por otro componente o la unidad no pudo volver a iniciarse. Lea systemctl status para esa unidad antes de reiniciarla otra 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 del paquete y no de una garantía global del sistema. Considere sudo needs-restarting -s como la fuente de autoridad: 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 aunque se haya instalado un kernel más reciente?

Porque compara la hora de instalación de RPM de una lista breve de paquetes principales 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ó el sistema 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 el problema. En Rocky y Alma 9 también omite una actualización de kernel-core realizada sin el paquete kernel, porque kernel-core no está incluido en la lista de la compilación para 9. 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 directamente en el complemento. En Rocky y Alma 10 contiene kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon y microcode_ctl. En 9 es la misma lista sin kernel-core. Puede ampliarla: coloque un archivo .conf en /etc/dnf/plugins/needs-restarting.d/ con los nombres de los 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í. Establezca reboot = when-needed en la sección [commands] de /etc/dnf/automatic.conf. El servidor se reiniciará sólo cuando la transacción aplicada lo requiera. when-changed reinicia después de cualquier cambio de paquete y never es el valor predeterminado. reboot_command controla el método y, de forma predeterminada, avisa durante cinco minutos a los usuarios que hayan iniciado sesión. 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 en un estado de fallo grave.

¿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 tanto, una biblioteca obsoleta integrada en una imagen no aparecerá. Vuelva a compilar la imagen y vuelva a desplegarla. El host sigue siendo relevante: el runtime de contenedores y el kernel que comparte son paquetes del host, por lo que sí aparecen.