Recherche de site Web

Comment utiliser la commande screen pour éviter la fermeture inopinée d’une session ssh

Problème de déconnexion SSH

Votre session de terminal peut être fermée en raison de divers problèmes de réseau pendant que vous êtes en train
exécuter un processus sur une machine distante, par exemple :

Write failed: Broken pipe

À la suite de cette déconnexion réseau, votre session shell ssh tuera également par inadvertance tous les processus enfants exécutés sous votre session ssh sur la machine distante.

Exécution d’une solution de session SSH ininterrompue

Utilisez la commande screen pour enregistrer la session. Pendant que votre session SSH est déconnectée, la commande screen maintient votre processus à distance en cours d’exécution. Prenons l’exemple SSH suivant où nous essayons de passer d’un hôte local 10.1.1.2 à un hôte 10.1.1.15 distant.

Exemple de commande SSH d’écran

Commençons par énumérer nos sessions d’écran actuellement ouvertes :

local> $ screen -list
No Sockets found in /var/run/screen/S-lubos.

À partir de la sortie de la commande d’écran ci-dessus, nous pouvons voir qu’aucune session n’est actuellement ouverte. Créons une nouvelle session d’écran tout en nous connectant en même temps à un hôte distant. Ouvrez le nouveau terminal et entrez :

local> $ screen ssh root@10.1.1.15

Listez à nouveau nos sessions d’écran :

local> $ screen -list
There is a screen on:
        5646.pts-0.thebeast     (13/05/15 16:49:30)     (Attached)
1 Socket in /var/run/screen/S-lubos.

La sortie d’écran ci-dessus montre que nous avons une session attachée avec l’ID PID 5646. À ce moment, nous pouvons démarrer un processus sur un hôte distant comme par exemple nous pouvons effectuer un simple ping :

remote> # ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.4.4: icmp_req=1 ttl=57 time=18.2 ms
64 bytes from 8.8.4.4: icmp_req=2 ttl=57 time=17.2 ms
64 bytes from 8.8.4.4: icmp_req=3 ttl=57 time=18.0 ms

À ce stade, nous pouvons simuler une déconnexion du réseau à un hôte distant en débranchant manuellement le câble réseau :

local> 
ping 10.1.1.15
PING 10.1.1.15 (10.1.1.15) 56(84) bytes of data.
From 10.1.1.2 icmp_seq=9 Destination Host Unreachable
From 10.1.1.2 icmp_seq=10 Destination Host Unreachable
From 10.1.1.2 icmp_seq=11 Destination Host Unreachable
^C
--- 10.1.1.15 ping statistics ---
13 packets transmitted, 0 received, +3 errors, 100% packet loss, time 12088ms
pipe 3

À ce stade, nous avons perdu la connexion et notre session ssh va se bloquer. Nous pouvons maintenant fermer la fenêtre du terminal avec une session ssh déconnectée et lister nos écrans :

local> $ screen -list
There is a screen on:
        5646.pts-0.thebeast     (13/05/15 16:49:30)     (Detached)
1 Socket in /var/run/screen/S-lubos.

Comme nous pouvons le voir, notre session à l’écran est maintenant détachée. Ensuite, nous recréons une connexion réseau à un hôte distant :

local> $ ping 10.1.1.15
PING 10.1.1.15 (10.1.1.15) 56(84) bytes of data.
64 bytes from 10.1.1.15: icmp_seq=1 ttl=64 time=0.951 ms
64 bytes from 10.1.1.15: icmp_seq=2 ttl=64 time=0.563 ms
^C
--- 10.1.1.15 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.563/0.757/0.951/0.194 ms

À ce stade, nous pouvons à nouveau nous rattacher à notre session ssh distante précédemment ouverte :

local> $ screen -d -r
64 bytes from 8.8.4.4: icmp_req=203 ttl=57 time=18.2 ms
64 bytes from 8.8.4.4: icmp_req=204 ttl=57 time=18.1 ms
64 bytes from 8.8.4.4: icmp_req=205 ttl=57 time=18.1 ms
64 bytes from 8.8.4.4: icmp_req=206 ttl=57 time=18.4 ms
64 bytes from 8.8.4.4: icmp_req=207 ttl=57 time=18.1 ms
^C
--- 8.8.4.4 ping statistics ---
207 packets transmitted, 207 received, 0% packet loss, time 206310ms
rtt min/avg/max/mdev = 17.231/18.369/23.795/0.571 ms

La sortie ci-dessus avec 0 % de perte de paquets est la preuve que même si nous avons été déconnectés d’une session distante par une défaillance du réseau, la commande screen a maintenu le processus distant en vie sans interruption.

Articles connexes: