Le scénario
Vous administrez votre serveur linux en ssh.
Généralement, c’est pour y lancer des commandes et des scripts. Certaines commandes sont rapides à exécuter (création d’un répertoire, changement de droits sur un fichier, vérification de l’espace disque disponible…).
En revanche, si vous utilisez des scripts, certains peuvent s’avérer assez long à exécuter, de quelques minutes à parfois plusieurs heures (vous synchroniser des répertoires entiers de medias, vous lancez des opérations de déploiement, par exemple).
Vous lancez donc le script long qui tue et qui commence sa besogne. Comme vous n’avez pas codé avec les pieds, votre beau script vous informe de l’état d’avancement des opérations sur la sortie standard. Nickel.
Horreur ! Votre machine locale plante ou passe en veille, le réseau tombe ou autre désastre du même genre. Au mieux, vous êtes bon pour recommencer tout à zéro en relançant le script après redémarrage d’une nouvelle session ssh, au pire, vous avez planté une partie de votre serveur en le laissant dans un état intermédiaire instable (votre script était finalement écrit avec les pieds).
Screen à la rescousse
Vous me direz, pour éviter cette calamité, on peut toujours lancer le script en redirigeant les logs dans un fichier et en détachant la commande avec un « & ». Vrai. Mais ce n’est pas pratique dans toutes les situations.
Il existe pourtant une commande bien utile pour vous sortir de ce genre de problèmes : screen.
Si vous disposez d’une distribution linux digne de ce nom, cette commande est vraisemblablement déjà installée. Donc, n’ayons pas peur, lançons la commande en question (screen, sans paramètres). Soit vous avez eu pour résultat un écran d’accueil à passer en tappant espace ou retour, soit vous pourrez avoir l’impression que rien ne s’est passé…
Grosso-modo, vous obtenez un prompt shell. Toutes les commandes et scripts sont disponibles normalement. En réalité, vous venez de créer une nouvelle session distante. Et la grosse différence avec la session ssh par défaut, c’est qu’elle est totalement autonome.
En d’autres termes, même si vous mettez fin accidentellement à la connexion ssh, la session créée avec la commande screen va continuer à exister. Vous pouvez donc lancer vos fameux scripts longs sans crainte qu’un problème local vienne contrarier les opérations sur la machine distante. Au pire, lorsque vous vous reconnectez au serveur, une simple commande screen -r vous permettra de retrouver votre session précédente.
Evidement, la commande screen est bien plus riche que cette simple utilisation et une série d’articles entiers seraient nécessaires pour en couvrir tous les aspects (vous pouvez par exemple lancer de multiples sessions et switcher de l’une à l’autre dans des contextes différents comme dans un système de fenêtres). Un petit tour par l’énorme manuel de la commande vous donnera une petite idée de la chose : man screen
Enjoy.
