O processo de inicialização de qualquer sistema operacional envolve uma série de procedimentos e eventos que devem ocorrer em determinada ordem para que o resultado final seja o esperado: programas em execução e o sistema operacional disponível para o usuário. No GNU/Linux, os "programas em execução" são os serviços: programas executados em segundo plano dedicados a fornecer toda a infra-estrutura de que necessitam os aplicativos em geral.

Os serviços são iniciados, a cada boot, pelo init, processo-pai de todos os processos do sistema. É o init quem recebe do kernel, logo após este ser devidamente carregado, o controle do sistema. Cabe ao init descobrir ou deduzir a ordem de início dos serviços — por exemplo, o serviço de montagem de sistemas de arquivo em rede precisa que o serviço de rede esteja de pé — e "subir" aqueles que devam ser "subidos". As tarefas do init, portanto, são múltiplas:

• descobrir ou deduzir quais serviços deverão ser iniciados;
• para cada serviço a ser iniciado:
• certificar-se de que o serviço ainda não esteja de pé antes de iniciá-lo;
• iniciá-lo;
• monitorá-lo (e também seus processos-filhos);
• reiniciá-lo caso o processo morra;
• descobrir ou deduzir quais serviços deverão ser parados (em mudanças de runlevel, por exemplo);
• parar serviços de forma competente: caso o serviço não consiga parar, matá-lo;

Como se pode ver, é dura a vida de init!

Além disso, recentemente passou-se a exigir muita inteligência desse sistema. Em busca de tempos de boot reduzidos (quem não quer ver o sistema ir de zero a "pronto" em dez segundos ou menos?), os usuários desejam agora que o init inicie os serviços em paralelo. E mais: sem fazer bagunça, isto é, respeitando as dependências entre os diversos serviços.

Tradicionalmente, sistemas GNU/Linux utilizavam um de dois sistemas de init, ambos emprestados: o do UNIX System V ou o ultra-simples do BSD.

Ambos, no entanto, são falhos em várias das tarefas que um sistema de init deve cumprir. O monitoramento e controle dos processos-filhos de cada serviço, por exemplo, costuma ser bastante problemático, com frequentes desencontros entre o init e o serviço. O reinício automático de serviços que porventura venham a morrer é outro ponto de incompetência. Compreensivelmente, surgiram várias tentativas de sistemas de init alternativos, a fim de resolver os problemas de uma vez por todas.

Contudo, cada nova iniciativa traz consigo um conjunto de obstáculos, como o fato de utilizar linguagens de programação diferentes de shell script, ou um foco exagerado no paralelismo — deixando muitas das demais obrigações do init apenas parcialmente cobertas — ou a ausência de documentação, ou ainda a pura e simples falta de divulgação. A maioria delas, no entanto, peca justamente por não oferecer uma alternativa realmente completa ao init tradicional e demandar do administrador muito trabalho e empenho. Tratam-se, portanto, de projetos imaturos.

No caso do Upstart usado no Ubuntu 10.04.1, por exemplo, há alguns serviços que o utilizam e outros que não o utilizam.

O resultado: a maioria dos sistemas alternativos hoje se restringe à própria distribuição que o criou, mesmo com muitos deles sendo perfeitamente multi-plataforma. É a tão temida fragmentação, eterno fantasma do Software Livre.

Contra o imaturo, o novo?

É muita audácia propor, diante de um cenário assim, uma nova alternativa. Pior ainda é afirmar que essa nova alternativa é superior a todas as demais, mesmo quando ainda não está sequer finalizada. Contudo, é isso mesmo que venho fazendo nos últimos meses, desde que conheci o Systemd, de autoria do talentoso Lennart Poettering. O funcionário da Red Hat, auxiliado por parceiros na Novell, Intel, Nokia e outras empresas, propõe algumas profundas mudanças de conceitos que fazem muito sentido e não requerem o emprego de novas estruturas, pois todo o necessário já está disponível no sistema. Trata-se, portanto, de simplesmente redefinir as infra-estruturas a serem utilizadas para iniciar serviços.

Em sua descrição do Systemd, Lennart expõe com muito mais profundidade, autoridade e clareza as vantagens e motivações do "novo init" que ele está construindo. Porém, vale a pena apresentá-lo aqui para divulgá-lo e evitar as dores dos demais inits alternativos.

Lennart propõe como fundamentos para seu novo init duas metas: iniciar menos processos no total e iniciar mais processos em paralelo. Isso significa adiar o início dos serviços até que sejam realmente necessários e, quando isso acontecer, usar todos os recursos disponíveis para iniciar cada serviço deforma a reduzir o tempo necessário para subi-lo. Ele defende que até mesmo os sistemas atuais de init como o Upstart, voltados ao paralelismo, ainda são "seriais demais", pois cada serviço apenas inicia após suas dependências informarem que foram iniciadas.

Mais burro é melhor

A forma de evitar isso é fornecer a cada serviço todos os sockets dos quais ele depende, mesmo que o "dono" de cada socket ainda não tenha sido iniciado. Por exemplo, em vez de vários serviços aguardarem o início do serviço do D-Bus, eles simplesmente enviariam tudo que precisassem ao socket do D-Bus (/var/run/dbus/system_bus_socket) antes mesmo de o serviço do D-Bus ser iniciado. Quando o D-Bus fosse iniciado (o que seria feito justamente ao receber dados nesse socket, ou seja, sob demanda), ele recolheria os dados enviados a seu socket e saberia perfeitamente o que fazer com eles. A semelhança com o inetd (ou xinetd) é marcante, e o próprio autor afirma que a ideia não é nova — inclusive, é usada pela Apple no sistema de inicialização do Mac OS X.

A vantagem desse sistema é justamente dispensar a inteligência dos serviços. Ainda no exemplo do D-Bus, um serviço que dependa do D-Bus não precisará mais saber que depende dele; bastará enviar ao socket do D-Bus tudo que for necessário, assim que desejar.

Com relação à robustez desse sistema, o autor ainda lembra: mesmo que o serviço saia do ar, seu socket pode continuar aberto, recebendo dados, de forma que os serviços que dependam dele não tenham que parar. Quando o serviço retornar, ele recuperará novamente os dados em seu socket. A ausência de uma seta para cima indica justamente que não é necessária uma transmissão de dados de volta para o serviço. Isto é economia de recursos!

Toda a infra-estrutura para suportar esses recursos já existe. Serviços que utilizam sockets diretamente podem trabalhar assim, da mesma forma que os mais modernos, que utilizam a infra-estrutura do D-Bus.

Bash é ruim! Bash é ruim?

Um dos indicativos de que o sistema de init atual é ineficiente, segundo Lennart, é o fato de que o PID do primeiro programa executado pelo primeiro usuário a fazer login num sistema atual já é "alto demais". Ele compara isso aos números em sistemas Mac OS X, em que esse "primeiro PID" é entre 100 e 200, enquanto no GNU/Linux é acima de 1000. Cada chamada ao sed, grep ou awk nos scripts de inicialização abre um novo processo, incrementando o PID em 1. Portanto, um número como 1800 ao executar echo $$ no primeiro terminal gráfico após o boot significa que 1799 processos foram iniciados antes dele. Embora criar processos em UNIX e Linux seja "barato", não é de graça, e esse número alto de "primeiro PID" é um sintoma de ineficiência.

O culpado: Bash. Scripts de shell são práticos, mas sua execução é lenta e eles exigem a abertura de todos esses inúmeros outros processos. Na parte mais controversa e questionável da argumentação de Lennart, ele propõe eliminar os shell scripts da maior parte dos scripts, embutindo boa parte das tarefas desses scripts em outras partes do sistema ou — atenção — re-escrevendo-as em C. Mas calma, não vá embora. Ainda há coisas muito boas por vir!

Sistemas de arquivos

Sistemas de arquivos podem representar um ponto complicado, e certamente são uma parte significativa na demora da inicialização dos sistemas. Isto ocorre porque a verificação de integridade dos sistemas de arquivos acontece sempre de forma serial — um forte gargalo!

Lennart aponta Harald Hoyer como autor da ideia que ele apoia: usar o automount para isso! Em vez de seu sistema operacional gastar tempo conferindo a integridade do /home/ ao iniciar, que tal ele deixar isso para quando o /home/ for acessado? ;) Assim, até a montagem de sistemas de arquivos — claro, somente os que não forem necessários para o boot — se torna paralela!

Esta parte você mesmo(a) já pode experimentar aí no seu sistema. Desde que li a extensa argumentação de Lennart, passei a colocar o /home no autofs e acho que a inicialização ficou "fantásticos" 0,8 segundos mais rápida. :)

Não perca seus netos!

Lennart afirma que um script CGI iniciado pelo Apache pode fazer um fork() e matar o processo CGI original. Neste caso, o Apache perde completamente a ligação com seu "neto", isto é, o filho do processo CGI que o Apache iniciou. Como consequência, ao dar um stop no serviço do Apache, o coitado nem ao menos tem como saber que existe um neto seu à solta no sistema — que dirá terminá-lo!

O drama de um sistema de controle de processos reside justamente na falta de controle sobre netos, bisnetos e demais "parentes". O Systemd pretende utilizar uma estrutura não tão nova no kernel para isso, chamada control groups ou apenas cgroups. O poder dos cgroups tem duas vantagens excepcionais: em primeiro lugar, todos os processos-filhos e netos, e bisnetos etc. de um processo fazem parte de um grupo de processos, e essa estrutura é muito fácil de consultar — ninguém perde netos, jamais. Em segundo lugar, é possível limitar o número de processos-filhos (e netos, bisnetos...) que um serviço pode gerar, e os recursos de sistema (CPU, memória etc.). Esta é uma forma interessante para evitar que serviços virem vorazes consumidores de recursos, o que pode até servir como uma proteção BEM básica contra invasões.

Só falta funcionar

A ideia do Systemd foi publicada em abril deste ano. A equipe do Fedora cogitou incluí-lo no Fedora 14, a ser lançado em breve. Porém, durante uma série de testes intensivos (um Fedora Test Day), usuários e desenvolvedores concluíram que ainda falta maturidade ao projeto, adiando sua inclusão para o Fedora 15, que será lançado na primeira metade de 2011.

Aparentemente, há desenvolvedores de outras distribuições além do Fedora — "casa" do Systemd — de olho no projeto, o que aponta para uma redução na fragmentação.

Lennart publicou também, em agosto, um outro post sobre resultados de uso do Systemd.

Desempenho

Estima-se que, num primeiro momento (leia-se, no Fedora 15), o uso do Systemd ainda não traga grandes ganhos de desempenho do boot. O sistema usado atualmente na distribuição, o Upstart, paraleliza a maioria dos serviços que precisam ou podem ser paralelizados com ganhos de desempenho. Porém, com o amadurecimento dos processos envolvidos no Systemd — e uma boa dose de benchmarks — certamente teremos boots mais rápidos e melhor controle sobre os serviços no GNU/Linux.

Links

• (LONGA) Apresentação do Systemd ao mundo
• Segundo post de Lennart Poettering sobre Systemd
• Systemd no Wiki do Fedora
• Tópico sobre Systemd no Fedora 14 na lista do Fedora
• Sistemas de init, na Wikipédia em inglês
• Upstart, na Wikipédia em inglês
• Críticas aos princípios monolíticos do Launchd (Mac OS X) e do Systemd
• Resultados do Fedora Test Day do Systemd
• Systemd na LWN

Outros artigos deste autor

• Dica rápida: Automount mais inteligente
• Dica rápida: otimização de desktops com kernel Linux no /proc e /sys
• Fez besteira no /etc? Use o git para retornar tudo ao normal
• Renomear interface de rede com Udev
• Servidores atacados: culpa do distribuidor do kernel?
• Dica rápida: calendário anual no OpenOffice.org- Prompt de Bash mais útil
• Bê-á-bá do SSH, parte 9: Controle de acesso
• O planeta inteligente, na visão da IBM. Temos tempo até a Copa do Mundo?
• As novidades do kernel Linux 2.6.35
• Bê-á-bá do SSH, parte 8: Proxy HTTP em túnel
• Bê-á-bá do SSH, parte 7: Túneis
• Snapshots COW para os menos favorecidos: cron, rsync e hardlinks
• Bê-á-bá do SSH, parte 6: X remoto
• Bê-a-bá do SSH, parte 5: O uso da randomart
• Bê-a-bá do SSH, parte 4: Execução de comandos remotos
• Bê-á-bá do SSH, parte 3: Trabalhando com chaves criptográficas públicas e privadas
• Be-a-bá do SSH, parte 2: Cópia de arquivos pela rede
• Bê-á-bá do SSH, parte 1: Apresentação do SSH
• As novidades do kernel Linux 2.6.34
• Tux3, o sistema de arquivos que (mais uma vez) não aconteceu
• Compiladores melhorados pela genética

Marcações:  linux gnu