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.467 ]

Por: Perfil removido em 20/01/2016


Juntando tudo com Systemd



Expliquei antes o que acredito que um sistema init deveria fazer e vimos o que os sistemas atuais fazem. Tudo que sugeri como características e requisitos para um sistema de inicialização ideal estará disponível em systemd. Tudo ainda é muito experimental (escrito em 2010) mas o código já está disponível. Vejamos algumas características:

Systemd inicia e supervisiona o sistema inteiro. Ele implementa todas as características apontadas acima e até um pouco mais. Systemd é baseado na noção de Unidades (Units). Uma unidade tem um nome e um tipo. As unidades são armazenadas no sistema de arquivos com nomes como: avahi.service. A leitura desse arquivo faz a configuração de um serviço de mesmo nome. Existem vários tipos de Unidades:

1. serviços - Essa é unidade mais óbvia. Daemons são iniciados, parados, reiniciados, recarregados, etc. Procuramos manter compatibilidade com SysV e podemos ler scripts clássicos presentes em /etc/init.d se eles tiverem um cabeçalho LSB.

2. soquetes - Essa unidade encapsula um soquete no sistema de arquivos ou na Internet. São suportados AF_INET, AF_INET6, e AF_UNIX do tipo stream, datagrama ou pacotes sequenciais. Também suportamos FIFOs clássicos como meio de transporte. Cada tipo de soquete está associado a um serviço. Por exemplo, um soquete nscd.socket inicia nscd.service em uma conexão de entrada.

3. dispositivos - Essa unidade encapsula um dispositivo da árvore de dispositivos Linux. Se um dispositivo é marcado via regras de udev, ele será exposto como uma unidade do tipo dispositivo em systemd. Propriedades configuradas por udev podem ser utilizadas como fonte para definir dependências para esses dispositivos.

4. ponto de montagem - Essa unidade encapsula um ponto de montagem na hierarquia do sistema de arquivos. Systemd monitora todos os pontos de montagem a partir de onde eles vem e para onde eles vão. Além disto, essas unidades podem ser utilizadas para montar ou desmontar esses pontos. O arquivo em /etc/fstab é utilizado como uma fonte adicional de configurações para esses pontos de montagem.

5. automount - Essa unidade encapsula pontos de montagem automatizados. Cada unidade automount possui uma unidade mount correspondente. Isso faz com que esse ponto seja montado tão logo seja acessado.

6. target - Essa unidade é utilizada para agrupamento lógico de unidades. Essas unidades não fazem nada por si só. Elas são referências para grupos de unidades que podem ser controladas em conjunto. Por exemplo, podemos ter um alvo chamado multi-user.target que corresponde a um conjunto de regras do SysV necessárias para levar o sistema para o nível de execução 5 (runlevel 5).

7. snapshot - Similar a target. São utilizados para salvar/reverter o estado de todos os serviços e unidades. Por exemplo, se houver necessidade de entrar em um estado de emergência (Shell de manutenção ou runlevel 1), todos os serviços precisam ser encerrados. Após o término da manutenção o estado anterior precisa ser restaurado.

O mesmo serve para um sistema que entrou em estado de suspensão. Todas essas unidades têm dependências entre si (requerimentos e conflitos). Por exemplo, um ponto de montagem como /home/lennart implicitamente possui uma dependência que é a montagem de /home. Vejamos uma curta lista dessas características:
  1. Para cada processo instanciado, você pode controlar: o ambiente, os recursos, os diretórios de trabalho e o raiz, a máscara de arquivos, o nível de gentileza, a prioridade e a classe de I/O, a política de uso e afinidade de CPU, o id de usuário e de grupo, o acesso ao sistema de arquivos e várias outras coisas. Você pode fazer coisas como conectar em stdin/stdout/stderr, serviços como syslog, /dev/kmsg ou ttys arbitrárias.
  2. Cada processo executado possui seu próprio cgroup e ele é fácil de configurar com systemd para colocar serviços nesses grupos configurados externamente. Por exemplo, através de utilitários libcgroups.
  3. A configuração nativa usa uma sintaxe que segue de perto padrões do tipo ".desktop".
  4. Como mencionado, systemd fornece compatibilidade com scripts SysV. Tiramos vantagem de cabeçalhos LSB ou chkconfig (Red Hat) se disponíveis. Se essas opções não estão disponíveis nós tentamos fazer o melhor com as informações disponíveis, tais como as prioridades iniciais em /etc/rc.d. Esses scripts são considerados uma fonte alternativa de informações. Opcionalmente podemos ler arquivos clássicos de PID para identificar um serviço. Note que fazemos uso de informações do cabeçalho LSB e traduzimos isso como dependências nativas em systemd.
  5. De modo similar, lemos a configuração em /etc/fstab e consideramos os dados como outra fonte de informações. A opção comment= em fstab torna suas entradas automaticamente controladas por systemd.
  6. Quando uma unidade possui múltiplas fontes de configuração (por exemplo, /etc/systemd/system/avahi.service e /etc/initd.avahi) a configuração nativa terá precedência, o formato legado é ignorado, permitindo atualizar caminhos e pacotes para continuar usando scripts SysV e serviços systemd por um tempo.
  7. Suportamos um mecanismo de templates e instâncias simples. Exemplo: Em vez de termos seis arquivos para configurar seis gettys, temos apenas um único getty@.service que usamos para instanciar getty@tty2.service e afins. A interface pode ser herdada pelas dependências.
  8. Suportamos a compatibilidade completa com o modo tradicional de inetd para ativação de soquetes. Temos um modo simples de imitar a ativação por soquete de launchd e recomendamos esse modo para novos serviços. O modo inetd somente permite passagem de um soquete para o daemon started, enquanto o modo nativo suporta a passagem arbitrária de números do arquivo de descritores. Suportamos uma instância por conexão, assim como uma instância para todos os modos de conexão. No modo antigo nomeamos o daemon que será inicializado em um cgroup, após os parâmetros de conexão, e utilizamos a lógica de templates mencionada anteriormente.
  9. Provemos compatibilidade com /dev/initctl para certas extensões. Implementada através de um FIFO ativado por serviço, que simplesmente traduz essas requisições legadas para D-Bus. Na prática, coisas como o antigo shutdown, poweroff e comandos similares em Upstart e sysvinit agora estão em systemd.
  10. Provemos compatibilidade com utmp e wtmp. Acreditamos que fizemos melhor que o modo original destas funções.
  11. Systemd suporta diversos tipos de dependências entre unidades. A ordem como as unidades são alteradas pode ser ajustada com After/Before. Isso é completamente ortogonal e exige que um requerimento positivo seja expressado como algo mandatório ou facultativo. Então, quando há um conflito ele é expresso na forma de uma dependência negativa. Existem outros três tipos de dependências que são pouco utilizadas.
  12. Systemd lida o mínimo possível com transações. Se uma unidade é requisitada para inicializar ou encerrar ela será adicionada e suas dependências são transações. Então, verificaremos se as transações são consistentes.
  13. Gravamos o tempo de execução (start/exit), o PID e o estado de saída de cada processo que inicializamos e supervisionamos. Esses dados podem ser cruzados com dados de daemons em abrtd, autid e syslog.
  14. Suportamos a reexecução do Init a qualquer tempo permitindo upgrades sem reboot.
  15. Iniciamos um trabalho para eliminar shell script do processo de boot. Acreditamos que o sistema possa ser inicializado em C e depois movido para systemd.
  16. O estado do servidor será monitorado por D-Bus.
  17. Damos enfase na ativação baseada em soquete e bus-name, deste modo suportamos dependências entre soquetes e serviços, e entre serviços.
  18. Quando um processo é inicializado por systemd, isso pode ser confirmado com systemd.confirm_spawn=1 na linha de comando.
  19. Usando systemd.default= na linha de comando, seus parâmetros pessoais podem ser definidos em tempo de boot.
  20. Há uma interface para inicializar/parar serviços. Seu nome é systemadm.

Você deve que sytemd utiliza muitas características que são únicas no Linux, e não é limitada a POSIX. Isso destrava uma série de funcionalidades dentro de um sistema que é projetado para a portabilidade, mas outros sistemas não podem prover essas funcionalidades.

NT: Essa tradução busca entender o espírito do texto de Lennart. Se precisa das palavras exatas procure o texto original. Não emita comentários baseados nessa tradução, ela não é precisa o suficiente para permitir isso.

[1] - https://en.wikipedia.org/wiki/Harald_Hoyer

Página anterior    

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

Sudo 1.8.12 - Parte I - Manual

Quem disse que micro velho não presta?

Trabalhos gráficos no Biglinux

Cafe Con Leche (Gerenciador de Lan House e Cyber Café)

Linux ou Windows? Eis várias questões

Leitura recomendada

Software Livre - GNU x LPG e o Governo x Economia (parte 2)

Onde o GNU/Linux ganha de lavada do Windows

Análise de projetos de instituições públicas que adotaram o uso do Software Livre e suas vantagens

Certificações Novell para Linux

Viva o Linux 2008 - Site com cara e recursos novos!

  
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