Après une coupure SSH, une commande lancée au premier plan ne peut pas être considérée comme protégée : pour un script de recherche en ligne de commande, lancez-le dans une session tmux sur le Mac distant, puis vérifiez la reconnexion et les fichiers produits avant de déclarer le calcul réussi. Cette méthode protège contre la perte du terminal côté client, pas contre un redémarrage de l’hôte, l’arrêt de tmux ni le plantage du programme.

Cet article s’adresse aux chercheurs qui exécutent des scripts, des compilations ou des analyses en ligne de commande sur un Mac distant. Il aide aussi les personnels techniques de laboratoire à vérifier la reprise d’une session et l’intégrité des résultats avant de remettre un environnement à disposition.
Une application graphique ou un calcul qui doit survivre à une panne de l’hôte demande, en revanche, des mesures supplémentaires.

Déconnexion SSH sur Mac distant : distinguer les états

Une coupure de connexion et un arrêt de calcul sont deux événements différents. SSH relie le terminal local à un shell sur l’hôte distant ; si cette liaison disparaît, le terminal local ne permet plus d’observer directement ce qui se passe sur le Mac. La documentation de l’ouverture de session à distance sur macOS décrit l’accès SSH comme un moyen de se connecter à un Mac, mais cette fonction ne transforme pas une commande ordinaire en tâche récupérable.

Il faut donc distinguer trois états :

  • La connexion SSH est perdue. Le client n’échange plus avec le shell distant. Cela ne prouve pas, à lui seul, que le programme a terminé ou qu’il fonctionne encore.
  • Le contexte de terminal a disparu. Une commande démarrée au premier plan dans le shell peut dépendre de ce contexte. Son sort après la fermeture du terminal ne doit pas être deviné : il faut le vérifier.
  • Le processus distant s’est arrêté. Le programme peut avoir terminé, échoué ou été interrompu. Même si SSH fonctionne à nouveau, une nouvelle connexion ouvre un nouveau shell ; elle ne restaure pas l’ancien.

En pratique, une reconnexion réussie confirme uniquement que l’accès distant fonctionne de nouveau. Elle ne confirme ni la présence du processus, ni la fin correcte du calcul, ni l’écriture complète de ses résultats. Un nom de fichier créé n’est pas davantage une preuve suffisante : le programme a pu s’interrompre pendant son écriture.

Une commande au premier plan ne doit donc pas être relancée automatiquement après une coupure. Avant cela, recherchez des traces du calcul initial et vérifiez les chemins de sortie : une deuxième exécution peut écraser un journal, remplacer un fichier ou consommer inutilement des ressources. Pour comprendre ce que couvre la connexion SSH, consultez aussi la documentation de référence SSH ; elle décrit le protocole et ses options, mais ne promet pas la continuité des tâches d’un laboratoire.

Commande arrêtée ou toujours active : recueillir des indices

La première question est de savoir si le calcul avait été lancé directement dans le terminal SSH ou dans un outil conçu pour préserver une session distante. Sans tmux ou dispositif équivalent, le résultat dépend de la façon dont le shell et le programme réagissent à la perte de leur terminal. La documentation de nohup, par exemple, explique comment un processus peut ignorer le signal de déconnexion dans son contexte d’utilisation ; cela ne constitue pas une sauvegarde du calcul ni une solution universelle sur macOS. Vérifiez les options réellement disponibles dans l’environnement avant de vous y fier, au lieu de transposer une commande prévue pour un autre système.

À la reconnexion, procédez dans cet ordre, sans supprimer de processus ni relancer le script :

  1. Confirmez l’hôte et le compte. Un nom d’utilisateur différent, une autre machine ou un répertoire de travail différent peut faire croire que la session ou les fichiers ont disparu.
  2. Recherchez le processus. Sur macOS, une commande telle que ps -axo pid,etime,command affiche les processus ; examinez la sortie et repérez le programme concerné. Une correspondance de nom seule ne suffit pas toujours à identifier le lancement initial.
  3. Lisez le journal existant. Si la sortie était redirigée vers un fichier, consultez sa fin avec tail -n 40 analyse.log. Cherchez une erreur, un message de fin ou une progression encore active. Le journal aide au diagnostic, mais son silence ne prouve pas que le processus est mort.
  4. Contrôlez les fichiers attendus. Vérifiez les noms, la taille et les dates affichés par ls -lh. Comparez avec les sorties prévues par le script ou avec un manifeste établi avant l’exécution.
  5. Décidez seulement après ces vérifications. Si l’état reste incertain, conservez le journal et les fichiers observés, puis demandez conseil à la personne qui administre la machine. Ne relancez pas un calcul susceptible d’écraser ses propres preuves.

Ces contrôles donnent des indices, pas une garantie de validité scientifique. Un fichier de taille plausible peut être incomplet ou contenir des données mal formées ; le script peut aussi avoir échoué après avoir produit une partie des sorties. Lorsque c’est possible, utilisez les vérifications propres au logiciel d’analyse : nombre d’échantillons attendu, somme de contrôle, fichier de statut ou étape de validation finale.

Session tmux détachée : conserver un terminal récupérable

tmux permet de dissocier la session de terminal de la connexion SSH cliente. Selon sa documentation officielle de démarrage, les sessions peuvent être détachées puis rejointes de nouveau ; le serveur tmux et la session restent du côté du Mac distant. La coupure du client n’équivaut donc pas, à elle seule, à la fermeture de cette session.

Voici un parcours minimal pour lancer un script depuis une session nommée :

tmux new-session -s analyse
python3 analyse.py > analyse.log 2>&1

La première commande ouvre une session appelée analyse. La seconde exécute le script et redirige sa sortie standard et ses erreurs dans analyse.log. Adaptez le programme et le nom du journal à votre projet ; avant le lancement, vérifiez surtout le répertoire courant et l’emplacement où seront écrits les résultats. Le nom explicite facilite le repérage si plusieurs analyses sont en cours.

Quand le calcul est lancé, détachez la session avec le raccourci par défaut de tmux : appuyez sur Ctrl-b, relâchez, puis sur d. La session reste disponible sur l’hôte tant que le serveur tmux et le Mac restent actifs. Le manuel officiel de tmux documente les commandes de création, de détachement et de rattachement ; il est préférable de s’y reporter si votre configuration a modifié les raccourcis.

Après une nouvelle connexion SSH au même Mac et avec le même compte, vérifiez puis rattachez la session :

tmux list-sessions
tmux attach-session -t analyse

Si le terminal indique que la session est encore attachée ailleurs, examinez la situation avant de la reprendre de force : un collègue ou une autre fenêtre peut être en train de l’utiliser. Une fois rattaché, contrôlez la sortie et l’avancement du script. tmux rend le terminal consultable après une déconnexion ; il ne certifie pas que le programme a réussi et ne conserve pas magiquement son résultat.

Pour enregistrer également un état de fin, exécutez le programme dans un shell de session qui écrit son code de sortie après le calcul :

python3 analyse.py > analyse.log 2>&1
status=$?
printf '%s\n' "$status" > analyse.exit

Lisez analyse.exit seulement lorsque le shell a atteint cette dernière commande. Une valeur d’état est utile pour distinguer une fin signalée comme normale d’un échec, mais elle ne remplace pas la validation des résultats attendus. Si le terminal a été fermé avant l’écriture de ce fichier, son absence ne permet pas de conclure seule : revenez aux journaux, aux processus et aux fichiers de sortie.

Session introuvable ou résultat incomplet : suivre les preuves

Si tmux list-sessions ne montre pas la session attendue, évitez de conclure immédiatement à la perte du calcul. Vérifiez d’abord que vous êtes connecté au bon hôte et sous le compte qui l’a créée. Les sessions tmux sont liées à l’utilisateur et à l’instance de serveur concernée : changer de compte ou de machine peut rendre la liste différente, même si le processus ou ses sorties existent ailleurs.

Si l’hôte et le compte sont corrects, passez aux journaux et au processus. Une session absente peut indiquer que le serveur tmux s’est arrêté, que la session a été fermée ou que l’environnement a redémarré. Recherchez les traces disponibles sans nettoyer l’espace de travail ; examinez aussi les fichiers temporaires, les journaux applicatifs et les éventuels messages d’arrêt que l’équipe technique peut consulter. La foire aux questions officielle de tmux apporte des précisions sur le fonctionnement des sessions et du serveur, mais ne peut pas révéler les règles d’administration propres à un hôte donné.

Un résultat incomplet demande une vérification indépendante du statut du processus. S’il fonctionne encore, laissez-le progresser et observez les journaux. S’il a disparu, cherchez une trace de fin ou d’erreur et comparez les fichiers aux critères du projet. Si aucune preuve ne permet de déterminer ce qui s’est passé, archivez les éléments disponibles et demandez une vérification avant de relancer. Une relance n’est sûre que si les sorties sont protégées contre l’écrasement et si l’analyse peut être répétée sans créer de doublons ambigus.

Pour les calculs importants, préparez en amont un répertoire propre par exécution, un journal distinct, une liste des fichiers attendus et une méthode de validation. Si le programme permet de reprendre à partir d’un point de contrôle, testez cette reprise avant de dépendre d’elle. Un journal de progression réduit l’incertitude ; un mécanisme de reprise prévu par l’application réduit davantage le coût d’une interruption, mais aucun des deux ne doit être supposé disponible sans vérification.

Décision d’usage : terminal, reprise et application graphique

Avant de lancer un calcul, cochez les affirmations qui correspondent à votre situation. La première décision porte sur le type de tâche et la protection réellement nécessaire, pas sur le seul fait que la connexion SSH fonctionne.

  • [ ] Le travail est entièrement piloté en ligne de commande et le Mac reste disponible. Créez une session nommée tmux, consignez la sortie dans un journal et testez le détachement puis le rattachement. Si ces conditions sont réunies, choisissez tmux pour protéger la session contre une coupure du client.
  • [ ] Le travail est en ligne de commande, mais tmux n’est pas installé, accessible ou testé. Ne comptez pas sur une commande au premier plan. Demandez quelle méthode est prise en charge sur cet hôte ou réalisez d’abord un essai sans données précieuses ; nohup ou une commande avec & ne doivent pas être considérés automatiquement comme équivalents à une session récupérable.
  • [ ] Le calcul dépend d’une application graphique ou d’interactions continues avec le bureau. N’utilisez pas tmux comme garantie de maintien de l’application. Activez les fonctions d’enregistrement automatique ou de reprise propres au logiciel et validez séparément le comportement après fermeture de session.
  • [ ] Le calcul doit survivre à un redémarrage, à une maintenance ou à une panne du Mac. tmux seul ne répond pas à cette exigence. Ajoutez des points de contrôle, des copies de sécurité et une procédure de reprise compatible avec le programme, puis vérifiez les règles d’exploitation de l’hôte.
  • [ ] Les résultats sont difficiles à recalculer ou à reconstituer. Avant le lancement, définissez un journal distinct, un répertoire de sortie protégé contre l’écrasement et un contrôle d’intégrité des fichiers. Si ces éléments manquent, réduisez l’essai à une tâche réversible et ne confiez pas encore les données critiques à cette procédure.

Si seule la première case s’applique, tmux est un choix adapté pour la perte de connexion côté client, à condition de vérifier ensuite le processus et les résultats. Si une autre case décrit une exigence essentielle, complétez la protection ou reportez le lancement jusqu’à ce que la méthode correspondante ait été testée.

Cette distinction est particulièrement importante pour les tâches créatives de recherche : une analyse audio ou vidéo peut s’exécuter en ligne de commande, tandis que le même projet ouvert dans une interface graphique dépend du bureau et de l’état interne de l’application. Le fait que les fichiers source soient présents ne garantit pas que l’interface ou le traitement en cours pourra être restauré. Pour la gestion de services et leur cycle de vie sur macOS, la documentation de Service Management peut aider à comprendre les mécanismes système, mais ne remplace pas les règles du Mac utilisé.

Une session tmux protège contre une coupure du client, pas contre un redémarrage de l’hôte, une maintenance, une suppression de processus, un manque de ressources ou une panne logicielle. Les règles de fonctionnement et de conservation des données dépendent de la machine et de son administration ; elles doivent être confirmées auprès de l’équipe responsable. Même avec tmux, un résultat important doit être enregistré dans un emplacement vérifiable et copié selon les règles du laboratoire.

Vérification de reprise : essai avant le calcul important

Avant de confier à un Mac distant un calcul long ou difficile à répéter, effectuez un essai représentatif sur des données sans valeur critique. Il ne s’agit pas de mesurer une performance, mais de vérifier que les étapes de reprise sont comprises et que le résultat peut être contrôlé.

  • Créez une session tmux nommée et confirmez que le nom apparaît dans la liste des sessions.
  • Lancez un petit travail observable, qui écrit une progression dans un journal et produit un fichier de sortie attendu.
  • Détachez la session, fermez la connexion SSH côté client, puis reconnectez-vous au même hôte et au même compte.
  • Retrouvez la session, observez le processus et le journal, puis laissez le travail se terminer.
  • Vérifiez l’état de fin, la présence des sorties et leur contenu avec les critères propres au projet.
  • Recommencez ensuite le contrôle après une interruption volontaire uniquement si le responsable de l’environnement l’autorise et si les données de test peuvent être régénérées.

N’augmentez la durée ou l’enjeu du calcul qu’après avoir confirmé trois éléments : la session est retrouvable après déconnexion, le travail peut être observé sans deviner son état, et les fichiers exportés passent un contrôle défini à l’avance. Si l’un manque, corrigez la procédure ou réduisez la tâche à des étapes plus courtes avec sauvegardes intermédiaires.

Questions pratiques sur les tâches longues

Une commande en arrière-plan équivaut-elle à tmux ?
Non. Ajouter & lance une commande en arrière-plan du shell, mais ne fournit pas à lui seul un terminal persistant pour retrouver l’affichage et interagir avec le programme. nohup traite certains effets d’une déconnexion, selon l’environnement et la commande employée ; la documentation GNU de nohup précise son rôle, sans en faire un mécanisme de sauvegarde. Choisissez l’outil selon le besoin, puis testez-le sur l’hôte concerné.

Que faire si la session réapparaît, mais que le journal ne montre aucune progression récente ?
Commencez par vérifier le processus, le fichier de sortie et l’heure des dernières écritures, plutôt que de relancer immédiatement. Le journal peut être tamponné par le programme, ou celui-ci peut être bloqué sans afficher d’erreur. Consultez les indicateurs propres au logiciel et les règles de l’environnement ; si l’état reste ambigu, conservez les preuves et demandez une vérification avant toute intervention.

tmux peut-il restaurer un travail après le redémarrage du Mac ?
Non. Une session conservée par le serveur tmux n’est pas un point de reprise après redémarrage. Le calcul peut avoir été arrêté et les données non enregistrées peuvent être perdues. Pour réduire ce risque, vérifiez les règles de maintenance de l’hôte, configurez un mécanisme de points de contrôle compatible avec le logiciel et stockez les sorties intermédiaires dans un emplacement approuvé par le laboratoire.

Comment traiter un calcul piloté par une interface graphique ?
Vérifiez les fonctions d’enregistrement automatique, les sauvegardes de projet et les points de reprise de l’application. tmux peut héberger un outil en ligne de commande utilisé par le logiciel, mais ne maintient pas nécessairement l’interface graphique ni ses fenêtres. Effectuez un essai de fermeture et de reconnexion avec un projet jetable ; pour l’audio, la vidéo ou la conception, contrôlez également l’intégrité du fichier exporté dans l’application.

Pour préparer le premier accès SSH à une machine de laboratoire, le site de RUVCLOUD permet aussi de consulter les informations générales sur les solutions Mac à distance ; le contrôle du compte, des droits et des règles d’exploitation reste propre à chaque environnement.

Une connexion SSH directe reste fragile pour un travail long : elle ne fournit pas de session facilement récupérable, elle rend l’état du calcul difficile à observer après une coupure et elle ne remplace pas les règles de continuité de l’hôte. Si le laboratoire ne dispose pas d’un Mac adapté et que le logiciel ou le script exige macOS, une machine distante louée peut éviter l’achat immédiat d’un poste, sans supprimer la nécessité de vérifier la politique de maintenance ni de protéger les résultats. Les modalités et tarifs de RUVCLOUD peuvent être examinés avant de choisir une durée ; pour une tâche représentative, validez d’abord la connexion, la reprise de session et l’export des fichiers, puis décidez si cette solution convient à votre cycle de recherche.