آموزش

tmux: اجرای کار طولانی روی سرور بدون قطع شدن

اگر با بستن SSH دستور طولانی‌ات می‌میرد، اینجا یاد می‌گیری با tmux جلسهٔ ماندگار بسازی، دوباره وصل شوی و کار را زنده نگه داری.

آموزش

دستور mysqldump را زده‌ای، نوار پیشرفت آرام جلو می‌رود، و لپ‌تاپ روی باتری است. وای‌فای یک لحظه قطع می‌شود. دوباره وصل می‌شوی و می‌بینی پروسه مرده و فایل دامپ نصفه مانده. این دقیقاً همان جایی است که tmux وارد می‌شود: یک برنامهٔ کوچک که یک شل را داخل یک جلسهٔ مستقل از ترمینال تو نگه می‌دارد. وقتی SSH قطع شود، جلسه می‌ماند و دستور هم می‌ماند.

تفاوت را با nohup و & بگویم چون خیلی‌ها این دو را قاطی می‌کنند. nohup فقط جلوی سیگنال HUP را می‌گیرد و پروسه را از ترمینال جدا می‌کند، اما دیگر نمی‌توانی وسط کار به آن نگاه کنی یا ورودی بدهی. tmux یک ترمینال واقعی به تو می‌دهد که می‌توانی هر وقت خواستی برگردی داخلش. برای کارهایی مثل مهاجرت دیتابیس، rsync روی صد گیگ فایل، یا بیلد طولانی، این تفاوت حیاتی است.

چرا اجرای مستقیم دستور با قطع SSH می‌میرد

وقتی از طریق SSH وارد می‌شوی، شل تو یک فرزند از سشن SSH است. لحظه‌ای که اتصال قطع می‌شود، کرنل به پروسه‌های آن ترمینال سیگنال SIGHUP می‌فرستد. پروسه‌های پیش‌زمینه این سیگنال را می‌گیرند و می‌میرند. اگر خوش‌شانس باشی فقط کار نیمه‌کاره می‌ماند؛ اگر بدشانس باشی، یک جدول دیتابیس در حالت نیمه‌مهاجرت گیر می‌کند و باید از بکاپ برگردانی.

علامتش هم مشخص است: بعد از قطع و وصل، ps aux | grep mysqldump هیچ چیزی برنمی‌گرداند و لاگ خطایی هم نداری. فقط یک فایل ناقص روی دیسک مانده.

ساخت اولین جلسهٔ ماندگار با tmux

روی اکثر توزیع‌ها نصب است. اگر نبود:

apt install tmux        # دبیان و اوبونتو
dnf install tmux        # ردهت و فدورا

حالا یک جلسه با نام مشخص بساز. نام‌گذاری را جدی بگیر؛ وقتی سه جلسه باز داری، tmux ls بدون نام فقط یک مشت عدد بی‌معنی نشانت می‌دهد.

tmux new -s backup

وارد جلسه می‌شوی. دستور طولانی‌ات را همان‌جا بزن. حالا کلید ترکیبی Ctrl+b و بعد d را بزن تا از جلسه جدا (detach) شوی. جلسه در پس‌زمینه زنده می‌ماند. برای برگشتن:

tmux attach -t backup

اگر اسم جلسه را فراموش کردی، tmux ls لیست را می‌دهد و با tmux attach -t 0 به شمارهٔ صفر وصل می‌شوی. همین. تمام کاری که برای زنده ماندن یک بکاپ شش‌ساعته لازم داشتی انجام شد.

کلیدهایی که واقعاً استفاده می‌کنی

همهٔ دستورهای tmux با یک پیشوند شروع می‌شوند که پیش‌فرضش Ctrl+b است. این چند تا را حفظ کن، بقیه را لازم نداری:

  • Ctrl+b سپس d — جدا شدن از جلسه بدون بستن آن
  • Ctrl+b سپس c — ساخت پنجرهٔ جدید داخل همان جلسه
  • Ctrl+b سپس n و p — پنجرهٔ بعدی و قبلی
  • Ctrl+b سپس % — تقسیم عمودی پنل
  • Ctrl+b سپس " — تقسیم افقی پنل
  • Ctrl+b سپس [ — ورود به حالت اسکرول برای دیدن خروجی قبلی

حالت اسکرول را دست‌کم نگیر. وقتی یک بیلد هزار خط لاگ تولید می‌کند و تو فقط می‌خواهی خطای وسطش را ببینی، بدون این حالت باید لاگ را در فایل ذخیره می‌کردی. با Ctrl+b [ وارد می‌شوی، با کلیدهای جهت حرکت می‌کنی و با q بیرون می‌آیی.

این‌جا اشتباه می‌کنند

رایج‌ترین اشتباهی که در تیکت‌های پشتیبانی می‌بینم این است: کاربر داخل tmux کار می‌کند، بعد پنجرهٔ ترمینال را با کلیک روی ضربدر می‌بندد و فکر می‌کند جلسه در سرور مانده. در بعضی ترمینال‌ها این کار به‌جای detach، یک SIGHUP واقعی می‌فرستد و جلسه را می‌کشد. علامتش این است که tmux ls می‌گوید no server running on /tmp/tmux-1000/default و تو فکر می‌کنی سرور ریست شده.

عادت درست این است: همیشه اول Ctrl+b d بزن، بعد ترمینال را ببند. اگر مطمئن نیستی، بعد از detach یک بار دیگر SSH بزن و tmux ls را چک کن.

اشتباه دوم: اجرای دستور با sudo داخل جلسهٔ کاربر عادی. جلسهٔ tmux به همان کاربری تعلق دارد که آن را ساخته. اگر با sudo -u www-data tmux new -s deploy جلسه بسازی، بعداً با کاربر خودت نمی‌توانی به آن attach کنی و خطای no sessions می‌گیری. برای کارهای سرویس‌محور، جلسه را با همان کاربر مالک بساز.

tmux یا screen یا systemd؟

هر سه کار مشابهی می‌کنند و انتخاب بین‌شان به موقعیت بستگی دارد، نه به سلیقه.

ابزارکجا انتخاب درستی استهزینه‌اش
tmuxکار تعاملی، دیباگ زنده، چند پنل کنار همباید دستی مدیریتش کنی؛ بعد از ریبوت سرور جلسه برنمی‌گردد
screenسرورهای قدیمی که tmux نصب نیستکلیدهایش گیج‌کننده‌تر است و توسعه‌اش عملاً متوقف شده
systemd serviceکاری که باید خودکار بالا بیاید و بعد از ریبوت ادامه دهدبرای کار یک‌بارهٔ دستی زیادی سنگین است

انتخاب من برای کار روزمرهٔ روی سرور tmux است. اما اگر کاری قرار است هر شب ساعت سه اجرا شود و بعد از ریبوت هم باید برگردد، tmux پاسخ غلطی است؛ آنجا یک unit فایل systemd با Restart=on-failure بنویس. tmux برای «همین حالا، دستی، تا وقتی تمام شود» ساخته شده.

یک محدودیت واقعی هم بگویم که کمتر کسی از قبل می‌داند: جلسه‌های tmux بعد از ریبوت سرور از بین می‌روند. اگر سرور ریست شود، همهٔ جلسه‌ها می‌روند. برای کارهایی که ساعت‌ها طول می‌کشند و ریسک ریبوت دارند، خروجی را همیشه با tee در فایل بریز:

mysqldump -u root -p shop | gzip > /root/shop-$(date +%F).sql.gz

این‌طور حتی اگر جلسه بمیرد، می‌دانی تا کجا پیش رفته و می‌توانی ادامه بدهی.

تنظیمات کوچکی که تجربه را عوض می‌کند

فایل ~/.tmux.conf را بساز و این چند خط را داخلش بگذار:

set -g mouse on
set -g history-limit 50000
set -g base-index 1
setw -g pane-base-index 1

خط اول اسکرول با ماوس و انتخاب پنل با کلیک را فعال می‌کند. خط دوم بافر تاریخچه را از پیش‌فرض ۲۰۰۰ خط به ۵۰۰۰۰ خط می‌برد؛ برای لاگ‌های طولانی این عدد را لازم داری. دو خط آخر شماره‌گذاری پنجره‌ها را از صفر به یک می‌برند که برای اکثر آدم‌ها طبیعی‌تر است. بعد از ذخیره، با tmux source-file ~/.tmux.conf اعمالش کن.

اگر روی یک سرور اشتراکی کار می‌کنی و چند نفر باید یک جلسه را ببینند، tmux این را هم دارد: با tmux new -s shared جلسه بساز و بقیه با tmux attach -t shared وارد همان جلسه شوند. هر دو نفر یک تصویر می‌بینند و هر دو می‌توانند تایپ کنند. برای دیباگ مشترک روی یک مشکل، این از اشتراک‌گذاری اسکرین سریع‌تر است.

اگر تازه سرور را راه انداخته‌ای و هنوز محیط را آماده نکرده‌ای، قبل از هر چیز یک نگاه به مستندات و پایگاه دانش بینداز؛ چک‌لیست‌های اولیهٔ سرور آنجا جمع شده. برای کارهای سبک‌تر مثل تست دستورها یا بررسی DNS، ابزارهای رایگان بدون نیاز به SSH کارت را راه می‌اندازند. و اگر کل کارت روی یک سایت وردپرسی است و نمی‌خواهی درگیر مدیریت جلسه‌های شل شوی، هاست وردپرس سرورنت این لایه را از دوشت برمی‌دارد.

یک نکتهٔ آخر دربارهٔ سرورهایی که تازه بالا آمده‌اند: اگر بعد از نصب، سایت بالا نمی‌آید و مطمئن نیستی مشکل از DNS است یا از سرویس، اول خطای DNS_PROBE_FINISHED_NXDOMAIN را چک کن، چون در نیمی از موارد مشکل اصلاً سمت سرور نیست.

پرسش‌های پرتکرار

چطور بفهمم دستورم داخل tmux هنوز در حال اجراست؟

با tmux ls لیست جلسه‌های زنده را می‌بینی و با tmux attach -t نام واردش می‌شوی و خروجی زنده را می‌بینی. اگر جلسه در لیست نبود، یعنی یا detach نشده و با قطع SSH مرده، یا سرور ریبوت شده است.

آیا بعد از ریبوت سرور جلسه‌های tmux برمی‌گردند؟

نه. جلسه‌های tmux در حافظهٔ سرور زندگی می‌کنند و با ریبوت از بین می‌روند. اگر کاری باید بعد از ریبوت هم ادامه پیدا کند، باید آن را به‌صورت یک سرویس systemd تعریف کنی، نه یک جلسهٔ tmux.

تفاوت tmux و nohup در چیست؟

nohup فقط پروسه را از سیگنال قطع ترمینال جدا می‌کند و بعد از آن دیگر نمی‌توانی داخلش بروی یا ورودی بدهی. tmux یک ترمینال کامل و قابل برگشت می‌دهد که می‌توانی هر لحظه attach کنی، اسکرول کنی و دستور جدید بزنی.

چرا بعد از attach کردن، صفحه به‌هم‌ریخته نشان داده می‌شود؟

این معمولاً وقتی رخ می‌دهد که اندازهٔ ترمینال فعلی با اندازهٔ لحظهٔ ساخت جلسه فرق دارد. با Ctrl+b و بعد : وارد خط فرمان tmux شو و resize-window -A را اجرا کن، یا ساده‌تر پنجرهٔ ترمینال را یک بار کوچک و بزرگ کن تا خودش هم‌اندازه شود.

پشتیبانی سرورنت

تیم فنی و تحریریه‌ی سرورنت — تخصص در زیرساخت، شبکه و میزبانی وب.

هاست وردپرس
اشتراک‌گذاری:

دیدگاه‌ها ۰

هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!

دیدگاه خود را بنویسید

سرویس مرتبط

هاست وردپرس

استک اختصاصی وردپرس با LiteSpeed Enterprise و NVMe — نصب خودکار، آپدیت امن، استیجینگ و کشی که سایت شما را در صدر نتایج گوگل نگه می‌دارد.