الاسم¶

systemd.unit - ضبط الوحدة

موجز¶

service.service، socket.socket، device.device، mount.mount، automount.automount، swap.swap، target.target، path.path، timer.timer، slice.slice، scope.scope

الوصف¶

ملف الوحدة هو ملف نصي بسيط بنمط ini يُرمِّز معلومات حول خدمة، أو مقبس، أو جهاز، أو نقطة وصل، أو نقطة وصل آلي، أو ملف أو قسم تبديل، أو هدف بدء التشغيل، أو مسار نظام ملفات مراقَب، أو مؤقت مُتحكَّم فيه ومُراقَب بواسطة systemd(1)، أو شريحة إدارة موارد، أو مجموعة من العمليات المنشأة خارجيًا. طالع systemd.syntax(7) للحصول على وصف عام للصيغة.

تُدرج صفحة الدليل هذه خيارات الضبط الشائعة لجميع أنواع الوحدات. يجب ضبط هذه الخيارات في قِسمي [Unit] أو [Install] من ملفات الوحدة.

بالإضافة إلى قسمي [Unit] و [Install] العامَّين الموصوفين هنا، قد تحتوي كل وحدة على قسم خاص بنوعها، على سبيل المثال [Service] لوحدة خدمة. طالع صفحات الدليل ذات الصلة لمزيد من المعلومات: systemd.service(5)، systemd.socket(5)، systemd.device(5)، systemd.mount(5)، systemd.automount(5)، systemd.swap(5)، systemd.target(5)، systemd.path(5)، systemd.timer(5)، systemd.slice(5)، systemd.scope(5).

تُحمَّل ملفات الوحدات من مجموعة مسارات مُحدَّدة أثناء التجميع، وموصوفة في القسم التالي.

تتكون أسماء الوحدات الصالحة من "بادئة اسم الوحدة"، ولاحقة تحدد نوع الوحدة تبدأ بنقطة. يجب أن تتكون "بادئة اسم الوحدة" من حرف واحد أو أكثر من الأحرف الصالحة (أحرف ASCII، أرقام، ":"، "-"، "_"، "."، و "\"). يجب ألا يتجاوز الطول الإجمالي لاسم الوحدة بما في ذلك اللاحقة 255 حرفًا. يجب أن تكون لاحقة نوع الوحدة واحدة من ".service"، ".socket"، ".device"، ".mount"، ".automount"، ".swap"، ".target"، ".path"، ".timer"، ".slice"، أو ".scope".

يمكن إعطاء معلمات لأسماء الوحدات بواسطة وسيط واحد يُسمى "اسم النسخة". بعد ذلك تُنشأ الوحدة بناءً على "ملف قالب" يعمل كتعريف لخدمات متعددة أو وحدات أخرى. يجب أن تحتوي وحدة القالب على "@" واحدة في نهاية بادئة اسم الوحدة (مباشرة قبل لاحقة النوع). يتشكل اسم الوحدة الكاملة عن طريق إدراج اسم النسخة بين "@" ولاحقة نوع الوحدة. في ملف الوحدة نفسه، قد يُشار إلى معلمة النسخة باستخدام "%i" ومحددات أخرى، طالع أدناه.

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

يمكن إعطاء الوحدات اسماً مستعاراً (امتلاك اسم بديل)، عن طريق إنشاء رابط رمزي (symlink) من الاسم الجديد إلى الاسم الحالي في أحد مسارات بحث الوحدات. على سبيل المثال، تمتلك systemd-networkd.service الاسم المستعار dbus-org.freedesktop.network1.service، الذي أُنشئ أثناء التثبيت كرابط رمزي، لذا عندما يُطلب من systemd عبر D-Bus تحميل dbus-org.freedesktop.network1.service، فسيُحمل systemd-networkd.service. كمثال آخر، default.target — هدف النظام المبدئي الذي يُبدأ عند الإقلاع — يُشار إليه عادةً باسم مستعار إما multi-user.target أو graphical.target لاختيار ما يُبدأ بشكل مبدئي. يمكن استخدام الأسماء المستعارة في أوامر مثل disable، وstart، وstop، وstatus، وما يشابهها، وفي جميع توجيهات اعتمادية الوحدات، بما في ذلك Wants=، وRequires=، وBefore=، وAfter=. لا يمكن استخدام الأسماء المستعارة مع الأمر preset.

تخضع الأسماء المستعارة للقيود التالية: لا يمكن منح اسم مستعار لوحدة من نوع معين (".service"، ".socket"، ...) إلا بواسطة اسم له نفس لاحقة النوع. الوحدة العادية (ليست قالباً أو مثيلاً)، لا يمكن منحها اسماً مستعاراً إلا بواسطة اسم عادي. مثيل القالب لا يمكن منح اسم مستعار له إلا بواسطة مثيل قالب آخر، ويجب أن يكون جزء المثيل متطابقاً. يمكن منح اسم مستعار للقالب بواسطة قالب آخر (وفي هذه الحالة ينطبق الاسم المستعار على جميع مثيلات القالب). كحالة خاصة، يمكن أن يكون مثيل القالب (مثل "alias@inst.service") رابطاً رمزياً لقالب مختلف (مثل "template@inst.service"). في تلك الحالة، يُمنح هذا المثيل المحدد فقط اسماً مستعاراً، بينما لا تُمنح المثيلات الأخرى للقالب (مثل "alias@foo.service"، "alias@bar.service") أسماء مستعارة. تحافظ تلك القواعد على المتطلب بأن المثيل (إن وُجد) مُعرَّف دائماً بشكل فريد لوحدة معينة وجميع أسمائها المستعارة. يجب أن يشير هدف الرابط الرمزي للاسم المستعار إلى موقع ملف وحدة صالح، أي يجب أن يطابق اسم هدف الرابط الرمزي اسم مصدر الرابط الرمزي كما وُصف، ويجب أن يكون مسار الوجهة في أحد مسارات بحث الوحدات، انظر قسم مسار تحميل ملف الوحدة أدناه لمزيد من التفاصيل. لاحظ أن الملف الهدف قد لا يكون موجوداً، أي قد يكون الرابط الرمزي معلقاً.

يمكن لملفات الوحدات تحديد أسماء مستعارة من خلال توجيه Alias= في القسم [Install]. عند تفعيل الوحدة، ستُنشأ روابط رمزية لتلك الأسماء، وتُزال عند تعطيل الوحدة. على سبيل المثال، تحدد reboot.target التوجيه Alias=ctrl-alt-del.target، لذا عند التفعيل، سيُنشأ الرابط الرمزي /etc/systemd/system/ctrl-alt-del.target المشير إلى ملف reboot.target، وعند استدعاء Ctrl+Alt+Del، سيبحث systemd عن ctrl-alt-del.target، ويتبع الرابط الرمزي إلى reboot.target، ويُنفذ reboot.service كجزء من ذلك الهدف. لا ينظر systemd إلى القسم [Install] إطلاقاً أثناء التشغيل العادي، لذا فإن أي توجيهات في ذلك القسم لها تأثير فقط من خلال الروابط الرمزية المُنشأة أثناء التفعيل.

إلى جانب ملف الوحدة foo.service، قد يوجد الدليل foo.service.wants/. وتُضاف جميع ملفات الوحدات المرتبطة ارتباطًا رمزيًا من هذا الدليل ضمناً كتبعيات من النوع Wants= إلى الوحدة. توجد وظيفة مماثلة لتبعيات النوع Requires= أيضًا، حيث تكون لاحقة الدليل هي .requires/ في هذه الحالة. هذه الوظيفة مفيدة لربط الوحدات ببدء تشغيل وحدات أخرى، دون الحاجة إلى تعديل ملفات الوحدات الخاصة بها. للحصول على تفاصيل حول دلالات Wants= و Requires=، انظر أدناه. الطريقة المفضلة لإنشاء روابط رمزية في الدلائل .wants/ أو .requires/ هي عن طريق تحديد التبعية في قسم [Install] للوحدة المستهدفة، وإنشاء الرابط الرمزي في نظام الملفات باستخدام أوامر enable أو preset لـ systemctl(1). يمكن أن يكون الهدف وحدة عادية (سواء عادية أو مثيل محدد لوحدة قالب). في حالة ما إذا كانت الوحدة المصدر هي قالب، يمكن أن يكون الهدف أيضًا قالبًا، وفي هذه الحالة سيتم ”نقل“ المثيل إلى الوحدة الهدف لتشكيل مثيل وحدة صالح . يجب أن يشير هدف الروابط الرمزية في .wants/ أو .requires/ إلى موقع ملف وحدة صالح، أي أن اسم هدف الرابط الرمزي يجب أن يفي بالمتطلبات الموضحة، ويجب أن يكون مسار الوجهة في أحد مسارات البحث عن الوحدات، انظر قسم مسار تحميل ملف الوحدة أدناه لمزيد من التفاصيل. لاحظ أن الملف الهدف قد لا يكون موجودًا، أي أن الرابط الرمزي قد يكون معلقًا.

جنباً إلى جنب مع ملف الوحدة foo.service، قد يوجد مجلد "إضافات" (drop-in) foo.service.d/. جميع الملفات ذات اللاحقة ".conf" من هذا المجلد سيتم دمجها بالترتيب الأبجدي الرقمي وتحليلها بعد تحليل ملف الوحدة الرئيسي نفسه. هذا مفيد لتغيير أو إضافة إعدادات تهيئة لوحدة ما، دون الحاجة إلى تعديل ملفات الوحدة. يجب أن يحتوي كل ملف إضافات على ترويسات أقسام مناسبة. بالنسبة للوحدات المُنشأة، ستبحث هذه المنطقية أولاً عن المجلد الفرعي للمثيل ".d/" (مثل "foo@bar.service.d/") وتقرأ ملفات ".conf" الخاصة به، متبوعة بالمجلد الفرعي للقالب ".d/" (مثل "foo@.service.d/") وملفات ".conf" الموجودة هناك. علاوة على ذلك، بالنسبة لأسماء الوحدات التي تحتوي على شرطات ("-")، يتم البحث أيضًا في مجموعة المجلدات المُنشأة عن طريق اقتطاع اسم الوحدة بشكل متكرر بعد كل شرطة. وتحديداً، لاسم الوحدة foo-bar-baz.service لا يتم البحث في مجلد الإضافات العادي foo-bar-baz.service.d/ فحسب، بل أيضًا في كلا المجلدين foo-bar-.service.d/ و foo-.service.d/. هذا مفيد لتعريف إضافات مشتركة لمجموعة من الوحدات ذات الصلة، التي تبدأ أسماؤها ببادئة مشتركة. هذا المخطط مفيد بشكل خاص لوحدات الوصل (mount)، والوصل التلقائي (automount)، والشريحة (slice)، التي بُنيت بنية تسميتها المنتظمة حول الشرطات كفواصل للمكونات. لاحظ أن ملفات الإضافات ذات الأسماء المتطابقة الموجودة في مستوى أدنى في تسلسل البادئة الهرمي تلغي تلك الموجودة في مستوى أعلى، أي أن foo-bar-.service.d/10-override.conf يلغي foo-.service.d/10-override.conf.

في حالات الأسماء المستعارة للوحدات (الموصوفة أعلاه)، تُحمل الإضافات للاسم المُستعار وجميع الأسماء المستعارة. في مثال default.target الذي يشير اسماً مستعاراً إلى graphical.target، ستُقرأ جميع المجلدات التالية: default.target.d/، وdefault.target.wants/، وdefault.target.requires/، وgraphical.target.d/، وgraphical.target.wants/، وgraphical.target.requires/. بالنسبة للقوالب، تُقرأ إضافات القالب، وأي أسماء مستعارة للقالب، ومثيل القالب، وجميع مثيلات الأسماء المستعارة. عندما يُمنح مثيل قالب محدد اسماً مستعاراً فقط، تُقرأ الإضافات للقالب الهدف، ومثيل القالب الهدف، ومثيل قالب الاسم المستعار.

بالإضافة إلى /etc/systemd/system، يمكن وضع مجلدات الإضافات ".d/" لخدمات النظام في المجلدات /usr/lib/systemd/system أو /run/systemd/system. ملفات الإضافات في /etc/ لها الأولوية على تلك الموجودة في /run/ والتي بدورها لها الأولوية على تلك الموجودة في /usr/lib/. ملفات الإضافات تحت أي من هذه المجلدات لها الأولوية على ملفات الوحدات أينما وُجدت. تُطبق ملفات الإضافات المتعددة ذات الأسماء المختلفة بالترتيب المعجمي، بغض النظر عن المجلد الذي توجد فيه.

تدعم الوحدات أيضًا إضافات ذات مستوى أعلى بـ type.d/، حيث يمكن أن يكون type مثلاً "service" أو "socket"، مما يسمح بتغيير أو إضافة إعدادات لجميع ملفات الوحدات المقابلة على النظام. تتبع تنسيقات وأولويات تطبيق إعدادات الإضافات ما هو مُعرَّف أعلاه. الملفات في type.d/ لها أولوية أقل مقارنة بالملفات في مجلدات التجاوز الخاصة باسم محدد. تطبق القواعد المعتادة: تُطبق ملفات الإضافات المتعددة ذات الأسماء المختلفة بالترتيب المعجمي، بغض النظر عن المجلد الذي توجد فيه، لذا لا ينطبق ملف في type.d/ على وحدة ما إلا إذا لم تكن هناك إضافات أو أقنعة (masks) بهذا الاسم في مجلدات ذات أولوية أعلى. انظر الأمثلة.

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

كما ذُكر أعلاه، قد يتم إنشاء مثيل للوحدة من ملف قالب. هذا يسمح بإنشاء وحدات متعددة من ملف تهيئة واحد. إذا بحث systemd عن ملف تهيئة لوحدة ما، فسيقوم أولاً بالبحث عن اسم الوحدة الحرفي في نظام الملفات. إذا لم يؤد ذلك إلى نجاح وكان اسم الوحدة يحتوي على حرف "@"، فسيقوم systemd بالبحث عن قالب وحدة يشارك نفس الاسم ولكن مع إزالة سلسلة المثيل (أي الجزء الموجود بين حرف "@" واللاحقة). مثال: إذا طُلبت الخدمة getty@tty3.service ولم يُعثر على ملف بهذا الاسم، سيبحث systemd عن getty@.service ويُنشئ مثيل خدمة من ملف التهيئة ذلك إذا وُجد.

للإشارة إلى سلسلة المثيل من داخل ملف التهيئة، يمكنك استخدام المُحدِّد الخاص "%i" في العديد من خيارات التهيئة. انظر أدناه للحصول على التفاصيل.

إذا كان ملف الوحدة فارغاً (أي حجمه 0) أو كان مربوطاً رمزياً بـ /dev/null، فلن تُحمل تهيئته وسيظهر بحالة تحميل "مُقنَّع" (masked)، ولا يمكن تنشيطه. استخدم هذا كطريقة فعالة لتعطيل وحدة بالكامل، مما يجعل من المستحيل بدء تشغيلها حتى يدوياً.

الملفات (بما في ذلك المجلدات) ذات الأسماء التي تطابق أنماطاً معينة يتم تجاهلها بشكل عام. يشمل ذلك الأسماء التي تبدأ بـ "." أو تنتهي بـ ".ignore".

تنسيق ملف الوحدة مشمول ضمن وعد قابلية نقل واستقرار الواجهة[1].

هروب السلاسل النصية للإدراج في أسماء الوحدات¶

في بعض الأحيان يكون من المفيد تحويل سلاسل نصية عشوائية إلى أسماء وحدات. لتسهيل ذلك، تُستخدم طريقة هروب السلاسل النصية، لتعيين سلاسل تحتوي على قيم بايت عشوائية (باستثناء NUL) إلى أسماء وحدات صالحة ومجموعة محارفها المقيدة. حالة خاصة شائعة هي أسماء الوحدات التي تعكس مسارات إلى كائنات في تراتبية نظام الملفات. مثال: وحدة الجهاز dev-sda.device تشير إلى جهاز بعقدة جهاز /dev/sda في نظام الملفات.

تعمل خوارزمية الهروب كما يلي: بالنظر إلى سلسلة نصية، يتم استبدال أي حرف "/" بـ "-"، ويتم استبدال جميع المحارف الأخرى التي ليست محارف ASCII أبجدية رقمية، أو ":"، أو "_"، أو "." بـ هروب "\x2d" بنمط لغة C. بالإضافة إلى ذلك، يتم استبدال "." بهروب بنمط C مماثل عندما تظهر كأول محرف في السلسلة المُهربة.

عندما يُصنَّف المُدخل كمسار نظام ملفات مطلق، يتم توسيع هذه الخوارزمية قليلاً: يتم ترميز المسار إلى المجلد الجذر "/" كشرطة مفردة "-". بالإضافة إلى ذلك، تُزال أي محارف "/" بادئة أو لاحقة أو مكررة من السلسلة قبل التحويل. مثال: /foo//bar/baz/ تصبح "foo-bar-baz".

هذا الهروب قابل للعكس تماماً، طالما أنه من المعروف ما إذا كانت السلسلة المُهربة مساراً (نتائج عكس الهروب مختلفة للمسارات والسلاسل غير المسارات). يمكن استخدام الأمر systemd-escape(1) لتطبيق وعكس الهروب على سلاسل عشوائية. استخدم systemd-escape --path لهروب مسارات السلاسل، وsystemd-escape بدون --path في الحالات الأخرى.

اعتمادات آلية¶

مسار تحميل ملف الوحدة¶

تُحمَّل ملفات الوحدات من مجموعة مسارات حُدِّدت أثناء التجميع، وموصوفة في الجدولين أدناه. ملفات الوحدات الموجودة في المجلدات المدرجة أولًا تتخطى الملفات التي تحمل نفس الاسم في المجلدات الأدنى في القائمة [2].

عند ضبط المتغير $SYSTEMD_UNIT_PATH، يتخطى محتوى هذا المتغير مسار تحميل الوحدات. إذا انتهى $SYSTEMD_UNIT_PATH بمكون فارغ (":")، فسيُلحَق مسار تحميل الوحدات المبدئي بمحتوى المتغير.

Table 1.  مسار التحميل عند التشغيل في وضع النظام (--system).

Table 2.  مسار التحميل عند التشغيل في وضع المستخدم (--user).

قد تُعزَّز أو تُغيَّر مجموعة مسارات التحميل لنسخة مدير المستخدم باستخدام متغيرات بيئة مختلفة. ويمكن بدورها ضبط متغيرات البيئة باستخدام مولدات البيئة، انظر systemd.environment-generator(7). على وجه الخصوص، يمكن ضبط $XDG_DATA_HOME و $XDG_DATA_DIRS بسهولة باستخدام systemd-environment-d-generator(8). وبذلك، فإن المجلدات المدرجة هنا هي مجرد قيم مبدئية. لرؤية القائمة الفعلية التي ستُستخدم بناءً على خيارات التجميع والبيئة الحالية، استخدم

systemd-analyze --user unit-paths

علاوة على ذلك، قد تُحمَّل وحدات إضافية إلى systemd من مجلدات ليست في مسار تحميل الوحدات عن طريق إنشاء وصلة رمزية تشير إلى ملف وحدة في تلك المجلدات. يمكنك استخدام systemctl link لذلك؛ انظر systemctl(1). يجب أن يكون نظام الملفات حيث توجد ملفات الوحدات الموصولة قابلاً للوصول عند بدء systemd (على سبيل المثال، لا يُسمح بأي شيء تحت /home/ أو /var/، ما لم تكن تلك المجلدات تقع على نظام ملفات الجذر).

من المهم التمييز بين "ملفات الوحدات الموصولة" و"أسماء الوحدات المستعارة": أي وصلة رمزية حيث يكون target الوصلة الرمزية ضمن مسار تحميل الوحدات تصبح اسمًا مستعارًا: يجب أن يفي الاسم المصدر واسم الملف الهدف بقيود محددة مدرجة أعلاه في مناقشة الأسماء المستعارة، ولكن لا يجب أن يكون هدف الوصلة الرمزية موجودًا، وفي الواقع لا يُستخدم مسار هدف الوصلة الرمزية، باستثناء التحقق مما إذا كان الهدف ضمن مسار تحميل الوحدات. في المقابل، تشير الوصلة الرمزية التي تخرج عن مسار تحميل الوحدات إلى ملف وحدة موصول. تُتَّبع الوصلة الرمزية عند تحميل الملف، لكن اسم الوجهة لا يُستخدم بخلاف ذلك (وقد لا يكون حتى اسم ملف وحدة صالحاً). على سبيل المثال، الوصلات الرمزية /etc/systemd/system/alias1.service ← service1.service، و /etc/systemd/system/alias2.service ← /usr/lib/systemd/service1.service، و /etc/systemd/system/alias3.service ← /etc/systemd/system/service1.service هي كلها أسماء مستعارة صالحة وسيكون لـ service1.service أربعة أسماء، حتى لو كان ملف الوحدة يقع في /run/systemd/system/service1.service. على النقيض من ذلك، فإن الوصلة الرمزية /etc/systemd/system/link1.service ← ../link1_service_file تعني أن link1.service هي "وحدة موصولة" ومحتويات /etc/systemd/link1_service_file توفر إعداداتها.

تجميع مهملات الوحدات¶

يُحمِّل مدير النظام والخدمة إعدادات الوحدة آلياً عند الإشارة إلى وحدة لأول مرة. سيُفرغ إعدادات الوحدة وحالتها آلياً مرة أخرى عندما لا تعود الوحدة مطلوبة ("تجميع المهملات"). قد يُشار إلى الوحدة من خلال عدد من الآليات المختلفة:

يمكن تغيير منطق جمع القمامة بخيار CollectMode=، الذي يسمح بضبط ما إذا كان التفريغ الآلي للوحدات التي في حالة failed مسموحًا به، انظر أدناه.

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

استخدم systemctl daemon-reload أو أمرًا مكافئًا لإعادة تحميل إعدادات الوحدة بينما الوحدة محملة بالفعل. في هذه الحالة، تُفرغ جميع إعدادات التشكيل وتُستبدل بالإعدادات الجديدة (التي قد لا تدخل حيز التنفيذ فورًا)، ومع ذلك تُحفظ/تُستعاد كل حالة وقت التشغيل.

خيارات القسم [UNIT]¶

قد يحتوي ملف الوحدة على قسم [Unit]، الذي يحمل معلومات عامة حول الوحدة لا تعتمد على نوع الوحدة:

Description=

Documentation=

Wants=

Requires=

Requisite=

BindsTo=

PartOf=

Upholds=

Conflicts=

Before=, After=

OnFailure=

OnSuccess=

PropagatesReloadTo=, ReloadPropagatedFrom=

PropagatesStopTo=, StopPropagatedFrom=

JoinsNamespaceOf=

RequiresMountsFor=

WantsMountsFor=

OnSuccessJobMode=, OnFailureJobMode=

IgnoreOnIsolate=

StopWhenUnneeded=

RefuseManualStart=, RefuseManualStop=

AllowIsolate=

DefaultDependencies=

SurviveFinalKillSignal=

CollectMode=

FailureAction=, SuccessAction=

FailureActionExitStatus=, SuccessActionExitStatus=

JobTimeoutSec=, JobRunningTimeoutSec=

JobTimeoutAction=, JobTimeoutRebootArgument=

StartLimitIntervalSec=interval, StartLimitBurst=burst

StartLimitAction=

RebootArgument=

SourcePath=

تعيين خصائص الوحدة إلى معكوساتها¶

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

جدول 4.  خصائص الوحدة الأمامية والعكسية

ملاحظة: تُستخدم WantedBy=، وRequiredBy=، وUpheldBy= في قسم [Install] لإنشاء روابط رمزية في أدلة .wants/، و.requires/، و.upholds/. لا يمكن استخدامها مباشرة كإعداد لتهيئة الوحدة.

ملاحظة: تُنشأ ConsistsOf=، وBoundBy=، وRequisiteOf=، وConflictedBy= ضمنياً إلى جانب عكسياتها ولا يمكن تحديدها مباشرة.

ملاحظة: تُنشأ Triggers= ضمنياً بين مقبس، أو وحدة مسار، أو وحدة وصل آلي، والوحدة التي تُنشطها. مبدئياً، تُنشط وحدة بنفس الاسم، ولكن يمكن تجاوز ذلك باستخدام إعدادات Sockets=، وService=، وUnit=. راجع systemd.service(5)، وsystemd.socket(5)، وsystemd.path(5)، وsystemd.automount(5) للتفاصيل. تُنشأ TriggeredBy= ضمنياً على الوحدة المُنشطة.

ملاحظة: تُستخدم Following= لتجميع أسماء الأجهزة المستعارة وتُشير إلى وحدة الجهاز "الرئيسة" التي يستخدمها systemd لتتبع حالة الجهاز، وعادة ما توافق مسار sysfs. لا تظهر في وحدة "الهدف".

خيارات قسم [INSTALL]¶

قد تتضمن ملفات الوحدات قسماً للـ [Install]، والذي يحمل معلومات تثبيت الوحدة. لا يُفسر هذا القسم بواسطة systemd(1) أثناء وقت التشغيل؛ بل يُستخدم بواسطة أوامر enable وdisable في أداة systemctl(1) أثناء تثبيت الوحدة.

Alias=

WantedBy=, RequiredBy=, UpheldBy=

Also=

DefaultInstance=

يتم تفسير المحددات التالية في قسم Install: %a، و%b، و%B، و%g، و%G، و%H، و%i، و%j، و%l، و%m، و%n، و%N، و%o، و%p، و%u، و%U، و%v، و%w، و%W، و%%. لمعانيها راجع القسم التالي.

المحددات¶

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

جدول 5. المحددات المتاحة في ملفات الوحدات

أمثلة¶

مثال 1. السماح بتمكين الوحدات

القُصاصة التالية (المُظللة) تسمح بتمكين وحدة (على سبيل المثال. foo.service) عبر systemctl enable:

[Unit]
Description=Foo
[Service]
ExecStart=/usr/sbin/foo-daemon
[Install]
WantedBy=multi-user.target

بعد تشغيل systemctl enable، سَيُنشأ رابط رمزي /etc/systemd/system/multi-user.target.wants/foo.service يشير إلى الوحدة الفعلية. يخبر هذا systemd بسحب الوحدة عند بدء تشغيل multi-user.target. أما الأمر العكسي systemctl disable فسيحذف ذلك الرابط الرمزي مجدّدًا.

مثال 2. تجاوز إعدادات المورّد

توجد طريقتان لتجاوز إعدادات المورّد في ملفات الوحدات: نسخ ملف الوحدة من /usr/lib/systemd/system إلى /etc/systemd/system وتعديل الإعدادات المختارة. بدلاً من ذلك، يمكن إنشاء دليل باسم unit.d/ داخل /etc/systemd/system ووضع ملف إلحاق name.conf هناك يغيّر فقط الإعدادات المحددة المرغوبة. لاحظ أن ملفات الإلحاق المتعددة تُقرأ إذا وُجدت، وتُعالج بالترتيب المعجمي لأسماء ملفاتها.

ميزة الطريقة الأولى هي سهولة تجاوز الوحدة بالكامل، إذ لا يُحلَّل ملف وحدة المورّد على الإطلاق. ولها عيب يتمثل في أن التحسينات التي يجريها المورّد على ملف الوحدة لا تُدمج آليًّا عند التحديثات.

ميزة الطريقة الثانية هي تجاوز الإعدادات المرغوبة فقط، حيث تُطبَّق تحديثات الوحدة من المورّد آليًّا. ولها عيب يتمثل في أن بعض التحديثات المستقبلية من المورّد قد لا تتوافق مع التغييرات المحلية.

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

لنفترض وجود وحدة مقدَّمة من المورّد /usr/lib/systemd/system/httpd.service بالمحتويات التالية:

[Unit]
Description=Some HTTP Server
After=remote-fs.target sqldb.service
Requires=sqldb.service
AssertPathExists=/srv/webserver
[Service]
Type=notify
ExecStart=/usr/sbin/some-fancy-httpd-server
Nice=5
[Install]
WantedBy=multi-user.target

الآن، يريد المدير تغيير بعض الإعدادات: أولاً، في الإعداد المحلي، قد لا يكون /srv/webserver موجودًا، لأن خادوم HTTP مضبوط لاستخدام /srv/www بدلاً منه. ثانيًا، يجعل الإعداد المحلي خادوم HTTP يعتمد أيضًا على خدمة خبيئة ذاكرة memcached.service، التي يجب سحبها (Requires=) وترتيبها بشكل مناسب (After=). ثالثًا، من أجل زيادة تحصين الخدمة، يرغب المدير في ضبط إعداد PrivateTmp= (راجع systemd.exec(5) للتفاصيل). وأخيرًا، يرغب المدير في إعادة ضبط أولوية التنفيذ (niceness) للخدمة إلى قيمتها المبدئية 0.

الاحتمال الأول هو نسخ ملف الوحدة إلى /etc/systemd/system/httpd.service وتغيير الإعدادات المختارة:

[Unit]
Description=Some HTTP Server
After=remote-fs.target sqldb.service memcached.service
Requires=sqldb.service memcached.service
AssertPathExists=/srv/www
[Service]
Type=notify
ExecStart=/usr/sbin/some-fancy-httpd-server
Nice=0
PrivateTmp=yes
[Install]
WantedBy=multi-user.target

بدلاً من ذلك، يمكن للمدير إنشاء ملف إلحاق /etc/systemd/system/httpd.service.d/local.conf بالمحتويات التالية:

[Unit]
After=memcached.service
Requires=memcached.service
# Reset all assertions and then re-add the condition we want
AssertPathExists=
AssertPathExists=/srv/www
[Service]
Nice=0
PrivateTmp=yes

لاحظ أنه بالنسبة لملفات الإلحاق، إذا أراد المرء إزالة إدخالات من إعداد يُحلَّل كقائمة (وليس اعتمادية)، مثل AssertPathExists= (أو على سبيل المثال ExecStart= في وحدات الخدمة)، يجب أولاً مسح القائمة قبل إعادة إضافة جميع الإدخالات باستثناء تلك المُراد إزالتها. الاعتماديات (After=، إلخ) لا يمكن إعادة ضبطها إلى قائمة فارغة، لذا لا يمكن إضافة الاعتماديات إلا في ملفات الإلحاق. إذا كنت تريد إزالة اعتماديات، فيجب عليك تجاوز الوحدة بالكامل.

مثال 3. ملفات إلحاق على المستوى الأعلى مع وحدات القوالب

يمكن استخدام ملفات الإلحاق على المستوى الأعلى لكل نوع لتغيير جانب معيّن من جميع وحدات نوع محدّد. على سبيل المثال، بإنشاء الدليل /etc/systemd/system/service.d/ مع ملف إلحاق، يمكن تطبيق محتويات ملف الإلحاق على جميع وحدات الخدمة. يمكننا المضي قدمًا بجعل ملف الإلحاق على المستوى الأعلى ينسخ وحدة مساعدة ثانوية. لننظر على سبيل المثال إلى مجموعة الوحدات وملفات الإلحاق التالية حيث نُثبِّت اعتمادية OnFailure= لجميع وحدات الخدمة.

/etc/systemd/system/failure-handler@.service:

[Unit]
Description=My Failure Handler For %i
[Service]
Type=oneshot
# Perform some special action for when %i exits unexpectedly.
ExecStart=/usr/sbin/myfailurehandler %i

يمكننا حينئذٍ إضافة نسخة من failure-handler@.service كاعتمادية OnFailure= لجميع وحدات الخدمة.

/etc/systemd/system/service.d/10-all.conf:

[Unit]
OnFailure=failure-handler@%N.service

الآن، بعد تشغيل systemctl daemon-reload ستكتسب جميع الخدمات اعتمادية OnFailure= على failure-handler@%N.service. ستكتسب وحدات نسخ القوالب أيضًا الاعتمادية مما يؤدي إلى إنشاء سلسلة اعتمادية متكررة. سيحاول systemd اكتشاف سلاسل الاعتمادية المتكررة هذه حيث تعتمد وحدة القالب بشكل مباشر ومتكرر على نفسها، وسيزيل هذه الاعتماديات آليًّا إذا وجدها. إذا لم يكتشف systemd سلسلة الاعتمادية المتكررة، يمكننا كسر السلسلة بأنفسنا عن طريق تعطيل ملف الإلحاق لوحدات نسخ القوالب عبر رابط رمزي إلى /dev/null:

mkdir /etc/systemd/system/failure-handler@.service.d/
ln -s /dev/null /etc/systemd/system/failure-handler@.service.d/10-all.conf
systemctl daemon-reload

يضمن هذا أنه إذا فشلت نسخة failure-handler@.service، فلن تُشغِّل نسخة باسم failure-handler@failure-handler.service.

انظر أيضًا¶

systemd(1), systemctl(1), systemd-system.conf(5), systemd.special(7), systemd.service(5), systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5), systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.scope(5), systemd.slice(5), systemd.time(7), systemd-analyze(1), capabilities(7), systemd.directives(7), uname(1)

ملاحظات¶

1.

وعد استقرار وقابلية نقل الواجهة

2.

💣💥🧨💥💥💣 يرجى ملاحظة أن ملفات الضبط تلك يجب أن تكون متوفرة في جميع الأوقات. إذا كان /usr/local/ قسماً منفصلاً، فقد لا يكون متوفراً أثناء بدء التشغيل المبكر، ويجب عدم استخدامه للضبط.

3.

systemd وعفاريت التخزين لنظام ملفات الجذر

4.

بيانات اعتماد النظام والخدمة

5.

PSI (معلومات توقف الضغط)

ترجمة¶

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.