Qui n'a jamais lancé un gros rsync ou un import de base de données en SSH, avant de voir sa connexion tomber (ou de fermer son laptop par réflexe) et de tout perdre en route ? C'est exactement le problème que règle screen, un outil vieux comme vim et Linux, installable partout, et qui sauve des nuits.
Le principe : screen crée un terminal virtuel qui vit sur le serveur, indépendamment de votre connexion SSH. Vous pouvez vous « détacher » de la session (volontairement ou parce que le wifi a lâché), la commande continue de tourner, et vous vous « rattachez » plus tard, depuis chez vous ou d'ailleurs, en retrouvant tout comme vous l'aviez laissé.
1. Installation
Il y a de bonnes chances qu'il soit déjà là, on regarde avec la commande whereis screen
kgaut@garage:~$ whereis screen
screen: /usr/bin/screen /usr/share/screen ...dans ce cas il est installé, vous pouvez passer à l'étape 2
si la commande vous répond ça :
kgaut@garage:~$ whereis screen
screen:alors il faut l'installer :
# Debian / Ubuntu
sudo apt install screen
# Fedora / Alma Linux / Rocky Linux
sudo dnf install screen
2. Les bases : créer, se détacher, revenir
On crée une session nommée via -S (prenez l'habitude tout de suite, ne faites pas comme moi... ça évite de jongler avec des identifiants numériques) :
screen -S backupVous voilà dans un shell classique, mais qui vit dans la session « backup ». Lancez votre commande, puis détachez-vous avec le raccourci Ctrl+a puis d (d comme detach). Vous retombez sur votre shell normal, avec le message [detached], et la commande continue de tourner en arrière-plan.
Toute la logique des raccourcis de screen fonctionne comme ça : Ctrl+a est le préfixe, suivi d'une touche.
Pour lister les sessions en cours :
$ screen -ls
There is a screen on:
12345.backup (Detached)
1 Socket in /run/screen/S-kgaut.
(à noter c'est -ls et non pas ls, je me suis beaucoup fait avoir au début.)
Et pour se rattacher :
screen -r backupS'il n'y a qu'une seule session, un simple screen -r suffit. Quand la commande est finie et que vous n'avez plus besoin de la session, un exit (ou Ctrl+d) dans la session la ferme proprement.
Cas classique : votre connexion a sauté et la session est restée marquée (Attached) alors que vous n'êtes plus dessus. Le drapeau -d force le détachement avant de rattacher :
screen -rd backup3. Exemples concrets sur un serveur web
Importer un gros dump de base de données
L'exemple typique où une coupure fait mal : un import qui prend 40 minutes et qui, interrompu à la moitié, laisse la base dans un état bancal.
screen -S import-db
zcat dump-prod.sql.gz | mysql -u monuser -p mabase
# Ctrl+a d, et on va se faire un café
Même logique pour une migration applicative un peu longue (un drush updb sur un gros Drupal, une réindexation SolR, un gitlab-backup restore...) : tout ce qui dépasse quelques minutes mérite un screen.
Renouveler un certificat ou mettre à jour le système
True story : j'ai perdu deux heures jeudi dernier car j'ai lancé une mise à jour de kernel sur mon serveur gitlab, sans utiliser screen, car j'ai eu une coupure de connexion au mauvais moment... (bon ok j'avais lancé la maj depuis mon téléphone, ça n'est pas forcément le truc le plus malin...)
On ne m'y reprendra plus
screen -S maj
sudo dnf upgrade
4. Exemples concrets sur un home-server
Rapatrier sa médiathèque
Copier quelques centaines de Go depuis un NAS ou un ancien serveur, ça se compte en heures. Dans un screen, on peut fermer le laptop et aller se coucher :
screen -S rsync-mediatheque
rsync -avh --progress ancien-serveur:/media/mediatheque/ /media/mediatheque/
Le lendemain, screen -r rsync-mediatheque et on constate le résultat, y compris tout ce que --progress a affiché pendant la nuit.
Tester un service avant d'en faire un vrai conteneur
Avant d'écrire le compose.yml définitif d'un service, je le lance parfois « à la main » pour voir ses logs en direct et jouer avec sa configuration. Un screen est parfait pour ça : le service reste accessible même si je me déconnecte, sans avoir à dégainer systemd pour un simple essai.
5. Plusieurs fenêtres dans une même session
Je ne m'en sert que peu, j'ai plus l'habitude, par flemme de retenir les raccourcis, d'utiliser deux sessions screen, mais c'est la deuxième corde à l'arc de screen : une session peut contenir plusieurs « fenêtres », chacune avec son shell. Typiquement : la commande longue dans une fenêtre, les logs dans une autre.
Ctrl+a c: créer une nouvelle fenêtreCtrl+a n/Ctrl+a p: fenêtre suivante / précédenteCtrl+a 0à9: aller à la fenêtre n°XCtrl+a ": liste des fenêtres, navigable aux flèches
Exemple : une fenêtre avec l'import de base, une deuxième avec un tail -f sur les logs du site, et on bascule de l'une à l'autre avec Ctrl+a n.
6. Remonter dans l'historique
Dans un screen, la molette de la souris ne remonte pas dans l'historique du terminal. Il faut passer en « copy mode » avec Ctrl+a [ : on navigue alors aux flèches ou avec PgUp/PgDn, et on en sort avec Échap. C'est déroutant au début, mais ça devient vite un réflexe.
7. Partager une sessions
Encore un truc dont je devrais plus me servir : deux personnes connectées au même serveur peuvent s'attacher à la même session avec screen -x backup. Chacun voit ce que l'autre tape, en temps réel. Très pratique pour débugger à deux sur un serveur, ou pour montrer une manipulation à quelqu'un sans partage d'écran.
Récapitulatif des commandes
screen -S nom # créer une session nommée
Ctrl+a d # se détacher
screen -ls # lister les sessions
screen -r nom # se rattacher
screen -rd nom # se rattacher en forçant le détachement
Ctrl+a c # nouvelle fenêtre
Ctrl+a n / p # fenêtre suivante / précédente
Ctrl+a " # liste des fenêtres
Ctrl+a [ # remonter dans l'historique (Échap pour sortir)
screen -x nom # session partagée
screen -dmS nom cmd # session détachée lançant une commande
Pour conclure
Il existe une alternative plus moderne, tmux, plus puissante (découpage de l'écran en panneaux, configuration plus souple) et que beaucoup préfèrent aujourd'hui. Mais screen a pour lui d'être installé, ou installable, absolument partout, y compris sur des machines anciennes ou minimalistes. C'est la même logique que vim, il était là il y a 20ans, il sera là dans 20ans.
Commentaires (0)