Сеанс SSH умирает вместе с VPN: tmux или исполнитель заданий?

Индикатор VPN становится зелёным, маршрут возвращается, а окно SSH, которое вы оставили открытым, так и не возвращает приглашение. Восстановление маршрута не восстанавливает разговор TCP, который его использовал, поэтому всё, что было набрано в том окне, потеряно. Если настоящая забота — буфер редактора или долгая миграция, решение в том, чтобы перестать привязывать эту работу к одному соединению. tmux и исполнитель заданий решают разные половины этой проблемы.

Переподключённый VPN не возобновляет сокет

У TCP нет понятия возобновления после смены адреса. Соединение SSH определяется обоими концами, и когда туннель перестраивается, локальный адрес может измениться, а старый сокет мёртв. Сервер замечает это в конце концов, а ваш терминал замечает сразу.

Клиентский keepalive обнаруживает мёртвого партнёра раньше. Он не возвращает сеанс и не может восстановить команду, которая уже выполнялась. Keepalive — это детектор, а не средство восстановления. Он ничего не говорит о том, выжила ли удалённая команда.

Поместите работу на удалённый хост

Создайте сеанс на удалённом хосте, а не на ноутбуке. Подключитесь как обычно, запустите там tmux и запустите редактор или миграцию внутри него. Отсоединитесь префиксом по умолчанию, и сеанс продолжает работать, пока соединение SSH исчезает. Локальный запуск tmux защищает вашу оболочку от закрытого окна, а не удалённую команду от мёртвого туннеля.

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

Когда VPN вернётся, откройте новое соединение SSH к тому же хосту и подключитесь заново по имени. Долговечный объект — сеанс, а не соединение. Дайте ему имя, которое вы узнаете и через неделю.

tmux против исполнителя заданий

tmux поддерживает интерактивный процесс живым, пока хост включён. Исполнитель заданий или менеджер служб поддерживает неинтерактивное задание живым, записывает статус его выхода и переживает полное завершение сеанса SSH. Первый — для работы, за которой вы наблюдаете; второй — для работы, которую вы планируете и проверяете позже.

Ни один не переживает перезагрузку, если хост не настроен его восстанавливать. Сеанс tmux умирает вместе с машиной, а краткое задание умирает вместе с загрузкой, если оно не было зарегистрировано как единица. Выбирайте по тому, что работа должна пережить.

Обоим подходам нужен ещё журнал, который можно прочитать после повторного подключения. Без него вы знаете, что процесс существует, но не что он сделал. Запишите путь к журналу рядом с именем сеанса.

Решайте по тому, что должно выжить

Решайте по худшему, что может случиться, если работа остановится на полпути. Сеанс редактора теряет несохранённые буферы, что неприятно, но восстановимо. Миграция, которая фиксирует половину своих изменений, — нет, и это говорит в пользу исполнителя с записанным результатом. Если задание интерактивно и долго, tmux плюс записанный журнал обычно достаточно.

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

Что бы вы ни выбрали, просмотрите записанный результат, прежде чем что-то перезапускать. Отсутствующая последняя строка говорит о том, что видел ноутбук, а не о том, что зафиксировал сервер. Именно это различие и есть причина держать работу вне соединения с самого начала, а модель отсоединения и повторного присоединения — его наименьшая версия.