Empêcher un Mac de s'endormir pendant un long build Xcode ou cargo

Pourquoi un build s'arrête quand vous vous éloignez

Le minuteur de veille par inactivité ne sait pas ce qu'est un build. Il surveille les entrées clavier/souris et l'activité de l'écran, pas si clang est à mi-chemin dans une translation unit. Un build cargo de 40 minutes sans la moindre frappe ressemble exactement à une machine inactive, alors macOS fait ce qu'il juge responsable : il se met en veille.

Quand la veille survient en plein build, le travail se fige là où il en était. Rien n'est corrompu, mais le compilateur est gelé, et tout cache incrémental en train de se construire cesse de le faire. Vous réveillez le Mac, le build reprend ou redémarre, et l'attente que vous pensiez presque terminée recommence.

C'est le plus agaçant sur les tâches longues et silencieuses : un archive Xcode complet, une installation fraîche de node_modules, un build cargo en mode release avec les optimisations activées. Ce sont justement les builds que vous voulez le plus lancer puis oublier qui sont les plus susceptibles d'être interrompus par le minuteur de veille.

La solution gratuite : envelopper le build dans caffeinate

Avant de chercher une app, essayez l'outil déjà présent sur le Mac. caffeinate est l'utilitaire en ligne de commande d'Apple pour maintenir des assertions de gestion d'énergie, et il peut envelopper une commande directement : caffeinate -i cargo build --release maintient une assertion anti-veille exactement le temps que tourne ce processus, puis la relâche à l'instant où le processus se termine. Remplacez par votre propre commande : caffeinate -i npm run build, caffeinate -i xcodebuild -scheme MyApp -configuration Release build, caffeinate -i make all.

Le flag -i est celui qui compte ici (empêcher la veille par inactivité) ; -d garde aussi l'écran allumé si vous voulez regarder la sortie défiler, et -w <pid> permet d'attacher caffeinate à un processus déjà lancé plutôt que de le démarrer vous-même. Pour un build ponctuel unique sur une machine devant laquelle vous êtes assis, c'est une réponse tout à fait raisonnable, sans rien installer, et qui mérite d'être connue pour ce qu'elle est.

C'est vraiment le bon premier réflexe pour beaucoup de gens. La suite de cet article traite du moment où cela cesse de suffire, et de ce à quoi ressemble une configuration consciente du build et vérifiée côté sécurité une fois qu'on dépasse ce point.

Où la solution gratuite atteint ses limites

caffeinate n'a aucune idée de l'état du Mac. Il maintient la même assertion anti-veille à 8 % de batterie sur un portable brûlant qu'à 90 % sur un bureau bien ventilé, parce qu'il ne lit ni l'un ni l'autre signal : c'est un verrou d'éveil, pas un filet de sécurité. Laissez tourner un long build release sans surveillance sous caffeinate, et rien ne surveille la batterie ni l'état thermique à votre place.

Il est aussi limité au processus que vous avez enveloppé, ce qui est une force jusqu'à ce que ça devienne une faille. Fermez l'onglet du terminal, perdez une session SSH, ou laissez le job shell recevoir un SIGHUP, et l'assertion peut mourir avec lui, sauf si vous avez pensé à nohup ou disown — et vous voilà de nouveau sans protection sur un build que vous pensiez couvert.

La version « couvercle fermé » de ce problème est un tout autre outil : pmset -a disablesleep 1 est le flag qui empêche un Mac de s'endormir couvercle fermé (le même flag qu'utilise en coulisse le mode clamshell de LidRun, toujours associé à un disablesleep 0 correspondant quand il se désactive). Lancez-le à la main pour un seul build couvercle fermé et oubliez de le repasser à 0, et toutes les prochaines fermetures de couvercle sur ce Mac empêcheront la veille jusqu'à ce que vous vous en souveniez — un vrai piège pour ce qui devait n'être qu'un usage ponctuel.

Des outils de barre de menu comme Amphetamine, KeepingYouAwake, Lungo et Caffeine règlent le problème du « il faut y penser » avec une interface plus agréable que de taper des flags. Amphetamine en particulier peut se déclencher sur une app en cours d'exécution plutôt que d'exiger une bascule manuelle, et propose un déclencheur basé sur le niveau de batterie pour terminer une session — deux fonctions vraiment utiles. Ce qu'aucun d'eux ne fait, d'après leurs fiches de fonctionnalités publiées, c'est combiner cela avec la pression thermique en temps réel, comme le fait un seuil d'arrêt automatique portant à la fois sur la batterie et la chaleur. Ils maintiennent le verrou selon le planning ou le déclencheur que vous avez fixé, et c'est toujours à vous de savoir quand il est temps de le relâcher.

Deux méthodes de LidRun, conscientes du build, pour le garder éveillé

La promesse de fond de LidRun est simple : agent ou build en cours, rester éveillé ; build terminé ou Mac en zone de risque, relâcher et laisser dormir. Deux façons d'y arriver pour un build natif.

La première est automatique. Auto Mode surveille les outils de développement que vous lui indiquez, par nom de processus, ou par ligne de commande pour les interpréteurs comme node et python, et garde le Mac éveillé tant qu'ils travaillent réellement. cargo, xcodebuild, swift, swiftc, npm, node, pnpm, yarn, make, cmake, ninja, gradle, mvn et dotnet figurent déjà dans la liste de surveillance par défaut, rien à ajouter pour une chaîne d'outils standard. Un processus ne compte comme actif que si son CPU dépasse un seuil (5 % par défaut, ajustable), donc un Terminal inactif ne maintient pas le Mac éveillé, alors qu'un compilateur qui sature un cœur, si. Un délai de grâce, 60 secondes par défaut et ajustable de 10 à 600, maintient l'assertion active après le dernier échantillon actif, pour qu'une brève accalmie entre deux phases de build ne fasse pas tomber le verrou.

La seconde est explicite : enveloppez le build avec lidrun -- <votre commande de build> et LidRun maintient une assertion anti-veille exactement pendant la durée de vie de cette commande, puis la relâche à l'instant où la commande se termine. Le code de sortie de la commande devient celui de lidrun, donc $? (ou un if lidrun -- npm run build; then … dans un script) vous indique si le build a réussi. LidRun n'affiche pas de durée par lui-même, donc passez-le par time si vous voulez ça : time lidrun -- cargo build --release.

Auto Mode est préférable quand les builds vont et viennent toute la journée sur différents projets ; le wrapper est préférable quand vous avez une seule commande longue et précise à surveiller, ou un script de type CI. Les deux sont des fonctionnalités Pro, pas incluses dans le niveau gratuit ; la simple bascule Keep Awake (démarrage et arrêt manuels, gratuite pour toujours) applique déjà le même contrôleur de sécurité batterie et thermique décrit plus bas, elle ne détecte simplement pas le build à votre place.

Le contrôleur de sécurité s'applique quand même

Garder un Mac éveillé pour un long build, c'est la partie facile. Le faire sans cuire discrètement la batterie ou le châssis, c'est la partie qui mérite d'être bien faite, et c'est pourquoi LidRun ne se contente pas de désactiver la veille et de vous laisser seul, quel que soit celui des deux modes ci-dessus que vous utilisez.

Batterie : un seuil d'arrêt automatique, 20 % par défaut et ajustable de 15 % à 50 %, coupe le maintien dès que la charge tombe en dessous ; le Mac est alors libre de dormir normalement plutôt que de continuer à se vider. Thermique : LidRun suit la pression thermique à partir des propres signaux du SoC, pas seulement la mesure grossière au niveau du système, et sur une lecture critique, le Safety Governor relâche immédiatement le maintien d'éveil ; si vous avez aussi activé « dormir en cas de surchauffe », il peut aller jusqu'à réellement endormir le Mac plutôt que de simplement relâcher le verrou. Cela aide à réduire le risque, cela ne rend pas la surchauffe impossible : l'aération et l'endroit où vous posez le portable restent votre responsabilité.

Chacune de ces décisions est consignée dans l'Activity Log avec une raison : une entrée d'arrêt automatique batterie indique le pourcentage auquel elle s'est déclenchée, une entrée thermique signale que le Safety Governor a reculé — donc si un long build a été écourté, vous pouvez voir pourquoi au lieu de deviner. Ce journal est la contrepartie honnête de ne pas être un simple verrou d'éveil aveugle.

La mettre en place pour les builds du quotidien

Auto Mode : cliquez sur l'icône LidRun dans la barre de menu et activez Auto Mode. Pour une chaîne d'outils Xcode, npm ou cargo classique, il n'y a rien à configurer, les outils figurent déjà dans la liste de surveillance par défaut. Des sous-outils Apple plus larges comme clang et swift-frontend tournent pendant beaucoup de choses sans rapport, donc ils restent désactivés par défaut, sous forme de puces à activer volontairement plutôt que surveillées automatiquement ; ne les activez que si vous voulez précisément que LidRun réagisse à eux.

Wrapper CLI : installez la commande lidrun une fois depuis le menu (elle écrit un petit script wrapper dans /usr/local/bin/lidrun), puis faites passer votre build par elle : lidrun -- cargo build --release, lidrun -- xcodebuild -scheme MyApp build, lidrun -- npm run build. Pour une commande chaînée, mettez le tout entre guillemets comme un seul argument, lidrun -- 'npm ci && npm run build', sinon le shell découpe sur && avant même que lidrun ne le voie, et seule la première moitié est protégée. Attendez-vous à peu près à la même petite traîne dans les deux cas : Auto Mode revérifie les processus en cours toutes les 10 secondes et maintient le verrou pendant le délai de grâce par défaut de 60 secondes, donc le Mac peut rester éveillé moins d'une minute après que le build est réellement terminé. C'est un comportement attendu, pas un bug.

Si un build a été interrompu, ouvrez d'abord l'Activity Log plutôt que de relancer à l'aveugle : l'entrée indique s'il s'agissait d'un plancher batterie ou d'un repli thermique, et vous pouvez relever le seuil de batterie ou améliorer l'aération en conséquence. Le mode Timer (préréglages fixes de 30 minutes à 8 heures) est un outil différent pour un usage différent, utile quand vous savez exactement combien de temps quelque chose doit tourner ; pour un build dont vous ne connaissez pas la durée à l'avance, Auto Mode ou le wrapper conviennent mieux, car ils s'arrêtent quand le travail s'arrête, pas sur une horloge qu'il fallait deviner juste.

Deux habitudes qui comptent quel que soit le mode : lancez les tâches les plus lourdes, un clean build complet, une grosse passe LTO, sur une surface dure et plane avec de l'air qui circule en dessous, et restez sur secteur si possible, car un portable sur batterie doit toujours respecter le plancher d'arrêt automatique, alors que l'alimentation secteur élimine complètement la question. Si vos builds tournent dans des conteneurs, le même problème de veille par inactivité s'y applique aussi ; le cas des builds Docker est traité séparément, car le processus que LidRun doit surveiller est différent.