نشست 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

هر چه انتخاب کنید، پیش از اجرای دوبارهٔ هر چیزی نتیجهٔ ثبت‌شده را بررسی کنید. نبودِ خط آخر به شما می‌گوید لپ‌تاپ چه دید، نه اینکه سرور چه ثبت کرد. همین تفاوت دلیل نگه‌داشتن کار بیرون از اتصال از همان ابتدا است، و مدل جدا شدن و دوباره متصل شدن کوچک‌ترین شکل آن است.