Questão de Sistemas Operacionais — Contêineres (Docker, Kubernetes, etc.) — CESPE / CEBRASPE 2025

Deadlock em Pods e Verificação de Sanidade (Health Check)

Gabarito: letra E (ERRADO). A verificação de sanidade (health check / liveness probe) não resolve um deadlock — ela apenas detecta que o processo não está respondendo e, no Kubernetes, reinicia o contêiner. O deadlock é um impasse lógico entre processos que esperam recursos uns dos outros; a solução correta envolve prevenção, detecção e recuperação, não a simples verificação de sanidade. A afirmação confunde o mecanismo de monitoramento com o mecanismo de resolução de um problema de concorrência.

O deadlock (interbloqueio) é uma situação clássica de sistemas operacionais em que dois ou mais processos ficam permanentemente bloqueados, cada um aguardando um recurso que o outro detém. As quatro condições de Coffman — exclusão mútua, posse e espera, não-preempção e espera circular — precisam ocorrer simultaneamente para que o impasse se estabeleça. A resolução de um deadlock pode se dar por prevenção (negar uma das condições), por detecção e recuperação (identificar o ciclo e matar um processo ou preemptar recursos) ou por estratégias como o algoritmo do avestruz (ignorar o problema). Nenhuma dessas abordagens tem relação com health checks.

A verificação de sanidade, por sua vez, é um mecanismo de monitoramento de disponibilidade. No Kubernetes, as liveness probes verificam se o contêiner está vivo; se a probe falhar, o kubelet mata o contêiner e o reinicia conforme a política de restart. As readiness probes verificam se o contêiner está pronto para receber tráfego. Essas sondas são essenciais para a autorrecuperação de aplicações, mas atuam sobre sintomas (processo sem resposta), não sobre a causa lógica do deadlock. Se um processo está em deadlock, ele pode até continuar respondendo a probes superficiais, pois o impasse não necessariamente trava a CPU ou a rede — ele trava a lógica de acesso a recursos.

Na prática, se um processo dentro de um pod sofrer um deadlock, a liveness probe pode detectar a falta de resposta e reiniciar o contêiner, o que indiretamente resolve o problema ao recomeçar o processo do zero. Mas isso não é "utilizar a verificação de sanidade para resolver o deadlock" — é usar a verificação como gatilho para uma ação de recuperação (restart). A afirmação do enunciado atribui à verificação de sanidade um papel que ela não tem: o de resolver o impasse em si. A resolução efetiva exige intervenção no código (corrigir a lógica de concorrência), no escalonamento ou na alocação de recursos.

A pegadinha da banca está em confundir o papel do health check (monitorar e sinalizar) com o papel da resolução de deadlock (intervir na lógica de concorrência). O candidato que conhece apenas o conceito superficial de "health check mantém a aplicação ativa" pode marcar como certo, mas a afirmação é tecnicamente imprecisa: a verificação de sanidade não resolve deadlocks, apenas detecta indisponibilidade e, indiretamente, pode levar a um restart.

Item — ❌ ERRADO

A afirmação está incorreta porque atribui à verificação de sanidade (health check) a capacidade de resolver um deadlock. O health check apenas verifica se o processo está respondendo; ele não age sobre a causa do impasse. A resolução de deadlock envolve técnicas como prevenção (negar uma das condições de Coffman), detecção e recuperação (matar processos ou preemptar recursos) ou correção do código. O health check pode, indiretamente, levar a um restart do contêiner, mas isso não é "resolver o deadlock" — é reiniciar o processo, o que pode ou não eliminar o problema, dependendo da causa.

Gabarito: letra E (ERRADO).