DevOps

Processos, Serviços e o Comando `systemctl`

Nathan Geeksman 4 visualizações

Artigo 4 — Processos, Serviços e o Comando systemctl

Módulo 1 · Fundamentos do Terminal e Linux Prof. Ricardo Matos — Dominando DevOps & Cloud em 1 Ano

Tudo Que Roda é um Processo

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.

O Que Vem a Seguir

No próximo artigo será apresentado o Shell Script — a habilidade que transforma comandos avulsos em automações reais. Tudo que foi aprendido até aqui sobre terminal, arquivos, permissões e processos se reunirá em scripts que executam tarefas complexas com um único comando.

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.

Artigo 4 de 52 · Módulo 1 — Fundamentos do Terminal e Linux Prof. Ricardo Matos · Série Dominando DevOps & Cloud em 1 Ano