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 processoPID— identificador único do processo%CPUe%MEM— consumo de recursosCOMMAND— 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
- systemd Documentation — freedesktop.org — Documentação oficial do systemd, incluindo referência completa do
systemctle dojournalctl. - 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
systemctlcom 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?
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.