procesos

  • Este artículo demuestra el uso de la herramienta nohup para lanzar procesos inmunes a las señales de hangup (SIGHUP) en Linux. Esto sirve para mantener procesos en ejecución a pesar de que la terminal que lo controle se cierre (termine su ejecución).

  • Típicamente es necesario identificar un proceso por PID (identificador de proceso) al momento de matarlo o enviar una señal con kill. Sin embargo, es posible matar o enviar señales a procesos por nombre de ejecutable utilizando la herramienta killall.

  • Cada vez que necesitamos monitorear el consumo de recursos de un sistema (como por ejemplo CPU, memoria, etc.) en tiempo real, recurrimos al clásico top, o su versión más colorida y amigable: htop.


    Salida de la herramienta top


    Salida de la herramienta htop

    En general estos funcionan muy bien para un uso básico, como monitorear el consumo de CPU o memoria. Aunque existe una alternativa más avanzada que provee una salida mucho más informativa: atop.

  • Cuando se requiere monitorear el uso de CPU en un sistema operativo de la familia Unix, típicamente se utilizan herramientas como top, atop o htop. Sin embargo, estas herramientas trabajan en modo interactivo. Si se necesita obtener una lista de procesos que más CPU consumen en un instante dado, ya sea para guardar en un archivo, enviar por mail, reenviar a otro comando o utilizar desde otra aplicación, se puede recurrir al modo batch de top.

  • Los sistemas Linux actuales tienen ciertos procesos que ejecutan código del kernel Linux, pero son manejados como procesos del espacio usuario en lo que respecta a planificación (scheduling). Sin embargo no respetan las reglas típicas de manejo de memoria ya que corren código del kernel.

    Estos procesos son creados por kthreadd, el cual es una especie de init para procesos del kernel. Es posible reconocerlos porque usualmente la herramienta ps los lista con un nombre entre corchetes:

    root@debian9:~# ps -ef | grep '\[' | head -n 10
    root         1     0  0  2018 ?        00:01:38 init [2]
    root         2     0  0  2018 ?        00:00:23 [kthreadd]
    root         3     2  0  2018 ?        00:00:00 [rcu_gp]
    root         7     2  0  2018 ?        00:00:00 [mm_percpu_wq]
    root         8     2  0  2018 ?        00:00:13 [ksoftirqd/0]
    root         9     2  0  2018 ?        00:41:15 [rcu_sched]
    root        10     2  0  2018 ?        00:00:00 [rcu_bh]
    root        11     2  0  2018 ?        00:00:00 [migration/0]
    root        12     2  0  2018 ?        00:00:24 [watchdog/0]
    root        13     2  0  2018 ?        00:00:00 [cpuhp/0]
    

    Los hilos del kernel no son hijos de init ya que pueden ser iniciados antes de que arranque el espacio usuario (userland, PID 1 en adelante). Estos procesos típicamente se encargan de manejar hardware, por eso son gestionados directamente por el kernel y tienen alta prioridad.

    Este artículo demuestra cómo ocultar estos procesos en la salida de ps.

  • Haciendo pruebas en un servidor Ubuntu Server 12.04.04 LTS me encontré con un proceso desconocido llamado "whoopsie". Nunca antes había visto ese proceso en otros sistemas GNU/Linux, por lo que me llamó poderosamente la atención, e inmediatamente me surgieron dos preguntas: ¿Qué es el proceso whoopsie? y ¿Cómo hago para desactivarlo/eliminarlo/desinstalarlo?. Es sabido que muchos administradores de sistemas tenemos la manía de tendencia a desinstalar, eliminar y desactivar todo software/proceso que no sea absolutamente necesario.

  • Si observan cuidadosamente la salida de vmstat o top, hay una columna llamada "st" (o %st en top) que indica la cantidad de "stolen time", esto supuestamente es la cantidad de tiempo de CPU que el hypervisor le "robó" a los procesadores virtuales (si es que tenían algo para ejecutar, no cuenta si estaban "idle") ejecutando cualquier otra cosa en lugar de código perteneciente al guest virtual.

    En otras palabras, es la cantidad de tiempo que los procesadores virtuales tuvieron código para ejecutar pero no se les asignó un CPU físico, debido a la planificación o sobrecarga en el host. El % de CPU que no estuvo disponible para la VM debido a la sobrecarga de la virtualización.

  • En el último artículo expliqué cómo mantener procesos en ejecución en segundo plano utilizando la herramienta nohup. Veamos ahora cómo lograr el mismo efecto empleando disown, y al mismo tiempo comprender el uso de los comandos bg, fg y jobs en Bash