دليل إدارة العمليات في لينكس: تشريح الموارد والتحكم عبر top وhtop وps وkill

تشريح العملية في لينكس: الفارق بين البرنامج والكيان الحي

يمثل البرنامج في أنظمة لينكس ملفاً ثابتاً مخزناً على القرص الصلب بصيغة ثنائية تنفيذية مثل ELF، يتضمن التعليمات البرمجية والبيانات المبدئية. بمجرد قيام نواة النظام (Kernel) بتحميل هذا الملف إلى الذاكرة العشوائية وتخصيص مساحة عنونة افتراضية وسياق تنفيذ له، يتحول الملف الثابت إلى كائن ديناميكي نشط يُعرف باسم العملية (Process).

تعتمد النواة تسلسلاً هرمياً صارماً لإدارة العمليات؛ حيث تبدأ شجرة العمليات بأكملها من العملية ذات المعرف رقم 1 (PID 1)، والتي تكون غالباً systemd في التوزيعات الحديثة أو init في الأنظمة الكلاسيكية. كل عملية جديدة تُولد عبر استدعاء النظام fork() لتفريد عملية مطابقة من الأصل، متبوعة باستدعاء exec() لاستبدال مساحة العنونة بالبرنامج الجديد. هذا يرسخ علاقة الأب والابن، ممثلة في المعرف الخاص بالعملية PID ومعرف العملية الأب PPID.

تستقي جميع أدوات المراقبة بياناتها من نظام الملفات الوهمي /proc، وهو واجهة برمجية توفرها النواة في الذاكرة لقراءة حالة العمليات لحظياً؛ حيث يمثل كل مجلد رقمي مثل /proc/[PID]/status تقريراً حياً عن استهلاك الذاكرة، وخيوط المعالجة، والامتيازات الأمنية الخاصة بتلك العملية دون أي وساطة تخزينية خارجية.

دورة حياة العملية وحالات التنفيذ (Process States)

لا تعمل العمليات بشكل مستمر على المعالج، بل تتبدل حالاتها وفق جدولة زمنية دقيقة تديرها النواة. يُرمز لكل حالة بحرف قياسي يظهر في مخرجات أدوات الفحص:

• الحالة R (Running / Runnable): العملية تعمل حالياً على أحد أنوية المعالج أو تقف في طابور الجاهزية بانتظار تخصيص دورة تنفيذ زمنية لها.
• الحالة S (Interruptible Sleep): العملية في وضع خمول مؤقت بانتظار حدث معين (مثل إدخال من المستخدم أو وصول بيانات من مقبس الشبكة)، وتستجيب فوراً للإشارات المرسلة إليها.
• الحالة D (Uninterruptible Sleep): نوم غير قابل للمقاطعة، وغالباً ما تكون العملية بانتظار استجابة مباشرة من العتاد أو عودة عمليات الإدخال والإخراج للقرص (I/O). هذه الحالة لا تستجيب لأي إشارة برمجية حتى تنتهي النواة من معالجة طلب العتاد.
• الحالة T (Stopped / Traced): العملية متوقفة مؤقتاً إما بواسطة إشارة تعليق مثل SIGSTOP أو عبر أداة تصحيح أخطاء برمجية مثل gdb.
• الحالة Z (Zombie / Defunct): عملية أكملت تنفيذها وماتت بالفعل، لكن مدخلها لا يزال محجوزاً في جدول العمليات بالنواة لأن العملية الأب لم تستدعِ دالة wait() لقراءة كود الخروج الخاص بها.

استخراج اللقطات الثابتة عبر أداة ps

تُعد أداة ps (Process Snapshot) الوسيلة المعيارية لالتقاط صورة فورية ثابتة لحالة العمليات في لحظة زمنية محددة. يختلف مهندسو الأنظمة في بناء صياغات الأوامر، حيث يبرز أسلوبان أساسيان:

1. صياغة معيار POSIX القياسي

تعتمد الشرطة السابقة للخيارات، وأشهرها الأمر:

ps -ef

يعرض الخيار -e كافة العمليات على النظام، بينما يعرض -f تفاصيل موسعة تتضمن اسم المستخدم، ومعرف PID، ومعرف الأب PPID، ونسبة استهلاك المعالج، ووقت بدء التشغيل، ومسار الأمر المنفذ بالكامل.

2. صياغة نمط BSD التاريخي

تُكتب الخيارات دون شرطة، وأشهرها الأمر واسع الانتشار:

ps aux

يقوم الخيار a بعرض عمليات جميع المستخدمين المرتبطة بجلسات Terminal، والخيار u يضيف أعمدة استهلاك الذاكرة والمعالج مع اسم المستخدم، في حين يضمن الخيار x إظهار العمليات التي تعمل في الخلفية دون ارتباط بـ Terminal (مثل الشياطين والخدمات Daemons).

المراقبة التفاعلية المتقدمة: تفكيك مؤشرات top وhtop

توفر أدوات المراقبة الحية شاشات ديناميكية تتحدث دورياً (افتراضياً كل 3 ثوانٍ في top وثانية واحدة في htop). لقراءة هذه الأدوات بكفاءة، يجب فهم المؤشرات الحيوية التي تحكم أداء الخادم:

تفكيك لغز متوسط التحميل (Load Average)

يعبر شريط التحميل عن ثلاثة أرقام تمثل متوسط عدد العمليات التي كانت في حالة العمل الجاهز (R) أو بانتظار الإدخال والإخراج غير القابل للمقاطعة (D) خلال الدقيقة الواحدة، و5 دقائق، و15 دقيقة الماضية. لتقييم هذا الرقم، يجب مقارنته دائماً بعدد أنوية المعالج المتاحة في النظام؛ فإذا كان الخادم يمتلك 4 أنوية، فإن قراءة تحميل تبلغ 4.00 تعني وصول المعالج إلى سعة الاستخدام المثالية بنسبة 100%، بينما أي رقم يتجاوز ذلك يشير إلى تراكم العمليات في طوابير الانتظار وحدوث اختناق في الموارد.

المعادلة المعمارية لمقاييس الذاكرة (VIRT مقابل RES مقابل SHR)

ترتكب الفرق الهندسية خطأ فادحاً عند الخلط بين مؤشرات الذاكرة المعروضة في top:

• VIRT (Virtual Memory Size): الحجم الكلي لمساحة العنونة الافتراضية التي طلبتها العملية من النواة. يشمل ذلك التعليمات البرمجية، والمكتبات المشتركة، والملفات المحملة في الذاكرة، والصفحات التي حُجزت ولكن لم تُستخدم فعلياً بعد في العتاد.
• RES (Resident Memory Size): الحجم الحقيقي وغير القابل للنقاش لما تستهلكه العملية من شرائح الذاكرة العشوائية الفعلية (Physical RAM). هذا هو المؤشر الواقعي لتحديد استهلاك البرامج.
• SHR (Shared Memory): جزء من ذاكرة RES الذي يمكن مشاركته مع عمليات أخرى، مثل مكتبات C القياسية (libc.so) أو قطاعات الذاكرة المشتركة المخصصة للاتصال بين العمليات (IPC).

التحكم والتحليل في بيئة htop الحديثة

تطورت أداة htop المكتوبة بلغة C في إصداراتها الحديثة لتدعم تقنيات متقدمة تفتقر إليها الشاشات التقليدية؛ حيث تدعم كشف مؤشرات الذاكرة المضغوطة zram وzswap، فضلاً عن تقديم عرض شجري فوري للعمليات بالضغط على مفتاح F5 يكشف مباشرة عن العمليات المتفرعة من نفس الأصل. كما توفر ترشيحاً سريعاً للعمليات بالضغط على F4، وضبط أولويات الجدولة (Nice Values) التفاعلي من -20 (الأولوية القصوى) إلى 19 (الأولوية الدنيا) عبر F7 وF8.

منظومة الإشارات البرمجية: الإغلاق الآمن مقابل الإنهاء القسري

لا يُعد الأمر kill في بيئات يونكس أداة لإنهاء البرامج فحسب، بل هو ناقل اتصالات مخصص لإرسال إشارات برمجية غير متزامنة (Signals) عبر النواة إلى العمليات. تستمع كل عملية إلى هذه الإشارات وتقوم بمعالجتها وفق معالجات برمجية داخلية (Signal Handlers)، باستثناء إشارات حاسمة تتولاها النواة مباشرة.

أهم الإشارات المستخدمة في إدارة الأنظمة

• SIGTERM (Signal 15): إشارة الإنهاء المهذب الافتراضية. تخطر العملية بوجوب التوقف، مما يمنحها مهلة لإغلاق اتصالات قواعد البيانات، وحفظ الحالة، وإزالة ملفات القفل المؤقتة (Lock files) من القرص.
• SIGKILL (Signal 9): الإيقاف الإجباري الصارم الموجه مباشرة إلى النواة. تعزل النواة العملية فوراً وتسترد مواردها دون منح الكود أي فرصة للتنظيف، مما قد يتسبب في تلف الملفات المفتوحة جزئياً.
• SIGHUP (Signal 1): إشارة قطع الاتصال، وتُستخدم مع خدمات الويب الشائعة (مثل Nginx وApache) لإعادة قراءة ملفات الإعدادات وتحديث الشهادات الأمنية دون إسقاط جلسات العمل القائمة.
• SIGINT (Signal 2): إشارة المقاطعة الفورية التي تصدرها لوحة المفاتيح عبر الاختصار Ctrl + C.

تطبيق عملي: سكربت لاعتراض الإشارات ومحاكاة الإنهاء الآمن

يوضح المثال البرمجي التالي كيفية بناء خدمة نصية بلغة Bash تستهلك موارد حسابية وتستمع لإشارة SIGTERM لتنفيذ تفريغ آمن للكاش، مع إبراز الفرق الحاسم عند استهدافها بإشارة SIGKILL:

#!/usr/bin/env bash

echo "Worker process initialized with PID: $$"

cleanup() {
    echo ""
    echo "[Handling SIGTERM] Flushing state and releasing lock files..."
    sleep 2
    echo "[Handling SIGTERM] Graceful shutdown completed cleanly."
    exit 0
}

trap cleanup SIGTERM

step=1
while true; do
    echo "Processing compute cycle: ${step}"
    for ((i=1; i<=200000; i++)); do
        :
    done
    step=$((step + 1))
    sleep 1
done

يقوم السكربت بالخطوات البرمجية التالية بالتفصيل:

1. يطبع السطر الثالث معرف العملية الخاصة به لحظة الإطلاق عبر المتغير الخاص $$.
2. تُعرّف الدالة cleanup خطة الإغلاق الآمن، حيث تحاكي عملية حفظ البيانات وتفريغ الكاش باستخدام أمر sleep 2 لتوضيح استهلاك الوقت اللازم لإنهاء العمليات المعلقة.
3. يعترض الأمر trap cleanup SIGTERM في السطر الحادي عشر الإشارة رقم 15 الموجهة من النظام؛ فبدلاً من الانهيار المفاجئ، تُحوّل النواة تدفق التنفيذ إلى دالة التنظيف أولاً.
4. تنشئ حلقة while في السطور اللاحقة عبئاً حسابياً مستمراً باستخدام حلقة تكرار فارغة تستهلك جزءاً من دورات المعالج لتسهيل رصدها في top وps.

لتشغيل الاختبار، نفّذ السكربت بالخلفية عبر ./safe_worker.sh &، ثم أرسل إشارة ودية بالمعرف الناتج: kill -15 <PID>؛ ستلاحظ ظهور رسائل الإغلاق المنظم على الطرفية. أعد تشغيل السكربت مجدداً وأرسل kill -9 <PID>، وستجد أن العملية قُتلت فوراً دون تنفيذ أي سطر من دالة التنظيف، مما يجسد خطورة الإفراط في استخدام الإشارة 9.

الأخطاء الشائعة في إدارة العمليات والموارد

1. استدعاء أمر kill -9 كخيار أول عند بطء الخوادم

يلجأ بعض المهندسين لإنهاء العمليات المعلقة مباشرة عبر kill -9. يؤدي هذا السلوك إلى بقاء ملفات القفل التالفة على نظام الملفات، ومنع محررات التخزين وقواعد البيانات من إتمام المعاملات العالقة في الذاكرة المؤقتة. الإجراء الصحيح هو إرسال إشارة SIGTERM أولاً، وإعطاء العملية نافذة زمنية معقولة (مثل 10 إلى 30 ثانية)، وفقط في حال تجمد العملية التام وانقطاع استجابتها يتم التصعيد إلى SIGKILL.

2. استهداف العمليات الزومبي (Zombie Processes) بأوامر الإنهاء

محاولة تنفيذ kill -9 على عملية في الحالة Z هي محاولة لإنهاء كائن ميت في الأصل؛ فالعملية الزومبي لا تملك كوداً تنفيذياً في الذاكرة ولا تستهلك دورات معالج، بل تحتل خانة بيانات فقط داخل جدول العمليات بانتظار قراءة الأب لكود الخروج. الحل الحقيقي يكمن في إرسال إشارة SIGCHLD إلى العملية الأب (PPID) لتنبيهها بحصد نتائج أبنائها، أو إنهاء العملية الأب نفسها لتؤول وصاية العمليات الزومبي إلى عملية الجذر (PID 1) التي تقوم بتنظيفها فورياً.

3. قتل العمليات المدارة تحت مظلة systemd يدوياً

عند تنفيذ kill لعملية تابعة لخدمة تعمل تحت إدارة systemd مع تفعيل خاصية Restart=always، يعتبر مدير النظام هذا التوقف بمثابة انهيار مفاجئ للخدمة، فيقوم فوراً بإعادة تشغيلها تحت معرف PID جديد. لإنهاء أو إعادة تشغيل مثل هذه العمليات بشكل منظم، يجب توجيه الأوامر عبر مدير الخدمات حصراً مثل: systemctl stop service_name.

4. تفسير نسبة استهلاك المعالج (%CPU) بمعزل عن عدد الأنوية

في الأنظمة متعددة الأنوية، قد تعرض أداة top استهلاك عملية معينة بنسبة 250%، مما يثير حيرة المبتدئين. يعود هذا إلى وضع العرض الافتراضي (Irix Mode)، والذي يعتبر كل نواة بمثابة 100% منفصلة. لمعرفة النسبة الإجمالية من سعة الخادم الكلية، يجب إما تقسيم الرقم على عدد الأنوية المتاحة، أو الضغط على الاختصار Shift + I في top للتحويل إلى وضع (Solaris Mode) الذي يقسم الاستهلاك تلقائياً على إجمالي عتاد المعالجة.

متى تستخدم أدوات CLI التقليدية ومتى تتجاوزها؟

تظل أدوات ps وhtop وkill الخيار الأمثل للتشخيص السريع والفوري في بيئات الاستضافة الفردية، وتصحيح المشاكل اللحظية أثناء اتصال SSH بالخوادم للتحقق من أسباب بطء العتاد المفاجئ. مع ذلك، تصبح هذه الأدوات قاصرة وعاجزة في بيئات الحاويات الموزعة (مثل Kubernetes وDocker)، حيث تتداخل مساحات التسمية ولا توفر الأدوات التقليدية عزلاً لموارد كل حاوية على حدة؛ هناك يتحول الاعتماد الهندسي الإلزامي إلى أدوات تقرأ مجموعات التحكم الحديثة (cgroups v2) مثل systemd-cgtop، وتصدير المقاييس نحو منصات الرصد المتخصصة مثل Prometheus وGrafana لتحليل السلوك التاريخي للموارد عبر مئات الخوادم دفعة واحدة.