Processos, Serviços e o Comando `systemctl`

[33] Processos, Serviços e o Comando `systemctl`

Processos e serviços no Linux: leitura de ps aux e top, busca com pgrep, a diferença entre SIGTERM e SIGKILL, o ciclo de vida de serviços no systemd com systemctl, leitura de logs no journalctl e um diagnóstico real de serviço que não sobe.
DevOps

8 min de leitura

Cada programa em execução no Linux — seja um servidor web, um agente de monitoramento, um script de backup ou o próprio shell — existe no sistema como um processo. Todo processo tem um identificador numérico único chamado PID (Process ID), um dono, um estado e um consumo de recursos.

Saber como inspecionar, controlar e entender processos é uma habilidade cotidiana em DevOps. Quando uma aplicação trava, quando um servidor fica lento, quando um serviço não sobe — a investigação começa sempre pelos processos.

Inspecionando Processos em Execução

O comando mais direto para ver o que está rodando:

ps aux

A saída tem várias colunas. As mais importantes:

USER       PID  %CPU  %MEM  COMMAND
root         1   0.0   0.1  /sbin/init
www-data   842   0.3   1.2  nginx: worker process
usuario   1203   0.1   0.5  bash
  • USER — quem está rodando o processo
  • PID — identificador único do processo
  • %CPU e %MEM — consumo de recursos
  • COMMAND — o comando que originou o processo

Para uma visão dinâmica, atualizada em tempo real — equivalente ao Gerenciador de Tarefas do Windows:

top

Uma alternativa mais visual e informativa, se disponível:

htop

Para instalar o htop caso não esteja presente:

sudo apt install htop   # Debian/Ubuntu

Encontrando um Processo Específico

Combinando ps com grep:

ps aux | grep nginx

Ou de forma mais direta, com pgrep:

pgrep nginx          # Retorna apenas o PID
pgrep -l nginx       # Retorna PID e nome

Encerrando Processos com kill

O comando kill envia um sinal ao processo. O sinal mais comum é o SIGTERM (15) — pede educadamente que o processo se encerre, permitindo que ele faça limpeza antes de sair:

kill 1203            # Envia SIGTERM ao processo de PID 1203

Quando o processo não responde ao SIGTERM, usa-se o SIGKILL (9) — encerramento forçado, imediato, sem chance de limpeza:

kill -9 1203

O SIGKILL deve ser o último recurso. Processos encerrados abruptamente podem deixar arquivos de lock, conexões abertas ou dados incompletos.

Para encerrar todos os processos de um determinado nome:

pkill nginx

Serviços e o systemd

Na maioria das distribuições Linux modernas, os serviços — programas que rodam em segundo plano continuamente, como Nginx, PostgreSQL, SSH — são gerenciados pelo systemd, o sistema de inicialização padrão do Linux.

O systemd é responsável por:

  • Iniciar serviços quando o sistema liga
  • Reiniciar serviços que caíram
  • Gerenciar dependências entre serviços
  • Coletar os logs de cada serviço

A interface de linha de comando do systemd é o systemctl.

Gerenciando Serviços com systemctl

Os comandos fundamentais:

# Verifica o estado de um serviço
sudo systemctl status nginx

# Inicia um serviço
sudo systemctl start nginx

# Para um serviço
sudo systemctl stop nginx

# Reinicia completamente
sudo systemctl restart nginx

# Recarrega configuração sem derrubar o serviço
sudo systemctl reload nginx

# Habilita o serviço para iniciar automaticamente com o sistema
sudo systemctl enable nginx

# Desabilita o início automático
sudo systemctl disable nginx

# Habilita e já inicia de uma vez
sudo systemctl enable --now nginx

A saída do systemctl status merece atenção:

● nginx.service - A high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
     Active: active (running) since Mon 2025-03-10 10:00:00 UTC; 2h ago
   Main PID: 842 (nginx)

Os campos mais importantes são Active — que informa se o serviço está rodando — e Loaded, que mostra se está configurado para iniciar com o sistema (enabled) ou não (disabled).

Lendo Logs de Serviços com journalctl

O systemd centraliza os logs de todos os serviços em um diário chamado journal. O comando para consultá-lo é journalctl:

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

# Logs em tempo real (equivalente ao tail -f)
sudo journalctl -u nginx -f

# Logs das últimas 2 horas
sudo journalctl -u nginx --since "2 hours ago"

# Logs desde uma data específica
sudo journalctl -u nginx --since "2025-03-10 08:00:00"

Em produção, journalctl -u nome-do-servico -f é frequentemente o primeiro comando executado quando algo começa a falhar.

Um Cenário Real: Diagnosticando um Serviço que Não Sobe

Suponha que o Nginx foi instalado mas não está respondendo. O processo de investigação segue uma lógica clara:

# 1. Verifica o estado
sudo systemctl status nginx
# Resultado: "failed" — o serviço tentou subir e falhou

# 2. Lê os logs para entender o motivo
sudo journalctl -u nginx --since "10 minutes ago"
# Resultado: "nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)"

# 3. Descobre quem está usando a porta 80
sudo ss -tlnp | grep :80
# Resultado: mostra outro processo ocupando a porta

# 4. Encerra o processo conflitante ou reconfigura o Nginx
sudo kill -9 <PID do processo conflitante>

# 5. Sobe o Nginx novamente
sudo systemctl start nginx

# 6. Verifica se subiu corretamente
sudo systemctl status nginx

Esse fluxo — status, logs, investigação, ação, verificação — é repetido diariamente por profissionais de infraestrutura em todo o mundo.

Referências para Aprofundamento

Documentação oficial

Leitura técnica

Prática

  • Linux Upskill Challenge — Curso gratuito de 20 dias focado em administração de servidores Linux reais. Os dias 4 e 5 cobrem processos e serviços diretamente.
  • Over The Wire: Bandit — Os níveis intermediários envolvem processos em execução e serviços ativos.

Exercícios

Exercício 1

Qual a diferença entre kill 1203 e kill -9 1203? Por que o segundo deve ser o último recurso?

Ver resposta

✓ Resposta: kill sem argumento envia SIGTERM (15): um pedido para que o processo se encerre. Ele é avisado e tem a chance de fechar conexões, gravar o que está em buffer e remover arquivos de lock antes de sair. Já kill -9 envia SIGKILL, executado pelo kernel — o processo não é notificado e morre no ato. Por isso o -9 é o último recurso: o que ele deixa para trás são exatamente os locks presos, as conexões meio abertas e os dados gravados pela metade que causam o próximo problema.

Exercício 2

Qual a diferença entre systemctl restart nginx e systemctl reload nginx? Em que situação você escolheria cada um?

Ver resposta

✓ Resposta: restart derruba o serviço e sobe de novo: existe uma janela de indisponibilidade e as conexões em andamento caem. reload pede ao serviço que releia a configuração sem encerrar, mantendo o atendimento. Em produção, mudança de configuração — um novo virtual host no Nginx, um ajuste de limite — pede reload. O restart fica para quando o binário foi atualizado ou quando a alteração não é contemplada pelo reload.

Exercício 3

Qual a diferença entre systemctl start e systemctl enable? Que problema o enable --now resolve?

Ver resposta

✓ Resposta: start sobe o serviço agora e não diz nada sobre o próximo boot. enable registra o serviço para subir junto com o sistema, mas não o inicia neste momento. O erro clássico é dar apenas start: tudo funciona, o time comemora, e o serviço desaparece no primeiro reinício do servidor — geralmente semanas depois, quando ninguém associa mais uma coisa à outra. enable --now faz as duas coisas na mesma linha, eliminando esse esquecimento.

Exercício 4

Na saída abaixo, o que Loaded e Active informam? Por que consultar os dois é necessário?

● nginx.service - A high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
     Active: active (running) since Mon 2025-03-10 10:00:00 UTC; 2h ago
Ver resposta

✓ Resposta: Active responde sobre o presente: o serviço está rodando agora, e desde quando. Loaded, com o enabled no final, responde sobre o futuro: ele voltará sozinho no próximo boot. São perguntas independentes, e é por isso que os dois importam. Um serviço pode estar active (running) e disabled — no ar hoje, ausente depois do reinício. Ou inactive e enabled — parado agora, mas de volta ao reiniciar. Só os dois campos juntos respondem se o serviço está no ar e continuará estando.

Exercício 5

Reconstrua o diagnóstico do Nginx que não subia: qual era a causa, e o que cada comando do fluxo contribuiu para descobri-la?

Ver resposta

✓ Resposta: A causa era a porta 80 já ocupada por outro processo. O systemctl status deu o estado — failed, o serviço tentou subir e não conseguiu. O journalctl deu o motivo, na mensagem bind() to 0.0.0.0:80 failed (98: Address already in use). O ss -tlnp | grep :80 identificou qual processo detinha a porta. Encerrar o conflitante (ou reconfigurar a porta do Nginx) liberou o recurso, o start subiu o serviço e um novo status confirmou. O valor está na ordem — estado, causa, identificação, ação, verificação. Pular direto para a ação é o que produz o "reiniciei e voltou, mas não sei por quê", que reaparece na semana seguinte.

Exercício 6

Por que journalctl -u nginx -f costuma ser o primeiro comando quando um serviço começa a falhar? Em que ele difere de um tail -f em arquivo de log?

Ver resposta

✓ Resposta: -u filtra pela unidade do systemd e -f acompanha em tempo real, então o comando entrega apenas o que aquele serviço está produzindo, no instante em que produz. A diferença para o tail -f é o que você precisa saber de antemão: o journal centraliza a saída de todos os serviços gerenciados pelo systemd, com unidade, PID, prioridade e horário, sem que você precise descobrir onde aquele serviço grava — ou se ele grava em arquivo. O tail -f exige o caminho exato e só funciona quando existe um arquivo para seguir.

Comentários

Mais em DevOps

Instalação Manual do MySQL no Debian, Arch, Fedora e openSUSE
Instalação Manual do MySQL no Debian, Arch, Fedora e openSUSE

Instalação do MySQL pelo tarball genérico da Oracle em Debian, Arch, Fedora e…

Instalando e Rodando Seus Primeiros Containers
Instalando e Rodando Seus Primeiros Containers

Docker na prática: instalação pelo repositório oficial, uso sem sudo…

Compute, Storage e Redes no Azure
Compute, Storage e Redes no Azure

Os serviços que formam a base de qualquer aplicação no Azure, com o detalhe…