⬅ Voltar ao Dashboard 1º Bimestre — Linux Básico
Aula 1.7

⚙️ Processos e Serviços

ps, top, kill, nice e systemctl — monitore e controle o que roda no seu servidor.

ps
Fotografia
dos processos
top
Monitor
em tempo real
kill
Sinais para
processos
sctl
Gerenciar
serviços

🤔 O que é um Processo?

Um processo é um programa em execução. Enquanto o programa é um arquivo estático no disco, o processo é a instância viva na memória — com recursos alocados, PID próprio e estado definido.

📚 Analogia: o programa é a receita de bolo escrita no papel; o processo é o bolo sendo feito no forno — dinâmico, consome energia e ocupa espaço.

🔢
PID (Process ID) Número único que identifica o processo no sistema
👨‍👦
PPID (Parent PID) PID do processo que o criou — o "pai"
👤
Dono Usuário que iniciou o processo; define permissões
📊
Estado Rodando, dormindo, parado ou zumbi

Estados dos processos

R 🏃 Running Executando na CPU agora
S 😴 Sleeping Aguardando evento ou I/O
T ⏸️ Stopped Pausado via Ctrl+Z
Z 🧟 Zombie Encerrado, pai não coletou
pstree — árvore de processos
# Ver quem é pai de quem user@srv:~$ pstree systemd─┬─apache2───5*[apache2] ├─sshd───sshd───bash───pstree └─mysql───mysqld # systemd é o processo 1 — pai de todos

💡 Processos Zombie não devem preocupar em condições normais. São apenas registros de processos que terminaram aguardando o pai coletar o código de saída. O sistema os limpa automaticamente.

📋 Comando ps — Fotografando Processos

O ps (process status) exibe uma fotografia instantânea dos processos. Ao contrário do top, não atualiza em tempo real — ideal para scripts e filtragens com grep.

ps — variações mais usadas
# Todos os processos — formato BSD (mais usado) user@srv:~$ ps aux USER PID %CPU %MEM STAT COMMAND root 1 0.0 0.1 Ss /sbin/init www-data 1423 0.5 2.1 S apache2 mysql 2156 1.2 5.4 Sl mysqld # Formato System V (mostra PPID) user@srv:~$ ps -ef # Processos de um usuário específico user@srv:~$ ps -u www-data # Buscar processo por nome (combo clássico) user@srv:~$ ps aux | grep nginx www-data 1423 0.5 2.1 S nginx: worker process # Obter PID direto pelo nome user@srv:~$ pgrep apache2 1423

Colunas do ps aux

USER Usuário dono do processo
PID ID único do processo
%CPU Porcentagem da CPU usada
%MEM Porcentagem de RAM usada
STAT Estado: R S T Z (e variantes)
COMMAND Comando que gerou o processo

📊 top e htop — Monitor em Tempo Real

Enquanto o ps tira uma foto, o top exibe um vídeo ao vivo do sistema, atualizando a cada poucos segundos. Ferramenta padrão para diagnóstico imediato.

top - 14:32:15 up 5 days | load average: 0.52, 0.58, 0.59 Tasks: 203 total, 1 running, 202 sleeping, 0 zombie %Cpu: 5.2 us, 2.1 sy, 92.1 id | Mem: 7976M total, 4521M used
PID USER %CPU %MEM COMMAND 2156 mysql 5.3 10.2 mysqld 1423 www-data 2.1 4.1 apache2 3456 usuario 1.0 2.1 node 892 root 0.3 0.5 sshd

Atalhos interativos dentro do top

P Ordenar por CPU
M Ordenar por memória
k Matar processo (pede PID)
u Filtrar por usuário
1 Ver cada CPU separado
q Sair do top

💡 O htop é a versão melhorada: barras coloridas de CPU/memória, suporte a mouse e navegação mais intuitiva. Instale com apt install htop.

💀 kill e killall — Sinais para Processos

O kill não serve apenas para "matar" processos — ele envia sinais que instruem o processo a executar determinada ação. Matar é apenas um dos efeitos possíveis.

15 SIGTERM "Termine, por favor" — o processo pode salvar dados antes de sair
9 SIGKILL "Encerre imediatamente" — não pode ser ignorado, sem salvar
1 SIGHUP "Recarregue configuração" — útil para não matar o serviço
kill, killall e pkill
# Terminar educadamente — SIGTERM (padrão) user@srv:~$ kill 1234 # Forçar encerramento — SIGKILL (último recurso!) user@srv:~$ kill -9 1234 # Recarregar configuração sem reiniciar — SIGHUP user@srv:~$ kill -1 1234 # Matar TODOS os processos com este nome user@srv:~$ killall firefox # Matar por nome (mais moderno, mesmo efeito) user@srv:~$ pkill firefox # Listar todos os sinais disponíveis user@srv:~$ kill -l

⚠️ SIGKILL (-9) não pode ser ignorado e encerra imediatamente sem salvar dados. Use sempre kill PID (SIGTERM) primeiro e recorra ao -9 só se o processo não responder.

⚖️ nice e renice — Prioridade de Processos

O Linux distribui o tempo de CPU conforme a prioridade de cada processo. O nice define a prioridade ao iniciar; o renice altera a de um processo já em execução.

Escala de Niceness (prioridade)
-20 -10 0 (padrão) +10 +19
🔥 -20 = Máxima prioridade (só root) 💤 +19 = Mínima prioridade (mais "bonzinho")
nice e renice
# Iniciar com baixa prioridade — não atrapalha o sistema user@srv:~$ nice -n 10 ./script.sh # Iniciar com alta prioridade (só root pode usar negativo) root@srv:~# nice -n -10 ./processo_critico # Mudar prioridade de processo em execução root@srv:~# renice -n 5 -p 1234 1234 (process ID) old priority 0, new priority 5 # Caso real: backup com prioridade mínima (não impacta o sistema) user@srv:~$ nice -n 19 tar -czf backup.tar.gz /home

⚠️ Apenas o root pode aumentar a prioridade (valores negativos de nice). Usuários comuns só podem diminuir a prioridade dos próprios processos (valores positivos).

🔧 systemctl — Gerenciando Serviços

Serviços (ou daemons) são processos que rodam permanentemente em background: Apache, MySQL, SSH, Nginx etc. No Linux moderno, todos são gerenciados pelo systemd via systemctl.

start / stop / restart / reload Controla o serviço agora
  • Efeito imediato
  • Não persiste após reboot
  • Uso: manutenção e testes
enable / disable Controla o serviço no boot
  • Não age imediatamente
  • Define comportamento permanente
  • Uso: configuração do servidor
systemctl start nginx Inicia o serviço agora
systemctl stop nginx Para o serviço agora
systemctl restart nginx Para e reinicia o serviço
systemctl reload nginx Recarrega config sem parar
systemctl enable ssh Habilita início automático no boot
systemctl disable ssh Desabilita início no boot
systemctl status nginx Estado atual + logs recentes
systemctl list-units Lista todos os serviços ativos
systemctl status — saída típica
root@srv:~# systemctl status nginx ● nginx.service - A high performance web server Loaded: loaded (/lib/systemd/system/nginx.service; enabled) Active: active (running) since Seg 2025-12-01 10:00:00 Main PID: 1423 (nginx) Tasks: 3 (limit: 4915) # Ver serviços que falharam root@srv:~# systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION mysql.service loaded failed failed MySQL Community Server # Quando aparece "failed", investigue com journalctl!

📓 journalctl — Logs Centralizados

O journalctl é a ferramenta para consultar os logs centralizados do systemd. Um único ponto de acesso com filtros poderosos — sem precisar procurar em vários arquivos de /var/log/.

-u serviço Logs de um serviço específico
-f Follow: em tempo real (tail -f)
-n 50 Últimas N linhas de log
--since "today" Logs a partir de uma data
-p err Só erros e críticos
-b Logs do boot atual
journalctl — exemplos práticos
# Logs do nginx em tempo real root@srv:~# journalctl -u nginx -f # Últimas 50 linhas root@srv:~# journalctl -u nginx -n 50 # Logs de hoje root@srv:~# journalctl --since "today" # Apenas erros e alertas críticos do sistema root@srv:~# journalctl -p err # Logs do boot atual root@srv:~# journalctl -b

💡 Combine journalctl -u nginx -f em uma aba com systemctl restart nginx em outra para ver os logs de reinicialização em tempo real — técnica essencial para diagnóstico.

🧪 Caso Prático: Servidor Lento

Fluxo de diagnóstico quando o servidor está lento ou com carga alta.

1
Verificar a carga geral
admin@srv:~$ uptime load average: 8.52, 7.21, 5.43 # Carga alta! Número maior que CPUs = problema
2
Identificar o processo culpado
admin@srv:~$ top -o %CPU 9876 95.2 python loop_infinito.py ← vilão!
3
Encerrar com SIGTERM primeiro
admin@srv:~$ kill 9876 # Aguardar alguns segundos... # Se não responder, usar SIGKILL: admin@srv:~$ kill -9 9876
4
Confirmar recuperação
admin@srv:~$ uptime load average: 0.52, 2.21, 4.43 # Carga normalizada!

🎯 Exercício — Arraste e Conecte

Arraste cada descrição para o comando correto de processos e serviços.

Descrição
Lista processos filtrando por nome
Força encerramento do processo 1234
Reinicia o serviço nginx
Habilita serviço para iniciar no boot
Executa script com prioridade reduzida
Monitora logs do nginx em tempo real
Comando
ps aux | grep nginx
kill -9 1234
systemctl restart nginx
systemctl enable ssh
nice -n 10 ./script.sh
journalctl -u nginx -f

❓ Verifique seu Conhecimento

Qual é a diferença entre systemctl start e systemctl enable?

ASão sinônimos — fazem a mesma coisa
Bstart é para serviços de sistema e enable para serviços de usuário
Cstart inicia agora; enable configura para iniciar no próximo boot
Denable inicia agora e start habilita no boot
✓ start/stop = efeito imediato, temporário. enable/disable = configuração de boot permanente. Para que um serviço inicie sempre: systemctl enable --now nginx (faz os dois de uma vez!).

Por que é recomendado usar kill (SIGTERM) antes de kill -9 (SIGKILL)?

APorque o SIGKILL não funciona em todos os processos
BO SIGTERM permite ao processo salvar dados; o SIGKILL encerra imediatamente sem salvar
CPorque o SIGKILL só pode ser usado pelo root
DNão há diferença prática entre os dois
✓ SIGTERM (15) é um pedido educado — o processo pode finalizar tarefas e salvar dados. SIGKILL (9) é forcóso e imediato: não pode ser ignorado, pode causar perda de dados ou arquivos corrompidos.

Um processo com nice -20 tem qual prioridade?

AMáxima prioridade — recebe mais tempo de CPU
BMínima prioridade — recebe menos tempo de CPU
CPrioridade padrão — igual a todos os outros
DO processo é colocado em modo zombie
✓ Na escala de niceness, -20 = máxima prioridade (só root pode), +19 = mínima. O padrão é 0. Use nice +19 para tarefas pesadas (backup, compilação) que não devem impactar outros processos.

🛠️ Atividade Prática — Monitoramento do Sistema

⏱ ~30 min 💻 Ubuntu Server / Terminal 📸 Tirar screenshot da saída
1
Use o top para ver processos em tempo real
Execute top. Pressione M para ordenar por memória e P para voltar a CPU. Tire screenshot com os 5 primeiros processos. Pressione q para sair.
2
Liste e conte processos com ps aux
Execute ps aux e observe a saída. Em seguida ps aux | wc -l para contar quantos processos estão rodando. Anote o número.
3
Crie e encerre um processo com kill
Execute sleep 300 & para criar um processo em background. Anote o PID exibido. Encerre com kill PID e confirme com ps aux | grep sleep.
4
Gerencie o SSH com systemctl
Execute em sequência: sudo systemctl status ssh, sudo systemctl restart ssh e novamente sudo systemctl status ssh. Verifique que o serviço reiniciou (PID mudou).
5
Investigue logs com journalctl
Execute sudo journalctl -u ssh -n 20 para ver as últimas 20 linhas do SSH. Você deve ver o registro do restart do passo anterior. Tire screenshot mostrando as entradas de log com o horário.
6
Teste o nice com uma tarefa pesada
Execute nice -n 19 find / -name "*.log" 2>/dev/null. Em outro terminal, observe com top que o processo find tem prioridade baixa (coluna NI = 19). Encerre com Ctrl+C.
📌 Para refletir: Um administrador Linux passa boa parte do dia monitorando processos, ajustando prioridades e gerenciando serviços. Dominar ps, top, kill, systemctl e journalctl é o que separa um operador de um verdadeiro SysAdmin.
⬅ Pacotes e Repositórios Sistema de Arquivos ➡