البحث في الموقع

Nginx خادم ويب قوي ووكيل عكسي (reverse proxy) يُستخدم لتقديم العديد من المواقع الأكثر شهرةً في العالم. سنوضّح في هذا الدليل كيفية ترقية Nginx الموجود القابل للتنفيذ، بدون قطع اتصالات العميل. المتطلبات الأساسية قبل البدء في هذا الدليل، يجب أن يكون لديك مستخدم غير جذر على خادمك، تمَّ إعداده مع صلاحيات sudo. ستحتاج أيضًا أن يكون لديك خادم Nginx مثبَّتًا. إذا كنت تستخدم أبنتو 14.04، يمكنك تعلّم كيفية ضبط مستخدم بصلاحيات sudo هنا. يمكنك تثبيت Nginx باتّباع هذا الدليل. إذا كنت تستخدم CentOS 7، يمكنك الحصول على ضبط المستخدم بصلاحيات sudo عبر هذا الدليل، متّبعًا هذا الدليل لتثبّت Nginx. كيف تعمل الترقية يعمل Nginx على إنشاء إجراء سيّد أو رئيسي (master process) عندما تبدأ الخدمة. ويشغّل الإجراء السيّد بدوره إجراء تابع (worker process) أو أكثر تتعامل مع اتصالات العميل الفعلية. تم تصميم Nginx لأداء إجراءات معينة عندما يتلقّى إشارات محددة من المدير. يمنحك الفرصة باستخدام هذه الإشارات لتقوم بترقيته أو ترقية إعداداته الموجودة بسهولة، بدون قطع اتصالات العميل. هناك سكربتات (scripts) معينة للخدمة مزوّدة من قِبل القائمين على صيانة حزمة التوزيع ستوفر القدرة على الاستخدام مع الترقيات التقليدية. لكن توفر الترقية يدويًا المزيد من المرونة في المنهجية وتسمح لك بمراجعة الترقية للتراجع بسرعة إذا كان هناك مشاكل. هذا أيضًا سيوفر خيارًا للترقية بأمان إذا قمت بتثبيت Nginx من المصدر أو باستخدام طريقة لا توفر هذه الإمكانية. ستُستخدم الإشارات التالية: USR2: تولّد هذه مجموعة جديدة من إجراءات السيد/التابع بدون التأثير على المجموعة القديمة. WINCH: تخبر هذه الإجراء السيد لـNginx أن يوقف أغراض التابع المرتبطة بأمان. HUP: تخبر هذه الإجراء السيد لـNginx أن يعيد قراءة ملفات إعداداته ويستبدل إجراءات التابع بتلك المرتبطة بالإعدادات الجديدة. إذا كان هناك سيد قديم وجديد قيد التشغيل، فإنَّ إرسال هذا إلى السيد القديم سيولّد توابعًا باستخدام إعداداتهم الأصليّة. QUIT: توقف هذه تشغيل السيّد وتوابعه بأمان. TERM: تهيئ هذه إيقاف تشغيل سريع للسيّد وتوابعه. KILL: توقف هذه السيّد وتوابعه بدون أيّ تنظيف. إيجاد معرّفات إجراء Nginx لإرسال إشارات إلى الإجراءات المختلفة، نحتاج إلى معرفة معرّف الإجراء (PID) المستهدف. هناك طريقتان سهلتان لإيجاد هذا. أولًا، يمكنك استخدام الأداة ps وثمّ grep لـNginx بين النتائج. هذا بسيط ويسمح لك برؤية إجراءات السيّد والتابع: $ ps aux | grep nginx output root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 10847 0.0 0.1 47936 1908 ? S 13:26 0:00 nginx: worker process user 10961 0.0 0.0 112640 964 pts/0 S+ 13:53 0:00 grep --color=auto nginx يحتوي العمود الثاني على معرّفات الإجراءات المُختارة. المميز هو معرّف الإجراء. يوضّح العمود الأخير أنَّ النتيجة الأولى هي الإجراء السيّد لـNginx. طريقة أخرى لإيجاد معرّف الإجراء السيّد لـNginx وهي طباعة محتويات ملف ‎/run/nginx.pid: $ cat /run/nginx.pid output 10846 إذا كان هناك إجراءين سيّد لـNginx قيد التشغيل، سينتقل الإجراء القديم إلى run/nginx.pid.oldbin/. توليد مجموعة سيّد/توابع جديدة الخطوة الأولى لتحديث ملفنا القابل للتنفيذ بأمان هي في الواقع تحديث ملفك الثنائي.قم بذلك باستخدام أيّ طريقة مناسبة لتثبيت Nginx لديك، سواء من خلال مدير الحزمة أو التثبيت المصدري. بعد وضع الملف الثنائي الجديد في مكانه، يمكنك توليد مجموعة ثانية من إجراءات السيّد/التابع التي تستخدم الملف الجديد القابل للتنفيذ. يمكنك القيام بذلك إمّا بإرسال إشارة USR2 مباشرةً إلى رقم المعرّف الذي استعلمت عنه (تأكّد هنا من استبدال معرّف الإجراء السيّد بمعرّف الإجراء السيّد الخاص بخادمك Nginx): $ sudo kill -s USR2 10846 او يمكنك قراءة واستبدال القيمة المخزّنة في ملف PID مباشرةً باستخدام أمر كهذا: $ sudo kill -s USR2 `cat /run/nginx.pid` إذا تفحّصت إجراءاتك الحاليّة، ستشاهد أنّ لديك الآن مجموعتان من إجراءات السيّد/التوابع لـNginx: $ ps aux | grep nginx output root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 10847 0.0 0.1 47936 1908 ? S 13:26 0:00 nginx: worker process root 11003 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process user 11031 0.0 0.0 112640 960 pts/0 S+ 14:01 0:00 grep --color=auto nginx يمكنك أيضًا أن تشاهد أنَّ ملف run/nginx.pid/ الأصلي قد انتقل إلى run/nginx.pid.oldbin/ ومعرّف الإجراء السيّد الجديد كُتبَ في الملف run/nginx.pid/: $ tail -n +1 /run/nginx.pid* output ==> /run/nginx.pid <== 11003 ==> /run/nginx.pid.oldbin <== 10846 يمكنك الآن إرسال إشارات إلى أيّ من الإجراءين السيّدين مستخدمًا المعرّفات الموجودة في هذه الملفات. عند هذه النقطة، فإن مجموعتي السيّد/التابع شغّالتين وقادرتين على تلبية طلبات العميل. تستخدم المجموعة الأولى الملف الأصلي القابل للتنفيذ والإعدادات الأصلية لـNginx وتستخدم المجموعة الثانية الإصدارات الأحدث. يمكنهم الاستمرار في العمل جنبًا إلى جنب، لكن يجب أن نبدأ في الانتقال إلى المجموعة جديدة من أجل الاتساق. إيقاف تشغيل توابع السيّد الأول للبدء بالانتقال إلى المجموعة الجديدة، فإنَّ أول شيء يمكننا القيام به هو إيقاف الإجراءات توابع السيّد الأصلي. سينهي التوابع الأصليين معالجة كل اتصالاتهم الحالية ثمَّ يخرجون. أوقف توابع المجموعة الأصلية بإصدار إشارة WINCH إلى إجرائهم السيّد: $ sudo kill -s WINCH `cat /run/nginx.pid.oldbin` سيتيح ذلك لتوابع السيّد الجديد أن يتعاملوا مع اتصالات العميل الجديدة بمفردهم. سيظلّ الإجراء السيّد القديم قيد التشغيل، لكن بدون توابع: $ ps aux | grep nginx output root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root 11003 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process user 11089 0.0 0.0 112640 964 pts/0 R+ 14:13 0:00 grep --color=auto nginx يتيح هذا لك مراجعة التوابع الجدد لأنّهم يقبلون الاتصالات بشكلٍ منفصل مع الحفاظ على قابلية العودة إلى الملف القديم القابل للتنفيذ إذا كان هناك خطأٌ ما. تقييم النتيجة واتخاذ الخطوات التالية عند هذه النقطة يجب اختبار النظام ومراجعته للتأكّد من عدم وجود بوادر مشاكل. يمكنك ترك الإعدادات في هذه الحالة طالما ترغب بالتأكّد من أنّ الملف الجديد القابل للتنفيذ لـNginx خالٍ من الأخطاء وقادر على التعامل مع حركة المرور الخاصة بك. ستعتمد خطوتك التالية تمامًا على ما إذا كنت تواجه مشاكل. إذا كانت الترقية ناجحة، أكمل الانتقال إذا لم تواجه أيّ مشاكل مع توابع مجموعتك الجديدة، يمكنك إيقاف تشغيل الإجراء السيّد القديم بأمان. للقيام بذلك، فقط أرسل الإشارة QUIT إلى السيّد القديم: sudo kill -s QUIT `cat /run/nginx.pid.oldbin` سيُغلَق الإجراء السيّد القديم بأمان، تاركًا فقط مجموعتك الجديدة من السيّد/التوابع لـNginx. عند هذه النقطة، تكون قد حدّثت الملف الثنائي الموجود لـNginx بأمان بدون مقاطعة اتصالات العميل. إذا واجهت مشاكل في التوابع الجديدة، عُد إلى الملف الثنائي القديم إذا لاحظت وجود مشاكل في مجموعة التوابع الجديدة، يمكنك العودة إلى الملف الثنائي والإعدادات القديمة. وهذا ممكن خلال الجلسة نفسها. أفضل طريقة للقيام بذلك هي إعادة تشغيل توابع السيّد القديم بإرسال إشارة HUP له. عادةً، عندما ترسل إشارة HUP للسيّد في Nginx، يعيد قراءة ملفات إعداداته ويشغّل توابعًا جديدة. لكن عندما يكون الهدف سيّد أقدم، فقط يولّد توابعًا جديدة باستخدام إعدادات العمل الأصلية: $ sudo kill -s HUP `cat /run/nginx.pid.oldbin` يجب أن تعود الآن ليكون لديك مجموعتين من إجراءات السيّد/التابع: $ ps aux | grep nginx output root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root 11003 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process nginx 19918 0.0 0.1 47936 1900 ? S 14:47 0:00 nginx: worker process user 19920 0.0 0.0 112640 964 pts/0 R+ 14:48 0:00 grep --color=auto nginx ترتبط التوابع الجديدة بالتابع القديم. عند هذه النقطة فإنَّ توابع المجموعتين سيقبلون اتصالات العميل. أوقف الآن الإجراء السيّد الجديد الذي يحوي أخطاء وتوابعه بإرسال إشارة QUIT: $ sudo kill -s QUIT `cat /run/nginx.pid` يجب أن تعود للسيّد والتوابع القديمين: $ ps aux | grep nginx output root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 19918 0.0 0.1 47936 1900 ? S 14:47 0:00 nginx: worker process user 19935 0.0 0.0 112640 964 pts/0 R+ 14:50 0:00 grep --color=auto nginx سيستعيد السيّد الأصلي ملف run/nginx.pid/ لمعرّفه. إذا لم يعمل ما سبق لأي سبب من الأسباب، يمكنك أن تحاول فقط إرسال إشارة TERM للسيّد الجديد للخادم، وهذا يجب أن تتهيأ عملية إيقاف التشغيل. ويجب أن يوقف هذا السيّد الجديد وأي تابع من توابعه أثناء البحث التلقائي عن السيّد القديم لبدء إجراءات التابع الخاص به. إذا كان هناك مشاكل خطيرة والتوابع بهم أخطاء ولم يتم إنهاؤهم، يمكنك إرسال إشارة KILL لكلٍّ منهم للتنظيف. يجب أن يكون هذا كحل أخير لأنّه سيؤدي إلى قطع الاتصالات. بعد الانتقال مرة أخرى إلى الملف الثنائي القديم، تذكّر أنّه لا يزال لديك الإصدار الجديد مثبّتًا على نظامك. يجب أن تزيل الإصدار الذي يحوي مشاكل وتعود لإصدارك السابق حتى يعمل Nginx بدون أيّة مشاكل عند إعادة التشغيل. خاتمة يجب أن تكون الآن قادرًا على نقل أجهزتك بسلاسة من ملف ثنائي لـNginx إلى آخر. إنَّ قدرة Nginx على التعامل مع مجموعتي سيّد/توابع مع المحافظة على معلومات علاقاتهم تتيح لنا القدرة على ترقية برنامج الخادم بدون أن يصبح جهاز الخادم في وضع عدم الاتصال. ترجمة -وبتصرف- للمقال How To Upgrade Nginx In-Place Without Dropping Client Connections لصاحبه Justin Ellingwood

يُعتبر تشغيل التطبيقات على خادوم لينكس أمرًا اعتياديًا كما هو الحال مع أي جهاز حاسوب آخر، ويطلق الحاسب على تلك التطبيقات اسم "العمليات" Process. وبينما يعالج لينكس من وراء الكواليس العمليات على المستوى المنخفض ويدير [دورة حياتها][1] إلا أنك لا تزال بحاجة إلى أدوات تساعدك على إدارة هذه العمليات في المستوى العالي higher-level لإدارة النظام. في هذا الدّرس سنناقش بعض الجوانب البسيطة في إدارة العمليات تحت أنظمة لينكس، والتي توفّر عددًا كبيرًا من الأدوات لهذا الغرض. تم تطبيق الأمثلة على خادوم خاص VPS يعمل بتوزيعة Ubuntu 14.04، إلا أنها ستعمل بالتأكيد بذات الطريقة مع باقي التوزيعات. كيفية استعراض العمليات النشطة في لينكسtopلاستعراض العمليات النشطة حاليًا على الخادوم يمكن بسهولة تشغيل الأمر top: top top - 15:14:40 up 46 min, 1 user, load average: 0.00, 0.01, 0.05 Tasks: 56 total, 1 running, 55 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 1019600k total, 316576k used, 703024k free, 7652k buffers Swap: 0k total, 0k used, 0k free, 258976k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 24188 2120 1300 S 0.0 0.2 0:00.56 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/0 6 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 7 root RT 0 0 0 0 S 0.0 0.0 0:00.03 watchdog/0 8 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 cpuset 9 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper 10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs تضم السطور الأولى للخرج السابق معلومات عامة عن النظام مثل مدّة تشغيله، معدّل استخدام المعالج، عدد العمليات، وغيرها، ويمكن ملاحظة وجود عملية واحدة نشطة في مثالنا هذا، إضافة إلى 55 عملية في حالة سكون idle أي لا تستخدم شيئًا من موارد المعالج CPU. بينما يضم القسم الآخر والموزع في جدول على العمليات النشطة إضافةً لمعلومات مختلفة عنها (مثل مقدار استهلاكها للذاكرة أو المعالج). htopالنسخة المُحسّنة من top تدعى htop، وهي متاحة في المستودعات الرسمية لمعظم التوزيعات، على Ubuntu يمكن تركيبها بالأمر التالي: sudo apt-get install htopيعرض الأمر htop الخرج بأسلوب أيسر في القراءة والفهم: htop Mem[||||||||||| 49/995MB] Load average: 0.00 0.03 0.05 CPU[ 0.0%] Tasks: 21, 3 thr; 1 running Swp[ 0/0MB] Uptime: 00:58:11 PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 1259 root 20 0 25660 1880 1368 R 0.0 0.2 0:00.06 htop 1 root 20 0 24188 2120 1300 S 0.0 0.2 0:00.56 /sbin/init 311 root 20 0 17224 636 440 S 0.0 0.1 0:00.07 upstart-udev-brid 314 root 20 0 21592 1280 760 S 0.0 0.1 0:00.06 /sbin/udevd --dae 389 messagebu 20 0 23808 688 444 S 0.0 0.1 0:00.01 dbus-daemon --sys 407 syslog 20 0 243M 1404 1080 S 0.0 0.1 0:00.02 rsyslogd -c5 408 syslog 20 0 243M 1404 1080 S 0.0 0.1 0:00.00 rsyslogd -c5 409 syslog 20 0 243M 1404 1080 S 0.0 0.1 0:00.00 rsyslogd -c5 406 syslog 20 0 243M 1404 1080 S 0.0 0.1 0:00.04 rsyslogd -c5 553 root 20 0 15180 400 204 S 0.0 0.0 0:00.01 upstart-socket-brلقراءة المزيد عن استخدام الأمرين top و htop هنا. استخدام ps في عرض العملياتكما شاهدنا فكلا الأداتين top و htop تعرضان العمليات بشكل مشابه لمدير المهام في الواجهات الرسومية، إلا أنهما ليستا مرنتين كفايةً لتغطية كافة الاحتياجات، وهنا يأتي دور الأداة ps للتعويض عن هذا القصور. للوهلة الأولى قد يخيب أملنا فيما لو استدعينا الأمر ps مباشرةً ودون معطيات Arguments إضافية، حيث لن يزيد عدد أسطر الخرج عن اثنين مع ثلاثة أعمدة: ps PID TTY TIME CMD 1017 pts/0 00:00:00 bash 1262 pts/0 00:00:00 psوالسبب هو أن الأمر ps بشكله المجرّد يعرض العمليات المرتبطة بالمستخدم الحالي وجلسة الطرفية فقط، وبالنظر إلى أننا لم نشغّل سوى الطرفية مع الأمر ps فإن الخرج السابق يبدو طبيعيًا. أما لاستعراض تفاصيل أكثر عن عمليات نظامنا الحالي يمكننا تشغيل الأمر التالي: ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 24188 2120 ? Ss 14:28 0:00 /sbin/init root 2 0.0 0.0 0 0 ? S 14:28 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S 14:28 0:00 [ksoftirqd/0] root 6 0.0 0.0 0 0 ? S 14:28 0:00 [migration/0] root 7 0.0 0.0 0 0 ? S 14:28 0:00 [watchdog/0] root 8 0.0 0.0 0 0 ? S< 14:28 0:00 [cpuset] root 9 0.0 0.0 0 0 ? S< 14:28 0:00 [khelper] . . . مع الخيار aur سوف يعرض الأمر ps العمليات التي تخص كافة المستخدمين على شكل جدول سهل الفهم. كما يمكننا ترتيب عرض العمليات بشكل متسلسل يوضّح العلاقات فيما بينها عن طريق إضافة الخيار axjf للأمر: ps axjf PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND 0 2 0 0 ? -1 S 0 0:00 [kthreadd] 2 3 0 0 ? -1 S 0 0:00 \_ [ksoftirqd/0] 2 6 0 0 ? -1 S 0 0:00 \_ [migration/0] 2 7 0 0 ? -1 S 0 0:00 \_ [watchdog/0] 2 8 0 0 ? -1 S< 0 0:00 \_ [cpuset] 2 9 0 0 ? -1 S< 0 0:00 \_ [khelper] 2 10 0 0 ? -1 S 0 0:00 \_ [kdevtmpfs] 2 11 0 0 ? -1 S< 0 0:00 \_ [netns] . . .وكما ترى يمكننا بسهولة ملاحظة أن العملية kthreadd هي عملية أب للعملية ksoftirqd/0 وما يليها. ملاحظات حول معرّفات العمليات Process IDsيخصّص لينكس والأنظمة الشبيهة بيونكس رقمًا معرفًا لكل عملية Process ID أو ما يعرف بـ PID، حيث يتمكّن النظام من التعرف بذلك على العمليات وتعقبها أثناء التشغيل. يتيح الأمر pgrep أسلوبًا سهلًا للحصول على رقم PID لأيّة عملية، حيث يستعلم عنه ويعيده كخرج على الشاشة: pgrep bash 1017 كمثال آخر فإن أوّل عملية يتم إطلاقها أثناء الإقلاع والتي تدعى init تعطى رقم PID يساوي الواحد: pgrep init 1تعمل هذه العملية على متابعة تشغيل باقي العمليات أثناء تشغيل النظام، كما أنها مسؤولة عن تشغيل باقي الخدمات، وفي المقابل فإن آخر عملية يتم تشغيلها تأخذ أكبر رقم PID. نقول عن عملية ما أنها عملية أب Parent Process إذا كانت تتولى تشغيل عملية أخرى، وهذا يعني أنه إذا تم إيقاف العملية الأب بشكل إجباري (أي قتلها) فستنهار العملية الابن، يشار في هذه الحالة لرقم PID الخاص بمعرّف عملية أب برقم PPID. تعرض الأدوات السابقة (top, htop, ps) أعمدة تضم أرقام كلًا من PID و PPID الخاصة بالعمليات المختلفة، إذ تتم إدارة العمليات بين المستخدم والنظام من خلال استدعاء رقم العملية بدلًا من اسمها. كيفية إرسال إشارات للعمليات في لينكستستجيب جميع العمليات في لينكس إلى نظام الإشارات، والإشارات Signals هي أسلوب يتبعه نظام التشغيل لإدارة العمليات (كتعديلها أو إنهائها)، ويقصد بذلك تنفيذ إجراء للعملية عند تمرير إشارة ما. إرسال إشارة لعملية عن طريق PIDيعتبر الأمر kill واحدًا من أكثر الأمثلة شيوعًا عن تمرير إشارة لبرنامج، وكما هو متوقع فإن الوظيفة التي تقوم بها هذه الأداة هي محاولة الإيقاف الإجباري للعملية: kill PID_of_target_processيرسل الأمر السابق إشارة "إمهال" للعملية، والتي تحمل رسالة مفادها: انتهِ رجاءً.. وهذا ما يسمح للبرنامج بتنفيذ عمليات تنظيف الذاكرة والإغلاق بشكل طبيعي، أما فيما لو انتهت مهلة الإشارة ولم يستجب لها البرنامج، فيمكننا زيادة قّوة الإشارة بإضافة المعامل "-KILL" لها: kill -KILL PID_of_target_processفي هذه الحالة لا يتم إرسال الإشارة إلى البرنامج، وبدلًا من ذلك يتم تمريرها إلى نواة نظام التشغيل مباشرةً لإغلاق العملية، تُستعمل هذه الإشارة في الحالات التي لا تستجيب فيها العمليات لطلبات الإنهاء. وكما هو الحال مع العمليات، تملك الإشارات أرقامًا خاصة يمكن استخدامها أثناء تمريرها. على سبيل المثال يمكن تمرير الرقم "-15" بدلا من "-TERM"، و "-9" بدلًا من "-KILL". استخدامات أخرى للإشاراتلا يقتصر عمل الإشارات على إيقاف تشغيل البرامج، بل يمكن تنفيذ إجراءات أخرى معها، مثل إعادة تشغيل بعض خدمات daemons عند تمرير HUP لها، أباتشي Apache واحدة من هذه الخدمات: sudo kill -HUP pid_of_apacheعند تنفيذ الأمر السابق سيعيد Apache تحميل ملف الضبط الخاص به ومن ثم يستأنف الخدمة. لاستعراض جميع الإشارات التي من الممكن استخدامها مع الأمر kill اكتب: kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM . . . إرسال إشارة لعملية باستخدام الاسمعلاوةً على الأسلوب السابق في استخدام معرّفات PID لإرسال الإشارات المختلفة إلى العمليات، تتيح الأداة pkill إرسال الإشارات عن طريق أسماء العمليات نفسها، حيث الأمر: pkill -9 pingيكافئ تمامًا الأمر: kill -9 `pgrep ping` كما يمكنك إرسال إشارة ما إلى مجموعة عمليات من أسرة واحدة باستخدام الأمر: killall: killall firefox حيث يرسل الأمر السابق إشارة المهلة TERM signal لكل عملية نشطة على الكمبيوتر تحمل الاسم firefox. ضبط أولويات العملياتفي إدارتك للخادوم الخاص بك كثيرًا ما ستحتاج إلى كيفية تضبط بها أولويات العمليات، لتحدّد أيها التي ترغب بإعطائها أفضلية قصوى، ففي حالاتٍ متفرقة تكون بعض العمليات حساسة وذات أهمية عالية، بينما يمكن لباقي العمليات أن تنتظر قليلًا من الوقت بينما تتوفر موارد شاغرة. يتم التحكم بأولويات العمليات في لينكس من خلال قيمة يطلق عليها اسم niceness. المهام ذات الأولوية المرتفعة تدعى less nice، باعتبار أنها لا تسمح بمشاركة موارد الخادوم كما يجب، وفي المقابل يطلق على العمليات ذات الأولوية المنخفضة اسم nice باعتبار أنها لا تستهلك سوى أقل قدر من الموارد فقط. وبالعودة إلى مخرجات الأمر top سنجد أن هناك عمود يدعى "NI" والذي يحدد قيمة الـ nice لكل عملية: top Tasks: 56 total, 1 running, 55 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 1019600k total, 324496k used, 695104k free, 8512k buffers Swap: 0k total, 0k used, 0k free, 264812k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1635 root 20 0 17300 1200 920 R 0.3 0.1 0:00.01 top 1 root 20 0 24188 2120 1300 S 0.0 0.2 0:00.56 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:00.11 ksoftirqd/0حيث العمليات التي تأخذ قيمة من المجال "-19/-20" تعتبر ذات أولوية عالية، وتلك التي تأخذ قيمة محصورة ضمن المجال "19/20" تعتبر ذات أولوية منخفضة، وهذا يعتمد على نظام التشغيل. لتشغيل برنامج وفق قيمة محدّدة لـ nice يمكن استعمال الأمر التالي: nice -n 15 command_to_executeللتأكيد؛ الأمر السابق يُستخدم لتشغيل أمر جديد بقيمة محدّدة لـ nice، أما لتغيير قيمة nice لبرنامج يعمل بالفعل فإننا نستخدم أداة تدعي renice: renice 0 PID_to_prioritizeانتبه، بينما تتعامل الأداة nice مع العمليات وفق أسمائها، فإن renice تفعل ذلك باستخدام معرّفات PID، فوجب التفريق. خاتمةأحيانًا يشعر المستخدمون الجدد بصعوبة في فهم إدارة العمليات في لينكس والتعامل معها، باعتبار أن ذلك يتمّ ضمن سطر الأوامر خلافًا لما ألفوه من بدائل في الواجهات الرسومية. غير أن هذه الأفكار ما تلبث أن تصبح مألوفة وسهلة الاستخدام مع بعض الممارسة اليومية، إذ أن تعلم إدارة العمليات في لينكس يعدّ مهارة أساسية في كل ما تفعله مع نظام التشغيل. [1]: دورة حياة العملية أو Process Lifecycle، هي أسلوب في فهم "العمليات" انطلاقا من الحالة الابتدائية لها، مرورًا بمراحل النضج وحتى المرحلة النهائية لتطورها ونموها، حيث فهم وتحليل العمليات بهذا الأسلوب يساعدنا على فهم الكيفية التي تنسجم أو تتناسب بها العمليات مع النظام وفق صيرورة من النمو والنضج. ترجمة -وبتصرّف- للمقال How To Use ps, kill, and nice to Manage Processes in Linux