Gerir serviços com o systemd

Módulo 6: Serviços e registos · Tempo de leitura: 10 minutos

Objetivo de aprendizagem: Após esta lição, saberá iniciar, parar e recarregar serviços e configurá-los para arrancar com o sistema, ler o estado de um serviço e alterar com segurança uma definição de um serviço através de um drop-in.

Conceitos-chave: systemd, unit, service, systemctl, start, stop, restart, reload, enable, disable, --now, active, inactive, failed, systemctl --failed, drop-in, systemctl edit, daemon-reload, Restart=

Quem mantém tudo em funcionamento?

Num servidor correm dezenas de programas que têm de estar sempre disponíveis: o servidor SSH, o servidor web, uma base de dados, a sincronização da hora. Estes programas chamam-se serviços (services, ou daemons). Alguém tem de os iniciar no arranque, vigiá-los e reiniciá-los quando falham. No Debian, Ubuntu, AlmaLinux e Rocky Linux, é o systemd que o faz. É o primeiro programa que o kernel inicia (processo 1) e é ele que, a seguir, inicia todos os outros.

O systemd trabalha com units: descrições de algo que tem de gerir. Os tipos mais importantes:

Comunica com o systemd através do comando systemctl. Pode omitir a extensão .service: systemctl status nginx é o mesmo que systemctl status nginx.service.

Ler o estado

O comando que irá utilizar com mais frequência:

anna@web1:~$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-11-09 08:12:44 CET; 3h 2min ago
       Docs: man:nginx(8)
    Process: 902 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 905 (nginx)
      Tasks: 3 (limit: 2275)
     Memory: 4.1M (peak: 6.3M)
        CPU: 213ms
     CGroup: /system.slice/nginx.service
             ├─905 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             └─906 "nginx: worker process"

nov 09 08:12:44 web1 systemd[1]: Starting nginx.service - A high performance web server...
nov 09 08:12:44 web1 systemd[1]: Started nginx.service - A high performance web server...

Leia-o de cima para baixo:

• O círculo antes do nome é verde para um serviço em execução, branco para um serviço parado e vermelho para um serviço que falhou.
• Loaded indica onde se encontra o ficheiro da unit e se o serviço arranca com o sistema (enabled) ou não (disabled).
• Active indica se está em execução neste momento (active (running)), se está parado (inactive (dead)) ou se falhou (failed), e desde quando.
• Main PID e CGroup mostram que processos pertencem ao serviço.
• Em baixo aparecem as últimas linhas do registo do serviço. Muitas vezes, já aí se vê porque é que algo corre mal; pode ler mais com journalctl (lição 6.2).

Iniciar, parar, reiniciar e recarregar

anna@web1:~$ sudo systemctl start nginx      # iniciar agora
anna@web1:~$ sudo systemctl stop nginx       # parar agora
anna@web1:~$ sudo systemctl restart nginx    # parar e voltar a iniciar
anna@web1:~$ sudo systemctl reload nginx     # reler a configuração sem parar

A diferença entre restart e reload é importante na prática. Num restart, o serviço para por instantes: as ligações em curso são interrompidas e, se a nova configuração contiver um erro, o serviço deixa de arrancar e o seu site fica em baixo. Num reload, o serviço volta a ler a configuração enquanto continua em execução; se houver um erro na configuração, o nginx mantém a anterior. Assim, para o nginx, o Caddy, o SSH e o fail2ban, utilize reload após uma alteração de configuração e teste primeiro a configuração (nginx -t, sshd -t, fail2ban-client -t). Nem todos os serviços suportam reload; systemctl reload-or-restart escolhe por si.

No arranque: enable e disable

Iniciar e "iniciar no arranque" são duas coisas diferentes:

anna@web1:~$ sudo systemctl enable nginx         # passa a iniciar no arranque
anna@web1:~$ sudo systemctl disable nginx        # deixa de iniciar no arranque
anna@web1:~$ sudo systemctl enable --now nginx   # ambos: iniciar agora e no arranque
anna@web1:~$ systemctl is-enabled nginx
enabled

Um erro clássico: inicia um serviço com start, tudo funciona e, após o reinício seguinte (por exemplo, devido a uma atualização do kernel, lição 4.2), o serviço desapareceu. Por isso, para um serviço novo, utilize enable --now.

Se quiser ter a certeza de que um serviço nunca arranca, nem mesmo quando outro serviço o solicita, existe mask: sudo systemctl mask <dienst>. Para reverter, utilize unmask.

O que está errado?

Um único comando mostra todas as units que falharam:

anna@web1:~$ systemctl --failed
  UNIT                LOAD   ACTIVE SUB    DESCRIPTION
● php8.4-fpm.service  loaded failed failed The PHP 8.4 FastCGI Process Manager

1 loaded units listed.

Torne isto um hábito, por exemplo após cada reinício e cada atualização de versão (lição 4.3): a lista deve estar vazia. Depois de resolver o problema, elimina o aviso com sudo systemctl reset-failed.

Uma visão geral de todos os serviços em execução:

anna@web1:~$ systemctl list-units --type=service --state=running

Se estiver a correr algo que não conhece ou não utiliza, descubra o que é. Cada serviço desnecessário é superfície de ataque supérflua (lições 5.1 e 10.1).

Ficheiros de unit e drop-ins

Um ficheiro de unit é um ficheiro de texto. A versão do pacote encontra-se em /usr/lib/systemd/system/ (em sistemas mais antigos, /lib/systemd/system/). Esse ficheiro nunca deve ser alterado: uma atualização do pacote substitui-o. As suas próprias alterações são colocadas num drop-in: um pequeno ficheiro que contém apenas as linhas que pretende alterar. A forma mais simples de o fazer é:

anna@web1:~$ sudo systemctl edit nginx

Abre-se um editor com um espaço vazio entre duas linhas de comentário. O que escrever aí fica guardado em /etc/systemd/system/nginx.service.d/override.conf. Por exemplo: reiniciar o nginx automaticamente se parar inesperadamente.

[Service]
Restart=on-failure
RestartSec=5s

Depois de guardar, o systemctl edit recarrega automaticamente a configuração do systemd. Se editar um ficheiro de unit de outra forma, execute o seguinte:

anna@web1:~$ sudo systemctl daemon-reload
anna@web1:~$ sudo systemctl restart nginx

daemon-reload faz com que o systemd volte a ler os ficheiros de unit; o próprio serviço tem ainda de ser reiniciado para utilizar a alteração. Pode ver o resultado completo (original mais drop-ins) com systemctl cat nginx.

Restart=on-failure é um bom hábito para serviços importantes. Mas não esconda com isso um erro real: um serviço que falha e reinicia a cada cinco segundos deve ser investigado no registo. Após algumas falhas rápidas seguidas, o systemd deixa de reiniciar (o limite predefinido é de cinco arranques em dez segundos) e coloca o serviço em failed.

No AlmaLinux e no Rocky Linux

O systemd e o systemctl funcionam exatamente da mesma forma. Apenas os nomes dos serviços diferem por vezes: o serviço SSH chama-se sshd, o servidor web da distribuição chama-se httpd (Apache) ou nginx, e a firewall firewalld.

Na prática

O painel de VPS do seu fornecedor (na WebOké e noutros) pode desligar o servidor inteiro, reiniciá-lo ou "desligá-lo à força". Esta última opção equivale a tirar a ficha da tomada: os serviços não têm oportunidade de parar de forma ordenada e uma base de dados pode ficar danificada. Dentro do servidor, utilize sudo systemctl reboot ou sudo shutdown -h now e, no painel, o botão normal de encerrar ou reiniciar.

Resumo

• O systemd inicia e vigia todos os serviços; é controlado com systemctl.
• systemctl status mostra se um serviço está em execução, se arranca com o sistema e as últimas linhas do registo.
• start/stop/restart aplicam-se ao momento atual, enable/disable ao arranque; utilize enable --now para um serviço novo.
• Após uma alteração de configuração: primeiro testar, depois reload; systemctl --failed deve estar vazio.
• Nunca altere o ficheiro de unit de um pacote; utilize antes um drop-in com systemctl edit.

Questionário

Exercício

Exercício O6.1: Mapear os seus serviços. No seu servidor, faça uma lista de todos os serviços em execução (systemctl list-units --type=service --state=running) e verifique se systemctl --failed está vazio. Indique, para cada serviço, o que faz e se precisa dele. Escolha um serviço que não conhecia e descubra o que é (systemctl status, man). Em seguida, defina Restart=on-failure num drop-in para um serviço importante e confirme com systemctl cat que a definição está presente.

Para saber mais

• Manual systemctl(1): https://manpages.debian.org/trixie/systemd/systemctl.1.en.html
• Manual systemd.service(5) (Restart=): https://manpages.debian.org/trixie/systemd/systemd.service.5.en.html
• Manual systemd.unit(5) (drop-ins): https://manpages.debian.org/trixie/systemd/systemd.unit.5.en.html