Evita que tu Mac se duerma durante un build de Docker

Por qué la suspensión cancela un build de Docker

Un docker build corre en segundo plano mientras haces otra cosa — leer código, responder un mensaje, cerrar la tapa para ir a otro cuarto. Esa es exactamente la situación en la que un temporizador de inactividad por defecto o una tapa cerrada activan la suspensión.

La suspensión no pausa un build con delicadeza para retomarlo después. Corta el proceso a mitad de capa. Según dónde se detuvo, pierdes la caché de esa capa que estabas esperando y terminas reconstruyendo desde más atrás de lo que quisieras — a veces toda la capa de instalación de dependencias, a veces solo el último paso RUN.

Los builds que en verdad sufren esto son las imágenes multi-etapa con una instalación de dependencias lenta o un paso de compilación pesado, y los builds multi-arquitectura — docker buildx build --platform linux/amd64,linux/arm64 -t myapp . corre cada destino por emulación en un Mac y puede tardar varias veces más que un build nativo. Esas son justo las corridas que superan un temporizador de inactividad por defecto.

El arreglo gratuito y nativo: caffeinate y pmset

Dos comandos que ya vienen en todo Mac cubren el caso común, sin instalar nada. caffeinate -i docker build -t myapp . corre el build como proceso hijo de caffeinate, mantiene una aserción de 'prevenir suspensión por inactividad' mientras dura, y la libera automáticamente en cuanto docker build termina — con éxito o con error. Si el build ya está corriendo en otro lado, caffeinate -w <pid> se engancha a ese id de proceso en lugar de arrancar un comando nuevo.

LidRun trae exactamente el mismo truco como comando CLI gratuito: lidrun -- docker build -t myapp . toma la misma aserción de macOS (kIOPMAssertionTypePreventUserIdleSystemSleep — la misma que usa el -i de caffeinate) alrededor del proceso hijo y la libera cuando el comando termina. No necesita licencia ni la app corriendo en segundo plano; es un wrapper autónomo, la misma idea que caffeinate con el nombre de LidRun.

Para un build que arrancaste en una pestaña de terminal de la que estás por alejarte, sudo pmset noidle bloquea la suspensión por inactividad en todo el sistema hasta que le hagas Ctrl-C — sin comando objetivo, solo un bloqueo general del que tú eres responsable de terminar.

Dónde caffeinate y pmset se quedan cortos en un build real

Ninguno de los dos comandos vigila temperatura ni batería. caffeinate -i y lidrun -- ... mantienen la aserción con la misma fuerza sin importar si el SoC está frío en reposo o corriendo caliente, y sin importar si la batería está en 80% o en 3% — no tienen opinión, solo sostienen hasta que el comando envuelto termina.

Una aserción de suspensión por inactividad no anula la suspensión por tapa cerrada. Si cierras la tapa a mitad del build sin un monitor externo conectado, el Mac igual se duerme por debajo de caffeinate o del wrapper CLI — para eso hace falta sudo pmset disablesleep 1, que afecta el comportamiento de suspensión de todo el Mac, no solo el build. Si te olvidas de correr pmset disablesleep 0 después, el Mac no volverá a dormirse por sí solo, con la tapa abierta o cerrada, hasta que lo hagas.

Ninguno de estos se limpia solo si te olvidas de ellos. Una pestaña de terminal de sobra que sigue corriendo caffeinate o pmset noidle de un build de hace una hora mantiene el Mac despierto — y, con batería, caliente — mucho después de que quede algo que proteger.

Cómo LidRun agrega la capa de seguridad

La app completa de LidRun hace la misma detección, pero con un gobernador vigilando todo. Auto Mode viene con docker y docker-compose ya en su lista de vigilancia por defecto, así que un build aparece en el momento en que arranca — nada que configurar. Auto Mode también revisa la CPU: un proceso detectado necesita superar más o menos 20% de CPU (el umbral por defecto) antes de contar como activo, con cerca de un minuto de margen para que una baja breve no suelte el bloqueo a mitad del build.

Esa revisión de CPU normalmente no es problema para los propios procesos del compilador o del gestor de paquetes del build, pero según tu configuración de Docker Desktop, el trabajo pesado puede pasar dentro de un proceso de VM en segundo plano mientras el cliente docker en sí se queda casi inactivo transmitiendo la salida. Para eso está la Smart Rule integrada "Docker → keep awake + balanced cooling": se activa con solo que docker esté presente, sin piso de CPU, y enciende Keep Awake más un perfil de enfriamiento balanceado en cuanto ve uno corriendo.

Además de la detección, el Safety Governor de LidRun vigila ese mismo build. Si el SoC llega al nivel térmico crítico, libera el bloqueo de keep-awake de inmediato, en cualquier modo y con cualquier fuente de energía. Si sigue en crítico y te alejaste — o la tapa está cerrada — escala hasta dejar que el Mac se duerma de verdad, en lugar de dejar que los ventiladores peleen una batalla perdida. A un usuario presente con la tapa abierta nunca se lo fuerza a dormir solo por calor; LidRun libera el bloqueo para que macOS decida, no te corta la sesión por debajo.

La batería recibe el mismo trato gradual: por defecto LidRun avisa cerca del 15%, escala al 5%, y no sostiene el bloqueo más allá de un piso que no puede bajar de 4% — una parada controlada es mejor que una descontrolada. Ese auto-stop base es gratis para todos; Pro agrega la posibilidad de ajustar cada umbral. Es el mismo trato que hace LidRun en todos lados: si el agente — o el build — está corriendo, se mantiene despierto; si terminó o no es seguro, se libera.

Cómo configurarlo para un build de Docker

Gratis, sin licencia: lidrun -- docker build -t myapp . desde Terminal te da la misma protección que caffeinate -i, solo que con el propio binario de LidRun. Funciona de forma independiente — no hace falta tener la app completa abierta.

Con la app abierta, Auto Mode ya tiene docker en su lista por defecto, así que un build se detecta sin tocar Settings. Si prefieres la versión basada en presencia — útil cuando el propio proceso cliente corre frío — abre Smart Rules desde el menú y activa la regla integrada "Docker → keep awake + balanced cooling". Auto Mode y Smart Rules son funciones Pro; Keep Awake, Timer, y Charging-only run se mantienen gratis y sin límite de cualquier forma.

Para un build que quieres que sobreviva a la tapa cerrada, combina cualquiera de las opciones anteriores con Closed-Lid mode (también Pro), sobre una superficie dura y ventilada y conectado a la corriente. Closed-Lid mode es lo único en la app autorizado a llamar pmset disablesleep, y siempre empareja el 'on' con un 'off' correspondiente — al detenerse, al cerrar la app, y al siguiente arranque — así que revertirlo no es algo que tengas que recordar tú mismo.

Para un build multi-plataforma puntual desde un script, el wrapper CLI suele ser lo más simple: lidrun -- docker buildx build --platform linux/amd64,linux/arm64 -t myapp . mantiene el Mac despierto exactamente el tiempo que dura el build multi-arquitectura y lo suelta en cuanto termina.

Cuándo de verdad necesitas esto

Esto es para los builds largos — una imagen desde cero, una reconstrucción completa estilo CI hecha en local, una corrida de buildx multi-plataforma por emulación, una imagen base sobre la que estás iterando y que tarda de verdad. Esos son los builds que superan un temporizador de inactividad y valen la pena proteger.

Una reconstrucción rápida con caché caliente termina en segundos y ni se acerca a un temporizador de suspensión — nada de esto hace falta para la iteración del día a día.

Si un build largo se te ha muerto por cerrar la tapa o por un timeout de inactividad más de una vez, esa es la señal: usa el wrapper CLI gratuito para una corrida puntual, o la app completa con Auto Mode y la vigilancia térmica corriendo en segundo plano si prefieres que se maneje solo, sin tener que pensarlo.

Consejos para builds pesados

Conecta a la corriente para builds grandes. La CPU sostenida — o, con buildx, CPU emulada en dos arquitecturas a la vez — drena una laptop rápido, y la corriente eléctrica mantiene la atención del safety governor en el calor y no en la carga.

Mantén el Mac sobre una superficie dura y ventilada, sobre todo con la tapa cerrada. El calor de una compilación larga tiene que ir a algún lado, y una mochila o una superficie blanda bloquea las rejillas que lo sacarían.

Trata los builds multi-plataforma con buildx como el caso de 'build largo' incluso cuando el equivalente nativo suele terminar rápido — compilar cruzado por emulación corre más caliente y tarda notablemente más por cada arquitectura destino.

Si un build se puede colgar o entrar en loop — un paso RUN inestable que se reintenta sin fin, un docker compose up que se dejó sin --build — no dejes que mantenga el Mac despierto sin fin por accidente. El wrapper CLI se libera en cuanto el comando termina de cualquier forma, y el cooldown de una Smart Rule evita que LidRun se re-active sin parar con un contenedor en crash-loop.