Evita que tu Mac se duerma durante un build largo de Xcode o cargo

Por qué un build se corta cuando te alejas

El temporizador de reposo por inactividad no sabe qué es un build. Vigila la actividad de entrada y de pantalla, no si clang va a la mitad de una unidad de traducción. Un build de cargo de 40 minutos sin ninguna pulsación de tecla se ve exactamente igual que una máquina inactiva, así que macOS hace lo responsable y se duerme.

Cuando se duerme a mitad del build, el trabajo se detiene donde estaba. Nada se corrompe, pero el compilador queda congelado, y cualquier caché incremental que se estaba calentando deja de hacerlo. Despiertas la Mac, el build se reanuda o vuelve a empezar, y la espera que creías que ya casi terminaba arranca de nuevo.

Es más molesto en los trabajos largos y silenciosos: un archive completo de Xcode, una instalación nueva de node_modules, un build de cargo en release con las optimizaciones activadas. Justo los builds que más quieres iniciar e ignorar son los que el temporizador de inactividad tiene más probabilidades de interrumpir.

La solución gratuita: envuelve el build en caffeinate

Antes de buscar cualquier app, prueba la herramienta que ya viene en la Mac. caffeinate es la utilidad de línea de comandos de la propia Apple para mantener aserciones de gestión de energía, y puede envolver un comando directamente: caffeinate -i cargo build --release mantiene una aserción contra el reposo por inactividad durante exactamente el tiempo que dure ese proceso, y la libera en el instante en que el proceso termina. Cambia el comando por el tuyo: caffeinate -i npm run build, caffeinate -i xcodebuild -scheme MyApp -configuration Release build, caffeinate -i make all.

El flag -i es el que importa aquí (evita el reposo por inactividad); -d además mantiene la pantalla encendida si quieres ver cómo se desplaza la salida, y -w <pid> te permite enganchar caffeinate a un proceso que ya está corriendo, en lugar de lanzarlo tú mismo. Para un build puntual en una máquina frente a la que estás sentado, es una respuesta completamente razonable, sin instalar nada, y vale la pena conocerla por sus propios méritos.

Para mucha gente, este es realmente el primer paso correcto. El resto de este artículo trata sobre dónde deja de ser suficiente, y cómo se ve una configuración que sí entiende el build y sí vigila la seguridad cuando eso pasa.

Dónde la solución gratuita se queda corta

caffeinate no tiene ni idea de en qué estado está la Mac. Mantiene la misma aserción contra el reposo con un 8% de batería en una laptop caliente que con un 90% sobre un escritorio con buena ventilación, porque no lee ninguna de las dos señales: es un wake lock, no una red de seguridad. Deja un build de release largo corriendo sin supervisión bajo caffeinate y no hay nada vigilando la batería ni el estado térmico en tu nombre.

También está limitado al proceso que envolviste, lo cual es una ventaja hasta que se convierte en un hueco. Cierra la pestaña de la terminal, pierde una sesión SSH, o deja que el shell reciba un SIGHUP, y la aserción puede morir con él a menos que hayas recordado usar nohup o disown, y ahí quedas sin protección en un build que creías cubierto.

La versión de este problema con la tapa cerrada es una herramienta completamente distinta: pmset -a disablesleep 1 es el flag que evita que una Mac se duerma con la tapa cerrada (el mismo flag que usa por debajo el propio modo clamshell de LidRun, siempre emparejado con un disablesleep 0 cuando se desactiva). Ejecútalo a mano para un solo build con la tapa cerrada y olvida revertirlo, y cada vez que cierres la tapa de esa Mac dejará de dormirse hasta que te acuerdes, lo cual es un riesgo real para algo que solo querías hacer una vez.

Herramientas de la barra de menú como Amphetamine, KeepingYouAwake, Lungo y Caffeine resuelven el problema de olvidarte, con una interfaz más agradable que escribir flags. Amphetamine en particular puede activarse cuando detecta una app corriendo en vez de necesitar un interruptor manual, y ofrece un disparador por nivel de batería para terminar una sesión, ambas cosas genuinamente útiles. Lo que ninguna de ellas hace, según sus listas de funciones publicadas, es combinar eso con la presión térmica en tiempo real, como sí hace un umbral de auto-detención que vigila batería y calor a la vez. Mantienen el bloqueo según el horario o el disparador que configuraste, y sigue siendo tarea tuya saber cuándo es momento de soltarlo.

Dos formas de LidRun que la mantienen despierta según el build

La promesa de base de LidRun es simple: si hay un agente o un build corriendo, se mantiene despierta; si el build termina o la Mac deja de estar segura, suelta el bloqueo y la deja dormir. Hay dos formas de lograrlo con un build nativo.

La primera es sin intervención manual. Auto Mode vigila las herramientas de desarrollo que le indiques, por nombre de proceso, o por línea de comandos en el caso de intérpretes como node y python, y mantiene la Mac despierta mientras realmente están trabajando. cargo, xcodebuild, swift, swiftc, npm, node, pnpm, yarn, make, cmake, ninja, gradle, mvn y dotnet ya están en la lista de vigilancia por defecto, no hay nada que agregar para un toolchain estándar. Un proceso solo cuenta como activo cuando su CPU supera un umbral (5% por defecto, ajustable), así que una Terminal inactiva no mantiene la Mac despierta, pero un compilador exprimiendo un núcleo sí. Un margen de espera, 60 segundos por defecto y ajustable entre 10 y 600, mantiene la aserción activa después de la última muestra ocupada, así una pausa breve entre fases del build no suelta el bloqueo.

La segunda es explícita: envuelve el build con lidrun -- <tu comando de build> y LidRun mantiene una aserción de keep-awake durante exactamente la vida de ese comando, y la libera en el momento en que el comando termina. El código de salida del propio comando se convierte en el código de salida de lidrun, así que $? (o un if lidrun -- npm run build; then … dentro de un script) te dice si el build pasó. LidRun no imprime una duración por su cuenta, así que pásalo por time si quieres eso: time lidrun -- cargo build --release.

Auto Mode es mejor cuando los builds van y vienen todo el día entre distintos proyectos; el wrapper es mejor cuando tienes un comando largo y específico que vigilar, o un script estilo CI. Ambos son funciones de Pro, no forman parte del nivel gratuito; el interruptor simple de Keep Awake (inicio y parada manuales, gratis para siempre) ya lleva el mismo Gobernador de seguridad de batería y temperatura que se describe más abajo, solo que no detecta el build por ti.

El Gobernador de seguridad sigue aplicando

Mantener una Mac despierta durante un build largo es la parte fácil. Hacerlo sin cocinar silenciosamente la batería o el chasis es la parte que vale la pena hacer bien, y por eso LidRun no se limita a desactivar el reposo y desentenderse, sin importar cuál de los dos modos anteriores uses.

Batería: un umbral de auto-detención, 20% por defecto y ajustable entre 15% y 50%, detiene el bloqueo en cuanto la carga cae por debajo de ese nivel, y desde ahí la Mac queda libre para dormirse con normalidad en lugar de seguir drenándose hasta quedarse sin batería. Térmico: LidRun rastrea la presión térmica a partir de las señales propias del SoC, no solo la lectura general del sistema operativo, y ante una lectura crítica el Gobernador de seguridad libera el bloqueo de keep-awake de inmediato; si además tienes activado "dormir si se sobrecalienta", puede escalar hasta poner realmente la Mac a dormir en lugar de solo soltar el bloqueo. Esto ayuda a reducir el riesgo, pero no hace imposible el sobrecalentamiento; la ventilación y dónde apoyas la laptop siguen siendo responsabilidad tuya.

Cada una de esas decisiones queda registrada en el Activity Log con un motivo: una entrada de auto-detención por batería indica el porcentaje en que se activó, una entrada térmica significa que el Gobernador de seguridad se replegó, así que si un build largo se cortó, puedes ver por qué en lugar de adivinar. Ese registro es la contrapartida honesta de no ser un wake lock a ciegas.

Configurarlo para los builds de todos los días

Auto Mode: haz clic en el ícono de LidRun en la barra de menú y activa Auto Mode. Para un toolchain normal de Xcode, npm o cargo no hay nada que configurar, las herramientas ya están en la lista de vigilancia por defecto. Subherramientas más generales de Apple, como clang y swift-frontend, corren durante muchas cosas no relacionadas, así que están desactivadas por defecto como chips opcionales en vez de vigilarse automáticamente; actívalas solo si específicamente quieres que LidRun reaccione a ellas.

Wrapper de CLI: instala el comando lidrun una vez desde el menú (escribe un pequeño script wrapper en /usr/local/bin/lidrun), y luego pasa tu build por él: lidrun -- cargo build --release, lidrun -- xcodebuild -scheme MyApp build, lidrun -- npm run build. Para un comando encadenado, pon todo entre comillas como un solo argumento, lidrun -- 'npm ci && npm run build', de lo contrario el shell corta en el && antes de que lidrun llegue a verlo, y solo la primera mitad queda protegida. En ambos casos espera un colchón corto similar: Auto Mode vuelve a revisar los procesos en ejecución cada 10 segundos y mantiene el bloqueo durante el margen de espera por defecto de 60 segundos, así que la Mac puede seguir despierta menos de un minuto después de que el build realmente termine. Eso es el comportamiento esperado, no un bug.

Si un build se cortó, abre primero el Activity Log en vez de volver a correrlo a ciegas; la entrada indica si fue un piso de batería o un repliegue térmico, y puedes subir el umbral de batería o mejorar la ventilación según corresponda. El modo Temporizador (con preajustes fijos de 30 minutos a 8 horas) es una herramienta distinta para un trabajo distinto, útil cuando sabes exactamente cuánto tiempo debería correr algo; para un build cuya duración no conoces de antemano, Auto Mode o el wrapper encajan mejor porque terminan cuando el trabajo termina, no según un reloj que tuviste que adivinar correctamente.

Dos hábitos que importan sin importar el modo: corre los trabajos más pesados, un clean build completo, un pase grande de LTO, sobre una superficie dura y plana con ventilación por debajo, y mantente conectado a corriente si puedes, ya que una laptop en batería sigue teniendo que respetar el piso de auto-detención, mientras que estar enchufada elimina esa cuestión por completo. Si tus builds corren dentro de contenedores, el mismo problema de reposo por inactividad aplica ahí también; el caso de builds con Docker se cubre por separado, ya que el proceso que LidRun necesita vigilar es distinto.