أساسيات لينكس

العمليات والإشارات

18 دقيقة الدرس 7 من 26

العمليات والإشارات

كل برنامج يعمل على نظام لينكس هو عملية (Process) — نسخة قيد التشغيل من برنامج ما، لها معرّف عملية خاص بها (PID)، ومساحة ذاكرة، ومواصفات ملفات، وحصة في جدول التشغيل. في بيئة الإنتاج، تتعامل مع العمليات باستمرار: تفحصها لتشخيص مشكلات الأداء، وترسل إشارات لإعادة تحميل الإعدادات دون انقطاع، وتدير الأولوية لحماية الأعباء الحرجة. هذا الدرس يمنحك الأدوات الكاملة.

فحص العمليات باستخدام ps

ps أداة للقطة آنية — تعرض حالة العمليات في لحظة تنفيذ الأمر. أكثر استدعاء مفيد هو ps aux، الذي يسرد جميع العمليات من جميع المستخدمين بتنسيق مقروء.

# قائمة كاملة بالعمليات — الصيغة القياسية في بيئة الإنتاج ps aux # الأعمدة: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND # VSZ = الذاكرة الافتراضية (KB)، RSS = الذاكرة الفعلية المقيمة (KB) # عرض شجرة العمليات — مثالي للكشف عن العمليات الزومبي ps auxf # البحث عن خدمة محددة دون أن تظهر grep ذاتها في النتائج ps aux | grep '[n]ginx' # عرض PID والاسم ونسبة CPU والذاكرة لمستخدم معين ps -u deploy -o pid,comm,%cpu,%mem --sort=-%cpu

عمود STAT مهم في تشخيص الإنتاج. R = قيد التشغيل، S = نائمة (تنتظر I/O)، D = نوم غير قابل للمقاطعة (غالباً I/O للقرص — ارتفاع قيم D يشير إلى اختناق في التخزين)، Z = زومبي (انتهت العملية لكن العملية الأم لم تستدعِ wait() بعد)، T = موقوفة.

العمليات الزومبي لا تستهلك CPU أو ذاكرة لكنها تستهلك رقم PID. في حاويات microservices التي تُفرز كثيراً (Node.js cluster، PHP-FPM) دون عملية init صحيحة، يمكن أن يؤدي تراكم الزومبي إلى استنزاف فضاء PID — وهو سبب حقيقي لانقطاع الإنتاج. استخدم tini أو dumb-init بوصفهما PID 1 داخل الحاويات لاستيعاب العمليات اليتيمة بشكل صحيح.

المراقبة الآنية باستخدام top و htop

top هو المراقب الكلاسيكي التفاعلي للعمليات. يقدم الرأس ملخصاً على مستوى النظام (متوسط الحمل، سرقة CPU، الذاكرة)، ويعرض الجسم أكبر المستهلكين مرتبةً حسب CPU. اختصارات المفاتيح الأساسية داخل top: اضغط M للترتيب حسب الذاكرة، P للترتيب حسب CPU، k لإنهاء عملية بواسطة PID، 1 لعرض كل نواة على حدة (ضروري على الخوادم متعددة الأنوية)، q للخروج.

htop هو البديل الحديث — يضيف الألوان ودعم الفأرة ومقاييس لكل نواة وعرضاً شجرياً. ثبّته عبر مدير الحزم واستخدم htop -u nginx للتصفية الفورية حسب المستخدم.

فهم متوسط الحمل: الأرقام الثلاثة في رأس top (مثل 2.40 1.87 1.52) تمثل متوسطات الحمل لمدة دقيقة واحدة و5 دقائق و15 دقيقة. متوسط حمل يساوي عدد أنوية CPU يعني إشباعاً كاملاً. على جهاز رباعي الأنوية، حمل ثابت عند 4.0 يعني 100% استخدام؛ 8.0 يعني أن العمل يتراكم في الطابور. راقب الاتجاه — ارتفاع متوسط الـ 15 دقيقة إنذار مبكر.

الإشارات: التواصل مع العمليات

الإشارات إشعارات غير متزامنة ترسل إلى عملية ما. يمكن للنواة أو أي مستخدم مخوّل إرسالها. شغّل kill -l لرؤية القائمة الكاملة. إليك الأكثر استخداماً في الإنتاج يومياً:

Common Linux signals and their effects Signal Number Catchable What Happens SIGTERM (15) 15 Yes Graceful shutdown — flush buffers, close connections SIGKILL (9) 9 No Kernel immediately destroys process — no cleanup SIGHUP (1) 1 Yes Reload config (nginx, sshd) — zero downtime SIGINT (2) 2 Yes Ctrl+C — interrupt, same intent as SIGTERM SIGUSR1 (10) 10 Yes App-defined: nginx log rotation, unicorn hot reload SIGSTOP/CONT 19/18 No/Yes Pause / resume a process (Ctrl+Z sends SIGTSTP)
الإشارات الشائعة في لينكس: الرقم، وقابلية الاصطياد، وأثرها على العملية المستهدفة.
# إرسال SIGTERM (إيقاف مهذب) — ابدأ دائماً بهذا kill 1234 kill -15 1234 kill -SIGTERM 1234 # الثلاثة متكافئة # الإنهاء القسري حين تتجاهل العملية SIGTERM kill -9 1234 # إعادة تحميل إعدادات nginx دون قطع الاتصالات kill -HUP $(cat /var/run/nginx.pid) # أو باستخدام systemd (الأفضل في الأنظمة الحديثة) systemctl reload nginx # الإنهاء بالاسم — يرسل SIGTERM لجميع العمليات المطابقة pkill nginx pkill -HUP nginx # إعادة تحميل جميع عمال nginx # إنهاء كل عمليات مستخدم معين (استخدم بحذر!) pkill -u olduser
لا تلجأ إلى SIGKILL أولاً أبداً. العملية التي تُقتل بـ kill -9 لا تستطيع إغلاق اتصالات قاعدة البيانات، ولا تفريغ مخازن الكتابة المؤقتة، ولا تحرير الأقفال الاستشارية. هذا يسبب تلف البيانات في قواعد البيانات وملفات مكتوبة جزئياً وملفات قفل يتيمة تعيق التشغيل التالي. أرسل SIGTERM أولاً، وانتظر 5-30 ثانية، ثم تصعّد إلى SIGKILL فقط إذا رفضت العملية الخروج.

المقدمة والخلفية والتحكم في المهام

تتتبع الشل المهام — مجموعات العمليات المرتبطة بجلسة الطرفية الحالية. يمكنك تشغيل الأوامر في الخلفية لإبقاء الشل حرة، وتحريك المهام بين المقدمة والخلفية.

# تشغيل أمر في الخلفية — بإضافة & في نهاية الأمر ./long-migration.sh & # الناتج: [1] 4821 ← [رقم المهمة] PID # عرض جميع مهام الخلفية في الشل الحالية jobs -l # إعادة المهمة 1 إلى المقدمة fg %1 # تعليق العملية في المقدمة (يرسل SIGTSTP) # اضغط: Ctrl+Z # الناتج: [1]+ Stopped ./long-migration.sh # استئناف المهمة 1 في الخلفية bg %1 # فصل العملية عن الطرفية نهائياً (تبقى بعد تسجيل الخروج) nohup ./long-migration.sh > migration.log 2>&1 & # البديل الحديث والمفضل — tmux أو screen tmux new-session -d -s migration './long-migration.sh' tmux attach -t migration
عادة الإنتاج: لا تشغّل عمليات طويلة (هجرات قواعد البيانات، تصدير بيانات ضخمة، معالجة السجلات) في طرفية SSH مجردة دون tmux أو screen. إذا انقطع اتصالك في منتصف العملية، تستقبل العملية SIGHUP وتنتهي. استخدم tmux — يحتفظ بالجلسات حية على الخادم بغض النظر عن اتصالك.

أولوية العمليات باستخدام nice و renice

يجدول لينكس العمليات باستخدام قيمة النعومة (niceness) من -20 (أعلى أولوية، أكثر أنانية) إلى +19 (أدنى أولوية، أكثر تعاوناً). القيمة الافتراضية هي 0. يستطيع root فقط تعيين قيم سالبة (أولوية أعلى).

# تشغيل نسخ احتياطي مكثف للـ CPU بأولوية منخفضة كي لا يجوّع خادم الويب nice -n 15 tar -czf /backup/app.tar.gz /var/www/app # خفض أولوية عملية قيد التشغيل بالفعل renice +10 -p 4821 # عرض قيم النعومة الحالية (عمود NI) ps -eo pid,comm,ni --sort=-ni | head -20 # الجمع مع ionice للحدّ من أولوية CPU والقرص معاً ionice -c 3 nice -n 19 ./heavy-analytics-job.sh
سياق الشركات الكبرى: على البنية التحتية المشتركة، تعيين nice +15 على مهام الدُفعات (شحن السجلات، التحليلات، التقارير المجدولة) ممارسة قياسية. يضمن ذلك أنه عند تحميل المضيف، تحصل العمليات الحرجة على CPU أولاً، وتتنازل مهمة الدُفعات بسلاسة. تفرض Kubernetes وcgroups هذا على مستوى أعلى في بيئات الحاويات، لكن مفهوم المجدول الأساسي متطابق.

البحث عن عملية بواسطة المنفذ أو الملف

أداتان أخريان تكملان مجموعتك اليومية: lsof (سرد الملفات المفتوحة) وfuser. كلتاهما تساعدانك في معرفة أي عملية تمتلك موردًا — ضروري لتشخيص أخطاء "العنوان قيد الاستخدام" عند النشر.

# من يستمع على المنفذ 8080؟ lsof -i :8080 # أو باستخدام ss (أحدث من netstat) ss -tlnp | grep :8080 # أي عملية تحتفظ بملف معين مفتوحاً؟ lsof /var/log/app.log # تحرير منفذ تركته عملية معطوبة خلفها fuser -k 8080/tcp

يمنحك الجمع بين هذه الأدوات — ps وtop وkill وjobs وnice وlsof — رؤية كاملة والسيطرة التامة على كل عملية قيد التشغيل على أي خادم لينكس. هذه الأنماط متطابقة سواء كنت تشخّص مضيفاً معدنياً أو تنفّذ أوامر داخل pod في Kubernetes.