Systemd, onde mora ? onde vive ? o que faz ?

Systemd, onde mora ? onde vive ? o que faz ?

   16:46       Keep Linux World

---

Fala Rapazeada !

O blog acabou parando totalmente, muito trabalho, correria, namorada louca atrás (kkk).

Mas estamos de volta, e dessa vez não pretendemos parar com o Blog.




Nesse artigo pretendo explicar um pouco pra galera sobre as dificuldades que vários vêm tendo com as novas versões do Fedora e derivados depois da implementação do systemd no lugar do "morto" initd.

Vou levar em consideração que vocês já saibam as diferenças básicas entre os dois "gerenciadores" do sistema.

Um exemplo dessas dificuldades é entender que o systemd tem uma filosofia de usar os "cgroups" que o kernel do linux proporciona e não eram utilizados, que consiste em "agrupar" grupos de serviços em um pacote só, um exemplo é que seria possível agrupar todos os "daemons" de bancos de dados em um único pacote para o systemd:

* mysqld
* pgsql

Criaria-se o DB.service que possui os dois processos de incialização dos dois bancos de dados em um só.

Pelo menos foi isso que consegui abstrair das loucuras do systemd, corrijam-me caso eu esteja errado.

O sistema initd (UPSTART/SYSTEMV) não resolve(via) certos conflitos que o Linux (kernel) não tratava por sí próprio, como processos "virando zumbis" e consumindo recursos da máquina sem necessidade.

Acaba sendo aquela velha história:   O processo cria um processo que acabou criando outro processo que teve 3 "processinhos". Alguém se debanda uma hora nesse rolo todo e fica vagando pelo vasto universo negro, sem nenhum vínculo para voltar pra casa.

 O systemd entra para colocar um fim à essa história e vincular todos os "mini-processos" criados à partir do "processo pai" através dos Control Groups (cgroups). Logo, quando o processo do mysql é finalizado, tudo o que foi criado à partir dele é finalizado junto, sem deixar zumbis para trás iniciando o apocalipse dos recursos computacionais.

Para quem "nasceu" no initd e viveu o suficiente para ver o systemd entrar em ação é complicado compreender e derrubar alguns conceitos que antes eram leis.

Outra questão é que as intruções de inicialização do sistema initd (upstart/systemv) eram (são) scripts shell customizados, que poderiam ter falhas, ou dependendo da distribuição, eram totalmente alterados e isso, vai por mim, gera(va) vários conflitos f*didos quando você fazia update ou instalação de um pacote a partir repositório não homologado pela distro.

A ideia do systemd é eliminar totalmente os scripts shell por isso.

A maioria dos serviços abre sockets para receber pedidos de seus clients.
O X, por exemplo, cria um socket UNIX em forma de arquivo no /tmp.
O que o systemd faz é criar todos os sockets dos serviços que controla (eles estão descritos nos arquivos de configuração de cada serviço [unit]) e, quando recebe uma conexão, inicia o serviço e passa pra ele o socket.

O interessante dessa solução é que ela estabelece a relação de dependência entre socket e serviço: o serviço é iniciado quando alguém pede, e garante que os clients que forem iniciados vão ter seu primeiro request atendido, não há mais o problema de não saber, de fato, quando o serviço está plenamente ativo.

Vlw ! Até o próximo post !