A sessão SSH morre com a VPN: tmux ou um executor de tarefas?

O indicador da VPN fica verde, a rota está de volta, e a janela SSH que deixou aberta nunca mais devolve o prompt. Restaurar uma rota não restaura a conversa TCP que a usava, por isso tudo o que foi escrito nessa janela perdeu-se. Se a verdadeira preocupação é um buffer do editor ou uma migração longa, a solução é deixar de prender esse trabalho a uma só ligação. tmux e um executor de tarefas resolvem metades diferentes desse problema.

Uma VPN reconectada não retoma o socket

O TCP não tem noção de retomar depois de uma mudança de endereço. A ligação SSH é identificada por ambas as extremidades, e quando o túnel é reconstruído o endereço local pode mudar e o antigo socket está morto. O servidor nota-o ao fim de algum tempo, mas o seu terminal nota-o de imediato.

Um keepalive do lado do cliente deteta um par morto mais cedo. Não devolve a sessão, e não consegue recuperar um comando que já estava a correr. O keepalive é um detetor, não uma ferramenta de recuperação. Não diz nada sobre se o comando remoto sobreviveu.

Ponha o trabalho no anfitrião remoto

Crie a sessão no anfitrião remoto, não no portátil. Ligue-se como habitualmente, inicie aí o tmux e execute o editor ou a migração dentro dele. Desligue-se com o prefixo predefinido e a sessão continua a correr enquanto a ligação SSH desaparece. Iniciar o tmux localmente protege a sua shell de uma janela fechada, não um comando remoto de um túnel morto.

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

Quando a VPN voltar, abra uma nova ligação SSH ao mesmo anfitrião e volte a ligar-se pelo nome. O objeto duradouro é a sessão, não a ligação. Dê-lhe um nome que ainda reconheça uma semana depois.

tmux contra um executor de tarefas

O tmux mantém vivo um processo interativo enquanto o anfitrião estiver ligado. Um executor de tarefas ou gestor de serviços mantém viva uma tarefa não interativa, registando o seu estado de saída, e sobrevive ao fim completo da sessão SSH. O primeiro serve para trabalho que observa; o segundo para trabalho que agenda e inspeciona mais tarde.

Nenhum dos dois sobrevive a um reinício, a menos que o anfitrião esteja configurado para o restaurar. Uma sessão tmux morre com a máquina, e uma tarefa transitória morre com o arranque, a menos que tenha sido registada como unidade. Escolha em função do que o trabalho tem de sobreviver.

Ambas as abordagens precisam também de um registo que possa ler depois de se reconectar. Sem ele, sabe que o processo existe, mas não o que fez. Anote o caminho do registo ao lado do nome da sessão.

Decida em função do que tem de sobreviver

Decida em função da pior coisa que pode acontecer se o trabalho parar a meio. Uma sessão de editor perde buffers não guardados, o que é irritante mas recuperável. Uma migração que confirma metade das suas alterações não o é, e isso defende um executor com um resultado registado. Se a tarefa é interativa e longa, tmux mais um registo escrito costuma bastar.

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

Escolha o que escolher, inspecione o resultado registado antes de voltar a executar seja o que for. Uma última linha em falta diz-lhe o que o portátil viu, não o que o servidor confirmou. Essa distinção é a razão para manter o trabalho fora da ligação desde o início, e o modelo de desligar e voltar a ligar é a versão mais pequena disso.