systemd

Entenda o amor e ódio ao SystemD: conheça os diferentes daemons de inicialização do Linux, o que era o Init e qual a importância do SystemD!

---

| Se você apoia nosso site, desative o AdBlock quando visitá-lo, inclusive em Mobile!
Os anúncios são poucos e não invasivos. Se quiser contribuir com nosso trabalho, clique em qualquer banner de sua preferência, exceto dos Parceiros. Mais detalhes clicando aqui.

---

1. Introdução

Muito se fala no Init e na “perda” que foi substituí-lo pelo SystemD como padrão dos sistemas Linux atuais.
Mas quais as diferenças entre eles? Até que ponto essa substituição causou prejuízos aos sysadmins? O SystemD realmente atrapalhou ou melhorou as coisas? Hoje, no Glob… Linux Universe!

2. O que é o Init, o antigo daemon?

No Linux, o nome do daemon “init” é uma abreviatura para Inicialização. Seu nome completo é referido como “System V init”, pois o AT&T UNIX System V foi um dos primeiros sistemas operacionais comerciais da linha UNIX® que fez uso do init; sua implementação na maior parte das distribuições Linux de hoje é idêntico ao do System V, com poucas mudanças, como no Slackware que usa o estilo do BSD e o Gentoo que usa um init customizado.

O init é um processo (daemon) que começa assim que o computador é iniciado e continua funcionando até seu desligamento. Ele é o primeiro processo que o kernel inicia quando um computador é inicializado, tornando-o pai de todos os demais processos em execução, e portanto, lhe é atribuído PID = 1.

Curiosamente, se de algum modo o init não puder iniciar, nenhum processo do sistema será iniciado e o sistema entrará em “Kernel Panic”.

A necessidade de substituir o init com algo mais perfeito foi sentida desde muito tempo e várias alternativas foram desenvolvidas, algumas das quais se tornaram o novo padrão em distribuições Linux, dentre elas destaco:

• Upstart – Um daemon implementado no Ubuntu projetado para iniciar os processos de forma assíncrona.
• Epoch – Um daemon construído em torno de simplicidade e gerenciamento de serviços, projetado para iniciar os processos em um único thread.
• Mudar – Um daemon escrito em Python, implementado na distro GNU/Linux Pardus e projetado para iniciar os processos de forma assíncrona.
• systemd – Um daemon projetado para iniciar os processos em paralelo, implementado em uma série de distribuições padrão, como o Fedora, OpenSuSE, Arch, RHEL, CentOS, etc.
  Posteriormente também no Debian, Ubuntu e derivados.

OBS: O Debian havia sido construído sob grande dependência da maneira como o init operava, portanto parte do init ainda reside no Debian – e por consequência no Ubuntu – na forma de um serviço executado em /sbin/init. A tendência é que o init desapareça por completo dessas distribuições e o systemd seja o único daemon de gerenciamento geral do sistema.

3. O que é systemd?

O systemd é um Daemon de gerenciamento de sistema, cuja convenção UNIX definiu que seu nome leve “d” no final, significando “daemon”: systemd = SystemDaemon. Todos os daemons gerenciados pelo “pai” systemd levam “d” no final do nome, para facilitar sua identificação.

Inicialmente, foi lançado sob GNU General Public License, mas agora os lançamentos são feitos sob o GNU Lesser General Public License. Semelhante ao init, o systemd é o pai de todos os outros processos do sistema de maneira direta ou indiretamente e é o primeiro processo que inicia através do kernel Linux na inicialização, portanto, atribuído o PID = 1.

Agilidade na evolução natural do daemon de início dos sistemas Linux

O systemd pode se referir a todos os pacotes, utilitários e bibliotecas em torno do daemon. Foi projetado para superar as deficiências do init.

Ele próprio é um processo em segundo plano que é projetado para iniciar processos em paralelo, reduzindo assim o tempo de inicialização da máquina e o consumo computacional. Além disso, o systemd conta com muito mais recursos em comparação com init.

4. Funcionamento do systemd

O sistemd usa unidades de socket, que são arquivos de configuração que codificam informações relacionadas à comunicação entre processos Inter Process Communication – IPC – a soquetes de rede ou a arquivos FIFO.

Qual a importância disso tudo? Tal capacidade permite que todos os daemons requisitados no boot sejam carregados simultaneamente, bem como possibilita a transmissão coordenada entre dois sockets, resultando a rápida inicialização do sistema operacional. Em suma, paralelismo em toda sua glória!

Para efeitos de comparação, o sysvinit, utilizado em distros mais antigas do Linux, carrega todos os serviços (um por vez, automática e ordenadamente), utilizando shells scripts durante o boot. Em razão disso, ele é um sistema lento e propício a problemas.

De que “problemas” estamos falando? Vamos supor que determinado serviço não foi carregado pelo sysvinit. Diante da situação, o usuário precisa iniciá-lo manualmente, pois o sysvinit não pode ser acionado depois de concluído o boot.

A princípio pode até não parecer muito, mas, se colocarmos à mesa todos os dispositivos que conectamos no computador por meio de portas USB, LAN, HDMI, adaptador Bluetooth, entre outros, percebemos que as dores de cabeça seriam bastante recorrentes.

4.1 Arquitetura do systemd

Basicamente, a estrutura do systemd parte da organização de suas tarefas em unidades (units). Abaixo, algumas classes de units que constituem o systemd:

• service: essas unidades são os serviços presentes no sistema operacional acessíveis ao usuário;
• timer: temporizadores usados para determinar ações para um serviço usando como base o tempo (não confundir com o cron);
• mount: arquivo de configuração que codifica informações sobre um diretório controlado e supervisionado pelo systemd;
• target: grupos de unidades que reúnem todas as units necessárias para iniciar um determinado serviço;
• snapshot: mecanismo usado para criar snapshots dinâmicos do estado atual do systemd manager, útil para retomar o estado após problemas como indisponibilidade, por exemplo;
• path: unidades especialmente utilizadas para monitorar arquivos e diretórios para eventos e, também, executar serviços;
• socket: arquivo de configuração que armazena informações acerca de um IPC ou soquete de rede ou arquivo FIFO;
• swap: guarda informações relativas a dispositivos usados para swapping, bem como serviços que utilizam de memória Swap.

Cada serviço é alocado pelo systemd em um grupo de controle dedicado – control group, ou cgroup. No cgroup são organizas informações voltadas aos processos que fazem parte do grupo, como limite, supervisão e contabilização de recursos computacionais que eles consomem.

O controle desses grupos é feito a partir de utilitários que acompanham o systemd, tais como: journalctl, cgls, cgtop e systemctl. Mesmo com uma apresentação bem superficial dos seus componentes, é possível ter noção de quão robusto é o systemd.

5. Por que substituir o Init?

O Init iniciava os processos do sistema de forma seriada, ou seja, uma tarefa só começava após a última tarefa ter sido bem sucedida e carregada na memória. Isso muitas vezes resultava em atraso no tempo de inicialização do computador.

No entanto, o systemd não foi projetado para ser rápido, mas para fazer mais coisas ao mesmo tempo (paralelismo) e, principalmente, faze-las corretamente, o que por sua vez, evitava todo o atraso visto no init. Em suma, com a evolução dos computadores, processos em paralelo deixam de ser um gargalo mas uma vantagem evolutiva dos hardwares.

Dentre os motivos para trocar o init pelo systemd, destaco:

• Design limpo, sólido e funcional.
• Processo de inicialização mais simples.
• Processamento paralelo durante o boot.
• Melhor API.
• Sintaxe da Unidade Simples.
• Capacidade de remover componentes opcionais.
• Poucas marcações de memória.
• Técnica aprimorada para expressar dependências.
• Instruções de inicialização escritas em um arquivo de
• Textos de configuração e não em scripts do shell.
• Faz uso do Unix Domain Socket.
• Programação de tarefas usando temporizadores de calendário do Systemd.
• Registro de eventos com journald.
• Escolha de eventos de sistema de log com systemd, bem como syslog.
• Os logs são armazenados em arquivos binários.
• O estado atual do systemd pode ser preservado para ser chamado mais tarde no futuro.
• Acompanha processos usando o cgroup do kernel e não o sistema PID.
• Login de usuários gerenciado pelo systemd-logind.
• Melhor integração com o Gnome Shell para interoperabilidade.

O systemd também trouxe suporte a recursos novos que até então o Init não possuía ou suportava, tais como:

• Gerenciamento de quotas
• Matar processos do usuário ao fazer logout
• Integração com SELinux
• Suportar HDD criptografado
• Início estático de módulos do kernel
• Iniciar serviços em paralelo no boot
• Controlar e limitar recursos por serviços
• Melhor gerenciamento de sub-processos filhos, diminuindo a incidência de processos Zumbis
• Permite analisar organicamente quando um daemon do sistema terminou de carregar durante o boot, permitindo encontrar aqueles que apresentarem problemas. – Com o comando $ systemd-analyze blame
  Dentre outros.

Se há pontos negativos do systemd, são eles:

• Unificação: Tudo em um só lugar.
  Isso pode trazer brechas no aspecto segurança e até tirar a liberdade dos desenvolvedores de sistema, já que não haverão outros daemons externos á familia systemd que funcionem concomitantemente no sistema.
• Não é KISS
  Não segue a filosofia “Keep it Simples, Stupid”, de manter um único sistema, no caso um único daemon, que seja simples e apenas funcional.
• Não segue ao padrão POSIX.

6. Discussão

No passado, Linus Torvalds, criador do kernel Linux, sentia que o desenvolvimento do systemd iria contra os usuários, enquanto que seu report de bugs não era nada bom. Também foi reportado que a filosofia do systemd era estranha e controlava os processos do sistema fora dele, num ponto externo. O mesmo foi mencionado por Patric Volkerding, dentre outros notáveis desenvolvedores e usuários do kernel Linux em fóruns Online.

De maneira resumida o systemd dividiu a comunidade Linux em 2 lados: Os que defende o init e os que preferem o systemd.

Mas as vantagens do SystemD se sobressaíram e a tendência é que o SystemD seja o padrão.

7. Conclusão

Qualquer coisa que rode sob PID = 1 deve ser sólido, bem feito e facilmente controlado pelos usuários. Afinal este é o Daemon mais importante do sistema! E é por isso que muitos torceram o nariz em trocar o init por algo novo.
Muitos usuários tambem acreditam que trocar o init pelo systemd não é nada mais nada menos que reinventar a roda e quaisquer mudanças nesse aspecto são pura necessidade de mexer no status quo.

Mas essa é a natureza diversa do Linux, é o que o torna poderoso; mudanças sempre acompanharam o desenvolvimento dos sistemas Linux e devemos saber apreciá-las, principalmente quando essas mudanças são  positivas e com boas intenções. Hoje é sabido o quanto o systemd é superior ao init e o quanto essa mudança está sendo benéfica.

#UrbanCompassPony

Fonte adaptada de:
Tecmint
BRLinux.org
e-tinet