SSH сесията умира с VPN: tmux или изпълнител на задачи?

Индикаторът на VPN става зелен, маршрутът се връща, а SSH прозорецът, който оставихте отворен, така и не връща подкана. Възстановяването на път не възстановява TCP разговора, който го използваше, затова всичко, написано в онзи прозорец, е изгубено. Ако истинската грижа е буфер на редактор или дълга миграция, решението е да спрете да обвързвате тази работа с една връзка. tmux и изпълнител на задачи решават различни половини от този проблем.

Възстановеният VPN не подновява сокета

TCP не познава подновяването след промяна на адреса. SSH връзката се идентифицира по двата крайни пункта и когато тунелът се изгради наново, локалният адрес може да се промени и старият сокет е мъртъв. Сървърът забелязва това в крайна сметка, но терминалът ви го забелязва веднага.

Клиентско задържане на връзката открива мъртъв отсрещен край по-рано. То не връща сесията и не може да възстанови команда, която вече е работила. Задържането на връзката е детектор, а не средство за възстановяване. То не казва нищо за това дали отдалечената команда е оцеляла.

Сложете работата на отдалечения хост

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

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

След като VPN се върне, отворете нова SSH връзка към същия хост и се прикачете по име. Трайният обект е сесията, а не връзката. Дайте ѝ име, което ще разпознаете и след седмица.

tmux срещу изпълнител на задачи

tmux поддържа интерактивен процес жив, докато хостът работи. Изпълнител на задачи или мениджър на услуги поддържа неинтерактивна задача жива, записва статуса ѝ при изход и оцелява при пълното приключване на SSH сесията. Първото е за работа, която наблюдавате; второто е за работа, която планирате и после проверявате.

Нито едно от двете не оцелява при рестарт, освен ако хостът не е настроен да го възстанови. tmux сесията умира с машината, а краткотрайната задача умира при зареждането, освен ако не е регистрирана като unit. Избирайте според това, което работата трябва да надживее.

И двата подхода се нуждаят и от дневник, който можете да прочетете след повторното свързване. Без него знаете, че процесът съществува, но не какво е направил. Запишете пътя до дневника до името на сесията.

Решавайте по това, което трябва да оцелее

Решавайте по най-лошото, което може да се случи, ако работата спре по средата. Сесия на редактор губи незапазени буфери, което е досадно, но възстановимо. Миграция, която фиксира половината от промените си, не е, и това говори за изпълнител със записан резултат. Ако задачата е интерактивна и дълга, tmux плюс записан дневник обикновено е достатъчно.

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

Каквото и да изберете, прегледайте записания резултат, преди да пуснете нещо отново. Липсващият последен ред ви казва какво е видял лаптопът, а не какво е фиксирал сървърът. Тази разлика е причината да държите работата извън връзката от самото начало, а моделът на откачване и прикачване е най-малката ѝ форма.