Evite que o Mac durma durante um build do Docker

Por que o sleep cancela um build do Docker

Um docker build roda em segundo plano enquanto você faz outra coisa — lê código, responde uma mensagem, fecha a tampa pra ir a outro cômodo. É exatamente nessa situação que o temporizador de inatividade padrão ou a tampa fechada dispara o sleep.

O sleep não pausa um build educadamente pra retomar depois. Ele corta o processo no meio de uma layer. Dependendo de onde parou, você perde o cache da layer que estava esperando e acaba reconstruindo a partir de um ponto bem mais atrás do que gostaria — às vezes a layer inteira de instalação de dependências, às vezes só o último passo RUN.

Os builds que realmente esbarram nisso são imagens multi-stage com uma instalação de dependências lenta ou uma etapa de compilação pesada, e builds multiplataforma — docker buildx build --platform linux/amd64,linux/arm64 -t myapp . roda cada alvo por emulação no Mac e pode levar várias vezes mais tempo que um build nativo. São exatamente essas execuções que ultrapassam um temporizador de inatividade padrão.

O fix gratuito e nativo: caffeinate e pmset

Dois comandos que já vêm em todo Mac resolvem o caso comum, sem precisar instalar nada. caffeinate -i docker build -t myapp . roda o build como processo filho do caffeinate, mantém uma trava de 'prevenir sleep por inatividade' enquanto ele estiver rodando, e a libera automaticamente no instante em que docker build termina — com sucesso ou com falha. Se o build já estiver rodando em outro lugar, caffeinate -w <pid> se conecta a esse process id em vez de iniciar um novo comando.

O LidRun traz exatamente o mesmo truque como um comando de CLI gratuito: lidrun -- docker build -t myapp . pega a mesma assertion do macOS (kIOPMAssertionTypePreventUserIdleSystemSleep — a mesma que a flag -i do caffeinate usa) em volta do processo filho e a libera quando o comando termina. Não precisa de licença nem de um app rodando em segundo plano; é um wrapper autocontido, a mesma ideia do caffeinate com o nome do LidRun.

Para um build iniciado numa aba de terminal que você está prestes a deixar sozinha, sudo pmset noidle bloqueia o sleep por inatividade em todo o sistema até você dar Ctrl-C — sem comando alvo, é uma trava geral que fica por sua conta encerrar.

Onde caffeinate e pmset deixam a desejar num build real

Nenhum dos dois comandos observa temperatura ou bateria. caffeinate -i e lidrun -- ... mantêm a trava com a mesma força esteja o SoC frio e ocioso ou rodando quente, e esteja a bateria em 80% ou em 3% — eles não têm opinião, só seguram até o comando encapsulado terminar.

Uma trava de sleep por inatividade não sobrepõe o sleep por tampa fechada. Feche a tampa no meio do build sem um monitor externo conectado e o Mac ainda assim dorme por baixo do caffeinate ou do wrapper de CLI — isso exige sudo pmset disablesleep 1, que afeta o comportamento de sleep do Mac inteiro, não só o build. Esqueça de rodar pmset disablesleep 0 depois e o Mac não vai mais dormir sozinho, com a tampa aberta ou fechada, até você fazer isso.

Nenhum desses comandos se limpa sozinho se você esquecer deles. Uma aba de terminal esquecida ainda rodando caffeinate ou pmset noidle de um build de uma hora atrás mantém o Mac acordado — e, na bateria, quente — muito depois de sobrar algo pra proteger.

Como o LidRun acrescenta a camada de segurança

O app completo do LidRun faz a mesma detecção, só que com um governor de olho em tudo. O Auto Mode já vem com docker e docker-compose na lista de observação padrão, então um build aparece assim que começa — nada pra configurar. O Auto Mode também checa a CPU: um processo detectado precisa passar de uns 20% de CPU (o limiar padrão) pra contar como ativo, com cerca de um minuto de tolerância pra uma queda breve não derrubar a trava no meio do build.

Essa checagem de CPU normalmente não é problema pros processos do próprio compilador e do gerenciador de pacotes do build, mas dependendo da sua configuração do Docker Desktop o trabalho pesado pode acontecer dentro de um processo de VM em segundo plano, enquanto o cliente docker em si fica mais perto do ocioso só transmitindo output. É pra isso que serve a Smart Rule embutida "Docker → keep awake + balanced cooling": ela dispara com o docker simplesmente presente, sem piso de CPU, e liga o Keep Awake mais um perfil de resfriamento balanceado no instante em que vê um rodando.

Além da detecção, o Safety Governor do LidRun observa o mesmo build. Se o SoC atinge o nível térmico crítico, ele libera a trava de keep-awake na hora, em qualquer modo e em qualquer fonte de energia. Se continua crítico e você se afastou — ou a tampa está fechada — ele escala pra deixar o Mac de fato dormir, em vez de deixar as ventoinhas numa batalha perdida. Um usuário presente com a tampa aberta nunca é forçado a dormir só por causa do calor; o LidRun libera a trava pra que o macOS decida, ele não corta a sessão por baixo de você.

A bateria recebe o mesmo tratamento gradual: por padrão o LidRun avisa perto de 15%, escala em 5%, e não segura além de um piso que não pode ficar abaixo de 4% — uma parada controlada é melhor que uma descontrolada. Esse auto-stop básico é gratuito pra todo mundo; o Pro acrescenta a possibilidade de ajustar cada limiar. É a mesma troca que o LidRun faz em todo lugar: agente — ou build — rodando, fica acordado; terminado ou inseguro, libera.

Configurando isso pra um build do Docker

Gratuito, sem licença: lidrun -- docker build -t myapp . no Terminal dá a mesma proteção que caffeinate -i, só que com o binário do próprio LidRun. Funciona sozinho — o app completo não precisa estar aberto.

Com o app aberto, o Auto Mode já tem docker na lista padrão, então um build é detectado sem você mexer em Settings. Se preferir a versão baseada em presença — útil quando o próprio processo cliente roda frio — abra Smart Rules no menu e ative a regra embutida "Docker → keep awake + balanced cooling". Auto Mode e Smart Rules são recursos Pro; Keep Awake, Timer e Charging-only run continuam gratuitos e ilimitados de qualquer forma.

Pra um build que precisa sobreviver com a tampa fechada, combine qualquer uma das opções acima com o Closed-Lid mode (também Pro), numa superfície dura e ventilada e na tomada. O Closed-Lid mode é a única coisa no app com permissão pra chamar pmset disablesleep, e ele sempre combina o 'on' com um 'off' correspondente — ao parar, ao fechar o app e na próxima abertura — então reverter isso não é algo que você precisa lembrar de fazer sozinho.

Pra um build multiplataforma pontual disparado por um script, o wrapper de CLI costuma ser o mais simples: lidrun -- docker buildx build --platform linux/amd64,linux/arm64 -t myapp . mantém o Mac acordado exatamente pelo tempo que o build multiarquitetura leva e solta assim que termina.

Quando você realmente precisa disso

Isso é pros builds longos — uma imagem do zero, um rebuild completo estilo CI rodado localmente, uma execução multiplataforma do buildx via emulação, uma imagem base em que você está iterando e que leva um tempo de verdade. Esses são os builds que ultrapassam um temporizador de inatividade e valem a pena proteger.

Um rebuild rápido com o cache aquecido termina em segundos e nem chega perto de um temporizador de sleep — nada disso é necessário pra iteração do dia a dia.

Se um build longo já morreu por causa de uma tampa fechada ou de um timeout de inatividade mais de uma vez, esse é o sinal: use o wrapper de CLI gratuito numa execução pontual, ou o app completo com o Auto Mode e o monitoramento térmico rodando em segundo plano se preferir que isso seja resolvido sem você precisar pensar nisso.

Dicas pra builds pesados

Fique na tomada pra builds grandes. CPU sustentada — ou, com o buildx, CPU emulada em duas arquiteturas ao mesmo tempo — drena a bateria do notebook rápido, e ficar na tomada mantém a atenção do safety governor voltada pro calor em vez da carga.

Mantenha o Mac numa superfície dura e ventilada, principalmente com a tampa fechada. O calor de uma compilação longa precisa ir pra algum lugar, e uma mochila ou uma superfície macia bloqueia as saídas de ar que o dissipariam.

Trate builds multiplataforma do buildx como o caso de 'build longo' mesmo quando o build nativo equivalente normalmente termina rápido — compilar via emulação roda mais quente e leva visivelmente mais tempo por arquitetura alvo.

Se um build pode travar ou entrar em loop — um passo RUN instável sendo repetido indefinidamente, um docker compose up deixado sem --build — não deixe isso manter o Mac acordado indefinidamente por acidente. O wrapper de CLI libera no instante em que o comando termina de qualquer forma, e o cooldown de uma Smart Rule impede que o LidRun fique disparando sem parar num container em crash loop.