⬅ 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
Árvore de processos — systemd como pai de todos (animado)
systemd PID 1 apache2 PID 423 w1 w2 w3 sshd PID 892 mysqld PID 2156 cron PID 301

💡 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
ps aux — uso de CPU e memória por processo (animado ao vivo)
mysqld
%CPU
%MEM
apache2
%CPU
%MEM
node
%CPU
%MEM
sshd
%CPU
%MEM
init
%CPU
%MEM

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
Fluxo de sinal — SIGTERM (15) depois SIGKILL (9) se necessário (animado)
terminal $ kill PID SIGTERM (15) processo PID 1234 SIGKILL (9) último recurso processo encerrado usuário/admin salva dados sem salvar
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
Ciclo de vida de um serviço — estados e transições (animado)
start OK reload stop / disable erro → failed stopped inativo starting iniciando running ● ativo reloading recarrega
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 -f — log em tempo real aparecendo (animado)
Mar 22 14:10:01 servidor sshd[683]: Server listening on 0.0.0.0 port 22.
Mar 22 14:23:17 servidor sshd[683]: Accepted publickey for admin from 192.168.1.5
Mar 22 14:31:04 servidor nginx[1423]: 192.168.1.10 GET /index.html 200
Mar 22 14:33:44 servidor systemd[1]: Stopping OpenBSD Secure Shell server...
Mar 22 14:33:45 servidor systemd[1]: Started OpenBSD Secure Shell server.
Mar 22 14:33:45 servidor sshd[5103]: Server listening on 0.0.0.0 port 22.
Mar 22 14:41:02 servidor mysql[2156]: [ERROR] Can't open file: './db/table.MYI'
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
Abra o monitor interativo, ordene por memória e depois por CPU. Tire screenshot com os 5 primeiros processos:
bash — passo 1
usuario@servidor:~$ top # dentro do top: # M — ordena por uso de memória # P — ordena por uso de CPU # q — sai
2
Liste e conte processos com ps aux
Liste todos os processos e conte quantos estão rodando no momento. Anote o número:
bash — passo 2
usuario@servidor:~$ ps aux USER PID %CPU %MEM VSZ RSS COMMAND root 1 0.0 0.3 169512 12288 /sbin/init root 2 0.0 0.0 0 0 [kthreadd] # conta o total de processos em execução usuario@servidor:~$ ps aux | wc -l 112
3
Crie e encerre um processo com kill
Dispare um processo em background, anote o PID, encerre-o e confirme que sumiu:
bash — passo 3
usuario@servidor:~$ sleep 300 & [1] 4821 usuario@servidor:~$ kill 4821 [1]+ Terminated sleep 300 usuario@servidor:~$ ps aux | grep sleep
4
Gerencie o SSH com systemctl
Verifique o status, reinicie o serviço e confirme que o PID mudou após o restart:
bash — passo 4
usuario@servidor:~$ sudo systemctl status ssh ● ssh.service - OpenBSD Secure Shell server Active: active (running) since ... ; 2h ago Main PID: 683 (sshd) usuario@servidor:~$ sudo systemctl restart ssh usuario@servidor:~$ sudo systemctl status ssh Active: active (running) since ... ; 2s ago Main PID: 5103 (sshd) # PID diferente — reiniciou!
5
Investigue logs com journalctl
Leia as últimas entradas do log do SSH e identifique o registro do restart do passo anterior:
bash — passo 5
usuario@servidor:~$ sudo journalctl -u ssh -n 20 Mar 22 14:10:01 servidor sshd[683]: Server listening on 0.0.0.0 port 22. Mar 22 15:33:44 servidor systemd[1]: Stopping OpenBSD Secure Shell server... Mar 22 15:33:44 servidor systemd[1]: Started OpenBSD Secure Shell server. Mar 22 15:33:44 servidor sshd[5103]: Server listening on 0.0.0.0 port 22.
6
Teste o nice com uma tarefa pesada
Execute um processo com prioridade mínima e observe no top que a coluna NI mostra 19 (mais gentil com outros processos):
bash — passo 6
# niceness 19 = menor prioridade possível usuario@servidor:~$ nice -n 19 find / -name "*.log" 2>/dev/null # em outro terminal, observe NI=19 na coluna do find: usuario@servidor:~$ ps -o pid,ni,comm -C find PID NI COMMAND 5210 19 find
📌 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 ➡