Pourquoi les programmes s'arrêtent quand SSH tombe
Un programme lancé dans une session SSH est lié au terminal de cette session. Quand la connexion se termine, le terminal se ferme et le programme reçoit normalement un signal de raccrochage (hangup) puis s'arrête. tmux garde le terminal sur le serveur, ce qui permet à la connexion d'aller et venir.
tmux doit tourner sur le serveur, pas sur votre portable. Installez-le avec sudo apt install tmux ou sudo dnf install tmux.
Les commandes dont vous avez besoin
| Action | Commande |
|---|---|
Se rattacher à la session work, ou la créer | tmux new -A -s work |
| Se détacher en la laissant tourner | Ctrl+b, puis d |
| Lister les sessions | tmux ls |
| Se rattacher à une session existante | tmux attach -t work |
| Démarrer une session en arrière-plan | tmux new -d -s work |
| Terminer une session | tmux kill-session -t work |
| Terminer toutes les sessions | tmux kill-server |
| Remonter dans l'historique | Ctrl+b, puis [, et q pour quitter |
tmux new -A -s work est la commande à retenir, car elle fonctionne que la session existe déjà ou non. Vous pouvez aussi y aller directement depuis votre machine :
ssh -t user@server tmux new -A -s workLe -t est obligatoire, car tmux a besoin d'un terminal.
À quoi ressemble une vraie déconnexion
Nous avons lancé une boucle dans tmux, puis tué le client SSH avec kill -9 pour imiter une connexion perdue. Depuis une nouvelle connexion :
$ tmux ls
work: 1 windows (created Tue Nov 3 18:22:28 2026)(attached) a disparu de la ligne, car aucun client n'est connecté, et la boucle écrivait toujours dans son fichier. Quand aucune session n'existe, tmux ls répond no server running on /tmp/tmux-1000/default. Cela veut dire que vos sessions se sont terminées, par exemple après un redémarrage.
tmux ne survit pas à un redémarrage du serveur. Il meurt aussi à la déconnexion si le système tue les processus de l'utilisateur, avec KillUserProcesses=yes dans logind.conf. Debian et Ubuntu le livrent désactivé. Si votre tmux meurt à chaque déconnexion, remettez-le à no.
Sans tmux : nohup
Pour une seule tâche dont vous n'avez pas besoin de revoir l'écran :
nohup ./job.sh > job.log 2>&1 &Dans notre test, nous avons lancé trois tâches dans une session puis fermé la connexion. La tâche lancée avec nohup s'est terminée et a écrit son journal. La tâche en arrière-plan avec & seul et la tâche au premier plan sont mortes.
Si vous avez déjà lancé une tâche avec & en oubliant nohup, cette commande interne de bash la protège du signal de raccrochage :
disown -h %1Sa sortie va toujours vers l'ancien terminal : une tâche qui écrit beaucoup à l'écran peut donc échouer après votre départ. Dans les deux cas, vous ne pouvez plus interagir avec la tâche ensuite.
Avec systemd : systemd-run
Si vous avez sudo, vous pouvez lancer la tâche comme un service temporaire. Elle est alors totalement séparée de votre connexion, et systemd conserve sa sortie :
sudo systemd-run --unit=longjob /usr/local/bin/job.sh
systemctl status longjob
journalctl -u longjob -fElle s'exécute en root sauf si vous ajoutez --uid=user, et démarre dans / sauf si vous indiquez un dossier avec --working-directory= : utilisez donc des chemins complets.
Quand la tâche se termine avec succès, l'unité disparaît : dans notre test, systemctl status longjob répondait alors Unit longjob.service could not be found, mais journalctl -u longjob avait toujours la sortie. Une tâche en échec reste dans la liste jusqu'à ce que vous lanciez sudo systemctl reset-failed longjob.
Laquelle choisir
- tmux pour le travail interactif : éditeurs, shells de base de données, tout ce à quoi vous voulez revenir.
- nohup pour une tâche sur un serveur où vous ne pouvez rien installer.
- systemd-run pour une tâche longue que vous voulez journalisée et séparée de votre connexion.
Si la connexion elle-même continue de tomber, voir Broken pipe et keep-alive. tmux met votre travail à l'abri, et les réglages keep-alive rendent les coupures moins fréquentes. Sur un réseau qui change souvent, Mosh avec tmux sur le serveur garde à la fois la connexion et le travail.
Questions
Comment se rattacher à tmux après une déconnexion SSH ?
Reconnectez-vous et lancez tmux attach -t work, ou tmux new -A -s work, qui crée aussi la session si elle n'existe plus. tmux ls liste les sessions encore actives.
tmux survit-il au redémarrage du serveur ?
Non. tmux est un processus ordinaire sur le serveur, donc un redémarrage ferme toutes les sessions. Pour un travail qui doit reprendre après un redémarrage, utilisez un service systemd.
Pourquoi ma session tmux disparaît-elle quand je me déconnecte ?
Le système tue sans doute les processus de l'utilisateur à la déconnexion, avec KillUserProcesses=yes dans /etc/systemd/logind.conf. Mettez no, puis redémarrez systemd-logind ou le serveur.
Comment garder une commande active après avoir fermé SSH, sans tmux ?
Lancez-la avec nohup ./job.sh > job.log 2>&1 &. Elle continue après la déconnexion et écrit sa sortie dans job.log, mais vous ne pouvez pas revenir à son écran.
Faut-il tmux sur mon propre ordinateur ?
Non. tmux doit tourner sur le serveur. Votre ordinateur n'a besoin que d'un client SSH.