Tema: kernel
-
Comprobar si un host Linux necesita reiniciarse o reiniciar servicios tras las actualizaciones
Debian y Ubuntu marcan un reinicio pendiente con el simple archivo /var/run/reboot-required, mientras que los sistemas de la familia RHEL exigen comparar el kernel en ejecución con el más reciente instalado o ejecutar una comprobación al estilo needs-restarting; ninguna de las dos familias lo indica automáticamente en el indicador de comandos.
-
Gestión de los kernels instalados en Debian y Ubuntu: limpieza, espacio en /boot, HWE y Livepatch
Los paquetes de kernel antiguos se acumulan en /boot hasta que apt autoremove los elimina; además, Ubuntu ofrece en sus versiones LTS un kernel HWE (Hardware Enablement) continuo y el servicio Livepatch de Canonical para aplicar correcciones de seguridad del kernel sin reiniciar de inmediato; ambos son exclusivos de Ubuntu y no tienen equivalente en Debian.
-
Kernel panics y datos de fallo en Linux: el journal del arranque anterior, pstore y netconsole
Tras un kernel panic y un reinicio en Linux, `journalctl -b -1 -k` lee los mensajes del kernel del arranque anterior si el journal era persistente; pstore (por ejemplo ramoops, si está configurado) conserva un registro del panic tras el reinicio aunque el journal no lo hiciera; netconsole envía en tiempo real los mensajes del kernel a otra máquina por la red. kdump captura un volcado completo de memoria y se trata en otro artículo.
-
Configuración de kdump para capturar un fallo del kernel en RHEL
kdump reserva memoria de antemano para que, tras un kernel panic, arranque un segundo kernel mínimo que escriba un vmcore para su análisis. Esta metodología cubre la reserva de esa memoria, la activación del servicio y por qué probarlo a propósito tumba el host, por lo que conviene planificar la prueba.
-
Configurar parámetros del kernel de Linux con sysctl: cambios en tiempo de ejecución frente a /etc/sysctl.d
sysctl -w cambia un parámetro del kernel solo hasta el próximo reinicio; para que el cambio sea persistente hay que colocar un archivo en /etc/sysctl.d/ y entender el orden de carga entre /usr/lib, /etc y /run. sysctl --system aplica todos los archivos configurados e indica cuál prevalece en caso de conflicto.
Legible por máquina: JSON