Insights profundos do sistema Ubuntu Linux - vemos isso?

Linux Como sabemos, é um kernel e não um sistema operacional, navios com várias distribuições como: Debian, Fedora, Ubuntu etc. e muitos mais. Ubuntu OS desenvolvido por Mark Shuttleworth é popularmente conhecido e amplamente usado por muitos. Além disso, sendo livre e de código aberto, sua nova versão é lançada anualmente, que é contribuída por milhares de desenvolvedores que contribuem para o seu desenvolvimento. Mas, como isso funciona? O que todos os processos, a lista de eventos fazem funcionar e qual é o significado desses processos?

Este artigo levaria você um pouco profundamente para os internos de Ubuntu OS que são muito interessantes e ajudariam um novato a ter um entendimento completo de seu funcionamento.

Deitar do sistema

O Linux tem um processo para o seu funcionamento, todo e qualquer serviço de sistema, incluindo gerenciamento de energia, inicialização, manuseio de falhas do sistema é um processo que possui um arquivo de configuração em “/etc/init”Isso descreve o evento no qual ele será executado e o evento correspondente no qual impediria sua execução, juntamente com isso, também mantém seus outros arquivos de configuração que descrevem seu comportamento em tempo de execução no sistema“/etc/”Diretório, tornando assim o sistema um evento orientado a um.

Se houver eventos gerados, então alguém deve estar lá para pegá -los e executá -los?? Bem, obviamente, o controlador é o nosso principal processo que existe como pai de todos os processos com ID do processo 1 eu.e. iniciar. Este é o processo que começa com a inicialização do sistema e nunca para. Esse processo só morre quando o sistema é desligado, pois não há processo que seja o pai do init.

Versões anteriores de Ubuntu antes 6.10 Incluído estilo antigo sysvinit que foi usado para executar scripts em “/etc/rcx.d”Diretório em todas as startups e desligamentos do sistema. Mas, depois disso subir na vida sistema substituiu o estilo antigo sysvinit sistema, mas ainda fornece compatibilidade com versões anteriores.

As últimas versões do Ubuntu têm esse sistema iniciante, mas desde a sua evolução de Ubuntu 6.10 foi várias revisões da versão atual sendo 1.13.2 como em 4 de setembro de 2014. O mais recente sistema iniciante tem 2 init Processos, um para os processos do sistema e outro que gerencia a sessão atual de usuários e existe apenas até que o usuário esteja conectado, também chamado X-sessão iniciar.

Todo o sistema foi estabelecido como hierárquico, consistindo em relação ancestral em todo o poder para descer do sistema.

Por exemplo: Uma pequena relação hierárquica entre os dois processos INIT é: System Init (1) -> Display Manager (espaço do kernel) -> Display Manager (espaço do usuário) -> Usuário init (ou init de sessão X).

Os arquivos de configuração dos processos gerenciados pelo sistema iniciam residem em “/etc/init”E para aqueles gerenciados pela sessão Inits residem em“/usr/share/upstart”(De acordo com as versões atuais do início 1.12) e esses arquivos de configuração são essenciais para muitos segredos desenterrados sobre os processos, conforme descrito neste artigo.

Ficando mais profundo na hierarquia

O Ubuntu reconhece dois tipos de processos:

1. Empregos de vida curta (ou trabalho e trabalho).
2. Empregos de longa duração (ou empregos de permanência e trabalho).

A hierarquia feita no sistema é devido à relação de dependência entre os processos que podemos entender, visualizando seus arquivos de configuração. Vamos começar a partir de uma simples relação hierárquica entre os processos que fazem do sistema inicializar e entender o significado de cada um deles.

Hierarquia de inicialização

Iniciar é o primeiro processo a começar a ligar no sistema e é classificado em trabalho e estadia trabalho como nunca é morto e só o tempo em que o init é morto está em desgaste eu.e. init apenas morre e isso também uma vez por sessão e isso está desligando. Ao ligar, Initter gera o primeiro evento no sistema I.e. evento de inicialização. Cada arquivo de configuração em “/etc/init”Tem duas linhas que definem o evento que faz com que o processo inicie e pare. Essas linhas são destacadas na figura abaixo:

Este é um arquivo de configuração de um processo FailSafe-x E estes começam e param nas condições descrevem o evento em que o processo começará. Na geração de eventos de inicialização, por init processos, os processos que têm startups, pois o início da condição são executados em paralelo e isso define apenas a hierarquia, e todos os processos que executam na startup são filhos de init.

Os processos que começam na startup estão listados como abaixo e todos são trabalhos de trabalho e morto:

1. nome de anfitrião - Este é um processo que apenas informa ao sistema de seu nome de host definido no arquivo /etc /hostname.

2. Kmod - Carrega os módulos do kernel i.e. Todos os drivers do arquivo /etc /módulos.

3. Mountall - Esse processo gera muitos eventos e é principalmente responsável por montar todos os sistemas de arquivos na inicialização, incluindo sistemas de arquivos locais e sistemas de arquivos remotos.

O /Proc O arquivo também é montado por esse processo e, depois de todo o trabalho de montagem, o último evento gerado por ele é o evento FileSystems, que faz ainda mais a hierarquia prosseguir.

4. Plymouth - Esse processo é executado no início do Mountall e é responsável por mostrar a tela preta vista na startup do sistema mostrando algo como abaixo:

5. Pronto para Plymouth - Indica que Plymouth está em alta.

A seguir, o processo principal, outros que também são executados na startup incluem, como Udev-Fallback-Graphics, etc. Voltando à hierarquia de inicialização, em poucas palavras, os eventos e processos a seguir são como na sequência:

1. iniciar junto com a geração de eventos de inicialização.

2. Mountall Sistemas de arquivos de montagem, Plymouth (junto com o MountAll de partida) exibindo a tela Splash e os módulos de kernel de carregamento de kmod.

3. Sistema de Files Local Evento gerado pelo Mountall fazendo com que o DBUS seja executado. (DBUS é o barramento de mensagens amplo do sistema, que cria um soquete que permite que outros processos se comuniquem através do envio de mensagens para este soquete e o receptor escuta as mensagens neste soquete e filtra as que se destinam).

4. Sistema de Files Local Juntamente com o evento iniciado DBUS e estático-network-up causado pela rede de processos que também é executada no evento de sistema de filas locais faz com que o gerente de rede seja executado.

5. Virtual-Filesystem Evento gerado pelo Mountall faz com que o UDEV seja executado. (Udev é o gerenciador de dispositivos do Linux que gerencia a remoção de dispositivos a quente e é responsável por criar arquivos no diretório /dev e gerenciá-los também.) UDEV cria arquivos para RAM, ROM etc. ON DIRETÓRIO DE DEV O MOUNTALL Terminou em montagem Virtual-Filesystems e gerou o evento Virtual-Filesystem Significando Montagem do Diretório /Dev Directory.

6. udev faz com que o Upstart-Udev-Bridge execute o que significa que a rede local está em alta. Depois de Mountall terminar de montar o último sistema de arquivos e gerou evento de sistema de arquivos.

7. sistema de arquivo Evento, juntamente com o evento de rede estática, faz com que o trabalho de rc-sysinit seja executado. Aqui, vem a compatibilidade com versões anteriores entre o Sysvinit mais antigo e o início ..

9. rc-sysinit Executa o comando telinit que informa ao System RunLevel.

10. Depois de obter o nível de execução, o init executa os scripts que começam com 'S' ou 'K'(Trabalhos de partida que têm'S'No início do nome deles e matando aqueles que têm'K'No início do nome deles) no diretório /etc /rcx.D (onde 'X'é o nível atual).

Este pequeno conjunto de eventos faz com que o sistema inicie cada vez que você o liga. E esse evento acionamento de processos é a única coisa responsável por criar a hierarquia.

Agora, outro complemento acima é a causa do evento. Qual processo causa qual evento também é especificado nesse mesmo arquivo de configuração do processo, como mostrado abaixo nessas linhas:

Acima está uma seção do arquivo de configuração do processo Mountall. Isso mostra os eventos que emite. O nome do evento é um sucesso na palavra 'evento'. Evento pode ser o definido no arquivo de configuração como acima ou pode ser o nome do processo junto com o prefixo 'Starting', 'Iniciou', 'Stoping' ou 'Stop'.

Então, aqui definimos dois termos:

1. Gerador de eventos: Um que tem a linha 'emite xxx' em seu arquivo de configuração em que xxx é o nome do evento que ele possui ou gera.
2. Catcher de eventos: Um que tem sua condição de início ou parada como xxx ou que inicia ou pare no evento gerou um dos geradores de eventos.

Assim, a hierarquia segue e, portanto, a dependência entre os processos:

Gerador de eventos (pai) -> Catcher de eventos (filho) 

Adicionando complexidade à hierarquia

Até agora, você deve ter entendido como a hierarquia de pai-filho A dependência entre os processos é estabelecida por acionamento de eventos mecanismo através de um mecanismo de inicialização simples.

Agora, essa hierarquia nunca é um relacionamento individual com apenas um pai para um filho. Nesta hierarquia, podemos ter um ou mais pais para um filho ou um processo sendo pai de mais de um filho. Como isso é realizado?? Bem, a resposta está nos próprios arquivos de configuração.

Essas linhas são retiradas do processo - networking e aqui o início da condição parece um pouco complexo composto de muitos eventos, a saber - Sistemas de Files Locais, udevtrigger, recipiente, RUNLEVEL, networking.

Local-Filesystems é emitido por Mountall, Udevtrigger é o nome do trabalho, o evento de contêiner é emitido por um evento de detecção de contêineres, emitido por RC-sysinit, e a rede é novamente um emprego.

Assim, em uma hierarquia, a rede de processos é filho de Mountall, Udevtrigger e Detect, pois não pode continuar seu funcionamento (o funcionamento do processo é todas as linhas definidas nas seções Script ou Exec no arquivo de configuração do processo) Até os processos acima gerar seus eventos.
Da mesma forma, podemos ter um processo sendo pai de muitos se o evento gerado por um processo for armazenado em cache por muitos.

Distinguindo tipos de trabalho

Como definido anteriormente, podemos ter de vida curta (ou Trabalho e morrer empregos) ou de vida há muito Fique e trabalhe) empregos, mas como distinguir entre eles??

Os empregos que têm os doiscomece' e 'pare'Condições especificadas em seus arquivos de configuração e têm uma palavra'tarefa'em seu arquivo de configuração estão Trabalho e morrer Trabalhos que começam no evento gerado, executam sua seção Script ou Exec (enquanto executam, eles bloqueiam os eventos que os causaram) e morrem depois que liberam os eventos que eles bloquearam.

Aqueles trabalhos que não têm 'pare'Condição em seu arquivo de configuração tem vida longa ou Fique e trabalhe empregos e eles nunca morrem. Agora, os empregos de permanência e trabalho podem ser classificados ainda mais como:

1. Aqueles que não têm condição de reaparecimento e podem ser mortos pelo usuário root.
2. Aqueles que reaparecer.

Conclusão

Assim, cada processo em Linux depende de alguns e possui alguns processos dependentes dele e esse relacionamento é muitos em muitos e é especificado com o sistema iniciante, juntamente com outros detalhes do processo.