Impeça seu Mac de dormir durante um build longo no Xcode ou cargo

Por que um build morre quando você sai de perto

O timer de suspensão por inatividade não sabe o que é um build. Ele observa atividade de entrada e de tela, não se o clang está no meio de uma translation unit. Um build de cargo de 40 minutos sem nenhuma tecla pressionada parece exatamente uma máquina ociosa, então o macOS faz a coisa responsável e entra em suspensão.

Quando ele dorme no meio do build, o trabalho para exatamente onde estava. Nada é corrompido, mas o compilador congela, e qualquer cache incremental que estava esquentando para de esquentar. Você acorda o Mac, o build retoma ou recomeça, e a espera que você achava que estava quase no fim começa de novo.

É mais irritante nos jobs longos e silenciosos: um archive completo no Xcode, uma instalação nova de node_modules, um build de release do cargo com otimizações ligadas. Justamente os builds que você mais quer iniciar e ignorar são os que o timer de inatividade tem mais chance de interromper.

O truque grátis: envolva o build com caffeinate

Antes de recorrer a qualquer app, experimente a ferramenta que já vem no Mac. O caffeinate é o utilitário de linha de comando da própria Apple para segurar assertions de gerenciamento de energia, e ele pode envolver um comando diretamente: caffeinate -i cargo build --release segura uma assertion de anti-suspensão por inatividade pelo tempo exato em que esse processo roda, e a libera no instante em que o processo termina. Troque pelo seu próprio comando: caffeinate -i npm run build, caffeinate -i xcodebuild -scheme MyApp -configuration Release build, caffeinate -i make all.

A flag -i é a que importa aqui (impede a suspensão por inatividade); -d também mantém a tela acordada, caso você queira acompanhar a saída rolando na tela, e -w <pid> permite anexar o caffeinate a um processo que já está rodando, em vez de você mesmo iniciá-lo. Para um build único e pontual numa máquina em que você está sentado na frente, essa é uma resposta perfeitamente razoável e sem instalação nenhuma, que vale a pena conhecer por méritos próprios.

Esse é, sinceramente, o primeiro passo certo para muita gente. O restante deste texto é sobre onde ele deixa de ser suficiente, e como fica uma configuração ciente do build e com checagem de segurança quando isso acontece.

Onde o truque grátis para de dar conta

O caffeinate não tem a menor ideia do estado em que o Mac está. Ele segura a mesma assertion de anti-suspensão com 8% de bateria num laptop quente que seguraria com 90% numa mesa arejada, porque não está lendo nenhum dos dois sinais — é um wake lock, não uma rede de segurança. Deixe um build de release longo rodando sem supervisão sob o caffeinate e não há nada observando a bateria ou o estado térmico por você.

Ele também fica restrito ao processo que você envolveu, o que é um ponto forte até virar uma brecha. Feche a aba do terminal, perca uma sessão SSH, ou deixe o shell job levar um SIGHUP, e a assertion pode morrer junto, a menos que você tenha se lembrado de nohup ou disown — e aí você volta a ficar desprotegido num build que achava que estava coberto.

A versão desse problema com a tampa fechada é uma ferramenta totalmente diferente: pmset -a disablesleep 1 é a flag que impede o Mac de dormir com a tampa fechada (a mesma flag que o Closed-Lid do próprio LidRun usa por baixo dos panos, sempre emparelhada com um disablesleep 0 correspondente quando desliga). Rode isso na mão para um único build de tampa fechada e esqueça de desfazer, e todo fechamento de tampa futuro nesse Mac vai parar de dormir até você se lembrar — um perigo real para algo que era pra ser só uma vez.

Ferramentas de barra de menu como Amphetamine, KeepingYouAwake, Lungo e Caffeine resolvem o problema de esquecer com uma interface mais agradável do que digitar flags. O Amphetamine, em particular, consegue disparar a partir de um app em execução em vez de exigir um toggle manual, e oferece um gatilho por nível de bateria para encerrar uma sessão — os dois genuinamente úteis. O que nenhum deles faz, pelo que mostram seus conjuntos de recursos publicados, é combinar isso com pressão térmica ao vivo da forma como um limite de auto-stop tanto de bateria quanto de calor faz. Eles seguram o bloqueio no horário ou gatilho que você define, e continua sendo você quem precisa saber a hora de soltar.

Duas formas do LidRun manter o Mac acordado com consciência do build

A promessa de base do LidRun é simples: agente ou build rodando, fica acordado; build terminado ou Mac em risco, libera e deixa dormir. Duas formas de chegar lá num build nativo.

A primeira é sem intervenção manual. O Auto Mode observa as ferramentas de desenvolvimento que você indicar, por nome de processo, ou pela linha de comando para interpretadores como node e python, e mantém o Mac acordado enquanto elas estão realmente trabalhando. cargo, xcodebuild, swift, swiftc, npm, node, pnpm, yarn, make, cmake, ninja, gradle, mvn e dotnet já estão na lista de observação padrão — nada a adicionar para um toolchain padrão. Um processo só conta como ativo quando sua CPU está acima de um limite (5% por padrão, ajustável), então um Terminal ocioso não mantém o Mac acordado, mas um compilador cravando um núcleo mantém. Um holdoff, de 60 segundos por padrão e ajustável de 10 a 600, mantém a assertion viva depois da última amostra de atividade, para que uma pequena pausa entre fases do build não derrube o bloqueio.

A segunda é explícita: envolva o build com lidrun -- <seu comando de build> e o LidRun segura uma assertion de keep-awake pelo tempo exato de vida desse comando, liberando-a no instante em que o comando termina. O código de saída do próprio comando vira o código de saída do lidrun, então $? (ou um if lidrun -- npm run build; then … num script) diz se o build passou. O LidRun não imprime uma duração por conta própria, então passe por time se quiser isso: time lidrun -- cargo build --release.

O Auto Mode é melhor quando builds vêm e vão o dia todo em projetos diferentes; o wrapper é melhor quando você tem um comando longo específico para vigiar, ou um script no estilo CI. Os dois são recursos Pro, fora do plano grátis — o toggle simples Keep Awake (início e fim manuais, grátis para sempre) já carrega o mesmo controlador de segurança de bateria e temperatura descrito abaixo, só não detecta o build por você.

O controlador de segurança continua valendo

Manter o Mac acordado para um build longo é a parte fácil. Fazer isso sem cozinhar silenciosamente a bateria ou o chassi é a parte que vale a pena acertar, e é por isso que o LidRun não simplesmente desliga a suspensão e sai de cena, seja qual for um dos dois modos acima que você usar.

Bateria: um limite de auto-stop, de 20% por padrão e ajustável de 15% a 50%, encerra o bloqueio assim que a carga cai abaixo dele, e o Mac fica livre para dormir normalmente a partir daí, em vez de continuar drenando rumo ao zero. Térmico: o LidRun acompanha a pressão térmica a partir dos próprios sinais do SoC, não só a leitura genérica do sistema operacional, e numa leitura crítica o Safety Governor libera o bloqueio de keep-awake imediatamente; se você também tiver o "dormir quando superaquecer" ligado, ele pode escalar para efetivamente colocar o Mac para dormir, em vez de só liberar o bloqueio. Isso ajuda a reduzir o risco, mas não torna o superaquecimento impossível — ventilação e onde você apoia o laptop continuam sendo responsabilidade sua.

Cada uma dessas decisões é registrada no Activity Log com um motivo — uma entrada de auto-stop por bateria nomeia o percentual em que disparou, uma entrada térmica significa que o Safety Governor recuou — então, se um build longo foi cortado, você consegue ver o porquê em vez de ficar chutando. Esse registro é a troca honesta por não ser um wake lock cego.

Configurando para builds do dia a dia

Auto Mode: clique no ícone do LidRun na barra de menu e ative o Auto Mode. Para um toolchain normal de Xcode, npm ou cargo não há nada para configurar, as ferramentas já estão na lista de observação padrão. Subferramentas mais amplas da Apple, como clang e swift-frontend, rodam durante muita coisa sem relação direta, então elas ficam desligadas por padrão como chips opt-in em vez de serem observadas automaticamente — ative-as só se você quiser especificamente que o LidRun reaja a elas.

Wrapper de CLI: instale o comando lidrun uma vez pelo menu (ele grava um pequeno script wrapper em /usr/local/bin/lidrun), depois rode seu build através dele: lidrun -- cargo build --release, lidrun -- xcodebuild -scheme MyApp build, lidrun -- npm run build. Para um comando encadeado, coloque tudo entre aspas como um único argumento, lidrun -- 'npm ci && npm run build', senão o shell divide no && antes mesmo do lidrun ver o comando, e só a primeira metade fica protegida. Espere mais ou menos a mesma pequena sobra de tempo nos dois casos: o Auto Mode reverifica os processos em execução a cada 10 segundos e segura durante o holdoff padrão de 60 segundos, então o Mac pode continuar acordado por menos de um minuto depois que o build realmente termina. Isso é comportamento esperado, não um bug.

Se um build foi cortado, abra o Activity Log primeiro em vez de rodar tudo de novo no escuro — a entrada indica se foi um piso de bateria ou um recuo térmico, e você pode aumentar o limite de bateria ou melhorar a ventilação de acordo. O modo Timer (predefinições fixas de 30 minutos a 8 horas) é uma ferramenta diferente para um trabalho diferente, útil quando você sabe exatamente quanto tempo algo deve rodar; para um build cuja duração você não conhece de antemão, o Auto Mode ou o wrapper encaixam melhor, porque terminam quando o trabalho termina, não num relógio que você teve que adivinhar certo.

Dois hábitos que importam independentemente do modo: rode os jobs mais pesados — um clean build completo, uma passada grande de LTO — numa superfície dura e plana, com ventilação por baixo, e fique na tomada sempre que puder, já que um laptop na bateria ainda tem o piso de auto-stop a respeitar, e a energia da tomada remove essa questão por completo. Se seus builds rodam dentro de containers, o mesmo problema de suspensão por inatividade se aplica lá também — o caso do build com Docker é tratado à parte, já que o processo que o LidRun precisa observar é diferente.