Tutorial de Linux / Reproduza falhas e pratique recuperação baseada em evidências

Para praticar recuperação, use um ambiente isolado, confirme primeiro o estado normal, introduza uma falha por vez e restaure a condição alterada com base nas evidências. A recuperação só está concluída quando o estado do serviço e a resposta vista pelo usuário foram verificados.

Prepare snapshots e recuperação pelo console da VM, em inglês, e compare as evidências antes e depois de cada alteração usando o procedimento de investigação por logs.

As referências são VMs convencionais Ubuntu 26.04 LTS ou Rocky Linux 9. Contêineres, WSL e outras versões podem diferir em serviços e pacotes. Confirme o acesso ao console e registre as versões antes do exercício.

Prepare o laboratório isolado e o estado normal

Use uma VM de laboratório Ubuntu ou Rocky Linux com gerenciador systemd de usuário, Python 3 e curl. O exercício não altera Nginx, SSH, firewall nem discos de produção. Confira com ss -lnt se a porta de loopback 18080 está livre; caso esteja em uso, escolha outra porta livre e altere todos os valores correspondentes no exercício.

Confira o caminho real com command -v python3. O exemplo usa /usr/bin/python3: se o caminho for diferente, ajuste ExecStart e também o texto procurado pelo sed no experimento 1, senão a substituição não produzirá a falha pretendida. Confirme que a nova entrada é realmente alterada antes de reiniciar.

Verifique antes se já existem linux-course-recovery.service ou ~/linux-recovery-lab, inclusive links simbólicos. Os comandos abaixo gravam e sobrescrevem arquivos: em caso de conflito, escolha nomes e caminhos novos e ajuste-os em todas as etapas, inclusive no backup e na remoção. O servidor HTTP de desenvolvimento do Python é destinado somente ao loopback deste exercício, não a um servidor de produção exposto à internet.

mkdir -p "$HOME/linux-recovery-lab/site" "$HOME/.config/systemd/user"
printf "recovery baseline\n" > "$HOME/linux-recovery-lab/site/index.html"
cat > "$HOME/.config/systemd/user/linux-course-recovery.service" <<'EOF'
[Unit]
Description=Isolated Linux recovery lab

[Service]
Type=simple
WorkingDirectory=%h/linux-recovery-lab/site
ExecStart=/usr/bin/python3 -m http.server 18080 --bind 127.0.0.1
EOF
systemctl --user daemon-reload
systemctl --user start linux-course-recovery.service
systemctl --user is-active linux-course-recovery.service
curl --fail --max-time 5 http://127.0.0.1:18080/
cp "$HOME/.config/systemd/user/linux-course-recovery.service" "$HOME/linux-recovery-lab/service.good"

Provoque uma falha somente após confirmar active e a resposta recovery baseline. O arquivo correto foi guardado em service.good; o serviço não foi habilitado para iniciar no boot. Se a base falhar, resolva primeiro o caminho do Python, a sintaxe da unidade ou o conflito de porta.

Experimento 1: altere somente o caminho do executável

sed -i 's@ExecStart=/usr/bin/python3 @ExecStart=/nonexistent/course-python @' "$HOME/.config/systemd/user/linux-course-recovery.service"
systemctl --user daemon-reload
systemctl --user restart linux-course-recovery.service
systemctl --user status linux-course-recovery.service --no-pager
journalctl --user -u linux-course-recovery.service --since "5 minutes ago" --no-pager

A unidade passa a apontar para um executável inexistente, portanto o serviço não permanece ativo. Dependendo do momento, a falha aparece no comando de início ou no status posterior. Procure no journal a falha de execução e um possível estado 203/EXEC; registre a mensagem real em vez de tratar toda falha de serviço como problema de rede.

Restaure a configuração e verifique a resposta

cp "$HOME/linux-recovery-lab/service.good" "$HOME/.config/systemd/user/linux-course-recovery.service"
systemctl --user daemon-reload
systemctl --user reset-failed linux-course-recovery.service
systemctl --user start linux-course-recovery.service
systemctl --user is-active linux-course-recovery.service
curl --fail --max-time 5 http://127.0.0.1:18080/

Restaure o arquivo válido, recarregue o gerenciador e inicie o serviço. reset-failed pode limpar o estado de falha e contadores do limite de início, mas não corrige uma configuração inválida. A recuperação exige tanto o estado esperado quanto o retorno da página correta.

Experimento 2: diferencie porta fechada e erro HTTP

curl -i --max-time 5 http://127.0.0.1:18080/missing-resource
systemctl --user stop linux-course-recovery.service
curl -i --connect-timeout 2 --max-time 5 http://127.0.0.1:18080/
ss -lnt
systemctl --user start linux-course-recovery.service
curl --fail --max-time 5 http://127.0.0.1:18080/

A primeira requisição recebe HTTP 404 do servidor ativo para um recurso inexistente. Depois de parar o serviço, a próxima falha na conexão, normalmente com recusa, em vez de receber um HTTP 404. Compare o comportamento do curl com e sem --fail: uma transferência comum que recebe 404 pode terminar com estado 0. Assim é possível distinguir falha de serviço, transporte e HTTP sem alterar o firewall.

Registre uma mudança de cada vez

Não encha o disco do sistema, bloqueie o SSH de administração nem apague arquivos aleatórios neste exercício. Testes mais disruptivos exigem clone separado, armazenamento limitado, console verificado e backups. O objetivo é aprender a decidir a partir de evidências, desde a observação até a recuperação.

Pare o laboratório e remova somente sua unidade

systemctl --user stop linux-course-recovery.service
systemctl --user reset-failed linux-course-recovery.service
rm -- "$HOME/.config/systemd/user/linux-course-recovery.service"
systemctl --user daemon-reload
ss -lnt

Confirme que a porta de loopback deixou de escutar. Examine e remova separadamente a pasta do laboratório, que contém o backup da unidade e a página estática. Se houver outros serviços, limite a limpeza do estado de falha à unidade do exercício, preservando os registros dos demais.

Referências oficiais

• Falhas de execução e estados de saída do systemd
• Estado e reset-failed no systemctl
• http.server do Python e limitações de segurança
• Tratamento de falhas de transporte e HTTP no curl