systemd

fundamentos

Gerenciar serviços

Comando	O que faz
`systemctl status <unit>`	Estado, PID, últimas linhas de log
`systemctl start/stop/restart <unit>`	Controla a execução
`systemctl reload <unit>`	Recarrega config sem derrubar (se suportado)
`systemctl enable --now <unit>`	Habilita no boot e inicia agora
`systemctl disable --now <unit>`	Desabilita e para
`systemctl is-active <unit>` / `is-enabled`	Respostas para script
`systemctl list-units --type=service --state=running`	O que está rodando
`systemctl list-unit-files --state=enabled`	O que sobe no boot
`systemctl --failed`	O que falhou
`systemctl daemon-reload`	Recarrega definições após editar unit
`systemctl cat <unit>`	Mostra a unit efetiva, com overrides
`systemctl edit <unit>`	Cria override em `/etc/systemd/system/<unit>.d/`
`systemctl show <unit> -p ExecStart`	Consulta propriedade específica

Sempre daemon-reload depois de alterar arquivos de unit — sem isso, o systemd continua com a definição antiga.

Escrever uma unit

/etc/systemd/system/minha-api.service:

[Unit]
Description=API da loja
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=60
StartLimitBurst=5

[Service]
Type=simple
User=app
Group=app
WorkingDirectory=/opt/minha-api
EnvironmentFile=/etc/minha-api/env
ExecStart=/opt/minha-api/bin/api
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
TimeoutStopSec=30

# endurecimento — barato e eficaz
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/minha-api
CapabilityBoundingSet=

[Install]
WantedBy=multi-user.target

`Type=`	Quando usar
`simple`	O processo não faz fork (padrão da maioria)
`exec`	Como `simple`, mas espera o exec ter sucesso
`forking`	O processo tradicional que faz fork e o pai sai
`oneshot`	Executa e termina (com `RemainAfterExit=yes` para “ficar ativo”)
`notify`	O serviço avisa o systemd quando está pronto

`Restart=`	Comportamento
`no`	Não reinicia (padrão)
`on-failure`	Reinicia em saída diferente de zero ou sinal — a escolha usual
`always`	Reinicia sempre, inclusive após parada limpa

StartLimitBurst evita laço de reinício infinito consumindo o host.

Timers no lugar de cron

/etc/systemd/system/backup.service e backup.timer:

# backup.service
[Unit]
Description=Backup diário

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

# backup.timer
[Unit]
Description=Executa o backup diariamente

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true          # executa se a máquina estava desligada na hora
RandomizedDelaySec=300   # espalha a carga entre hosts
AccuracySec=1min

[Install]
WantedBy=timers.target

systemctl enable --now backup.timer
systemctl list-timers --all              # próxima e última execução
systemd-analyze calendar "*-*-* 02:30:00"  # valida a expressão
systemctl start backup.service            # executa agora, para testar

Vantagens sobre o cron: log integrado ao journal, dependências, Persistent, jitter e limite de recursos.

Logs com journalctl

Comando	O que faz
`journalctl -u <unit> -f`	Segue o log da unidade
`journalctl -u <unit> --since "1 hour ago"`	Janela de tempo
`journalctl -u <unit> -n 200 --no-pager`	Últimas linhas
`journalctl -p err -b`	Erros do boot atual
`journalctl -b -1`	Boot anterior
`journalctl -k`	Mensagens do kernel
`journalctl -u <unit> -o json-pretty`	Saída estruturada
`journalctl _PID=1234`	Por PID
`journalctl --disk-usage`	Espaço ocupado
`journalctl --vacuum-time=7d`	Limpa por idade
`journalctl --vacuum-size=500M`	Limpa por tamanho

Dependências e ordem

Diretiva	Efeito
`After=` / `Before=`	Ordem de inicialização, não dependência
`Requires=`	Dependência forte: se falhar, esta unit falha
`Wants=`	Dependência fraca: tenta iniciar, tolera falha
`BindsTo=`	Para junto se a outra parar
`Conflicts=`	Não podem rodar juntas
`PartOf=`	Reinicia junto com a unidade pai

systemctl list-dependencies <unit>
systemd-analyze critical-chain <unit>     # o que atrasa o boot
systemd-analyze blame                     # ranking de tempo de boot

Erro comum: usar After= achando que garante dependência. After só ordena; para exigir, combine com Requires ou Wants.

Limites de recurso

[Service]
MemoryMax=512M
CPUQuota=50%
TasksMax=100
LimitNOFILE=65535

systemd-cgtop mostra o consumo por unidade, agrupado por cgroup.

Pegadinhas

Esquecer daemon-reload após editar a unit.
Editar arquivo em /lib/systemd/system/ (é sobrescrito na atualização do pacote): use systemctl edit ou /etc/systemd/system/.
Restart=always mascara um serviço que morre em laço — olhe o journal.
Type errado faz o systemd achar que o serviço não subiu (ou que subiu antes da hora).
EnvironmentFile não interpreta shell: nada de $OUTRA_VAR nem aspas com expansão.
Timer sem Persistent=true perde a execução se a máquina estiver desligada.