Informes profundos del sistema Ubuntu Linux - ¿Vemos esto??

Linux Como sabemos, es un núcleo y no un sistema operativo, se envía con varias distribuciones como: Debian, Fedora, Ubuntu etc. y muchos más. Ubuntu OS desarrollado por Mark Shuttleworth es conocido popularmente y ampliamente utilizado por muchos. Además, siendo gratuito y de código abierto, su nueva versión se lanza anualmente, que es contribuida por miles de desarrolladores que contribuyen a su desarrollo. Pero, ¿cómo funciona?? ¿Qué todos los procesos, la lista de eventos lo hacen funcionar y cuál es la importancia de estos procesos??

Este artículo te llevaría un poco a las partes internas de OS de Ubuntu que son muy interesantes y ayudarían a un novato a tener una comprensión completa de su funcionamiento.

Colocar el sistema

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

Si hay eventos generados, 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 i.mi. en eso. Este es el proceso que comienza con el inicio del sistema y nunca se detiene. Este proceso solo muere una vez que el sistema se apaga, ya que no hay ningún proceso que sea el padre de init.

Versiones anteriores de Ubuntu antes 6.10 incluía estilo antiguo sysvinit que se usó para ejecutar scripts en "/etc/rcx.d"Directorio en cada inicio y cierre del sistema. Pero después de eso advenedizo El sistema reemplazó el estilo antiguo sysvinit sistema, pero aún le proporciona compatibilidad hacia atrás.

Las últimas versiones de Ubuntu tienen este sistema advenedizo, pero desde su evolución de Ubuntu 6.10 ha pasado varias revisiones la versión actual 1.13.2 como el 4 de septiembre de 2014. El último sistema de advenedizo tiene 2 init procesos, uno para los procesos del sistema y otro que administra la sesión actualizada en la sesión del usuario y existe solo hasta que el usuario haya iniciado sesión, también llamó sesión X en eso.

Todo el sistema se ha establecido como jerárquico, que consiste en una relación de antepasado en toda la potencia para reducir el sistema.

Por ejemplo: Una pequeña relación jerárquica entre ambos procesos de inicio es: Init del sistema (1) -> Display Manager (espacio del núcleo) -> Display Manager (espacio de usuario) -> Init de usuarios (o X-Session Init).

Los archivos de configuración para los procesos administrados por el inicio del sistema residen en "/etc/init"Y para aquellos administrados por sesión init residen en"/usr/share/upstart”(Según las versiones actuales actuales anteriores 1.12) y estos archivos de configuración son clave para muchos secretos desenterrados sobre los procesos como se describe en este artículo.

Cada vez más profundo en la jerarquía

Ubuntu reconoce dos tipos de procesos:

1. Trabajos de corta duración (o trabajos de trabajo y muerte).
2. Trabajos de larga duración (o trabajos de permanencia y trabajo).

La jerarquía que se realiza en el sistema se debe a la relación de dependencia entre los procesos que podemos entender al ver sus archivos de configuración. Primero comencemos desde una relación jerárquica simple entre los procesos que hacen que el sistema arrance y comprenda la importancia de cada uno de ellos.

Jerarquía de arranque

En eso es el primer proceso en comenzar a encender el sistema y se clasifica bajo trabajo y estadía El trabajo, ya que nunca se mata y solo el tiempo que se mata al inicio está en el encendido de I.mi. Init solo muere y eso también una vez por sesión y eso está en impulsar. Al encender, Init genera el primer evento en el sistema I.mi. evento de inicio. Cada archivo de configuración en "/etc/init”Tiene dos líneas que definen el evento que hace que el proceso comience y se detenga. Esas líneas son como se destacan en la figura a continuación:

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

Los procesos que comienzan en el inicio se enumeran como en el que se encuentran y todos estos son trabajos de trabajo y muerte:

1. nombre de host - Este es un proceso que solo le dice al sistema de su nombre de host definido en el archivo /etc /hostname.

2. kmod - Carga los módulos del núcleo I.mi. Todos los controladores del archivo /etc /módulos.

3. montaña - 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 /Proc El archivo también está montado en este mismo proceso y después de todo el trabajo de montaje, el último evento generado por IS es el evento de sistemas de archivos 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 en el inicio del sistema que muestra algo como a continuación:

5. preparado para Plymouth - Indica que Plymouth está arriba.

Los siguientes son el proceso principal, otros que también se ejecutan en el inicio incluyen, como UDEV-Fallback-Graphics, etc. Volviendo a la jerarquía de arranque, en pocas palabras, los eventos y los procesos que siguen son como en secuencia:

1. en eso junto con la generación de eventos de inicio.

2. montaña Montaje de sistemas de archivos, Plymouth (junto con el inicio de Mountall) que muestra la pantalla de salpicaduras y los módulos de kernel de carga KMOD.

3. sistema de archivos locales Evento generado por Mountall haciendo que se ejecute DBUS. (DBUS es el bus de mensajes en todo el sistema que crea un socket que permite que otros procesos se comuniquen entre sí mediante el envío de mensajes a este socket y el receptor escucha los mensajes en este socket y filtra los que se destinan a ello).

4. sistema de archivos locales Junto con el evento inicial de DBUS y la red estática causada por la red de procesos que también se ejecuta en el evento local-archivos que hace que se ejecute el administrador de la red.

5. sistema de archivos virtuales El evento generado por Mountall hace que se ejecute UDEV. (UDEV es el Administrador de dispositivos de Linux que administra el encaprobado de dispositivos y es responsable de crear archivos en /dev directorio y administrarlos también.) UDEV crea archivos para RAM, ROM, etc. In /dev Directory One The Mountall ha terminado de montar los sistemas de archivos virtuales y ha generado el evento Virtual-FileSystem que significa el montaje de /Dev Directory.

6. udev Hace que se ejecute el advenedizo-UDVV-Bridge que significa que la red local está arriba. Luego, después de que Mountall haya terminado de montar el último sistema de archivos y haya generado el evento del sistema de archivos.

7. sistema de archivos El evento junto con el evento estático-net-up hace que el trabajo de RC-Sysinit se ejecute. Aquí, viene la compatibilidad atrasada entre el sysvinit más antiguo y el advenedizo ..

9. rc-sysinit Ejecuta el comando Telinit que le indica al sistema RunLevel.

10. Después de obtener el RunLevel, el init ejecuta los scripts que comienzan con 'S' o 'K'(Empleos iniciales que tienen'S'Al comienzo de su nombre y matando a los que tienen'K'Al comienzo de su nombre) en el directorio /etc /rcx.D (donde 'X'¿Es el RunLevel actual).

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

Ahora, otro complemento de arriba 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 Mountall. Esto muestra los eventos que emite. El nombre del evento es uno que tiene éxito la palabra 'evento'. El evento puede ser el definido en el archivo de configuración como se indicó anteriormente o puede ser el nombre del proceso junto con el prefijo 'iniciar', 'iniciado', 'detener' o 'detener'.

Entonces, aquí definimos dos términos:

1. 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.
2. Receptor de eventos: Uno que tenga su condición de inicio o parada como xxx o que comience o detenga en el evento generó uno de los generadores de eventos.

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

Generador de eventos (padre) -> Catcher de eventos (niño) 

Agregar complejidad a la jerarquía

Hasta ahora, debes haber entendido cómo la jerarquía de padre-hijo La dependencia entre los procesos se establece por Evento de activación mecanismo a través de un mecanismo de arranque simple.

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

Estas líneas se toman del proceso: las redes y aquí el inicio en la condición parece un poco complejo compuesto por muchos eventos, a saber - sistemas de archivos locales, UDEVTRIGGER, envase, renta, redes.

Local-FileSystems es emitido por Mountall, UDevTrigger es el nombre de Job, el evento de contenedores se emite mediante detection de contenedores, evento RunLevel emitido por RC-Sysinit, y Networking es nuevamente un trabajo.

Por lo tanto, en una jerarquía, la red de procesos es el niño de Mountall, UDevtrigger y el contenedor detectar, ya que no puede continuar su funcionamiento (el funcionamiento del proceso son todas las líneas que se definen en secciones de script o ejecutor en el archivo de configuración del proceso) Hasta que los procesos anteriores generen sus eventos.
Del mismo modo, podemos tener un proceso como padre de muchos si el evento generado por un proceso es almacenado en caché por muchos.

Distinguir los tipos de trabajo

Como se definió anteriormente, podemos tener de corta duración (o trabajo y morir trabajos) o durante mucho tiempo (o estancia y trabajo) trabajos pero cómo distinguirlos entre ellos??

Los trabajos que tienen ambos 'comienza en' y 'parar en'Condiciones especificadas en sus archivos de configuración y tener una palabra'tarea'En su archivo de configuración están trabajo y morir trabajos que comienzan en el evento generado, ejecutar su script o sección ejecutiva (mientras se ejecutan, bloquean los eventos que los causaron) y mueren luego liberando esos eventos que bloquearon.

Aquellos trabajos que no tienen 'parar en'La condición en su archivo de configuración es de larga duración o estancia y trabajo trabajos y nunca mueren. Ahora los trabajos de estadía y trabajo se pueden clasificar más a fondo como:

1. Aquellos que no tienen condición de reaparición y pueden ser asesinados por un usuario root.
2. Aquellos que tienen una condición de reaparición en su archivo de configuración y, por lo tanto, se reinician después de ser asesinados a menos que se haya completado su trabajo.

Conclusión

Así, cada proceso en Linux depende de algunos y tiene algunos procesos que dependen de ello y esta relación es de muchos en muchos y se especifica con el sistema Upeste junto con otros detalles del proceso.