Administração de Sistemas

Systemd: gerenciamento de serviços, units e journald

• 6 min de leitura

Systemd: gerenciamento de serviços, units e journald
Systemd é um sistema de init (inicialização) e gerenciador de serviços projetado para substituir o antigo SysVinit, que dominava as distribuições Linux desde os anos 1980. Criado por Lennart Poettering e Kay Sievers em 2010, o Systemd trouxe paralelismo na inicialização, dependências explícitas entre serviços e uma arquitetura modular baseada em "units". Seu objetivo principal é acelerar o boot, simplificar o gerenciamento de processos e unificar a configuração do sistema.

Systemd: gerenciamento de serviços, units e journald

1. Introdução ao Systemd e seu papel no Linux moderno

Systemd é um sistema de init (inicialização) e gerenciador de serviços projetado para substituir o antigo SysVinit, que dominava as distribuições Linux desde os anos 1980. Criado por Lennart Poettering e Kay Sievers em 2010, o Systemd trouxe paralelismo na inicialização, dependências explícitas entre serviços e uma arquitetura modular baseada em "units". Seu objetivo principal é acelerar o boot, simplificar o gerenciamento de processos e unificar a configuração do sistema.

A arquitetura do Systemd é centrada em três conceitos: units (unidades de configuração), targets (agrupamentos lógicos de units) e o gerenciador de sistema (PID 1). Ele se integra profundamente ao kernel Linux, utilizando cgroups para controle de processos, journald para logs binários e timedatectl para gerenciamento de tempo. Hoje, é adotado por praticamente todas as principais distribuições, incluindo Fedora, Ubuntu, Debian, Arch Linux e openSUSE.

2. Units do Systemd: tipos e estrutura

Units são os blocos de construção do Systemd. Cada unit representa um recurso gerenciável, definido por um arquivo de configuração com extensão específica. Os principais tipos são:

  • service: Gerencia processos (daemons, aplicações).
  • socket: Ativa serviços sob demanda via socket de rede ou Unix.
  • timer: Agendamento baseado em tempo (substituto do cron).
  • mount: Pontos de montagem de sistemas de arquivos.
  • target: Agrupamento lógico de units (equivalente a runlevels).
  • path: Ativa serviços quando arquivos ou diretórios mudam.

A estrutura de um arquivo .service segue seções padronizadas:

[Unit]
Description=Meu Serviço Personalizado
After=network.target
Wants=postgresql.service

[Service]
Type=simple
ExecStart=/usr/bin/meu-servico --config /etc/meu-servico.conf
ExecStop=/usr/bin/meu-servico --stop
Restart=on-failure
User=meuusuario
WorkingDirectory=/opt/meu-servico

[Install]
WantedBy=multi-user.target

As units residem em três diretórios principais, com precedência decrescente:

  • /etc/systemd/system/ — configurações do administrador (sobrescreve demais).
  • /run/systemd/system/ — units geradas em tempo de execução.
  • /usr/lib/systemd/system/ — units fornecidas por pacotes instalados.

3. Gerenciamento de serviços com systemctl

O comando systemctl é a ferramenta central para interagir com o Systemd. Abaixo, os comandos mais utilizados:

# Iniciar, parar, reiniciar e recarregar um serviço
systemctl start nginx.service
systemctl stop nginx.service
systemctl restart nginx.service
systemctl reload nginx.service   # Recarrega configuração sem interromper

# Habilitar e desabilitar inicialização automática
systemctl enable nginx.service   # Ativa no boot
systemctl disable nginx.service  # Desativa no boot

# Status e análise
systemctl status nginx.service   # Informações detalhadas
systemctl is-active nginx.service  # Retorna active/inactive
systemctl is-enabled nginx.service # Retorna enabled/disabled
systemctl list-units --type=service  # Lista serviços ativos
systemctl list-unit-files --type=service  # Lista todos os arquivos .service

# Gerenciamento de dependências
systemctl list-dependencies nginx.service  # Mostra dependências

Dependências são declaradas nas diretivas After, Before, Wants e Requires. After=network.target garante que o serviço inicie após a rede estar pronta, enquanto Requires=postgresql.service faz o Systemd iniciar o PostgreSQL antes do serviço principal.

4. Criação e customização de units de serviço

Vamos criar um serviço personalizado que executa um script simples. Primeiro, o arquivo de serviço:

# /etc/systemd/system/meu-script.service
[Unit]
Description=Executa script de exemplo
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/meu-script.sh
ExecStop=/bin/kill -s QUIT $MAINPID
Restart=on-failure
RestartSec=5
User=nobody
Group=nogroup
WorkingDirectory=/tmp
Environment=MEU_VAR=exemplo
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Após criar o arquivo, ative e inicie:

sudo systemctl daemon-reload
sudo systemctl enable meu-script.service
sudo systemctl start meu-script.service

Para sobrescrever diretivas sem modificar o arquivo original, use drop-ins:

sudo systemctl edit meu-script.service

Isso cria o diretório /etc/systemd/system/meu-script.service.d/ com um arquivo override.conf. Exemplo de override:

[Service]
Restart=always
RestartSec=10

5. Targets e níveis de execução (runlevels)

Targets são grupos de units que representam estados do sistema. Eles substituem os runlevels do SysVinit:

Runlevel tradicional Target Systemd Descrição
0 poweroff.target Desligamento
1 rescue.target Modo de recuperação (single)
2,3,4 multi-user.target Modo multiusuário sem gráfico
5 graphical.target Modo gráfico
6 reboot.target Reinicialização

Para alterar o target padrão:

# Ver target atual
systemctl get-default

# Definir multi-user como padrão (sem interface gráfica)
sudo systemctl set-default multi-user.target

# Transição imediata para outro target
sudo systemctl isolate rescue.target   # Modo de recuperação

6. Timers do Systemd: agendamento moderno

Timers substituem o crontab com vantagens: logs integrados ao journald, dependências entre serviços, precisão de segundos e execução após eventos (boot, ativação de serviço). Estrutura de um timer:

# /etc/systemd/system/backup-diario.timer
[Unit]
Description=Timer para backup diário
Requires=backup-diario.service

[Timer]
OnCalendar=daily
Persistent=true
Unit=backup-diario.service

[Install]
WantedBy=timers.target

E o serviço correspondente:

# /etc/systemd/system/backup-diario.service
[Unit]
Description=Executa backup diário

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
User=root

Ative o timer (não o serviço):

sudo systemctl daemon-reload
sudo systemctl enable backup-diario.timer
sudo systemctl start backup-diario.timer

Outros agendamentos comuns:

OnCalendar=Mon..Fri 02:00:00   # Dias úteis às 2h
OnBootSec=10min                # 10 minutos após boot
OnUnitActiveSec=1h             # 1 hora após última ativação

7. Journald: sistema de logs centralizado

O journald coleta logs do kernel, serviços e aplicações em formato binário, armazenado em /var/log/journal/ (persistente) ou /run/log/journal/ (volátil). Principais comandos:

# Visualizar logs completos
journalctl

# Logs desde o último boot
journalctl -b

# Logs de um serviço específico
journalctl -u nginx.service

# Logs com prioridade (0=emerg, 1=alert, 2=crit, 3=err, 4=warning)
journalctl -p err -u nginx.service

# Logs em tempo real (modo follow)
journalctl -f

# Logs por período
journalctl --since "2025-01-01 00:00:00" --until "2025-01-02 23:59:59"

# Últimas N linhas
journalctl -n 50

# Saída em formato JSON
journalctl -o json-pretty

Para persistência dos logs, edite /etc/systemd/journald.conf:

[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=500M
SystemMaxFileSize=100M
MaxRetentionSec=1month

Após alterar, reinicie o journald:

sudo systemctl restart systemd-journald

8. Boas práticas e resolução de problemas

Depuração de serviços com falha:

# Ver status detalhado
systemctl status meu-servico.service

# Últimas linhas do journal para o serviço
journalctl -xe -u meu-servico.service

# Logs completos do serviço
journalctl -u meu-servico.service --no-pager

Monitoramento de recursos com cgroups:

# Limitar CPU e memória no arquivo .service
[Service]
CPUQuota=50%          # Máximo 50% de uma CPU
MemoryMax=256M        # Limite de memória
TasksMax=100          # Máximo de processos filhos

Segurança com sandboxing:

[Service]
ProtectSystem=strict     # Sistema de arquivos raiz read-only
PrivateTmp=true          # /tmp isolado
NoNewPrivileges=true     # Impede escalonamento de privilégios
ProtectHome=true         # /home inacessível
CapabilityBoundingSet=   # Remove todas as capacidades

Verificação de erros comuns:

# Verificar sintaxe das units
systemd-analyze verify /etc/systemd/system/*.service

# Analisar tempo de boot
systemd-analyze blame

# Listar dependências circulares
systemd-analyze dot | dot -Tsvg > dependencias.svg

Referências

💬 Comentários
Mais em Administração de Sistemas