كيفية إعداد خدمة Linux للتشغيل التلقائي بعد إعادة التشغيل أو انهيار النظام: الجزء 2 (تفسيرات نظرية)

في هذا الجزء الثاني من البرنامج التعليمي المكون من جزأين حول تكوين Linux لتشتغل تلقائيًا بعد إعادة التشغيل أو تعطل النظام، سنناقش نظام init بالتفصيل. يمكنك الرجوع إلى الجزء الأول من السلسلة: كيفية تكوين خدمة Linux للتشغيل التلقائي بعد إعادة التشغيل أو تعطل النظام: أمثلة عملية هنا.

سيركز هذا البرنامج التعليمي الحالي بشكل كبير على الجانب النظري. لذلك، يجب عليك استخدامه كمرجع للحصول على فهم أعمق لكيفية عمل نظام init في Linux. في الجزء الأول من هذا البرنامج التعليمي، شاركنا بعض مقتطفات البرمجية والبرامج النصية لبدء التشغيل التي يقرأها نظام init عند بدء التشغيل. كما استخدمنا أيضًا MySQL كمثال لتعلم كيفية تمكين وتعطيل خدمة Linux للتشغيل التلقائي بعد تعطل النظام أو إعادة التشغيل. كما تعلمت في الجزء الأول من هذا البرنامج التعليمي المكون من جزأين، هناك ثلاثة أنظمة init مستخدمة في توزيعات مختلفة من Linux: وهي System V و Upstart و Systemd. يمكنك الرجوع إلى الجزء الأول من هذا البرنامج التعليمي لفهم التوزيعة والإصدار اللذين تم تكوينهما لاستخدام نظام init معين.

في هذا البرنامج التعليمي، سنشرح الكود الذي استخدمناه في الجزء الأول من البرنامج التعليمي. وسنفصل في الأوامر وملفات التكوين التي يستخدمها نظام init. لنبدأ!

المتطلبات الأساسية

في ختام الجزء الأول من هذا البرنامج التعليمي المكون من جزأين، ذكرنا أنه يجب عليك إبقاء خوادم الاختبار الثلاثة قيد التشغيل. إذا قمت بحذفها، يمكنك العودة وإعادة إنشائها. سيساعدك هذا على المتابعة مع البرنامج التعليمي. خوادم الاختبار الثلاثة التي يجب أن تكون لديك هي:

• Ubuntu 9.04 والإصدارات الأقدم، أو Debian 6 x64 (سنستخدمه لتوضيح نظام init الخاص بـ System V)
• Ubuntu 14.04 x64 (سنستخدمه لتوضيح Upstart). إليك برنامج تعليمي حول كيفية إعداد خادم Ubuntu الخاص بك بسهولة.
• CentOS 7 x64 (سنستخدمه لتوضيح Systemd).

يجب أن يكون لديك مستخدم يتمتع بامتيازات sudo على كل خادم من الخوادم التي ستستخدمها لتشغيل الأوامر. هذا البرنامج التعليمي حول تكوين ملف sudoers الخاص بـ Linux يمكنه توجيهك.

ملاحظة: ستتداخل الأوامر الموجودة في البرنامج التعليمي مع خدمات النظام. لذلك، يجب ألا تطبقها على خادم إنتاج فعلي.

Runlevels

إن runlevel هو مستوى تشغيلي يصف الحالة الحالية لنظام Linux فيما يتعلق بالخدمات المتاحة. ينشأ هذا المفهوم في System V init. عندما يبدأ نظام Linux في العمل، فإنه يقوم بتهيئة النواة (kernel)، ويدخل في runlevel واحد، ويقوم بتشغيل برنامج بدء التشغيل النصي المرتبط بـ runlevel هذا. يمكنك تنفيذ runlevel واحد فقط عند بدء التشغيل.

تشمل الأمثلة الأخرى لـ runlevels حالة إيقاف التشغيل، ووضع إعادة التشغيل، ووضع المستخدم الواحد، وما إلى ذلك. يحدد كل مستوى الخدمات التي سيتم تشغيلها في تلك الحالة. يمكن لبعض الخدمات العمل في أكثر من مستوى بينما لا يمكن لخدمات أخرى ذلك.

هناك سبعة runlevels: من 0 إلى 6. فيما يلي تعريف لـ runlevels السبعة:

• Runlevel 0: إيقاف تشغيل النظام
• Runlevel 1: وضع المستخدم الواحد والإنقاذ
• Runlevels 2, 3, 4: وضع متعدد المستخدمين والوضع النصي مع تمكين الشبكة
• Runlevel 5: وضع متعدد المستخدمين، مُمكّن الشبكة، والوضع الرسومي
• Runlevel 6: إعادة تشغيل النظام

لا يتم بالضرورة تنفيذ Runlevels بشكل متسلسل. تختلف Runlevels 2 و 3 و 4 اعتمادًا على توزيعة Linux التي تقوم بتشغيلها. يمكنك تطبيق runlevel 4 في بعض التوزيعات دون غيرها. عندما قمت بتمكين خدمة للتشغيل التلقائي، كما هو موضح في الجزء الأول، فقد قمت بالفعل بإضافتها إلى runlevel. في System V، يبدأ نظام التشغيل بـ runlevel معين، وأثناء بدء التشغيل، يحاول بدء جميع الخدمات المرتبطة بـ runlevel هذا. تعتبر Runlevels بمثابة أهداف (targets) في Systemd، والتي سنناقشها في قسم Systemd.

Init و PID 1

نظام init هو أول عملية يتم تشغيلها على الإطلاق عند بدء تشغيل نظام Linux وتحميل النواة (Kernel) في الذاكرة. ويقوم بمهام مختلفة بما في ذلك تحديد كيفية تحميل عملية المستخدم أو خدمة النظام، وبأي ترتيب، وما إذا كان ينبغي تشغيلها تلقائيًا. في كل توزيعة Linux، يتم تحديد كل عملية بواسطة معرف العملية (PID) ولدى init معرف PID بقيمة 1. وهو الأصل لجميع العمليات الأخرى التي تبدأ بالتتابع مع بدء تشغيل النظام.

تاريخ init

إن نظام init الموجود في توزيعات Linux الحديثة هو تحسين للنظام الأصلي. استخدمت الإصدارات الأولى من توزيعات Linux نظام System V init، والذي تم استخدامه بشكل مشابه في أنظمة Unix. ومع تطور Linux، تم تطبيق daemon البدء Upstart - والذي تم إنشاؤه بواسطة Ubuntu. الآن، (في وقت كتابة هذا البرنامج التعليمي، 2021) لدينا daemon البدء Systemd - والذي تم تطبيقه لأول مرة بواسطة Fedora. ومع استمرار تطور أنظمة Linux، قد يكون هناك نظام init أحدث. في هذا البرنامج التعليمي، سنناقش هذه الأنظمة الثلاثة: System V و Upstart و Systemd.

تأتي إصدارات Linux الحديثة مع نظام init من نوع Systemd بشكل افتراضي. ومع ذلك، فقد احتفظت بأنظمة init القديمة الأخرى من أجل التوافق مع الإصدارات السابقة. هناك تطبيقات مختلفة لـ System V يمكنك استخدامها في متغيرات أخرى من Linux. على سبيل المثال،  FreeBSD، وهو أحد متغيرات UNIX، يستخدم BSD init. وتستخدم الإصدارات الأقدم من Debian نظام SysVinit. وكلاهما يأتي من System V.

تختلف الطريقة التي يدير بها كل إصدار من daemon البدء الخدمات. كانت التحسينات المضافة إلى كل إصدار موجهة نحو أداة قوية لإدارة الخدمات تتعامل مع كل ما يحتاجه نظام Linux من خدمات وأجهزة ومنافذ وموارد أخرى. كانت هناك حاجة إلى نظام قوي يمكنه تحميل الموارد بالتوازي، ويمكنه التعافي بأناقة من تعطل النظام.

تسلسل بدء System V

يستخدم System V ملف inittab للاحتفاظ بتعليمات التهيئة. يحتفظ Upstart بملف inittab للتوافق مع الإصدارات السابقة. إليك تدفق بدء تشغيل System V:

• يأتي نظام init من الملف الثنائي /sbin/init.
• بمجرد تحميل نظام init في الذاكرة، فإنه يقرأ ملفه الأول في /etc/inittab.
• يحدد أحد الإدخالات في هذا الملف مستوى التشغيل (runlevel) الذي يجب أن يقلع الجهاز فيه. على سبيل المثال، إذا تم تحديد قيمة مستوى التشغيل كـ 5، فسيتم إقلاع Linux في وضع متعدد المستخدمين الرسومي مع تمكين الشبكة (وهو أمر شائع في التوزيعات المصممة للاستخدام المكتبي). يُعرف مستوى التشغيل المحدد هنا بمستوى التشغيل الافتراضي لأنه ما سيتم استخدامه دائمًا.
• بعد ذلك، يبحث نظام init بشكل أعمق في /etc/inittab ويقرأ البرامج النصية لبدء التشغيل (init scripts) التي يحتاج إلى تشغيلها لمستوى التشغيل هذا.

من خلال العثور على البرامج النصية التي يجب تشغيلها لمستوى تشغيل معين، سيجد نظام init الخدمات التي يحتاج إلى تشغيلها. هذه البرامج النصية لبدء التشغيل (init scripts) هي المكان الذي تقوم فيه عادةً بتكوين سلوك بدء التشغيل للخدمات الفردية، بنفس الطريقة التي قمنا بها بتكوين خدمة MySQL في الجزء الأول من هذا البرنامج التعليمي.

بنية البرامج النصية لبدء تشغيل System V

في هذا القسم، سنلقي نظرة على البرامج النصية لبدء التشغيل (init scripts) بالتفصيل. ملفات تكوين System V أو البرامج النصية لبدء التشغيل هي ما يتحكم في الخدمات. تقوم البرامج النصية لبدء التشغيل بـ تهيئة الخدمة، ومن هنا جاء اسم البرنامج النصي لبدء التشغيل (init script).

لكل خدمة برنامج نصي لبدء التشغيل خاص بها. على سبيل المثال، يتحكم البرنامج النصي لبدء تشغيل MySQL في خادم MySQL. يوفر بائعو التطبيقات البرامج النصية لبدء التشغيل لتطبيقاتهم الخاصة، بينما تأتي خدمات Linux الأصلية مع تثبيت نظام التشغيل. عندما تقوم بإنشاء تطبيق مخصص، يمكنك أيضًا إنشاء برامج نصية مخصصة لبدء التشغيل له.

لبدء خدمة مثل خادم MySQL، يتم أولاً تحميل برنامجه الثنائي في الذاكرة. اعتمادًا على تكوينه، قد يستمر البرنامج في العمل في الخلفية لمواصلة قبول اتصالات العملاء. يتعامل البرنامج النصي لبدء تشغيل الخدمة مع مهمة بدء تشغيل التطبيق الثنائي أو إيقافه أو إعادة تحميله. البرامج النصية لبدء التشغيل في System V هي برامج شل نصية (shell scripts). والاسم الآخر لها هو برامج rc (run command) النصية.

بنية دليل System V

الدليل الأب للبرامج النصية لبدء التشغيل هو الدليل /etc. والدليل /etc/init.d هو الدليل الفعلي لبرامج شل النصية لبدء التشغيل. يتم ربط البرامج النصية بروابط رمزية (symlinked) إلى أدلة rc.

هناك العديد من أدلة rc داخل الدليل /etc، ولكل منها رقم في اسمه. تمثل الأرقام مستويات تشغيل مختلفة. إذا قمت بسرد محتويات الدليل، فسترى أسماء مثل /etc/rc0.d, /etc/rc1.d, /etc/rc2.d، إلخ.

إذا قمت بعرض محتويات كل دليل من أدلة rc، فسترى ملفات تبدأ بـ K أو S في اسم الملف الخاص بها، متبوعة برقمين. تحتوي هذه الملفات على روابط رمزية تشير إلى البرامج النصية الفعلية لغلاف init للبرنامج الفعلي. الحروف K و S هي اختصارات: K تعني إنهاء أو إيقاف، بينما ترمز S إلى بدء التشغيل. يمثل الرقمان في أسماء الملفات ترتيب التنفيذ. إذا رأيت ملفًا باسم K05script_name، فسيتم تنفيذه قبل ملف باسم K09script_name.

بدء التشغيل

متابعةً لتسلسل بدء التشغيل، دعنا نرى كيف يتم استدعاء البرامج النصية لـ init.

لا يتم استدعاء البرامج النصية S و K مباشرة بواسطة نظام init. بل يتم استدعاؤها بواسطة برنامج نصي آخر: وهو /etc/init.d/rc . يوجه ملف /etc/inittab برنامج init الخفي إلى مستوى التشغيل الذي يجب أن يقوم النظام بالتمهيد فيه افتراضيًا. اعتمادًا على مستوى التشغيل المحدد، يقوم سطر في ملف /etc/inittab باستدعاء البرنامج النصي /etc/init.d/rc، ممررًا مستوى التشغيل الافتراضي كمعلمة. باستخدام هذه المعلمة، سيقوم البرنامج النصي باستدعاء الملفات الموجودة تحت دليل /etc/rc المقابلN.d، حيث يشير N إلى مستوى التشغيل. على سبيل المثال، إذا تم تمهيد الخادم بمستوى التشغيل 5، فسيتم استدعاء الملفات المقابلة تحت دليل /etc/rc5.d.

داخل دليل rc، يتم تشغيل جميع البرامج النصية K رقميًا مع وسيطة stop، بينما يتم تشغيل جميع البرامج النصية S بشكل مشابه مع وسيطة start. سيتم استدعاء البرامج النصية الفعلية لغلاف init المقابلة للبرنامج الذي تشير إليه الروابط الرمزية تحت /etc/rcN.d مع المعلمتين stop و start على التوالي.

بعبارات بسيطة، ما يحدث عندما يدخل نظام Linux أو ينتقل إلى مستوى تشغيل معين هو أنه سيتم تشغيل برامج نصية معينة لإيقاف بعض الخدمات، بينما سيتم تشغيل برامج أخرى لبدء خدمات أخرى. تضمن هذه العملية إيقاف أي عملية ليس من المفترض تشغيلها في حالة Linux معينة، وبدء تشغيل أي عملية يجب تشغيلها تلقائيًا.

بدء التشغيل التلقائي لـ System V

عندما تقوم بتمكين خدمة لتبدأ تلقائيًا عند التمهيد، فإنك تقوم بتعديل سلوك init مباشرة. على سبيل المثال، إذا قمت بتكوين خدمة لتبدأ تلقائيًا عند مستوى التشغيل 2، فإن عملية init تنشئ الروابط الرمزية المناسبة في دليل /etc/rc2.d. لمساعدتك على الفهم، سنشرح ذلك بمثال.

مثال على System V

لإعطائك مثالاً عمليًا، سنستخدم تكوين خدمة MySQL من الجزء 1. وبالتالي، قم بتسجيل الدخول إلى Debian 6 VPS باستخدام مستخدم sudo/root الخاص بك عبر ssh (أو putty إذا كنت تستخدم نظام التشغيل Windows)، وتابع الخطوات التالية.

الخطوة 1: افتح ملف inittab وافحصه

أولاً، أدخل الأمر التالي لعرض محتويات ملف inittab على الطرفية:

يجب أن تكون محتويات الملف شيئًا كالتالي:

يشير الرقم 2 إلى مستوى التشغيل الذي يبدأ به النظام. في هذه الحالة، يكون مستوى التشغيل 2 هو الافتراضي، وبالتالي سيبدأ نظام Debian هذا في مستوى التشغيل 2 كوضع نصي متعدد المستخدمين. يمكنك تشغيل الأمر التالي للتأكيد:

سيعرض مخرجات مشابهة لـ:

الخطوة 2: فحص أدلة rc

بعد ذلك، لسرد أدلة rc، قم بتشغيل الأمر التالي:

إليك لقطة شاشة للمخرجات:

كما رأينا في ملف inittab سابقًا، تم تكوين النظام للتمهيد في runlevel 2، وبالتالي فإن البرامج النصية تحت /etc/rc2.d سيتم تنفيذها عند بدء تشغيل النظام. يمكنك سرد محتويات هذا الدليل باستخدام الأمر:

كما ترى من المخرجات، فإن الملفات هي مجرد روابط رمزية تشير إلى ملفات البرامج النصية الفعلية تحت /etc/init.d . إليك مقتطف من المخرجات:

لا توجد برامج نصية K في هذا الدليل، فقط برامج نصية S (بدء التشغيل). ستبدأ البرامج النصية الخدمات المرتبطة هنا، مثل rsync . يمكنك أيضًا ملاحظة خدمة mysql المدرجة والتي نناقشها في الموضوع الفرعي التالي.

الخطوة 3: فحص برنامج Init النصي

عندما يتم تثبيت خدمة متوافقة مع System V، فإنها تنشئ نصًا برمجيًا لـ shell تحت دليل /etc/init.d. يمكنك التحقق من توفر النص البرمجي لـ MySQL shell عن طريق إدخال الأمر التالي:

يظهر المخرجات أدناه:

الملف كبير جدًا. يمكنك إدخال الأمر التالي لعرض محتوياته:

الخطوة 4: استخدام chkconfig أو sysv-rc-conf

Chkconfig هو أمر يمكنك استخدامه في التوزيعات المبنية على RHEL مثل CentOS لتمكين أو تعطيل الخدمات المتوافقة مع System V. يمكنك أيضًا استخدامه لسرد الخدمات المثبتة ومستويات التشغيل (runlevels) الخاصة بها. إليك الأمر الخاص بذلك (يعمل على CentOS):

في توزيعات Debian، لا توجد مثل هذه الأداة المساعدة بشكل أصلي. تقوم أداة update-rc.d في أنظمة Debian فقط بتثبيت وإزالة الخدمات من مستويات التشغيل (runlevels). تتوفر أداة مخصصة يمكنك استخدامها لجلب وظائف chkconfig إلى أنظمة Debian. أدخل الأمر التالي لتثبيتها:

بمجرد تثبيتها، يمكنك تشغيل الأمر التالي لعرض سلوكيات مستوى التشغيل (runlevel) لمختلف الخدمات:

يتم تنسيق مخرجات هذا الأمر في جدول يوضح اسم الخدمة على اليسار ومستوى التشغيل (runlevel) الذي تعمل الخدمة تحته:

يشير الحرف X إلى مستوى التشغيل (runlevel) الذي ستعمل الخدمة تحته. تتيح لك هذه الأداة تعطيل أو تمكين خدمة لمستوى تشغيل معين باستخدام مفاتيح الأسهم ومسطرة المسافة. للخروج من الأداة، اضغط على Q.

الخطوة 5: اختبار سلوك بدء تشغيل MySQL أثناء إقلاع النظام

من لقطة الشاشة أعلاه، يمكنك رؤية أن خدمة mysql مُمكّنة في مستويات التشغيل 2,3,4,5. يمكنك تعطيل MySQL باستخدام الأمر التالي:

تبدو المخرجات كالتالي. لاحظ أن الخدمة قد توقفت لجميع مستويات التشغيل:

قم بتشغيل الأمر أدناه لرؤية محتويات الدليل:

انظر إلى سطر mysql في المخرجات أدناه:

تظهر المخرجات أن الرابط الرمزي (symlink) قد تغير إلى K، مما يعني Kill (إيقاف). وبالتالي، لن يتم تشغيل MySQL تلقائيًا بشكل افتراضي عند مستوى التشغيل 2. يحدث هذا في كل مرة تقوم فيها بتمكين أو تعطيل خدمة في System V. طالما يوجد نص برمجي S (بدء) تحت دليل مستوى التشغيل الافتراضي للخدمة، فإن init daemon سيبدأ تشغيل تلك الخدمة أثناء إقلاع النظام.

لتمكين الخدمة مرة أخرى، أدخل الأمر التالي:

الخطوة 6: اختبار سلوك بدء تشغيل MySQL بعد تعطل النظام

في هذا القسم، سنناقش كيف يتعامل System V مع حالات تعطل الخدمة. يمكنك استخدام هذه المعرفة لتكوين سلوك خدماتك المخصصة بعد التعطل.

في الجزء الأول من هذا البرنامج التعليمي، قمنا بإجراء تغيير على ملف /etc/inittab لتمكين MySQL من البدء تلقائيًا بعد التعطل. أضفنا السطر التالي لتمكين هذا السلوك:

يمكننا التحقق من هذا السلوك عن طريق إجراء بعض الاختبارات. أولاً، أعد تشغيل VPS الخاص بك عن طريق إدخال الأمر التالي:

بعد إعادة التشغيل، تحقق من معرفات العمليات (process IDs) التي يعمل بها mysql_safe و mysqld، وأدخل الأمر التالي للحصول على معرفات العمليات:

المخرجات التي حصلنا عليها هي:

دوّن معرفات العمليات (process IDs). في حالتنا، كانت 1836 و 186338. الآن، قم بمحاكاة حدوث عطل عن طريق إنهاء العملية باستخدام الخيار -9 عن طريق إدخال الأمر التالي. تذكر استبدالها بمعرفات العمليات الخاصة بك:

بعد بضع دقائق، تحقق من حالة MySQL عن طريق تشغيل الأمر التالي:

تشير المخرجات إلى أن MySQL قيد التشغيل، مما يعني أنه تمت إعادة تشغيله تلقائيًا بعد العطل المحاكى. إذا قمت بتشغيل ps -ef | grep mysql مرة أخرى، ستجد أن كلا من mysqld_safe و mysqld قيد التشغيل، وإن كان بمعرفات جديدة.

يمكنك محاولة إنهاء العمليات عدة مرات وستتم إعادة تشغيلها بعد بضع دقائق. هذا السلوك ممكن بفضل السطر الذي أضفناه إلى ملف /etc/inittab. هذه هي الطريقة التي تقوم بها بتهيئة الخدمات لإعادة التشغيل تلقائيًا بعد حدوث عطل في System V. لرؤية الصيغة البرمجية مرة أخرى، ألقِ نظرة على الجزء الأول من هذا البرنامج التعليمي.

قد تحتوي بعض الخدمات المخصصة على أخطاء برمجية وتفشل في إعادة التشغيل بعد محاولات متعددة. ستحاول خدمة init daemon إعادة تشغيل الخدمة، ولكن إذا فشلت أكثر من عشر مرات في غضون دقيقتين، فإن نظام Linux يعطل الخدمة لمدة تصل إلى 5 دقائق. يساعد هذا في الحفاظ على استقرار النظام وضمان عدم إهدار موارد النظام على الخدمات المعطلة. من الجيد التحقق من سجلات النظام لتحديد المشكلات في تطبيقاتك المخصصة التي تحتاج إلى إصلاح.

مقدمة عن Upstart

لقد كان نظام التهيئة System V init حاسمًا لتوزيعات Linux لفترة طويلة. ومع ذلك، كما هو الحال مع التكنولوجيا، فإنها تستمر في التقدم. لقد نما نظام Linux البيئي بشكل هائل بفضل الدعم من مجتمع المصادر المفتوحة. يقوم System V بتحميل المهام والخدمات بطريقة متسلسلة مما يؤدي إلى التعقيد ويستهلك الوقت. بالإضافة إلى ذلك، فإن إدخال وسائط التخزين الحديثة القابلة للتوصيل والتي لم يكن System V مصممًا لها أدى إلى الحاجة إلى نظام تهيئة مختلف.

بدأ المطورون في Ubuntu العمل على نظام تهيئة آخر. تم تصميم نظام التهيئة هذا للتعامل مع تحميل أسرع لنظام التشغيل، وضمان التنظيف السلس للخدمات المعطلة، والحفاظ على إمكانية التنبؤ بالاعتمادية بين خدمات النظام، ومراعاة وسائط التخزين القابلة للتوصيل. وهكذا وُلد برنامج Upstart daemon.

يتمتع Upstart init بالعديد من المزايا مقارنة بـ System V init بالطرق التالية:

• لا يقوم Upstart بتحميل الخدمات بشكل متسلسل مثل System V، مما يقلل من وقت إقلاع النظام.
• لقد تم تصميمه للتعامل مع الخدمات المعطلة بشكل أفضل مع التنظيف السلس وإعادة تشغيل الخدمة.
• يستخدم Upstart نظام أحداث مرنًا لتخصيص التعامل مع الخدمات في حالات مختلفة.
• يتجنب نظام التهيئة هذا نصوص shell المعقدة لتحميل الخدمات وإدارتها كما هو الحال في System V. يستخدم Upstart ملفات تهيئة بسيطة يسهل فهمها وتعديلها.
• تم بناء Upstart مع مراعاة التوافق مع الإصدارات السابقة. لا يزال البرنامج النصي /etc/init.d/rc يعمل لإدارة خدمات System V الأصلية.
• يتجنب الاحتفاظ بالروابط الرمزية المكررة، والتي تشير جميعها إلى نفس البرنامج النصي.

أحداث Upstart

يعتمد Upstart على الأحداث، مما يسمح بربط أحداث متعددة بنفس الخدمة. تضمن هذه البنية القائمة على الأحداث إدارة مرنة للخدمات. يمكن لكل حدث استدعاء برنامج نصي shell خاص بالحدث.

تشمل أحداث Upstart ما يلي:

• البدء (Starting)
• تم البدء (Started)
• الإيقاف (Stopping)
• تم الإيقاف (Stopped)

بين حدث وآخر، يمكن أن تكون الخدمة في حالات مختلفة تشمل على سبيل المثال لا الحصر:

• الانتظار (Waiting)
• ما قبل البدء (Pre-start)
• البدء (Starting)
• ما بعد البدء (Post-start)
• التشغيل (Running)
• ما قبل الإيقاف (Pre-stop)
• الإيقاف (Stopping)
• ما بعد الإيقاف (Post-stop)

يمكن تهيئة Upstart init لاتخاذ إجراءات لكل حالة من هذه الحالات، ومن هنا يأتي تصميمه المرن.

تسلسل بدء تشغيل Upstart Init

يقوم Upstart init بتشغيل برنامج /etc/init.d/rc النصي عند بدء التشغيل، تمامًا مثل System V. يقوم هذا البرنامج النصي بتشغيل أي برامج نصية لتهيئة System V بشكل طبيعي لضمان التوافق مع الإصدارات السابقة.

توجد ملفات تهيئة Upstart في دليل /etc/init لذا فإنه يبحث هناك افتراضيًا وينفذ أوامر shell الموجودة في ملفات التهيئة تحت هذا الدليل.

ملفات تهيئة Upstart

يستخدم نظام بدء التشغيل Upstart ملفات تكوين الخدمة للتحكم في الخدمات، على عكس البرامج النصية لـ bash المستخدمة في System V. معيار التسمية لملفات تكوين الخدمة هذه هو service_name.conf.

تحتوي الملفات على محتوى نصي عادي مقسم إلى أقسام مختلفة تسمى stanzas (فقرات). تصف كل فقرة حالة مختلفة للخدمة وسلوكها. وتتحكم الفقرات المختلفة في أحداث مختلفة للخدمة. على سبيل المثال، الانتظار (waiting)، ما قبل البدء (pre-start)، البدء (start)، ما قبل الإيقاف (pre-stop)، الإيقاف (stopping)، إلخ.

تحتوي الفقرة (stanza) على أوامر shell، مما يجعل من الممكن بدء إجراءات متعددة لكل حدث لكل خدمة. بالإضافة إلى ذلك، يحدد كل ملف تكوين خدمة الأمرين التاليين:

• مستويات التشغيل (runlevels) التي يجب أن تبدأ الخدمة وتتوقف عندها.
• ما إذا كان يجب إعادة تشغيل الخدمة تلقائيًا (respawn) في حالة تعطلها.

بنية دليل Upstart

توجد ملفات تكوين خدمة Upstart تحت الدليل /etc/init. لا تخلط بينه وبين /etc/init.d.

مثال على Upstart

في هذا المثال، سنرى كيف يتعامل Upstart مع الخدمة أثناء تمهيد النظام وفي حالة حدوث عطل. سنتطرق إلى مزيد من التفاصيل لشرح الأمثلة العملية الموضحة في الجزء الأول من هذا البرنامج التعليمي.

الخطوة 1: تسجيل الدخول إلى خادم Ubuntu 14.0.4

أولاً، لاختبار Upstart، سنستخدم خادم VPS الثاني، وهو الخادم الذي يعمل بنظام التشغيل Ubuntu 14.0.4. وذلك لأن توزيعة Linux هذه تطبق Upstart بشكل أصلي. استخدم ssh أو putty إذا كنت تستخدم نظام التشغيل Windows. يجب عليك تسجيل الدخول بمستخدم يتمتع بامتيازات root أو sudo. لدي مستخدم يسمى hackins، وهذه هي الطريقة التي سأسجل بها الدخول:

استبدله بمستخدم root/sudo وعنوان IP العام لخادمك. ثم اضغط على enter، وأدخل كلمة المرور أو عبارة المرور.

الخطوة 2: فحص دليل init و rc

يتم تخزين ملفات تكوين Upstart في الدليل /etc/init. وهو الدليل الذي ستستخدمه عند إنشاء ملفات تكوين خدمة جديدة.

لسرد أسماء ملفات التكوين في الدليل /etc/init، قم بتنفيذ الأمر التالي:

كما سترى من مخرجات الأمر أعلاه، هناك العديد من الخدمات التي تعمل تحت Upstart. اضغط على Q للخروج من less.

إذا قمت بتشغيل ما يلي لسرد ملفات تكوين الخدمة لـ System V في دليل rc، فسترى القليل منها فقط:

الخطوة 3: فحص ملف Upstart

في الجزء الأول من هذا البرنامج التعليمي، استخدمنا ملف mysql.conf للتعرف على تكوين الخادم. للإضافة إلى معرفتنا، دعنا نستخدم تكوينًا مختلفًا. ملف تكوين cron هو مرشح جيد. أدخل الأمر التالي لفتح الملف:

يجب أن تحصل على مخرجات مشابهة للقطة الشاشة أدناه:

البرنامج النصي مباشر للغاية. انتبه إلى الحقول المهمة التالية: start on, stop on, fork، و respawn. دعنا نحدد ما تفعله هذه التوجيهات:

• start on يوجه Ubuntu لبدء تشغيل cron daemon عندما يدخل النظام في مستويات التشغيل 2 أو 3 أو 4 أو 5. ولن يعمل في مستويات التشغيل الأخرى غير المحددة هنا، أي 0 أو 1 أو 6.
• stop on يوجه Ubuntu لإيقاف daemon قيد التشغيل. ومع ذلك، في هذه الحالة، توجد علامة تعجب (!) وهي علامة نفي. لا ينبغي إيقاف البرنامج النصي في مستويات التشغيل بعد علامة التعجب: 2,3,4,5.
• fork يوجه التوجيه Upstart بفصل العملية عن وحدة التحكم وإبقائها قيد التشغيل في الخلفية.
• respawn يوجه التوجيه النظام لبدء تشغيل cron تلقائيًا إذا تعطل لأي سبب من الأسباب.

اضغط على Ctrl X للخروج من المحرر دون كتابة أي شيء.

تتبع ملفات تكوين upstart الأخرى نفس البنية، مع فقرات (stanzas) للبدء والإيقاف وإعادة التشغيل (respawn). قد تحتوي بعض ملفات التكوين على كتل برمجية نصية إضافية لـ pre-start و pre-stop و post-start والمزيد. تخبر كتل التعليمات البرمجية هذه النظام بما يجب تنفيذه عندما تكون العملية في أي من الحالات المحددة.

الخطوة 4: اختبار سلوك بدء تشغيل خدمة MySQL بعد تمهيد النظام

بشكل افتراضي، تم ضبط MySQL لتبدأ تلقائيًا بعد إقلاع النظام. سنحاول تعطيلها ورؤية السلوك. في Upstart، يمكن تعطيل الخدمة عن طريق إنشاء ملف يسمى service_name.override تحت المجلد /etc/init/. محتوى الملف هو كلمة واحدة فقط: manual.

دعنا نرى كيف يمكننا استخدام هذا الأمر لتعطيل خدمة MySQL. أدخل الأمر التالي لفتح الملف باستخدام محرر nano:

في الملف المفتوح أضف السطر التالي:

احفظ التغييرات بالضغط على Ctrl + O، ثم اضغط enter. اخرج من المحرر بالضغط على Ctrl + X. قم بتشغيل الأمر التالي لإعادة تشغيل الخادم:

انتظر بضع دقائق ثم سجل الدخول مرة أخرى. بمجرد تسجيل الدخول مجددًا، اختبر حالة خدمة MySQL عن طريق إدخال الأمر التالي:

ستشير المخرجات إلى أن الخدمة لا تعمل:

يشير هذا إلى أن MySQL لم تبدأ تلقائيًا بعد إقلاع النظام. بعد ذلك، افتح ملف تكوين MySQL وتحقق مما إذا كان التوجيه start قد تغير:

ستشير المخرجات إلى أنه لم يتم تغيير أي شيء:

هذا يعني أنه إذا كانت خدمتك لا تبدأ تلقائيًا، وقمت فقط بالتحقق من ملف تكوين الخدمة (service_name.conf)، فقد لا تجد الخطأ. يجب عليك أيضًا التحقق من وجود ملف service_name.override في المجلد.

أدخل الأمر التالي لحذف ملف التجاوز وإعادة تمكين خدمة MySQL. ثم، أعد تشغيل الخادم:

بمجرد إقلاع الخادم، اختبر حالة خدمة MySQL مرة أخرى:

يجب أن يظهر أن خدمة MySQL قد بدأت تلقائيًا.

الخطوة 5: اختبار سلوك بدء تشغيل خدمة MySQL بعد تعطل النظام

بشكل افتراضي، تعيد خدمة MySQL التشغيل تلقائيًا إذا تعطلت. لإيقاف هذا السلوك، سنقوم بتعديل ملف mysql.conf. أدخل الأمر التالي لفتح الملف باستخدام محرر nano:

ابحث عن أسطر توجيه respawn وقم بتعليقها كما هو موضح أدناه باستخدام #:

نفذ الأوامر التالية لإعادة تشغيل الخدمة:

لقد استخدمنا الأوامر المذكورة أعلاه لإيقاف الخدمة وبدء تشغيلها لأن استخدام initctl restart أو initctl reload لن يعمل هنا. عند تشغيل الأمر لبدء تشغيل خدمة MySQL، ستعرض المخرجات معرف عملية (PID) لـ MySQL مثل:

كان معرف العملية (PID) لدينا هو 1439. بعد ذلك، قم بتدوين ما حصلت عليه عند تشغيل الأمر، وسنستخدمه في الخطوة التالية. لمحاكاة تعطل، قم بإنهاء عملية MySQL باستخدام الأمر التالي، وتذكر استبدال معرف العملية (PID) الخاص بك كما هو موضح أعلاه:

للتحقق مما إذا كانت MySQL قد أعادت التشغيل بعد التعطل، انتظر بضع دقائق ثم أدخل الأمر التالي:

ستشير المخرجات إلى أن MySQL متوقفة:

حاول التحقق من الحالة بضع مرات أخرى لمعرفة ما إذا كان هناك أي تغيير. ستلاحظ أن MySQL تظل متوقفة. هذا لأن ملف تكوين الخدمة لا يحتوي على توجيهات respawn (تلك التي قمنا بتعليقها). راجع الجزء الأول من هذا البرنامج التعليمي لمزيد من الشرح حول توجيه respawn.

لماذا أوضحنا لك كيفية تعطيل إعادة التشغيل التلقائي للخدمات بعد تمهيد النظام أو تعطله؟ هذا مخصص بشكل أساسي لأغراض استكشاف الأخطاء وإصلاحها. إذا بدأت خدمتك واستمرت في التعطل على سبيل المثال، فقد ترغب في تعطيلها حتى تتمكن من استكشاف الأخطاء وإصلاحها، وكذلك الحفاظ على استقرار نظامك. يمكنك أيضًا منع بعض تكوينات الخدمات القديمة من إعادة التشغيل تلقائيًا إذا قمت بالترقية إلى توزيعة Linux جديدة تأتي بشكل أصلي مع systemd الذي تمت مناقشته في القسم التالي.

مقدمة في Systemd

Systemd هو أحدث نظام تهيئة، والموجود في أحدث توزيعات Linux. وهو يتضمن العديد من المكونات التي تشكل نظام Linux حديثًا.

Systemd لا يدير الخدمات فحسب، بل يدير أيضًا نظام Linux بأكمله. في هذا القسم، سنركز على كيفية تحكم systemd في سلوك الخدمات بعد تمهيد النظام أو تعطله.

يتوافق Systemd مع الإصدارات السابقة من البرامج النصية وأوامر التهيئة لـ System V. وبالتالي، إذا كان لديك أي خدمات مكوّنة لـ System V، فستعمل أيضًا تحت مظلة Systemd. تم تعديل معظم الأوامر الإدارية لـ Upstart و System V لتعمل مع Systemd. يعيد Systemd تسمية نفسه إلى init في وقت التمهيد. يوجد ملف /sbin/init يرتبط برابط رمزي بـ /bin/systemd.

ملفات تكوين Systemd: ملفات الوحدات

يتكون تكوين Systemd من ملفات وحدات. يمثل كل ملف وحدة موردًا من موارد النظام. في حين أن نظامي التهيئة الآخرين (أي System V و Upstart) كانا مسؤولين عن إدارة خدمات نظام Linux، فإن Systemd لا يدير شياطين الخدمات فحسب، بل يدير أيضًا أنواعًا أخرى من موارد النظام مثل مسارات نظام تشغيل الأجهزة، والمقابس، ونقاط التحميل، وما إلى ذلك. تخزن ملفات الوحدات معلومات حول المورد.

يمثل كل ملف وحدة مورد نظام معينًا بأسلوب تسمية service_name.unit_type. هذا يعني أنك ستجد ملفات مثل home.mount و dbus.service و sshd.socket وما إلى ذلك. ملفات الوحدات هي ملفات نصية بسيطة ذات صيغة تعريفية يسهل فهمها وتعديلها.

بنية الدليل

الموقع الرئيسي لملفات الوحدات الأصلية هو الدليل /lib/systemd/system/. يتم تخزين ملفات الوحدات التي تقوم بإنشائها أو تلك التي تم إنشاؤها خصيصًا بواسطة مسؤولي النظام، وملفات الوحدات الأصلية المعدلة الأخرى في الدليل /etc/systemd/system.

إذا كان هناك ملف وحدة بنفس الاسم موجودًا في كل من الدليلين /lib/systemd/system/ و /etc/systemd/system، فسيستخدم systemd الملف الموجود تحت الدليل /etc.

عند تمكين خدمة لتبدأ في وقت التمهيد أو أي هدف/مستوى تشغيل آخر، يتم إنشاء ارتباط رمزي لملف وحدة الخدمة هذا تحت الأدلة المناسبة في /etc/systemd/system. ملفات الوحدات في الدليل /etc/systemd/system هي مجرد ارتباطات رمزية للملفات ذات الاسم المماثل في الدليل /lib/systemd/system.

تسلسل تهيئة Systemd: وحدات الهدف

وحدات الهدف هي أنواع فريدة من ملفات الوحدات التي تنتهي عادةً بـ .target. تختلف وحدات الهدف عن الأنواع الأخرى من ملفات الوحدات لأنها لا تمثل موردًا معينًا واحدًا. بدلاً من ذلك، فهي تمثل حالة النظام بأكمله في وقت معين.

لتحقيق ذلك، تقوم وحدات الهدف بتجميع وتشغيل ملفات وحدات متعددة تشكل جزءًا من حالة معينة. في حين يمكن مقارنة أهداف Systemd ومستويات تشغيل System V بشكل تقريبي، إلا أنهما ليسا متطابقين. يحتوي ملف وحدة الهدف على اسم بدلاً من رقم. على سبيل المثال، ستجد شيئًا مثل multi-user.target بدلاً من runlevel 3 أو reboot.target بدلاً من runlevel 6. قد يتم تمهيد نظام Linux باستخدام multi-user.target. في هذه الحالة، فإنه ينقل الخادم بشكل أساسي إلى مستوى التشغيل 2 أو 3 أو 4، مما يبدأ تشغيل النظام في وضع النص متعدد المستخدمين مع تمكين الشبكة.

يكمن الاختلاف في كيفية نقل الخادم إلى هذا المستوى. يقوم System V بتشغيل الخدمات بالتسلسل. من ناحية أخرى، أثناء تمهيد النظام، يتحقق systemd مما إذا كانت هناك خدمات أو موارد أخرى موجودة ويحدد ترتيب تحميلها.

هناك اختلاف آخر بين وحدات أهداف systemd ومستويات التشغيل في System V وهو أن توزيعة Linux التي تستخدم System V ستوجد في مستوى تشغيل واحد فقط. إذا قمت بتعديل مستوى التشغيل، فسينتقل ببساطة إلى مستوى التشغيل الجديد هذا ويوجد فيه. من ناحية أخرى، يمكن أن تكون ملفات وحدات الأهداف شاملة. علاوة على ذلك، فإن تنشيط وحدة هدف يضمن تحميل وحدات أهداف أخرى كجزء منها. على سبيل المثال، إذا قمت بتمهيد نظام Linux بواجهة مستخدم رسومية، فسيكون لديه graphical.target نشطًا. وهذا بدوره يضمن تلقائيًا أن multi-user.target قد تم تحميله وتنشيطه أيضًا.

إليك جدول يقارن بين مستويات التشغيل والأهداف.

مستوى التشغيل (System V)	وحدات الأهداف (systemd)
مستوى التشغيل 0	poweroff.target
مستوى التشغيل 1	rescue.target
مستوى التشغيل 2,3,4	multi-user.target
مستوى التشغيل 5	graphical.target
مستوى التشغيل 6	reboot.target

default.target لـ Systemd

في systemd، default.target هو المكافئ لمستوى التشغيل الافتراضي في System V. لقد رأينا أن مستوى التشغيل الافتراضي في System V تم تحديده في ملف inittab. في systemd، لدينا ملف default.target . يتم تخزين ملف الهدف الافتراضي في دليل /etc/systemd/system . وهو يرتبط برابط رمزي بأحد ملفات وحدات الأهداف تحت /lib/systemd/system . وتغيير الهدف الافتراضي يعني ببساطة إعادة إنشاء رابط رمزي وتعديل مستوى تشغيل النظام.

في System V، حدد ملف inittab الدليل الذي سيجد فيه Linux نصوص init البرمجية. يمكن أن يكون هذا أيًا من أدلة rc كما تم توضيحه سابقًا. من ناحية أخرى، يحدد الهدف الافتراضي لـ systemd وحدات الموارد التي سيتم تحميلها في وقت التمهيد. يتم تحميل جميع الوحدات المحددة. ومع ذلك، لا يتم تحميلها جميعًا بالتوازي، ولا يتم تحميلها جميعًا بالتتابع. يعتمد تحميل وحدة الموارد على الموارد الأخرى التي تريدها أو تتطلبها.

تبعيات Systemd: Wants و Requires

في هذا القسم، سنناقش كيف يتعامل Systemd مع التبعيات. لقد رأينا أنه مع Upstart، يمكن تحميل الخدمات بالتوازي عند استخدام ملفات التكوين. ناقشنا أيضًا كيف يستخدم System V مستويات التشغيل لتحديد الخدمة التي سيتم تشغيلها تلقائيًا أو الانتظار حتى تظهر خدمة أو مورد آخر. وبالمثل، يمكن تكوين خدمات Systemd للتحميل في هدف واحد أو أكثر، أو الانتظار حتى تظهر خدمة أو مورد آخر.

في Systemd، ملف الوحدة الذي يتطلب وحدة أخرى لن يبدأ حتى يتم تحميل الوحدة المطلوبة وتصبح نشطة. إذا فشل تحميل الوحدة المطلوبة أثناء نشاط الوحدة الأولى، فستتوقف الوحدة الأولى.

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

على النقيض من ذلك، فإن الوحدة التي تريد وحدة أخرى لا تفرض مثل هذه القيود. لن تتوقف إذا توقفت الوحدة المطلوبة بينما لا تزال الوحدة المستدعية نشطة. على سبيل المثال، بعض الخدمات غير الأساسية في وضع graphical-target.

مثال على Systemd

دعنا نرى كيف يمكننا تكوين سلوك الخدمة تحت systemd.

الخطوة 1: تسجيل الدخول إلى مثيل VPS الخاص بك

سنستخدم MySQL كخدمة حقيقية و CentOS 7 كخادم. للمرور بالخطوات عمليًا وفهم المفاهيم، قم بتسجيل الدخول إلى CentOS 7 VPS الخاص بك أو أنشئ واحدًا على CloudSigma . إن VPS الذي يعمل بتوزيعة CentOS 7 أو Debian 7 أو 8 أو Ubuntu 15 أو أحدث مناسب لهذا القسم لأنها تأتي جميعًا مع systemd. قم بتسجيل الدخول باستخدام أمر ssh أو إذا كنت تستخدم نظام التشغيل Windows، فاستخدم PuTTY:

الخطوة 2: فحص ملف default.target والتبعيات

تتبع سلسلة بدء تشغيل Systemd سلسلة طويلة من التبعيات التي سنناقشها بالتفصيل في هذا القسم.

• default.target

يتحكم ملف default.target في الخدمات التي تبدأ أثناء التمهيد العادي. يمكنك سرد ملف وحدة الهدف الافتراضي باستخدام الأمر التالي:

يظهر المخرج شيئًا مثل لقطة الشاشة أدناه:

توضح لقطة الشاشة أن الهدف الافتراضي يرتبط برابط رمزي بملف multi-user.target في /lib/systemd/system/ . هذا يعني أنه بشكل افتراضي، سيقوم النظام بالإقلاع تحت multi-user.target، وهو ما يعادل مستوى التشغيل 3.

• multi-user.target.wants

لعرض جميع الخدمات التي يحتاجها ملف multi-user.target، أدخل الأمر التالي:

يحتوي المخرج على الكثير من الأسطر، إليك مقتطفًا منها:

كما يوضح المخرج، فهي عبارة عن روابط رمزية تشير إلى ملفات الوحدات الفعلية في دليل /lib/systemd/system/ . لقد قمنا بتمييز mysqld.service لنوضح لك أنه أيضًا جزء من multi-user.target. إذا كنت ترغب في التأكد مما إذا كانت خدمة معينة مهيأة لبدء التشغيل، يمكنك تعديل الأمر الخاص بهذا الملف. على سبيل المثال، يمكننا تصفية المخرجات للعثور على برنامج mysql أو cron الخفي باستخدام الأوامر التالية:

سيظهر المخرج:

لتصفية النتيجة لبرنامج cron الخفي، أدخل الأمر التالي:

سيظهر المخرج:

بصرف النظر عن multi-user.target، توجد أنواع مختلفة أخرى من الأهداف، مثل system-update.target أو basic.target.

أدخل الأمر التالي لمعرفة الأهداف التي يعتمد عليها هدف multi-user:

يوضح المخرج:

هذا يعني أن basic-target يجب تحميله أولاً ليبدأ النظام في وضع multi-user.target.

• basic-target

أدخل الأمر التالي لمعرفة الأهداف الأخرى التي يحتاجها basic.target:

سيعرض المخرج:

• sysinit.target

يمكنك تشغيل الأمر التالي لمعرفة ما إذا كانت هناك أي أهداف مطلوبة لـ sysinit.target. صيغة الأمر هي نفسها. يمكنك الاستمرار في تعديله لمعرفة وحدات الأهداف المطلوبة من قبل وحدة هدف أخرى أثناء تقدمك. إليك الأمر:

سيوضح المخرج أنه لا توجد وحدات مطلوبة لـ sysinit.target. يمكننا التحقق مما إذا كانت هناك خدمات وأهداف أخرى مطلوبة بواسطة sysinit.target باستخدام الأمر التالي:

يظهر المخرج قائمة طويلة من الخدمات والأهداف المطلوبة بواسطة sysinit.target. يمكنك رؤية جزء من المخرج أدناه:

أثناء تهيئة النظام باستخدام system4، لا يبقى النظام في هدف واحد فقط. بدلاً من ذلك، يقوم بتحميل الخدمات بطريقة تعتمد على بعضها البعض أثناء انتقاله من هدف إلى آخر.

Step 3: Examine a Unit File

دعنا نرى كيف يبدو ملف الوحدة. لقد استخدمنا ملف وحدة خدمة MySQL في الجزء الأول من هذا البرنامج التعليمي، وسنستخدمه مرة أخرى. ومع ذلك، يمكننا أيضًا إلقاء نظرة على ملف وحدة خدمة آخر - ملف وحدة sshd. أدخل الأمر التالي لفتح ملف تكوين sshd:

أدناه لقطة شاشة توضح الأسطر الموجودة في الملف:

كما ترى، فإن كتل التعليمات البرمجية الموضحة في الملف تجعل من السهل فهمها وتعديلها عند الضرورة. أدناه بعض التوجيهات الهامة التي يجب فهمها:

• After – يخبر بند After النظام بتحميل الخدمة فقط بعد تحميل الأهداف والخدمات المحددة. في هذه الحالة، سيتم تحميل خدمة SSHD بعد تحميل هدف الشبكة وخدمة keygen.
• Wants – يوضح بند Wants الأهداف التي تريد هذه الخدمة. في هذه الحالة، فإن ssh-keygen.service تطلب sshd.service. ومع ذلك، إذا فشلت sshd أو تعطلت، فلن يؤدي ذلك إلى إيقاف تشغيل ssh-keygen.service.

اضغط على Ctrl + X لإغلاق المحرر.

الخطوة 4: اختبار سلوك بدء تشغيل خدمة MySQL عند تمهيد النظام

في هذا القسم، سنوضح لك كيف يمكنك تغيير واختبار سلوك خدمة MySQL عند تمهيد النظام. في القسم السابق، رأينا أن mysqld.service مطلوبة بواسطة multi-user.target. وبالتالي، ستعمل تلقائيًا عند بدء التشغيل.

يمكنك تعطيل الخدمة عن طريق تشغيل الأمر التالي:

يظهر تشغيل الأمر أنه تمت إزالة الارتباط الرمزي لـ mysql من دليل /etc/systemd/system/multi-user.target.wants/. لاختبار ذلك، قم بتشغيل الأمر التالي لاختبار ما إذا كانت MySQL لا تزال مطلوبة بواسطة multi-user.target:

لا يعيد الأمر أي شيء. إذا حاولت إعادة تشغيل الخادم والتحقق من حالة MySQL، فلن يكون قيد التشغيل، مما يعني أنه لم يبدأ تلقائيًا عند وقت التمهيد.

الآن أعد تمكين الخدمة باستخدام الأمر:

سيعرض المخرج رابطًا رمزيًا. إذا قمت بإعادة تشغيل الخادم، فيجب أن يبدأ MySQL تلقائيًا. يؤدي تمكين خدمة Systemd إلى إنشاء رابط رمزي في دليل wants الخاص بالهدف الافتراضي. يؤدي تعطيل خدمة Systemd إلى إزالة الرابط الرمزي من دليل wants دليل.

الخطوة 5: اختبار سلوك بدء تشغيل خدمة MySQL بعد تعطل الخدمة

بشكل افتراضي، ستبدأ خدمة MySQL تلقائيًا في حالة تعطلها. يمكننا تعطيل هذا السلوك في ملف تكوين Systemd الخاص بـ MySQL. أولاً، دعنا نلقي نظرة على الملف. أدخل الأمر التالي لفتح الملف:

توضح لقطة الشاشة أدناه المخرج:

تم تعيين قيمة توجيه Restart على on-failure. هذا يعني أن خدمة MySQL ستعيد التشغيل بعد رموز الخروج غير النظيفة، أو انتهاء المهلة، أو الإشارات غير النظيفة. يوجد أدناه جدول يوضح بعض معلمات إعادة التشغيل من صفحة الدليل.

إعدادات إعادة التشغيل/أسباب الخروج	no	always	on-success	on-failure	on-abnormal	on-abort	on-watchdog
رمز خروج أو إشارة نظيفة		X	X
رمز خروج غير نظيف		X		X
إشارة غير نظيفة		X		X	X	X
انتهاء المهلة		X		X	X
Watchdog		X		X	X		X

التوجيهان المهمان في ملف وحدة Systemd هما Restart و RestartSec. يتحكمان في سلوك تعطل الخدمة. Restart يحدد متى يجب إعادة تشغيل الخدمة، و RestartSec يحدد المدة التي يجب أن ينتظرها قبل إعادة التشغيل بعد التعطل. لتعطيل سلوك إعادة التشغيل، قم بتعليق توجيه Restart عن طريق إضافة # في بداية السطر كما هو موضح:

الآن، أعد تحميل شيطان النظام، ثم أعد تحميل خدمة mysqld باستخدام الأوامر التالية:

بعد ذلك، قم بتشغيل الأمر التالي للعثور على معرف العملية الرئيسي (Main PID) لخدمة MySQL:

كان معرف العملية الرئيسي (Main PID) لاختبارنا هو 23809. قم بتدوين المعرف الخاص بك لاستخدامه في الأمر التالي. باستخدام الأمر kill -9، قم بمحاكاة تعطل عن طريق إنهاء العملية. تذكر أيضًا استبداله برقم العملية الذي حصلت عليه في اختبارك:

إذا قمت بتشغيل الأمر الذي يتحقق من حالة MySQL، فستجد أنها غير نشطة، وفشلت في إعادة التشغيل:

ستظل في حالة الفشل طالما تم تعليق توجيه Restart في ملف تكوين mysqld.service. يحاكي هذا تعطلاً حيث تتوقف الخدمة ولا تعود للعمل.

لإعادة تمكين الخدمة، يمكنك تعديل ملف تكوين mysqld.service، وإلغاء تعليق توجيه Restart، ثم الحفظ والإغلاق. كما فعلت سابقًا، أعد تحميل الشيطان وأعد تشغيل الخدمة. يعيد هذا الخدمة إلى تكوينها الأولي، والآن يمكنها البدء تلقائيًا بعد التعطل. أخيرًا، هذا كل ما يتعلق بتكوين خدمة للبدء تلقائيًا بعد التعطل. إذا كنت تريد تكوين الخدمات للبدء تلقائيًا بعد التعطل، فما عليك سوى إضافة توجيه Restart، (وإذا كنت ترغب في ذلك، يمكنك أيضًا إضافة توجيه RestartSec)، أسفل قسم [Service] في ملف وحدة الخدمة.

الخاتمة

في هذا البرنامج التعليمي، ناقشنا كيفية تعامل Linux مع الخدمات أثناء بدء التشغيل أو بعد التعطل. لفهم عملية تهيئة نظام Linux، ناقشنا أنظمة التهيئة الثلاثة التي يستخدمها Linux: System V و Upstart و Systemd. وناقشنا تطورها وكيف تعمل كل عملية init فيما يتعلق ببدء تشغيل الخدمة تلقائيًا بعد إعادة تشغيل النظام أو تعطلها.

بما أن كلاً من عفاريت init وتوزيعات Linux قد تطورت بمرور الوقت، تذكر التحقق من إصدار توزيعة Linux التي تقوم بتشغيلها حتى تعرف أي عفريت init يدعمه نظامك بشكل أصلي.

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

حوسبة سعيدة!