O que um software como o systemd faz \u00e9 dar prosseguimento aos processos de boot assim que o kernel, por meio do initramfs (ou initrd, dependendo da distro), carrega o hardware da m\u00e1quina e, em seguida, invoca o gerenciador para carregar o sistema operacional e respectivos servi\u00e7os.<\/p>\n
Nota: a explica\u00e7\u00e3o acima foi bem superficial, pois muitas outras coisas acontecem durante os poucos segundos entre apertarmos o bot\u00e3o Power e digitarmos o login de acesso \u00e0 \u00e1rea de trabalho. A quest\u00e3o \u00e9 que o sistema de inicializa\u00e7\u00e3o entra em cena somente ap\u00f3s o kernel concluir a sua fun\u00e7\u00e3o.<\/i><\/p>\n
Como vimos nos artigos anteriores, ainda que brevemente, h\u00e1 diferentes sistemas de inicializa\u00e7\u00e3o para Linux. O systemd \u00e9 mais robusto (complexo, seguro e cheio de recursos) e utilizado na maioria das distribui\u00e7\u00f5es na atualidade, mas, at\u00e9 pouco tempo atr\u00e1s, o Linux geralmente rodava com Upstart ou SysVinit.<\/p>\n
![\"processo](\"https:\/\/e-tinet.com\/wp-content\/uploads\/2019\/11\/processo-de-boot-linux.jpg\")
<\/p>\n
Ent\u00e3o o systemd reina de forma absoluta? Para responder a essa pergunta, reuni os seis principais sistemas para gerenciamento do processo de boot do Linux, incluindo o pr\u00f3prio systemd e seus antecessores. Vamos l\u00e1?<\/p>\n
1. Systemd<\/b><\/h2>\n
Caso ainda n\u00e3o tenha lido os Sem atropelar etapas, vamos a um resumo da sua hist\u00f3ria: com o primeiro c\u00f3digo lan\u00e7ado em 2009, o systemd \u00e9 um projeto encabe\u00e7ado por Lennart Poettering. Desde o in\u00edcio, o intuito dos desenvolvedores foi criar um mecanismo que se tornasse padr\u00e3o nas principais distribui\u00e7\u00f5es do Linux.<\/p>\n Devido \u00e0 vasta gama de funcionalidades \u2014 a qual \u00e9 alvo de cr\u00edticas de muitos desenvolvedores que procuram por algo mais simplificado \u2014, muitos projetos grandes passaram a adot\u00e1-lo, tais como:<\/p>\n O Ubuntu, por exemplo, que inicialmente resistiu com o Upstart, migrou para o systemd em 2015 (ver. 15.04 da distro). Outra distro importante, o Slackware ainda n\u00e3o o utiliza como init padr\u00e3o, por\u00e9m a ideia j\u00e1 est\u00e1 em fase de experimenta\u00e7\u00e3o (vide projeto Dlackware<\/a>).<\/p>\n Entre todas as suas vantagens e caracter\u00edsticas, o fator determinante para o sucesso do systemd foi a sua capacidade de se adaptar a novas tecnologias. Considerando que a tend\u00eancia \u00e9 a integra\u00e7\u00e3o constante de dispositivos, o systemd oferece os meios necess\u00e1rios para que ela seja realizada com sucesso no Linux.<\/p>\n Por fim, outros motivos que favorece a escolha pelo systemd s\u00e3o: a compatibilidade com os scripts do SysVinit e do padr\u00e3o LSB, detalhe que facilita a sua customiza\u00e7\u00e3o; a agilidade para carregar os servi\u00e7os paralelamente; e o gerenciamento pr\u00e1tico a partir dos utilit\u00e1rios que acompanham o gerenciador.<\/p>\n Para mais informa\u00e7\u00f5es sobre o systemd, s\u00f3 ler os artigos dispon\u00edveis aqui no blog.<\/i><\/p>\n Agora vamos ao cl\u00e1ssico SysVinit. Esse gerenciador de sistema \u00e9 utilizado no Linux desde as suas primeiras distros e manteve-se padr\u00e3o durante muitos anos. A hegemonia, no entanto, converteu-se em obsolesc\u00eancia na medida em que novas solu\u00e7\u00f5es vinham \u00e0 tona.<\/p>\n O SysVinit, assim como os demais programas, trabalha com n\u00edveis de execu\u00e7\u00e3o (runlevels). O que \u00e9 isso? Basicamente, trata-se de um esquema classificado de 0 a 6, onde cada um dos sete n\u00edveis carrega um conjunto de servi\u00e7os a serem executados ou finalizados pelo sistema.<\/p>\n Cabe frisar que os runlevels variam de acordo com o gerenciador, embora a estrutura seja quase sempre similar entre eles. No caso do SysVinit, os n\u00edveis s\u00e3o:<\/p>\n Conforme o usu\u00e1rio seleciona um dos n\u00edveis descritos acima, o SysVinit faz a leitura do arquivo script correspondente \u00e0 op\u00e7\u00e3o (exemplo: \/etc\/rc1.d para monousu\u00e1rio), que guarda todas as configura\u00e7\u00f5es \u2014 ou seja, cada servi\u00e7o que deve ser inicializado.<\/p>\n O modo de funcionamento que expliquei acima funcionou muito bem, mas ele acabou limitando o ciclo de vida do SysVinit, pois tornou-se pouco eficiente perante a evolu\u00e7\u00e3o da Tecnologia da Informa\u00e7\u00e3o. Entre os pontos fracos do gerenciador, o maior deles era o m\u00e9todo de execu\u00e7\u00e3o.<\/p>\n Diferentemente dos programas utilizados atualmente, o SysVinit carrega os servi\u00e7os um por um, seguindo a ordem que consta nos scripts. Isso gera, entre outros problemas, muita lentid\u00e3o para que o sistema operacional fique pronto para uso. \u00c9 algo inconceb\u00edvel na era digital.<\/p>\n Mesmo que o SysVinit seja invi\u00e1vel na maioria dos casos \u2014 se j\u00e1 n\u00e3o foi substitu\u00eddo em todos os projetos \u2014, os seus scripts ainda podem ser aplicados em outros gerenciadores.<\/p>\n Lan\u00e7ado em 2006, o Upstart foi um dos primeiros projetos criados com o prop\u00f3sito de mudar o processo de boot do Linux. Como eu disse no primeiro t\u00f3pico, ele foi padr\u00e3o nos sistemas Ubuntu por um determinado per\u00edodo; o porqu\u00ea da resist\u00eancia em mant\u00ea-lo se resume ao fato de que a Canonical era quem desenvolvia ambas as solu\u00e7\u00f5es.<\/p>\n Entretanto, o Upstart tem um importante diferencial que \u00e9 a execu\u00e7\u00e3o em resposta a eventos. Em outras palavras, n\u00e3o h\u00e1 sequ\u00eancia fixa de servi\u00e7os a serem carregados, como no SysVinit; em vez disso, cada trabalho especifica os eventos que reagir\u00e3o a ele, e o Upstart, paralelamente, inicia todos os servi\u00e7os correspondentes aos eventos.<\/p>\n Na estrutura do Upstart existem os j\u00e1 mencionados trabalhos (jobs). Cada job se subdivide em task jobs e service jobs, sendo o primeiro um processo que realiza uma tarefa espec\u00edfica quando acionado e, depois, fica em espera. Por sua vez, um service job s\u00e3o os pr\u00f3prios servi\u00e7os iniciados \/ encerrados manualmente ou por um evento.<\/p>\n Logo, sendo o Upstart um gerenciador reativo (no caso, que responde a eventos em tempo real), significa que ele n\u00e3o trabalha com n\u00edveis de execu\u00e7\u00e3o<\/b>, ainda que haja compatibilidade com scripts do SysVinit \u2014 eles foram inclu\u00eddos no projeto no intuito de assegurar que a transa\u00e7\u00e3o para o Upstart ocorresse gradualmente.<\/p>\n O modo como funciona o Upstart \u00e9 diferenciado e, de fato, muito interessante, mas, infelizmente, a Canonical n\u00e3o pretende desenvolv\u00ea-lo. Hoje, o projeto segue dispon\u00edvel com prop\u00f3sitos de manuten\u00e7\u00e3o, visto que ainda h\u00e1 distribui\u00e7\u00f5es com suporte ativo que usam Upstart.<\/p>\n Desenvolvido pela equipe do Gentoo, o OpenRC \u00e9 um init que surgiu em 2007 com o prop\u00f3sito de trazer simplicidade, portabilidade e agilidade. Ele \u00e9 o gerenciador preferido de boa parte dos programadores que necessitam de solu\u00e7\u00f5es menos robustas (leia-se systemd), mas excelentes para o que se disp\u00f5em a fazer.<\/p>\n Fazendo uma analogia pouco inspirada, o OpenRC, comparado ao systemd, \u00e9 como um forasteiro minimalista que se concentra em sobreviver (e faz isso como ningu\u00e9m) diante de um cidad\u00e3o urbano, que estuda, trabalha e faz diversas outras tarefas muito bem, mas vive numa rotina complexa.<\/p>\n At\u00e9 pelas caracter\u00edsticas relativamente simples, assemelhando-se ao SysVinit, podemos considerar o OpenRC um dos sucessores mais bem sucedidos do tradicional gerenciador, ou at\u00e9 mesmo a evolu\u00e7\u00e3o natural dele restrita a executar os servi\u00e7os a partir de scripts \u2014 inclusive, o OpenRC \u00e9 oferece suporte aos scripts do SysVinit.<\/p>\n Em contrapartida, o ponto fraco do OpenRC \u00e9 a supervis\u00e3o, que deixa muito a desejar em rela\u00e7\u00e3o a outros gerenciadores. Nele, se determinado servi\u00e7o n\u00e3o \u00e9 iniciado ou encerrado, o usu\u00e1rio \u00e9 apenas informado disso. Se o processo permanece inativo ou travado \u00e9 necess\u00e1rio inici\u00e1-lo \/ encerr\u00e1-lo manualmente.<\/p>\n Uma das capacidades mais legais do OpenRC \u00e9 a possibilidade de alternar a inicializa\u00e7\u00e3o para responder a eventos, como o Upstart. S\u00f3 n\u00e3o chega a ser uma vantagem e tanto porque o suporte \u00e9 limitado \u2014 n\u00e3o podemos nos esquecer de que ele foi projetado para ser simples.<\/p>\n Outras caracter\u00edsticas e recursos em destaque s\u00e3o a compatibilidade com Linux, FreeBSD e NetBSD, o registro de mensagens emitidas pelo OpenRC e servi\u00e7os iniciados por meio dele, e a quantidade significativamente menor de desafios para aprendizado.<\/p>\n Um dos projetos mais recentes (primeira vers\u00e3o lan\u00e7ada em 2013) e com grande potencial de desenvolvimento, o Shepherd (GNU dmd, como tamb\u00e9m \u00e9 conhecido) \u00e9 um gerenciador de inicializa\u00e7\u00e3o e servi\u00e7os do projeto GNU. Estamos falando do que, provavelmente, ser\u00e1 o principal concorrente do systemd.<\/p>\n Os motivos para tal afirma\u00e7\u00e3o s\u00e3o \u00f3bvios, afinal a comunidade GNU \u00e9 muito grande, o que \u00e9 fundamental para a continuidade do projeto, e o seu ecossistema \u00e9 abrangente, englobando as mais variadas solu\u00e7\u00f5es desenvolvidas junto \u00e0 filosofia de software livre \u2014 saiba mais sobre a import\u00e2ncia do projeto GNU.<\/p>\n Se h\u00e1 um fator que diferencia at\u00e9 demais o Shephard dos demais \u00e9 a sua constru\u00e7\u00e3o a partir da linguagem de programa\u00e7\u00e3o GNU Guile, o que torna o gerenciador mais um complemento do sistema operacional Guix, tamb\u00e9m mantido pela equipe do projeto GNU, ainda que ele possa ser integrado a qualquer outro projeto.<\/p>\n No entanto, cabe esclarecer que o Shepherd ainda est\u00e1 em processo de desenvolvimento, portanto ele n\u00e3o fornece a mesma quantidade de recursos que o systemd \u2014 que \u00e9 escrito em C, uma linguagem muito mais acess\u00edvel aos programadores.<\/p>\n Lan\u00e7ado em 2004, o Runit \u00e9 um dos mais antigos sistemas de inicializa\u00e7\u00e3o voltados ao Linux. O respons\u00e1vel pela cria\u00e7\u00e3o (e manuten\u00e7\u00e3o) do projeto Runit \u00e9 Gerrit Pape, que trabalha em outros projetos muito interessantes \u2014 voc\u00ea pode encontrar mais informa\u00e7\u00f5es, aqui<\/a>.<\/p>\n Em contraste ao SysVinit, ent\u00e3o \u201csoberano\u201d, o Runit era compat\u00edvel n\u00e3o apenas com sistemas Linux e BSD, mas tamb\u00e9m com Solaris e MacOS, o famoso sistema operacional da Apple.<\/p>\n Entre as suas vantagens na \u00e9poca estava a velocidade do boot. A superioridade no quesito em rela\u00e7\u00e3o ao SysVinit em raz\u00e3o da sua capacidade de carregar servi\u00e7os paralelamente. Com isso, o processo de boot do Linux, que durava quase 3 minutos no SysVinit, ca\u00eda para 55<\/a> segundos.<\/p>\n Na pr\u00e1tica, cada servi\u00e7o \u00e9 associado com um diret\u00f3rio espec\u00edfico, bem como s\u00e3o executados em segundo plano como “processo filho” de um outro processo que roda nesse diret\u00f3rio: o runsv, cuja fun\u00e7\u00e3o \u00e9 supervisionar os servi\u00e7os.<\/p>\n O processo de controle runsv foi bastante ben\u00e9fico para otimizar o boot devido a sua confiabilidade. Isso porque o runsv era menos propenso a falhas em compara\u00e7\u00e3o a outros programas que “adivinhavam” o n\u00famero de PID dos servi\u00e7os (PID-guessing) e \/ ou usavam arquivos PID.<\/p>\n Como o Runit consiste em apenas tr\u00eas est\u00e1gios (inicializa\u00e7\u00e3o, supervis\u00e3o de processo e halt \/ poweroff \/ reboot), o seu funcionamento \u00e9 alheio a complexidades, o que facilita o trabalho dos desenvolvedores, que se deparam com um c\u00f3digo pequeno e port\u00e1vel \u2014 pronto para rodar em sistemas como Debian e BSD, por exemplo.<\/p>\n Uma caracter\u00edstica do Runit que tamb\u00e9m agrada a muitos desenvolvedores \u00e9 a simplicidade. \u00c9 um dos programas que se enquadram na abordagem Unix, mais precisamente quanto a “fazer uma coisa bem feita” e escolher “portabilidade em vez de efici\u00eancia”.<\/p>\n Quer saber como \u00e9 o seu desempenho na vers\u00e3o est\u00e1vel mais recente? Bom, o Runit pode ser encontrado no Void Linux, sistema operacional aut\u00eantico desenvolvido por uma comunidade pequena; \u00e9 a melhor op\u00e7\u00e3o para test\u00e1-lo.<\/p>\n Como vimos ao longo deste artigo especial sobre sistemas init, os processos de boot do Linux podem ser executados por meio de diversas solu\u00e7\u00f5es. Embora a maioria das distribui\u00e7\u00f5es tenham incorporado o systemd, dependendo do seu prop\u00f3sito, voc\u00ea tem boas alternativas para utilizar no seu projeto.<\/p>\naltamente recomend\u00e1veis<\/s> textos sobre systemd,<\/a> este t\u00f3pico \u00e9 dedicado a voc\u00ea. Podemos definir o systemd<\/strong><\/a> como o sistema de inicializa\u00e7\u00e3o Linux do momento, por\u00e9m, de t\u00e3o robusto, ele vai muito al\u00e9m do que um programa do tipo se prop\u00f5e a fazer.<\/p>\n\n
Algumas caracter\u00edsticas e benef\u00edcios<\/b><\/h3>\n
2. SysVinit<\/b><\/h2>\n
\n
De padr\u00e3o a legado<\/b><\/h3>\n
3. Upstart<\/b><\/h2>\n
Funcionamento<\/b><\/h3>\n
4. OpenRC<\/b><\/h2>\n
Outras caracter\u00edsticas e benef\u00edcios<\/b><\/h3>\n
5. Shepherd<\/b><\/h2>\n
6. Runit<\/b><\/h2>\n
Outras caracter\u00edsticas e benef\u00edcios do Runit<\/b><\/h3>\n