La compilation Xcode s’arrête-t-elle après une coupure SSH ? Guide Mac distant 2026

La connexion SSH vient de tomber pendant une compilation Xcode, et le terminal ne répond plus.

Adapté si la compilation doit survivre à la fermeture du terminal : lancez-la dans une session tmux sur le Mac distant, puis vérifiez le processus et les résultats après reconnexion. Inadapté comme garantie de reprise : tmux ne relance pas une tâche interrompue par un redémarrage, un arrêt du processus ou une panne système.

Cette situation concerne les personnes qui lancent des compilations à distance depuis une connexion instable, les équipes CI qui déboguent une tâche à la main et les responsables d’un Mac distant qui doivent distinguer coupure de session, fin du processus et indisponibilité de l’hôte. Le point important n’est pas seulement de récupérer le terminal : il faut établir ce qui s’est réellement passé sur la machine.

Trois états à vérifier avant de conclure

Une compilation Xcode lancée avec xcodebuild est un processus exécuté sur le Mac distant. La session SSH est le canal qui permet d’interagir avec ce Mac ; elle n’est pas, à elle seule, un relevé fiable de l’état de la compilation. Apple documente xcodebuild comme outil en ligne de commande pour construire, tester et effectuer d’autres opérations sur des projets Xcode (référence des outils Xcode en ligne de commande). Cette documentation décrit l’outil, mais ne permet pas de déduire ce qu’a fait un processus particulier après une coupure.

Il faut donc séparer trois vérifications. La connexion indique si le Mac est joignable. Le processus indique si la commande de compilation est toujours active. Le résultat indique si la tâche a abouti, échoué ou s’est arrêtée sans résultat exploitable. Une session SSH qui se reconnecte ne prouve pas que la compilation est terminée ; un processus portant un nom lié à Xcode ne prouve pas que le projet a été construit correctement.

Une commande peut aussi se terminer entre la coupure et la reconnexion. Dans ce cas, la tâche n’est plus visible parmi les processus, mais son journal peut permettre de déterminer si elle a réussi. À l’inverse, un processus encore visible peut être bloqué, attendre une saisie ou échouer plus tard. La présence du processus n’est qu’un indice, pas un compte rendu final.

Après une coupure, contrôler le Mac et la commande

Commencez par ouvrir une nouvelle connexion SSH. Si le Mac répond, recherchez le processus de construction sans supposer que son absence signifie immédiatement une réussite ou un échec :

ssh utilisateur@adresse-du-mac
pgrep -alf 'xcodebuild|Xcode'

Remplacez les valeurs d’exemple par les paramètres réels de l’hôte. La recherche peut afficher des commandes sans rapport avec le projet, ou ne rien afficher si la compilation est terminée. Elle ne remplace donc ni la lecture du journal ni la vérification du résultat attendu.

Si le Mac est joignable, mais que le processus n’apparaît pas, cherchez d’abord le journal créé au lancement. Pour une commande démarrée dans un terminal ordinaire, le texte affiché avant la rupture peut n’avoir été conservé que dans le défilement local. Si cette fenêtre est fermée ou perdue, il peut être impossible de récupérer son contenu. Une trace écrite dans un fichier, au contraire, peut être relue après une reconnexion, sous réserve que le fichier soit accessible et que la machine n’ait pas perdu les données concernées.

La cause de la coupure compte également. Une fermeture volontaire du client, une perte réseau et l’envoi d’un signal d’arrêt au processus sont des événements différents. Il ne faut pas attribuer automatiquement à une coupure réseau le même effet qu’à l’arrêt explicite d’un terminal. Le comportement concret doit être vérifié sur l’hôte et dans le contexte du shell utilisé.

Si une commande est encore active, évitez de la relancer immédiatement : deux compilations simultanées peuvent écrire dans des emplacements communs, utiliser les mêmes ressources ou rendre le diagnostic plus difficile. Vérifiez d’abord que le processus appartient bien au projet attendu et qu’il progresse. Si son état reste ambigu, consignez ce qui est observable avant toute intervention.

Apple présente xcodebuild dans ses ressources consacrées à la construction depuis la ligne de commande (note technique sur la construction et les tests en ligne de commande). Pour les tests, les résultats doivent aussi être interprétés à partir des informations réellement produites par Xcode, et non du seul fait que la session a disparu (documentation Apple sur l’exécution des tests et l’interprétation des résultats).

Avec tmux, garder un terminal réattachable

Pour retrouver une session après une perte de connexion, tmux doit être installé et exécuté sur le Mac distant. Lancer tmux uniquement sur l’ordinateur local ne conserve pas la session du serveur. Le projet tmux décrit précisément les sessions détachables du terminal, puis réattachables depuis une autre connexion (guide officiel de prise en main de tmux). Les commandes ci-dessous illustrent ce flux ; adaptez le nom de session et les arguments de compilation au projet.

ssh utilisateur@adresse-du-mac
tmux new-session -s build-xcode

Une fois dans cette session, démarrez la compilation et laissez le terminal ouvert pendant le travail. Pour quitter le terminal sans fermer la session, utilisez la séquence de détachement documentée par tmux : Ctrl-b, puis d. Vous revenez alors au shell SSH ; la session tmux reste disponible sur le Mac tant que l’hôte et le processus concernés restent en fonctionnement. Le manuel de tmux décrit les commandes de création, de détachement et de rattachement (manuel officiel de tmux).

Après une coupure, reconnectez-vous d’abord au même Mac, puis demandez la liste des sessions :

tmux list-sessions

Si la session attendue existe, rattachez-vous à elle :

tmux attach-session -t build-xcode

Comment éviter de confondre la session locale et la session distante ? Ouvrez la connexion SSH avant de créer la session et vérifiez que l’invite correspond bien au Mac distant. Après une reconnexion, exécutez tmux list-sessions depuis ce même hôte. Si aucune session n’est trouvée, ne créez pas immédiatement une session portant le même nom en supposant que la compilation est terminée : contrôlez d’abord les processus et les fichiers de résultat.

Cette méthode est utile pour une commande lancée manuellement, notamment pendant un diagnostic ou une compilation longue. Elle n’est pas, à elle seule, un système de file d’attente, un ordonnanceur ou un mécanisme de reprise. Si la compilation se termine pendant que la session est détachée, tmux conserve le terminal et sa sortie tant que la session existe ; il ne transforme pas l’échec en réussite et ne garantit pas que toute la sortie soit enregistrée dans un fichier.

Contrôler la fin et conserver les preuves

Avant de lancer une tâche, choisissez où conserver le journal et où Xcode doit écrire les résultats, selon l’organisation du projet. Les chemins varient : il faut employer ceux qui conviennent à l’espace de travail, au schéma et aux règles de l’équipe, sans supposer qu’un emplacement universel existe.

Une façon de conserver la sortie du processus dans un fichier consiste à rediriger le flux du terminal :

set -o pipefail
xcodebuild -scheme "NomDuSchema" -destination "DestinationDuProjet" build 2>&1 | tee "build.log"

Remplacez les éléments entre guillemets par les paramètres du projet. Dans les shells compatibles, pipefail permet de ne pas masquer l’échec de la commande située avant tee par la réussite de l’écriture du journal. À la fin de la commande, relevez immédiatement le statut de sortie du shell :

echo $?

Cette valeur décrit l’issue rapportée par la commande terminée ; elle ne doit pas être relevée plus tard après d’autres commandes, qui peuvent modifier le statut courant du shell. En cas de reconnexion à une session tmux encore active, revenez au terminal de compilation et observez sa fin. Si la commande est déjà terminée, recherchez plutôt le statut consigné, les messages d’erreur et les résultats enregistrés.

Pour les tests, Xcode propose également des résultats consultables et des options de compte rendu en ligne de commande. La documentation Apple explique comment organiser les tests pour améliorer les retours et les invoquer depuis la ligne de commande (guide Apple sur l’organisation des tests et leur utilisation en ligne de commande). L’installation des outils de ligne de commande peut dépendre de l’état de la machine et des outils déjà présents ; Apple décrit la procédure dans son guide d’installation (documentation Apple sur l’installation des outils de ligne de commande).

À la reprise, vérifiez plusieurs éléments, pas un seul :

• La commande est-elle toujours active ? Confirmez qu’il s’agit bien du processus lié au projet et à la compilation en question.
• Le journal est-il complet ? Consultez sa fin et recherchez les erreurs pertinentes. Une sortie tronquée ne permet pas de certifier le résultat.
• Quel est le statut de sortie ? Relevez celui de xcodebuild au moment où la commande s’achève, en tenant compte de la façon dont la sortie a été redirigée.
• Les résultats attendus existent-ils ? Vérifiez les fichiers ou comptes rendus prévus par le projet. Leur présence seule ne prouve pas qu’ils correspondent à la tentative la plus récente.
• Les tests ont-ils abouti ? Examinez les résultats de test et les erreurs, plutôt que de déduire la réussite du seul achèvement de la compilation.

Comment savoir si la compilation a réussi pendant la coupure ? Rattachez-vous à la session si elle existe. Sinon, combinez le journal conservé, le statut de sortie enregistré et les résultats attendus. Si ces éléments ne permettent pas de distinguer une réussite d’un arrêt incomplet, considérez le résultat comme non vérifié et relancez la tâche après avoir contrôlé l’état du Mac.

Limites de récupération après arrêt ou incident

tmux gère la relation entre un terminal et une session de travail. Il ne promet pas la survie d’un processus à un redémarrage, à une panne système, à l’arrêt du processus ou à la perte des fichiers nécessaires. Un redémarrage peut mettre fin à la session ; un processus tué ne reprend pas automatiquement au point où il s’est arrêté. De même, tmux n’assure ni la reprise d’une compilation à un point de contrôle ni son redémarrage automatique après le retour de l’hôte.

Si le Mac ne répond plus, commencez par vérifier que l’hôte est de nouveau accessible et que les données utiles ont été préservées. Examinez ensuite les journaux système disponibles, les sessions tmux, les processus et les résultats du projet. La procédure de récupération dépend de la cause et de la configuration réelle : ne créez pas un mécanisme automatique sans l’avoir testé sur le Mac concerné et sans savoir comment il traite les compilations déjà en cours.

Quelle décision prendre avant de relancer ? Appliquez ces conditions :

• Si le Mac est accessible, que la session existe et que la commande est encore active, alors rattachez-vous et surveillez-la au lieu de lancer une seconde compilation.
• Si la commande a fini et que statut, journal et résultats concordent, alors archivez les éléments nécessaires et consignez le résultat.
• Si le processus a disparu, mais que les traces ne permettent pas de confirmer l’issue, alors traitez la tâche comme non vérifiée et préparez une nouvelle exécution après contrôle de l’espace disque et de l’environnement.
• Si l’hôte a redémarré ou reste indisponible, alors rétablissez d’abord l’accès et examinez les traces disponibles ; ne comptez pas sur une reprise automatique par tmux.

Pour une équipe CI, ces contrôles sont aussi une occasion de distinguer le lancement manuel d’une véritable chaîne de construction. Un processus relançable doit conserver son journal et ses résultats dans des emplacements connus, et son état doit pouvoir être vérifié indépendamment de la fenêtre SSH. Un flux Xcode automatisé doit en outre définir comment il rapporte les échecs et comment il évite les doublons. tmux peut faciliter une intervention humaine, mais ne remplace pas ces règles d’exploitation.

Choisir l’environnement selon la durée des tâches

Pour des essais ponctuels, un Mac local peut rester plus simple, surtout si les tâches nécessitent des périphériques physiques ou une interaction directe. Pour des compilations à lancer à distance, un Mac dédié ou un environnement Mac distant évite de dépendre de la disponibilité du poste de travail ; il faut toutefois vérifier l’accès, la conservation des résultats et les règles de maintenance avant d’y placer des tâches longues.

Avant de retenir un environnement distant, vérifiez que la version de Xcode et les outils requis sont disponibles, que le projet peut être récupéré de façon fiable et que les journaux restent accessibles après déconnexion. Les développeurs peuvent aussi consulter les informations sur la connexion à un Mac distant pour évaluer les modalités d’accès, puis examiner les scénarios d’usage du Mac distant selon leur flux de développement. Ces vérifications sont particulièrement utiles lorsque la compilation n’est pas le seul travail concerné : les tests, les tâches de conception ou les traitements audio et vidéo peuvent imposer d’autres exigences de stockage, d’interaction ou de transfert.

Un poste déjà disponible peut être préférable si les compilations sont fréquentes, lourdes et réalisées dans un environnement stable que l’équipe maîtrise. À l’inverse, acheter une machine pour un besoin temporaire immobilise un budget et ajoute des tâches de mise en place et de maintenance. Un Mac distant ne supprime pas les contraintes : la connexion peut ralentir les échanges, l’accès aux périphériques physiques peut être limité et les résultats doivent être conservés selon le processus du projet.

Pour un besoin temporaire de construction ou de test, la location d’un Mac peut donc être plus commode que l’achat d’un appareil, à condition de valider au préalable le flux SSH, l’installation de Xcode, les journaux et les résultats. Les informations sur les offres Mac de HopVM permettent d’évaluer cette option sans confondre location et garantie de reprise des tâches : même sur un Mac distant, une session tmux protège contre la perte du terminal, pas contre l’arrêt de l’hôte ou du processus.

La règle opérationnelle reste simple : une coupure SSH ne donne pas le verdict. Utilisez tmux pour retrouver une session détachée, puis fondez la décision sur l’état réel du processus, le statut de sortie, les journaux et les résultats du projet.