Repensando o PID 1 - Lennart Poettering

Esse artigo é a tradução (livre e resumida) do documento que deu origem ao systemd. Escrito por Lennart Poettering, Et al. A partir de 2010 esse polêmico sistema pretende substituir o SysVinit e ir bem além. No documento podemos ver os motivos e as justificativas que levaram desenvolvimento do systemd na visão do seu próprio autor.

[ Hits: 9.469 ]

Por: Perfil removido em 20/01/2016


"Paralelizando" Serviços com Soquetes



Este tipo de inicialização sincronizada resulta em um tipo de serialização de partes significativas do processo de boot. Não seria ótimo se pudéssemos nos livrar dos custos computacionais da serialização e das dependências?

Bem, eu digo que podemos. O que precisamos é entender o quê um daemon requer de outro e quais as causas do atraso de sua inicialização. Para daemons tradicionais do Unix há uma única resposta: eles precisam esperar até que um soquete seja oferecido pelo outro daemon para que possam se servir dele.

Usualmente esse é um soquete do tipo AF_UNIX disponível no sistema de arquivo; mas pode ser um soquete do tipo AF_INET[6], também. Por exemplo, clientes de D-Bus aguardam por /var/run/dbus/system_bus_socket para serem conectados. Enquanto clientes de syslog aguardam por /dev/log; os clientes de CUPS aguardam por um soquete como /var/run/cups/cups.sock e uma montagem NFS pode aguardar por um soquete como /var/run/rpcbind.sock. Isso é tudo que eles precisam para funcionar.

Agora, se isso é tudo que eles precisam, então, se criarmos um jeito de tornar esses soquetes disponíveis de modo cedo, e então aguardarmos (de algum modo) que o daemon seja carregado depois podemos aumentar a velocidade do processo de boot iniciando processos paralelos. Mas como podemos fazer isso?

Atualmente isso pode ser considerado simples em sistemas do tipo Unix: podemos criar uma lista de soquetes do tipo "antes" (before) e quando realmente iniciarmos o daemon responsável passamos esses soquetes para ele durante a chamada exec(). Assim, podemos criar TODOS os soquetes para TODOS os daemons em um único passo durante o processo Init.

Num segundo passo podemos executar TODOS os daemons de uma vez. Se um serviço precisava de outro, e este não está disponível, tudo bem, sua conexão entra em uma fila e esse cliente bloqueia uma única requisição. Além disto, esse método faz com que configurar dependências entre serviços não seja mais necessário. Uma vez iniciados TODOS os soquetes, TODOS os serviços podem considerar suas dependências satisfeitas.

Essa é a ideia central, vou dizer novamente com outras palavras e um exemplo: Se você inicia syslog e vários clientes dele ao mesmo tempo, o que acontece é que, no esquema proposto acima, TODAS as mensagens são enviadas para o soquete em /dev/log; os clientes NÃO tem que aguardar por syslog. Tão logo syslog esteja disponível ele assume essa fila processa uma mensagem por vez.

Basicamente, um buffer de soquete do kernel nos ajuda a maximizar a paralelização além de ordenar e sincronizar tudo, sem nenhum tipo de gerenciamento feito a partir do espaço usuário! E, se TODOS os soquetes estivessem disponíveis antes da inicialização dos daemons, o gerenciamento de dependências se tornaria dispensável ou, pelo menos, secundário.

Um daemon não precisa mais aguardar por outro (a menos que haja uma requisição síncrona, neste caso, o daemon deverá ser autoinicializável). Da perspectiva do daemon não há diferença e como consequência o gerenciamento de dependências se torna ainda mais desnecessário. No topo disto, e o que torna tudo mais robusto, é que os soquetes estão disponíveis independentemente dos daemons. No futuro, um daemon poderia ser escrito para rodar e sair, em seguida rodar novamente um novo ciclo de execução e novamente sair. O cliente não perceberia que o daemon é executado em ciclos.

Inicialmente, vamos deixar claro algumas coisas: o que proponho é um novo tipo de lógica? Não, certamente não é. O mais proeminente sistema da atualidade funciona deste modo. Ele é o sistema launchd da Apple. No MacOS a escuta por soquete de todos os daemons é feita por launchd.

Os serviços por si mesmos podem ser inicializados em paralelo e não há configuração de dependências. Essa é a razão pela qual MacOS possui tempos de inicialização fantásticos. Claro que a ideia central é mais antiga do que launchd, mas apenas o pessoal da Apple aplicou o conceito com eficiência.

No Unix, inetd tentou fazer isso. Todavia, o foco em inetd não eram os serviços locais, mas os serviços de rede. O suporte para soquetes do tipo AF_UNIX vieram posteriormente em reimplementações. Essas funcionalidades não faziam de inetd uma ferramenta de paralelização ou tornavam as dependências desnecessárias.

Os serviços de inetd foram utilizados primeiramente para soquetes TCP, de modo que cada conexão entrante iniciava uma nova instância de um daemon. Esse comportamento não é a receita para servidores de alto desempenho. Entretanto, inetd também suportava outro modo, onde uma instância simples era lançada e aceitava conexões posteriores (com a opção de wait/nowait em inet.conf).

Essa era uma opção mal documentada, infelizmente. Daemons baseados em modo per-connection deram a Inetd uma má reputação de ser lento, o que de certa forma é injusto.

Paralelizando" Serviços de Barramento (BUS)

Daemons modernos no Linux tendem a prover serviços via D-Bus em vez de fazê-lo via soquetes AF_UNIX. Agora, a questão é: para esses serviços podemos aplicar a mesma lógica de paralelização em tempo de boot que propomos para os serviços baseados em soquetes? A resposta é: sim, nós podemos.

D-Bus já nos dá todos os ganchos (hooks) para isso. Usando a ativação por barramento um serviço pode ser inicializado na primeira vez que é acessado. A ativação por barramento nos dá o mínimo de sincronização por requisição, necessário para iniciar os provedores e os consumidores de serviços D-bus ao mesmo tempo. Por exemplo, se precisamos de Avahi como dependência de CUPS, podemos executar os dois ao mesmo tempo. E, se CUPS for iniciado primeiro D-Bus controla isso em uma fila até que Avahi esteja disponível.

Então, em resumo: a ativação de serviços baseada em soquete e baseado em barramento funcionam juntas para ativar TODOS os daemons em paralelo, sem qualquer necessidade de sincronização. Essa configuração permite atrasar a inicialização de serviços quando esse é raramente utilizado. E, se isso não é uma coisa grande, então eu não sei o que seria!

"Paralelizando" Atividades do Sistema de Arquivos

Se olhar para os processos de disco em tempo de boot, verá que a serialização e a sincronização gerada pelo start-up de vários daemons é grande. A maior parte desses gargalos vem de atividades como montagem, checagem, ajuste de quotas, etc. Durante o boot, muito tempo é perdido até que todos os dispositivos listados no arquivo /etc/fstab sejam ajustados.

Os serviços somente podem ser inicializados depois que essas atividades de disco terminaram. Podemos melhorar isso? Acontece que podemos. O programador Harald Hoyer [1] veio com uma ideia chamada autofs para melhorar isso. Do mesmo modo que uma chamada connect() mostra o serviço que está interessado em outro, uma chamada open() ou outra similar, mostra que serviço está interessado em determinado arquivo ou sistema de arquivos.

Então, a fim de melhorar podemos paralelizar e fazer esses aplicativos aguardar somente se o sistema de arquivos não estiver disponível. Fazemos isso configurando esses pontos de montagem em modo automático com autofs. Enquanto esse sistema de arquivos não está disponível, todo acesso será colocado em uma fila no kernel e os processos serão bloqueados para acesso somente a um único daemon. Desta forma, podemos inicializar daemons mesmo que ainda faltem sistemas de arquivos para serem montados.

Paralelizar atividades do sistema de arquivos e de serviços não faz sentido para o diretório raiz, já que todos os binários são armazenados nesta estrutura. Todavia, para partes da árvore como o /home, que usualmente contém muitos arquivos e é muito grande ou até mesmo criptografado, isso pode aumentar o tempo de boot consideravelmente. Ainda podemos mencionar que sistemas de arquivo virtuais como procfs ou sysfs não podem ser montados via autofs.

Eu não ficaria surpreso se alguns leitores acharem que a integração de algo como autofs com um sistema init poderia fragilizar ou fazer as coisas quebrarem mais facilmente. Posso afirmar que esse contorno funciona muito bem. Utilizar autofs onde as coisas simplesmente significam criar um ponto de montagem e sem ter que fornecer algo mais, funcionam bem.

Se a aplicação tenta acessar um sistema de arquivos em autofs e leva muito tempo para substituir a fila pelo sistema real, ele pode suportar uma interrupção, isso significa que você pode cancelar a requisição com segurança, via C-c.

Se o ponto de montagem realmente falhar (por falha real de disco) então dizemos para autofs retornar um código de erro e deixar tudo com o estado de limpo. Na prática autofs se mostrou uma excelente ideia quando implementado para a coisa certa e do modo certo.

Página anterior     Próxima página

Páginas do artigo
   1. Repensando o PID 1
   2. "Paralelizando" Serviços com Soquetes
   3. Mantendo o PID pequeno
   4. Upstart
   5. Juntando tudo com Systemd
Outros artigos deste autor

Configuração básica do Conky para mostrar informações sobre a sua máquina no Desktop

Programando em Qt

Criando um álbum de fotos no Linux

Navegando com privacidade com Tor e Firefox

Configurando servidor Samba como Workgroup no Slackware

Leitura recomendada

Conhecimento x Soberba

O software livre na administração pública

Convertendo MBR para GPT com gdisk

FAQ do SO GNU/Linux

Porque eu uso Linux Mint

  
Comentários
[1] Comentário enviado por bielinux em 20/01/2016 - 13:12h

Vendo este artigo,
dá até vontade de usar o systemd...
mas...
o Lennart Poettering é quem o desenvolve...
e o PulseAudio depois que foi "abandonado" por seu dono...
ficou melhor...
então...

É UMA CILADA, BINO!

[2] Comentário enviado por aldooliveira em 20/01/2016 - 15:37h

Interessante.

[3] Comentário enviado por MrBlackWolf em 20/01/2016 - 16:59h

Eu entendo o pé atrás de vocês com Lennart, vide o histórico do mesmo, mas vamos acompanhar de perto a evolução do systemd.

[4] Comentário enviado por sacioz em 20/01/2016 - 19:11h

Divertido ? Não sei , seguro ? Duvido , facil de manter ? Parece que não é ; léve ? não é . O que tem de gente irritada com esse systemd , não são poucos , e gente de peso na indústria .
Vamos ver . Eu estou usando sim , mas tão logo posso , saio dele pois segundo li , não é seguro . E segurança em computação é altíssima prioridade no meu livro . Quem estiver interessado procure por Devuan , a titulo de informação , talvez .
Vamos ver .

[5] Comentário enviado por removido em 20/01/2016 - 20:27h

O systemd pode até dar certo, mas o histórico de comportamento do Poettering como programador e (suposto) profissional mostra que o systemd só vai ficar decente de usar após a saída deste indivíduo da equipe de desenvolvimento do systemd.
Vide o caso do conhecido PulseAudio.
--------------------
Primeiro você se adapta ao Linux; depois, o Linux se adapta a você.

[6] Comentário enviado por removido em 20/01/2016 - 22:04h

Mesmo assim systemd incomoda.
O problema é com o software ou com o programador?
Prá mim são os dois.

----------------------------------------------------------------------------------------------------------------
http://24.media.tumblr.com/tumblr_m62bwpSi291qdlh1io1_250.gif

# apt-get purge systemd

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. — Edward Snowden

[7] Comentário enviado por Username em 23/01/2016 - 15:29h

Assange já havia dito que o Debian e derivados não era mais seguro.
E também é de se estranhar que a distribuição considerada a mais estável e segura e rigorosa de todas, passe a usar systemd de cara.
https://stallman.org/rms-assange-snowden.jpg

Não é trabalho do Linus ficar usando o kernel pra contornar os bugs não resolvidos do complexo systemd , a qual usa o kernel Linux de mula.
E tome cuidado Linus Torvalds , o Lennart Poettering não está trollando rsrs
http://i.imgur.com/h3t1MaS.jpg
Não duvido num apocaliptico futuro próximo passaremos a usar "GNU/Systemd"

O problema não é o systemd ter backdoor ou não, o qual tenho certeza que não tem . O problema é sua complexidade , a monopolização e sua suite, systemd é um init system inchado com a proposta de fazer muito mais além do que um simples init deveria fazer.
Vai enfraquecer a segurança no mundo Linux e facilitar a implementação de backdoor de terceiros no futuro.

edit: De acordo com o senhor Poettering Systemd is about "choice".
http://i.imgur.com/eZNwlMx.jpg

Poettering zueiro tirando uma onda com o projeto Devuan
http://i.imgur.com/cIkG0q9.png





[8] Comentário enviado por removido em 23/01/2016 - 20:49h

Não tem jeito. O pessoal só vai acreditar quando a m&rd@ estiver feita.

----------------------------------------------------------------------------------------------------------------
http://24.media.tumblr.com/tumblr_m62bwpSi291qdlh1io1_250.gif

# apt-get purge systemd

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. — Edward Snowden

[9] Comentário enviado por removido em 25/01/2016 - 21:24h

Concordo plenamente!
Systemd é complexo demais, quer fazer muita coisa ao mesmo tempo. Isso é contrário ao princípio KISS.
--------------------
Primeiro você se adapta ao Linux; depois, o Linux se adapta a você.

[10] Comentário enviado por Carlos_Cunha em 27/01/2016 - 02:41h

Muito bom artigo amigo, ja estou lendo.
Eu particularmente uso o Systemd e gosto, acho só falta as pessoas mais vontade de aprender a usa-lo, pois vejo mais reclamações do que acham do que de experiências e produção.


#-------------------------------------------------------------------------------------#

"Linux é algo que me fez ter Gosto pela Informática, se tornou um Vicio" - Carlos A. P. Cunha

[11] Comentário enviado por removido em 30/01/2016 - 11:45h

Notícia urgente: acabei de descobrir que LP se criou no Rio de Janeiro. Isto explica alguma coisa?
----------------------------------------------------------------------------------------------------------------
http://24.media.tumblr.com/tumblr_m62bwpSi291qdlh1io1_250.gif

# apt-get purge systemd

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. — Edward Snowden

[12] Comentário enviado por lcavalheiro em 10/02/2016 - 22:15h

Lennart Poettering. Que nenhuma voz alegre diga seu nome, e que nenhuma memória de sua existência seja preservada. Que nem as cinzas que ele toque sejam permitidas existir, e que o Limbo o engolfe e o engula e jamais o regurgite ou o defeque de volta. Que todo o software que ele toque seja esquecido e malogre bom funcionamento enquanto seu nome estiver associado a ele. Pois se essas são as justificativas de Lennart Poettering para algo como o systemd, então vê-se que ele não apenas deixa a lógica e o bom senso em casa quando vai programar como não os tem em momento algum. Após um texto longo, tudo que ele disse foi "systemd é bom porque ele inicializa a máquina mais rapidamente" - como se eu fosse desligar e religar meu computador a cada 30min.

Há um mérito menor para ele nesse texto. Ele fez uma análise não-ruim do PID 1. Mas não é uma análise boa, apenas uma não-ruim.

--
Dino®
[i]Vi veri universum vivus vici[/i]
Public GPG signature: 0x246A590B
Só Slackware é GNU/Linux e Patrick Volkerding é o seu Profeta

[13] Comentário enviado por albfneto em 11/02/2016 - 13:35h

Olha, muitas pessoas, inclusive eu, não gostam pq systemd é pesado, dificil de usar e muito instável... Eu uso no Sabayon pq não tem outra coisa, mas.... por exemplo, após atualizar meu KDE 5, cadê que o icone de desligar funciona, só no comando... dá erro de DBUS, UDEV e Polkit e timeout...]
é por causa do systemd... Muitos linux em DVD não dão mais boot em micros antigos e porque?
por causa do systemd etc... etc...
ele vai melhorar, claro que ele vai melhorar, tudo melhora... mas no momento...
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Albfneto,
Ribeirão Preto, S.P., Brasil.
Usuário Linux, Linux Counter: #479903.
Distros Favoritas: [i] Sabayon, Gentoo, OpenSUSE, Mageia e OpenMandriva[/i].

[14] Comentário enviado por removido em 12/02/2016 - 20:43h

Concordo plenamente com os comentários dos 2 especialistas acima:

- "Após um texto longo, tudo que ele disse foi 'systemd é bom porque ele inicializa a máquina mais rapidamente' - como se eu fosse desligar e religar meu computador a cada 30min." (lcavalheiro)

- "Muitos linux em DVD não dão mais boot em micros antigos e porque?
por causa do systemd (...)" (albfneto)

Eu possuo um computador antigo, bem modesto mas que ainda dá conta do recado (e muito bem). Já tentei usar diversas distros, mas praticamente só as que não tem o systemd deram boot... todas as outras falharam nessa simples tarefa.

Agora, eu pergunto também: pra quê eu quero um sistema que "dá boot depressa" apenas em computadores novos? Será que ele acha que todo mundo que usa Linux tem condições de comprar um PC novo (e jogar um computador funcionando no lixo... sim, no lixo) só pra continuar usando a distro que gosta porque o systemd não é capaz de inicializar em um computador mais antigo?
Claro que a solução mais óbvia é mudar de distro, sem dó nem piedade, e evitar o systemd até que as coisas melhorem...

Eu não quero um sistema operacional que dá boot depressa, eu quero um que funcione e me dê liberdade de escolher o que eu quero fazer com o meu computador!
--------------------
Primeiro você se adapta ao Linux; depois, o Linux se adapta a você.

[15] Comentário enviado por lcavalheiro em 28/02/2016 - 19:15h

Rapaz, tô longe de ser um especialista. Inclusive eu apenas citei o que Patrick Volkerding disse sobre esse texto do Lennart Poettering, citação essa com a qual concordo plenamente :-)
--
Dino®
[i]Vi veri universum vivus vici[/i]
Public GPG signature: 0x246A590B
Só Slackware é GNU/Linux e Patrick Volkerding é o seu Profeta


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts