SYSTEMD.UNIT(5)

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

موجز

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

  مسار بحث وحدات النظام

    /etc/systemd/system.control/*
    /run/systemd/system.control/*
    /run/systemd/transient/*
    /run/systemd/generator.early/*
    /etc/systemd/system/*
    /etc/systemd/system.attached/*
    /run/systemd/system/*
    /run/systemd/system.attached/*
    /run/systemd/generator/*
    ...
    /usr/local/lib/systemd/system/*
    /usr/lib/systemd/system/*
    /run/systemd/generator.late/*

  مسار بحث وحدات المستخدم

    ~/.config/systemd/user.control/*
    $XDG_RUNTIME_DIR/systemd/user.control/*
    $XDG_RUNTIME_DIR/systemd/transient/*
    $XDG_RUNTIME_DIR/systemd/generator.early/*
    ~/.config/systemd/user/*
    $XDG_CONFIG_DIRS/systemd/user/*
    /etc/systemd/user/*
    $XDG_RUNTIME_DIR/systemd/user/*
    /run/systemd/user/*
    $XDG_RUNTIME_DIR/systemd/generator/*
    $XDG_DATA_HOME/systemd/user/*
    $XDG_DATA_DIRS/systemd/user/*
    ...
    /usr/local/lib/systemd/user/*
    /usr/lib/systemd/user/*
    $XDG_RUNTIME_DIR/systemd/generator.late/*

الوصف

ملف الوحدة هو ملف نصي بسيط بنمط 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".

عند إدخال تسمية مستعارة للوحدة أثناء إعادة التحميل/إعادة التنفيذ (مثل تحويل b.service إلى رابط رمزي يشير إلى a.service)، تُحفظ الحالة الجارية للوحدة الأساسية (a.service). تُهاجر الحالة المتسلسلة القديمة للوحدة المُسمّاة الآن إلى وحدة يتيمة جديدة لمنع البيانات القديمة من إفساد الحالة الحية للوحدة الأساسية. تُحل التبعيات التي تشير إلى الاسم المستعار آليًا إلى الوحدة الأساسية، ويُعاد بناء رسم بياني للتبعيات من ملفات الوحدات، مما يضمن الاتساق. إذا كانت للوحدة المُسمّاة الآن موارد مثل عمليات جارية، فسيتم تتبعها الآن تحت الوحدة اليتيمة الجديدة. بمجرد زوال جميع الموارد (مثل خروج جميع العمليات)، ستُجمع الوحدة اليتيمة آليًا.

تنسيق ملف الوحدة مشمول ضمن وعد قابلية نقل واستقرار الواجهة[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 في الحالات الأخرى.

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

  التبعيات الضمنية

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

على سبيل المثال، وحدات الخدمة ذات Type=dbus تكتسب آلياً اعتماديات من نوع Requires= وAfter= على dbus.socket. انظر systemd.service(5) للحصول على التفاصيل.

  الاعتمادات المبدئية

الاعتماديات المبدئية مشابهة للاعتماديات الضمنية، ولكن يمكن تشغيلها وإيقافها عن طريق ضبط DefaultDependencies= على yes (القيمة المبدئية) وno، بينما الاعتماديات الضمنية تكون سارية المفعول دائماً. انظر قسم "الاعتماديات المبدئية" في صفحات دليل man المقابلة لتأثير تفعيل DefaultDependencies= في كل أنواع الوحدات.

على سبيل المثال، ستُكمل وحدات الهدف جميع الاعتماديات المُهيأة من نوع Wants= أو Requires= باعتماديات من نوع After=. انظر systemd.target(5) للحصول على التفاصيل. لاحظ أنه يمكن إلغاء هذا السلوك عن طريق ضبط DefaultDependencies=no في الوحدات المحددة، أو يمكن تجاوزه بشكل انتقائي عبر اعتمادية Before= صريحة.

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

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

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

Table 1. مسار التحميل عند التشغيل في وضع النظام (--system).
المسار | الوصف
/etc/systemd/system.control | الإعدادات المستمرة والعابرة المنشأة باستخدام واجهة برمجة تطبيقات dbus
/run/systemd/system.control |
/run/systemd/transient | إعدادات ديناميكية للوحدات العابرة
/run/systemd/generator.early | وحدات مولَّدة ذات أولوية عالية (انظر early-dir في systemd.generator(7))
/etc/systemd/system | وحدات النظام التي أنشأها المدير
/run/systemd/system | وحدات وقت التشغيل
/run/systemd/generator | وحدات مولَّدة ذات أولوية متوسطة (انظر normal-dir في systemd.generator(7))
/usr/local/lib/systemd/system | وحدات النظام التي ثبَّتها المدير
/usr/lib/systemd/system | وحدات النظام التي ثبَّتها مدير حزم التوزيعة
/run/systemd/generator.late | وحدات مولَّدة ذات أولوية منخفضة (انظر late-dir في systemd.generator(7))

Table 2. مسار التحميل عند التشغيل في وضع المستخدم (--user).
المسار | الوصف
$XDG_CONFIG_HOME/systemd/user.control or ~/.config/systemd/user.control | الإعدادات المستمرة والعابرة المنشأة باستخدام واجهة برمجة تطبيقات dbus (يُستخدم $XDG_CONFIG_HOME إذا ضُبِط، وإلا يُستخدم ~/.config)
$XDG_RUNTIME_DIR/systemd/user.control |
$XDG_RUNTIME_DIR/systemd/transient | إعدادات ديناميكية للوحدات العابرة
$XDG_RUNTIME_DIR/systemd/generator.early | وحدات مولَّدة ذات أولوية عالية (انظر early-dir في systemd.generator(7))
$XDG_CONFIG_HOME/systemd/user or $HOME/.config/systemd/user | إعدادات المستخدم (يُستخدم $XDG_CONFIG_HOME إذا ضُبِط، وإلا يُستخدم ~/.config)
$XDG_CONFIG_DIRS/systemd/user or /etc/xdg/systemd/user | مجلدات الإعدادات الإضافية كما حددتها مواصفات مجلدات XDG الأساسية (يُستخدم $XDG_CONFIG_DIRS إذا ضُبِط، وإلا يُستخدم /etc/xdg)
/etc/systemd/user | وحدات المستخدم التي أنشأها المدير
$XDG_RUNTIME_DIR/systemd/user | وحدات وقت التشغيل (تُستخدم فقط عند ضبط $XDG_RUNTIME_DIR)
/run/systemd/user | وحدات وقت التشغيل
$XDG_RUNTIME_DIR/systemd/generator | وحدات مولَّدة ذات أولوية متوسطة (انظر normal-dir في systemd.generator(7))
$XDG_DATA_HOME/systemd/user or $HOME/.local/share/systemd/user | وحدات الحزم التي ثُبِّتت في مجلد المنزل (يُستخدم $XDG_DATA_HOME إذا ضُبِط، وإلا يُستخدم ~/.local/share)
$XDG_DATA_DIRS/systemd/user or /usr/local/share/systemd/user and /usr/share/systemd/user | مجلدات البيانات الإضافية كما حددتها مواصفات مجلدات XDG الأساسية (يُستخدم $XDG_DATA_DIRS إذا ضُبِط، وإلا يُستخدم /usr/local/share و /usr/share)
$dir/systemd/user for each $dir in $XDG_DATA_DIRS | مواقع إضافية لوحدات المستخدم المثبتة، موقع واحد لكل إدخال في $XDG_DATA_DIRS
/usr/local/lib/systemd/user | وحدات المستخدم التي ثبَّتها المدير
/usr/lib/systemd/user | وحدات المستخدم التي ثبَّتها مدير حزم التوزيعة
$XDG_RUNTIME_DIR/systemd/generator.late | وحدات مولَّدة ذات أولوية منخفضة (انظر late-dir في systemd.generator(7))

قد تُعزَّز أو تُغيَّر مجموعة مسارات التحميل لنسخة مدير المستخدم باستخدام متغيرات بيئة مختلفة. ويمكن بدورها ضبط متغيرات البيئة باستخدام مولدات البيئة، انظر 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 توفر إعداداتها.

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

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

    1. وحدة أخرى محمَّلة تشير إليها بتبعية مثل After=، أو Wants=، ...

    2. الوحدة حالياً في حالة بدء، أو تشغيل، أو إعادة تحميل، أو إيقاف.

    3. الوحدة حالياً في حالة failed (فشل). (لكن انظر أدناه.)

    4. هناك مهمة معلقة للوحدة.

    5. الوحدة مُثبَّتة بواسطة برنامج عميل IPC نشط.

    6. الوحدة هي وحدة "دائمة" خاصة تكون دائماً نشطة ومحمَّلة. أمثلة على الوحدات الدائمة هي وحدة وصل الجذر -.mount أو وحدة النطاق init.scope التي يعيش فيها مدير الخدمة نفسه.

    7. الوحدة لديها عمليات مشغلة مرتبطة بها.

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

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

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

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

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

Description=
    نص موجز وذي معنى ومقروء بشريًا يحدد الوحدة. قد يستخدمه systemd (وواجهات المستخدم المناسبة) كملصق مرئي للمستخدم للوحدة، لذا ينبغي أن تحدد هذه السلسلة الوحدة بدلاً من مجرد وصفها، رغم الاسم. كما ينبغي ألا تكرر هذه السلسلة اسم الوحدة فحسب. "خادم Apache HTTP" أو "خادم بريد Postfix" أمثلة جيدة. الأمثلة السيئة هي "خادم HTTP خفيف الوزن عالي الأداء" (عام للغاية) أو "Apache" (لا معنى له للأشخاص الذين لا يعرفون مشروع خادم Apache HTTP، ويكرر اسم الوحدة). قد يستخدم systemd هذه السلسلة كاسم في رسائل الحالة ("بدء الوصف..."، "بُدئ الوصف."، "وُصل إلى الهدف الوصف."، "فشل بدء الوصف.")، لذا ينبغي أن تُبدأ بحرف كبير، وألا تكون جملة كاملة، أو عبارة بفعل مصرف في المضارع المستمر، أو تنتهي بنقطة. الأمثلة السيئة تشمل "خروج من الحاوية"، "تحديث قاعدة البيانات مرة واحدة في اليوم."، أو "خادم OpenSSH مثيل ثانٍ".

    أُضيف في الإصدارة 201.

Documentation=
    قائمة مفصولة بمسافات من عناوين URI تشير إلى وثائق لهذه الوحدة أو إعداداتها. المقبول فقط هي عناوين URI من الأنواع "http://"، "https://"، "file:"، "info:"، "man:". للمزيد من المعلومات حول صيغة عناوين URI هذه، انظر uri(7). ينبغي إدراج عناوين URI بترتيب الأهمية، بدءًا من الأكثر صلة. من الجيد الإشارة أولاً إلى الوثائق التي تشرح غرض الوحدة، متبوعة بكيفية إعدادها، متبوعة بأي وثائق أخرى ذات صلة. قد يُحدد هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج قائمة عناوين URI المحددة. إذا أُسندت سلسلة فارغة إلى هذا الخيار، تُعاد تهيئة القائمة ولن يكون لجميع التعيينات السابقة أي تأثير.

    أُضيف في الإصدارة 201.

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

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

    لاحظ أن متطلبات الاعتمادية لا تؤثر على الترتيب الذي تُبدأ أو تُوقف به الخدمات. يجب ضبط هذا بشكل مستقل بخياري After= أو Before=. إذا قامت الوحدة foo.service بجذب الوحدة bar.service كما هو مضبوط بـ Wants= ولم يُضبط أي ترتيب بـ After= أو Before=، فستُبدأ الوحدتان في وقت واحد وبدون أي تأخير بينهما إذا نُشطت foo.service.

    أُضيف في الإصدارة 201.

Requires=
    مشابه لـ Wants=، لكنه يعلن عن متطلب اعتمادية أقوى. قد تُضبط اعتماديات من هذا النوع أيضًا بإضافة وصلة رمزية إلى دليل .requires/ المرافق لملف الوحدة.

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

    غالبًا ما يكون استخدام Wants= خيارًا أفضل من Requires= لتحقيق نظام أكثر متانة عند التعامل مع الخدمات الفاشلة.

    لاحظ أن نوع الاعتمادية هذا لا يعني أن الوحدة الأخرى يجب أن تكون دائمًا في حالة نشطة عندما تكون هذه الوحدة قيد التشغيل. تحديدًا: فحوصات الحالة الفاشلة (مثل ConditionPathExists=، ConditionPathIsSymbolicLink=، ... — انظر أدناه) لا تتسبب في فشل مهمة بدء وحدة لديها اعتمادية Requires= عليها. أيضًا، بعض أنواع الوحدات قد تتوقف عن النشاط من تلقاء نفسها (على سبيل المثال، قد تقرر عملية خدمة الخروج بشكل نظيف، أو قد يفصل المستخدم جهازًا)، وهو أمر لا يُنقل إلى الوحدات التي لديها اعتمادية Requires=. استخدم نوع الاعتمادية BindsTo= جنبًا إلى جنب مع After= لضمان ألا تكون الوحدة أبدًا في حالة نشطة دون أن تكون وحدة أخرى محددة في حالة نشطة أيضًا (انظر أدناه).

    أُضيف في الإصدارة 201.

Requisite=
    مشابه لـ Requires=. ومع ذلك، إذا لم تكن الوحدات المدرجة هنا قد بُدئت بالفعل، فلن تُبدأ وسيفشل بدء هذه الوحدة فورًا. Requisite= لا يعني اعتمادية ترتيب، حتى لو بُدئت كلتا الوحدتين في نفس العملية. ومن ثم ينبغي عادةً دمج هذا الإعداد مع After=، لضمان ألا تُبدأ هذه الوحدة قبل الوحدة الأخرى.

    عند استخدام Requisite=b.service في a.service، ستظهر هذه الاعتمادية كـ RequisiteOf=a.service في قائمة خصائص b.service. لا يمكن تحديد اعتمادية RequisiteOf= مباشرةً.

    أُضيف في الإصدارة 201.

BindsTo=
    يضبط متطلبات الاعتمادية، مشابه جدًا في الأسلوب لـ Requires=. ومع ذلك، نوع الاعتمادية هذا أقوى: بالإضافة إلى تأثيرات Requires=، التي تُوقف (أو تُعيد تشغيل) الوحدة التي تضبطها بالفعل عندما تُوقف (أو تُعاد تشغيل) وحدة مدرجة صراحةً، فإنه يفعل ذلك أيضًا عندما تتوقف وحدة مدرجة بشكل غير متوقع (وهو ما يشمل عندما تفشل). يمكن للوحدات أن تدخل فجأة وبشكل غير متوقع في حالة غير نشطة لأسباب مختلفة: قد تنهي العملية الرئيسية لوحدة الخدمة نفسها بقرارها الخاص، أو قد يُفصل الجهاز الداعم لوحدة جهاز، أو قد يُفصل وصل نقطة وصل لوحدة وصل دون تدخل مدير النظام والخدمة.

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

    عند استخدام BindsTo=b.service في a.service، ستظهر هذه الاعتمادية كـ BoundBy=a.service في قائمة خصائص b.service. لا يمكن تحديد اعتمادية BoundBy= مباشرةً.

    أُضيف في الإصدارة 201.

PartOf=
    يضبط اعتماديات مشابهة لـ Requires=، لكنها تقتصر على إيقاف وإعادة تشغيل الوحدات. عندما يوقف أو يعيد تشغيل systemd الوحدات المدرجة هنا، يُنقل الإجراء إلى هذه الوحدة. لاحظ أن هذه اعتمادية ذات اتجاه واحد — التغييرات في هذه الوحدة لا تؤثر على الوحدات المدرجة.

    عند استخدام PartOf=b.service في a.service، ستظهر هذه الاعتمادية كـ ConsistsOf=a.service في قائمة خصائص b.service. لا يمكن تحديد اعتمادية ConsistsOf= مباشرةً.

    أُضيف في الإصدارة 201.

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

    عند استخدام Upholds=b.service في a.service، ستظهر هذه الاعتمادية كـ UpheldBy=a.service في قائمة خصائص b.service.

    أُضيف في الإصدار 249.

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

    لاحظ أن هذا الإعداد لا يعني اعتمادية ترتيب، على غرار اعتماديات Wants= و Requires= الموصوفة أعلاه. هذا يعني أنه لضمان إيقاف الوحدة المتعارضة قبل بدء الوحدة الأخرى، يجب إعلان اعتمادية After= أو Before=. لا يهم أي من اعتماديتي الترتيب تُستخدم، لأن مهام الإيقاف تُرتب دائمًا قبل مهام البدء، انظر النقاش في Before=/After= أدناه.

    إذا جُدولت الوحدة A التي تتعارض مع الوحدة B للبدء في نفس وقت B، فإما أن تفشل العملية (في حال كان كلاهما جزأين مطلوبين من العملية) أو تُعدل لتُصلح (في حال لم تكن واحدة أو كلتا المهمتين جزءًا مطلوبًا من العملية). في الحالة الأخيرة، ستُحذف المهمة غير المطلوبة، أو في حال لم يكن كلاهما مطلوبًا، ستُبدأ الوحدة التي تتعارض وتُوقف الوحدة التي يقع عليها التعارض.

    أُضيف في الإصدارة 201.

Before=, After=
    يتوقع هذان الإعدادان قائمة مفصولة بمسافات من أسماء الوحدات. قد يُحددان أكثر من مرة، وفي هذه الحالة تُنشأ اعتماديات لجميع الأسماء المدرجة.

    يضبط هذان الإعدادان اعتماديات الترتيب بين الوحدات. إذا احتوت الوحدة foo.service على الإعداد Before=bar.service وبدأ تشغيل كلتا الوحدتين، يُؤخر بدء تشغيل bar.service حتى ينتهي بدء تشغيل foo.service. After= هو عكس Before=، أي بينما يضمن Before= بدء الوحدة المضبوطة قبل أن تبدأ الوحدة المدرجة في بدء التشغيل، يضمن After= العكس، أن الوحدة المدرجة قد بدأت بالكامل قبل بدء الوحدة المضبوطة.

    عند إيقاف تشغيل وحدتين بينهما اعتمادية ترتيب، يُطبق عكس ترتيب بدء التشغيل. أي إذا ضُبطت وحدة بـ After= على وحدة أخرى، تُوقف الأولى قبل الأخيرة إذا أُوقف تشغيل كلتيهما. بالنظر إلى وحدتين بينهما أي اعتمادية ترتيب، إذا أُوقف تشغيل وحدة وبدء تشغيل الأخرى، يُرتب الإيقاف قبل بدء التشغيل. لا يهم إذا كانت اعتمادية الترتيب After= أو Before=، في هذه الحالة. كما لا يهم أي من الاثنتين تُوقف، طالما أن واحدة أُوقف تشغيلها والأخرى بدء تشغيلها؛ يُرتب الإيقاف قبل بدء التشغيل في جميع الحالات. إذا لم تكن بين وحدتين أي اعتماديات ترتيب، فإنهما تُوقفان أو تُبدآن في وقت واحد، ولا يحدث أي ترتيب. يعتمد الأمر على نوع الوحدة متى تنتهي الوحدة بدقة من بدء التشغيل. والأهم من ذلك، بالنسبة لوحدات الخدمة، يُعتبر بدء التشغيل مكتملاً لغرض Before=/After= عندما تُستدعى جميع أوامر بدء التشغيل المضبوطة لها وإما أن تفشل أو تبلغ عن نجاح بدء التشغيل. لاحظ أن هذا يشمل ExecStartPost= (أو ExecStopPost= لحالة إيقاف التشغيل).

    لاحظ أن هذه الإعدادات مستقلة ومتعامدة مع متطلبات الاعتمادية كما هي مضبوطة بـ Requires= أو Wants= أو Requisite= أو BindsTo=. من الشائع تضمين اسم وحدة في خياري After= و Wants= معًا، وفي هذه الحالة ستبدأ الوحدة المدرجة قبل الوحدة التي ضُبطت بهذه الخيارات.

    لاحظ أن اعتماديات Before= على وحدات الأجهزة ليس لها أي تأثير وغير مدعومة. تصبح الأجهزة عادةً متاحة نتيجة لحدث توصيل خارجي، وينشئ systemd وحدة الجهاز المقابلة دون تأخير.

    أُضيف في الإصدارة 201.

OnFailure=
    قائمة مفصولة بمسافات لوحدة واحدة أو أكثر تُنشط عندما تدخل هذه الوحدة في حالة "فاشل".

    أُضيف في الإصدارة 201.

OnSuccess=
    قائمة مفصولة بمسافات لوحدة واحدة أو أكثر تُنشط عندما تدخل هذه الوحدة في حالة "غير نشط".

    أُضيف في الإصدار 249.

PropagatesReloadTo=, ReloadPropagatedFrom=
    قائمة مفصولة بمسافات لوحدة واحدة أو أكثر تُراد إحالة طلبات إعادة التحميل من هذه الوحدة إليها، أو وحدات تُراد إحالة طلبات إعادة التحميل منها إلى هذه الوحدة، على التوالي. إصدار طلب إعادة تحميل على وحدة سيُصنف آليًا أيضًا طلبات إعادة تحميل على جميع الوحدات المرتبطة بها باستخدام هذين الإعدادين.

    أُضيف في الإصدارة 201.

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

    أُضيف في الإصدار 249.

JoinsNamespaceOf=
    للوحدات التي تبدأ عمليات (مثل وحدات الخدمات)، تُدرِج وحدة أو أكثر من الوحدات الأخرى التي يُراد الانضمام إلى نطاق أسماء الشبكة و/أو الملفات المؤقتة الخاص بها. إذا حُدِّد هذا في وحدة (على سبيل المثال، إذا كان للوحدة a.service الإعداد JoinsNamespaceOf=b.service)، فإن التبعية العكسية (JoinsNamespaceOf=a.service للوحدة b.service) تُعد ضمنية. ينطبق هذا فقط على أنواع الوحدات التي تدعم توجيهات PrivateNetwork=، وNetworkNamespacePath=، وPrivateIPC=، وIPCNamespacePath=، وPrivateTmp= (طالع systemd.exec(5) لمزيد من التفاصيل). إذا بُدئت وحدة مضبوطة بهذا الإعداد، فسترى عملياتها نفس نطاق أسماء /tmp/، و/var/tmp/، ونطاق أسماء IPC، ونطاق أسماء الشبكة للوحدة المُدرجة التي بُدئت. إذا كانت وحدات متعددة مُدرجة مُشغّلة بالفعل ولم تكن تتشارك في نطاق الأسماء الخاص بها، فغير مُعرَّف أي نطاق أسماء سيتم الانضمام إليه. لاحظ أن هذا الإعداد يؤثر فقط إذا كان PrivateNetwork=/NetworkNamespacePath=، وPrivateIPC=/IPCNamespacePath= و/أو PrivateTmp= مُفعَّلاً لكل من الوحدة التي تنضم إلى نطاق الأسماء والوحدة التي يُنضم إلى نطاق أسمائها.

    أُضيف في الإصدارة 209.

RequiresMountsFor=
    يأخذ قائمة مفصولة بمسافات لمسارات مطلقة. يُضيف آلياً تبعيات من النوع Requires= وAfter= لجميع وحدات الوصل المطلوبة للوصول إلى المسار المحدّد.

    نقاط الوصل المميّزة بـ noauto لا تُوصل آلياً من خلال local-fs.target، لكنها لا تزال مُعتبرة لأغراض هذا الخيار، أي أنها ستُجلب بواسطة هذه الوحدة.

    أُضيف في الإصدارة 201.

WantsMountsFor=
    نفس RequiresMountsFor=، لكن يُضيف تبعيات من النوع Wants= بدلاً من Requires=.

    أُضيف في الإصدار 256.

OnSuccessJobMode=, OnFailureJobMode=
    يأخذ قيمة "fail" (فشل)، أو "replace" (استبدال)، أو "replace-irreversibly" (استبدال غير قابل للتراجع)، أو "isolate" (عزل)، أو "flush" (إفراغ)، أو "ignore-dependencies" (تجاهل التبعيات)، أو "ignore-requirements" (تجاهل المتطلبات). الإعداد "OnFailureJobMode=" افتراضياً "replace"، و"OnSuccessJobMode=" افتراضياً "fail". يُحدّد كيفية وضع الوحدات المدرجة في OnSuccess=/OnFailure= في قائمة الانتظار. طالع خيار --job-mode= الخاص بـ systemctl(1) للحصول على تفاصيل حول القيم الممكنة. إذا ضُبط هذا على "isolate"، فيمكن إدراج وحدة واحدة فقط في OnSuccess=/OnFailure=.

    أُضيف في الإصدارة 209.

IgnoreOnIsolate=
    يأخذ معاملًا منطقيًا. إذا كان true، فلن تُوقف هذه الوحدة عند عزل وحدة أخرى. الإعداد المبدئي هو false لوحدات الخدمة، والهدف، والمقبس، والمؤقت، والمسار، وtrue لوحدات الشريحة، والنطاق، والجهاز، والمبادلة، والوصل، والوصل الآلي.

    أُضيف في الإصدارة 201.

StopWhenUnneeded=
    يأخذ معاملًا منطقيًا. إذا كان true، فستُوقف هذه الوحدة عندما لا تعود مستخدمة. لاحظ أنه لتقليل العمل المراد تنفيذه، لن يوقف systemd الوحدات مبدئيًا ما لم تتعارض مع وحدات أخرى، أو إذا طلب المستخدم إيقافها صراحةً. إذا ضبط هذا الخيار، فستُنظَّف الوحدة آلياً إذا لم تكن هناك وحدة نشطة أخرى تتطلبها. الإعداد المبدئي هو false.

    أُضيف في الإصدارة 201.

RefuseManualStart=, RefuseManualStop=
    يأخذ معاملًا منطقيًا. إذا كان true، فلا يمكن تنشيط هذه الوحدة أو إلغاء تنشيطها إلا بشكل غير مباشر. في هذه الحالة، يُرفض البدء أو الإنهاء الصريح الذي يطلبه المستخدم، ومع ذلك إذا بُدئت أو أُوقفت كتبعية لوحدة أخرى، فسينجح البدء أو الإنهاء. هذه في الغالب ميزة أمان لضمان عدم تنشيط المستخدم آلياً (عن طريق الخطأ) لوحدات غير مخصصة للتنشيط الصريح، وعدم إلغاء تنشيط وحدات غير مخصصة لإلغاء التنشيط. الإعداد المبدئي لهذه الخيارات هو false.

    أُضيف في الإصدارة 201.

AllowIsolate=
    يأخذ معاملًا منطقيًا. إذا كان true، فيمكن استخدام هذه الوحدة مع الأمر systemctl isolate. وإلا، فسيُرفض ذلك. ربما من الجيد ترك هذا مُعطلاً باستثناء وحدات الهدف التي ستُستخدم بشكل مشابه لمستويات التشغيل في أنظمة بدئ SysV، كإجراء احترازي لتجنب حالات النظام غير القابلة للاستخدام. الإعداد المبدئي لهذا الخيار هو false.

    أُضيف في الإصدارة 201.

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

    أُضيف في الإصدارة 201.

SurviveFinalKillSignal=
    يأخذ معاملًا منطقيًا. الإعداد المبدئي هو no. إذا كان yes، فلن تُرسل إشارات "SIGTERM" و"SIGKILL" النهائية إلى العمليات التي تنتمي لهذه الوحدة أثناء المرحلة النهائية من عملية إيقاف تشغيل النظام. تستبدل هذه الوظيفة الآلية الأقدم التي سمحت لبرنامج بضبط "argv[0][0] = '@'" كما هو موضح في systemd and Storage Daemons for the Root File System[3]، والتي مع ذلك تظل مدعومة.

    أُضيف في الإصدار 255.

CollectMode=
    يُعدل خوارزمية "جمع القمامة" لهذه الوحدة. يأخذ إحدى القيمتين inactive أو inactive-or-failed. إذا ضُبط على inactive، فسيُفرَّغ تحميل الوحدة إذا كانت في حالة inactive (غير نشطة) ولم يشر إليها عملاء أو وظائف أو وحدات أخرى — ومع ذلك لا تُفرَّغ إذا كانت في حالة failed (فاشلة). في وضع failed، لا تُفرَّغ الوحدات الفاشلة حتى يستدعي المستخدم systemctl reset-failed عليها لإعادة ضبط حالة failed، أو أمر مكافئ. يتغير هذا السلوك إذا ضُبط هذا الخيار على inactive-or-failed: في هذه الحالة، تُفرَّغ الوحدة حتى لو كانت في حالة failed، وبالتالي فإن إعادة ضبط حالة failed صراحةً ليست ضرورية. لاحظ أنه إذا استُخدم هذا الوضع، فسيُفرَّغ نتائج الوحدة (مثل رموز الخروج، وإشارات الخروج، والموارد المستهلكة، ...) آلياً بعد اكتمال الوحدة، باستثناء ما يُخزَّن في نظام فرعي للسجلات. الإعداد المبدئي هو inactive.

    منذ الإصدار 261، إذا ضُبط FileDescriptorStorePreserve= على yes، وكان للوحدة واصفات ملفات مخزنة، فسيُعطَّل جمع القمامة حتى تُزال الوحدة، أو يخرج مدير الخدمة، أو تحصل واصفات الملفات على EPOLLHUP أو EPOLLERR.

    أُضيف في الإصدارة 236.

FailureAction=, SuccessAction=
    اضبط الإجراء المراد اتخاذه عند توقف الوحدة ودخولها في حالة فشل أو حالة غير نشطة. يأخذ إحدى القيم: none، وreboot، وreboot-force، وreboot-immediate، وpoweroff، وpoweroff-force، وpoweroff-immediate، وexit، وexit-force، وsoft-reboot، وsoft-reboot-force، وkexec، وkexec-force، وhalt، وhalt-force، وhalt-immediate. في وضع النظام، جميع الخيارات مسموح بها. في وضع المستخدم، فقط none، وexit، وexit-force مسموح بها. كلا الخيارين افتراضياً none.

    إذا ضُبط على none، فلن يُحفَّز أي إجراء. تسبب reboot إعادة تشغيل متبعةً إجراء الإغلاق العادي (أي تعادل systemctl reboot). تسبب reboot-force إعادة تشغيل قسرية ستنهي جميع العمليات قسراً ولكن لا ينبغي أن تسبب ملفات نظام تالفة عند إعادة التشغيل (أي تعادل systemctl reboot -f)، وتسبب reboot-immediate تنفيذًا فوريًا لنداء النظام reboot(2)، مما قد يؤدي إلى فقدان البيانات (أي تعادل systemctl reboot -ff). وبالمثل، poweroff، وpoweroff-force، وpoweroff-immediate، وkexec، وkexec-force، وhalt، وhalt-force، وhalt-immediate لها تأثير إيقاف تشغيل النظام، أو تنفيذ kexec، أو إيقاف النظام على التوالي بدلالات مماثلة. تسبب exit خروج المدير متبعًا إجراء الإغلاق العادي، وتسبب exit-force إنهاءه دون إغلاق الخدمات. عند استخدام exit أو exit-force افتراضياً، يُعاد وضع خروج العملية الرئيسية للوحدة (إذا انطبق هذا) من مدير الخدمة. ومع ذلك، يمكن تجاوز هذا بـ FailureActionExitStatus=/SuccessActionExitStatus=، طالع أدناه. ستُحفِّز soft-reboot عملية إعادة تشغيل في مساحة المستخدم. soft-reboot-force تفعل ذلك أيضًا، ولكن لا تمر عبر معاملة الإغلاق مسبقًا.

    أُضيف في الإصدارة 236.

FailureActionExitStatus=, SuccessActionExitStatus=
    يتحكم في حالة الخروج المُراد نشرها مرة أخرى إلى مدير حاويات مستدعي (في حالة خدمة نظام) أو مدير خدمة (في حالة مدير مستخدم) عندما يُضبط FailureAction=/SuccessAction= على exit أو exit-force ويُحفَّز الإجراء. افتراضياً، تُنشر حالة خروج العملية الرئيسية للوحدة المُحفِّزة (إذا انطبق هذا). يأخذ قيمة في النطاق 0...255 أو سلسلة نصية فارغة لطلب السلوك المبدئي.

    أُضيف في الإصدار 240.

JobTimeoutSec=, JobRunningTimeoutSec=
    يُحدّد JobTimeoutSec= مهلة زمنية للوظيفة الكاملة التي تبدأ في التشغيل عند وضع الوظيفة في قائمة الانتظار. يُحدّد JobRunningTimeoutSec= مهلة زمنية تبدأ في التشغيل عند بدء الوظيفة الموضعة في قائمة الانتظار فعلياً. إذا وُصل إلى أي من الحدين، فستُلغى الوظيفة، ومع ذلك لن تغير الوحدة حالتها أو حتى تدخل في وضع "failed" (فشل).

    كلا الإعدادين يأخذان فترة زمنية بالوحدة المبدئية وهي الثواني، ولكن يمكن تحديد وحدات أخرى، طالع systemd.time(7). القيمة المبدئية هي "infinity" (مهل الوظائف مُعطَّلة)، باستثناء وحدات الجهاز حيث الإعداد المبدئي لـ JobRunningTimeoutSec= هو DefaultDeviceTimeoutSec=.

    ملاحظة: هذه المهل الزمنية مستقلة عن أي مهل زمنية خاصة بالوحدة (على سبيل المثال، المهلة المضبوطة بـ TimeoutStartSec= في وحدات الخدمة). مهلة الوظيفة ليس لها تأثير على الوحدة نفسها. أو بعبارة أخرى: المهل الزمنية الخاصة بالوحدة مفيدة لإلغاء تغييرات حالة الوحدة، والتراجع عنها. ومع ذلك، مهلة الوظيفة المضبوطة بهذا الخيار مفيدة لإلغاء الوظيفة التي تنتظر فقط تغيير حالة الوحدة.

    أُضيف في الإصدارة 201.

JobTimeoutAction=, JobTimeoutRebootArgument=
    يُهيئ JobTimeoutAction= اختيارياً إجراءً إضافيًا لاتخاذه عند بلوغ المهلة الزمنية، طالع وصف JobTimeoutSec= وJobRunningTimeoutSec= أعلاه. يأخذ نفس قيم FailureAction=/SuccessAction=. الإعداد المبدئي هو none.

    يُهيئ JobTimeoutRebootArgument= سلسلة إعادة تشغيل اختيارية لتمريرها إلى نداء النظام reboot(2).

    أُضيف في الإصدار 240.

StartLimitIntervalSec=interval, StartLimitBurst=burst
    اضبط تحديد معدل بدء الوحدة. الوحدات التي تُبدأ أكثر من burst (دفق) مرة ضمن فترة زمنية interval (فاصل زمني) غير مسموح لها بالبدء بعد الآن. استخدم StartLimitIntervalSec= لضبط الفاصل الزمني للتحقق وStartLimitBurst= لضبط عدد البدء المسموح به لكل فاصل زمني.

    interval عبارة عن فترة زمنية بوحدة مبدئية هي الثواني، ولكن يمكن تحديد وحدات أخرى، طالع systemd.time(7). يمكن استخدام القيمة الخاصة "infinity" لتحديد العدد الإجمالي لمحاولات البدء، حتى لو حدثت في فواصل زمنية كبيرة. القيمة المبدئية هي DefaultStartLimitIntervalSec= في ملف تهيئة المدير، ويمكن ضبطها على 0 لتعطيل أي نوع من تحديد المعدل. burst هو رقم والإعداد المبدئي له هو DefaultStartLimitBurst= في ملف تهيئة المدير.

    خيارات التهيئة هذه مفيدة بشكل خاص بالاقتران مع إعداد الخدمة Restart= (طالع systemd.service(5))؛ ومع ذلك، فهي تنطبق على جميع أنواع البدء (بما في ذلك البدء اليدوي)، وليس فقط تلك التي يُحفِّزها منطق Restart=.

    لاحظ أن الوحدات المُهيأة لـ Restart=، والتي تصل إلى حد البدء لا يُحاوَل إعادة تشغيلها بعد الآن؛ ومع ذلك، لا يزال يمكن إعادة تشغيلها يدوياً أو من مؤقت أو مقبس في وقت لاحق، بعد انقضاء interval. من تلك النقطة فصاعداً، يُنشَّط منطق إعادة التشغيل مرة أخرى. سيؤدي systemctl reset-failed إلى إفراغ عداد معدل إعادة التشغيل لخدمة ما، وهو أمر مفيد إذا أراد المدير بدء وحدة يدوياً وكان حد البدء يتداخل مع ذلك. يُفرض تحديد المعدل بعد تنفيذ أي فحوصات شرط الوحدة، وبالتالي فإن تنشيطات الوحدة ذات الشروط الفاشلة لا تُحسَب ضمن حد المعدل.

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

    لا ينطبق هذا الإعداد على وحدات الشريحة، والهدف، والجهاز، والنطاق، لأنها أنواع وحدات قد لا تفشل فعاليتها أبداً، أو قد تنجح مرة واحدة فقط.

    أُضيف في الإصدارة 229.

StartLimitAction=
    اضبط إجراءً إضافياً لاتخاذه إذا بُلِغ حد المعدل المضبوط بـ StartLimitIntervalSec= وStartLimitBurst=. يأخذ نفس قيم إعدادات FailureAction=/SuccessAction=. إذا ضُبط none، فلن يُحفِّز بلوغ حد المعدل أي إجراء باستثناء أنه لن يُسمح بالبدء. الإعداد المبدئي هو none.

    أُضيف في الإصدارة 229.

RebootArgument=
    اضبط المعامل الاختياري لنداء النظام reboot(2) إذا كان StartLimitAction= أو FailureAction= إجراء إعادة تشغيل. يعمل هذا تماماً مثل المعامل الاختياري لأمر systemctl reboot.

    أُضيف في الإصدارة 229.

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

    أُضيف في الإصدارة 201.

  الشروط والتوكيدات

قد تتضمن ملفات الوحدات أيضًا عدداً من إعدادات Condition...= وAssert...=. قبل بدء الوحدة، سيتحقق systemd من أن الشروط والتوكيدات المحدّدة صحيحة. إذا لم تكن كذلك، فسيُتخطَّى بدء الوحدة (بشكل صامت في الغالب) (في حالة الشروط)، أو يُجهَض مع رسالة خطأ (في حالة التوكيدات). الشروط أو التوكيدات الفاشلة لن تؤدي إلى نقل الوحدة إلى حالة "failed" (فشل). تُفحَص الشروط والتوكيدات في الوقت الذي ستُنفَّذ فيه وظيفة البدء الموضعة في قائمة الانتظار. لا تزال تبعيات الترتيب مُحترمة، لذا لا تزال الوحدات الأخرى تُجلب وتُرتب كما لو أن هذه الوحدة نُشِّطت بنجاح، وتُنفَّذ الشروط والتوكيدات في اللحظة الدقيقة التي ستبدأ فيها الوحدة عادةً وبالتالي يمكنها التحقق من حالة النظام بعد اكتمال تهيئة الوحدات المرتبة قبلها. استخدم تعبيرات الشروط لتخطي الوحدات التي لا تنطبق على النظام المحلي، على سبيل المثال لأن النواة أو بيئة التشغيل لا تتطلب وظائفها.

إذا حُدِّدت شروط متعددة، فستُنفَّذ الوحدة إذا انطبقت جميعها (أي يُطبق منطق AND). يمكن لفحوصات الشروط استخدام رمز الأنبوب ("|") بعد علامة يساوي ("Condition...=|...")، مما يجعل الشرط يصبح شرطاً triggering (مُحفِّزاً). إذا عُرِّف شرط مُحفِّز واحد على الأقل لوحدة ما، فستبدأ الوحدة إذا انطبق واحد على الأقل من الشروط المُحفِّزة للوحدة وانطبقت جميع الشروط العادية (أي غير المُحفِّزة). إذا بادأتَ معاملًا برمز الأنبوب وعلامة تعجب، فيجب تمرير رمز الأنبوب أولاً، وعلامة التعجب ثانياً. إذا أُسندت سلسلة نصية فارغة لأي من هذه الخيارات، فستُعاد تهيئة قائمة الشروط بالكامل، ولن يكون لأي إعدادات شروط سابقة (من أي نوع) أي تأثير.

خيارات AssertArchitecture=، وAssertVirtualization=، ... متشابهة مع الشروط ولكنها تسبب فشل وظيفة البدء (بدلاً من تخطيها). يُسجَّل الفحص الفاشل. الوحدات ذات الشروط غير المستوفاة تُعتبر في حالة نظيفة وستُجمع كقمامة إذا لم يُشر إليها. هذا يعني أنه عند الاستعلام، قد يظهر فشل الشرط أو قد لا يظهر في حالة الوحدة.

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

يمكن استخدام الفعل condition الخاص بـ systemd-analyze(1) لاختبار تعبيرات الشرط والتأكيد.

باستثناء ConditionPathIsSymbolicLink=، تتبع جميع فحوصات المسارات الوصلات الرمزية.

ConditionArchitecture=
    تحقق مما إذا كان النظام يعمل على معمارية محددة. يأخذ إحدى القيم "x86"، "x86-64"، "ppc"، "ppc-le"، "ppc64"، "ppc64-le"، "ia64"، "parisc"، "parisc64"، "s390"، "s390x"، "sparc"، "sparc64"، "mips"، "mips-le"، "mips64"، "mips64-le"، "alpha"، "arm"، "arm-be"، "arm64"، "arm64-be"، "sh"، "sh64"، "m68k"، "tilegx"، "cris"، "arc"، "arc-be"، أو "native".

    استخدم systemd-analyze(1) للحصول على القائمة الكاملة للمعماريات المعروفة.

    تُحدد المعمارية من المعلومات التي يعيدها uname(2) وبالتالي فهي تخضع لـ personality(2). لاحظ أن إعداد Personality= في ملف الوحدة نفسه ليس له أي تأثير على هذا الشرط. يُعيَّن اسم المعمارية الخاص "native" إلى المعمارية التي صُرف مدير النظام نفسه من أجلها. يمكن نفي الاختبار بإضافة علامة تعجب في بدايته.

    أُضيف في الإصدارة 201.

ConditionFirmware=
    تحقق مما إذا كانت برمجيات النظام الثابتة من نوع معين. القيم التالية ممكنة:

        • "uefi" تطابق الأنظمة التي تحتوي على EFI.

        • "device-tree" تطابق الأنظمة التي تحتوي على شجرة أجهزة (device tree).

        • "device-tree-compatible(value)" تطابق الأنظمة التي تحتوي على شجرة أجهزة متوافقة مع "value".

        • "smbios-field(field operator value)" تطابق الأنظمة التي تحتوي على حقل SMBIOS بقيمة معينة. field هو اسم حقل SMBIOS المكشوف كملف سمة "sysfs" أسفل /sys/class/dmi/id/. operator هي واحدة من "<"، "<="، ">="، ">"، "=="، "<>" لمقارنات الإصدار، و "=" و "!=" للمقارنات النصية الحرفية، أو "$="، "!$=" لمقارنات نمط الغلوب (glob) بأسلوب الصدفة. value هي القيمة المتوقعة لقيمة حقل SMBIOS (قد تحتوي على أنماط غلوب بأسلوب الصدفة في حال استخدام "$="/"!$=").

    أُضيف في الإصدار 249.

ConditionVirtualization=
    تحقق مما إذا كان النظام مُنفذًا في بيئة افتراضية واختبر اختياريًا ما إذا كان تنفيذًا محددًا. يأخذ إما قيمة منطقية للتحقق مما إذا كان قيد التنفيذ في أي بيئة افتراضية، أو واحدة من "vm" و "container" للاختبار مقابل نوع عام من حلول المحاكاة الافتراضية، أو واحدة من "qemu"، "kvm"، "amazon"، "zvm"، "vmware"، "microsoft"، "oracle"، "powervm"، "xen"، "bochs"، "uml"، "bhyve"، "qnx"، "apple"، "sre"، "openvz"، "lxc"، "lxc-libvirt"، "systemd-nspawn"، "docker"، "podman"، "rkt"، "wsl"، "proot"، "pouch"، "acrn" للاختبار مقابل تنفيذ محدد، أو "private-users" للتحقق مما إذا كنا نعمل في مساحة أسماء مستخدم. راجع systemd-detect-virt(1) للحصول على قائمة كاملة بتقنيات المحاكاة الافتراضية المعروفة ومعرفاتها. إذا كانت هناك تقنيات محاكاة افتراضية متعددة متداخلة، فيُؤخذ في الاعتبار الأعمق فقط. يمكن نفي الاختبار بإضافة علامة تعجب في بدايته.

    أُضيف في الإصدارة 244.

ConditionHost=
    يمكن استخدام ConditionHost= للمطابقة مقابل اسم المضيف، أو معرّف الجهاز، أو معرّف الإقلاع، أو UUID الخاص بمنتج المضيف. يأخذ هذا إما نص اسم المضيف (اختياريًا مع غلوب بأسلوب الصدفة) الذي يُختبر مقابل اسم المضيف المحدد محليًا كما يعيده gethostname(2)، أو معرّف 128-بت أو UUID، منسق كنص. يُقارن الأخير مقابل معرّف الجهاز، ومعرّف الإقلاع، و UUID لمنتج البرمجيات الثابتة إن وُجد. راجع machine-id(5) للحصول على تفاصيل حول معرّف الجهاز. يمكن نفي الاختبار بإضافة علامة تعجب في بدايته.

    أُضيف في الإصدارة 244.

ConditionKernelCommandLine=
    يمكن استخدام ConditionKernelCommandLine= للتحقق مما إذا كان خيار سطر أوامر نواة معين مضبوطاً (أو غير مضبوط إذا سُبق بعلامة التعجب —). يجب أن يكون المُعامل إما كلمة مفردة، أو تعييناً (أي كلمتين، تفصل بينهما "="). في الحالة الأولى، يتم البحث في سطر أوامر النواة عن الكلمة كما هي، أو كجانب أيسر من تعيين. في الحالة الأخيرة، يتم البحث عن التعيين الدقيق مع مطابقة الجانبين الأيمن والأيسر. يعمل هذا على سطر أوامر النواة المُبلغ عنه إلى مساحة المستخدم عبر /proc/cmdline، باستثناء عندما يتم استدعاء مدير الخدمة كحمولة لمدير حاويات، وفي هذه الحالة يُستخدم سطر أوامر PID 1 بدلاً من ذلك (أي /proc/1/cmdline).

    أُضيف في الإصدارة 244.

ConditionKernelVersion=
    يمكن استخدام ConditionKernelVersion= للتحقق مما إذا كانت نسخة النواة (كما يُبلغ عنها بواسطة uname -r) تطابق تعبيراً معيناً، أو لا تطابق إذا سُبقت بعلامة التعجب. يجب أن يكون المُعامل قائمة من التعبيرات (التي قد تكون موضوعة بين علامتي اقتباس). يبدأ كل تعبير بأحد "=" أو "!=" لمقارنات السلاسل، أو "<"، أو "<="، أو "=="، أو "<>"، أو ">="، أو ">" لمقارنات النسخ، أو "$="، أو "!$=" لمطابقة glob بأسلوب الصدفة. إذا لم يُحدد عامل تشغيل، يُفترض "$=".

    لاحظ أن استخدام سلسلة نسخة النواة طريقة غير موثوقة لتحديد الميزات المدعومة من قبل النواة، بسبب الممارسة الواسعة النطاق لنقل التعريفات والميزات والإصلاحات خلفياً (backporting) من أنوية المنبع الأحدث إلى نسخ أقدم توفرها التوزيعات. وبالتالي، هذا التحقق غير قابل للنقل بطبيعته ولا ينبغي استخدامه للوحدات التي قد تُستخدم في توزيعات مختلفة.

    أُضيف في الإصدارة 244.

ConditionVersion=
    يمكن استخدام ConditionVersion= للتحقق مما إذا كانت نسخة برمجية تطابق تعبيراً معيناً، أو لا تطابق إذا سُبقت بعلامة التعجب. المُعامل الأول هو البرنامج الذي يجب التحقق من نسخته. حالياً "kernel" و"systemd" و"glibc" مدعومة. إذا حُذف هذا المُعامل، يُفترض "kernel". يجب أن يكون المُعامل الثاني قائمة من التعبيرات (التي قد تكون موضوعة بين علامتي اقتباس). يبدأ كل تعبير بأحد "=" أو "!=" لمقارنات السلاسل، أو "<"، أو "<="، أو "=="، أو "<>"، أو ">="، أو ">" لمقارنات النسخ، أو "$="، أو "!$=" لمطابقة glob بأسلوب الصدفة. إذا لم يُحدد عامل تشغيل، يُفترض "$=".

    أُضيف في الإصدار 258.

ConditionCredential=
    يمكن استخدام ConditionCredential= للتحقق مما إذا كان قد تم تمرير استيثاق (credential) بالاسم المحدد إلى مدير الخدمة. انظر استيثاق النظام والخدمة[4] للحصول على تفاصيل حول الاستيثاق. إذا استُخدم في الخدمات لمدير خدمة النظام، فقد يُستخدم هذا لتكييف الخدمات بناءً على استيثاق النظام المُمرر. إذا استُخدم في الخدمات لمدير خدمة المستخدم، فقد يُستخدم هذا لتكييف الخدمات بناءً على الاستيثاق المُمرر إلى مثيل خدمة unit@.service التابع للمستخدم. يجب أن يكون المُعامل اسم استيثاق صالحاً.

    أُضيف في الإصدار 252.

ConditionEnvironment=
    يمكن استخدام ConditionEnvironment= للتحقق مما إذا كان متغير بيئة معين مضبوطاً (أو غير مضبوط إذا سُبق بعلامة التعجب —) في كتلة بيئة مدير الخدمة. قد يكون المُعامل كلمة مفردة، للتحقق مما إذا كان المتغير بهذا الاسم مُعرَّفاً في كتلة البيئة، أو تعييناً ("name=value")، للتحقق مما إذا كان المتغير بهذه القيمة الدقيقة مُعرَّفاً. لاحظ أن كتلة بيئة مدير الخدمة نفسها هي التي تُفحص، أي ليس أي متغيرات مُعرفة بـ Environment= أو EnvironmentFile=، كما وُصف أعلاه. هذا مفيد بشكل خاص عندما يعمل مدير الخدمة داخل بيئة حاوية أو كمدير خدمة لكل مستخدم، من أجل التحقق من المتغيرات المُمررة بواسطة مدير الحاويات المحيط أو PAM.

    أُضيف في الإصدار 246.

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

    جدول 3. تقنيات الأمن المُعترف بها
    القيمة | الوصف
    selinux | SELinux MAC
    apparmor | AppArmor MAC
    tomoyo | Tomoyo MAC
    smack | SMACK MAC
    ima | بنية قياس النزاهة (IMA)
    audit | إطار عمل تدقيق Linux
    uefi-secureboot | الإقلاع الآمن لـ UEFI
    tpm2 | وحدة المنصة الموثوقة 2.0 (TPM2) (مع دعم UEFI الكامل، بما في ذلك تشكيلة برمجيات منصة عميل TCG PC)
    cvm | آلة افتراضية سرية (SEV/TDX)
    measured-uki | صورة النواة الموحدة مع قياسات PCR 11، وفقاً لـ systemd-stub(7). أُضيفت في الإصدار 255.

    يمكن نفي الاختبار بوضع علامة تعجب قبله.

    أُضيف في الإصدارة 244.

ConditionCapability=
    تحقق مما إذا كانت الصلاحية المعطاة موجودة في مجموعة صلاحيات مدير الخدمة (أي. هذا لا يتحقق مما إذا كانت الصلاحية متاحة فعلياً في المجموعات المسموح بها أو الفعالة، راجع capabilities(7) لمزيد من التفاصيل). مرر اسم صلاحية مثل "CAP_MKNOD"، مسبوقاً -إن لزم الأمر- بعلامة تعجب لنفي التحقق.

    أُضيف في الإصدارة 244.

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

    أُضيف في الإصدارة 244.

ConditionNeedsUpdate=
    يأخذ أحد المسارين /var/ أو /etc/ كوسيط، مسبوقاً -إن لزم الأمر- بـ "!" (لعكس الشرط). يمكن استخدام هذا الشرط لربط الوحدات شرطياً بمدى حاجة المجلد المحدد إلى تحديث لأن وقت تعديل /usr/ أحدث من ملف الطابع .updated في المجلد المحدد. هذا مفيد لتنفيذ تحديثات دون اتصال لموارد نظام تشغيل البائع في /usr/ التي تتطلب تحديث /etc/ أو /var/ في الإقلاع التالي. الوحدات التي تستخدم هذا الشرط يجب أن تُرتب قبل systemd-update-done.service(8)، لضمان عملها قبل إعادة ضبط وقت تعديل ملف الطابع للإشارة إلى اكتمال التحديث.

    إذا حُدد الخيار systemd.condition_needs_update= في سطر أوامر النواة (يأخذ قيمة منطقية)، فإنه سيتجاوز نتيجة فحص هذا الشرط، وله الأولوية على أي فحوصات لوقت تعديل الملف. إذا استُخدم خيار سطر أوامر النواة، فلن يكون لـ systemd-update-done.service تأثير فوري على أي فحوصات ConditionNeedsUpdate= لاحقة، حتى يُعاد إقلاع النظام بدون تحديد خيار سطر أوامر النواة هذا.

    لاحظ أنه لجعل هذا المخطط فعالًا، يجب تحديث الطابع الزمني لـ /usr/ صراحةً بعد تعديل محتوياته. ستُحدّث النواة الطابع الزمني للتعديل على دليل ما آليًا فقط عند تعديل الأبناء المباشرين للدليل؛ أما تعديل الملفات المتداخلة فلن يؤدي آليًا إلى تحديث mtime لـ /usr/.

    لاحظ أيضًا أنه إذا كانت طريقة التحديث تتضمن استدعاءً لتنفيذ خطوات ما بعد التحديث المناسبة بذاتها، فلا ينبغي أن تلمس الطابع الزمني لـ /usr/. في مخطط حزم التوزيع النموذجي، ستنفذ الحزم أي خطوات تحديث مطلوبة كجزء من التثبيت أو الترقية، لجعل محتويات الحزمة قابلة للاستخدام فورًا. يجب استخدام ConditionNeedsUpdate= مع آليات تحديث أخرى حيث لا يحدث مثل هذا التحديث الفوري.

    أُضيف في الإصدارة 244.

ConditionFirstBoot=
    يأخذ وسيطًا منطقيًا. يمكن استخدام هذا الشرط لربط الوحدات شرطيًا بما إذا كان النظام يقلع لأول مرة. يعني هذا تقريبًا أن /etc/ كان غير مأهول عندما بدأ النظام في الإقلاع (للتفاصيل، راجع "دلالات الإقلاع الأول" في machine-id(5)). يُعتبر الإقلاع الأول منتهيًا (سيُقيَّم هذا الشرط كخطأ) بعد أن ينهي المدير مرحلة بدء التشغيل.

    يمكن استخدام هذا الشرط لملء /etc/ عند الإقلاع الأول بعد إعادة ضبط المصنع، أو عند إقلاع نسخة نظام جديدة لأول مرة.

    لاحظ أن مدير الخدمة نفسه سينفذ خطوات الإعداد أثناء الإقلاع الأول: سيهيئ machine-id(5) ويضبط مسبقًا جميع الوحدات، مُمكّنًا أو مُعطّلًا لها وفقًا لإعدادات systemd.preset(5). يمكن تنفيذ إعداد إضافي عبر وحدات تحتوي على ConditionFirstBoot=yes.

    للمتانة، يجب أن ترتب الوحدات التي تحتوي على ConditionFirstBoot=yes نفسها قبل first-boot-complete.target وتستدعي هذا الهدف الخامل باستخدام Wants=. يضمن هذا أنه في حالة إجهاض الإقلاع الأول، ستُعاد عملية تشغيل هذه الوحدات أثناء إقلاع النظام التالي.

    إذا حُدّد الخيار systemd.condition_first_boot= في سطر أوامر النواة (بأخذ قيمة منطقية)، فسيتجاوز نتيجة فحص هذا الشرط، ويكون له الأسبقية على فحوصات وجود /etc/machine-id.

    أُضيف في الإصدارة 244.

ConditionPathExists=
    افحص وجود ملف. إذا كان اسم المسار المطلق المحدد غير موجود، فسيفشل الشرط. إذا كان اسم المسار المطلق الممرر إلى ConditionPathExists= مسبوقًا بعلامة تعجب ("!")، يُنْفى الاختبار، ولا تُبدأ الوحدة إلا إذا كان المسار غير موجود.

    أُضيف في الإصدارة 244.

ConditionPathExistsGlob=
    ConditionPathExistsGlob= مشابه لـ ConditionPathExists=، لكنه يفحص وجود ملف واحد على الأقل أو دليل يطابق نمط البحث المحدد.

    أُضيف في الإصدارة 244.

ConditionPathIsDirectory=
    ConditionPathIsDirectory= مشابه لـ ConditionPathExists= ولكنه يتحقق من أن مسارًا معينًا موجود وأنه دليل.

    أُضيف في الإصدارة 244.

ConditionPathIsSymbolicLink=
    ConditionPathIsSymbolicLink= مشابه لـ ConditionPathExists= ولكنه يتحقق من أن مسارًا معينًا موجود وأنه وصلة رمزية.

    أُضيف في الإصدارة 244.

ConditionPathIsMountPoint=
    ConditionPathIsMountPoint= مشابه لـ ConditionPathExists= ولكنه يتحقق من أن مسارًا معينًا موجود وأنه نقطة وصل.

    أُضيف في الإصدارة 244.

ConditionPathIsReadWrite=
    ConditionPathIsReadWrite= مشابه لـ ConditionPathExists= ولكنه يتحقق من أن نظام الملفات الأساسي قابل للقراءة والكتابة (أي لم يُوصل للقراءة فقط).

    أُضيف في الإصدارة 244.

ConditionPathIsEncrypted=
    ConditionPathIsEncrypted= مشابه لـ ConditionPathExists= ولكنه يتحقق من أن الجهاز الكتلي الداعم لنظام الملفات الأساسي مُعمّى باستخدام dm-crypt/LUKS. لاحظ أن هذا الفحص لا يغطي تعمية ext4 لكل دليل، ويكتشف فقط التعمية على مستوى الجهاز الكتلي. علاوة على ذلك، إذا كان المسار المحدد يقع على نظام ملفات فوق جهاز كتلي استرجاعي (loopback)، فلا تُكتشف إلا التعمية الموجودة فوق جهاز الاسترجاع. لا يُكتشف ما إذا كان نظام الملفات الذي يدعم الجهاز الكتلي الاسترجاعي مُعمّى أم لا.

    أُضيف في الإصدار 246.

ConditionPathIsSocket=
    ConditionPathIsSocket= مشابه لـ ConditionPathExists= ولكنه يتحقق من وجود مسار معين وكونه مقبساً.

    أُضيف في الإصدار 260.

ConditionDirectoryNotEmpty=
    ConditionDirectoryNotEmpty= مشابه لـ ConditionPathExists= ولكنه يتحقق من وجود مسار معين وكونه مجلداً غير فارغ.

    أُضيف في الإصدارة 244.

ConditionFileNotEmpty=
    ConditionFileNotEmpty= مشابه لـ ConditionPathExists= ولكنه يتحقق من وجود مسار معين وكونه يشير إلى ملف عادي بحجم غير صفري.

    أُضيف في الإصدارة 244.

ConditionFileIsExecutable=
    ConditionFileIsExecutable= مشابه لـ ConditionPathExists= ولكنه يتحقق من وجود مسار معين وكونه ملفاً عادياً ومميزاً كقابل للتنفيذ.

    أُضيف في الإصدارة 244.

ConditionUser=
    ConditionUser= يأخذ "UID" رقمياً، أو اسم مستخدم UNIX، أو القيمة الخاصة "@system". يمكن استخدام هذا الشرط للتحقق مما إذا كان مدير الخدمة يعمل كالمستخدم المعطى. يمكن استخدام القيمة الخاصة "@system" للتحقق مما إذا كان معرف المستخدم ضمن نطاق مستخدمي النظام. هذا الخيار ليس مفيداً لخدمات النظام، حيث أن مدير النظام يعمل حصرياً كمستخدم الجذر، وبالتالي فإن نتيجة الاختبار ثابتة.

    أُضيف في الإصدارة 244.

ConditionGroup=
    ConditionGroup= مشابه لـ ConditionUser= ولكنه يتحقق مما إذا كانت المجموعة الحقيقية أو الفعالة لمدير الخدمة، أو أي من مجموعاته المساعدة، تطابق المجموعة أو GID المحدد. هذا الإعداد لا يدعم القيمة الخاصة "@system".

    أُضيف في الإصدارة 244.

ConditionControlGroupController=
    تحقق مما إذا كانت متحكمات cgroup المعطاة (مثل "cpu") متاحة للاستخدام على النظام أو ما إذا كان يُستخدم تسلسل cgroup الهرمي v1 القديم أو v2 الحديث.

    يمكن تمرير متحكمات متعددة مع فصلها بمسافة؛ في هذه الحالة، سينجح الشرط فقط إذا كانت جميع المتحكمات المدرجة متاحة للاستخدام. المتحكمات غير المعروفة لـ systemd تُتجاهل. المتحكمات الصالحة هي "cpu"، و "io"، و "memory"، و "pids". حتى لو كانت متاحة في النواة، قد لا يكون متحكم معين متاحاً إذا عُطل في سطر أوامر النواة باستخدام cgroup_disable=controller.

    بدلاً من ذلك، يمكن تحديد سلسلتين خاصتين هما "v1" و "v2" (بدون أي أسماء متحكمات). سينجح "v2" إذا كان تسلسل cgroup الهرمي v2 الموحد مستخدماً، وسينجح "v1" إذا كان تسلسل v1 الهرمي القديم أو التسلسل الهجين مستخدماً. لاحظ أن التسلسلات الهرمية القديمة أو الهجينة أصبحت مهملة. راجع systemd(1) لمزيد من المعلومات.

    أُضيف في الإصدارة 244.

ConditionMemory=
    تحقق مما إذا كان المقدار المحدد من ذاكرة النظام متاحاً للنظام الحالي. يأخذ حجماً للذاكرة بالبايت كوسيط، مسبوقاً -إن لزم الأمر- بمعامل مقارنة مثل "<"، أو "<="، أو "=" (أو "==")، أو "!=" (أو "<>")، أو ">="، أو ">". في الأنظمة المعدنية (Bare-metal) يقارن مقدار الذاكرة الفيزيائية في النظام بالحجم المحدد، مع الالتزام بمعامل المقارنة المحدد. في الحاويات يقارن مقدار الذاكرة المخصصة للحاوية بدلاً من ذلك.

    أُضيف في الإصدارة 244.

ConditionCPUs=
    تحقق مما إذا كان العدد المحدد من المعالجات متاحاً للنظام الحالي. يأخذ عدداً من المعالجات كوسيط، مسبوقاً -إن لزم الأمر- بمعامل مقارنة مثل "<"، أو "<="، أو "=" (أو "==")، أو "!=" (أو "<>")، أو ">="، أو ">". يقارن عدد المعالجات في قناع تقارب المعالج المهيأ لمدير الخدمة نفسه بالعدد المحدد، مع الالتزام بمعامل المقارنة المحدد. في الأنظمة الفيزيائية يطابق عدد المعالجات في قناع التقارب لمدير الخدمة عادةً عدد المعالجات الفيزيائية، لكنه قد يختلف في البيئات الخاصة والافتراضية. وبالأخص، في الحاويات يطابق قناع التقارب عادةً عدد المعالجات المخصصة للحاوية وليس المعالجات المتاحة فيزيائياً.

    أُضيف في الإصدارة 244.

ConditionCPUFeature=
    تحقق مما إذا كانت ميزة معالجة معطاة متاحة عبر تعليمة "CPUID". هذا الشرط يعمل فقط على معالجات i386 و x86-64. على معالجات أخرى يُفترض أن المعالج لا يدعم الميزة المعطاة. يتحقق من الأوراق "1"، و "7"، و "0x80000001"، و "0x80000007". القيم الصالحة هي: "fpu"، "vme"، "de"، "pse"، "tsc"، "msr"، "pae"، "mce"، "cx8"، "apic"، "sep"، "mtrr"، "pge"، "mca"، "cmov"، "pat"، "pse36"، "clflush"، "mmx"، "fxsr"، "sse"، "sse2"، "ht"، "pni"، "pclmul"، "monitor"، "ssse3"، "fma3"، "cx16"، "sse4_1"، "sse4_2"، "movbe"، "popcnt"، "aes"، "xsave"، "osxsave"، "avx"، "f16c"، "rdrand"، "bmi1"، "avx2"، "bmi2"، "rdseed"، "adx"، "sha_ni"، "syscall"، "rdtscp"، "lm"، "lahf_lm"، "abm"، "constant_tsc".

    أُضيف في الإصدار 248.

ConditionOSRelease=
    تحقق مما إذا كان زوج "key=value" محدد مضبوطاً في ملف os-release(5) للمضيف.

    بخلاف مطابقة السلاسل النصية الدقيقة (باستخدام "=" و "!=")، تُدعم المقارنات النسبية للمعاملات ذات الإصدارات (مثل "VERSION_ID"؛ باستخدام "<"، أو "<="، أو "=="، أو "<>"، أو ">="، أو ">")، وتُدعم مقارنات المحارف البديلة بأسلوب الصدفة ("*"، "?"، "[]") باستخدام "$=" (للمطابقة) و "!$=" (لعدم المطابقة).

    إذا لم يُعثر على المفتاح المعطى في الملف، تُنفذ المطابقة مقابل قيمة فارغة.

    أُضيف في الإصدار 249.

ConditionMemoryPressure=, ConditionCPUPressure=, ConditionIOPressure=
    تحقق مما إذا كان ضغط النظام الكلي (الذاكرة، أو المعالج، أو الإدخال/الإخراج) أقل من أو يساوي عتبة معينة. يأخذ هذا الإعداد قيمة عتبة كوسيط. يمكن تحديدها كقيمة مئوية بسيطة، متبوعة بـ "%"، وفي هذه الحالة سيُقاس الضغط كمتوسط خلال الدقائق الخمس الأخيرة قبل تنفيذ محاولة بدء الوحدة. بدلاً من ذلك، يمكن تحديد النطاق الزمني للمتوسط باستخدام "/" كفاصل، على سبيل المثال: "10%/1min". النطاقات الزمنية المدعومة تطابق ما توفره النواة، وهي محدودة بـ "10sec"، و "1min"، و "5min". سيُفحص مؤشر "full" PSI أولاً، وإذا لم يُعثر عليه سيُفحص "some". لمزيد من التفاصيل، راجع التوثيق الخاص بـ PSI (معلومات توقف الضغط)[5].

    اختيارياً، يمكن أن تُسبق قيمة العتبة بوحدة الشريحة (slice unit) التي سيُفحص الضغط تحتها، متبوعة بـ ":". إذا لم تُحدد وحدة الشريحة، فسيُقاس ضغط النظام الكلي، بدلاً من ضغط cgroup معين.

    أُضيف في الإصدار 250.

ConditionKernelModuleLoaded=
    اختبر ما إذا كانت وحدة النواة المحددة قد حُملت وأصبحت مهيأة بالكامل.

    أُضيف في الإصدار 258.

AssertArchitecture=, AssertVirtualization=, AssertHost=, AssertKernelCommandLine=, AssertKernelVersion=, AssertVersion=, AssertCredential=, AssertEnvironment=, AssertSecurity=, AssertCapability=, AssertACPower=, AssertNeedsUpdate=, AssertFirstBoot=, AssertPathExists=, AssertPathExistsGlob=, AssertPathIsDirectory=, AssertPathIsSymbolicLink=, AssertPathIsMountPoint=, AssertPathIsReadWrite=, AssertPathIsEncrypted=, AssertPathIsSocket=, AssertDirectoryNotEmpty=, AssertFileNotEmpty=, AssertFileIsExecutable=, AssertUser=, AssertGroup=, AssertControlGroupController=, AssertMemory=, AssertCPUs=, AssertCPUFeature=, AssertOSRelease=, AssertMemoryPressure=, AssertCPUPressure=, AssertIOPressure=, AssertKernelModuleLoaded=
    على غرار إعدادات الشروط ConditionArchitecture=، و ConditionVirtualization=، ... الموصوفة أعلاه، تضيف هذه الإعدادات فحوصات توكيد (assertion) لبدء تشغيل الوحدة. ومع ذلك، على عكس إعدادات الشروط، فإن أي إعداد توكيد لا يتحقق يؤدي إلى فشل مهمة البدء (مما يعني تسجيل ذلك بصوت عالٍ). لاحظ أن عدم تحقق توكيد مهيأ لا يتسبب في دخول الوحدة في حالة "فاشلة" (أو في الواقع يؤدي إلى أي تغيير في حالة الوحدة)، بل يؤثر فقط على المهمة المصطفة لها. استخدم تعبيرات التوكيد للوحدات التي لا يمكنها العمل عندما لا تتحقق متطلبات معينة، وعندما يكون هذا شيئاً يجب على المدير أو المستخدم النظر فيه.

    أُضيف في الإصدارة 218.

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

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

جدول 4. خصائص الوحدة الأمامية والعكسية
خاصية "أمامية" | خاصية "عكسية" | مكان الاستخدام
Before= | After= | قسم [Unit]
After= | Before= |  |
Requires= | RequiredBy= | قسم [Unit] | قسم [Install]
Wants= | WantedBy= | قسم [Unit] | قسم [Install]
Upholds= | UpheldBy= | قسم [Unit] | قسم [Install]
PartOf= | ConsistsOf= | قسم [Unit] | خاصية آلية
BindsTo= | BoundBy= | قسم [Unit] | خاصية آلية
Requisite= | RequisiteOf= | قسم [Unit] | خاصية آلية
Conflicts= | ConflictedBy= | قسم [Unit] | خاصية آلية
Triggers= | TriggeredBy= | خصائص آلية، انظر الملاحظات أدناه
PropagatesReloadTo= | ReloadPropagatedFrom= | قسم [Unit]
ReloadPropagatedFrom= | PropagatesReloadTo= |  |
PropagatesStopTo= | StopPropagatedFrom= | قسم [Unit]
StopPropagatedFrom= | PropagatesStopTo= |  |
Following= | n/a | خاصية آلية |

ملاحظة: تُستخدم 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=
    قائمة مفصولة بمسافات بأسماء إضافية سيتم تثبيت هذه الوحدة تحتها. يجب أن يكون للأسماء المدرجة هنا نفس اللاحقة (أي النوع) مثل اسم ملف الوحدة. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُستخدم جميع الأسماء المدرجة. في وقت التثبيت، سيُنشئ systemctl enable روابط رمزية من هذه الأسماء إلى اسم ملف الوحدة. لاحظ أنه لا تدعم جميع أنواع الوحدات مثل هذه الأسماء المستعارة، وهذا الإعداد غير مدعوم لها. على وجه التحديد، وحدات الوصل، والشرائح، والمبادلة، والوصل الآلي لا تدعم التسمية المستعارة.

    أُضيف في الإصدارة 201.

WantedBy=, RequiredBy=, UpheldBy=
    يمكن استخدام هذا الخيار أكثر من مرة، أو يمكن إعطاء قائمة مفصولة بمسافات بأسماء الوحدات. يُنشأ رابط رمزي في دليل .wants/، أو .requires/، أو .upholds/ لكل وحدة من الوحدات المدرجة عند تثبيت هذه الوحدة بواسطة systemctl enable. يؤدي هذا إلى إضافة اعتمادية من نوع Wants=، أو Requires=، أو Upholds= من الوحدة المدرجة إلى الوحدة الحالية. راجع وصف أنواع الاعتمادية المذكورة في قسم [Unit] للتفاصيل.

    في حالة وحدات القوالب التي تدرج وحدات ليست قوالب، يجب أن يكون للوحدة المُدرِجة إعداد DefaultInstance=، أو يجب استدعاء systemctl enable باسم حالة. ستُضاف الحالة (المبدئية أو المحددة) إلى قائمة .wants/، أو .requires/، أو .upholds/ للوحدة المدرجة. على سبيل المثال، WantedBy=getty.target في خدمة getty@.service سيؤدي إلى إنشاء systemctl enable getty@tty2.service لرابط getty.target.wants/getty@tty2.service إلى getty@.service. ينطبق هذا أيضًا على إدراج حالات محددة من وحدات القوالب: ستكتسب هذه الحالة المحددة الاعتمادية. قد تُدرج وحدة القالب أيضًا وحدة قالب، وفي هذه الحالة ستُضاف اعتمادية عامة حيث سيكون لكل حالة من الوحدة المُدرِجة اعتمادية على حالة من القالب المدرج بنفس قيمة الحالة. على سبيل المثال، WantedBy=container@.target في خدمة monitor@.service سيؤدي إلى إنشاء systemctl enable monitor@.service لرابط container@.target.wants/monitor@.service إلى monitor@.service، وهو ما ينطبق على جميع حالات container@.target.

    أُضيف في الإصدارة 201.

Also=
    وحدات إضافية لتثبيتها/إلغاء تثبيتها عند تثبيت/إلغاء تثبيت هذه الوحدة. إذا طلب المستخدم تثبيت/إلغاء تثبيت وحدة مهيأ فيها هذا الخيار، فسيقوم systemctl enable وsystemctl disable تلقائياً بتثبيت/إلغاء تثبيت الوحدات المدرجة في هذا الخيار أيضًا.

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

    أُضيف في الإصدارة 201.

DefaultInstance=
    في ملفات وحدات القوالب، يحدد هذا لأي حالة يجب تمكين الوحدة إذا تم تمكين القالب بدون أي حالة محددة بوضوح. ليس لهذا الخيار أي تأثير في ملفات الوحدات التي ليست قوالب. يجب أن يكون السلسلة المحددة قابلة للاستخدام كمعرف للحالة.

    أُضيف في الإصدارة 215.

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

المحددات

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

جدول 5. المحددات المتاحة في ملفات الوحدات
المحدد | المعنى | التفاصيل
"%a" | المعمارية | سلسلة قصيرة تحدد معمارية النظام المحلي. سلسلة مثل x86، أو x86-64، أو arm64. راجع المعماريات المحددة لـ ConditionArchitecture= أعلاه للحصول على قائمة كاملة.
"%A" | إصدار صورة نظام التشغيل | معرف إصدار صورة نظام التشغيل للنظام المشغل، كما يُقرأ من حقل IMAGE_VERSION= في /etc/os-release. إذا لم يُضبط، يُحل إلى سلسلة فارغة. انظر os-release(5) لمزيد من المعلومات.
"%b" | معرف الإقلاع | معرف الإقلاع للنظام المشغل، منسق كسلسلة نصية. انظر random(4) لمزيد من المعلومات.
"%B" | معرف بناء نظام التشغيل | معرف بناء نظام التشغيل للنظام المشغل، كما يُقرأ من حقل BUILD_ID= في /etc/os-release. إذا لم يُضبط، يُحل إلى سلسلة فارغة. انظر os-release(5) لمزيد من المعلومات.
"%C" | جذر دليل الخبيئة | هذا إما /var/cache (لمدير النظام) أو المسار الذي يحل إليه "$XDG_CACHE_HOME" (لمديري المستخدمين).
"%d" | دليل الاستيثاق | هذه هي قيمة متغير البيئة "$CREDENTIALS_DIRECTORY" إن توفر. راجع قسم "Credentials" في systemd.exec(5) لمزيد من المعلومات.
"%D" | دليل البيانات المشتركة | هذا إما /usr/share/ (لمدير النظام) أو المسار الذي يحل إليه "$XDG_DATA_HOME" (لمديري المستخدمين).
"%E" | جذر دليل التهيئة | هذا إما /etc/ (لمدير النظام) أو المسار الذي يحل إليه "$XDG_CONFIG_HOME" (لمديري المستخدمين).
"%f" | اسم الملف غير المُرمّز | هذا إما اسم الحالة غير المُرمّز (إن انطبق) مع إضافة / في البداية (إن انطبق)، أو اسم البادئة غير المُرمّز مع إضافة / في البداية. يُنفذ هذا إلغاء الترميز وفقاً لقواعد ترميز مسارات نظام الملفات المطلقة التي نوقشت أعلاه.
"%g" | مجموعة المستخدم | هذا هو اسم المجموعة التي تُشغِّل مثيل مدير الخدمة. في حالة مدير النظام، يُحل هذا إلى "root".
"%G" | معرف المجموعة (GID) للمستخدم | هذا هو مُعرِّف المجموعة (GID) الرقمي للمستخدم الذي يُشغِّل مثيل مدير الخدمة. في حالة مدير النظام، يُحل هذا إلى "0".
"%h" | دليل منزل المستخدم | هذا هو دليل المنزل لـ المستخدم الذي يُشغِّل مثيل مدير الخدمة. في حالة مدير النظام، يُحل هذا إلى "/root". لاحظ أن هذا الإعداد لا يتأثر بإعداد User= القابل للضبط في قسم [Service] لوحدة الخدمة.
"%H" | اسم المضيف | اسم المضيف للنظام المُشغَّل في لحظة تحميل إعدادات الوحدة.
"%i" | اسم المثيل | بالنسبة للوحدات المُستنسخة، هذا هو السلسلة النصية بين أول محرف "@" ولاحقة النوع. فارغ للوحدات غير المُستنسخة.
"%I" | اسم المثيل غير المُهَرَّب | مثل "%i"، ولكن مع إزالة الهروب.
"%j" | المكوِّن الأخير للبادئة | هذه هي السلسلة النصية بين آخر "-" ونهاية اسم البادئة. إذا لم يوجد "-"، فهذا يطابق "%p".
"%J" | المكوِّن الأخير للبادئة غير المُهَرَّب | مثل "%j"، ولكن مع إزالة الهروب.
"%l" | اسم المضيف القصير | اسم المضيف للنظام المُشغَّل في لحظة تحميل إعدادات الوحدة، مُقتطَع عند أول نقطة لإزالة أي مكوِّن نطاق.
"%L" | جذر دليل السجل | هذا هو إما /var/log (لمدير النظام) أو المسار الذي يُحَل إليه $XDG_STATE_HOME مع إضافة /log إليه (لمديري المستخدم).
"%m" | معرف الآلة | معرف الجهاز للنظام المشغل، منسق كسلسلة نصية. انظر machine-id(5) لمزيد من المعلومات.
"%M" | معرف صورة نظام التشغيل | معرف صورة نظام التشغيل للنظام المشغل، كما يُقرأ من حقل IMAGE_ID= في /etc/os-release. إذا لم يُضبط، يُحل إلى سلسلة فارغة. انظر os-release(5) لمزيد من المعلومات.
"%n" | اسم الوحدة الكامل |
"%N" | اسم الوحدة الكامل | مثل "%n"، ولكن مع إزالة لاحقة النوع.
"%o" | معرف نظام التشغيل | معرف نظام التشغيل للنظام المشغل، كما يُقرأ من حقل ID= في /etc/os-release. انظر os-release(5) لمزيد من المعلومات.
"%p" | اسم البادئة | بالنسبة للوحدات المُستنسخة، يشير هذا إلى السلسلة النصية قبل أول محرف "@" في اسم الوحدة. للوحدات غير المُستنسخة، يطابق "%N".
"%P" | اسم البادئة غير المُهَرَّب | مثل "%p"، ولكن مع إزالة الهروب.
"%q" | اسم المضيف الجميل | اسم المضيف الجميل للنظام المُشغَّل في لحظة تحميل إعدادات الوحدة، كما قُرئ من حقل PRETTY_HOSTNAME= في /etc/machine-info. إذا لم يُضبط، يُحل إلى اسم المضيف القصير. انظر machine-info(5) للمزيد من المعلومات.
"%s" | صدفة المستخدم | هذه هي صدفة المستخدم الذي يُشغِّل مثيل مدير الخدمة.
"%S" | جذر دليل الحالة | هذا هو إما /var/lib (لمدير النظام) أو المسار الذي يُحَل إليه $XDG_STATE_HOME (لمديري المستخدم).
"%t" | جذر دليل وقت التشغيل | هذا هو إما /run/ (لمدير النظام) أو المسار الذي يُحَل إليه "$XDG_RUNTIME_DIR" (لمديري المستخدم).
"%T" | مجلد للملفات المؤقتة | هذا إما /tmp أو المسار الذي ضُبطت إليه "$TMPDIR" أو "$TEMP" أو "$TMP". (لاحظ أن الدليل قد يُحدد بدون شرطة مائلة لاحقة.)
"%u" | اسم المستخدم | هذا هو اسم المستخدم الذي يُشغِّل مثيل مدير الخدمة. في حالة مدير النظام، يُحل هذا إلى "root". لاحظ أن هذا الإعداد لا يتأثر بإعداد User= القابل للضبط في قسم [Service] لوحدة الخدمة.
"%U" | معرف المستخدم (UID) | هذا هو مُعرِّف المستخدم (UID) الرقمي لـ المستخدم الذي يُشغِّل مثيل مدير الخدمة. في حالة مدير النظام، يُحل هذا إلى "0". لاحظ أن هذا الإعداد لا يتأثر بإعداد User= القابل للضبط في قسم [Service] لوحدة الخدمة.
"%v" | إصدار النواة | مطابق لمخرجات uname -r.
"%V" | مجلد للملفات المؤقتة الأكبر حجمًا والمستمرة | هذا إما /var/tmp أو المسار الذي ضُبطت إليه "$TMPDIR" أو "$TEMP" أو "$TMP". (لاحظ أن الدليل قد يُحدد بدون شرطة مائلة لاحقة.)
"%w" | معرف إصدار نظام التشغيل | معرف إصدار نظام التشغيل للنظام المشغل، كما يُقرأ من حقل VERSION_ID= في /etc/os-release. إذا لم يُضبط، يُحل إلى سلسلة فارغة. انظر os-release(5) لمزيد من المعلومات.
"%W" | معرف نوع نظام التشغيل | معرف تنويعة نظام التشغيل للنظام المشغل، كما يُقرأ من حقل VARIANT_ID= في /etc/os-release. إذا لم يُضبط، يُحل إلى سلسلة فارغة. انظر os-release(5) لمزيد من المعلومات.
"%y" | المسار إلى القطعة | هذا هو المسار حيث يقع الجزء الرئيس من ملف الوحدة. بالنسبة لملفات الوحدات المرتبطة، يُستخدم المسار الحقيقي خارج أدلة بحث الوحدات. بالنسبة للوحدات التي لا تملك ملف قطعة، سيُثير هذا المحدِّد خطأً.
"%Y" | دليل القطعة | هذا هو جزء الدليل من "%y".
"%%" | علامة مئوية مفردة | استخدم "%%" بدلاً من "%" لتحديد علامة مئوية مفردة.

أمثلة

مثال 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.  وعد استقرار وقابلية نقل الواجهة
    https://systemd.io/PORTABILITY_AND_STABILITY/

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

3.  systemd وعفاريت التخزين لنظام ملفات الجذر
    https://systemd.io/ROOT_STORAGE_DAEMONS

4.  بيانات اعتماد النظام والخدمة
    https://systemd.io/CREDENTIALS

5.  PSI (معلومات توقف الضغط)
    https://docs.kernel.org/accounting/psi.html

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

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 (https://www.gnu.org/licenses/gpl-3.0.html) أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

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