A sesión SSH morre coa VPN: tmux ou un executor de tarefas?

O indicador da VPN ponse verde, a ruta volve, e a xanela SSH que deixou aberta nunca volve devolver o aviso de ordes. Restaurar unha ruta non restaura a conversa TCP que a usaba, así que todo o que se escribiu nesa xanela perdeuse. Se a preocupación real é un búfer do editor ou unha migración longa, a solución é deixar de atar ese traballo a unha soa conexión. tmux e un executor de tarefas resolven metades distintas dese problema.

Unha VPN reconectada non retoma o socket

TCP non ten noción de retomar tras un cambio de enderezo. A conexión SSH identifícase polos dous extremos, e cando o túnel se reconstrúe, o enderezo local pode cambiar e o vello socket está morto. O servidor nótao ao final, pero o seu terminal nótao de inmediato.

Un keepalive de cliente detecta un par morto antes. Non devolve a sesión, e non pode recuperar un comando que xa se estaba executando. O keepalive é un detector, non unha ferramenta de recuperación. Non di nada sobre se o comando remoto sobreviviu.

Pon o traballo no host remoto

Cree a sesión no host remoto, non no portátil. Conéctese como sempre, inicie tmux alí e execute o editor ou a migración dentro. Desengánchese co prefixo predeterminado e a sesión segue executándose mentres a conexión SSH desaparece. Iniciar tmux en local protexe a súa shell dunha xanela pechada, non un comando remoto dun túnel morto.

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

Cando volva a VPN, abra unha conexión SSH nova ao mesmo host e volva engancharse polo nome. O obxecto duradeiro é a sesión, non a conexión. Póñalle un nome que aínda recoñeza unha semana despois.

tmux fronte a un executor de tarefas

tmux mantén vivo un proceso interactivo mentres o host está aceso. Un executor de tarefas ou xestor de servizos mantén viva unha tarefa non interactiva, rexistra o seu estado de saída e sobrevive a que a sesión SSH remate por completo. O primeiro é para traballo que vostede observa; o segundo, para traballo que programa e inspecciona despois.

Ningún dos dous sobrevive a un reinicio a non ser que o host estea configurado para restauralo. Unha sesión de tmux morre coa máquina, e unha tarefa transitoria morre co arranque a non ser que se rexistrase como unidade. Elixa segundo o que o traballo deba sobrevivir.

Ambos enfoques tamén necesitan un rexistro que poida ler tras reconectarse. Sen un, sabe que o proceso existe, pero non que fixo. Anote a ruta do rexistro xunto ao nome da sesión.

Decida polo que debe sobrevivir

Decida polo peor que pode pasar se o traballo se detén a metade. Unha sesión de editor perde búfers sen gardar, o cal é molesto pero recuperable. Unha migración que confirma a metade dos seus cambios non o é, e iso avoga por un executor cun resultado rexistrado. Se a tarefa é interactiva e longa, tmux máis un rexistro escrito adoita abondar.

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

Escolla o que escolla, revise o resultado rexistrado antes de volver executar nada. Unha última liña que falta dille o que viu o portátil, non o que confirmou o servidor. Esa distinción é a razón para manter o traballo fóra da conexión desde o principio, e o modelo de desenganchar e volver enganchar é a versión máis pequena dela.