Empêcher la veille du Mac pendant un build Docker

Pourquoi la veille annule un build Docker

Un docker build tourne en arrière-plan pendant que vous passez à autre chose — lire du code, répondre à un message, fermer le capot pour aller dans une autre pièce. C'est exactement la situation où une minuterie d'inactivité par défaut ou un capot fermé déclenche la veille.

La veille ne met pas un build en pause poliment pour le reprendre ensuite. Elle coupe le processus en pleine couche. Selon l'endroit où elle s'est arrêtée, vous perdez le cache de couche que vous attendiez et vous repartez de plus loin que vous ne le voudriez — parfois toute la couche d'installation des dépendances, parfois juste la dernière étape RUN.

Les builds réellement touchés par ce problème sont les images multi-étapes avec une installation de dépendances lente ou une grosse étape de compilation, ainsi que les builds multi-architectures — docker buildx build --platform linux/amd64,linux/arm64 -t myapp . fait passer chaque cible par de l'émulation sur un Mac et peut prendre plusieurs fois plus de temps qu'un build natif. Ce sont précisément les exécutions qui dépassent la durée d'une minuterie d'inactivité par défaut.

La solution native gratuite : caffeinate et pmset

Deux commandes déjà présentes sur tout Mac couvrent le cas courant, sans rien installer. caffeinate -i docker build -t myapp . exécute le build comme processus enfant de caffeinate, maintient une assertion « empêcher la veille d'inactivité » tant qu'il tourne, et la relâche automatiquement dès que docker build se termine — succès ou échec. Si le build tourne déjà ailleurs, caffeinate -w <pid> s'attache à cet identifiant de processus au lieu de lancer une nouvelle commande.

LidRun propose exactement la même astuce sous forme de commande CLI gratuite : lidrun -- docker build -t myapp . prend la même assertion macOS (kIOPMAssertionTypePreventUserIdleSystemSleep — celle-là même que le -i de caffeinate utilise) autour du processus enfant et la relâche quand la commande se termine. Elle ne nécessite ni licence ni application tournant en arrière-plan ; c'est un wrapper autonome, la même idée que caffeinate avec le nom de LidRun dessus.

Pour un build lancé dans un onglet de terminal que vous êtes sur le point de laisser tourner sans surveillance, sudo pmset noidle bloque la veille d'inactivité pour tout le système jusqu'à ce que vous fassiez Ctrl-C — pas de commande cible, juste un blocage global dont vous êtes seul responsable de la fin.

Les limites de caffeinate et pmset sur un vrai build

Aucune des deux commandes ne surveille la température ou la batterie. caffeinate -i et lidrun -- ... maintiennent l'assertion avec la même intensité que le SoC soit au repos et frais ou en pleine chauffe, et que la batterie soit à 80% ou à 3% — elles n'ont pas d'avis, elles maintiennent, point, jusqu'à ce que la commande enveloppée se termine.

Une assertion anti-veille-inactivité ne remplace pas la veille déclenchée par la fermeture du capot. Fermez le capot en plein build sans écran externe branché, et le Mac s'endort quand même, malgré caffeinate ou le wrapper CLI — il faut pour cela sudo pmset disablesleep 1, qui change le comportement de veille de tout le Mac, pas seulement du build. Oubliez de lancer pmset disablesleep 0 ensuite, et le Mac ne se remettra plus jamais en veille tout seul, capot ouvert ou fermé, tant que vous ne l'aurez pas fait.

Aucune de ces solutions ne se nettoie toute seule si vous les oubliez. Un onglet de terminal oublié, qui fait encore tourner caffeinate ou pmset noidle depuis un build lancé il y a une heure, garde le Mac éveillé — et, sur batterie, au chaud — bien après qu'il n'y ait plus rien à protéger.

Comment LidRun ajoute la couche de sécurité

L'application LidRun complète fait la même détection, avec un gouverneur qui veille par-dessus. Auto Mode embarque déjà docker et docker-compose dans sa liste de surveillance par défaut, donc un build est repéré dès qu'il démarre — rien à configurer. Auto Mode vérifie aussi le CPU : un processus détecté doit dépasser environ 20% de CPU (le seuil par défaut) pour compter comme actif, avec environ une minute de délai de grâce pour qu'un creux passager ne fasse pas tomber le maintien en plein build.

Cette vérification CPU ne pose en général aucun problème pour les processus de compilateur et de gestionnaire de paquets du build lui-même, mais selon votre configuration de Docker Desktop, le gros du travail peut se passer dans un processus de VM en arrière-plan pendant que le client docker reste, lui, proche de l'inactivité, se contentant de streamer la sortie. C'est à ça que sert la Smart Rule intégrée « Docker → maintien en éveil + refroidissement équilibré » : elle se déclenche dès que docker est simplement présent, sans plancher de CPU, et active Maintien en éveil plus un profil de refroidissement équilibré dès qu'elle en voit un tourner.

En plus de la détection, le Safety Governor de LidRun surveille ce même build. Si le SoC atteint le niveau thermique critique, il relâche immédiatement le maintien d'éveil, sur tous les modes et toutes les sources d'alimentation. Si la situation reste critique et que vous vous êtes absenté — ou que le capot est fermé — il monte d'un cran en laissant le Mac s'endormir pour de bon, plutôt que de laisser les ventilateurs mener un combat perdu d'avance. Un utilisateur présent, capot ouvert, n'est jamais mis en veille forcée pour la seule raison de la chaleur ; LidRun relâche le maintien pour laisser macOS décider, il ne coupe pas la session sous vos pieds.

La batterie reçoit le même traitement graduel : par défaut, LidRun avertit vers 15%, monte d'un cran à 5%, et ne maintient jamais au-delà d'un plancher qui ne peut pas descendre sous 4% — un arrêt contrôlé vaut mieux qu'un arrêt subi. Cet arrêt automatique de base est gratuit pour tout le monde ; Pro ajoute la possibilité d'ajuster chaque seuil. C'est le même arbitrage que LidRun applique partout ailleurs : agent — ou build — en cours, rester éveillé ; terminé ou dangereux, relâcher.

Le mettre en place pour un build Docker

Gratuit, sans licence : lidrun -- docker build -t myapp . depuis Terminal offre la même protection que caffeinate -i, avec le binaire de LidRun cette fois. Ça fonctionne de façon autonome — pas besoin que l'application complète soit ouverte.

Avec l'application ouverte, Auto Mode a déjà docker dans sa liste par défaut, donc un build est repéré sans toucher aux Réglages. Si vous préférez la version basée sur la simple présence — utile quand le processus client lui-même reste tranquille — ouvrez Smart Rules depuis le menu et activez la règle intégrée « Docker → maintien en éveil + refroidissement équilibré ». Auto Mode et Smart Rules sont des fonctionnalités Pro ; Maintien en éveil, Minuteur et Uniquement en charge restent gratuits et illimités dans tous les cas.

Pour un build qui doit survivre à un capot fermé, associez l'une des deux options ci-dessus au mode Closed-Lid (également Pro), sur une surface dure et ventilée, branché sur secteur. Closed-Lid est la seule chose dans l'application autorisée à appeler pmset disablesleep, et elle associe toujours le « on » à un « off » correspondant — à l'arrêt, à la fermeture de l'application, et au lancement suivant — donc ce n'est pas à vous de penser à revenir en arrière.

Pour un build multi-plateformes ponctuel lancé depuis un script, le wrapper CLI est en général le plus simple : lidrun -- docker buildx build --platform linux/amd64,linux/arm64 -t myapp . maintient le Mac éveillé exactement le temps que dure le build multi-architectures et relâche dès qu'il est terminé.

Quand vous en avez vraiment besoin

Tout ça, c'est pour les longs builds — une image construite depuis zéro, un rebuild complet en local façon CI, un run buildx multi-plateformes passant par l'émulation, une image de base sur laquelle vous itérez et qui prend vraiment du temps. Ce sont les builds qui dépassent une minuterie d'inactivité et qui méritent d'être protégés.

Un rebuild rapide avec un cache chaud se termine en quelques secondes et n'approche jamais d'une minuterie de veille — rien de tout cela n'est nécessaire pour l'itération au quotidien.

Si un long build est déjà mort à cause d'un capot fermé ou d'une minuterie d'inactivité plus d'une fois, c'est le signal : utilisez le wrapper CLI gratuit pour une exécution ponctuelle, ou l'application complète avec Auto Mode et la surveillance thermique en arrière-plan si vous préférez que tout soit géré sans y penser.

Conseils pour les builds lourds

Branchez le secteur pour les gros builds. Un CPU sollicité en continu — ou, avec buildx, du CPU émulé sur deux architectures à la fois — vide une batterie de portable rapidement, et l'alimentation secteur permet au Safety Governor de se concentrer sur la chaleur plutôt que sur la charge.

Gardez le Mac sur une surface dure et ventilée, surtout capot fermé. La chaleur d'une longue compilation doit bien aller quelque part, et un sac ou une surface molle bouche les grilles d'aération qui l'évacueraient.

Traitez les builds buildx multi-plateformes comme des « longs builds », même quand le build natif équivalent se termine d'habitude rapidement — la compilation croisée par émulation chauffe davantage et prend nettement plus de temps par architecture cible.

Si un build peut se figer ou boucler — une étape RUN instable retentée indéfiniment, un docker compose up laissé sans --build — ne le laissez pas maintenir le Mac éveillé indéfiniment par accident. Le wrapper CLI relâche dès que la commande se termine, dans tous les cas, et le temps de recharge d'une Smart Rule empêche LidRun de se redéclencher en boucle sur un conteneur qui crashe en boucle.