Linux sans magie #23 — screen et tmux : garder une session terminal persistante et s’y reconnecter

Dans l’article précédent, nous avons vu comment nohup et disown permettent de rendre une commande moins dépendante de la session shell qui l’a lancée. C’est utile pour un traitement non interactif, mais cela ne répond pas à un autre besoin très courant : retrouver plus tard exactement la même session terminal avec ses programmes encore ouverts.

C’est le rôle des multiplexeurs de terminal comme screen et tmux.

Ils permettent de créer une session indépendante du terminal SSH courant, d’y lancer un shell ou un programme interactif, de détacher cette session, puis de la rattacher plus tard depuis une autre connexion.

L’objectif de cet article est de comprendre ce mécanisme avec deux outils classiques : GNU Screen et tmux.

Le problème : une session SSH n’est pas durable

Imaginez une connexion SSH vers un serveur :

ssh admin@serveur

Vous lancez ensuite un programme interactif long, par exemple :

top

ou un éditeur :

vim fichier.conf

Si la connexion réseau tombe ou si vous fermez le terminal, vous perdez l’accès direct à cette interface interactive.

Avec nohup, on peut protéger une commande adaptée à l’exécution non interactive. Mais on ne peut pas revenir plus tard dans le même terminal pour retrouver exactement l’écran, le shell, l’éditeur ou les commandes comme on les avait laissés.

Un multiplexeur de terminal crée une couche intermédiaire :

terminal SSH
    ↓
screen ou tmux
    ↓
session persistante
    ↓
shell / top / vim / autres programmes

Le terminal SSH peut disparaître tandis que la session screen ou tmux continue d’exister.

Ce que signifie « détacher » une session

Détacher une session ne veut pas dire arrêter les programmes qu’elle contient.

Cela signifie simplement couper le lien entre la session multiplexée et le terminal externe actuellement utilisé.

La session continue alors à fonctionner en arrière-plan. Plus tard, vous ouvrez un nouveau terminal ou une nouvelle connexion SSH et vous vous rattachez à cette même session.

Le principe est donc :

créer → travailler → détacher → se déconnecter → se reconnecter → rattacher

C’est différent de nohup : ici, le but n’est pas seulement de laisser tourner une commande, mais de conserver une session terminal interactive.

Prérequis

Vérifiez d’abord si les outils sont disponibles :

command -v screen
command -v tmux

Selon la distribution, l’un ou les deux peuvent ne pas être installés.

L’installation dépend du système. Sur une distribution Debian ou Ubuntu récente, les paquets portent généralement les noms screen et tmux. Sur d’autres distributions, utilisez le gestionnaire de paquets habituel et vérifiez le nom du paquet avant installation.

L’article ne dépend d’aucune configuration personnalisée dans .screenrc ou .tmux.conf.

Premier lab avec GNU Screen

1. Créer une session nommée

Lancez :

screen -S lab

Vous entrez alors dans une nouvelle session Screen nommée lab.

À l’intérieur, lancez une commande simple :

watch -n 2 date

Cette commande met à jour l’heure toutes les deux secondes.

2. Détacher la session

Pour détacher Screen, utilisez la séquence :

Ctrl-a d

Il faut comprendre cette notation ainsi :

appuyez sur Ctrl-a ;
relâchez ;
appuyez sur d.

Vous revenez alors dans le shell extérieur.

La commande watch continue dans la session Screen détachée.

3. Vérifier les sessions Screen

Affichez les sessions disponibles :

screen -ls

Vous devez voir une session nommée lab, généralement marquée comme détachée.

4. Rattacher la session

Reconnectez-vous :

screen -r lab

Vous retrouvez la session et watch toujours en cours.

5. Fermer proprement

Dans watch, quittez avec :

Ctrl-c

Puis quittez le shell de la session :

exit

La session Screen se termine lorsqu’elle ne contient plus de shell actif.

Vérifiez :

screen -ls

La session lab ne doit plus apparaître.

Ce que Screen protège réellement

GNU Screen possède un mécanisme d’autodetach activé par défaut. Lorsqu’un hangup survient, Screen peut détacher la session au lieu de détruire les programmes qu’elle contient.

C’est ce qui rend Screen adapté aux connexions distantes instables : une coupure de terminal n’implique pas forcément la perte de la session multiplexée.

Cela ne signifie pas que Screen rend les processus immortels. Si le serveur redémarre, si Screen est tué, si l’utilisateur termine explicitement la session ou si un programme se termine de lui-même, Screen ne peut pas préserver ce qui n’existe plus.

Même lab avec tmux

1. Créer une session nommée

Lancez :

tmux new -s lab

Vous entrez dans une nouvelle session tmux appelée lab.

Lancez :

watch -n 2 date

2. Détacher tmux

La combinaison par défaut est :

Ctrl-b d

Comme pour Screen :

appuyez sur Ctrl-b ;
relâchez ;
appuyez sur d.

Vous revenez dans le shell externe tandis que la session continue d’exister.

3. Lister les sessions tmux

Utilisez :

tmux ls

Vous devez voir une session nommée lab.

4. Rattacher la session

Rattachez-la avec :

tmux attach -t lab

La commande watch doit toujours être active dans la session.

5. Fermer proprement

Quittez watch avec :

Ctrl-c

Puis :

exit

Une fois le dernier shell de la session terminé, tmux ferme cette session.

Vérifiez :

tmux ls

S’il ne reste aucune session, tmux peut répondre qu’aucun serveur n’est actif. Ce n’est pas une erreur opérationnelle : cela signifie simplement qu’aucune session tmux n’existe encore.

Le modèle tmux : session, window, pane

Tmux va plus loin que le simple détachement d’une session.

Son modèle principal est :

session
  └── window
       ├── pane
       └── pane

Un pane contient un terminal dans lequel tourne un shell ou un programme.

Une window contient un ou plusieurs panes.

Une session regroupe une ou plusieurs windows.

Pour le #23, il suffit de comprendre cette hiérarchie. Les raccourcis avancés de création et de navigation entre panes et windows seront laissés à un éventuel article dédié.

Le point important est que tmux ne protège pas uniquement une commande : il maintient une structure complète de terminaux virtuels que l’on peut détacher et rattacher.

Screen et tmux : même besoin, modèles différents

Les deux outils répondent au même besoin principal : maintenir une session terminal indépendante de la connexion courante.

Dans les usages de base de cet article :

Screen                         tmux
------                         ----
screen -S lab                 tmux new -s lab
Ctrl-a d                      Ctrl-b d
screen -ls                    tmux ls
screen -r lab                 tmux attach -t lab

Screen possède une histoire plus ancienne et un modèle souvent perçu comme direct pour créer, détacher et rattacher une session.

Tmux structure explicitement les terminaux en sessions, windows et panes et expose de nombreuses commandes pour les organiser.

L’objectif ici n’est pas de déclarer un « meilleur » outil. Sur un serveur, le bon choix dépend notamment de ce qui est installé, des habitudes de l’équipe et du niveau de fonctionnalités nécessaire.

Tester une vraie coupure SSH

Le test le plus parlant consiste à utiliser une session SSH de laboratoire.

Par exemple avec tmux :

tmux new -s ssh-test

À l’intérieur :

watch -n 2 date

Fermez ensuite la connexion SSH sans quitter tmux proprement, puis reconnectez-vous au serveur.

Listez les sessions :

tmux ls

Puis rattachez :

tmux attach -t ssh-test

Vous devez retrouver la session toujours active.

Le même principe peut être testé avec Screen :

screen -S ssh-test

Puis, après reconnexion :

screen -ls
screen -r ssh-test

Faites ce test sur une session non critique. L’objectif n’est pas de provoquer volontairement une coupure sur une connexion d’administration importante.

Vérifier à quel niveau on se trouve

Avec plusieurs couches terminales, il est facile d’oublier si l’on est encore dans tmux ou Screen.

Pour tmux, la variable TMUX est généralement définie dans la session :

printf '%s\n' "$TMUX"

Une valeur non vide indique normalement que le shell courant fonctionne à l’intérieur de tmux.

Pour Screen, la variable STY est généralement définie :

printf '%s\n' "$STY"

Ces variables sont pratiques pour éviter de lancer accidentellement des sessions imbriquées sans s’en rendre compte.

Bonnes pratiques en administration

Nommez les sessions de manière explicite :

tmux new -s maintenance

ou :

screen -S migration

Une session nommée maintenance est beaucoup plus facile à retrouver qu’un identifiant générique lorsque plusieurs sessions existent.

Avant de créer une nouvelle session, vérifiez celles qui existent déjà :

tmux ls

ou :

screen -ls

Évitez de conserver indéfiniment des sessions oubliées. Une session persistante peut contenir des shells ouverts, des commandes sensibles ou des programmes consommant encore des ressources.

Fermez les sessions devenues inutiles et vérifiez régulièrement leur contenu.

Sécurité

Une session Screen ou tmux s’exécute avec les droits de l’utilisateur qui l’a créée.

Elle ne constitue pas une frontière de sécurité supplémentaire et n’ajoute aucun privilège.

En revanche, une session oubliée peut conserver un shell ouvert ou un programme d’administration pendant longtemps. La sécurité dépend donc toujours des permissions du compte, de l’accès au serveur et de la protection des sockets ou sessions associées.

Sur un système partagé, ne supposez pas qu’une session persistante remplace les mécanismes normaux de contrôle d’accès.

Évitez également d’y laisser des secrets visibles à l’écran plus longtemps que nécessaire.

Ce que Screen et tmux ne remplacent pas

Un multiplexeur de terminal n’est pas un gestionnaire de services.

Pour une application qui doit :

démarrer automatiquement au boot ;
redémarrer en cas de crash ;
avoir des dépendances explicites ;
être supervisée ;
produire des logs centralisés ;

une unité systemd est généralement plus adaptée.

Screen et tmux sont d’abord des outils de session interactive persistante.

Ils sont très utiles pour une maintenance, une migration, une compilation, un diagnostic ou une tâche interactive longue exécutée à distance.

Limites de cet article

Nous ne couvrons volontairement pas :

.tmux.conf ;
.screenrc ;
plugins tmux ;
thèmes ;
mode copie avancé ;
partage de sessions entre utilisateurs ;
scripting tmux ;
personnalisation des préfixes clavier ;
gestion avancée des windows et panes.

Le but est de maîtriser d’abord le cycle de vie fondamental d’une session : création, détachement, découverte, rattachement et fermeture.

Rollback et nettoyage

Pour tmux, listez les sessions :

tmux ls

Puis, si nécessaire, terminez explicitement une session de lab :

tmux kill-session -t lab

Pour Screen :

screen -ls

Le nettoyage recommandé reste de rattacher la session puis de quitter proprement les programmes et le shell qu’elle contient.

Pour une session de laboratoire devenue inutile, vous pouvez aussi la terminer depuis Screen avec la commande appropriée après rattachement.

Vérifiez ensuite qu’aucune session de lab ne reste active.

Références officielles

GNU Screen — Screen User’s Manual — GNU Project
GNU Screen — Detach — GNU Project
tmux — Getting Started — projet tmux
tmux — manuel — OpenBSD manual pages

Conclusion

screen et tmux répondent à un besoin différent de nohup et disown.

Avec nohup, on cherche surtout à permettre à une commande non interactive de continuer malgré la disparition du terminal. Avec Screen ou tmux, on conserve une session terminal interactive que l’on peut détacher puis retrouver plus tard.

Le workflow de base est simple : créer une session, lancer son travail, détacher, se reconnecter, lister les sessions puis rattacher celle que l’on veut retrouver.

Une fois ce mécanisme compris, tmux ouvre ensuite la porte à des usages plus avancés avec ses windows et ses panes. Mais le premier réflexe à retenir est plus simple : pour une longue intervention SSH interactive, un multiplexeur de terminal évite qu’une coupure réseau transforme immédiatement la session en perte de travail.