Introdução
Um sistema Linux em execução é 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 depois 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, inspecionará relações entre processos, encontrará processos pelo nome, enviará sinais de término, praticará o controle interativo de tarefas, interpretará o status de saída, executará um comando desanexado 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 exibe informações do kernel. As opções -s, -r e -m selecionam, respectivamente, o nome do kernel, a versão do kernel 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 não interrompível em 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 consultar mais tarde:
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 uma linha com as informações de tempo de atividade.
Inspecionar processos e atividade de recursos
Nesta etapa, você inspecionará identificadores de processos, relações entre processos pai e filho, estados e um instantâneo da atividade de recursos do sistema.
Um processo é um programa em execução. Todo processo tem um ID de processo, ou PID. A maioria dos processos também tem um ID do processo pai, ou PPID, que identifica o processo que os iniciou.
O comando ps exibe um instantâneo dos processos. Selecione campos úteis e ordene-os pelo 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, e -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, juntamente com sinalizadores opcionais.COMMANDé o nome do executável.
As letras de estado mais comuns incluem R para em execução, S para espera interrompível, D para espera não interrompível, T para parado e Z para zumbi. Um processo em espera geralmente está apenas aguardando trabalho.
O formato ps aux, no estilo BSD, fornece colunas de CPU e memória, além das linhas de comando completas:
ps aux | head -n 10
Quando usado interativamente, top é atualizado continuamente. O modo em lote produz um único instantâneo 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 dele ajuda a localizar os processos que consomem mais recursos.
Agora abra a exibiçã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 quando você precisa 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 um instantâneo concentrado 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, salvará seu PID e o localizará com ps e pgrep.
O & no final pede ao shell que execute um comando em segundo plano e retorne imediatamente o prompt. 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 do shell $! 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 decorrido, 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 ser igual ao valor em worker.pid. Pesquisar com 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 normal com SIGTERM e usará SIGKILL somente 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 fazer a limpeza necessária.
Leia o PID do worker e envie SIGTERM:
cd /home/labex/project/process-lab
worker_pid=$(cat worker.pid)
kill "$worker_pid"
sleep 1
A falha esperada do ps a seguir confirma que o processo terminou:
ps -p "$worker_pid" || echo "labex-worker stopped after SIGTERM"
Agora inicie um processo controlado que ignora SIGTERM intencionalmente:
bash -c 'trap "" TERM; exec -a labex-stubborn sleep 300' &
stubborn_pid=$!
echo "$stubborn_pid" > stubborn.pid
Aguarde um momento para que o novo shell instale o 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"
O processo ainda deve estar presente porque esse processo de prática ignora SIGTERM. SIGKILL, o sinal 9, não pode ser capturado nem ignorado. Use-o somente depois que um sinal normal não funcionar:
kill -KILL "$stubborn_pid"
Recolha a tarefa em segundo plano encerrada. O status diferente de zero é esperado, portanto || 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"
SIGKILL não dá ao processo a oportunidade de salvar o estado ou liberar os recursos da aplicação de forma limpa, portanto é o último recurso.
kill atua sobre um PID conhecido. Quando você precisa 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 usando pkill -f. Os delimitadores ^ e $ impedem que esse padrão de treinamento 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 precisos com pkill e inspecione primeiro as correspondências com pgrep; padrões amplos podem encerrar 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á de volta 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 fácil de reconhecer:
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 exibirá novamente o prompt.
Liste as tarefas conhecidas por este 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 de volta 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 depois de 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 desanexado
Nesta etapa, você interpretará o status de saída de comandos e executará uma tarefa curta em segundo plano cuja saída continuará disponível independentemente da exibição do 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 que acabou de terminar.
Execute um comando bem-sucedido e imprima imediatamente seu status:
cd /home/labex/project/process-lab
true
echo "true status: $?"
O resultado é 0. Agora execute um comando que não consegue encontrar seu caminho:
ls missing-path
Capture o status antes que outro comando substitua $?:
missing_status=$?
echo "missing-path status: $missing_status"
O valor é 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 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 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 até background: three. Para trabalhos de longa duração, o PID salvo e o log oferecem formas de inspecionar 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 de 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 carimbo de data e hora e no componente ou subsistema que produziu cada mensagem.
A opção --level filtra 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 significar 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 de serviços e os sintomas observados antes de decidir uma ação.
Resumo
Você identificou um sistema Linux, interpretou o tempo de atividade e as médias de carga e inspecionou IDs de processos, processos pai, proprietários, estados e atividade de recursos usando ferramentas interativas e de instantâneo. Você iniciou e encontrou processos nomeados, atuou sobre eles com precisão usando kill e pkill, 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 trabalho desanexado com nohup e registro explícito e inspecionou mensagens do kernel com dmesg. Esses hábitos de observar primeiro formam a base para uma solução segura de problemas de processos e preparam você para diagnósticos de serviços, logs e redes mais adiante no curso.
