أساسيات Systemd: العمل مع الخدمات، الوحدات Units، واليوميات Journal

شهدت السنوات الأخيرة انتقال توزيعات لينِكس على نحو متزايد من أنظمة init الأخرى إلى systemd، تُوفِّر مجموعة أدوات systemd نموذج init مرن وسريع لإدارة الجهاز بشكل كامل من الإقلاع boot فصاعدًا.

سنقوم في هذا الدرس بالمرور بشكل سريع على أهم الأوامر التي نحتاج معرفتها لإدارة خادوم يحتوي على systemd، ينبغي أن يعمل هذا على أي خادوم يُطبِّق systemd (أي إصدار نظام تشغيل يساوي أو أعلى من Ubuntu 15.04, Debian 8, CentOS 7, Fedora 15). فلنبدأ الآن.

إدارة الوحدة بشكل أساسي Basic Unit Management

الشيء الأساسي الذي يديره systemd ويعمل عليه هو الوحدة “unit”، يُمكن أن تكون الوحدات من عدّة أنواع، ولكن النّوع الأشيع هو الخدمة service (يتبيّن ذلك من ملف الوحدة الذي ينتهي بـ .service)، ولإدارة الخدمات على خادوم يحتوي systemd فإنّ أداتنا الرئيسيّة هي الأمر systemctl.

تمتلك جميع أوامر نظام init الاعتياديّة إجراءات مُكافِئة مع الأمر systemctl، سنستخدم الوحدة nginx.service للتوضيح (يجب علينا تثبيت Nginx باستخدام مُدير الحِزَم للحصول على ملف الخدمة هذا).

نستطيع على سبيل المثال تشغيل الخدمة بكتابة ما يلي:

sudo systemctl start nginx.service

نستطيع إيقافها مرّة أخرى بكتابة:

sudo systemctl stop nginx.service

ولإعادة تشغيل الخدمة نكتب:

sudo systemctl restart nginx.service

ولمحاولة إعادة تحميل reload الخدمة بدون مقاطعة الوظيفة الطبيعيّة نكتب ما يلي:

sudo systemctl reload nginx.service

تمكين أو تعطيل الوحدات

لا يتم بشكل افتراضي تشغيل معظم ملفّات وحدات systemd تلقائيًّا عند الإقلاع، ولإعداد هذه الوظيفة نحتاج لتمكين “enable” الوحدة، والذي يقوم بتعليقها بخطافة hook إلى هدف “target” إقلاع مُعيَّن ممّا يُسبِّب تحفيز تشغيلها عند بدء تشغيل الهدف.

لتمكين خدمة من البدء تلقائيًّا عند الإقلاع نكتب:

sudo systemctl enable nginx.service

إن كُنّا نرغب بتعطيل الخدمة مرّة أخرى نكتب:

sudo systemctl disable nginx.service

الحصول على لمحة عامة عن حالة النظام

هناك قدر كبير من المعلومات التي يمكننا استخلاصها من خادوم systemd للحصول على لمحة عامّة عن حالة النّظام.

على سبيل المثال للحصول على كافّة ملفّات الوحدات التي يعرضها systemd على أنّها نشطة “active” نكتب ما يلي (نستطيع فعليًّا ألّا نكتب list-units لأنّه سلوك systemctl الافتراضي):

systemctl list-units

ولعرض جميع الوحدات التي قام systemd بتحميلها أو حاول تحميلها إلى الذّاكرة بما في ذلك الخدمات غير النشطة حاليًّا نُضيف المحوِّل switch الذي يُدعى all--:

systemctl list-units --all

لعرض جميع الوحدات المُثبَّتة على النّظام بما في ذلك الوحدات التي لم يحاول systemd أن يُحمّلها إلى الذاكرة نكتب:

systemctl list-unit-files

عرض معلومات السجل Log الأساسية

يجمع ويدير المُكوِّن في systemd الذي يُدعى journald المُدخلات اليوميّة journal entries من كافّة أجزاء النّظام.

وهي بالأساس معلومات السّجلات من التطبيقات والنواة kernel.

ولمشاهدة جميع مُدخلات السّجلات بدءًا من المُدخَل الأقدم نكتب:

journalctl

سيظهر لنا هذا افتراضيًّا المُدخلات من الإقلاعات السّابقة والحاليّة إن تمّ إعداد journald ليحفظ سجلّات records الإقلاع السّابق، تُمكِّن بعض التوزيعات هذا الأمر افتراضيًّا بينما لا تقوم توزيعات أخرى بتمكينه (ولتمكينه إمّا نُحرِّر الملف etc/systemd/journald.conf/ ونُعيِّن الخيار Storage= إلى مستمر "persistent" أو نُنشِئ الدّليل persistent بكتابة sudo mkdir -p /var/log/journal).

إن كُنّا نرغب برؤية المُدخلات اليوميّة فقط من الإقلاع الحالي نُضيف العَلَم b-:

journalctl -b

ولمشاهدة رسائل النواة فقط، مثل تلك التي تكون ممثلة عادةً بواسطة dmesg، نستطيع استخدام العَلَم k-:

journalctl -k

مرةً أخرى، نستطيع تحديد الأمر السّابق ليكون فقط للإقلاع الحالي بإضافة العَلَم b-:

journalctl -k -b

الاستعلام عن سجلات وحالات الوحدة

بينما تُمكّننا الأوامر السّابقة من الوصول إلى الحالة العامّة للنظام، فنستطيع أيضًا الحصول على معلومات حول حالة الوحدات بشكلٍ فردي.

يُستخدم الخيار status مع الأمر systemctl للحصول على لمحة عامّة عن الحالة الحاليّة للوحدة، يُظهر لنا هذا الأمر إذا ما كانت الوحدة نشطة، معلومات حول العمليّة process، وآخر المُدخلات اليوميّة:

systemctl status nginx.service

لمشاهدة كافّة المُدخلات اليوميّة للوحدة التي نسأل عنها نضيف الخيار –u مع اسم الوحدة إلى الأمر journalctl:

journalctl -u nginx.service

ونستطيع كالعادة تحديد المُدخلات للإقلاع الحالي فقط بإضافة العَلَم b-:

journalctl -b -u nginx.service

فحص الوحدات وملفات الوحدات

نعرف حتى الآن كيفيّة تعديل حالة وحدة ما بواسطة تشغيلها أو إيقافها، ونعلم كيف نشاهد معلومات اليوميّات journal والحالة لأخذ فكرة عمّا يحدث مع العمليّة، ومع ذلك لم نتعلّم كيفيّة فحص inspect جوانب أخرى للوحدات وملفّات الوحدات.

يحتوي ملف الوحدة المُعامِلات parameters التي يستخدمها systemd لإدارة وتشغيل الوحدة، ولمشاهدة المحتويات الكاملة لملف الوحدة نكتب:

systemctl cat nginx.service

ولرؤية شجرة الاعتماديّات dependency tree لوحدة ما (والتي تحاول وحدات systemd تفعيلها عند بدء تشغيل الوحدة) نكتب:

systemctl list-dependencies nginx.service

يُظهر لنا هذا الأمر الوحدات المعتمدة مع توسيع expand الوحدات الهدف target بشكل تكراري recursively، ولتوسيع كافّة الوحدات المعتمدة بشكل تكراري نُمرِّر العَلَم all--:

systemctl list-dependencies --all nginx.service

وأخيرًا نستخدم الخيار show لمشاهدة التفاصيل ذات المستوى المُنخفض low-level لإعدادات الوحدة على النّظام:

systemctl show nginx.service

يُعطينا هذا الأمر قيمة كل مُعامِل تتم إدارته بواسطة systemd.

تعديل ملفات الوحدة

إن كُنّا نحتاج للقيام بتعديلات على ملف الوحدة فيسمح لنا systemd بالقيام بالتغييرات من خلال الأمر systemctl بنفسه بدون أن نضطر للذهاب إلى موقع الملف الفعلي على القرص.

لإضافة مقطع snippet لملف الوحدة، والذي يُمكن استخدامه لإلحاق append أو تجاوز override إعدادات في ملف الوحدة الافتراضي، نستدعي ببساطة الخيار edit على الوحدة:

sudo systemctl edit nginx.service

وإن كُنّا نرغب بتعديل كامل محتوى ملف الوحدة بدلًا من إنشاء مقطع، نُمرَّر العَلَم --full:

sudo systemctl edit --full nginx.service

يجب بعد الانتهاء من تعديل ملف الوحدة إعادة تحميل العمليّة systemd نفسها لكي تلتقط تغييراتنا:

sudo systemctl daemon-reload

استخدام الأهداف targets (مستويات التشغيل Runlevels)

ومن الوظائف الأخرى لنظام init نقل الخادوم نفسه بين حالات مختلفة، تُشير أنظمة init التقليديّة لهذا الأمر باسم مستويات التشغيل "runlevels" ممّا يسمح للنظام بأن يكون في مستوى تشغيل runlevel واحد فقط بنفس الوقت.

يتم في systemd استخدام الأهداف targets بدلًا من ذلك، والتي هي بشكل أساسي نقاط تزامن يستطيع الخادوم استخدامها لنقل نفسه إلى حالة مُحدّدة، يُمكن أن يتم ربط الخدمة وملفّات الوحدة الأخرى إلى هدف، ويُمكن للأهداف المتعددة أن تكون نشطة في الوقت نفسه.

ولرؤية كل الأهداف المتاحة على نظامنا نكتب:

systemctl list-unit-files --type=target

لمشاهدة الهدف الافتراضي الذي يحاول systemd الوصول إليه عند الإقلاع (والذي بدوره يقوم بتشغيل كافّة ملفّات الوحدة التي تُشكّل شجرة الاعتماديّات لهذا الهدف) نكتب:

systemctl get-default

نستطيع تغيير الهدف الافتراضي الذي سيتم استخدامه عند الإقلاع باستخدام الخيار set-default:

sudo systemctl set-default multi-user.target

نكتب ما يلي لكي نرى ما هي الوحدات المرتبطة بالهدف:

systemctl list-dependencies multi-user.target

يمكننا تعديل حالة النظام للانتقال بين الأهداف عن طريق الخيار isolate، سيقوم هذا بإيقاف تشغيل أيّة وحدات غير مرتبطة بالهدف المحدّد، ويجب أن نكون متأكدين من أنّ الهدف الذي نقوم بعزله isolate لا يوقف تشغيل أيّة خدمات أساسيّة:

sudo systemctl isolate multi-user.target

إيقاف تشغيل أو إعادة تشغيل الخادوم

هنالك بعض الاختصارات المتاحة لبعض الحالات الرئيسيّة التي يستطيع النّظام الانتقال إليها، على سبيل المثال لإيقاف تشغيل خادومنا نكتب:

sudo systemctl poweroff

إن كُنّا بدلًا من ذلك نريد إعادة تشغيل النظام فبإمكاننا فعل ذلك بكتابة:

sudo systemctl reboot

نستطيع الإقلاع في وضع الإنقاذ rescue mode بكتابة:

sudo systemctl rescue

لاحظ أنّ معظم أنظمة التشغيل تقوم بتضمين كنيات aliases تقليديّة لهذه العمليّات بحيث أنّنا نستطيع ببساطة كتابة:

sudo poweroff

أو

sudo reboot

بدون systemctl، ومع ذلك ليس من المضمون أن يكون هذا مُعدًّا على كل الأنظمة.

الخطوات التالية

ينبغي أن نكون الآن قد تعلّمنا أساسيّات إدارة خادوم يستخدم systemd، ومع ذلك هناك المزيد لتعلمّه مع توسّع احتياجاتنا، توجد أدناه روابط دروس تحتوي معلومات أكثر تفصيلًا حول بعض المُكوّنات التي ناقشناها في هذا الدّرس: