Le script Python s’arrête-t-il après une déconnexion SSH du Mac distant ? 2026

Le manuel de tmux décrit deux opérations complémentaires — détacher une session et s’y rattacher — qui permettent de retrouver une session après une coupure SSH (manuel officiel de tmux). Cette semaine, vérifiez d’abord où s’exécute votre script Python ; pour les tâches de recherche en ligne de commande, lancez-le dans une session tmux créée sur le Mac distant, puis contrôlez les journaux et les résultats après reconnexion. Une session persistante ne protège toutefois ni contre le redémarrage du Mac, ni contre un plantage du programme.

Cet article s’adresse aux étudiantes et étudiants, aux doctorants et aux chercheurs qui exécutent des tâches Python par SSH sur un Mac distant, ainsi qu’aux équipes techniques qui doivent distinguer une session encore accessible d’une analyse réellement réussie.

SSH fournit un moyen d’ouvrir une session distante ; une connexion perdue ne constitue donc pas, à elle seule, une preuve que le processus Python a terminé ou qu’il a échoué. La documentation d’OpenSSH décrit la connexion comme le transport de sessions et de canaux entre les machines (manuel OpenSSH). L’état du calcul dépend ensuite de la session qui l’a lancé, de son environnement et de la réaction du processus à la fermeture de cette session.

Séparez ces situations avant toute action :

• La fenêtre du terminal local est fermée, mais le shell distant peut encore être actif ou avoir reçu une fermeture. Il faut vérifier sur le Mac, et non supposer que fermer la fenêtre a nécessairement tué Python.
• La connexion SSH est interrompue de façon inattendue. Dans un shell ordinaire, le processus peut se terminer, rester actif ou recevoir un signal associé à la fermeture de la session. Le module Python consacré aux signaux décrit leur rôle dans le comportement des processus ; il ne permet pas, à lui seul, de déduire ce qu’a fait un script donné.
• Le script tourne dans une session tmux détachée. La session reste accessible à distance et peut être rattachée ultérieurement, tant que la machine et le processus sont toujours disponibles.
• Le Mac distant redémarre ou le processus plante. Il ne s’agit plus d’une simple coupure SSH : la session ou le calcul peut avoir disparu.
• Le processus est encore visible, mais ne progresse plus. Un programme peut attendre une saisie, buter sur un accès fichier ou être bloqué dans une étape. Sa seule présence ne certifie pas que les résultats avancent.

Notez la commande exécutée, les messages affichés à la déconnexion, le répertoire des sorties et les chemins des journaux. Cette trace limite les risques de relancer une analyse sans savoir si elle a déjà modifié des fichiers ou traité une partie des données.

Après avoir rouvert SSH, ne relancez pas immédiatement le même script. Une seconde exécution peut écraser des fichiers, consommer des ressources inutilement ou produire un résultat ambigu si la première tâche tourne encore. Commencez par retrouver le contexte d’exécution.

Dans un shell ordinaire, l’historique de la fenêtre précédente n’est pas forcément récupérable. Cherchez les processus Python actifs avec les outils disponibles sur la machine, puis comparez leur commande et leur répertoire à ceux du lancement initial. Sur macOS, le Moniteur d’activité permet aussi d’examiner les processus et leur activité ; suivez les indications du guide Apple du Moniteur d’activité. Une liste de processus ne révèle cependant pas toujours si l’analyse progresse correctement.

Si tmux avait été utilisé, listez les sessions existantes, puis rattachez-vous à celle qui correspond au travail concerné. Le guide de démarrage de tmux présente les principes de création et de rattachement des sessions. Si aucune session n’apparaît, cela ne prouve pas que le script n’a jamais été lancé : le processus peut avoir été exécuté ailleurs ou la machine peut avoir été redémarrée.

Recoupez alors plusieurs signes :

• Le processus : est-il encore actif et correspond-il à la bonne commande ?
• Le journal : contient-il des messages récents, une erreur finale ou une indication d’étape terminée ?
• Les sorties : leur taille ou leur contenu a-t-il évolué depuis la dernière vérification ?
• La validité scientifique : une entrée témoin ou un résultat de référence produit-il le comportement attendu ?

Un fichier créé au démarrage peut rester présent même si le traitement a échoué. De même, un processus actif ne signifie pas que ses calculs sont valides : il peut tourner sans écrire, attendre un accès ou traiter un fichier inattendu.

Pour un script en ligne de commande qui doit survivre à une déconnexion de terminal, le principe est de créer la session sur le Mac distant, d’y démarrer le travail, puis de détacher la session avant de fermer SSH. Le manuel officiel de tmux confirme qu’une session détachée peut continuer en arrière-plan et être rattachée ultérieurement ; il ne garantit pas la continuité après une panne de la machine ou du programme.

Procédez ainsi, en adaptant le nom de la session, le répertoire et la commande au projet :

1. Connectez-vous au Mac distant avec SSH et placez-vous dans le répertoire du projet. Vérifiez que les données d’entrée, les droits d’accès et l’environnement Python sont ceux attendus par l’analyse.
2. Vérifiez que tmux est disponible avec command -v tmux. Si aucune commande n’est trouvée, n’installez pas un outil à l’aveugle sur une machine administrée par un laboratoire : vérifiez d’abord les règles de l’équipe et les outils autorisés.
3. Créez une session nommée, par exemple avec tmux new -s analyse. Cette commande démarre une session tmux dans le shell distant ; le guide officiel fournit les bases de la création et de la gestion de sessions.
4. Lancez le script depuis cette session, en affichant ou en enregistrant ses messages. Avant un traitement important, vérifiez le chemin des entrées, la destination des résultats et l’absence d’un lancement précédent qui modifierait les mêmes fichiers.
5. Détachez la session avec la combinaison de touches tmux Ctrl-b, puis d. La session se sépare du terminal sans que cette action soit équivalente à fermer volontairement le processus Python.
6. Reconnectez-vous en SSH lorsque nécessaire et rattachez-vous à la session avec tmux attach -t analyse. Si le nom ne correspond pas, listez les sessions disponibles au lieu de lancer un nouveau calcul immédiatement.

Ces commandes suivent les conventions documentées par le projet tmux, mais leur disponibilité doit être confirmée dans l’environnement macOS utilisé. Le shell, la configuration de la machine et les règles d’administration du laboratoire peuvent différer. Pour un accès macOS destiné à vérifier un logiciel ou un environnement de recherche, consultez aussi les conditions d’utilisation d’un Mac distant avec JEXCLOUD avant de choisir cette solution.

Une session tmux retrouvée prouve seulement que cette session existe encore. Elle ne prouve ni que le traitement fonctionne, ni que les résultats sont complets. Pour une analyse reproductible, définissez séparément les journaux, les fichiers intermédiaires et les résultats finaux. Le guide de journalisation de Python détaille les mécanismes disponibles pour enregistrer les événements d’un programme.

Par exemple, un lancement avec redirection de la sortie du terminal peut ressembler à ceci :

python3 analyse.py > logs/analyse.log 2>&1

Cette redirection enregistre les sorties standard et d’erreur dans le fichier indiqué, mais elle ne transforme pas à elle seule un script en tâche reprenable. Vérifiez que le répertoire de journaux existe, que le compte peut y écrire et que le script enregistre aussi les étapes utiles à l’interprétation : entrée traitée, paramètres, erreurs et progression significative. Si le programme utilise le module logging, configurez ses gestionnaires et son format selon les besoins du projet, plutôt que de compter uniquement sur les messages imprimés à l’écran.

Pour une tâche longue, la reprise dépend de la façon dont le code traite les données. Un script qui écrit un résultat final seulement à la dernière étape peut ne laisser aucun état exploitable après une interruption. Si le traitement le permet, enregistrez des sorties intermédiaires identifiables, évitez d’écraser les résultats validés et prévoyez un mécanisme de reprise cohérent avec les données. Testez cette reprise sur une entrée représentative avant de la considérer fiable.

Lorsque le journal ne change plus, cherchez une erreur explicite, une attente de saisie, un problème de chemin ou un défaut de droits. Vérifiez aussi si le programme met ses sorties en tampon : l’absence de nouvelles lignes n’établit pas toujours que le calcul est arrêté. Enfin, comparez un résultat à une référence du projet ou à un échantillon dont le comportement est connu. Ne remettez pas un résultat en circulation uniquement parce que la session est encore ouverte.

La décision dépend des preuves observées, pas de l’impression laissée par le terminal :

• Le processus est actif, les journaux avancent et les sorties évoluent de façon cohérente : laissez le travail continuer, puis contrôlez le résultat final et son intégrité.
• Le processus est absent, mais les fichiers de sortie sont complets et validés : documentez le contrôle et évitez un nouveau lancement inutile.
• Le processus est absent et les sorties sont partielles : vérifiez si le script peut reprendre sans écraser les étapes déjà correctes. Si ce n’est pas clair, copiez ou isolez les fichiers partiels avant de relancer.
• Le processus est présent sans progression vérifiable, ou les journaux révèlent une erreur : arrêtez-vous avant de déclarer le calcul valide ; identifiez la cause et testez la correction sur un petit cas.
• Le Mac a redémarré, le service a été arrêté ou l’état est impossible à établir : traitez le calcul comme potentiellement interrompu et vérifiez les fichiers avant toute reprise.

Pour un calcul volumineux, planifié ou soumis à des règles d’allocation de ressources, l’ordinateur distant n’est pas nécessairement le bon environnement. Consultez les politiques du laboratoire et de l’établissement : les règles d’utilisation des ressources de calcul de TACC illustrent pourquoi les utilisateurs doivent respecter les conditions propres à leur infrastructure. Si votre université utilise Slurm, la documentation de sbatch explique la soumission d’un script à un ordonnanceur ; les options disponibles et les limites relèvent toutefois de l’administration locale.

Une coupure SSH arrête-t-elle toujours Python sur le Mac distant ?

Non. Si le script tourne dans une session tmux détachée sur le Mac distant, vous pouvez normalement vous rattacher à cette session après reconnexion. Dans un shell ordinaire, la fin de la connexion peut affecter le processus selon son lancement et les signaux reçus. Vérifiez le processus et ses sorties plutôt que de déduire son état de la fenêtre fermée.

Comment vérifier après reconnexion si l’analyse tourne encore ?

Vérifiez séparément la session tmux, le processus Python, l’activité récente du journal et l’évolution des fichiers de sortie. Un processus visible peut être bloqué, attendre une entrée ou avoir échoué sans se terminer immédiatement ; un fichier présent peut être incomplet. Comparez les résultats à une entrée de référence avant de déclarer l’analyse terminée.

tmux protège-t-il le calcul contre un redémarrage ou un plantage ?

Non. tmux permet de détacher une session et de la retrouver après une déconnexion SSH, mais ne constitue ni un mécanisme de reprise après redémarrage ni un ordonnanceur. Un arrêt de la machine, un processus défaillant ou une intervention d’administration peut interrompre le calcul. Pour les analyses importantes, prévoyez journaux, sauvegardes et étapes reprenables, puis vérifiez la politique de votre laboratoire.

Comment conserver les journaux et reprendre une longue analyse ?

Écrivez les messages d’exécution dans un journal séparé des résultats et consignez les étapes, les erreurs et les paramètres nécessaires à la reproductibilité. Pour reprendre, le programme doit sauvegarder des états cohérents ou pouvoir retraiter les données sans corrompre les sorties. Testez la procédure sur une entrée représentative avant un calcul important ; si le travail relève du HPC, utilisez les mécanismes autorisés par l’établissement.

Avant de relancer ou de quitter une analyse, cochez chaque point applicable :

• [ ] La commande initiale, le répertoire du projet et l’environnement Python ont été identifiés.
• [ ] La session tmux, si elle existe, a été examinée sur le Mac distant plutôt que supposée active.
• [ ] Le processus correspond bien au script et aux données attendus.
• [ ] Le journal a été consulté jusqu’à son dernier message utile, et les erreurs ont été recherchées.
• [ ] Les sorties ont été vérifiées pour détecter des fichiers partiels, vides ou écrasés.
• [ ] Un échantillon ou un résultat de référence confirme que l’analyse reste scientifiquement cohérente.
• [ ] La reprise a été testée ou la décision de relancer a été prise en protégeant les résultats déjà produits.
• [ ] Les règles du laboratoire ont été vérifiées si le calcul est long, intensif ou soumis à un ordonnanceur.

Si le besoin principal consiste à faire fonctionner ou à valider un logiciel exclusivement disponible sur macOS, un Mac distant peut fournir l’environnement de test sans transformer tmux en garantie de disponibilité. JEXCLOUD peut être envisagé pour un usage macOS temporaire : consultez les conditions d’accès et les offres de Mac distant après avoir vérifié les contraintes propres au projet. Les travaux lourds, récurrents ou régis par les règles de calcul de l’université doivent plutôt être évalués au regard du HPC institutionnel. Une session persistante aide à retrouver un terminal, mais la fiabilité scientifique vient des journaux, d’une reprise conçue dans le code et d’une vérification indépendante des résultats.

• Découvrez comment préserver les tâches d’empaquetage après une coupure SSH et vérifier les journaux et les artefacts avant de les relancer.
• Pour automatiser le lancement et la supervision d’un processus sur macOS, consultez ce guide pratique de launchd.
• Le guide Remote SSH aide à diagnostiquer les connexions à un Mac distant et les problèmes de reconnexion.