Сеанс 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

Хоч би що ви вибрали, перегляньте записаний результат, перш ніж щось перезапускати. Відсутній останній рядок говорить про те, що бачив ноутбук, а не про те, що зафіксував сервер. Саме ця різниця і є причина тримати роботу поза з'єднанням від самого початку, а модель від'єднання та повторного приєднання — її найменша версія.