Processos, Serviços e o Comando `systemctl`

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.

Fontes e leituras recomendadas

Documentação oficial

• systemd Documentation — freedesktop.org — Documentação oficial do systemd, incluindo referência completa do systemctl e do journalctl.
• systemctl man page — man7.org — Referência completa de todas as opções e sinais do systemctl.

Leitura técnica

• How To Use Systemctl — DigitalOcean — Tutorial prático da DigitalOcean cobrindo os casos de uso mais comuns do systemctl com exemplos reais.
• Understanding Systemd — Red Hat — Artigo do Red Hat explicando a filosofia do systemd e os comandos essenciais para administração de serviços.

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?

Exercício 2

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

Exercício 3

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

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

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?

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?