SYSTEMD NO LINUX

AINDA TO EDITANDO GALERA!

SYSTEMD NO LINUX: ARQUITETURA, MODELO DE EXECUÇÃO E ANÁLISE OPERACIONAL AVANÇADA

1. INTRODUÇÃO

O systemd é o componente central dos sistemas Linux modernos, responsável pela inicialização (bootstrapping) e gerenciamento do espaço de usuário. Introduzido como substituto dos sistemas tradicionais como SysVinit e Upstart, o systemd redefine o paradigma de inicialização ao adotar um modelo baseado em unidades declarativas, paralelismo e controle explícito de dependências. Diferente de abordagens sequenciais, utiliza um modelo orientado a grafos, permitindo maior eficiência, previsibilidade e controle fino sobre o estado do sistema.

2. PAPEL DO SYSTEMD COMO PID 1

No processo de boot, o kernel Linux é carregado pelo bootloader e inicializa o espaço de usuário, executando o systemd como PID 1. Nesta posição, ele assume responsabilidades críticas:

• Reaproveitamento de processos órfãos: Adota processos cujo pai foi encerrado.

• Coleta de processos zumbis: Limpa a tabela de processos do sistema.

• Inicialização de serviços essenciais: Orquestra a subida de daemons de rede, storage e segurança.

• Gerenciamento de dependências: Garante que o sistema atinja o estado desejado (target) de forma consistente.

• Controle de estados: Gerencia a transição entre diferentes níveis de operação.

Nota de Infraestrutura: O fato de ser PID 1 implica que falhas críticas no systemd resultam em Kernel Panic, comprometendo a estabilidade total do sistema.

3. MODELO BASEADO EM UNITS

O systemd abstrai recursos do sistema em Units, que representam entidades gerenciáveis.

3.1 Tipos de Units e Funções Operacionais

+------------+----------------------------------------------------------+

| TIPO       | FUNÇÃO TÉCNICA E COMPORTAMENTO                           |

+------------+----------------------------------------------------------+

| Service    | Gerencia daemons e processos (ciclo de vida longo).      |

| Socket     | Ativação sob demanda (Socket Activation) via rede/IPC.   |

| Target     | Agrupamento lógico de unidades (Estados do sistema).     |

| Mount      | Gerencia pontos de montagem de sistemas de arquivos.     |

| Automount  | Montagem dinâmica de sistemas de arquivos sob demanda.   |

| Device     | Expõe dispositivos do kernel identificados via udev.     |

| Path       | Monitora arquivos/diretórios para disparar ações.        |

| Timer      | Agendamento preciso de tarefas (substituto do Cron).     |

| Slice      | Unidade de organização de cgroups para gestão de recursos.|

+------------+----------------------------------------------------------+

4. ESTRUTURA FORMAL DE UMA UNIT

Uma unit segue o formato padrão INI, dividida em seções lógicas:

[Unit]

Description=Serviço de Aplicação Crítica

After=network-online.target

Requires=network-online.target

[Service]

Type=simple

ExecStart=/usr/local/bin/app

Restart=on-failure

RestartSec=5s

[Install]

WantedBy=multi-user.target

• [Unit]: Metadados e dependências. Define a relação da unit com o resto do sistema.

• [Service]: Comportamento do processo (binário, sinais de restart, limites de recursos).

• [Install]: Regras de integração com targets para persistência no boot.

5. HIERARQUIA E PRIORIDADE DE CONFIGURAÇÃO

A resolução de configuração segue uma hierarquia de precedência para garantir que alterações administrativas não sejam sobrescritas por atualizações de pacotes:

1. /etc/systemd/system/ → Override administrativo (maior prioridade)

2. /run/systemd/system/ → Configurações voláteis criadas em runtime

3. /lib/systemd/system/ e /usr/lib/systemd/system/ → Unidades padrão do fornecedor (Vendor)

6. MECÂNICA DO SYSTEMCTL EDIT

Ao executar o comando systemctl edit , o systemd não abre o arquivo original. Ele cria um diretório e um arquivo de "puxadinho" (drop-in) que tem prioridade na árvore de carregamento.

6.1 Overriding e Drop-ins

O systemd permite sobrescrever diretivas sem modificar os arquivos originais através do comando:

systemctl edit nginx

Isso cria um diretório em /etc/systemd/system/nginx.service.d/override.conf, garantindo a imutabilidade do binário do vendor e a rastreabilidade das mudanças locais.

6.2 Edição Parcial (Recomendado)

O comando padrão abre um arquivo vazio. Tudo o que você escrever ali será mesclado (merge) com a configuração original.

Comando:
sudo systemctl edit nginx

Resultado:
Cria /etc/systemd/system/nginx.service.d/override.conf

6.3 Edição Integral (Full Override)

Se você precisa reconstruir a Unit do zero, ignorando completamente o arquivo do vendor:

Comando:
sudo systemctl edit --full nginx

Resultado:
Copia o arquivo original para /etc/systemd/system/nginx.service e abre para edição. O arquivo em /lib/ será totalmente ignorado.

7. GERENCIAMENTO AVANÇADO COM SYSTEMCTL

O systemctl é a interface de controle que interage com o PID 1 via D-Bus.

7.1 Operações de Ciclo de Vida (Análise de Impacto)

• start: Inicia a unidade e dependências. Falha se um Requires falhar.

• stop: Envia SIGTERM (padrão). Aguarda o TimeoutStopSec antes de forçar com SIGKILL.

• restart: Stop seguido de Start. Limpa estados de memória, mas interrompe conexões ativas.

• reload: Instruciona o serviço a ler configs (ex: SIGHUP) sem encerrar o processo.

7.2 Persistência e Segurança

• enable / disable: Cria ou remove links simbólicos em /etc/systemd/system/*.wants/. Define o que sobe no boot, mas não altera o estado do processo atual.

• enable --now: Atalho atômico que habilita e inicia o serviço simultaneamente.

• mask / unmask: Cria um link para /dev/null. Torna impossível iniciar o serviço (manual ou via dependência), prevenindo ativações acidentais.

• daemon-reload: Recarrega o gerenciador e reconstrói o grafo de dependências na memória. Indispensável após qualquer edição manual em arquivos .service.

8. TARGETS E ESTADOS DO SISTEMA

Targets representam estados agregados do sistema, substituindo os antigos Runlevels.

• multi-user.target: Modo multiusuário (CLI padrão para servidores)

• graphical.target: Interface gráfica e serviços de desktop

• rescue.target: Ambiente de manutenção (Single-user)

• network-online.target: Target de sincronização que garante que a stack IP esteja funcional

Comandos úteis:

• systemctl get-default: Verifica o alvo padrão de boot

• systemctl isolate rescue.target: Altera o estado do sistema em tempo real, encerrando serviços não vinculados ao novo alvo

9. MODELO DE DEPENDÊNCIAS E ORDENAÇÃO

Erro comum em infraestrutura: confundir O que deve rodar com Quando deve rodar.

9.1 Diretivas de Dependência (O Que)

• Wants: Dependência fraca. O sistema tenta subir o parceiro, mas ignora se falhar.

• Requires: Dependência forte. Se o parceiro falhar ou parar, esta unidade é encerrada.

• Requisite: Falha imediatamente se o parceiro não estiver ativo (não tenta iniciá-lo).

• BindsTo: Acoplamento máximo. Se o parceiro (ex: placa de rede) sumir, a unidade para.

9.2 Diretivas de Ordenação (Quando)

• After: Inicia esta unidade somente após a unidade especificada estar funcional.

• Before: Garante que esta unidade suba antes da unidade especificada.

Problema clássico (Race Condition): Usar apenas Requires=network-online.target. O correto é usar Requires + After para garantir que o serviço espere a conclusão da inicialização da rede.

10. LOGGING E OBSERVABILIDADE COM JOURNALD

O journald coleta logs estruturados e binários, permitindo consultas de alta performance.

• journalctl -u nginx: Logs específicos de uma unit

• journalctl -f: Visualização em tempo real (tail -f)

• journalctl -xe: Mostra as últimas mensagens com detalhes de erros do sistema

• journalctl -b: Filtra logs desde o último boot

• journalctl -k: Logs do kernel (dmesg), essencial para diagnosticar OOM Killer

11. ANÁLISE OPERACIONAL (COMO VALIDAR)

Como um analista sênior, você não confia apenas no comando; você valida o estado real do sistema.

11.1 Verificando a Hierarquia

Para saber quais arquivos estão compondo a configuração atual da Unit:

Bash
systemctl cat nginx

O output mostrará primeiro o arquivo original em /lib/ e, logo abaixo, o conteúdo do seu override.conf.

11.2 Auditando as Alterações

Para confirmar se as diretivas foram aplicadas corretamente na memória do systemd:

Bash
systemctl show nginx -p MemoryLimit -p Restart

11.3 Removendo Customizações

Se precisar reverter para o padrão de fábrica:

Bash
sudo rm -rf /etc/systemd/system/nginx.service.d/
sudo systemctl daemon-reload

12. LABORATÓRIO PRÁTICO AVANÇADO

12.1 Criação de serviço resiliente

sudo vim /etc/systemd/system/app.service

(Inserir conteúdo da seção 4)

12.2 Ciclo de Testes Operacionais

1. Validação: systemctl daemon-reload

2. Ativação: systemctl enable --now app

3. Simulação de Falha: kill -9 e observe o restart automático via journalctl -u app -f

4. Isolamento: systemctl isolate rescue.target para testar o comportamento em modo de manutenção

13. CASO DE USO REAL: AJUSTANDO O NGINX

Imagine que o Nginx padrão do seu repositório não tem uma política de restart agressiva e você precisa limitar o uso de memória via Cgroups.

Execute o comando:

Bash
sudo systemctl edit nginx

Insira apenas o que deseja alterar/adicionar:

Ini, TOML

[Service]

# Adicionando restart automático após 10 segundos em caso de falha

Restart=on-failure

RestartSec=10s

# Limitando recursos diretamente no PID 1

MemoryLimit=1G

CPUQuota=20%

Salve e saia. O systemd executará um daemon-reload automaticamente.

14. PONTO CEGO: LIMPANDO LISTAS

Atenção: Em algumas diretivas que aceitam múltiplas entradas (como ExecStart ou OnFailure), se você quiser substituir o comando original e não apenas adicionar um novo, você deve "limpar" a lista primeiro:

Ini, TOML

[Service]

ExecStart=

ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'

(O campo vazio limpa a configuração herdada do arquivo principal).

Se quiser, posso adaptar isso já no formato exato do seu blog (HTML, Notion, WordPress, etc.) sem você precisar ajustar nada manualmente.