Sesja SSH umiera razem z VPN: tmux czy runner zadań?

Wskaźnik VPN zmienia się na zielony, trasa wraca, a pozostawione otwarte okno SSH nigdy więcej nie zwraca znaku zachęty. Przywrócenie trasy nie przywraca rozmowy TCP, która z niej korzystała, więc wszystko, co wpisano w tym oknie, przepadło. Jeśli prawdziwym zmartwieniem jest bufor edytora albo długa migracja, rozwiązaniem jest przestać wiązać tę pracę z jednym połączeniem. tmux i runner zadań rozwiązują różne połowy tego problemu.

Ponownie połączony VPN nie wznawia gniazda

TCP nie ma pojęcia wznawiania po zmianie adresu. Połączenie SSH jest identyfikowane przez oba końce, a gdy tunel jest odbudowywany, adres lokalny może się zmienić i stare gniazdo jest martwe. Serwer zauważa to w końcu, ale twój terminal zauważa to natychmiast.

Keepalive po stronie klienta wykrywa martwego partnera wcześniej. Nie przywraca sesji i nie potrafi odzyskać polecenia, które już działało. Keepalive to detektor, a nie narzędzie odzyskiwania. Nic nie mówi o tym, czy zdalne polecenie przetrwało.

Umieść pracę na zdalnym hoście

Utwórz sesję na zdalnym hoście, a nie na laptopie. Połącz się jak zwykle, uruchom tam tmux i uruchom w nim edytor albo migrację. Odłącz się domyślnym prefiksem, a sesja działa dalej, gdy połączenie SSH znika. Uruchomienie tmux lokalnie chroni twoją powłokę przed zamkniętym oknem, a nie zdalne polecenie przed martwym tunelem.

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

Gdy VPN wróci, otwórz nowe połączenie SSH do tego samego hosta i dołącz ponownie po nazwie. Trwałym obiektem jest sesja, a nie połączenie. Nadaj jej nazwę, którą rozpoznasz jeszcze po tygodniu.

tmux kontra runner zadań

tmux utrzymuje proces interaktywny przy życiu, dopóki host jest włączony. Runner zadań lub menedżer usług utrzymuje przy życiu zadanie nieinteraktywne, zapisuje jego status wyjścia i przeżywa całkowite zakończenie sesji SSH. Pierwszy jest dla pracy, którą obserwujesz; drugi dla pracy, którą planujesz i później sprawdzasz.

Żadne z nich nie przeżywa restartu, chyba że host jest skonfigurowany, by je odtworzyć. Sesja tmux umiera wraz z maszyną, a zadanie tymczasowe umiera wraz z rozruchem, chyba że zarejestrowano je jako jednostkę. Wybieraj według tego, co praca musi przetrwać.

Oba podejścia potrzebują też dziennika, który możesz przeczytać po ponownym połączeniu. Bez niego wiesz, że proces istnieje, ale nie co zrobił. Zapisz ścieżkę dziennika obok nazwy sesji.

Decyduj według tego, co musi przetrwać

Decyduj według najgorszego, co może się stać, jeśli praca zatrzyma się w połowie. Sesja edytora traci niezapisane bufory, co jest irytujące, ale odtwarzalne. Migracja, która zatwierdza połowę swoich zmian, nie jest, i to przemawia za runnerem z zapisanym wynikiem. Jeśli zadanie jest interaktywne i długie, tmux plus zapisany dziennik zwykle wystarcza.

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

Cokolwiek wybierzesz, sprawdź zapisany wynik, zanim cokolwiek uruchomisz ponownie. Brakująca ostatnia linia mówi ci, co widział laptop, a nie co zatwierdził serwer. Ta różnica jest powodem trzymania pracy poza połączeniem od samego początku, a model odłączania i ponownego dołączania jest jego najmniejszą wersją.