FutureForgeFutureForge

خدمات FutureForge

  • طراحی و ساخت محصولاز شناخت نیاز تا انتشار محصول، یک مسیر روشن پیش رو دارید.
  • توسعه فول‌استکوب‌اپلیکیشن، API و داده را هماهنگ و یکپارچه توسعه دهید.
  • ممیزی مهندسیپیش از هزینه‌ی بیشتر، از وضعیت واقعی محصول‌تان باخبر شوید.
  • مشاوره معماریپیش از یک تصمیم فنی پرهزینه، گزینه‌ها را درست بسنجید.
  • زیرساخت و استقرارمحصول را با خیال راحت منتشر کنید و پایدار نگه دارید.
  • هوش مصنوعی در محصولهوش مصنوعی را فقط جایی به کار می‌گیریم که مسئله‌ای را حل کند.
نمونه‌کارهایادداشت‌هاقیمت‌گذاریدرباره ما
شروع گفتگو
  1. خانه
  2. /یادداشت‌ها
  3. /یادداشت‌ها
FutureForge

استودیوی مهندسی محصول — طراحی، ساخت و استقرار نرم‌افزار.

خدمات

طراحی سایت با وردپرستوسعه اختصاصیمهندسی محصولزیرساخت و استقرارمشاوره معماریهوش مصنوعی در محصول

راهنمای انتخاب

یادداشت‌هاقیمت‌گذاریتخمین هزینه پروژهمقایسه روش‌هانمونه‌کارهادرباره ماتماس

ارتباط

hello@futureforge.ir

ایده‌ای برای ساخت دارید؟

نیازتان را مطرح کنید تا درباره مسیر توسعه و قدم بعدی صحبت کنیم.

شروع گفتگو

© 2026 FutureForge. همه حقوق محفوظ است.

حریم خصوصیشرایط استفاده
خانهنمونه‌کارشروعتماس
عملیات و استقرار

فرایند در لینوکس چیست؟ PID، والد و چرخهٔ حیات

سا
سهیل ابراهیم‌پور
·۲۹ شهریور ۱۴۰۵·10 دقیقه مطالعه
فرایند لینوکسPIDPPIDsignalzombieniceness/procsystemd service
مانیتور پروسس شبیه htop و استیکی PID

مفهوم process در لینوکس: PID، والد، وضعیت‌ها، سیگنال‌ها، زومبی، و رابطه با سرویس — با man credentials و proc.

هر برنامه‌ای که روی لینوکس در حال اجرا می‌بینید، در قالب یک یا چند فرایند (process) توسط هسته مدیریت می‌شود. فرایند هویت اجرایی دارد: PID، کاربر، حافظه، فایل‌های باز، و وضعیت زمان‌بندی. بدون این مدل ذهنی، خروجی ps و top جدول شلوغی است و kill مثل دکمهٔ تصادفی.

این مقاله مفهوم فرایند، درخت والد-فرزند، وضعیت‌ها، سیگنال‌ها، و تفاوت با «سرویس systemd» را می‌سازد. ابزارهای مشاهده در ۱۵۲ و کشتن امن در ۱۵۳ می‌آیند؛ اینجا پایه است.

صفحات credentials(7) و proc(5) نشان می‌دهند هویت و نمایش /proc چگونه به فرایند گره خورده‌اند.

جدول وایت‌برد PID PPID STATE CPU MEMORY

پاسخ کوتاه

فرایند نمونهٔ در حال اجرای برنامه است با PID یکتا در آن فضای نام. هر فرایند معمولاً والدی دارد (PPID). هسته زمان CPU و حافظه را بین فرایندها تقسیم می‌کند. برای توقف مؤدبانه SIGTERM و برای اجبار SIGKILL رایج است. سرویس systemd یک یا چند فرایند را تحت واحد مدیریت می‌کند؛ کشتن فقط pid بدون فهم واحد، ممکن است توسط مدیر سرویس دوباره زنده شود یا ناقص بماند.

PID آدرس موقت است؛ سرویس قرارداد ماندگار. اول بفهمید با کدام حرف می‌زنید.

PID، PPID و درخت

PID شناسهٔ فرایند است. بعد از پایان، ممکن است بعداً دوباره استفاده شود — بنابراین لاگ قدیمی PID را ابدی ندانید. PPID والد را نشان می‌دهد. درخت فرایند کمک می‌کند بفهمید چه چیزی چه چیزی را ساخته؛ در عیب‌یابی کرشهای زنجیره‌ای مفید است.

bash

echo $$ ps -o pid,ppid,user,cmd -p $$ pstree -p | head

هویت و مجوز اجرا

فرایند با uid/gid مؤثر به فایل‌ها و سیگنال‌ها دسترسی دارد. به همین دلیل سرویس را با کاربر جدا اجرا می‌کنید. قابلیت‌های هسته (capabilities) می‌توانند بخشی از قدرت root را بدون uid ۰ بدهند — موضوع پیشرفته‌تر، ولی بدانید «غیرroot» همیشه به معنی بی‌قدرت نیست.

وضعیت‌های رایج

  • Running / Runnable: در حال اجرا یا آمادهٔ CPU.
  • Sleeping: منتظر رویداد یا IO.
  • Stopped: متوقف با سیگنال (مثلاً Ctrl+Z).
  • Zombie: تمام شده ولی والد wait نکرده؛ باقیماندهٔ جدول فرایند.

زومبی را با kill معمولاً نمی‌شود پاک کرد؛ والد باید wait کند یا خودش تمام شود. ترس از زومبی بدون دیدن تعداد و والد، معمولاً اغراق است؛ چند زومبی کوتاه‌عمر عادی‌تر از یک نشت بزرگ است.

سیگنال‌ها

سیگنال پیام نرم به فرایند است. SIGINT (Ctrl+C)، SIGTERM برای خاتمهٔ مؤدبانه، SIGKILL غیرقابل‌گرفتن برای اجبار، SIGHUP گاهی برای reload پیکربندی. برنامه‌ای که SIGTERM را درست پیاده کند، اتصال‌ها را می‌بندد؛ SIGKILL بلافاصله می‌بُرد.

جزئیات فرمان kill در ۱۵۳ است؛ اینجا اصل را بدانید: اول مؤدبانه، بعد اجبار، و روی سرویس‌های production ترجیحاً از systemctl stop.

فرایند در برابر سرویس و کانتینر

systemd واحد سرویس را تعریف می‌کند: کدام باینری، کدام کاربر، وابستگی‌ها، سیاست restart. ممکن است یک سرویس چند فرایند کارگر داشته باشد. در کانتینر، فضای نام PID جداست؛ pid 1 داخل کانتینر نقش ویژه‌ای در دریافت سیگنال دارد. Image بدون init مناسب گاهی سیگنال توقف را به اپ نمی‌رساند.

/proc به‌عنوان پنجره

برای هر PID مسیر /proc/PID اطلاعات cmdline، محیط، fdها و وضعیت را نشان می‌دهد. ابزارهای سطح بالا همان را می‌خوانند. کنجکاوی مفید است؛ دستکاری خام بدون دانش می‌تواند گمراه‌کننده باشد.

bash

ps -p 1 -o pid,cmd ls /proc/$$/fd | head tr '\0' ' ' < /proc/$$/cmdline; echo

جدول مفاهیم

مفهوممعنی عملیابزار بعدی
PIDشناسهٔ اجراps, top
PPIDوالدpstree
سیگنالکنترل خاتمه/reloadkill, systemctl
زومبیورودی تمام‌شدهٔ منتظر waitبررسی والد
سرویسواحد مدیریت‌شدهsystemctl

اشتباه‌های رایج

  • کشتن pid قدیمی که حالا به فرایند دیگر تعلق دارد.
  • فرض اینکه بستن ترمینال همیشه همهٔ فرزندان را می‌کشد (tmux/nohup/systemd فرق دارد).
  • نادیده گرفتن کاربر فرایند هنگام عیب‌یابی مجوز.
  • استفاده از SIGKILL به‌عنوان اولین گزینه.
  • یکی‌گرفتن «چند فرایند جاوا» با نشت لزومی بدون متریک.

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

thread همان process است؟

در لینوکس threadها سبک‌اند و در همان گروه مرتبط دیده می‌شوند؛ جزئیات را در مستند ps و /proc ببینید. برای شروع، فرایند را واحد اصلی عیب‌یابی بدانید.

چرا بعد از kill سرویس برگشت؟

احتمالاً systemd یا supervisord دوباره راهش انداخته. واحد را stop کنید.

PID 1 چیست؟

روی میزبان کلاسیک، init/systemd. داخل کانتینر، فرایند اصلی Image.

nice چیست؟

اولویت نسبی زمان‌بندی. برای کار روزمرهٔ وب کمتر از دیدن CPU داغ فوری است.

چطور بفهمم کدام فرایند پورت را گرفته؟

با ss یا lsof در مقالات شبکه/پورت؛ مدل فرایند اینجا پایهٔ خواندن آن خروجی است.

پل به ابزارهای بعدی

با دانستن PID و سیگنال، ps و top معنی‌دار می‌شوند (۱۵۲). با دانستن تفاوت سرویس و فرایند، kill را عاقلانه می‌زنید (۱۵۳). با systemd، به‌جای مدیریت دستی همیشگی، واحد تعریف می‌کنید (۱۵۴–۱۵۵).

سناریو و نکتهٔ تکمیلی (1)

فرایندها منابع را مصرف می‌کنند و بدون مشاهده، ظرفیت سرور در تاریکی تمام می‌شود. عادت کنید قبل از مقیاس‌کردن عمودی، ببینید کدام pid CPU، حافظه یا IO را می‌خورد. ابزارهای ps و top و در مقالهٔ بعد htop، همان ذره‌بین‌اند.

سیگنال‌ها زبان مؤدبانه تا قاطع برای توقف فرایندند. SIGTERM فرصت پاکسازی می‌دهد؛ SIGKILL آخرین ضربه است. در واحدهای systemd همین تمایز در TimeoutStopSec دیده می‌شود. کشتن کور همهٔ هم‌نام‌ها می‌تواند فرایند بی‌گناه را از بین ببرد.

زومبی و یتیم را با فهم والد و wait معنی کنید نه با وحشت. زومبی معمولاً نشانهٔ والد بد است. در کانتینر، فرایند pid 1 مسئولیت خاصی دارد؛ Image بد بدون init مناسب سیگنال را درست جلو نمی‌دهد.

برای سرویسهای تولید، مدیریت طول عمر را به systemd یا ارکستراسیون بسپارید نه به شِل دستی همیشگی. شِل برای عیب‌یابی است؛ نگه داشتن اپ با nohup روی session شخصی بدهی عملیاتی می‌سازد.

سناریو و نکتهٔ تکمیلی (2)

فرایندها منابع را مصرف می‌کنند و بدون مشاهده، ظرفیت سرور در تاریکی تمام می‌شود. عادت کنید قبل از مقیاس‌کردن عمودی، ببینید کدام pid CPU، حافظه یا IO را می‌خورد. ابزارهای ps و top و در مقالهٔ بعد htop، همان ذره‌بین‌اند.

سیگنال‌ها زبان مؤدبانه تا قاطع برای توقف فرایندند. SIGTERM فرصت پاکسازی می‌دهد؛ SIGKILL آخرین ضربه است. در واحدهای systemd همین تمایز در TimeoutStopSec دیده می‌شود. کشتن کور همهٔ هم‌نام‌ها می‌تواند فرایند بی‌گناه را از بین ببرد.

زومبی و یتیم را با فهم والد و wait معنی کنید نه با وحشت. زومبی معمولاً نشانهٔ والد بد است. در کانتینر، فرایند pid 1 مسئولیت خاصی دارد؛ Image بد بدون init مناسب سیگنال را درست جلو نمی‌دهد.

برای سرویسهای تولید، مدیریت طول عمر را به systemd یا ارکستراسیون بسپارید نه به شِل دستی همیشگی. شِل برای عیب‌یابی است؛ نگه داشتن اپ با nohup روی session شخصی بدهی عملیاتی می‌سازد.

سناریو و نکتهٔ تکمیلی (3)

فرایندها منابع را مصرف می‌کنند و بدون مشاهده، ظرفیت سرور در تاریکی تمام می‌شود. عادت کنید قبل از مقیاس‌کردن عمودی، ببینید کدام pid CPU، حافظه یا IO را می‌خورد. ابزارهای ps و top و در مقالهٔ بعد htop، همان ذره‌بین‌اند.

سیگنال‌ها زبان مؤدبانه تا قاطع برای توقف فرایندند. SIGTERM فرصت پاکسازی می‌دهد؛ SIGKILL آخرین ضربه است. در واحدهای systemd همین تمایز در TimeoutStopSec دیده می‌شود. کشتن کور همهٔ هم‌نام‌ها می‌تواند فرایند بی‌گناه را از بین ببرد.

زومبی و یتیم را با فهم والد و wait معنی کنید نه با وحشت. زومبی معمولاً نشانهٔ والد بد است. در کانتینر، فرایند pid 1 مسئولیت خاصی دارد؛ Image بد بدون init مناسب سیگنال را درست جلو نمی‌دهد.

برای سرویسهای تولید، مدیریت طول عمر را به systemd یا ارکستراسیون بسپارید نه به شِل دستی همیشگی. شِل برای عیب‌یابی است؛ نگه داشتن اپ با nohup روی session شخصی بدهی عملیاتی می‌سازد.

سناریو و نکتهٔ تکمیلی (4)

فرایندها منابع را مصرف می‌کنند و بدون مشاهده، ظرفیت سرور در تاریکی تمام می‌شود. عادت کنید قبل از مقیاس‌کردن عمودی، ببینید کدام pid CPU، حافظه یا IO را می‌خورد. ابزارهای ps و top و در مقالهٔ بعد htop، همان ذره‌بین‌اند.

سیگنال‌ها زبان مؤدبانه تا قاطع برای توقف فرایندند. SIGTERM فرصت پاکسازی می‌دهد؛ SIGKILL آخرین ضربه است. در واحدهای systemd همین تمایز در TimeoutStopSec دیده می‌شود. کشتن کور همهٔ هم‌نام‌ها می‌تواند فرایند بی‌گناه را از بین ببرد.

زومبی و یتیم را با فهم والد و wait معنی کنید نه با وحشت. زومبی معمولاً نشانهٔ والد بد است. در کانتینر، فرایند pid 1 مسئولیت خاصی دارد؛ Image بد بدون init مناسب سیگنال را درست جلو نمی‌دهد.

برای سرویسهای تولید، مدیریت طول عمر را به systemd یا ارکستراسیون بسپارید نه به شِل دستی همیشگی. شِل برای عیب‌یابی است؛ نگه داشتن اپ با nohup روی session شخصی بدهی عملیاتی می‌سازد.

سناریو و نکتهٔ تکمیلی (5)

فرایندها منابع را مصرف می‌کنند و بدون مشاهده، ظرفیت سرور در تاریکی تمام می‌شود. عادت کنید قبل از مقیاس‌کردن عمودی، ببینید کدام pid CPU، حافظه یا IO را می‌خورد. ابزارهای ps و top و در مقالهٔ بعد htop، همان ذره‌بین‌اند.

سیگنال‌ها زبان مؤدبانه تا قاطع برای توقف فرایندند. SIGTERM فرصت پاکسازی می‌دهد؛ SIGKILL آخرین ضربه است. در واحدهای systemd همین تمایز در TimeoutStopSec دیده می‌شود. کشتن کور همهٔ هم‌نام‌ها می‌تواند فرایند بی‌گناه را از بین ببرد.

زومبی و یتیم را با فهم والد و wait معنی کنید نه با وحشت. زومبی معمولاً نشانهٔ والد بد است. در کانتینر، فرایند pid 1 مسئولیت خاصی دارد؛ Image بد بدون init مناسب سیگنال را درست جلو نمی‌دهد.

برای سرویسهای تولید، مدیریت طول عمر را به systemd یا ارکستراسیون بسپارید نه به شِل دستی همیشگی. شِل برای عیب‌یابی است؛ نگه داشتن اپ با nohup روی session شخصی بدهی عملیاتی می‌سازد.

سناریو و نکتهٔ تکمیلی (6)

فرایندها منابع را مصرف می‌کنند و بدون مشاهده، ظرفیت سرور در تاریکی تمام می‌شود. عادت کنید قبل از مقیاس‌کردن عمودی، ببینید کدام pid CPU، حافظه یا IO را می‌خورد. ابزارهای ps و top و در مقالهٔ بعد htop، همان ذره‌بین‌اند.

سیگنال‌ها زبان مؤدبانه تا قاطع برای توقف فرایندند. SIGTERM فرصت پاکسازی می‌دهد؛ SIGKILL آخرین ضربه است. در واحدهای systemd همین تمایز در TimeoutStopSec دیده می‌شود. کشتن کور همهٔ هم‌نام‌ها می‌تواند فرایند بی‌گناه را از بین ببرد.

زومبی و یتیم را با فهم والد و wait معنی کنید نه با وحشت. زومبی معمولاً نشانهٔ والد بد است. در کانتینر، فرایند pid 1 مسئولیت خاصی دارد؛ Image بد بدون init مناسب سیگنال را درست جلو نمی‌دهد.

برای سرویسهای تولید، مدیریت طول عمر را به systemd یا ارکستراسیون بسپارید نه به شِل دستی همیشگی. شِل برای عیب‌یابی است؛ نگه داشتن اپ با nohup روی session شخصی بدهی عملیاتی می‌سازد.

خلاصه

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

منابع و مراجع

  • man7.org — credentials(7) — https://man7.org/linux/man-pages/man7/credentials.7.html
  • man7.org — proc(5) — https://man7.org/linux/man-pages/man5/proc.5.html
  • man7.org — signal(7) — https://man7.org/linux/man-pages/man7/signal.7.html
  • man7.org — pid_namespaces(7) — https://man7.org/linux/man-pages/man7/pid_namespaces.7.html
  • systemd documentation — https://systemd.io/

نویسنده

سا

سهیل ابراهیم‌پور بنیان‌گذار FutureForge است. روی طراحی محصول، معماری و استقرار نرم‌افزار سفارشی کار می‌کند.

یادداشت‌های مرتبط

یادداشت‌های مرتبط

دسته‌بندی‌ها

خدمات مرتبط

از یادداشت تا پروژه

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

برای انتخاب مسیر فنی پروژه‌تان کمک می‌خواهید؟

از مسئله و محدودیت‌هایتان بگویید؛ اگر بتوانیم همراهی‌تان کنیم، برای گفت‌وگو هماهنگ می‌کنیم.

سهیل ابراهیم‌پور
یادداشت‌ها
امنیت n8n: اعتبارنامه، وب‌هوک و SSRF
نصب n8n روی سرور با Docker Compose
n8n چیست و چگونه کار می‌کند؟
امنیت فروشگاه اینترنتی: سایت، درگاه و فرایند عملیاتی
بازیابی سرور لینوکس بعد از خرابی دیسک یا استقرار اشتباه

عملیات و استقرار

امنیت n8n: اعتبارنامه، وب‌هوک و SSRF

۹ آبان ۱۴۰۵

عملیات و استقرار

نصب n8n روی سرور با Docker Compose

۸ آبان ۱۴۰۵

عملیات و استقرار

n8n چیست و چگونه کار می‌کند؟

۸ آبان ۱۴۰۵

عملیات و استقرار

امنیت فروشگاه اینترنتی: سایت، درگاه و فرایند عملیاتی

۶ آبان ۱۴۰۵

عملیات و استقرار

بازیابی سرور لینوکس بعد از خرابی دیسک یا استقرار اشتباه

۲ آبان ۱۴۰۵
همه یادداشت‌ها315
معماری نرم‌افزار31
واژه‌نامه37
عملیات و استقرار94
مهندسی محصول122
راهنمای وب31
طراحی و ساخت محصول
توسعه فول‌استک
ممیزی مهندسی
مشاوره معماری
زیرساخت و استقرار
شروع گفتگو
ابزارهای رایگان
شروع گفتگو