Procesos y señales en Linux

Un proceso es un programa en ejecución. Conviene distinguir entre el programa, que es un archivo estático almacenado en el disco, y el proceso, que es lo que ocurre cuando ese programa se pone en marcha y el sistema operativo lo carga en memoria y le da vida. Cada vez que se lanza un comando o se abre una aplicación, el sistema crea uno o varios procesos, les asigna memoria, tiempo de procesador y otros recursos, y los gestiona mientras funcionan. Un mismo programa puede dar lugar a varios procesos simultáneos, como ocurre por ejemplo con un navegador que ejecuta cada pestaña en un proceso separado. El PID, que significa identificador de proceso, es el número único que el sistema asigna a cada proceso en el momento de crearlo, y que sirve para referirse a él de forma inequívoca durante toda su vida. Este número es fundamental para la gestión de procesos, porque es la forma en que se identifica a qué proceso concreto se quiere consultar, controlar o terminar. Cuando se quiere, por ejemplo, cerrar un programa que no responde, el procedimiento habitual consiste precisamente en averiguar el PID de su proceso, mediante herramientas como ps o top, y luego usar ese número para enviarle una señal con el comando kill. Además del PID, cada proceso tiene asociado el identificador de su proceso padre, lo que refleja que los procesos se organizan en una jerarquía en forma de árbol.

ps y top son las dos herramientas clásicas para observar los procesos del sistema, y su diferencia fundamental está en que ps ofrece una foto instantánea y estática, mientras que top ofrece una vista dinámica y en tiempo real. El comando ps muestra la lista de procesos tal como estaban en el instante exacto en que se ejecutó, y luego devuelve el control, de modo que su salida es como una fotografía congelada del estado del sistema en ese momento; es ideal cuando se quiere capturar la situación, filtrarla o procesarla, por ejemplo combinándolo con otras herramientas para buscar un proceso concreto. El comando top, en cambio, abre una vista que se actualiza continuamente cada pocos segundos y que normalmente ordena los procesos por su consumo de recursos, mostrando en la parte superior los que más procesador o memoria están utilizando; esto lo convierte en la herramienta ideal para diagnosticar situaciones en vivo, como cuando el equipo va lento y se quiere saber qué proceso está acaparando los recursos en ese preciso momento. Existe además una versión mejorada de top llamada htop, que presenta la misma información en tiempo real pero con una interfaz más visual, colorida y cómoda, que permite desplazarse, buscar y enviar señales a los procesos de forma interactiva. En la práctica, ps se usa para inspecciones puntuales y para scripts, mientras que top o htop se usan para monitorizar la actividad del sistema mientras sucede.

Una señal en Linux es un mensaje breve y estandarizado que el sistema operativo o un usuario envía a un proceso para comunicarle algo, habitualmente para pedirle que realice una acción como detenerse, pausarse o recargar su configuración. Es uno de los mecanismos básicos de comunicación y control de procesos del sistema. Cada señal tiene un nombre, que suele empezar por las letras SIG, y un número asociado, y cada una tiene un significado convencional. Algunas señales las genera el propio sistema ante determinadas circunstancias, mientras que otras las envía deliberadamente el usuario mediante comandos como kill, pkill o killall. Cuando un proceso recibe una señal, puede reaccionar de distintas maneras según la señal de que se trate y según cómo esté programado: muchas señales pueden ser capturadas y gestionadas por el proceso, que decide entonces qué hacer al recibirlas, como guardar su estado antes de terminar o releer su archivo de configuración sin reiniciarse. Sin embargo, hay señales especiales que el proceso no puede ignorar ni gestionar, como la que fuerza su terminación inmediata. Las señales más conocidas y usadas en el día a día son las relacionadas con la terminación de procesos, y entre ellas la distinción más importante es la que existe entre pedir a un proceso que termine de forma ordenada, dándole ocasión de limpiar, y forzar su terminación inmediata sin margen de reacción. Comprender el concepto de señal es esencial para controlar adecuadamente los procesos y los servicios del sistema.

SIGTERM y SIGKILL son las dos señales que se usan para terminar un proceso, y la diferencia entre ellas es crucial y determina cuál se debe usar en cada situación. SIGTERM, que es la señal que se envía por defecto cuando se usa el comando kill con solo el número del proceso, es una petición de terminación ordenada y cortés: el sistema le pide al proceso que termine, pero le da la oportunidad de reaccionar de forma controlada antes de hacerlo, lo que le permite guardar su trabajo pendiente, cerrar correctamente los archivos que tenía abiertos, liberar los recursos que estaba usando y despedirse limpiamente. Como el proceso puede gestionar esta señal, la terminación resulta segura y no arriesga la integridad de los datos. SIGKILL, que se envía con la opción menos nueve del comando kill, es en cambio una terminación forzada e inmediata que el proceso no puede capturar, ignorar ni gestionar en modo alguno: el sistema simplemente lo elimina en el acto, sin avisarle y sin darle ninguna oportunidad de guardar ni de limpiar. La consecuencia es que SIGKILL puede dejar datos a medio escribir, archivos en estado inconsistente o recursos sin liberar correctamente, lo que es especialmente delicado en el caso de bases de datos y servicios. Por todo esto, la regla práctica es clara: se debe intentar siempre primero SIGTERM y darle al proceso unos segundos para que termine por su cuenta, y solo recurrir a SIGKILL como último recurso cuando el proceso está realmente colgado y no responde a la petición ordenada.

Para cerrar un programa que no responde desde la terminal, el procedimiento recomendado sigue una secuencia pensada para minimizar el riesgo de pérdida de datos. El primer paso es identificar el proceso del programa, averiguando su número de identificación o PID; esto se puede hacer con el comando ps combinado con un filtro por el nombre del programa, o mediante top o htop, que muestran los procesos activos y su consumo. Una vez conocido el PID, o directamente el nombre del programa, el segundo paso es enviarle la señal de terminación ordenada, lo que se logra con el comando kill seguido del PID, o alternativamente con pkill o killall seguidos del nombre del programa si se prefiere actuar por nombre en lugar de por número. Esta señal pide al programa que se cierre de forma controlada, permitiéndole guardar y limpiar, por lo que es la forma más segura y la que siempre debe intentarse primero. El tercer paso solo es necesario si el programa está tan colgado que ni siquiera responde a esa petición ordenada tras esperar unos segundos: en ese caso, y solo entonces, se recurre a la terminación forzada con la opción menos nueve del comando kill, que elimina el proceso de inmediato aunque a costa de perder cualquier trabajo no guardado. Conviene tener cuidado de dirigir la señal al proceso correcto verificando bien el PID, y recordar que para detener servicios del sistema lo adecuado no es usar kill directamente, sino su gestor de servicios correspondiente.

Un proceso zombi es un proceso que ya ha terminado su ejecución pero cuya entrada todavía permanece en la tabla de procesos del sistema porque su proceso padre aún no ha recogido su información de finalización. En el funcionamiento normal de Linux, cuando un proceso hijo termina, no desaparece del todo inmediatamente, sino que queda en un estado especial a la espera de que su proceso padre lea su código de salida, es decir, el resultado con el que terminó; este acto del padre de recoger esa información se realiza mediante un mecanismo específico y, una vez hecho, la entrada del proceso terminado se elimina definitivamente y el zombi desaparece. Un proceso zombi es, por tanto, simplemente un proceso muerto que todavía figura brevemente en la tabla a la espera de ser recogido, y no consume recursos reales como memoria o procesador, sino únicamente una entrada en la tabla de procesos. En la mayoría de los casos los zombis son transitorios y se resuelven solos casi de inmediato, por lo que ver alguno de forma ocasional no es motivo de preocupación. El problema solo aparece cuando los zombis se acumulan en gran cantidad y no se recogen, lo que suele indicar un fallo en el programa padre que no está gestionando correctamente la finalización de sus hijos; en esa situación, la solución habitual pasa por reiniciar o corregir el proceso padre defectuoso, ya que los zombis en sí no se pueden terminar con las señales normales al estar ya muertos.