La session SSH meurt avec le VPN : tmux ou un exécuteur de tâches ?

Votre indicateur VPN passe au vert, la route est de retour, et la fenêtre SSH que vous avez laissée ouverte ne rend plus jamais l’invite. Rétablir une route ne rétablit pas la conversation TCP qui l’utilisait, donc tout ce qui a été tapé dans cette fenêtre est perdu. Si la vraie inquiétude est un tampon d’éditeur ou une migration longue, la solution est de cesser de lier ce travail à une seule connexion. tmux et un exécuteur de tâches résolvent des moitiés différentes de ce problème.

Un VPN reconnecté ne reprend pas le socket

TCP n’a aucune notion de reprise après un changement d’adresse. La connexion SSH est identifiée par ses deux extrémités, et lorsque le tunnel est reconstruit, l’adresse locale peut changer et l’ancien socket est mort. Le serveur le remarque finalement, mais votre terminal le remarque immédiatement.

Un keepalive côté client détecte un pair mort plus tôt. Il ne ramène pas la session, et il ne peut pas récupérer une commande qui tournait déjà. Le keepalive est un détecteur, pas un outil de récupération. Il ne dit rien sur le sort de la commande distante.

Placez le travail sur l’hôte distant

Créez la session sur l’hôte distant, pas sur l’ordinateur portable. Connectez-vous comme d’habitude, démarrez tmux là-bas et lancez l’éditeur ou la migration à l’intérieur. Détachez avec le préfixe par défaut et la session continue pendant que la connexion SSH disparaît. Démarrer tmux en local protège votre shell d’une fenêtre fermée, pas une commande distante d’un tunnel mort.

ssh [email protected]
tmux new-session -s office-work

Une fois le VPN revenu, ouvrez une nouvelle connexion SSH vers le même hôte et rattachez-vous par nom. L’objet durable est la session, pas la connexion. Donnez-lui un nom que vous reconnaîtrez encore une semaine plus tard.

tmux face à un exécuteur de tâches

tmux garde un processus interactif en vie tant que l’hôte tourne. Un exécuteur de tâches ou un gestionnaire de services garde une tâche non interactive en vie, consigne son code de sortie et survit à la fin complète de la session SSH. Le premier sert au travail que vous surveillez ; le second à celui que vous planifiez et inspectez plus tard.

Ni l’un ni l’autre ne survit à un redémarrage, sauf si l’hôte est configuré pour le restaurer. Une session tmux meurt avec la machine, et une tâche éphémère meurt avec le démarrage, sauf si elle a été enregistrée comme unité. Choisissez selon ce que le travail doit survivre.

Les deux approches ont aussi besoin d’un journal que vous pouvez lire après la reconnexion. Sans lui, vous savez que le processus existe, mais pas ce qu’il a fait. Notez le chemin du journal à côté du nom de la session.

Décidez selon ce qui doit survivre

Décidez selon le pire qui peut arriver si le travail s’arrête à mi-chemin. Une session d’éditeur perd les tampons non enregistrés, ce qui est contrariant mais récupérable. Une migration qui valide la moitié de ses changements ne l’est pas, et cela plaide pour un exécuteur au résultat consigné. Si la tâche est interactive et longue, tmux plus un journal écrit suffisent généralement.

systemd-run --user --unit=migrate-customers --collect ./migrate.sh

Quoi que vous choisissiez, inspectez le résultat consigné avant de relancer quoi que ce soit. Une dernière ligne manquante vous dit ce que l’ordinateur portable a vu, pas ce que le serveur a validé. Cette distinction est la raison de garder le travail hors de la connexion dès le départ, et le modèle de détachement et de rattachement en est la plus petite version.