Conocimientos profundos 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 muchos más. El sistema operativo Ubuntu desarrollado por Mark Shuttleworth es popularmente conocido y ampliamente utilizado por muchos. Además, al ser gratuito y de Código Abierto anualmente se lanza su nueva versión la cual es aportada por miles de desarrolladores que contribuyen a su desarrollo. Pero, ¿cómo funciona? ¿Cuáles son todos los procesos, la lista de eventos que hacen que funcione y cuál es el significado de estos procesos?

Este artículo le profundizará un poco en los aspectos internos del Ubuntu OS que son muy interesantes y ayudaría a un principiante a tener una comprensión completa de 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 fallos del sistema, son un proceso que tiene un archivo de configuración en “/etc/init” que describe el evento en el que ejecutará el evento correspondiente en el que detendrá su ejecución, además de mantener sus otros archivos de configuración que describen su comportamiento en tiempo de ejecución en el directorio “/etc/” del sistema, haciendo así que el sistema uno impulsado por eventos.

Si se generan eventos, ¿debería haber alguien allí para detectarlos 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 finaliza una vez que el sistema se apaga, ya que no hay ningún proceso que sea el padre de init.

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

Las últimas versiones de Ubuntu tienen este sistema advenedizo, pero desde su evolución desde Ubuntu 6.10 ha tenido 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 actual del usuario que ha iniciado sesión 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, y consiste en una relación ancestro-hijo desde el inicio hasta el apagado del sistema.

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

Los archivos de configuración para los procesos administrados por system init residen en “/etc/init” y para aquellos administrados por session init residen en “/usr/share/upstart” (como según las versiones actuales superiores a 1.12) y estos archivos de configuración son clave para descubrir muchos secretos sobre los procesos como se describe en este artículo.

Profundizando más en la jerarquía

Ubuntu reconoce dos tipos de procesos:

Empleos de corta duración (o trabajos de trabajo y muerte).
Empleos de larga duración (o trabajos de permanencia y trabajo).

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

Jerarquía de arranque

Init es el primer proceso que comienza al encender el sistema y se clasifica en el trabajo work-and-stay ya que nunca se finaliza y solo se activa el momento en que se finaliza el inicio. apagar, es decir, init solo muere y eso también una vez por sesión y eso es al apagar. Al encenderse, 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 como se resaltan en la siguiente figura:

Este es un archivo de configuración de un proceso failsafe-x y estas condiciones de inicio y detención describen el evento en el que se iniciará el proceso. Al generar un evento de inicio por parte del proceso init, aquellos procesos que tienen el 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 comienzan al 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 es el evento del sistema de archivos, lo que hace que la jerarquía avance aún 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 y que muestra algo como a continuación:
5. plymouth-ready: indica que Plymouth está listo.
Los siguientes son 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 los siguientes en secuencia:
1. init junto con la generación del evento de inicio.

2. mountall monta sistemas de archivos, plymouth (junto con el inicio de mountall) muestra la pantalla de inicio y kmod carga módulos del kernel.
3. Evento sistema de archivos local generado por mountall que provoca la ejecución de dbus. (Dbus es el bus de mensajes de todo el sistema que crea un socket que permite que otros procesos se comuniquen entre sí enviando mensajes a este socket y el receptor escucha los mensajes en este socket y filtra los que están destinados a él).
4. El sistema de archivos local junto con el dbus iniciado y el evento de red estática causado por el proceso de red que también se ejecuta en el evento del sistema de archivos local hacen que se ejecute el administrador de red.
5. El evento sistema de archivos virtual generado por mountall hace que se ejecute udev. (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, aquellos que el montaje ha terminado de montar virtualmente. -filesystems y ha generado el evento virtual-filesystem que significa montaje del directorio /dev.
6. udev hace que se ejecute upstart-udev-bridge, 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 hacen 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, init ejecuta los scripts que comienzan con 'S' o 'K' (iniciando trabajos que tienen 'S' en comienzo de su nombre y eliminar aquellos que tienen 'K' al principio 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 que desencadena procesos es el único responsable de crear la jerarquía.
Ahora, otro complemento a 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 el que sucede a la palabra "evento". El evento puede ser el definido en el archivo de configuración como se muestra arriba o puede ser el nombre del proceso junto con el prefijo "iniciando", "iniciado", "deteniendo" o "detenido".
Entonces, aquí definimos dos términos:
Generador de eventos: Uno que tiene la línea 'emite xxx' en su archivo de configuración donde xxx es el nombre del evento que posee o genera.
Event Catcher: Uno que tiene su condición de inicio o detención como xxx o que comienza o se detiene en el evento generado por uno de los generadores de eventos.
Así, sigue la jerarquía y, por tanto, la dependencia entre procesos:
Event generator (parent) -> Event catcher (child)
Agregar complejidad a la jerarquía
Hasta ahora, debes 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 simple mecanismo de arranque.
Ahora bien, esta jerarquía nunca es una relación uno a uno en la que solo hay un padre para un hijo. En esta jerarquía podemos tener uno o más padres para un niño o un proceso de ser padre de más de un niño. ¿Cómo se logra esto? Bueno, la respuesta está en los propios archivos de configuración.
Estas líneas están tomadas del proceso: redes y aquí la condición de inicio parece demasiado compleja y está compuesta de muchos eventos, a saber: sistemas de archivos locales, udevtrigger, contenedor, nivel de ejecución, redes.
Mountall emite los sistemas de archivos locales, udevtrigger es el nombre del trabajo, el evento de contenedor lo emite Container-detect, el evento de nivel de ejecución lo emite rc-sysinit y la red es nuevamente un trabajo.
Por lo tanto, en una jerarquía, la red de procesos es hija de mountall, udevtrigger y container-detect ya que no puede continuar su funcionamiento (el funcionamiento del proceso son todas las líneas definidas en las secciones script o exec en el archivo de configuración del proceso) hasta que los procesos anteriores generen sus eventos.
Del mismo modo, podemos hacer que un proceso sea padre de muchos si el evento generado por un proceso está almacenado en caché por muchos.
Distinguir tipos de trabajo
Como se definió anteriormente, podemos tener trabajos de corta duración (o trabajar y morir) o de larga duración (o quedarse y trabajar), pero ¿cómo distinguirlos? ¿¿a ellos??
Los trabajos que tienen condiciones 'iniciar' y 'detener' especificadas en sus archivos de configuración y tienen una palabra 'tarea' en su El archivo de configuración son trabajos de trabajo y muerte que comienzan con el evento generado, ejecutan su script o sección ejecutiva (mientras se ejecutan, bloquean los eventos que los causaron) y mueren después liberando los eventos que bloquearon. .
Aquellos trabajos que no tienen la condición 'detener' en su archivo de configuración son trabajos de larga duración o de quedarse y trabajar y nunca mueren. Ahora los trabajos de permanencia y trabajo se pueden clasificar además como:
Aquellos que no tienen condición de reaparición y pueden ser eliminados por el usuario root.
Aquellos que tienen la condición de reaparición en su archivo de configuración y, por lo tanto, se reinician después de ser eliminados a menos que se haya completado su trabajo.
Conclusión
Por lo tanto, cada proceso en LINUX depende de algunos y tiene algunos procesos dependientes de él y esta relación es de muchos en muchos y se especifica con el sistema advenedizo junto con otros detalles del proceso.