O que é systemd: como funciona e como gerenciar serviços no Linux

O systemd é o sistema de inicialização e gerenciador de serviços usado pela maioria das distribuições Linux atuais: Debian, Ubuntu, Fedora, RHEL e suas derivadas. Depois da inicialização, o kernel executa o systemd como primeiro processo, com PID 1, e é ele quem sobe a rede, monta os discos, inicia o servidor web, o banco de dados e todos os demais serviços. Em resumo, o systemd é o «gerente» que sabe quais serviços devem estar rodando, em que ordem iniciá-los e o que fazer quando um serviço cai.

Para confirmar se o seu sistema usa systemd, basta:

$ ps -p 1 -o comm=
systemd

Por que o systemd surgiu

Antes, o Linux usava o SysV init: um conjunto de scripts de shell em /etc/init.d/ executados um após o outro. O modelo era compreensível, mas lento e frágil. Cada script escrevia seu próprio arquivo PID, decidia sozinho como verificar se o processo estava vivo, e o reinício de um serviço que caía precisava ser configurado à parte.

O systemd resolve esses problemas de forma centralizada:

• Inicialização paralela.Serviços sem dependências entre si são iniciados ao mesmo tempo, e o boot fica mais rápido.
• Dependências e ordem.A descrição do serviço declara o que ele precisa (por exemplo, a rede) e depois de que ele deve iniciar.
• Supervisão.O systemd conhece todos os processos de um serviço por meio de cgroups e pode reiniciá-lo quando ele falha.
• Registro unificado.A saída de todos os serviços é coletada pelo journald, e os logs são consultados com um único comando.
• Interface unificada.Qualquer serviço é gerenciado do mesmo jeito: systemctl start|stop|restart|status.

Além do gerenciador de serviços, o projeto systemd inclui outros componentes: journald (logs), logind (sessões de usuários), timesyncd (sincronização de hora), resolved (DNS) e networkd (rede). Nem todas as distribuições usam todos eles, mas o systemd como PID 1 e o journald estão presentes quase em qualquer lugar.

Unidades: os blocos do systemd

Tudo o que o systemd controla é descrito por unidades (units). Uma unidade é um arquivo de texto no formato INI, e o tipo da unidade é definido pela extensão do arquivo.

Onde ficam os arquivos de unidade

Os arquivos de unidade ficam em vários diretórios, e cada um tem uma prioridade:

• /usr/lib/systemd/system/ (no Debian e no Ubuntu também /lib/systemd/system/): unidades instaladas por pacotes. Não as edite diretamente, porque a atualização do pacote sobrescreve suas alterações.
• /etc/systemd/system/: unidades e substituições feitas pelo administrador. Têm a prioridade mais alta.
• /run/systemd/system/: unidades temporárias criadas durante a execução.

Para ver o conteúdo final de uma unidade com todas as substituições, use systemctl cat nginx.service.

Targets no lugar dos níveis de execução

Os targets substituíram os antigos runlevels. O multi-user.target é o modo servidor comum, sem interface gráfica; o graphical.target inclui a interface gráfica; o rescue.target é o modo de recuperação para um único usuário. O target padrão é exibido por systemctl get-default e alterado com systemctl set-default multi-user.target.

systemctl: gerenciando serviços

O systemctl é a principal ferramenta para trabalhar com o systemd. A maioria dos comandos que alteram o estado do sistema exige sudo.

Como ler o systemctl status

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-10-12 09:14:03 UTC; 2h 5min ago
       Docs: man:nginx(8)
   Main PID: 812 (nginx)
      Tasks: 3 (limit: 2307)
     Memory: 6.1M
        CPU: 154ms
     CGroup: /system.slice/nginx.service
             ├─812 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─813 "nginx: worker process"
             └─814 "nginx: worker process"

A linha Loaded mostra de onde vem o arquivo de unidade e se a inicialização automática está ativa (enabled). A linha Active mostra o estado atual: active (running), inactive (dead) ou failed. O bloco CGroup lista todos os processos do serviço: é assim que o systemd sabe o que pertence a ele.

A diferença entre enable e start

Esta é uma confusão frequente. O start inicia o serviço agora, mas ele não sobe sozinho depois de uma reinicialização. O enable cria um link simbólico no diretório do target (por exemplo, /etc/systemd/system/multi-user.target.wants/), e o serviço passa a iniciar com o sistema, mas não é iniciado agora. Em geral você precisa dos dois, por isso se usa enable --now.

Existe ainda um terceiro estado, o mask. O comando systemctl mask service liga a unidade a /dev/null, e ela não pode ser iniciada nem manualmente nem como dependência. É útil quando você quer desativar um serviço com garantia.

journalctl: logs dos serviços

Tudo o que um serviço escreve em stdout e stderr é capturado pelo systemd-journald e gravado em um log binário, junto com metadados: nome da unidade, PID, prioridade e horário. O journal é lido com o comando journalctl.

journalctl -u nginx              # logs de um serviço
journalctl -u nginx -f           # acompanha em tempo real, como tail -f
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx -n 50        # últimas 50 linhas
journalctl -b                    # desde a inicialização atual
journalctl -b -1                 # a inicialização anterior
journalctl -p err -b             # apenas erros e níveis mais graves
journalctl -k                    # mensagens do kernel
journalctl --disk-usage          # espaço ocupado pelo journal

A opção -p filtra pela prioridade do syslog: emerg, alert, crit, err, warning, notice, info, debug. O nível indicado inclui tudo o que for mais grave do que ele.

Manter o journal após a reinicialização

Se o diretório /var/log/journal não existir e o journald.conf tiver Storage=auto, o journal fica apenas na memória (/run/log/journal) e some ao reiniciar. Para torná-lo permanente, defina Storage=persistent ou crie o diretório e reinicie o journald. O tamanho é limitado por SystemMaxUse=, e os registros antigos podem ser apagados com journalctl --vacuum-time=2weeks ou --vacuum-size=500M.

O journald costuma trabalhar em par com o rsyslog: o journal repassa as mensagens ao rsyslog, que grava arquivos de texto tradicionais em /var/log/ e pode enviar os logs para um servidor central.

Iniciando um serviço próprio: exemplo de arquivo de unidade

Suponha que você tenha uma aplicação (um script ou um binário) que precisa ficar sempre no ar, subir com o sistema e reiniciar caso caia. Crie o arquivo /etc/systemd/system/myapp.service:

[Unit]
Description=My web application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/opt/myapp/bin/server --port 8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Explicando cada seção:

• [Unit]: descrição e dependências. After= define apenas a ordem; Wants= é uma dependência fraca (tenta puxar a unidade, mas não falha se ela não subir). Dependência forte usa Requires=.
• [Service]: como iniciar. Type=simple significa que o processo de ExecStart é o próprio serviço e não vai para o segundo plano. User= executa com um usuário sem privilégios. Restart=on-failure reinicia o serviço se ele terminar com erro, após RestartSec segundos.
• [Install]: o que o enable faz. WantedBy=multi-user.target significa «iniciar em uma inicialização normal».

Aplicando a configuração:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo systemctl daemon-reload
sudo systemctl enable --now myapp
systemctl status myapp
journalctl -u myapp -f

Erros comuns em arquivos de unidade

• Caminho relativo em ExecStart.O caminho do programa deve ser absoluto. O systemd não procura comandos no PATH do usuário como faz o shell.
• Esquecer o daemon-reload.Depois de editar o arquivo, o systemd continua usando a versão antiga e avisa isso no status.
• O daemon vai para o segundo plano.Se o programa faz fork por conta própria, mas está configurado como Type=simple, o systemd entende que o serviço terminou. Execute o programa em primeiro plano, ou use Type=forking com PIDFile=.
• Variáveis de ambiente do perfil.O serviço não enxerga o ~/.bashrc nem o /etc/profile. As variáveis são definidas com Environment= ou EnvironmentFile=.

Alterando um serviço de pacote sem editar o arquivo original

Para mudar os parâmetros de um serviço vindo de um pacote sem tocar no arquivo dele, use um drop-in:

sudo systemctl edit nginx

O editor abre, e as alterações são salvas em /etc/systemd/system/nginx.service.d/override.conf. Por exemplo, você pode acrescentar ali uma seção [Service] com Restart=always. Ao sair do editor, o systemd relê a configuração sozinho.

Temporizadores do systemd no lugar do cron

O temporizador (timer) é uma unidade que aciona um serviço de mesmo nome em um agendamento. Em relação ao cron, ele tem o log da tarefa no journal, permite declarar dependências e pode recuperar execuções perdidas (Persistent=true). Um exemplo de backup diário:

# /etc/systemd/system/backup.service
[Unit]
Description=Nightly backup

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

# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup daily

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers

Para testar a expressão de OnCalendar, use systemd-analyze calendar "*-*-* 03:00:00": o comando mostra quando será a próxima execução.

Diagnosticando o tempo de inicialização

O systemd registra o horário de início de cada unidade, então é fácil analisar uma inicialização lenta:

systemd-analyze                  # tempo total de inicialização
systemd-analyze blame            # unidades ordenadas pelo tempo de início
systemd-analyze critical-chain   # a cadeia que atrasou a inicialização
systemd-analyze verify /etc/systemd/system/myapp.service   # verifica o arquivo de unidade

Conclusão

O systemd é o PID 1 e o gerenciador de serviços do Linux moderno. Ele descreve tudo com unidades, é controlado pelo systemctl, reúne os logs em um journal lido pelo journalctl e pode executar tarefas com temporizadores no lugar do cron. Para usá-lo com segurança basta dominar status, enable --now e journalctl -u, além de saber escrever um arquivo de unidade simples com Restart=on-failure. O systemd, o journald e o gerenciamento de logs são explicados com prática no curso de Linux.