Header Ads

Kworker

En mayo del 2014 se reportó en launchpad un bug que alertaba que Ubuntu generaba procesos kworker que consumían el 100% de la CPU. Esta falla es muy crucial, teniendo en cuenta que un servidor en producción, con un kernel 3x puede tragarse literalmente los recursos de la máquina, al punto de hacerla colapsar, garantizándole a los administradores IT un puesto VIP en un manicomio o una carta de despido.
Ya no es primera vez que se presentan este tipo de situaciones con Ubuntu (no sabemos si afecta a otras distribuciones), sobre todo relacionadas con interrupciones ACPI. Hace algún tiempo publicamos el post Suspensión en Ubuntu, donde se presentaba un problema con la suspensión-hibernación en la laptops con Ubuntu. En ese entonces las soluciones propuestas solo eran compatible con algunas versiones de Ubuntu y en un hardware determinado.
Este bug aún hoy se sigue presentando en las últimas distribuciones, incluyendo LTS, sin solución; y si ahora le sumamos el problema de la sobrecarga de la CPU, el panorama es complicado. Las causas pueden ser varias (drivers defectuosos, kernel con problemas, etc) y no es objeto de este post adentrarnos en esa área, sino plantear alternativas de solución a esta problemática que muchos llaman "kworker".
(Vea Kworker, ¿qué es y por qué está acaparando tanta CPU?)
Misteriosamente los procesos generados tipo "gpe" en algunos casos se dispara al 100% y consume todos los recursos del sistema, lo cual afecta no solo el buen funcionamiento del equipo sino la suspensión y/o hibernación en laptops con Ubuntu, ya que cuando cerramos la pantalla, los gpe no se deshabilitan, por tanto el sistema no entra en suspensión como debería o nunca regresa de éste estado, cuando intentamos restablecerlo, quedando la pantalla en negro y obligando a un reinicio forzoso. Esta situación causa un deterioro progresivo de la batería de la laptop y del disco duro, entre otros componentes de hardware.
Los servidores (y PC de escritorios) tampoco se escapan de este bug, ya que colapsan por causa de los procesos gpe que consumen los recursos de sistema.
Afortunadamente podemos solucionarlo, identificando los gpe problemáticos y cerrándolos. Para hacerlo corremos un comando grep en el terminal para determinar cuales interrupciones gpe están "enable" y cuánto están consumiendo. Para mostrar todos los gpe lance el siguiente comando:
grep . -r /sys/firmware/acpi/interrupts/
Pero como lo que realmente nos interesa son los que están en "enable" puede reemplazar el comando anterior por:
grep enabled /sys/firmware/acpi/interrupts/*
Una vez aparecerán todos los gpe, buscamos el que consuma más recursos de los normal y procedemos a deshabilitarlo (ver imagen del encabezado del post). Ejemplo:
su -c "echo disable > /sys/firmware/acpi/interrupts/gpe02"
Donde "gpe02" es el gpe que está consumiendo.
Automatizando Kworker
José Linares nos trae un script para automatizar la detección y cierre de los GPE problemáticos.
#!/bin/bash
### BEGIN INIT INFO
# Provides:          Kworker
# Required-Start:    $local_fs $remote_fs $network $syslog $named
# Required-Stop:     $local_fs $remote_fs $network $syslog $named
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts kworker
# Description:       starts kworker using start-stop-daemon
### END INIT INFO

# Author: Jose Linares (jose-linares.com) 
# Modified by: Maravento Studio (maravento.com)

kworker=~/gpelist.txt

# Generates GPE list
echo "Debugging GPE..."
# grep . -r /sys/firmware/acpi/interrupts/ > list
grep enabled /sys/firmware/acpi/interrupts/* > $kworker

# Save in the variable $gpe the full address of the erroneous gpe
num=$(cat $kworker | egrep -o '[0-9]+ ' | sort -r -n | head -n1)
line=$(cat $kworker | egrep -n "/sys/firmware/acpi/interrupts/gpe[A-Z,0-9]+:[ ]*+$num" | cut -d":" -f1)
gpe=$(cat $kworker | head -n $line | tail -n 1 | cut -d":" -f1)

# Send deactivation signal
echo "disable" > $gpe

rm $kworker
echo done

Actualización Jun 28/2016
El Usuario Francisco Tineo nos reporta que, independientemente del sistema GNU/Linux que utilicen, este problema también puede ser causado por hardware defectuoso (en su caso específico de la BIOS en Boards ASRock), lo cual brinda un nuevo panorama sobre este bug.
Con la tecnología de Blogger.