 |
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 a BSD, SystemV (ou simplesmente sysvinit que introduziu o conceito de runlevels (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.
É 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, o runit foi desenvolvido para ser integrado a outros ao invés de substituí-los (apesar que runit ainda permite substituir outros init systemsd). dinit é utilizado no Chimera Linux é 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.
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.
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.
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.
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.
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.
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"... O porque ficar com essas discussões se temos a liberdade de adotar o que quisermos? ISSO É LIBERDADE DE VERDADE. Por que o systemd deveria seguir os padrões de outros init systems sendo que já existem muitos dentro do mesmo padrã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.