Systemd – O que você precisa saber

A menos que você tenha vivido debaixo de uma pedra, ou pior – não se importe muito com como o Linux funciona, você deve ter ouvido falar do systemd, o sistema init (relativamente) novo que está substituindo o antigo e ultrapassado SysV init, recentemente adotado pela maioria das principais distribuições Linux.

O que é um sistema init?

Quando sua máquina Linux inicia, ela executará primeiro algum código “embutido”, carregado a partir do BIOS ou UEFI, seguido pelo carregador de inicialização, que de acordo com sua configuração carrega um kernel Linux. O kernel carrega os drivers e, como seu primeiro trabalho, inicia o processo init, que sendo o primeiro recebe o PID (ID do Processo) 1 atribuído a ele.

Do ponto de vista do usuário, isso parece como iniciar a rede e os bancos de dados, etc., mas na realidade, há um processo bastante complexo acontecendo nos bastidores. Serviços são iniciados, parados e reiniciados, muitas vezes em paralelo uns com os outros. Alguns são executados sob privilégios diferentes de outros, os status dos serviços estão sendo reportados e registrados, e muitas outras tarefas são realizadas para fazer a parte diferente do seu sistema funcionar e interagir com seus usuários e ambiente.

Como isso é implementado, no entanto, está longe de ser uniforme, e é aqui que tudo começa a não ser comum e bem definido.

O antigo sistema init

O sistema init usado pela maioria das distribuições Linux mainstream até recentemente era o System V init (ou SysV init para abreviar), que recebeu seu nome do UNIX System V (pronunciado “Sistema Cinco”), o primeiro sistema UNIX comercialmente disponível. O OS System V tinha uma maneira específica de executar seu processo init, e o SysV init permaneceu leal a isso ao longo dos anos.

E já se passaram muitos anos. O UNIX System V foi lançado originalmente em 1983, fazendo do init SysV init uma abordagem de mais de 30 anos para iniciar máquinas Linux.

A necessidade de uma mudança

Como foi observado, o SysV init está ultrapassado e há muito tempo deveria ter sido substituído. Algumas das razões para isso incluem:

• O SysV init usa /sbin/init para iniciar o processo init, mas o init em si tem um papel muito limitado. O init faz pouco mais do que iniciar /etc/init.d/rc, de acordo com a configuração lida de /etc/inittab, que por sua vez executará scripts para fazer o verdadeiro trabalho do processo init. Isso, a menos que seja paralelizado explicitamente (como acontece com startpar no Debian), ocorrerá sequencialmente, um script começando após o outro, tornando todo o processo lento, já que cada script tem que esperar o anterior terminar.
• O SysV init não tem acesso ao PID ou aos processos que ele (indiretamente) iniciou. Ele apenas lê PIDs e os associa a processos reais de uma maneira circunstancial e complicada.
• Para os administradores de sistema que tentam modificar o ambiente sob o qual um determinado processo começaria, é bastante difícil com o SysV init. (Para conseguir isso, eles terão que modificar o script init que é responsável por iniciar o dado processo.)
• Há uma certa funcionalidade comum a cada serviço que o SysV não implementa, mas que cada processo teria que implementar por si só, como “daemonizar-se” (tornar-se um daemon do sistema), o que é um processo elaborado e longo. Em vez de implementar esses passos uma vez, o SysV exige que cada processo faça o trabalho por conta própria.
• O SysV também deixa certas funcionalidades para programas externos e não sabe nada sobre serviços iniciados por esses.

Tudo isso, e muitos mais defeitos de design, ou melhor, o design do sistema ultrapassado do SysV, tornaram a criação de um sistema init moderno uma necessidade há muito tempo não atendida.

A entrada do systemd

Houve muitas tentativas de criar um sistema init alternativo, do qual o systemd é apenas um deles. O Ubuntu costumava rodar seu próprio sistema init chamado upstart. O Gentoo ainda usa o OpenRC. Outros sistemas init incluem initng, busybox-init, runit, Mudur e outros.

A razão pela qual o systemd é um vencedor claro é que ele foi adotado pela maioria das grandes distribuições. O RHL e o CentOS naturalmente seguiram o caminho do systemd, já que o Fedora foi a primeira distribuição a adotar oficialmente o systemd em 2011. Mas o systemd realmente se tornou o único sistema init que domina todos, quando o Debian 8 mudou oficialmente para o systemd, levando o Ubuntu e seus derivados com ele, superando a oposição inicial da Canonical (ou mais precisamente de Mark Shuttleworth) ao systemd.

Como o systemd é diferente?

• O systemd tem como objetivo fornecer uma forma única e centralizada de gerenciar o processo init do começo ao fim.
• Ele inicia e para processos e serviços enquanto acompanha suas dependências. Ele pode até iniciar um processo em resposta a um requisito de dependência de outro processo.
• Além de iniciar e parar processos durante o tempo de inicialização, o Systemd também pode começar a qualquer momento quando o sistema está ativo em resposta a certos eventos de gatilho, como quando um dispositivo é conectado.
• Ele também não requer que os processos se daemonizem. Ao contrário do SysV init, o systemd pode gerenciar serviços em execução sem ter que passar pelo longo processo de se tornar daemons.
• Ao contrário do SysV init, o systemd conhece e rastreia todos os processos, incluindo PIDs, e obter informações sobre os processos é muito mais simples para os administradores de sistema sob o systemd.
• O systemd suporta containers que são, basicamente, ambientes de serviço isolados sem a necessidade de máquinas virtuais. Isso tem um grande potencial para desenhos de sistema mais seguros e simples no futuro.

Claro que essas são apenas algumas das principais vantagens. Para uma discussão completa sobre as vantagens do systemd, você deve ler o “Systemd Position Statement” do Debian 8.

Controvérsia

Claro que o systemd não foi bem recebido por todos. Na verdade, muitos têm e ainda fazem careta para ele, chamando-o de monolítico e complicado, alguns até o acusando de seguir o “caminho do Windows” de ter tudo centralizado. Muitos argumentam que não é “o caminho do Linux”, e certamente o systemd não parece estar em conformidade com os padrões POSIX, e se considerarmos o systemd como uma caixa de ferramentas (mais além do que apenas o binário), é definitivamente enorme.

No entanto, o systemd é claramente um passo adiante, e embora não seja perfeito, grande parte da crítica que recebeu foi abordada pelo seu autor e desenvolvedor original, Lennart Poettering. Definitivamente é um avanço muito necessário e um passo adiante em relação ao antigo sistema init. Linus Torvalds, o criador do Linux, não parece se importar muito com o systemd, e quem somos nós para discutir com “O Criador”.

Conclusão

Tendo sido adotado por todas as principais distribuições Linux, o systemd veio para ficar. O que alguns administradores de sistema dizem por qualquer razão, o systemd é o futuro do Linux mainstream, quer usuários individuais gostem ou não, o que, olhando para suas vantagens distintas, não é necessariamente uma coisa ruim.

Para o usuário médio, ele traz tempos de inicialização mais rápidos e provavelmente sistemas mais confiáveis, enquanto no futuro as distribuições que o adotarem podem se tornar mais “compatíveis” entre si. Do lado do usuário, definitivamente beneficiaremos do design de sistema mais atualizado e contemporâneo que traz para nossas áreas de trabalho.