Profundos conocimientos del sistema "Ubuntu Linux": ¿vemos esto?


LINUX como sabemos es un kernel y no un sistema operativo, viene con varias distribuciones como: Debian, Fedora, Ubuntu, etc. y muchas más. El sistema operativo Ubuntu desarrollado por Mark Shuttleworth es conocido y ampliamente utilizado por muchos. Además, al ser gratuito y Open Source, anualmente se lanza su nueva versión la cual es aportada por miles de desarrolladores que contribuyen a su desarrollo. Pero, ¿cómo funciona? ¿Qué procesos, lista de eventos lo hacen funcionar y cuál es el significado de estos procesos?

Este artículo le llevará un poco más a los aspectos internos del SO Ubuntu que son muy interesantes y ayudarían a un principiante a comprender completamente su funcionamiento.

Establecimiento del sistema

Linux tiene un proceso para su funcionamiento, todos y cada uno de los servicios del sistema, incluida la administración de energía, el arranque y el manejo de fallas del sistema, es un proceso que tiene un archivo de configuración en "/etc/init " que describe el evento en el que ejecutará y el evento correspondiente en el que detendrá su ejecución, junto con que también mantiene sus otros archivos de configuración que describen su comportamiento en tiempo de ejecución en el directorio "/etc/" del sistema, lo que hace que el sistema uno impulsado por eventos.

Si se generan eventos, entonces alguien debería estar allí para atraparlos y ejecutarlos. Bueno, obviamente, el controlador es nuestro proceso principal que existe como padre de todos los procesos con ID de proceso 1 , es decir, init . Este es el proceso que comienza con el inicio del sistema y nunca se detiene. Este proceso solo muere una vez que se apaga el sistema, ya que no hay ningún proceso que sea el padre de init.

Las versiones anteriores de Ubuntu anteriores a la 6.10 incluían sysvinit de estilo antiguo que se usaba para ejecutar scripts en “ /etc/rcx.d ”en cada inicio y apagado del sistema. Pero, después de eso, el sistema advenedizo reemplazó al antiguo sistema sysvinit , pero aún proporciona compatibilidad con versiones anteriores.

Las últimas versiones de Ubuntu tienen este sistema advenedizo, pero desde su evolución desde Ubuntu 6.10 ha pasado varias revisiones, siendo la versión actual 1.13.2 el 4 de septiembre de 2014. El último sistema advenedizo tiene 2 procesos init , uno para los procesos del sistema y otro que administra la sesión del usuario que ha iniciado sesión actualmente y existe solo hasta que el usuario inicia sesión, también llamado x-session init .

Todo el sistema se ha establecido como jerárquico, que consiste en la relación ancestro-hijo a lo largo del poder y el apagado del sistema.

Por ejemplo : Una pequeña relación jerárquica entre ambos procesos de inicio es: system init (1) -> administrador de pantalla (espacio del kernel) -> administrador de pantalla (espacio de usuario) -> inicio de usuario (o x- inicio de sesión).

Los archivos de configuración para los procesos administrados por el sistema init residen en "/etc/init " y los administrados por la sesión init residen en "/usr/share/upstart " (como según las versiones emergentes actuales por encima de 1.12 ) y estos archivos de configuración son clave para muchos secretos descubiertos sobre procesos como se describe en este artículo.

Profundizando más en la jerarquía

Ubuntu reconoce dos tipos de procesos:

  1. Short lived jobs (or work-and-die jobs).
  2. Long lived jobs (or stay-and-work jobs).

La jerarquía que se hace en el sistema se debe a la relación de dependencia entre procesos que podemos entender al ver sus archivos de configuración. Comencemos primero por una simple relación jerárquica entre los procesos que hacen que el sistema se inicie y comprendamos el significado de cada uno de ellos.

Init es el primer proceso que se inicia al encender el sistema y se clasifica en el trabajo trabajar y permanecer , ya que nunca se mata y solo se activa el momento en que se mata el init apagando, es decir, init solo muere y eso también una vez por sesión y eso es al apagar. Al encender, init genera el primer evento en el sistema, es decir, el evento de inicio. Cada archivo de configuración en “/etc/init ” tiene dos líneas que definen el evento que hace que el proceso se inicie y se detenga. Esas líneas son las que se resaltan en la siguiente figura:

Este es un archivo de configuración de un proceso failsafe-x y estos comienzan y se detienen en las condiciones que describen el evento en el que se iniciará el proceso. En la generación del evento de inicio por proceso de inicio, aquellos procesos que tienen inicio como condición de inicio se ejecutan en paralelo y esto solo define la jerarquía, y todos los procesos que se ejecutan al inicio son hijos de init.

Los procesos que se inician en el inicio se enumeran a continuación y todos estos son trabajos de trabajo y muerte:

1 . nombre de host : este es un proceso que simplemente le dice al sistema su nombre de host definido en el archivo/etc/hostname.

2 . kmod : carga los módulos del kernel, es decir, todos los controladores del archivo/etc/modules.

3 . mountall : este proceso genera muchos eventos y es el principal responsable de montar todos los sistemas de archivos en el arranque, incluidos los sistemas de archivos locales y los sistemas de archivos remotos.

El archivo /proc también se monta mediante este mismo proceso y, después de todo el trabajo de montaje, el último evento generado por él es el evento del sistema de archivos, lo que hace que la jerarquía avance más.

4 . plymouth : este proceso se ejecuta al iniciar mountall y es responsable de mostrar esa pantalla negra que se ve al iniciar el sistema mostrando algo como a continuación:

5 . Plymouth-ready : indica que Plymouth está activo.

A continuación se muestran los procesos principales, otros que también se ejecutan al inicio incluyen, como udev-fallback-graphics , etc. Volviendo a la jerarquía de inicio, en pocas palabras, los eventos y procesos que siguen son como en secuencia:

1 . init junto con la generación del evento de inicio.

2 . mountall montando sistemas de archivos, plymouth (junto con el inicio de mountall) mostrando la pantalla de presentación y cargando módulos del kernel kmod.

3 . Evento sistema de archivos local generado por mountall que hace que dbus se ejecute. (Dbus es el bus de mensajes de todo el sistema que crea un conector que permite que otros procesos se comuniquen entre sí mediante el envío de mensajes a este conector y el receptor escucha los mensajes en este conector y filtra los destinados a él).

4 . sistema de archivos local junto con el dbus iniciado y el evento static-network-up causado por el proceso de red que también se ejecuta en el evento del sistema de archivos local hace que network-manager se ejecute.

5 . El evento sistema de archivos virtual generado por mountall hace que udev se ejecute. (udev es el administrador de dispositivos para linux que administra la conexión en caliente de dispositivos y es responsable de crear archivos en el directorio/dev y administrarlos también). udev crea archivos para ram, rom, etc.en el directorio/dev, los que el mountall ha terminado de montar virtuales -filesystems y ha generado el evento virtual-filesystem que significa el montaje del directorio/dev.

6 . udev hace que upstart-udev-bridge se ejecute, lo que significa que la red local está activa. Luego, después de que mountall haya terminado de montar el último sistema de archivos y haya generado un evento del sistema de archivos.

7 . El evento sistema de archivos junto con el evento static-network-up hace que se ejecute el trabajo rc-sysinit. Aquí viene la compatibilidad con versiones anteriores entre sysvinit más antiguo y advenedizo ...

9 . rc-sysinit ejecuta el comando telinit que indica el nivel de ejecución del sistema.

10 . Después de obtener el nivel de ejecución, el init ejecuta los scripts que comienzan con 'S' o 'K' (iniciando trabajos que tienen 'S' al comienzo de su nombre y matando aquellos que tienen 'K' al comienzo de su nombre) en el directorio/etc/rcX.d (donde 'X' es el nivel de ejecución actual).

Este pequeño conjunto de eventos hace que el sistema se inicie cada vez que lo enciende. Y este evento de activación de procesos es lo único responsable de crear la jerarquía.

Ahora, otro complemento de lo anterior es la causa del evento. Qué proceso causa qué evento también se especifica en ese mismo archivo de configuración del proceso como se muestra a continuación en estas líneas:

Arriba hay una sección del archivo de configuración del proceso de montaje. Esto muestra los eventos que emite. El nombre del evento es uno que sigue a la palabra " evento ". El evento puede ser el definido en el archivo de configuración como arriba o puede ser el nombre del proceso junto con el prefijo "iniciando", "iniciado", "deteniendo" o "detenido".

Entonces, aquí definimos dos términos:

  1. Event Generator: One that has the line ‘emits xxx’ in its configuration file where xxx is the name of event it owns or generates.
  2. Event Catcher: One that has its start on or stop condition as xxx or that starts or stop on the event generated one of the Event generators.

Por tanto, sigue la jerarquía y, por tanto, la dependencia entre procesos:

Event generator (parent) -> Event catcher (child)

Hasta ahora, debe haber entendido cómo la jerarquía de dependencia padre-hijo entre los procesos se establece mediante el mecanismo de activación de eventos a través de un mecanismo de inicio simple.

Ahora bien, esta jerarquía nunca es una relación uno a uno que tenga solo un padre para un hijo. En esta jerarquía podemos tener uno o más padres para un niño o un proceso es padre de más de un niño. ¿Cómo se logra esto? Bueno, la respuesta está en los archivos de configuración en sí.

Estas líneas se toman del proceso: redes y aquí la condición de inicio parece demasiado compleja compuesta por muchos eventos, a saber: sistemas de archivos locales , udevtrigger , contenedor , nivel de ejecución , redes .

Los sistemas de archivos locales son emitidos por mountall, udevtrigger es el nombre del trabajo, el evento contenedor es emitido por la detección de contenedores, el evento de nivel de ejecución es emitido por rc-sysinit y la red es nuevamente un trabajo.

De la misma manera, podemos tener un proceso como padre de muchos si el evento generado por un proceso es almacenado en caché por muchos.

Como se definió anteriormente, podemos tener trabajos de corta duración (o trabajos de trabajar y morir ) o de larga duración (o permanecer y trabajar ) pero cómo distinguir entre ¿¿ellos??

Los trabajos que tienen las condiciones ' iniciar en ' y ' finalizar ' especificadas en sus archivos de configuración y tienen la palabra ' tarea ' en su El archivo de configuración son trabajos trabajar y morir que comienzan en el evento generado, ejecutan su secuencia de comandos o sección ejecutiva (mientras se ejecutan, bloquean los eventos que los causaron) y luego mueren liberando aquellos eventos que bloquearon .

Los trabajos que no tienen la condición " detener el " en su archivo de configuración son trabajos de larga duración o permanecen y trabajan y nunca mueren. Ahora los trabajos de permanencia y trabajo se pueden clasificar además como:

  1. Those that do not have respawn condition and can be killed by root user.
  2. Those that have respawn condition in their configuration file and so they restart after being killed unless their work has been completed.

Conclusión

Por lo tanto, cada proceso en LINUX depende de algunos y tiene algunos procesos que dependen de él y esta relación es de muchos en muchos y se especifica con el sistema advenedizo junto con otros detalles del proceso.