چگونه فرایندها را در لینوکس متوقف یا بکشیم؟

فرایند گیرکرده، worker زامبی‌نما، یا اسکریپتی که CPU را بلعیده — وسوسه این است که فوراً `kill -9` بزنید. در لینوکس «کشتن» در واقع ارسال سیگنال (signal) است؛ شدت و پیامد هر سیگنال فرق دارد. انتخاب غلط می‌تواند تراکنش نیمه‌کاره، قفل فایل، یا حتی قطع جلسهٔ SSH خودتان را به‌دنبال داشته باشد.

این راهنما بعد از دیدن فرایند با ps/top می‌آید: ابتدا هویت PID را محکم کنید، سیگنال ملایم بفرستید، صبر کنید، و فقط در صورت نیاز به زور متوسل شوید. برای سرویس‌های تحت systemd، اغلب `systemctl stop/restart` درست‌تر از kill دستی است.

پاسخ کوتاه

ابتدا PID را با ps یا pgrep پیدا کنید. پیش‌فرض `kill PID` برابر SIGTERM (۱۵) است: از فرایند می‌خواهد تمیز خارج شود. اگر بعد از چند ثانیه نرفت، علت را بفهمید (انتظار I/O، فرزند، نادیده گرفتن سیگنال). SIGKILL (۹) قابل‌گرفتن نیست و فرایند را هسته قطع می‌کند — آخرین تیر، نه عادت روزانه. برای الگوی نام از `pkill`/`killall` با احتیاط و ترجیحاً با محدودیت کاربر استفاده کنید.

SIGKILL مثل قطع برق است؛ کار می‌کند، اما فرصت ذخیره و قفل‌آزادسازی را می‌گیرد.

سیگنال یعنی چه؟

سیگنال پیامی نرم‌افزاری از هسته یا فرایند دیگر است. برنامه‌ها می‌توانند بسیاری از سیگنال‌ها را بگیرند و واکنش نشان دهند (مثلاً ذخیره و خروج)، اما SIGKILL و SIGSTOP را نمی‌توانند نادیده بگیرند.

bash

kill -l

فهرست نام‌ها را ببینید؛ هم `-15` و هم `-TERM` معتبرند.

پیدا کردن هدف درست

bash

ps aux | grep '[n]ode' pgrep -a node pgrep -u www-data -l

قبل از kill بپرسید: این PID مال کدام کاربر است؟ PPID چیست؟ آیا زیر unit مربوط به systemd است؟ کشتن worker ممکن است supervisor را وادار به respawn کند — گاهی مطلوب، گاهی حلقهٔ کرش.

bash

ps -o pid,ppid,user,stat,cmd -p 1234 tr '\0' ' ' < /proc/1234/cmdline; echo ls -l /proc/1234/cwd

kill: سیگنال به یک PID

bash

kill 1234 kill -TERM 1234 kill -15 1234

هر سه در عمل SIGTERM می‌فرستند (اگر مجوز داشته باشید). اگر «Operation not permitted» دیدید، یا مالک فرایند نیستید یا به قابلیت لازم دسترسی ندارید — sudo فقط وقتی سیاست سازمان اجازه می‌دهد.

SIGKILL فقط وقتی لازم است

bash

kill -KILL 1234 # یا kill -9 1234

موارد موجه: فرایند در حالت D گیر کرده و به TERM جواب نمی‌دهد (گاهی حتی KILL هم فوری کمک نمی‌کند تا I/O آزاد شود)، یا بدافزار/آزمایشی که عمداً TERM را نادیده می‌گیرد. بعد از KILL، وضعیت قفل، فایل موقت و اتصال پایگاه را بررسی کنید.

pkill و killall: بر اساس نام

bash

pkill -u deploy node pkill -f 'celery worker' killall -u www-data nginx

`pkill` از الگوی فرایند استفاده می‌کند؛ `-f` کل خط فرمان را مقایسه می‌کند و خطرناک‌تر است چون ممکن است الگوی پهن چند چیز را بگیرد. همیشه اول خشک اجرا کنید:

bash

pgrep -a -u deploy node pkill -n -u deploy node # فقط جدیدترین، در صورت پشتیبانی

هرگز روی سرور مشترک `pkill -9 -f python` نزنید مگر دقیقاً بدانید چند تفسیر از «python» زنده است.

توقف و ادامه بدون کشتن

bash

kill -STOP 1234 kill -CONT 1234

مفید برای منجمد کردن موقت یک جاب سنگین تا منبع آزاد شود؛ فراموش کردن CONT یعنی جاب تا ابد معلق می‌ماند.

ترجیح systemd برای سرویس‌ها

اگر فرایند را unit مدیریت می‌کند، kill دستی اغلب با سیاست Restart= همیشه برمی‌گردد یا وابستگی‌ها را ناقص می‌گذارد.

bash

systemctl status nginx sudo systemctl stop nginx sudo systemctl restart nginx

برای فرستادن سیگنال از مسیر رسمی:

bash

sudo systemctl kill -s SIGTERM nginx sudo systemctl kill -s SIGKILL nginx # فقط اگر stop شکست خورد

ترتیب امن پیشنهادی

1. هویت PID را دوبار بررسی کنید (کاربر، cmdline، cwd، unit).
2. اگر سرویس است، stop/restart با systemctl.
3. وگرنه SIGTERM بفرستید و ۱۰–۳۰ ثانیه صبر کنید؛ با ps وضعیت را ببینید.
4. لاگ سرویس/journal را برای علت امتناع از خروج بخوانید.
5. SIGKILL را آگاهانه بزنید و پیامد داده/قفل را چک کنید.

bash

# نمونهٔ صبورانه kill -TERM 1234 sleep 5 ps -p 1234 || echo 'exited' # اگر هنوز هست: kill -KILL 1234

خطرهای واقعی

• kill کردن sshd یا جلسهٔ خودتان از راه دور بدون console جایگزین.
• pkill با الگوی کوتاه مثل `sh` یا `java` روی میزبان شلوغ.
• عادت به -9 که فساد داده در صف نوشتن را پنهان می‌کند.
• کشتن والد و رها کردن یتیمان در وضعیت نامشخص بدون فهم supervisor.

زامبی و فرایند D

وضعیت Z (زامبی) یعنی فرایند مرده و منتظر wait توسط والد است؛ کشتن زامبی معمولاً بی‌فایده است — والد یا init/systemd باید جمعش کند. وضعیت D اغلب منتظر I/O است؛ KILL ممکن است تا آزاد شدن دستگاه اثر نکند. ریشه را در دیسک، NFS یا درایور بجویید نه در اسپم کردن kill.

خلاصه

کشتن فرایند یعنی سیاست سیگنال: TERM اول، صبر، فهم، سپس KILL. برای سرویس‌های مدیریت‌شده مسیر systemctl را ترجیح دهید. نام‌محور بودن pkill قدرت و خطر همزمان دارد. بعد از خاتمهٔ اجباری، سلامت داده و restart ناخواسته را بررسی کنید.

سوالات متداول

چرا بعد از kill -9 هنوز در ps هست؟

ممکن است در همان لحظهٔ نمونه‌برداری بوده، PID بازیافت شده، یا فرایند در D گیر کرده. دوباره با `ps -p` چک کنید؛ اگر Z است مشکل والد است.

فرق killall و pkill؟

هر دو بر اساس نام کار می‌کنند؛ جزئیات تطبیق و گزینه‌ها در پیاده‌سازی procps فرق دارد. قبل از استفاده روی production، man همان ماشین را بخوانید و اول pgrep خشک بزنید.

آیا Ctrl+C همان kill است؟

Ctrl+C معمولاً SIGINT به گروه فرایند پیش‌زمینهٔ ترمینال می‌فرستد؛ معادل دقیق kill روی PID دلخواه نیست.

منابع و مراجع

• signal(7) — Linux manual: https://man7.org/linux/man-pages/man7/signal.7.html
• kill(1): https://man7.org/linux/man-pages/man1/kill.1.html
• pkill(1): https://man7.org/linux/man-pages/man1/pkill.1.html
• systemd.kill(5): https://www.freedesktop.org/software/systemd/man/latest/systemd.kill.html