APRENDER. PRATICAR. EVOLUIR.O contrato de paragem começa na aplicação
Antes de parar um serviço, identifica o sinal efetivo, quem o recebe e que trabalho está em curso. A imagem pode definir STOPSIGNAL e a criação ou a operação podem introduzir overrides. No caso fictício, o lote precisa de 35 segundos e o prazo de stop é dez. A solução não se resume a aumentar um número: revê admissão de trabalho, drenagem, janela e critérios de conclusão. Um processo terminado não confirma que o ficheiro chegou ao consumidor. A recuperação deve contemplar o trabalho que ficou incompleto ou com resultado incerto.
Relacionar cronologia e causa provável
Uma ficha fictícia indica stop às 02:00:00, terminação às 02:00:10, código 137 e OOMKilled=false. Os tempos são coerentes com esgotamento do prazo de dez segundos, mas a conclusão exige correlação com eventos da instância e comportamento de shutdown. Evita converter um código de saída em causa universal. Guarda identidade, comando, horários e alteração recente. Se alguém iniciou um worker por docker exec, lembra que esse processo não se torna automaticamente parte do arranque permanente do contentor. A reconstrução da sequência deve incluir intervenções manuais que afetaram a instância.
Política de restart e intenção de manutenção
As políticas respondem a eventos distintos. on-failure usa a saída com erro e não entende se um ficheiro funcional ficou incompleto apesar de código zero. always pode voltar a iniciar após restart do daemon mesmo depois de uma paragem manual. unless-stopped preserva a intenção de paragem nesse contexto. Revê também automações externas que podem iniciar o serviço. Se uma mitigação usa docker update, reconcilia a configuração efetiva com o Compose mantido no repositório; uma recriação pode reaplicar a declaração antiga. Documenta a decisão antes da próxima intervenção, com responsável e âmbito.
Saúde não é o mesmo que ciclo de vida
Um healthcheck pode falhar enquanto o processo principal continua em execução. Num Engine standalone sem controlador adicional, a política de restart não deve ser tratada como recuperação automática de qualquer unhealthy. Define quem responde ao sinal, que observação confirma impacto e que mitigação pode ser autorizada. Um check em localhost pode ainda passar enquanto o cliente externo falha, porque mede outro percurso. Compara origem, listener, publicação, autenticação e resultado funcional. Estas decisões estão apoiadas em documentação e cenários originais; não foram exercitadas num daemon local nesta expansão.
Logs: capacidade, perda e evidência
O modo non-blocking usa um buffer intermédio; quando enche, novos registos podem perder-se. Isso protege o escritor de parte da pressão do destino, mas não garante uma trilha completa. Num caso fictício, 200 operações estão reconciliadas e só existem 150 eventos centrais. A diferença exige investigar observabilidade, não repetir automaticamente efeitos para fabricar os registos em falta. Revê ainda rotação e retenção de json-file e a configuração efetiva das instâncias: alterar defaults do daemon não atualiza automaticamente contentores existentes. Planeia aplicação da mudança sem apagar evidência necessária.
Oficina de recuperação com resultado incerto
Um worker fictício envia uma operação, perde a confirmação e sai com erro. O restart recupera um processo, mas não prova que o destinatário rejeitou a operação. Mantém a identidade funcional, reconcilia o resultado e decide repetição de acordo com o contrato da integração. Prepara a passagem em inglês: “The process restarted; the previous operation’s outcome remains unconfirmed.” Acrescenta instância, horários, saídas, política, logs disponíveis e decisões pendentes. O objetivo é recuperar o serviço preservando a distinção entre estar em execução e ter concluído o trabalho esperado.
Ficha fictícia: stop 02:00:00, prazo 10 s, saída 02:00:10/137, OOMKilled=false. A hipótese de prazo esgotado exige eventos e identificação da instância; não é uma execução registada do Docker.
Armadilhas comuns
Tratar always como suspensão permanente após stop; usar unhealthy como saída; interpretar zero como entrega funcional; esperar recuperação de processos exec; tomar ausência de log como ausência de efeito.
Tópicos relacionados: Processos e imagens · Dados e mounts · Compose: overrides, dados e aceitação
Liga política e cronologia ao trabalho real. Um restart pode recuperar execução sem reconciliar operações, corrigir a causa ou completar a evidência necessária para aceitar o serviço.
Referência: Start containers automatically · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped