tmux Mac distant : arrêt après déconnexion ? Guide 2026

Un serveur tmux reste distinct de son client SSH : c’est la séparation documentée par le projet tmux entre la session persistante et la connexion qui l’affiche (documentation officielle de démarrage). La conséquence pratique est immédiate : une coupure SSH n’arrête généralement pas une tâche lancée dans tmux, mais tmux ne protège ni contre la veille de macOS, ni contre un redémarrage, ni contre un plantage du processus.

Calendrier de décision

• Après une coupure SSH : reconnectez-vous avec le même compte, listez les sessions et vérifiez le processus avant toute relance.
• Après une mise en veille : contrôlez l’état d’alimentation du Mac ; ne concluez pas que tmux garantit l’exécution.
• Après un redémarrage : cherchez les journaux et le mécanisme de relance ; une session tmux ordinaire ne revient pas automatiquement.
• Cette semaine : exécutez un test contrôlé de déconnexion, d’inactivité et de redémarrage sur une tâche non critique, puis choisissez entre tmux, un service macOS et un ordonnanceur CI.

Cette procédure s’adresse aux développeurs qui compilent, testent, traitent des données ou exécutent un agent d’IA sur un Mac distant via SSH. Elle concerne aussi les ingénieurs DevOps qui doivent distinguer une simple conservation de terminal d’un service véritablement autonome, ainsi que les responsables de plateforme qui valident la reprise après incident.

La séparation entre SSH, shell et tmux

Une session SSH fournit une connexion distante. Le shell reçoit vos commandes. Le client tmux affiche une session existante, tandis que le serveur tmux conserve les fenêtres, les panes et les processus associés. Le travail réel, lui, est exécuté par un processus enfant : compilateur, script, outil de test ou agent d’IA.

Cette distinction explique une erreur fréquente. Après une coupure, l’écran du terminal local disparaît, mais cela ne prouve pas que le processus distant a disparu. À l’inverse, le fait de retrouver un nom de session ne prouve pas que la compilation est encore active : elle peut avoir échoué, attendu une saisie ou terminé sans conserver de sortie exploitable.

Le modèle officiel de tmux sépare donc la création du serveur, l’attachement du client et le détachement de la session (manuel tmux). Vous devez examiner ces éléments séparément au lieu de traiter « terminal vide » comme un diagnostic.

Commencez par préserver les preuves :

tmux ls
ps -axo pid,ppid,state,etime,command | grep -E 'xcodebuild|swift|node|python|go'
pwd

Adaptez les noms de processus à votre tâche. Si tmux ls retourne une session, ne la supprimez pas et ne tuez pas immédiatement les processus. Rattachez-vous d’abord à la session supposée correcte :

tmux attach-session -t build-ios

Inspectez ensuite le répertoire, la commande en cours et la dernière sortie. Si la tâche a terminé, recherchez son code de retour dans le journal ou dans le mécanisme de suivi de votre projet. Relancer sans cette vérification peut produire deux compilations concurrentes, écraser un artefact ou doubler un traitement de données.

Création et récupération d’une session nommée

Le scénario le plus fiable commence par une session explicitement nommée, créée avec le même compte qui exécutera la tâche :

tmux new-session -s build-ios

Lancez ensuite la commande dans cette session, plutôt que dans le shell SSH parent. Pour conserver une trace indépendante de l’affichage, redirigez la sortie vers un fichier du projet :

mkdir -p "$HOME/logs"
xcodebuild -workspace "$HOME/projets/Exemple/Exemple.xcworkspace" \
  -scheme Exemple \
  > "$HOME/logs/build-ios.log" 2>&1

Les chemins restent des exemples : remplacez-les par votre répertoire réel et ne copiez pas un chemin appartenant à un autre compte. Cette précaution est importante sur un Mac partagé ou loué, car le répertoire personnel, les droits d’accès, les certificats et les agents SSH ne sont pas interchangeables.

Détachez proprement la session sans arrêter la tâche :

Ctrl-b puis d

Vous pouvez aussi demander à tmux de détacher le client depuis une autre connexion :

tmux detach-client

Lors de la reconnexion, utilisez le cycle minimal suivant :

tmux ls
tmux attach-session -t build-ios
tail -n 80 "$HOME/logs/build-ios.log"

La session doit être confirmée par son nom, mais aussi par son contenu. Vérifiez que le PID observé avant la coupure correspond toujours à une tâche cohérente, que pwd pointe vers le bon projet et que le journal avance. Si le compte SSH est différent, vous pourrez ne voir aucune session, même si le serveur tmux de l’autre utilisateur fonctionne encore.

Un nom de session stable réduit également le risque de rejoindre le mauvais environnement. Évitez les sessions anonymes lorsque plusieurs compilations ou traitements sont exécutés en parallèle. Ne supprimez pas le socket tmux pour « repartir proprement » avant d’avoir sauvegardé les journaux : cette action peut rendre la récupération plus difficile.

Environnement de reconnexion et variables perdues

Retrouver une session ne signifie pas retrouver exactement le contexte d’une nouvelle connexion. Un pane déjà ouvert conserve son processus et son environnement initial ; un nouveau pane peut recevoir un environnement différent. Le chemin vers Homebrew, la valeur de PATH, les variables de projet et l’agent SSH doivent donc être vérifiés séparément.

La FAQ officielle de tmux décrit les limites de la mise à jour de l’environnement entre le serveur, les clients et les nouvelles fenêtres (FAQ tmux sur l’environnement). Ne concluez pas qu’une tâche est perdue simplement parce qu’une commande n’est plus trouvée dans un nouveau pane.

Contrôlez le contexte avec des commandes explicites :

id -un
printf '%s\n' "$HOME"
printf '%s\n' "$PATH"
command -v git
command -v brew
ssh-add -l

Si brew est absent, examinez le chemin installé sur votre nœud plutôt que d’ajouter une valeur copiée depuis une autre machine. Si ssh-add -l signale qu’aucune identité n’est disponible, le problème concerne l’agent et ses permissions, non la persistance de tmux. Une tâche déjà lancée peut continuer avec son environnement initial tout en échouant lorsqu’elle tente ensuite d’accéder à un dépôt privé ou à un service externe.

Avant le lancement, enregistrez dans le journal le répertoire, la version de l’outil et les variables non secrètes nécessaires au diagnostic. Ne versez jamais de jeton, de clé privée ou de mot de passe dans un fichier de sortie. Pour un nœud destiné à la compilation, la méthode d’accès SSH à un Mac distant doit être validée avec le compte, les droits et le mode d’authentification réellement utilisés.

Attention : tuer le processus, supprimer le socket tmux, modifier les réglages d’alimentation ou redémarrer le Mac sont des opérations différentes. Avant chacune, notez le PID, copiez le journal et écrivez la méthode de retour. Une action irréversible ne constitue pas un diagnostic.

Sommeil de macOS et disponibilité du nœud

tmux ne maintient pas le Mac éveillé. Il protège une session contre la fermeture du client, pas contre la politique d’alimentation du système. La documentation Apple distingue les réglages de sommeil, l’extinction de l’écran et les options de réveil (réglages de veille et de réveil de macOS).

Cette différence compte pour une compilation Xcode, un rendu vidéo, un traitement audio ou un agent d’IA qui attend une réponse réseau. Un écran éteint peut être compatible avec une tâche encore active ; la mise en veille complète peut, selon la configuration et le nœud, rendre le service inaccessible ou suspendre l’exécution. Le réveil réseau ne signifie pas non plus que chaque processus reprendra exactement là où il s’est arrêté.

Procédez sans modifier immédiatement la politique globale :

• vérifiez si l’ordinateur ou seulement l’écran passe en veille ;
• contrôlez la disponibilité SSH avant et après la période d’inactivité ;
• observez le journal de la tâche, plutôt que la seule présence de la session tmux ;
• testez une mesure temporaire sur une tâche non critique ;
• documentez ensuite le réglage permanent accepté par votre organisation.

Sur un Mac distant fourni pour une durée limitée, demandez aussi quelle est la politique d’alimentation du nœud. Une solution peut convenir à une session interactive de développement sans convenir à un traitement nocturne. Les nœuds Mac distants disponibles pour vos tests doivent être évalués sur la disponibilité réellement nécessaire, et non sur la seule possibilité d’ouvrir une connexion SSH.

Redémarrage, arrêt du serveur et récupération

Une session détachée dépend toujours du serveur tmux et du système qui l’exécute. Si macOS redémarre, le serveur tmux disparaît avec les processus ordinaires qu’il gérait. Vous ne devez donc pas promettre une restauration automatique en vous fondant uniquement sur tmux attach-session.

Pour une tâche ponctuelle, préparez une reprise sûre :

• écrivez la commande complète dans un script versionné ;
• stockez les journaux dans un emplacement connu ;
• rendez les sorties identifiables par projet et par date ;
• vérifiez si l’opération peut être relancée sans doublon ;
• contrôlez le dépôt, les artefacts partiels et l’état des données avant reprise.

Pour un script qui doit démarrer sans connexion interactive, redémarrer après un échec et fonctionner après un redémarrage du Mac, utilisez un mécanisme de service. Apple documente la création de tâches lancées par launchd dans son guide de programmation système (guide Apple consacré aux tâches launchd). Les mécanismes actuels de gestion des services sont également décrits dans la documentation Apple Service Management.

Le choix est alors fonctionnel :

• tmux convient à une tâche interactive, observable et relancée manuellement ;
• launchd convient à un service local qui doit démarrer selon une politique système ;
• un ordonnanceur CI convient à une compilation ou à une suite de tests déclenchée par un événement, avec journaux, statut et politique d’échec.

N’utilisez pas une session tmux comme substitut silencieux à un système de supervision. Elle ne fournit pas, à elle seule, une politique de verrouillage, de reprise, de notification ou de rotation des journaux.

Test de reprise et critères d’acceptation

Un test utile ne consiste pas seulement à fermer la fenêtre SSH. Vous devez vérifier les différents points de rupture dans un ordre qui limite les risques. Employez une tâche réversible : compilation d’un projet de test, génération d’un artefact temporaire ou traitement sur des données copiées.

• [ ] Créer une session nommée avec le compte de service prévu.
• [ ] Enregistrer le PID, le répertoire courant, la commande et le fichier journal.
• [ ] Détacher volontairement le client tmux et confirmer que le processus continue.
• [ ] Couper la connexion SSH sans supprimer la session ni le socket.
• [ ] Reconnecter le même compte, lister les sessions et rattacher la bonne cible.
• [ ] Comparer le PID, le répertoire et les dernières lignes du journal.
• [ ] Créer un nouveau pane et vérifier séparément PATH, Homebrew et l’agent SSH.
• [ ] Laisser le Mac atteindre son état d’inactivité habituel, puis contrôler la connexion et le journal.
• [ ] Effectuer un redémarrage contrôlé uniquement après avoir sauvegardé les preuves.
• [ ] Vérifier si le service ou le CI relance la tâche ; sinon, appliquer la procédure documentée de reprise.

Classez ensuite la charge selon le résultat. Si seule la coupure SSH est tolérée et qu’une surveillance humaine reste possible, tmux est adapté. Si la veille ou le redémarrage interrompent le traitement, modifiez la politique du nœud ou déplacez la charge vers un service. Si le travail doit être déclenché, suivi et rejoué automatiquement, un ordonnanceur CI est plus approprié.

Le critère d’acceptation n’est pas « la session existe ». Il est plutôt : « après l’incident testé, vous pouvez identifier l’état de la tâche, retrouver son journal et reprendre sans duplication ni perte non expliquée ».

Questions fréquentes

Déconnexion SSH

Une tâche lancée dans tmux continue généralement après une coupure SSH, car le serveur tmux n’est pas le client qui vient de disparaître. Reconnectez-vous avec le même compte, exécutez tmux ls, puis vérifiez le processus et le journal. Une session présente peut néanmoins contenir une tâche déjà terminée ou échouée.

Redémarrage du Mac distant

Une session tmux ordinaire ne constitue pas une sauvegarde après redémarrage. Le serveur tmux et ses processus sont arrêtés avec le système. La récupération doit donc s’appuyer sur des journaux persistants, un script relançable et, pour un besoin permanent, un service launchd ou un système CI configuré pour reprendre explicitement.

Sommeil de macOS

Le sommeil concerne l’état du système, pas seulement l’affichage du terminal. tmux ne l’empêche pas. Vérifiez les réglages Apple, observez si SSH reste accessible et comparez les journaux avant de modifier la politique d’alimentation. Une session détachée peut survivre à une coupure réseau tout en restant inutilisable pendant une mise en veille complète.

Journaux de compilation

Rattachez-vous à la session avec tmux attach-session -t nom-session, puis utilisez pwd, ps et tail sur le fichier journal. Pour éviter de dépendre du défilement du pane, redirigez dès le départ la sortie vers un fichier situé dans le projet. Cette trace permet de distinguer une tâche active d’une compilation terminée sans affichage.

Tâche permanente

tmux est un outil d’interaction et de conservation de session, pas un superviseur complet. Pour un script permanent, définissez le comportement attendu après échec, redémarrage et absence de connexion. Utilisez launchd ou un ordonnanceur CI lorsque l’exécution doit démarrer automatiquement, produire un statut exploitable et suivre une procédure de reprise connue.

Choix du support pour votre prochain long traitement

Pour un travail ponctuel, tmux reste le moyen le plus simple de garder une console de compilation, de test ou de traitement accessible après une rupture SSH. Pour une charge de production, vous devez cependant tester le sommeil, le redémarrage, les variables d’environnement et la récupération des journaux avant de lui confier une exécution sans surveillance.

Un Mac local évite la dépendance à une connexion distante, mais il immobilise du matériel, dépend de votre alimentation et n’est pas toujours disponible pour une équipe répartie. Une machine virtuelle ou un serveur Linux peut être plus simple à automatiser, mais ne remplace pas un environnement macOS réel pour Xcode, certains outils audio et vidéo ou les chaînes de signature Apple. Un Mac distant loué ajoute une dépendance au réseau et au fournisseur, mais offre une machine accessible sans achat initial, avec une durée d’usage ajustable.

Si votre solution actuelle repose sur un poste personnel laissé allumé, elle cumule souvent trois faiblesses : accès limité lorsque le poste est éteint, reprise manuelle après un redémarrage et environnement difficile à partager avec d’autres ingénieurs. Si vous utilisez une machine virtuelle non native, vous ajoutez les limites de compatibilité et de performance propres à cette couche. Dans ces cas, louer un Mac auprès de VPSMAC peut fournir un environnement distant plus cohérent pour vos essais de longue durée, à condition de valider le mode de connexion, les journaux et la politique de disponibilité avant de déplacer une charge importante.

Commencez par un test réel et réversible : déconnexion SSH, période d’inactivité, puis redémarrage contrôlé. Si le résultat attendu est une console interactive, gardez tmux. Si vous avez besoin d’un démarrage automatique et d’une reprise vérifiable, passez à launchd ou au CI, puis choisissez un Mac distant adapté à votre cycle de test chez VPSMAC en fonction de la durée et du niveau de disponibilité recherchés.