Sistemas Operacionais com Linux e Python: Systemd, serviços, logs, pacotes e containers

O que a questão pede

Classificar comandos como cd, ls e grep, localizar executáveis externos e identificar o tipo real de arquivo.

Conceito cobrado

No shell Linux, comando pode ser builtin, alias, script ou binário externo; cada ferramenta de consulta responde um ponto diferente.

Estrutura dos dados

Entrada: nomes de comandos existentes no host.
Saída: classificação por tipo, caminho no PATH e classe do arquivo executável.

Como pensar

Modelo mental mínimo: type responde o que o shell entende por aquele nome; which só faz sentido quando existe executável no PATH; file confirma a natureza do artefato encontrado. Se type cd retornar builtin, a causa é o comando viver dentro do shell. Se which ls devolver um caminho, o efeito esperado é a existência de um binário externo que pode ser inspecionado com file.

Como validar

Caso de validação: entrada cd deve indicar builtin; entrada ls deve apontar para caminho em /usr/bin; saída esperada de file inclui ELF para binários comuns.

Tabela de Evidência

• Sinal: type cd retorna builtin.
• Sinal: which ls retorna caminho no PATH.
• Sinal: file /usr/bin/ls confirma tipo do executável.

Variáveis-chave

• cd
• ls
• grep
• PATH

O que focar no Screenshot

Se você quiser conferir visualmente se a resposta está bem sustentada, vale focar no retorno de type cd, no caminho devolvido por which ls ou which grep e na linha do file com ELF, script ou classe equivalente. Esses três pontos mostram se a classificação faz sentido.

Como explicar

Use uma defesa madura: "Executei type, which e file em camadas porque cada um prova uma parte diferente do problema. Assim distingui o que é builtin do que depende de executável externo e confirmei o tipo real do arquivo no sistema."

Problema & Solução

Problema: tratar todo comando como binário em /usr/bin. Solução: começar por type; se o retorno for builtin, não procure executável. Se houver caminho no PATH, aí sim valide com which e file.

O que a questão pede

Ler o panorama do sistema após o boot com systemctl status, identificando estado global, unidades e falhas.

Conceito cobrado

systemctl status funciona como painel do systemd e deve ser lido antes de investigar unidade isolada.

Estrutura dos dados

Entrada: estado atual do host.
Saída: campos como State, Units, Jobs e Failed.

Como pensar

Leia o terminal em camadas: State responde a saúde global do gerenciador; Failed mostra se existe unit quebrada; Units contextualiza o tamanho do sistema carregado. Se aparecer State: running, o systemd está operacional. Se aparecer degraded, o efeito prático é a existência de uma ou mais units com falha e a próxima ação é descobrir quais.

Como validar

Caso de validação: com State: running e Failed: 0, a saída esperada é sistema operacional sem falha registrada naquele momento.

Tabela de Evidência

• Sinal: State define saúde global do gerenciador.
• Sinal: Failed resume falhas em unidades.
• Sinal: Units contextualiza volume de serviços carregados.

Variáveis-chave

• State
• Units
• Failed

O que focar no Screenshot

Se quiser revisar rapidamente se a leitura está correta, foque nas linhas State, Units e Failed. São elas que confirmam se a conclusão realmente responde ao estado global do systemd.

Como explicar

Use uma defesa objetiva: "Executei systemctl status para obter o retrato global do systemd antes de descer para serviços isolados. Li State, Failed e Units; por isso concluí a saúde operacional do host naquele instante."

Problema & Solução

Problema: declarar que o sistema inteiro está saudável olhando apenas um daemon. Solução: começar sempre pelo status global; só depois investigar a unit específica que explica o sintoma.

O que a questão pede

Examinar o boot atual por ordem temporal usando journalctl -b e filtros para componentes relevantes.

Conceito cobrado

A opção -b limita ao boot atual; filtros por componente e prioridade tornam a leitura auditável.

Estrutura dos dados

Entrada: journal do boot vigente.
Saída: eventos cronológicos de kernel, systemd e serviços essenciais.

Como pensar

journalctl -b limita a coleta ao boot atual; sem essa chave, você mistura passado com presente. Depois do recorte, use filtros por componente e prioridade para separar sinal de ruído. Se journalctl -b -p warning não retornar linhas, o efeito correto é registrar ausência de warnings nesse boot, não inventar diagnóstico.

Como validar

Caso de validação: entrada journalctl -b -p warning com saída vazia indica ausência de warnings nesse recorte; se houver linhas, a saída esperada é uma lista de alertas para ação.

Tabela de Evidência

• Sinal: Recorte temporal do boot atual preservado.
• Sinal: Filtros destacam systemd, kernel e rede.
• Sinal: A prioridade warning sinaliza risco operacional.

Variáveis-chave

• -b
• -p warning
• systemd
• kernel

O que focar no Screenshot

Para conferir se a interpretação bate com o terminal, observe o comando com -b visível e algumas linhas do boot atual. Se houver warnings, foque neles; se não houver, a ausência de linhas após journalctl -b -p warning já responde ao que se espera.

Como explicar

Uma fala defensável seria: "Executei journalctl -b para restringir a análise ao boot atual e depois refinei por prioridade e componente. Assim, qualquer alerta relatado pertence à inicialização vigente e não a um evento antigo fora de contexto."

Problema & Solução

Problema: misturar logs de boots antigos com o boot vigente. Solução: usar -b como recorte obrigatório e, quando necessário, combinar com -p warning ou grep para deixar explícito o critério da leitura.

O que a questão pede

Consultar bootctl status para obter informações de firmware, loader e entrada de kernel.

Conceito cobrado

bootctl depende do ambiente; resposta técnica pode incluir registro de limitação quando dados não estiverem disponíveis.

Estrutura dos dados

Entrada: metadados de boot expostos pelo host.
Saída: modo de inicialização, loader e entrada ativa quando aplicável.

Como pensar

Primeiro pergunte se o ambiente suporta a leitura: bootctl só produz metadados completos quando o host expõe esse contexto, normalmente em cenários UEFI. Se houver dados, extraia fatos como sistema, boot loader e entry atual. Se não houver suporte, a resposta tecnicamente correta é registrar a limitação do ambiente, e não preencher lacunas com suposição.

Como validar

Caso de validação: com saída contendo UEFI e entry ativa, a saída esperada resume esses campos; sem suporte, a saída esperada documenta a indisponibilidade.

Tabela de Evidência

• Sinal: Presença de dados de firmware/loader.
• Sinal: Entry de kernel quando exibida.
• Sinal: Registro da limitação quando comando não se aplica.

Variáveis-chave

• bootctl
• UEFI
• entry

O que focar no Screenshot

Se quiser uma checagem visual rápida, observe as linhas de System, Boot Loader e Current Entry quando existirem. Quando o ambiente não suportar a leitura, a própria mensagem do comando já mostra que a resposta correta é registrar a limitação.

Como explicar

Defenda assim: "Executei bootctl status para verificar se o host expunha metadados de firmware, boot loader e entry atual. Quando esses campos apareceram, eu os relatei; quando não apareceram, registrei a limitação técnica do ambiente sem inventar saída."

Problema & Solução

Problema: tratar ausência de dado como se fosse falha de interpretação do aluno. Solução: verificar se o ambiente suporta a consulta e, em caso negativo, documentar a limitação com a mensagem real exibida pelo comando.

O que a questão pede

Escolher serviço existente, usar systemctl status <serviço> e relatar estado operacional.

Conceito cobrado

Diagnóstico de unit exige leitura conjunta de Loaded, Active, Main PID e mensagens recentes. Serviço carregado não é sinônimo de serviço saudável.

Estrutura dos dados

Entrada: nome de serviço válido no host.
Saída: estado da unit, PID principal e trecho de log recente.

Como pensar

Escolha primeiro um serviço existente e seguro no host. Depois leia o status como um bloco causal: Loaded diz se a unit foi reconhecida; Active mostra o estado operacional; Main PID comprova processo principal; o rodapé de logs contextualiza o motivo daquele estado. Se Loaded estiver presente mas Active estiver inactive ou failed, a causa do problema estará melhor explicada nas mensagens recentes.

Como validar

Caso de validação: com sshd ativo, saída esperada inclui Active: active (running) e Main PID maior que zero.

Tabela de Evidência

• Sinal: Serviço aparece na listagem de units.
• Sinal: Status mostra Active e Main PID.
• Sinal: Logs recentes sustentam interpretação de funcionamento.

Variáveis-chave

• Loaded
• Active
• Main PID

O que focar no Screenshot

Se quiser verificar visualmente se a resposta está consistente, olhe para a linha Active, a linha Main PID e o trecho final do log mostrado pelo systemctl status. Esses pontos costumam bastar para confirmar se a leitura faz sentido.

Como explicar

Uma defesa robusta seria: "Executei systemctl status <serviço> para ler a unit como evidência operacional. Relacionei Loaded, Active, Main PID e o trecho de log final; por isso concluí se o serviço estava ativo, parado ou falhando, com base em dados e não em percepção subjetiva."

Problema & Solução

Problema: ler Loaded como se ele provasse serviço ativo. Solução: só fechar o diagnóstico depois de cruzar Active, Main PID e as mensagens recentes da própria unit.

O que a questão pede

Operar serviço não crítico com start, stop e restart, registrando o efeito observado.

Conceito cobrado

Mudança operacional sem validação não gera evidência; cada ação exige leitura de estado correspondente.

Estrutura dos dados

Entrada: serviço não crítico disponível.
Saída: transições de estado após cada comando do ciclo.

Como pensar

Antes de alterar qualquer coisa, fotografe o estado inicial. Depois, trate cada comando como causa e o novo Active como efeito observado. stop deve levar a inactive ou estado equivalente; start deve restaurar active; restart deve manter o serviço operacional, muitas vezes com mudança de PID ou timestamp. Faça isso apenas com uma unit segura de laboratório.

Como validar

Caso de validação: estado inicial active -> após stop inactive -> após start active; a saída esperada é a cadeia coerente dessas transições.

Tabela de Evidência

• Sinal: Estado inicial registrado.
• Sinal: Mudança confirmada após stop.
• Sinal: Retorno operacional confirmado após start/restart.

Variáveis-chave

• stop
• start
• restart
• Active

O que focar no Screenshot

Para revisar se a sequência está correta, compare pelo menos um estado antes da mudança e um estado depois dela. Foque na linha Active e, se possível, em Main PID para confirmar a transição.

Como explicar

Defenda assim: "Escolhi um serviço não crítico, capturei o estado inicial e validei o efeito de cada operação com nova leitura de status. Por isso consigo demonstrar a cadeia causa-efeito entre stop, start, restart e o estado retornado pela unit."

Problema & Solução

Problema: testar em serviço crítico ou disparar vários comandos sem checkpoint. Solução: usar uma unit segura de laboratório e registrar o status antes e depois de cada ação para não perder a rastreabilidade.

O que a questão pede

Alterar estado de auto-inicialização de serviço com enable/disable e comprovar com is-enabled.

Conceito cobrado

enable/disable alteram comportamento de boot; start/stop alteram estado de execução atual.

Estrutura dos dados

Entrada: estado de habilitação atual da unit.
Saída: resultado de is-enabled antes e depois de cada alteração.

Como pensar

Separe política de boot de estado em tempo real. is-enabled responde o que acontecerá no próximo boot; ele não diz, sozinho, se o serviço está rodando agora. Se o retorno for enabled ou disabled, a leitura é direta. Se surgir static ou masked, registre o termo exato e explique que a semântica muda.

Como validar

Caso de validação: se iniciar em enabled, após disable a saída esperada é disabled; após enable, deve retornar enabled.

Tabela de Evidência

• Sinal: Estado inicial capturado por is-enabled.
• Sinal: Estado alterado após disable.
• Sinal: Estado restaurado após enable.

Variáveis-chave

• is-enabled
• enable
• disable

O que focar no Screenshot

Se quiser uma conferência visual simples, observe o retorno de is-enabled antes da alteração e o retorno depois de disable ou enable. A comparação já mostra se a leitura do comportamento no boot está correta.

Como explicar

Uma fala madura seria: "Usei is-enabled porque a pergunta trata de comportamento no boot, não apenas do estado atual do processo. Registrei o valor antes e depois das mudanças e, com isso, provei a política de inicialização configurada para a unit."

Problema & Solução

Problema: usar systemctl status e achar que isso responde sobre o próximo boot. Solução: registrar exatamente a palavra devolvida por is-enabled e explicar seu significado operacional.

O que a questão pede

Pesquisar pacote, instalar e inspecionar metadados de versão, dependência e origem com o gerenciador adequado.

Conceito cobrado

Pacote é artefato rastreável; o metadado sustenta a governança técnica e a reprodução do ambiente.

Estrutura dos dados

Entrada: nome de pacote no repositório da distribuição.
Saída: prova de busca, instalação e informações de pacote.

Como pensar

Siga a trilha de auditoria completa: buscar prova disponibilidade, instalar prova ação executada, inspecionar metadados prova versão, dependências e origem do pacote. Se a busca não retornar resultado, o correto é registrar que o pacote não foi localizado naquele repositório ou que o nome varia por distribuição; não invente disponibilidade.

Como validar

Caso de validação: a entrada htop em apt deve retornar pacote na busca, instalar sem erro e mostrar versão em apt show; a saída esperada inclui os três pontos.

Tabela de Evidência

• Sinal: Pacote encontrado em busca oficial.
• Sinal: Instalação concluída pelo gerenciador.
• Sinal: Metadados exibidos com versão/dependências.

Variáveis-chave

• apt
• yum
• pacman
• htop

O que focar no Screenshot

Se quiser confirmar rapidamente se a resposta está completa, olhe para uma evidência de busca, uma de instalação concluída e as linhas de metadado como Version e Depends. Esse conjunto costuma bastar para validar a leitura.

Como explicar

Defenda assim: "Primeiro provei que o pacote existia no repositório, depois executei a instalação e por fim li os metadados para registrar versão, dependências e origem. Dessa forma, a operação fica rastreável e reproduzível."

Problema & Solução

Problema: instalar e encerrar a questão sem registrar versão ou dependências. Solução: sempre fechar o ciclo com apt show, yum info ou equivalente e anotar o que esses campos revelam.

O que a questão pede

Usar lsns para observar namespaces ativos e correlacionar com processos específicos.

Conceito cobrado

Namespace isola a visão no kernel e fundamenta containers, mas sua presença isolada não prova container em execução.

Estrutura dos dados

Entrada: tabela de namespaces do host.
Saída: tipos de namespace, PID associado e comando relacionado.

Como pensar

Namespace responde "quem enxerga o quê"; ele descreve isolamento, não prova container ativo sozinho. Leia primeiro TYPE para entender a natureza do namespace, depois PID e COMMAND para ligar aquela estrutura a um processo real. Se a conclusão desejada for sobre container, você precisa de correlação adicional com ps ou com o runtime.

Como validar

Caso de validação: entrada lsns -p 1 deve retornar namespaces do processo init; saída esperada inclui tipos como mnt, pid, uts ou ipc.

Tabela de Evidência

• Sinal: Tabela lsns com TYPE/PID/COMMAND.
• Sinal: Correlação de PID com namespace observado.
• Sinal: Conclusão limitada ao que a evidência suporta.

Variáveis-chave

• TYPE
• PID
• COMMAND
• pid/net/mnt/uts/ipc

O que focar no Screenshot

Se quiser uma checagem visual, foque nas colunas TYPE, PID e COMMAND. Se você usar lsns -p, vale observar também a linha do processo correlacionado para confirmar a interpretação.

Como explicar

Uma defesa consistente seria: "Executei lsns para observar namespaces ativos e depois relacionei alguns deles a processos específicos. Assim, descrevi isolamento real no kernel sem extrapolar automaticamente para a existência de um container ativo."

Problema & Solução

Problema: afirmar que qualquer namespace visível equivale a um container em execução. Solução: usar PID e COMMAND para correlacionar o namespace ao processo e só então sustentar a interpretação.

O que a questão pede

Abrir systemd-cgtop, observar grupos com maior consumo e registrar interpretação técnica.

Conceito cobrado

Se namespace isola visão, cgroup organiza e observa recursos; ele responde melhor à pergunta "quanto este grupo consome?" do que a leitura de um processo isolado.

Estrutura dos dados

Entrada: painel interativo de cgroups em tempo real.
Saída: comparação de CPU/memória por control group.

Como pensar

Olhe o painel como fotografia de consumo por grupo. Primeiro identifique o Control Group, depois compare %CPU e Memory. O raciocínio correto é: se um grupo aparece acima dos demais naquele instante, ele está consumindo mais recursos naquele recorte temporal; isso não autoriza, sozinho, concluir que o limite é permanente.

Como validar

Caso de validação: se o grupo A exibe memória maior que o grupo B no painel, a saída esperada é o registro dessa diferença naquele instante, sem afirmar limite permanente.

Tabela de Evidência

• Sinal: Control Group identifica o escopo medido.
• Sinal: %CPU e Memory sustentam comparação.
• Sinal: Leitura temporal é encerrada com q após a coleta.

Variáveis-chave

• Control Group
• Tasks
• %CPU
• Memory

O que focar no Screenshot

Se você quiser conferir se a interpretação está bem amarrada, observe o nome do Control Group e as colunas %CPU e Memory. Essas três partes já mostram se a comparação foi feita no lugar certo.

Como explicar

Defenda assim: "Usei systemd-cgtop para medir consumo agregado por control group. Em vez de olhar processo isolado, comparei grupo, CPU e memória no mesmo instante; por isso minha leitura responde quanto cada agrupamento estava consumindo naquele momento."

Problema & Solução

Problema: tratar pico momentâneo como política fixa de limite. Solução: registrar que a leitura é temporal, capturar o grupo e os valores observados e, se necessário, repetir a medição antes de generalizar.

O que a questão pede

Criar arquivo no vi, aplicar comandos de inserção/edição e documentar operações realizadas.

Conceito cobrado

Editor modal exige comando adequado para cada tipo de mudança; produtividade vem do modo normal.

Estrutura dos dados

Entrada: arquivo texto com configurações iniciais.
Saída: arquivo editado e registro dos comandos utilizados.

Como pensar

No vi, o modo normal é sua camada de controle e o modo de inserção é apenas uma fase do trabalho. O modelo mental mínimo é: entrar, editar, voltar ao modo normal com Esc, aplicar operações estruturais e só então salvar. Se você não souber em que modo está, pare, pressione Esc e retome o comando conscientemente.

Como validar

Caso de validação: a entrada com mode=dev e o comando :%s/dev/prod/g devem produzir a saída esperada com ocorrências alteradas para mode=prod.

Tabela de Evidência

• Sinal: Arquivo final contém linhas planejadas.
• Sinal: Comandos usados foram registrados.
• Sinal: Busca e substituição produziram efeito verificável.

Variáveis-chave

• i
• o
• yy
• dd
• u
• Ctrl-r
• :%s/old/new/g

O que focar no Screenshot

Se quiser conferir se a edição realmente respondeu ao pedido, observe a alteração visível no conteúdo do arquivo e, de preferência, a verificação final com cat. Isso já mostra se a transformação esperada aconteceu.

Como explicar

Uma defesa madura seria: "Usei o modo normal como centro de controle da edição, executei inserção, cópia, remoção, desfazer e substituição global, e depois conferi o arquivo salvo. Assim demonstrei domínio operacional do editor, não apenas memorização de teclas."

Problema & Solução

Problema: ficar preso no modo de inserção ou sair sem salvar o resultado correto. Solução: usar Esc como checkpoint, salvar com :wq quando a edição estiver correta e recorrer a :q! somente se a intenção for descartar mudanças.

O que a questão pede

Construir Dockerfile simples, executar docker build/run e validar estado com docker images e docker ps -a.

Conceito cobrado

Imagem é template imutável; container é instância em execução com ciclo de vida próprio.

Estrutura dos dados

Entrada: Dockerfile e contexto de build local.
Saída: imagem gerada e container registrado no ambiente.

Como pensar

Separe artefato de execução: imagem é o pacote reproduzível; container é a instância que nasce quando você roda essa imagem. O fluxo mental é build -> run -> inventário. Se o processo terminar rápido, isso não significa desaparecimento; o efeito esperado é o container aparecer em docker ps -a com status de saída. Se houver permission denied no daemon, a correção é usar sudo ou ajustar o grupo do Docker.

Como validar

Caso de validação: Dockerfile com CMD echo deve imprimir mensagem no run; por ser processo curto, saída esperada inclui container em docker ps -a.

Tabela de Evidência

• Sinal: Build conclui com tag local.
• Sinal: Run executa comando esperado.
• Sinal: O inventário mostra a imagem e o histórico do container.

Variáveis-chave

• Dockerfile
• docker build
• docker run
• docker images
• docker ps -a

O que focar no Screenshot

Se quiser uma conferência visual útil, observe a tag criada no build, a saída do docker run e a linha correspondente em docker ps -a. Esse trio ajuda a verificar se a resposta realmente distinguiu imagem de container.

Como explicar

Defenda assim: "Primeiro construí a imagem, depois executei o container e por fim conferi os artefatos gerados com docker images e docker ps -a. Com isso diferenciei o que é imagem reproduzível do que é execução concreta do container."

Problema & Solução

Problema: achar que o container sumiu quando o processo termina rápido ou travar no acesso ao daemon. Solução: validar a execução com docker ps -a e, se houver problema de permissão, usar sudo ou configurar corretamente o acesso ao serviço Docker.

Checklist de domínio

• Diferencia comando builtin de executável externo com prova em terminal.
• Lê o panorama do systemd e depois aprofunda em uma unit, sem misturar níveis.
• Interpreta boot, namespace e cgroup com limite claro do que a evidência comprova.
• Executa ciclo de serviço e auto-inicialização com verificação antes/depois.
• Explica build e run de Docker sem confundir imagem com container.