 |
Daemons, daemons e mais daemons (init). |
No vídeo "O que é daemon init?" eu mencionei que existem várias daemons init (ou init systems) diferentes disponíveis. porém mencionei somente as (digamos) mais populares como o rc (run command) do Unix mais ou menos na versão 10 e que foi herdado pelos BSDs e pelo slackware, o SystemV (ou sysvinit que introduziu o conceito de runlevels que é uma especificação declarativa de serviço de sistema). O holandês Miquel van Smoorenburg é o autor da versão do sysvinit para Linux. Miquel fez também o primeiro port do Debian para a arquitetura Alpha e tem como símbolo um Tux bebinho de tudo).
 |
| Tux de Miguel Van Smoorenburg |
O launchd do Mac OS X, o OpenRC originado no Gentoo, o Upstart originado no Ubuntu e o systemd originado no Fedora. O vídeo pode ser conferido logo abaixo:
Então por que não debater sobre outros init systems diferentes? Vale começar pelo NetBSD que, como mencionei no vídeo, o NetBSD migrou da init BSD para uma versão da SystemV.
O Solaris possui o SMF (Service Management Facility = Facilidade de Gerenciamento de Serviço que também é uma das inspirações para a criação do systemd). Esse init system faz uso de arquivos XML ao invés de init scripts, é utilizado no IllumOS (já que é um fork do antigo OpenSolaris) e no OpenIndiana que é uma distribuição derivada do IllumOS. Agora, vamos a mais um monte de outros init systems.
Plan9 rc
Quero começar com rc específico do Plan9 (não confunda com o rc dos BSDs e do Slackware) que é um shell que soluciona o problema de white space que ocorrem em outros shell no padrão POSIX (como o bash). O que acontece é que os scripts de outros shells quebram caso os nomes dos arquivos possuam espaço como no exemplo:
for i in *.jpg; docp $i /tmpdone
Já o plan9 rc lida com esse problema utilizando um recurso chamado Free Carets inserindo o operador ^ automaticamente entre as palavras. O Plan9 rc possui sintax diferente mas um exemplo de como ele soluciona o problema pode ser conferido abaixo:
for (i in *.jpg) {cp $i images}
Outros shells como o fish e o zsh também possuem respostas para esse problema porem o rc faz isso de forma mais simples. O plan9 rc está disponível no plan9port (port do user space do plan9 para os Unix) e existem re-implementações do plan9 rc como a re-implementação independente do Plan 9 rc de 1992 para Unix e também a uma iplementação na linguagem Hare.
É um init system alternativo que incorpora as ideias da sysVinit, do simpleinit, do 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 é que o Depinit possui comando parecido com o systemctl do systemd chamado depinctl. O 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 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.
É possível utilizar runit sem substituir o atual init system que estiver utilizando em sua distribuição simplesmente executando o stage 2 do runit como um serviço do seu atual init.
eINIT
É uma alternativa a implementação do /sbin/init para Linux e FreeBSD, mas parece que anda em decadência. Apesar disso, é um bom 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.
É um init system para Linux na versão do kernel 2.6. Foi 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 vários outros recursos. Vale a pena conhecer esse init system:
minit
É uma daemon (ainda em versão beta) feita pelo alemão Felix von Leitner, mesmo criador da dietlibc e do embutils. 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 típicas 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 horríveis 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).
cinit
cinit é um init system com recursos de dependência e suporte a perfil que foi baseado no design no minit. Devido o minit não possuir suporte a dependências reais (o que leva a você não saber se o serviço que você depende foi realmente iniciado) e seu conceito de dependência ser lento, o suíço Nico Schottelius para suprir estas necessidade.
O cinit possui características semelhantes ao systemd: parallel execution; profile support que além de serem fáceis de criar você ainda pode especificar quais serviços iniciar (o que me lembra o conceito de units do systemd).
sinit (11/05/2022)
sinit (suckless_init) é um init system baseado no minimal init (clique aqui para conferir) criado por Rich Felker (criador da bliblioteca Musl muito abordada aqui no blog). Foi criado com a intenção de integra-la ao Busybox em um experimento (confira aqui). O sinit está sob a MIT/X Consortium License e existe um manual introdutório ao sinit que pode ser conferido aqui.
dinit
dinit é desenvolvido por Davin McCall, um ex contribuidor do kernel Linux e do Mesa driver. Assim como cinit e o runit, o dinit foi desenvolvido para ser integrado a outros ao invés de substituí-los (apesar que runit ainda permite substituir outros init systems). dinit é utilizado no Chimera Linux e é uma das várias escolhas do Artix Linux.
jinit
Também desenvolvida na Alemanha, trabalha utilizando seu próprio filesystem baseado em esquema de serviço e é escrita em C++. Ainda não é muito bem testada.
s6 é descrito como um pequeno conjunto de programas para UNIX, projetado para permitir supervisão de processos (a.k.a service supervision), na linha do daemontools em conjunto com runit, assim como várias operações em processos e daemons. As ferramentas do s6 são independentes que podem ser utilizadas com ou sem framework e podem ser agrupadas.
O s6 é o init system padrão da distribuição Glaucus. A skarnet disponibiliza também o s6-linux-utils que faz parte do ecossistema s6 e é utilizada para criar init system baseado no s6 no kernel Linux. É possível também ter um s6-linux-utils multicall.
66
Foi desenvolvido para a distribuição ObaRun, um fork da distribuição Arch desenvolvida por um anônimo como uma alternativa ao systemd. Na verdade o 66 é um fornecedor de gerenciamento de serviços para o s6 e não um init system em si.
rinit
Esse é um init e gerenciador de serviços escrito na linguagem Rust por Danilo Spinella, um desenvolvedor italiano da Suse inspirando-se no 66, no s6 (já mencionado anteriormente) e no daemontools mencionado a seguir. Ainda é um trabalho em progresso e o autor descreve que você o utiliza por conta e risco. Inicialmente se chamava tt e era escrito em C++. Possui uma sintaxe muito parecida com a do systemd. Está sob licença GPL3+, o que eu acho uma bela de uma burrice.
tt
Também desenvolvido por Danilo Spinella o tt é um gerenciador de serviço init também inspirado no 66, s6 e no deamontools, para substituir o systemd mas oferecendo melhor base de código que o 66. A ideia é realmente reescrever o 66 já que este possui muitos bugs difíceis de serem corrigidos. A princípio parece que iria ser escrito na linguagem porém, em seu github vamos que é escrito na linguagem C++.
daemontools e nosh
As próximas não são init systems. Na verdade se tratam de ferramentas que servem como auxiliares de init systems. A daemontools foi desenvolvida por Dan Bernstein como uma coleção de ferramentas para o gerenciamento de serviços de sistemas operacionais da família Unix (eles iniciam o serviço e o reiniciam caso ele morra. Parecido com o que temos no systemd). Esta ferramenta é fortemente utilizada em conjunto com o runit e o minit. Do daemontools surgiu um derivado chamado daemontools-encore que adiciona várias melhorias e mantendo compatibilidade entre ambos.
Nesse meio ainda temos o nosh que tem a mesma função que o daemontools. nosh foi desenvolvido originalmente para suprir a falta de opções que os BSDs não possui como as do launchd, systemd e do upstart. A equipe do nosh queria algo mais do que outras daemontools oferecem.
No meio disso, parece que teremos em breve algo similar no toybox que hoje traz os comandos init e oneit.
A ultima que eu gostaria de mencionar é a perp (abreviação de "the perpetrator"). Infelizmente, sua ultima versão foi em 2013.
sninit
sninit é uma pequena implementação para Linux que visa ser um substituto para o systemV sendo mais limpo e mais confiável, fornecendo melhor controle de processos removendo a necessidade de init scripts. Também é menor que o systemd para distribuilções que dependam do comando systemctl. O projeto sinit foi concluído sendo agora a continuidade no minibase.
Procd
procd é a daemon do OpenWrt sistema operacional Linux que utilizamos em nossos roteadores escrito em C. Ele mantem rastreio de processos iniciados a partir de seus init scripts (via ubus calls), e pode suprimir solicitação de inicialização/reinicialização de serviço redundante quando o ambiente de configuração não for alterado.
Conclusão
No Linux, tudo é uma questão de escolha. Não quer utilizar uma interface gráfica, você utiliza outra; não quer utilizar um terminal, utiliza outro. O mesmo vale para sistema de arquivos, gerenciadores de pacotes tanto de baixo quanto de alto nível, empacotamentos e todos os tipos de ferramentas, inclusive init systems. Isso é OS VÁRIOS SABORES DE LINUX.
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 e Serel que também foca em acelerar o boot. 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.
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. E no meio de um oceano repleto de init systems, o inútil debate criticando o systemd continua até hoje. Como sempre, os argumentos são os mesmo e os piores imagináveis:
"ele não é portável", "ele é incompatível com init scripts" (o que não é verdade), "Ain, logs binários", "systemd faz muitas coisas, isso é contra a filosofia", "systemd é uma ameaça ao sistema operacional", "vou contar para a minha mãe"...
E porque ficar com essas discussões se temos a liberdade de adotar o que quisermos? ISSO É LIBERDADE DE VERDADE. Por que o systemd deveria ser portável se outros init systems já são? Alias por que criticar o systemd sendo que outros já tentaram implementar os mesmos recursos? Não quer utilizar o systemd? Neste artigo está um catalogo bom para você desfrutar; basta partir para os estudos.
Fico por aqui, espero ter agregado mais conhecimento. Forte abraço e até a próxima.
Nenhum comentário:
Postar um comentário
Viu algum erro e quer compartilhar seu conhecimento? então comente aí.
Observação: somente um membro deste blog pode postar um comentário.