Daemons, daemons e mais daemons init

Daemons, daemons e mais daemons init
Imagem ilustrando com os logos os vários initi systemd utilizados no Linux.
No vídeo "O que é daemon init?" eu mencionei que existem várias daemons init diferentes. porém mencionei no vídeo somente as (digamos) principais como a BSD, System V, o launchd do Mac OS X da Apple, o OpenRC do Gentoo, o Upstart do Ubuntu e o systemd.
O vídeo pode ser conferido logo abaixo:


Vale começar pela daemon init do NetBSD que, como mencionei no vídeo, o NetBSD migrou da init BSD para uma versão da System V que em sua diferença, não trabalha com runlevels e não possui ferramenta de gerenciamento de serviços (dentre outras coisas).

O Solaris possui o SMF (Service Management Facility = Facilidade de Gerenciamento de Serviço que também é baseada na SysVinit). Eu não sei hoje, talvez esse não seja mais o init do Solaris, mas ele é fortemente utilizado no IllumOS e no OpenIndiana. Agora, vamos a mais um monte de outros init systems.

Depinit é um init system alternativo que incorpora as ideias da sysVinit, do simpleinit, daemontools e do make que visa cuidar de processo paralelo (assim como o systemd e o launchd), dependências, roll-back, pipelines, melhorias no signaling e desmontar filesystems no desligamento (assim como o systemd possui recurso parecido). Falando em desmontar no desligamento, no dia 20 de agosto foi adicionado ao Systemd a ferramenta para montar filesystems . O interessante é o Depinit possui comando parecido com o systemctl do systemd chamado depinctl. Voltando ao Depinit, está sob licença GPLv2 e ainda está em fase experimental sendo disponível para Linux e FreeBSD. Sua ultima versão foi lançada em maio de 2014 (a versão 0.1.4).

InitNG tem como objetivo iniciar os processos em paralelo para reduzir o tempo de boot (assim como o systemd e o launchd... Mas já foi dito isso). Algo que foi inspirado no Mac OS X Tiger. Nele tudo é chamado em uma única ferramenta para gerenciar ciclo de vida ao invés de chamar múltiplos scripts que duplicam comportamentos similares. Li a algum tempo atras que a daemon InitNG tornou o Linux mais rápido (notaram como até mesmo a daemon init ou as outras daemons influenciam no desempenho do sistema operacional e não somente um filesystem? O InitNG está sob licença GPLv3 e recebeu uma pequena atualização há dois anos.

Runit é um init Unix de esquema Cross-platform com supervisão de serviço operando em três estágios obtidos em /etc/runit. Ela está disponível para Linux, FreeBSD, Mac OS X e Solaris e pode ser facilmente adaptada para outros Unixes. Os direitos autorais são reservados ao desenvolvedor da daemon. Hoje essa daemon é adotada pela distribuição Void Linux e tendo também suporte do Busybox.


eINIT é uma alternativa a implementação do /sbin/init para Linux e FreeBSD, mas parece que anda em decadência. apesar disso, é uma boa init para dispositivos embarcados e é bem modular. possui runlevels nomeados modes que é descrito em um arquivo XML a parece-se um pouco com a runlevel do Gentoo.

Pardus é a daemon init da distribuição Turka chamada Pardus. É uma versão paga do Linux pelo que me lembro de ter visto anos atrás. É difícil conseguir informações nesse site desde que não possui versão inglesa (parece que os caras não querem mais nenhum outro país por lá rsrs. Essa seria uma boa distribuição para entrar para os "50 lugares onde Linux está rodando e você nem faz ideia), mas essa init trabalha com um subsistema init chamada Mudur que é escrito em python e um sistema de gerenciamento de configuração chamado Çomar.

Epcoh é um init system para Linux na versão do kernel 2.6 projetado tendo como foco a facilidade na configuração e a não intromissão, ser pequeno para funcionar tanto em distribuições grandes e minimas. Esse init não possui dependências externas além da biblioteca C, dos pthreads do kernel e sugerido um /bin/sh funcional. Ele possui um sistema de logs para boot, runlevels em ASCII, um único arquivo de configuração conveniente; recursos automáticos como hostname e montagem do sistema de arquivos virtual (como o /proc) e é em vários outros recursos.
 Vale a pena conhecer esse init system:
minit é uma daemon (ainda em versão beta) feita na Alemanha por Felix von Leitner, mesmo criador da dietlibc e do embutils, que além de visar ser minuscula (característica típica do Felix e que faz isso muito bem) também visa corrigir alguns erros cometidos pelos init systems tradicionais no Linux. Se quiser saber mais sobre a diet libc e do embutils, assista o vídeo abaixo:

 Como descrito  no documento de sua palestra na Linux Kongress de 2004 que:
  • O processo de boot das tipicas distribuições Linux é muito sofrido
  • Se um boot script falhar, todo o processo de boot é interrompido
  • Se um serviço for interrompido via o comando kill, ele não é automaticamente reiniciado (se tornando um processo zumbi)
  • O script de shutdown não sabe qual o PID da daemon (modos de falhas horriveis onde você acidentalmente mata o processo errado)
  • E a falta de flexibilidade (iniciar mais um ou um serviço a menos?).
 No minit, cada serviço possui seu próprio diretório dentro de /etc/minit contendo dependências e dentre outros recursos. Dentre os problemas a serem solucionados pelo minit estava o de reduzir o período de downtime (que é também uma das ideias do systemd).

jinit também desenvolvida na Alemanha e também competidos do minit, trabalha utilizando seu próprio filesystem baseado em esquema de serviço e é escrita em C++. Ainda não é muito bem testada.

Existe também por exemplo a Twsinit que é desenvolvido em Assembly, é bem pequena (exige somente coisa de 8k de memória) e ser uma substituição das atuais; a do Fedora chamada FCNewInit a Serel que também foca em acelerar o boot.

 Moral da história é que acelerar o boot, reduzir o shutdown melhorando assim o uptime e solucionar os problemas gerados pelos scripts já é um desejo antigo. A maioria das aqui mencionadas focaram esforços para poder trazer essas soluções. Criticar o systemd então se torna somente uma questão de birra.

 Bom, acho que está bom o tamanho da lista. Vale mencionar (mais uma vez, assim como mencionado no vídeo "O caso Systemd") que do Systemd surgiu o fork UselessD, mas que não conseguiram atingir o seu objetivo proposto.


busybox remove suporte ao Systemd:


Fico por aqui, espero ter agregado  mais conhecimento,forte abraço e falow.

Analista (bilíngue) de sistemas, redator do blog Diolinuxtradutor da distribuição Funtoo e parte da distribuição IPFire, do manual chamado Caixa de Ferramentas do UNIX e do manual Zsh Lovers. Dono dos canais e blogs Toca do Tux e Resenha Nerd:

Compartilhe isso

Leia outros posts

Próximo post
« Próximo post
Post Anterior
Próximo Post »