Processo de boot do Linux: conheça os 6 principais gerenciadores

JUNTE-SE A MAIS DE 110.000 PESSOAS QUE JÁ TEM UMA CÓPIA

Ubuntu: Iniciando com Linux de maneira prática e rápida

processo de boot no linux

Compartilhe este post

Share on facebook
Share on linkedin
Share on twitter
Share on email

Depois dos artigos completos que acompanhamos sobre o systemd, sistema que faz parte do processo de boot do Linux na maioria das distribuições, darei continuidade ao assunto apresentando as demais opções disponíveis para gerenciamento de serviços e inicialização. Antes de continuarmos, você se lembra o que faz um init system?

O que um software como o systemd faz é dar prosseguimento aos processos de boot assim que o kernel, por meio do initramfs (ou initrd, dependendo da distro), carrega o hardware da máquina e, em seguida, invoca o gerenciador para carregar o sistema operacional e respectivos serviços.

Nota: a explicação acima foi bem superficial, pois muitas outras coisas acontecem durante os poucos segundos entre apertarmos o botão Power e digitarmos o login de acesso à área de trabalho. A questão é que o sistema de inicialização entra em cena somente após o kernel concluir a sua função.

Como vimos nos artigos anteriores, ainda que brevemente, há diferentes sistemas de inicialização para Linux. O systemd é mais robusto (complexo, seguro e cheio de recursos) e utilizado na maioria das distribuições na atualidade, mas, até pouco tempo atrás, o Linux geralmente rodava com Upstart ou SysVinit.

processo de boot no linux

Então 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óprio systemd e seus antecessores. Vamos lá?

1. Systemd

Caso ainda não tenha lido os altamente recomendáveis textos sobre systemd, este tópico é dedicado a você. Podemos definir o systemd como o sistema de inicialização Linux do momento, porém, de tão robusto, ele vai muito além do que um programa do tipo se propõe a fazer.

Sem atropelar etapas, vamos a um resumo da sua história: com o primeiro código lançado em 2009, o systemd é um projeto encabeçado por Lennart Poettering. Desde o início, o intuito dos desenvolvedores foi criar um mecanismo que se tornasse padrão nas principais distribuições do Linux.

Devido à vasta gama de funcionalidades — a qual é alvo de críticas de muitos desenvolvedores que procuram por algo mais simplificado —, muitos projetos grandes passaram a adotá-lo, tais como:

  • Debian;
  • Fedora;
  • Red Hat; e
  • SUSE.

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ão o utiliza como init padrão, porém a ideia já está em fase de experimentação (vide projeto Dlackware).

Algumas características e benefícios

Entre todas as suas vantagens e características, o fator determinante para o sucesso do systemd foi a sua capacidade de se adaptar a novas tecnologias. Considerando que a tendência é a integração constante de dispositivos, o systemd oferece os meios necessários para que ela seja realizada com sucesso no Linux.

Por fim, outros motivos que favorece a escolha pelo systemd são: a compatibilidade com os scripts do SysVinit e do padrão LSB, detalhe que facilita a sua customização; a agilidade para carregar os serviços paralelamente; e o gerenciamento prático a partir dos utilitários que acompanham o gerenciador.

Para mais informações sobre o systemd, só ler os artigos disponíveis aqui no blog.

2. SysVinit

Agora vamos ao clássico SysVinit. Esse gerenciador de sistema é utilizado no Linux desde as suas primeiras distros e manteve-se padrão durante muitos anos. A hegemonia, no entanto, converteu-se em obsolescência na medida em que novas soluções vinham à tona.

O SysVinit, assim como os demais programas, trabalha com níveis de execução (runlevels). O que é isso? Basicamente, trata-se de um esquema classificado de 0 a 6, onde cada um dos sete níveis carrega um conjunto de serviços a serem executados ou finalizados pelo sistema.

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íveis são:

  • 0: halt (desliga o sistema);
  • 1: também conhecido como s ou S, este é o nível monousuário. Nele, o usuário com privilégios root tem acesso ao modo “básico” do sistema para fins de manutenção (equivalente ao modo de segurança do Windows);
  • 2, 3, 4 e 5: são níveis multiusuários sem rede, com rede, interface CLI (linha de comandos), GUI (interface gráfica) e modo customizado, respectivamente;
  • 6: reboot (reinicia o sistema).

Conforme o usuário seleciona um dos níveis descritos acima, o SysVinit faz a leitura do arquivo script correspondente à opção (exemplo: /etc/rc1.d para monousuário), que guarda todas as configurações — ou seja, cada serviço que deve ser inicializado.

De padrão a legado

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ção da Tecnologia da Informação. Entre os pontos fracos do gerenciador, o maior deles era o método de execução.

Diferentemente dos programas utilizados atualmente, o SysVinit carrega os serviços um por um, seguindo a ordem que consta nos scripts. Isso gera, entre outros problemas, muita lentidão para que o sistema operacional fique pronto para uso. É algo inconcebível na era digital.

Mesmo que o SysVinit seja inviável na maioria dos casos — se já não foi substituído em todos os projetos —, os seus scripts ainda podem ser aplicados em outros gerenciadores.

3. Upstart

Lançado em 2006, o Upstart foi um dos primeiros projetos criados com o propósito de mudar o processo de boot do Linux. Como eu disse no primeiro tópico, ele foi padrão nos sistemas Ubuntu por um determinado período; o porquê da resistência em mantê-lo se resume ao fato de que a Canonical era quem desenvolvia ambas as soluções.

Entretanto, o Upstart tem um importante diferencial que é a execução em resposta a eventos. Em outras palavras, não há sequência fixa de serviços a serem carregados, como no SysVinit; em vez disso, cada trabalho especifica os eventos que reagirão a ele, e o Upstart, paralelamente, inicia todos os serviços correspondentes aos eventos.

Funcionamento

Na estrutura do Upstart existem os já mencionados trabalhos (jobs). Cada job se subdivide em task jobs e service jobs, sendo o primeiro um processo que realiza uma tarefa específica quando acionado e, depois, fica em espera. Por sua vez, um service job são os próprios serviços iniciados / encerrados manualmente ou por um evento.

Logo, sendo o Upstart um gerenciador reativo (no caso, que responde a eventos em tempo real), significa que ele não trabalha com níveis de execução, ainda que haja compatibilidade com scripts do SysVinit — eles foram incluídos no projeto no intuito de assegurar que a transação para o Upstart ocorresse gradualmente.

O modo como funciona o Upstart é diferenciado e, de fato, muito interessante, mas, infelizmente, a Canonical não pretende desenvolvê-lo. Hoje, o projeto segue disponível com propósitos de manutenção, visto que ainda há distribuições com suporte ativo que usam Upstart.

4. OpenRC

Desenvolvido pela equipe do Gentoo, o OpenRC é um init que surgiu em 2007 com o propósito de trazer simplicidade, portabilidade e agilidade. Ele é o gerenciador preferido de boa parte dos programadores que necessitam de soluções menos robustas (leia-se systemd), mas excelentes para o que se dispõem a fazer.

Fazendo uma analogia pouco inspirada, o OpenRC, comparado ao systemd, é como um forasteiro minimalista que se concentra em sobreviver (e faz isso como ninguém) diante de um cidadão urbano, que estuda, trabalha e faz diversas outras tarefas muito bem, mas vive numa rotina complexa.

Até pelas características relativamente simples, assemelhando-se ao SysVinit, podemos considerar o OpenRC um dos sucessores mais bem sucedidos do tradicional gerenciador, ou até mesmo a evolução natural dele restrita a executar os serviços a partir de scripts — inclusive, o OpenRC é oferece suporte aos scripts do SysVinit.

Em contrapartida, o ponto fraco do OpenRC é a supervisão, que deixa muito a desejar em relação a outros gerenciadores. Nele, se determinado serviço não é iniciado ou encerrado, o usuário é apenas informado disso. Se o processo permanece inativo ou travado é necessário iniciá-lo / encerrá-lo manualmente.

Outras características e benefícios

Uma das capacidades mais legais do OpenRC é a possibilidade de alternar a inicialização para responder a eventos, como o Upstart. Só não chega a ser uma vantagem e tanto porque o suporte é limitado — não podemos nos esquecer de que ele foi projetado para ser simples.

Outras características e recursos em destaque são a compatibilidade com Linux, FreeBSD e NetBSD, o registro de mensagens emitidas pelo OpenRC e serviços iniciados por meio dele, e a quantidade significativamente menor de desafios para aprendizado.

5. Shepherd

Um dos projetos mais recentes (primeira versão lançada em 2013) e com grande potencial de desenvolvimento, o Shepherd (GNU dmd, como também é conhecido) é um gerenciador de inicialização e serviços do projeto GNU. Estamos falando do que, provavelmente, será o principal concorrente do systemd.

Os motivos para tal afirmação são óbvios, afinal a comunidade GNU é muito grande, o que é fundamental para a continuidade do projeto, e o seu ecossistema é abrangente, englobando as mais variadas soluções desenvolvidas junto à filosofia de software livre — saiba mais sobre a importância do projeto GNU.

Se há um fator que diferencia até demais o Shephard dos demais é a sua construção a partir da linguagem de programação GNU Guile, o que torna o gerenciador mais um complemento do sistema operacional Guix, também mantido pela equipe do projeto GNU, ainda que ele possa ser integrado a qualquer outro projeto.

No entanto, cabe esclarecer que o Shepherd ainda está em processo de desenvolvimento, portanto ele não fornece a mesma quantidade de recursos que o systemd — que é escrito em C, uma linguagem muito mais acessível aos programadores.

6. Runit

Lançado em 2004, o Runit é um dos mais antigos sistemas de inicialização voltados ao Linux. O responsável pela criação (e manutenção) do projeto Runit é Gerrit Pape, que trabalha em outros projetos muito interessantes — você pode encontrar mais informações, aqui.

Em contraste ao SysVinit, então “soberano”, o Runit era compatível não apenas com sistemas Linux e BSD, mas também com Solaris e MacOS, o famoso sistema operacional da Apple.

Entre as suas vantagens na época estava a velocidade do boot. A superioridade no quesito em relação ao SysVinit em razão da sua capacidade de carregar serviços paralelamente. Com isso, o processo de boot do Linux, que durava quase 3 minutos no SysVinit, caía para 55 segundos.

Na prática, cada serviço é associado com um diretório específico, bem como são executados em segundo plano como “processo filho” de um outro processo que roda nesse diretório: o runsv, cuja função é supervisionar os serviços.

O processo de controle runsv foi bastante benéfico para otimizar o boot devido a sua confiabilidade. Isso porque o runsv era menos propenso a falhas em comparação a outros programas que “adivinhavam” o número de PID dos serviços (PID-guessing) e / ou usavam arquivos PID.

Outras características e benefícios do Runit

Como o Runit consiste em apenas três estágios (inicialização, supervisão de processo e halt / poweroff / reboot), o seu funcionamento é alheio a complexidades, o que facilita o trabalho dos desenvolvedores, que se deparam com um código pequeno e portável — pronto para rodar em sistemas como Debian e BSD, por exemplo.

Uma característica do Runit que também agrada a muitos desenvolvedores é a simplicidade. É 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ência”.

Quer saber como é o seu desempenho na versão estável mais recente? Bom, o Runit pode ser encontrado no Void Linux, sistema operacional autêntico desenvolvido por uma comunidade pequena; é a melhor opção para testá-lo.

Como vimos ao longo deste artigo especial sobre sistemas init, os processos de boot do Linux podem ser executados por meio de diversas soluções. Embora a maioria das distribuições tenham incorporado o systemd, dependendo do seu propósito, você tem boas alternativas para utilizar no seu projeto.

Presumindo que o Linux ainda seja novidade para você, que deseja se tornar um desenvolvedor de alto nível, e queira aprender a trabalhar fazer coisas incríveis com ele, fica a sugestão: acesse agora mesmo a página Profissionais Linux.

Compartilhe este post

Share on facebook
Share on linkedin
Share on twitter
Share on email

Artigos Recentes

Aprenda a dominar o Linux de uma vez por todas

Aprenda a dominar o Linux de uma vez por todas