Screen : lancer des commandes longues sur son serveur sans craindre la déconnexion

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. Le piège sur AlmaLinux 10

Sur une AlmaLinux 10 fraîchement installée, le dnf install screen se passe très bien… et le premier lancement échoue :

$ screen -S test
Directory '/run/screen' must have mode 777.

Le réflexe naturel, c'est d'aller regarder ce répertoire et de le passer en 777, puisque c'est ce que la commande réclame. C'est d'ailleurs la réponse qu'on trouve en premier à peu près partout. Sauf que le message d'erreur désigne la mauvaise cause : /run/screen est parfaitement conforme à ce que le paquet déclare. Le problème est ailleurs, sur le binaire — et tant qu'on regarde le répertoire, on ne peut pas le voir.

Le bon diagnostic : rpm -V

Plutôt que d'inspecter des permissions dont on ignore l'attendu, autant demander à RPM de comparer ce qui est sur le disque à ce que le paquet déclare :

$ rpm -V screen
.M....G..    /usr/bin/screen

Chaque ligne de sortie signale un fichier qui a divergé (pas de sortie du tout = tout est conforme). Ici M pour le mode et G pour le groupe : /usr/bin/screen n'a ni les permissions ni le groupe prévus. Le verdict est immédiat, et surtout il ne demande aucune connaissance préalable : on n'a pas besoin de savoir ce qu'on aurait dû voir, c'est RPM qui le sait.

Pour visualiser l'écart, on peut demander au paquet l'état qu'il déclare, puis le comparer au disque :

$ rpm -qlv screen | grep bin/screen
-rwxr-sr-x    1 root    screen    480680 ... /usr/bin/screen     <- ce que le paquet prévoit

$ ls -l /usr/bin/screen
-rwxr-xr-x. 1 root root 480680  5 janv. 2026 /usr/bin/screen     <- ce qu'il y a vraiment

Le s à la place du x des droits du groupe, c'est le bit setgid. C'est lui qui manque, et le groupe screen avec.

L'explication

Le paquet crée un groupe système screen et installe le binaire en root:screen avec le bit setgid. C'est ce qui permet à screen d'écrire dans un répertoire de sockets partagé — d'où le fichier /usr/lib/tmpfiles.d/screen.conf livré par le paquet, qui contient d /run/screen 0775 root screen. Privé de son setgid, screen n'a plus ce droit et bascule sur son autre mode de fonctionnement : celui où, n'ayant aucun privilège particulier, il exige un répertoire ouvert à tous en 0777 pour pouvoir y créer son sous-dossier. D'où le message.

Quant à savoir pourquoi le bit disparaît à l'installation, le bug Red Hat n°2385964, toujours ouvert, l'attribue à un problème d'ordre dans le paquet : le groupe screen serait créé après la pose des permissions sur les fichiers, si bien que RPM échoue silencieusement à attribuer un groupe qui n'existe pas encore. Je rapporte cette mécanique telle qu'elle y est décrite, sans l'avoir vérifiée moi-même. Ce qui est certain — et qui suffit à corriger — c'est que le binaire n'est pas dans l'état que le paquet déclare.

La correction

D'abord, vérifiez qu'aucune session screen ne tourne. Attention : tant que le bug est là, screen -ls échoue avec la même erreur et ne vous apprendra rien. C'est donc ps qu'il faut interroger :

ps -ef | grep [s]creen

Ensuite, une seule commande suffit. Le groupe screen existe désormais sur le système : réinstaller le paquet repose les permissions correctement.

sudo dnf reinstall screen

On peut aussi corriger à la main :

sudo chown root:screen /usr/bin/screen
sudo chmod 2755 /usr/bin/screen

…mais préférez le reinstall, et pas seulement parce qu'il est plus court : il restaure tout ce que le paquet déclare, y compris ce qu'on n'a pas remarqué. Si la création tardive du groupe a fait échouer l'attribution sur un fichier, rien ne garantit qu'elle n'a pas échoué ailleurs. Ici rpm -V ne signalait qu'une seule ligne, l'écart était donc limité — mais on ne l'apprend qu'après coup.

Rien d'autre n'est nécessaire : pas de reconnexion, pas de redémarrage, pas de systemd-tmpfiles --create. Et surtout, inutile de vous ajouter au groupe screen : c'est le binaire setgid qui porte le droit, pas l'utilisateur. C'est une erreur naturelle quand on voit un groupe dédié apparaître, mais elle ne sert à rien.

Vérifier que c'est réparé

$ ls -l /usr/bin/screen
-rwxr-sr-x. 1 root screen 480680  5 janv. 2026 /usr/bin/screen   # le « s » est revenu

$ rpm -V screen
                                                                 # plus aucune sortie
$ screen -S test                                                 # démarre, et screen -ls le liste

Les trois ensemble, pas seulement le dernier : un screen qui démarre pourrait le faire pour une autre raison. Le socket est créé dans /run/screen/S-votrelogin, en 0700 et à votre nom.

Et le chmod 777, alors ?

C'est la première réponse qu'on trouve en ligne, et elle est doublement mauvaise. D'une part /run est un tmpfs : la modification est perdue au prochain redémarrage. D'autre part elle consiste à faire exactement ce que le message d'erreur demande, c'est-à-dire à basculer délibérément screen dans son mode sans privilège, avec un répertoire de sockets ouvert en écriture à tous les comptes de la machine — alors que le vrai problème est un bit manquant sur un binaire, et qu'il se corrige en une commande.

Une dernière option, en revanche légitime si vous n'êtes pas administrateur de la machine : demander à screen de ranger ses sockets dans votre home plutôt que dans /run, en ajoutant à votre .bashrc :

mkdir -p ~/.screen && chmod 700 ~/.screen
export SCREENDIR="$HOME/.screen"

Attention, la variable doit être exportée dans tous vos shells : un screen -ls lancé sans elle ne verra plus aucune de vos sessions.

Est-ce que ça va revenir ?

Non. Le groupe screen existe maintenant sur le système, donc les futures mises à jour du paquet appliqueront les droits correctement. Il n'y a rien à surveiller.

Constaté sur AlmaLinux 10.2 avec screen-5.0.1-6.el10_2.x86_64. Le mécanisme décrit laisse penser que Rocky Linux 10 et RHEL 10 sont concernés de la même façon, mais je ne l'ai pas vérifié sur ces distributions.

3. 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 backup

Vous 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 backup

S'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 backup

4. 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

5. 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.

6. 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être
• Ctrl+a n / Ctrl+a p : fenêtre suivante / précédente
• Ctrl+a 0 à 9 : aller à la fenêtre n°X
• Ctrl+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.

7. 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.

8. 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.