Processos no Linux: ps, top, htop, kill, sinais e nice

Qualquer programa em execução no Linux é um processo, com número PID próprio, dono, estado e prioridade. Os processos são listados com ps, top e htop, encerrados com kill, e a prioridade deles é alterada com nice e renice. A seguir veja como ler a saída desses comandos, quais sinais enviar em cada situação e por que o kill -9 não deve ser o primeiro recurso.

O que é um processo e o PID

Um processo é um programa no momento da execução: código, memória, arquivos abertos e um conjunto de atributos. O kernel dá a cada processo um identificador único, o PID, e também registra o PPID, o número do pai que o iniciou. O primeiro processo do sistema, com PID 1, costuma ser o systemd, e ele é o "ancestral" de todos os demais.

Um novo processo surge em duas etapas. Primeiro, o pai chama fork() e obtém uma cópia de si mesmo; depois, a cópia chama execve() e substitui o código dela pelo do novo programa. Quando você digita ls no terminal, o bash faz exatamente isso e aguarda o término do filho com wait().

$ echo $$          # PID do shell atual
4182
$ ps -o pid,ppid,cmd -p $$
    PID    PPID CMD
   4182    4170 -bash

Como listar processos com ps

ps faz um instantâneo: mostra os processos exatamente no momento da execução e termina. Sem argumentos, ele exibe apenas os processos do terminal atual, por isso na prática quase sempre se usa uma de duas variantes.

$ ps aux | head -5
USER       PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
root         1  0.0  0.3 168540 12780 ?     Ss   09:12   0:03 /sbin/init
root         2  0.0  0.0      0     0 ?     S    09:12   0:00 [kthreadd]
www-data  1532  1.2  2.1 412308 86420 ?     S    09:15   1:47 php-fpm: pool www
postgres  1610  0.4  3.8 221004 154312 ?    Ss   09:15   0:31 postgres: checkpointer

Aqui, a são os processos de todos os usuários, u é o formato detalhado com o dono, e x inclui os processos sem terminal (daemons). A sintaxe alternativa no estilo System V é ps -ef: ela mostra o PPID, útil quando você quer entender quem iniciou quem.

Truques úteis com ps

# top 10 por memória
ps aux --sort=-%mem | head -11

# top 10 por processador
ps aux --sort=-%cpu | head -11

# colunas personalizadas
ps -eo pid,ppid,user,ni,stat,etime,cmd

# árvore de processos
ps -ef --forest
pstree -p

# encontrar o PID pelo nome
pgrep -a nginx
pidof nginx

Um erro clássico é procurar um processo com ps aux | grep nginx e acabar vendo o próprio grep na saída. Use pgrep ou o truque grep [n]ginx, que não casa com a própria linha de comando.

Estados dos processos: R, S, D, Z, T

A letra na coluna STAT não é enfeite: ela é o estado real do processo. Dela depende como interpretar a carga e se o kill vai adiantar.

Os caracteres extras depois da letra também são úteis: s — líder de sessão, + — processo em primeiro plano no terminal, < — prioridade elevada, N — prioridade reduzida, l — multithread.

Processo no estado D

Um processo em D está dentro de uma chamada de sistema, esperando, por exemplo, a resposta de um disco ou de um NFS travado. Ele não recebe nenhum sinal, nem mesmo o SIGKILL. Por isso o kill -9 não adianta: é preciso investigar a causa da espera, observando o iostat, o dmesg e o estado do armazenamento de rede.

Processos zumbis

O zumbi já está morto: não consome CPU nem memória, ocupando apenas uma entrada na tabela de processos. Não é possível matá-lo, pois ele já terminou. Ele desaparece quando o pai chama wait(), ou quando o próprio pai termina e o zumbi é adotado pelo PID 1.

# encontrar zumbis e seus pais
ps -eo pid,ppid,stat,cmd | awk '$3 ~ /Z/'

Um zumbi isolado é inofensivo. Se há centenas deles e o número cresce, o erro está no programa pai: é preciso corrigi-lo ou reiniciá-lo.

top: processos e carga em tempo real

O top mostra a mesma lista, mas a atualiza a cada poucos segundos e exibe um resumo do sistema. É o primeiro comando a executar quando "o servidor está lento".

top - 14:21:07 up 12 days,  3:02,  2 users,  load average: 1.84, 1.20, 0.95
Tasks: 213 total,   2 running, 211 sleeping,   0 stopped,   0 zombie
%Cpu(s): 23.1 us,  4.2 sy,  0.0 ni, 70.3 id,  1.9 wa,  0.0 hi,  0.5 si,  0.0 st
MiB Mem :   7821.4 total,    412.6 free,   3105.8 used,   4303.0 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   4398.2 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   1532 www-data  20   0  412308  86420  14212 R  38.2   1.1   1:47.31 php-fpm
   1610 postgres  20   0  221004 154312 148900 S   6.0   1.9   0:31.08 postgres

Na linha %Cpu(s), o mais importante é: us — código do usuário, sy — kernel, id — ocioso, wa — espera pelo disco. Um wa alto com o processador livre é sinal claro de gargalo em E/S.

Teclas de atalho do top

Para scripts e logs, o modo em lote é útil: top -b -n 1 | head -20 exibe um único instantâneo sem interação. Para acompanhar um processo específico, use top -p 1532.

Load average é uma fila, não uma porcentagem

Os três números do load average são o tamanho médio da fila nos últimos 1, 5 e 15 minutos. No Linux, entram nessa fila os processos nos estados R e D; o sono comum S não entra. Para interpretar o LA, compare-o com o número de núcleos (nproc): em 4 núcleos, o valor 4 significa carga total, e 12 significa uma fila três vezes maior que a capacidade.

Se o LA está alto e o processador está ocioso, procure processos em D: ps -eo stat,pid,cmd | grep '^D'. Quase sempre o culpado é um disco lento ou um armazenamento de rede.

htop: uma alternativa mais confortável ao top

O htop mostra o mesmo conteúdo, com indicadores coloridos por núcleo, rolagem, suporte a mouse e árvore de processos. Normalmente é preciso instalá-lo: sudo apt install htop ou sudo dnf install htop.

• F3 ou / — buscar processo pelo nome;
• F4 — filtro que mostra apenas as correspondências;
• F5 ou t — árvore "pai — filhos";
• F6 — escolher a coluna de ordenação;
• F7 / F8 — diminuir ou aumentar o nice;
• F9 — menu de sinais para o processo selecionado;
• Space — marcar vários processos para uma ação em massa.

Em servidores em que não é possível instalar nada, o top basta: todas as operações principais também estão nele.

Como encerrar um processo: kill e sinais

O comando kill não "mata" de fato; ele envia um sinal ao processo. O que acontece depois depende do sinal e de como o programa o trata.

Os números valem para x86 e ARM; a lista completa sai com kill -l. Informar o sinal pelo nome é mais seguro do que pelo número.

kill 1532              # SIGTERM
kill -TERM 1532        # o mesmo, explícito
kill -HUP $(pidof nginx)   # reler a configuração
kill -STOP 1532; kill -CONT 1532
kill -0 1532 && echo "processo ativo"

O sinal 0 não envia nada: ele apenas verifica se o processo existe e se você tem permissão para enviar sinais a ele, o que é útil em scripts.

Por que não começar com kill -9

O SIGTERM dá ao programa a chance de fechar arquivos, gravar buffers, remover arquivos de lock e concluir transações corretamente. O SIGKILL interrompe tudo imediatamente: dados que não foram gravados se perdem, arquivos temporários ficam para trás, e um banco de dados pode entrar em recuperação na próxima inicialização.

A sequência correta é:

1. Enviar kill PID (SIGTERM).
2. Aguardar de 5 a 30 segundos, verificando com kill -0 PID.
3. Somente se o processo continuar ativo e não estiver em D, usar kill -9 PID.

Para serviços gerenciados pelo systemd, o melhor é nem mexer no PID manualmente: systemctl stop envia o SIGTERM, aguarda o tempo limite e então força com SIGKILL.

pkill e killall: pelo nome

pkill -f "python worker.py"   # pela linha de comando completa
pkill -u alice                 # todos os processos do usuário
killall -TERM node             # todos os processos chamados node
pgrep -l -f worker             # antes, confira o que o padrão vai pegar

Antes de um pkill em massa, rode sempre o pgrep com o mesmo padrão: o -f casa com qualquer parte da linha de comando e pode atingir processos indesejados.

Você só pode enviar sinais aos seus próprios processos; para os demais é preciso sudo. O erro Operation not permitted indica exatamente isso.

Prioridade dos processos: nice e renice

O valor de nice indica ao escalonador quem deve ceder o processador. A faixa vai de -20 (prioridade mais alta) a 19 (cede a todos), e o padrão é 0. No top, esse valor aparece na coluna NI; a coluna PR é a prioridade interna derivada.

# executar uma tarefa pesada com prioridade reduzida
nice -n 10 tar czf backup.tar.gz /var/www

# reduzir a prioridade de um processo em execução
renice -n 15 -p 1532

# aumentar a prioridade (somente root)
sudo renice -n -5 -p 1610

# todos os processos de um usuário
sudo renice -n 10 -u alice

Um usuário comum só pode reduzir a prioridade dos próprios processos; valores negativos são exclusivos do root. É importante entender o limite do nice: ele afeta somente a CPU. Se a tarefa sobrecarrega o sistema pelo disco, use ionice -c3 comando — a classe idle, que recebe o disco somente quando ninguém mais precisa dele.

Processos em segundo plano e tarefas do shell

Um comando pode ser executado em segundo plano acrescentando &, ou ser suspenso com Ctrl+Z. O shell mantém uma lista de tarefas, controlada por comandos internos.

$ long_task &
[1] 5120
$ jobs
[1]+  Running    long_task &
$ fg %1        # trazer para o primeiro plano
^Z             # suspender (SIGTSTP)
$ bg %1        # continuar em segundo plano

Ao fechar o terminal, o shell envia SIGHUP às tarefas, e elas terminam. Para que um processo sobreviva à saída, execute-o com nohup comando &, desvincule-o com disown ou use o tmux. Para trabalhos permanentes, o correto é criar um serviço systemd.

Cenários típicos de diagnóstico

Quem está consumindo o processador

top -o %CPU            # ou P dentro do top
ps -eo pid,user,%cpu,etime,cmd --sort=-%cpu | head

Se um processo consome CPU sem necessidade, reduza a prioridade dele com renice primeiro — é seguro e dá tempo para investigar.

Quem ocupa uma porta

sudo ss -ltnp | grep :8080
sudo lsof -i :8080

A saída mostra o PID; a partir dele, em /proc/PID/, é possível encontrar o executável (exe), o diretório de trabalho (cwd) e os argumentos (cmdline).

O processo desapareceu sem explicação

Uma causa comum é o OOM Killer, que encerra processos quando falta memória. Para verificar: dmesg -T | grep -i oom ou journalctl -k | grep -i "killed process".

Resumo

Para trabalhar com processos no Linux bastam poucos comandos: ps aux para o instantâneo, top e htop para acompanhar, kill com o sinal correto para encerrar, e nice/renice para as prioridades. Leia o estado do processo antes de agir: zumbis e processos em D não se resolvem com sinais. E comece sempre pelo SIGTERM, deixando o kill -9 para o último caso. Processos, memória, load average e chamadas de sistema são explicados com mais detalhes, e com prática, no curso de Linux.