Ya adelanté hace mucho tiempo que la vida de los programas no es nada agradable a pesar de las apariencias, y de hecho puede llegar a ser bastante surrealista. Hoy aprenderemos a solidarizarnos con estas pobres criaturas. Para seguir leyendo interesa que recuerde qué es un proceso: básicamente, es la forma en que nos referiemos un programa que esté ejecutándose en el sistema. Las diferencias son sutiles pero importantes.

Y por favor, sea prudente: esta entrada puede herir su sensibilidad… ;-)

Dando a luz

¿Cómo empieza la vida de un proceso? Pues como la de (casi) todo el mundo: con un parto. En efecto, los procesos nacen de otros procesos. No me estoy riendo de ustedes, es la pura verdad: muchos programas crean subprocesos para que éstos se encarguen de ciertas tareas auxiliares y aprovechar la famosa simultaneidad. Se trata de una forma de entender la vida bastante interesada: tengo hijos para que me ayuden en el trabajo que no quiero o no puedo realizar…

A su vez, estos hijos tendrán su descendencia, y de esta manera los procesos formarán una bonita familia feliz en memoria. Toda estirpe tiene un origen, y es lógico pensar que tendrá que existir un proceso «patriarca» que engendre al resto. Cuando el sistema arranca, se crea un proceso 0, cuya función es engendrar al proceso 1, que recibe el nombre de “Init?. Este proceso, el padre de todos, se encarga de iniciar el sistema correctamente, teniendo hijos que asumirán las diferentes funciones del sistema y tendrán más hijos. A partir de este momento, todos los programas que se ejecuten serán, de alguna manera, descendientes de Init, que permanecerá siempre en el sistema, como el capitán de un barco.

Hay que hacer una precisión. Técnicamente los procesos no tienen hijos. No. Los procesos se clonan a sí mismos (esto empieza a ser surrealista). Es decir, Init crea un clon de sí mismo y le manda atender una función del sistema. Aunque son iguales en su origen, quedan completamente diferenciados y el Init original conserva cierto poder sobre la copia, con lo que podemos considerar que es su padre. Para que quede claro, es igual que el capítulo de Los Simpsons en que Homer crea clones de sí mismo a los que manda a hacer el trabajo sucio.

Una vida peligrosa

Después de este parto accidentado, la vida del proceso transcurrirá con mayor o menor interés, desempeñando la función que su padre le encomendó. En todo ese tiempo, puede ser expulsado momentáneamente de la ejecución, puede quedarse dormido en espera de algún evento que le despierte nuevamente… tendrá, en general, una existencia aparentemente relajada.

Y digo aparentemente porque en todo este tiempo, una enorme cantidad de peligros amenazan su existencia… un proceso puede morir por muchos motivos:

• Puede ser por muerte natural, en la que llega al final de su tarea asignada. Como no tiene nada más que hacer, se muere.
• También puede suicidarse si encuentra una anomalía que no sabe resolver por sí mismo.
• Puede ser matado por otro proceso, siempre que el proceso asesino tenga “licencia para matar?, que se traduce en que sea su padre o un proceso del administrador.
• Puede ser matado por el sistema operativo, por varios motivos: intentó realizar una operación no admitida, cometió un error, no tenía memoria suficiente, acaparaba un determinado recurso… cualquier momento es bueno para morir.

El mecanismo por el que un proceso elimina a otro es muy interesante. Si un proceso padre quiere matar a su hijo (cosa muy común por otro lado), le pide primero que se muera por las buenas, porque puede que el hijo quiera hacer algo antes de morirse.

El bondadoso padre le dice “mira, te voy a matar, así que haz lo que tengas que hacer y haz el favor de morirte?. Eso equivale a enviarle una señal, llamada SIGTERM, que quiere decir “termina?. Si el hijo sigue en ejecución pasado un tiempo, el padre cumplirá sus amenazas y le matará, enviándole la señal SIGKILL (unos cachondos mentales, los del Unix…)

El hijo zombie

El objetivo final de la vida de un proceso hijo es informar a su padre de que terminó su trabajo con éxito, y lo es tanto que un proceso no morirá hasta haber informado de que lo hizo. En principio no hay problema, pero ¿qué pasa si un proceso padre muere y el hijo continúa funcionando? Cuando el hijo termine sus tareas, no podrá informar a su padre de que ha hecho los deberes, y como un chico obediente esperará a su padre (que no va a volver jamás, qué dura es esta vida…).

En este caso, el proceso huérfano sigue vivo pero no tiene nada que hacer, así que decimos que el proceso está Zombie. La cosa se pone macabra. ¿Quién se hace cargo de esta pobre criatura? Pues el proceso Init hace de padre adoptivo, recoge lo que el hijo tenía que decir, lo desecha (porque realmente no le vale para nada) y acto seguido exorciza al zombie vía SIGKILL y lo manda al descanso eterno.

Divertido ¿eh?