Gerenciando serviços com systemd na prática

Praticamente toda distribuição moderna usa o systemd para gerenciar serviços. Ele é o primeiro processo que sobe no boot e o responsável por iniciar, supervisionar, reiniciar e registrar tudo o que roda no servidor. Saber operá-lo é pré-requisito para administrar servidores com confiança — e evita a instalação de gerenciadores de processo extras que fazem o que o sistema já faz.

O básico do controle

systemctl start nginx      # inicia agora
systemctl stop nginx       # para agora
systemctl restart nginx    # para e inicia
systemctl reload nginx     # recarrega a configuração sem derrubar
systemctl enable nginx     # inicia junto com o boot
systemctl disable nginx    # não inicia mais no boot
systemctl status nginx     # estado e últimas linhas de log

Dois comandos que valem mais do que parecem:

systemctl list-units --failed    # tudo que falhou
systemctl is-enabled nginx       # vai subir no boot?

O primeiro é a pergunta certa a fazer em um servidor com comportamento estranho. O segundo evita a surpresa clássica: o serviço está rodando porque alguém iniciou na mão, e some no próximo reinício.

Criando seu próprio serviço

Precisa que uma aplicação suba sozinha e reinicie se cair? Crie um arquivo em /etc/systemd/system/minha-app.service:

[Unit]
Description=Minha aplicacao
After=network.target postgresql.service
Wants=postgresql.service

[Service]
Type=simple
User=appuser
Group=appuser
WorkingDirectory=/opt/app
Environment=NODE_ENV=production
EnvironmentFile=-/etc/app/app.env
ExecStart=/usr/bin/node /opt/app/server.js
Restart=always
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Depois é só recarregar e ativar:

sudo systemctl daemon-reload
sudo systemctl enable --now minha-app

Vale entender as diretivas que mais importam:

• After define ordem: sobe depois da rede e do banco. Wants define dependência fraca: tenta subir o banco junto, mas não falha se ele não subir;
• User faz o serviço rodar sem privilégios. Aplicação não deve rodar como root — se for comprometida, o alcance do atacante fica limitado;
• EnvironmentFile com o - na frente significa "use se existir". É onde ficam senhas e chaves, em um arquivo com permissão restrita, fora do serviço;
• RestartSec=5 espera cinco segundos antes de tentar de novo, evitando um laço de reinício frenético que consome CPU.

Quando reiniciar sozinho não basta

Um serviço que falha na inicialização e é reiniciado para sempre entra em um laço que mascara o problema real. O systemd tem controle para isso:

[Unit]
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Restart=on-failure
RestartSec=10

Isso significa: no máximo 5 tentativas em 5 minutos. Depois disso o systemd desiste e deixa o serviço em estado de falha — que aparece no list-units --failed e no monitoramento. É bem melhor descobrir assim do que ter um serviço reiniciando de segundo em segundo por três dias.

Limitando o que o serviço pode consumir

Uma aplicação com vazamento de memória pode derrubar o servidor inteiro. O systemd impede isso com poucas linhas:

[Service]
MemoryMax=2G
CPUQuota=50%
TasksMax=256

Com MemoryMax, o processo é encerrado ao ultrapassar o limite — e reiniciado, se assim configurado — em vez de consumir toda a memória da máquina e levar junto o banco de dados e o SSH.

Endurecendo o serviço

Algumas diretivas restringem bastante o que uma aplicação comprometida consegue fazer, e custam apenas linhas de configuração:

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/minha-app
ProtectKernelTunables=true
RestrictSUIDSGID=true

O ProtectSystem=strict deixa todo o sistema de arquivos somente leitura para aquele serviço, exceto os caminhos listados em ReadWritePaths. Uma aplicação web comprometida com essa configuração simplesmente não consegue gravar em /etc nem instalar nada.

Timers: o substituto moderno do cron

Tarefas agendadas também podem viver no systemd, com uma vantagem grande: o resultado vai para o journal e aparece como falha se der errado — algo que o cron não faz bem.

# /etc/systemd/system/backup.timer
[Unit]
Description=Backup diario

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

O Persistent=true resolve um problema clássico do cron: se o servidor estava desligado no horário, a tarefa roda assim que ele volta, em vez de simplesmente ser pulada.

systemctl list-timers --all    # o que está agendado e quando roda

Investigando falhas

Quando algo não sobe, o journal responde:

journalctl -u minha-app -e          # do fim para trás
journalctl -u minha-app -f          # ao vivo
journalctl -u minha-app --since today -p err
systemd-analyze verify /etc/systemd/system/minha-app.service

O último comando valida o arquivo de unidade e aponta erros de sintaxe antes de você tentar iniciar. Poupa tempo em arquivos recém-escritos.

Por que isso vale a pena

Aprender systemd a fundo substitui um monte de gambiarra: script de inicialização caseiro, gerenciador de processo externo, laço de while true em segundo plano, cron sem monitoramento. Tudo isso passa a ser configuração declarativa, versionável, com log centralizado e visível para o monitoramento.

E, principalmente: quando o servidor reinicia às três da manhã, tudo volta na ordem certa, sozinho.