Informações do Sistema e Gerenciamento de Processos

Introdução

Um sistema Linux em execução é muito mais do que seus arquivos. O kernel gerencia o hardware e os processos; cada comando é executado como um processo com um identificador, e o shell acompanha as tarefas em primeiro e segundo plano. Os administradores primeiro observam esse estado e só então atuam sobre o menor processo relevante.

Neste laboratório, você identificará o sistema operacional e o kernel, interpretará o tempo de atividade e as médias de carga, examinará as relações entre processos, localizará processos pelo nome, enviará sinais de término, praticará o controle interativo de tarefas, interpretará o status de saída, executará um comando desvinculado do terminal com nohup e lerá mensagens recentes do kernel.

Identificar o Sistema e Interpretar a Carga

Nesta etapa, você identificará o kernel e a distribuição, verificará há quanto tempo o sistema está em execução e aprenderá o que representam as médias de carga.

Crie e acesse um diretório de trabalho:

mkdir -p /home/labex/project/process-lab

cd /home/labex/project/process-lab

O comando uname informa dados do kernel. As opções -s, -r e -m selecionam, respectivamente, o nome do kernel, a versão de lançamento e a arquitetura da máquina:

uname -srm

uname -a exibe todos os campos disponíveis em uma única linha:

uname -a

O kernel não é a mesma coisa que a distribuição Linux. Leia os metadados da distribuição:

cat /etc/os-release

Procure campos como NAME, VERSION e ID. Em seguida, verifique o tempo de atividade e a carga:

uptime

A saída inclui a hora atual, há quanto tempo o sistema está em execução, o número de usuários conectados e três médias de carga. Essas médias descrevem o trabalho executável ou em espera não interrompível ao longo de aproximadamente 1, 5 e 15 minutos. Elas não são porcentagens; seu significado depende, em parte, do número de núcleos da CPU.

Veja o registro compacto de carga do kernel:

cat /proc/loadavg

Os três primeiros valores correspondem ao conceito de média de carga. Os campos seguintes mostram as tarefas executáveis e o ID de processo atribuído mais recentemente.

Salve um pequeno resumo do sistema para consulta posterior:

uname -srm > system-summary.txt

uptime >> system-summary.txt

cat system-summary.txt

O arquivo deve conter uma linha com as informações do kernel e outra com o tempo de atividade.

Inspecionar Processos e Atividade de Recursos

Nesta etapa, você examinará identificadores de processos, relações entre processos-pai e processos-filhos, estados e uma visão instantânea da atividade de recursos do sistema.

Um processo é um programa em execução. Todo processo possui um ID de processo, ou PID. A maioria dos processos também possui um ID do processo-pai, ou PPID, que identifica o processo responsável por iniciá-los.

O comando ps exibe uma visão instantânea dos processos. Selecione campos úteis e ordene por PID:

cd /home/labex/project/process-lab

ps -eo pid,ppid,user,stat,comm --sort=pid | head -n 15

A opção -e seleciona todos os processos, enquanto -o define as colunas:

• PID é o identificador do processo.
• PPID é o identificador do processo-pai.
• USER é o proprietário do processo.
• STAT é o estado do processo, acompanhado de possíveis sinalizadores.
• COMMAND é o nome do executável.

Entre as letras de estado mais comuns estão R para em execução, S para espera interrompível, D para espera não interrompível, T para interrompido e Z para zumbi. Um processo em espera geralmente está simplesmente aguardando trabalho.

O formato ps aux, no estilo BSD, fornece colunas de CPU e memória, além da linha de comando completa:

ps aux | head -n 10

Quando usado interativamente, top é atualizado continuamente. O modo em lote produz uma única visão estável: -b seleciona a saída em lote e -n 1 solicita uma atualização.

top -b -n 1 | head -n 12

O cabeçalho resume o tempo de atividade, a carga, os estados das tarefas, o uso da CPU e a memória. A tabela de processos abaixo ajuda a localizar os processos que mais consomem recursos.

Agora abra a visualização interativa:

top

Observe os valores sendo atualizados, localize as colunas %CPU e %MEM e pressione q para voltar ao shell. O top interativo é útil para observar mudanças ao longo do tempo; o modo em lote é melhor quando a saída precisa ser salva ou processada por outro comando.

Salve uma visão concentrada dos processos como resultado observável:

ps -eo pid,ppid,user,stat,comm --sort=pid > process-snapshot.txt

head -n 5 process-snapshot.txt

Iniciar e Localizar um Processo de Prática

Nesta etapa, você iniciará um processo inofensivo em segundo plano, registrará seu PID e o localizará usando ps e pgrep.

O & no final solicita ao shell que execute um comando em segundo plano e devolva o prompt imediatamente. Inicie um processo sleep de cinco minutos com o nome visível labex-worker:

cd /home/labex/project/process-lab

bash -c 'exec -a labex-worker sleep 300' &

O valor especial $! contém o PID do processo em segundo plano iniciado mais recentemente. Salve-o antes de iniciar outro comando em segundo plano:

worker_pid=$!

echo "$worker_pid" > worker.pid

Inspecione exatamente esse processo. A opção -p seleciona um PID e -o escolhe os campos:

ps -o pid,ppid,user,stat,etime,args -p "$worker_pid"

ETIME mostra o tempo de execução transcorrido, enquanto ARGS inclui o nome visível do processo. Use pgrep -f para pesquisar a linha de comando completa; -a também a exibe:

pgrep -af labex-worker

O PID exibido por pgrep deve corresponder ao conteúdo de worker.pid. Pesquisar usando um padrão preciso é mais seguro do que agir sobre todos os processos que tenham um nome genérico.

Encerrar Processos com Sinais

Nesta etapa, você solicitará um encerramento organizado usando SIGTERM e utilizará SIGKILL apenas em um processo projetado para ignorar essa solicitação.

O comando kill envia um sinal para um PID. Sem um sinal explícito, ele envia SIGTERM, o sinal 15. SIGTERM solicita um encerramento ordenado e dá ao processo a oportunidade de realizar a limpeza necessária.

Leia o PID do processo de trabalho e envie SIGTERM:

cd /home/labex/project/process-lab

worker_pid=$(cat worker.pid)

kill "$worker_pid"

sleep 1

A falha esperada do comando ps a seguir comprova que o processo terminou:

ps -p "$worker_pid" || echo "labex-worker stopped after SIGTERM"

Agora inicie um processo controlado que ignora intencionalmente o SIGTERM:

bash -c 'trap "" TERM; exec -a labex-stubborn sleep 300' &

stubborn_pid=$!

echo "$stubborn_pid" > stubborn.pid

Dê ao novo shell um momento para instalar seu manipulador de sinais:

sleep 1

Envie SIGTERM, aguarde brevemente e inspecione o processo:

kill -TERM "$stubborn_pid"

sleep 1

ps -o pid,stat,args -p "$stubborn_pid"

Ele ainda deverá estar presente, pois esse processo de prática ignora SIGTERM. SIGKILL, o sinal 9, não pode ser capturado nem ignorado. Use-o somente quando um sinal de encerramento normal não surtir efeito:

kill -KILL "$stubborn_pid"

Recolha a tarefa em segundo plano encerrada. O status diferente de zero é esperado, por isso || true permite que a sequência de prática continue:

wait "$stubborn_pid" 2>/dev/null || true

ps -p "$stubborn_pid" || echo "labex-stubborn required SIGKILL"

O SIGKILL não dá ao processo nenhuma oportunidade de salvar seu estado ou liberar os recursos da aplicação de maneira adequada; portanto, ele deve ser usado como último recurso.

kill atua sobre um PID conhecido. Quando for necessário selecionar um processo pelo nome ou pela linha de comando completa, pkill combina a correspondência com o envio do sinal. Inicie mais um processo controlado com uma linha de comando distinta:

bash -c 'exec -a labex-helper sleep 300' &

helper_pid=$!
echo "$helper_pid" > helper.pid

Confirme a correspondência exata da linha de comando completa antes de agir:

pgrep -af '^labex-helper 300$'

Envie SIGTERM para essa correspondência exata com pkill -f. As âncoras ^ e $ evitam que o padrão de prática corresponda a linhas de comando não relacionadas:

pkill -TERM -f '^labex-helper 300$'

wait "$helper_pid" 2>/dev/null || true
ps -p "$helper_pid" || echo "labex-helper stopped by pkill"

Use padrões pkill precisos e verifique primeiro as correspondências com pgrep; um padrão muito amplo pode interromper mais processos do que o pretendido.

Controlar Tarefas em Primeiro e Segundo Plano

Nesta etapa, você suspenderá um comando em primeiro plano, retomará sua execução em segundo plano, o trará novamente para o primeiro plano e o interromperá.

O controle de tarefas pertence ao shell interativo atual. Inicie um processo sleep em primeiro plano com um nome reconhecível:

cd /home/labex/project/process-lab

bash -c 'exec -a labex-job sleep 300'

O terminal agora está ocupado pelo processo em primeiro plano. Pressione Ctrl+Z. O shell enviará um sinal de parada e devolverá o prompt.

Liste as tarefas conhecidas por esse shell. A opção -l inclui o ID do processo:

jobs -l

Você deverá ver uma tarefa com o estado Stopped. Retome a tarefa número 1 em segundo plano:

bg %1

jobs -l

O estado agora deve ser Running, e o prompt continuará disponível. Traga a tarefa novamente para o primeiro plano:

fg %1

Pressione Ctrl+C para enviar um sinal de interrupção à tarefa em primeiro plano. O prompt deverá retornar. Confirme que não restou nenhuma tarefa de prática:

pgrep -af labex-job || echo "No labex-job process remains"

Crie um marcador de conclusão após terminar a sequência interativa:

touch job-control.done

Use o controle de tarefas para comandos vinculados ao terminal atual. Mais adiante, você usará nohup para trabalhos que não devem depender da sessão do terminal.

Ler o Status de Saída e Executar Trabalho Desvinculado

Nesta etapa, você interpretará o status de saída dos comandos e executará uma tarefa curta em segundo plano cuja saída permanecerá disponível independentemente do conteúdo exibido no terminal.

Todo comando retorna um status inteiro. Zero significa sucesso; um valor diferente de zero indica algum tipo de falha. A variável do shell $? contém o status do comando concluído imediatamente antes.

Execute um comando bem-sucedido e, logo em seguida, imprima seu status:

cd /home/labex/project/process-lab

true

echo "true status: $?"

O resultado é 0. Agora execute um comando que não consegue localizar o caminho informado:

ls missing-path

Capture o status antes que outro comando substitua $?:

missing_status=$?

echo "missing-path status: $missing_status"

O valor será diferente de zero. Salve as duas interpretações esperadas:

printf 'success=0\nfailure=%s\n' "$missing_status" > exit-status.txt

O comando nohup faz com que um programa ignore o sinal de desligamento do terminal. O & final inicia o programa em segundo plano. O redirecionamento < /dev/null desconecta a entrada do terminal, enquanto > nohup.log 2>&1 envia os dois fluxos de saída para um arquivo de log:

nohup bash -c 'for item in one two three; do echo "background: $item"; sleep 1; done' < /dev/null > nohup.log 2>&1 &

Salve o PID do processo em segundo plano e aguarde a conclusão da tarefa curta:

echo $! > nohup.pid

sleep 4

cat nohup.log

Você deverá ver três linhas, de background: one a background: three. Para trabalhos de longa duração, o PID e o log salvos oferecem formas de acompanhar o progresso.

Inspecionar Mensagens Recentes do Kernel

Nesta etapa, você inspecionará o buffer de mensagens do kernel e salvará a versão do kernel em execução como uma referência estável.

O kernel registra mensagens sobre inicialização, hardware, drivers e eventos durante a execução em um buffer circular. dmesg lê esse buffer. Geralmente são necessários privilégios administrativos:

cd /home/labex/project/process-lab

sudo dmesg | tail -n 10

As mensagens exatas variam conforme a máquina e o momento. Concentre-se no campo semelhante a um timestamp e no componente ou subsistema que produziu cada mensagem.

A opção --level filtra as mensagens por gravidade. Exiba avisos e erros recentes:

sudo dmesg --level=err,warn | tail -n 10

A ausência de saída não significa que o comando falhou; pode indicar que o buffer atual não contém mensagens nesses níveis. Pesquise nas mensagens recentes termos comuns relacionados a armazenamento e rede:

sudo dmesg | grep -Ei 'disk|filesystem|network|eth' | tail -n 10

Novamente, os resultados dependem do sistema atual. Salve a versão do kernel informada por uname -r:

uname -r > kernel-version.txt

cat kernel-version.txt

As mensagens do kernel são evidências, não diagnósticos automáticos. Combine-as com o estado dos processos, os logs dos serviços e os sintomas observados antes de decidir por uma ação.

Resumo

Você identificou um sistema Linux, interpretou o tempo de atividade e as médias de carga e examinou IDs de processos, processos-pai, proprietários, estados e visões instantâneas dos recursos. Você iniciou e localizou um processo nomeado, usou SIGTERM antes de SIGKILL e praticou o controle de tarefas em primeiro e segundo plano.

Você também interpretou o status de saída, executou um trabalho desvinculado com nohup e registro explícito e inspecionou mensagens do kernel com dmesg. Esses hábitos, baseados primeiro na observação, são a base para uma resolução segura de problemas de processos e preparam você para diagnósticos de serviços, logs e redes mais adiante no curso.