SYSTEMD.EXEC(5)

systemd.exec

SYSTEMD.EXEC(5)

الاسم¶

systemd.exec - تهيئة بيئة التنفيذ

موجز¶

service.service, socket.socket, mount.mount, swap.swap

الوصف¶

تتشارك ملفات تهيئة الوحدات الخاصة بالخدمات والمقابس ونقاط الوصل وأجهزة التبديل في مجموعة فرعية من خيارات التهيئة التي تحدد بيئة تنفيذ العمليات المولدة.

تسرد صفحة الدليل هذه خيارات التهيئة المشتركة بين أنواع الوحدات الأربعة هذه. انظر systemd.unit(5) للخيارات المشتركة لجميع ملفات تهيئة الوحدات، و systemd.service(5)، و systemd.socket(5)، و systemd.swap(5)، و systemd.mount(5) لمزيد من المعلومات حول ملفات تهيئة الوحدات المحددة. وتُهيأ خيارات التهيئة الخاصة بالتنفيذ في أقسام [Service] أو [Socket] أو [Mount] أو [Swap]، اعتمادًا على نوع الوحدة.

بالإضافة إلى ذلك، تُسرد الخيارات التي تتحكم في الموارد من خلال مجموعات تحكم لينكس (cgroups) في systemd.resource-control(5). وتكمل تلك الخيارات الخيارات المدرجة هنا.

اعتماديات ضمنية¶

تؤدي بعض معلمات التنفيذ إلى إضافة اعتماديات إضافية آليًا:

•الوحدات التي عُيّن لها WorkingDirectory= أو RootDirectory= أو RootImage= أو RuntimeDirectory= أو StateDirectory= أو CacheDirectory= أو LogsDirectory= أو ConfigurationDirectory= تكتسب آليًا اعتماديات من النوع Requires= و After= على جميع وحدات الوصل المطلوبة للوصول إلى المسارات المحددة. هذا يعادل إدراجها صراحة في RequiresMountsFor=.

•وبالمثل، الوحدات التي فُعّل بها PrivateTmp= تحصل آليًا على تبعيات وحدات وصل لجميع الوصلات المطلوبة للوصول إلى /tmp/ و /var/tmp/. كما ستكتسب تبعية آلية After= على systemd-tmpfiles-setup.service(8).

•الوحدات التي يتصل مخرجها القياسي أو مخرج الخطأ فيها بـ journal أو kmsg (أو توليفاتها مع مخرج الطرفية، انظر أدناه) تكتسب آليًا اعتماديات من نوع After= على systemd-journald.socket.

•الوحدات التي تستخدم LogNamespace= ستكتسب آليًا اعتماديات ترتيب ومتطلبات على وحدتي المقبس المرتبطتين بنماذج systemd-journald@.service.

المسارات¶

يمكن استخدام الإعدادات التالية لتغيير منظور الخدمة لنظام الملفات. يرجى ملاحظة أن المسارات يجب أن تكون مطلقة وألا تحتوي على جزء مسار "..".

ExecSearchPath=

يأخذ قائمة مفصولة بنقطتين رأسيتين من المسارات المطلقة التي يمكن العثور فيها على الملف التنفيذي المستخدم بواسطة خصائص Exec*= (مثل ExecStart= و ExecStop= وما إلى ذلك). يتخطى ExecSearchPath= المتغير $PATH إذا لم يوفره المستخدم من خلال Environment= أو EnvironmentFile= أو PassEnvironment=. يؤدي تعيين سلسلة نصية فارغة إلى إزالة التعيينات السابقة، ويؤدي تعيين ExecSearchPath= إلى قيمة عدة مرات إلى الإلحاق بالإعداد السابق.

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

WorkingDirectory=

يأخذ مسار دليل نسبيًا إلى دليل الجذر الخاص بالخدمة والمحدد بواسطة RootDirectory=، أو القيمة الخاصة "~". يحدد دليل العمل للعمليات المنفذة. إذا عُيّن إلى "~"، فيُستخدم الدليل المنزلي للمستخدم المحدد في User=. إذا لم يُحدد، فإنه يؤول مبدئيًا إلى دليل الجذر عندما يعمل systemd كنموذج نظام، وإلى الدليل المنزلي للمستخدم المعني إذا دُور كمستخدم. إذا بُدئ الإعداد بحرف "-"، فلا يُعد غياب دليل العمل أمرًا مهلكًا. إذا لم يُعين RootDirectory=/RootImage=، فإن WorkingDirectory= يكون نسبيًا لجذر النظام الذي يدير مدير الخدمة. لاحظ أن تعيين هذه المعلمة قد يؤدي إلى إضافة اعتماديات إضافية إلى الوحدة (انظر أعلاه).

RootDirectory=

يأخذ مسار دليل نسبيًا إلى دليل جذر المضيف (أي جذر النظام الذي يدير مدير الخدمة). ويحدد دليل الجذر للعمليات المنفذة، باستخدام استدعاء النظام pivot_root(2) أو chroot(2). إذا استُخدم هذا، فيجب التأكد من أن الملف التنفيذي للعملية وجميع ملفاته المساعدة متاحة في الجذر الجديد. لاحظ أن تعيين هذه المعلمة قد يؤدي إلى إضافة اعتماديات إضافية إلى الوحدة (انظر أعلاه).

يُعد الإعدادان MountAPIVFS= و PrivateUsers= مفيدين بشكل خاص بالاقتران مع RootDirectory=. للتفاصيل، انظر أدناه.

إذا استُخدم RootDirectory=/RootImage= مع NotifyAccess=، فيُوصل مقبس الإشعار آليًا من المضيف إلى بيئة الجذر، لضمان عمل واجهة الإشعارات بشكل صحيح.

لاحظ أن الخدمات التي تستخدم RootDirectory=/RootImage= لن تتمكن من التسجيل عبر بروتوكولات syslog أو journal في البنية التحتية لتسجيل المضيف، ما لم تُوصل المقابس المعنية من المضيف، وتحديدًا:

سيُتاح ملف os-release(5) الخاص بالمضيف للخدمة (للقراءة فقط) كـ /run/host/os-release. وسيُحدّث آليًا عند إعادة التشغيل المرنة (انظر: systemd-soft-reboot.service(8))، في حال هُيئت الخدمة للبقاء بعدها.

مثال 1. وصل مقابس التسجيل في بيئة الجذر

BindReadOnlyPaths=/dev/log /run/systemd/journal/socket /run/systemd/journal/stdout

بدلاً من مسار الدليل، يُمكن تحديد دليل ذي إصدار ".v/"، راجع systemd.v(7) للتفاصيل.

هذا الخيار متاح فقط لخدمات النظام، أو للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة وفي هذه الحالة يُمكّن PrivateUsers= ضمنيًا (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=").

RootImage=

تأخذ مسارًا إلى عُقدة جهاز كتلي أو ملف عادي كوسيط. هذا الاستدعاء مشابه لـ RootDirectory= ومع ذلك، فهو يصل تسلسل هرمي لنظام ملفات من عُقدة جهاز كتلي أو ملف loopback بدلًا من دليل. تحتاج عُقدة الجهاز أو ملف صورة نظام الملفات إلى احتواء نظام ملفات بدون جدول أقسام، أو نظام ملفات داخل جدول أقسام MBR/MS-DOS أو GPT مع قسم واحد فقط متوافق مع لينكس، أو مجموعة من أنظمة الملفات داخل جدول أقسام GPT يتبع مواصفات الأقسام القابلة للاكتشاف[1].

عندما يُعين DevicePolicy= إلى "closed" أو "strict"، أو يُعين إلى "auto" ويُحدد DeviceAllow=، يضيف هذا الإعداد /dev/loop-control بالوضع rw، و "block-loop" و "block-blkext" بالوضع rwm إلى DeviceAllow=. انظر systemd.resource-control(5) للتفاصيل حول DevicePolicy= أو DeviceAllow=. وأيضًا، انظر PrivateDevices= أدناه، لأنه قد يغير إعداد DevicePolicy=.

الوحدات التي تستخدم RootImage= تكتسب آليًا اعتمادية After= على systemd-udevd.service.

بدلاً من مسار الصورة، يمكن تحديد دليل بنسخة ".v/"، راجع systemd.v(7) للمزيد من التفاصيل.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

RootImageOptions=

تأخذ قائمة مفصولة بفواصل من خيارات الوصل التي ستُستخدم على صور القرص المحددة بواسطة RootImage=. اختياريًا، يمكن وضع بادئة باسم قسم متبوع بنقطتين، في حالة كان للصورة أقسام متعددة، وإلا يُفترض اسم القسم "root". يمكن تحديد خيارات لأقسام متعددة في سطر واحد مع فواصل مسافية. تعيين سلسلة فارغة يزيل التعيينات السابقة. تُتجاهل الخيارات المكررة. للحصول على قائمة بخيارات الوصل الصالحة، يُرجى الرجوع إلى mount(8).

تتبع أسماء الأقسام الصالحة مواصفة Discoverable Partitions Specification[1]: root, usr, home, srv, esp, xbootldr, tmp, var.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

RootEphemeral=

يأخذ معاملًا منطقيًا. في حال تمكينه، ستعمل العمليات المنفذة في نسخة زائلة من دليل الجذر أو صورة الجذر. توضع النسخة الزائلة في /var/lib/systemd/ephemeral-trees/ أثناء نشاط الخدمة وتُنظّف عند إيقاف الخدمة أو إعادة تشغيلها. إذا استُخدم RootDirectory= وكان دليل الجذر حجمًا فرعيًا، فستُنشأ النسخة الزائلة عن طريق أخذ لقطة للحجم الفرعي.

للتأكد من إمكانية إنشاء نسخ زائلة بكفاءة، يجب أن يقع دليل الجذر أو صورة الجذر على نفس نظام الملفات الذي يقع عليه /var/lib/systemd/ephemeral-trees/. عند استخدام RootEphemeral= مع أدلة الجذر، ينبغي استخدام btrfs(5) كنظام ملفات، ويُفضل أن يكون دليل الجذر حجمًا فرعيًا يمكن لـ systemd أخذ لقطة له لإنشاء النسخة الزائلة. بالنسبة لصور الجذر، ينبغي استخدام نظام ملفات يدعم الروابط المرجعية (reflinks) لضمان نسخة زائلة كفؤة.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

RootHash=

يأخذ مفروم جذر لسلامة البيانات (dm-verity) محددًا بالنظام الست عشري، أو مسار ملف يحتوي على مفروم جذر بتنسيق ست عشري ASCII. يُمكّن هذا الخيار عمليات التحقق من سلامة البيانات باستخدام dm-verity، إذا كانت الصورة المستخدمة تحتوي على بيانات السلامة المناسبة (انظر أعلاه) أو إذا استُخدم RootVerity=. يجب أن يطابق المفروم المحدد مفروم الجذر لبيانات السلامة، وعادةً ما يكون طوله 256 بت على الأقل (وبالتالي 64 محرفًا ست عشريًا منسقًا) (في حالة SHA256 على سبيل المثال). إذا لم يُحدد هذا الخيار، ولكن ملف الصورة يحمل سمة الملف الموسعة "user.verity.roothash" (انظر xattr(7))، فيُقرأ مفروم الجذر منها، كأحرف ست عشرية منسقة أيضًا. إذا لم تُعثر على سمة الملف الموسعة (أو كانت غير مدعومة من نظام الملفات الأساسي)، ولكن عُثر على ملف ذي اللاحقة .roothash بجوار ملف الصورة، ويحمل نفس الاسم (إلا إذا كانت الصورة ذات اللاحقة .raw، وفي هذه الحالة يجب ألا يحتوي اسم ملف مفروم الجذر عليها)، فيُقرأ مفروم الجذر منه ويُستخدم آليًا، كأحرف ست عشرية منسقة أيضًا.

إذا كانت صورة القرص تحتوي على قسم /usr/ منفصل، فقد يكون محميًا أيضًا بواسطة Verity، وفي هذه الحالة يمكن تهيئة مفروم الجذر عبر سمة موسعة "user.verity.usrhash" أو ملف .usrhash مجاور لصورة القرص. لا يوجد حاليًا خيار لتهيئة مفروم الجذر لنظام ملفات /usr/ عبر ملف الوحدة مباشرة.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

RootHashSignature=

يأخذ توقيع PKCS7 لخيار RootHash= كمسار لملف توقيع مرمّز بـ DER، أو كسلسلة نصية ASCII مرمّزة بـ base64 لتوقيع مرمّز بـ DER مسبوق بـ "base64:". لن يُفتح حجم dm-verity إلا إذا كان توقيع مفروم الجذر صالحًا وموقعًا بواسطة مفتاح عام موجود في حلقة مفاتيح النواة. إذا لم يُحدد هذا الخيار، ولكن عُثر على ملف ذي اللاحقة .roothash.p7s بجوار ملف الصورة، ويحمل نفس الاسم (إلا إذا كانت الصورة ذات اللاحقة .raw، وفي هذه الحالة يجب ألا يحتوي اسم ملف التوقيع عليها)، فيُقرأ التوقيع منه ويُستخدم آليًا.

إذا كانت صورة القرص تحتوي على قسم /usr/ منفصل، فقد يكون محميًا أيضًا بواسطة Verity، وفي هذه الحالة يمكن تهيئة توقيع مفروم الجذر عبر ملف .usrhash.p7s مجاور لصورة القرص. لا يوجد حاليًا خيار لتهيئة توقيع مفروم الجذر لـ /usr/ عبر ملف الوحدة مباشرة.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

RootVerity=

يأخذ مسار ملف سلامة البيانات (dm-verity). يُمكّن هذا الخيار عمليات التحقق من سلامة البيانات باستخدام dm-verity، إذا استُخدم RootImage= ومُرّر مفروم جذر وإذا كانت الصورة المستخدمة نفسها لا تحتوي على بيانات السلامة. يجب أن يتطابق مفروم الجذر مع بيانات السلامة. إذا لم يُحدد هذا الخيار، ولكن عُثر على ملف ذي اللاحقة .verity بجوار ملف الصورة، ويحمل نفس الاسم (إلا إذا كانت الصورة ذات اللاحقة .raw، وفي هذه الحالة يجب ألا يحتوي اسم ملف بيانات verity عليها)، فيُقرأ بيانات verity منه وتُستخدم آليًا.

هذا الخيار مدعوم فقط لصور الأقراص التي تحتوي على نظام ملفات واحد، بدون جدول أقسام مغلف. الصور التي تحتوي على جدول أقسام GPT يجب بدلاً من ذلك أن تتضمن كلاً من نظام ملفات الجذر وبيانات Verity المطابقة في نفس الصورة، لتنفيذ Discoverable Partitions Specification[1].

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

RootImagePolicy=، و MountImagePolicy=، و ExtensionImagePolicy=

يأخذ سلسلة سياسة الصورة وفقًا لـ systemd.image-policy(7) لاستخدامها عند وصل صور الأقراص (DDI) المحددة في RootImage= و MountImage= و ExtensionImage= على التوالي. إذا لم تُحدد، فإن سلسلة السياسة التالية هي المبدئية لـ RootImagePolicy= و MountImagePolicy:

root=verity+signed+encrypted+unprotected+absent: \


        usr=verity+signed+encrypted+unprotected+absent: \


        home=encrypted+unprotected+absent: \


        srv=encrypted+unprotected+absent: \


        tmp=encrypted+unprotected+absent: \


        var=encrypted+unprotected+absent

السياسة المبدئية لـ ExtensionImagePolicy= هي:

root=verity+signed+encrypted+unprotected+absent: \


        usr=verity+signed+encrypted+unprotected+absent

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

MountAPIVFS=

يأخذ معاملًا منطقيًا. في حال تشغيله، تُنشأ مساحة اسم وصل خاصة لعمليات الوحدة وتُوصل أنظمة ملفات واجهة برمجة التطبيقات /proc/ و /sys/ و /dev/ و /run/ (كـ "tmpfs" فارغ) بداخلها، ما لم تكن موصلة بالفعل. لاحظ أن هذا الخيار ليس له تأثير ما لم يُستخدم بالاقتران مع RootDirectory=/RootImage= لأن عمليات الوصل الأربعة هذه تُوصل عمومًا في المضيف على أي حال، وما لم يتغير دليل الجذر، فستكون مساحة اسم الوصل الخاصة نسخة 1:1 من المضيف، وتتضمن عمليات الوصل الأربعة هذه. لاحظ أن نظام ملفات /dev/ للمضيف يُوصل ربطًا إذا استُخدم هذا الخيار بدون PrivateDevices=. لتشغيل الخدمة مع نسخة خاصة وبسيطة من /dev/، اجمع بين هذا الخيار و PrivateDevices=.

من أجل السماح بنشر عمليات الوصل في وقت التشغيل بطريقة آمنة، سيُستخدم ‎/run/systemd/propagate/‎ على المضيف لإعداد عمليات وصل جديدة، وسيُستخدم ‎/run/host/incoming/‎ في مساحة الاسم الخاصة كخطوة وسيطة لتخزينها قبل نقلها إلى نقطة الوصل النهائية.

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

BindLogSockets=

يأخذ معاملًا منطقيًا. إذا كان صحيحًا، فستُوصل المقابس من systemd-journald.socket(8) ربطًا في مساحة اسم الوصل. هذا مفيد بشكل خاص عند استخدام نموذج مختلف من /run/، للتأكد من أن العمليات التي تعمل في مساحة الاسم لا تزال قادرة على استخدام sd-journal(3).

هذا الخيار مفهوم ضمنيًا عند استخدام LogNamespace=، أو عندما يكون MountAPIVFS=yes، أو عند استخدام PrivateDevices=yes بالاقتران مع RootDirectory= أو RootImage=.

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

ProtectProc=

تأخذ إحدى القيم "noaccess" أو "invisible" أو "ptraceable" أو "default" (وهي القيمة المبدئية). عند الضبط، يتحكم هذا في خيار وصل "hidepid=" الخاص بمثيل "procfs" للوحدة التي تتحكم في أي من الأدلة التي تحتوي على معلومات وصفية عن العملية (/proc/PID) تكون مرئية وقابلة للوصول: عند الضبط على "noaccess" تُسحب القدرة على الوصول إلى معظم بيانات التعريف الخاصة بعمليات المستخدمين الآخرين في /proc/ لعمليات الخدمة. عند الضبط على "invisible" تُخفى العمليات المملوكة لمستخدمين آخرين من /proc/. إذا كانت "ptraceable" تُخفى جميع العمليات التي لا يمكن ptrace()'ها بواسطة عملية ما عنها. إذا كانت "default" لا يُوضع قيود على الوصول إلى /proc/ أو رؤيته. لمزيد من التفاصيل انظر نظام ملفات /proc[2]. يُوصى عادة بتشغيل معظم خدمات النظام مع ضبط هذا الخيار على "invisible". يُنفذ هذا الخيار عبر مساحة أسماء نظام الملفات، وبالتالي لا يمكن استخدامه مع الخدمات التي يجب أن تكون قادرة على تثبيت نقاط وصل في تسلسل نظام ملفات المضيف. لاحظ أن مستخدم الجذر (root) غير متأثر بهذا الخيار، لذا لكي يكون فعالًا يجب استخدامه جنبًا إلى جنب مع User= أو DynamicUser=yes، وأيضًا بدون صلاحية "CAP_SYS_PTRACE"، والتي تسمح أيضًا للعملية بتجاوز هذه الميزة. لا يمكن استخدامه للخدمات التي تحتاج إلى الوصول إلى معلومات وصفية حول عمليات المستخدمين الآخرين. هذا الخيار يتضمن MountAPIVFS=.

إذا كانت النواة لا تدعم خيارات الوصل hidepid= لكل نقطة وصل، فإن هذا الإعداد يظل بدون تأثير، وستكون عمليات الوحدة قادرة على الوصول إلى العمليات الأخرى ورؤيتها كما لو لم يُستخدم الخيار.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

ProcSubset=

تأخذ إحدى القيم "all" (المبدئية) و "pid". إذا كانت "pid"، فستُجعل جميع الملفات والأدلة غير المرتبطة مباشرة بإدارة العمليات والاستبطان غير مرئية في نظام ملفات /proc/ المكون لعمليات الوحدة. هذا يتحكم في خيار وصل "subset=" الخاص بمثيل "procfs" للوحدة. لمزيد من التفاصيل انظر نظام ملفات /proc[2]. لاحظ أن لينكس يعرض واجهات برمجة تطبيقات مختلفة للنواة عبر /proc/، والتي تصبح غير متاحة مع هذا الإعداد. نظرًا لأن واجهات برمجة التطبيقات هذه تُستخدم بشكل متكرر، فإن هذا الخيار مفيد فقط في حالات قليلة ومحددة، وغير مناسب لمعظم البرامج غير البسيطة.

تمامًا مثل ProtectProc= أعلاه، يُنفّذ هذا عبر مساحات أسماء وصل نظام الملفات، وبالتالي تنطبق نفس القيود: فهو متاح فقط لخدمات النظام، ويعطل نشر الوصل إلى جدول وصل المضيف، ويتضمن ضمنيًا MountAPIVFS=. أيضًا، مثل ProtectProc=، يُعطل هذا الإعداد بلطف إذا كانت النواة المستخدمة لا تدعم خيار الوصل "subset=" لـ "procfs".

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

BindPaths=, BindReadOnlyPaths=

يضبط وصلات الربط الخاصة بالوحدة. تجعل وصلة الربط ملفًا أو دليلًا معينًا متاحًا في مكان إضافي في عرض الوحدة لنظام الملفات. أي وصلات ربط تُنشئ بهذا الخيار تكون خاصة بالوحدة، وغير مرئية في جدول وصلات المضيف. يتوقع هذا الخيار قائمة مفصولة بالمسافات لتعريفات وصلات الربط. يتكون كل تعريف من ثلاثية مفصولة بنقطتين: مسار المصدر، مسار الوجهة، وسلسلة الخيارات، حيث الأخيرتان اختياريتان. إذا حُدد مسار المصدر فقط، يُفترض أن المصدر والوجهة هما نفس المسار. يمكن أن تكون سلسلة الخيارات إما "rbind" أو "norbind" لضبط وصلة ربط متكررة أو غير متكررة. إذا حُذفت مسار الوجهة، فيجب حذف سلسلة الخيارات أيضًا. يمكن أن تُسبق كل تعريف وصلة ربط بـ "-"، وفي هذه الحالة ستُتجاهل عندما لا يكون مسار مصدرها موجودًا.

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

يقتضي استخدام هذا الخيار تخصيص مساحة اسم وصل للوحدة، أي أنه يقتضي تأثير PrivateMounts= (انظر أدناه).

هذا الخيار مفيد بشكل خاص عند استخدام RootDirectory=/RootImage=. في هذه الحالة، يشير مسار المصدر إلى مسار على نظام ملفات المضيف، بينما يشير مسار الوجهة إلى مسار أسفل الدليل الجذر للوحدة.

لاحظ أن دليل الوجهة يجب أن يكون موجودًا أو يجب أن يكون systemd قادرًا على إنشائه. وبالتالي، لا يمكن استخدام هذه الخيارات لنقاط الوصل المتداخلة أسفل المسارات المحددة في InaccessiblePaths=، أو أسفل /home/ والأدلة المحمية الأخرى إذا حُدد ProtectHome=yes. وينبغي استخدام TemporaryFileSystem= مع ":ro" أو ProtectHome=tmpfs بدلاً من ذلك.

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

MountImages=

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

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

قد يُسبق كل تعريف وصل بـ "-"، وفي هذه الحالة سيُتجاهل عندما يكون مسار مصدره غير موجود. المعامل المصدر هو مسار لعقدة جهاز كتلي أو ملف عادي. إذا كان المصدر أو الوجهة يحتويان على ":"، فيجب هروبه كـ "\:". يجب أن تتبع عقدة الجهاز أو ملف صورة نظام الملفات نفس القواعد المحددة لـ RootImage=. أي عمليات وصل تُنشأ بهذا الخيار تكون خاصة بالوحدة، وغير مرئية في جدول وصل المضيف.

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

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

ExtensionImages=

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

سيُعد OverlayFS للقراءة فقط فوق هرميات /usr/ و /opt/ لصور sysext وهرمية /etc/ لصور confext. سيحدد الترتيب الذي تُدرج به الصور الترتيب الذي يوضع به التراكب: ستؤدي الصور المحددة من الأولى إلى الأخيرة إلى طبقات overlayfs من الأسفل إلى الأعلى.

قد يُسبق كل تعريف وصل بـ "-"، وفي هذه الحالة سيُتجاهل عندما يكون مسار مصدره غير موجود. المعامل المصدر هو مسار لعقدة جهاز كتلي أو ملف عادي. إذا كان مسار المصدر يحتوي على ":"، فيجب هروبه كـ "\:". يجب أن تتبع عقدة الجهاز أو ملف صورة نظام الملفات نفس القواعد المحددة لـ RootImage=. أي عمليات وصل تُنشأ بهذا الخيار تكون خاصة بالوحدة، وغير مرئية في جدول وصل المضيف.

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

يجب أن تحمل كل صورة sysext ملفًا /usr/lib/extension-release.d/extension-release.IMAGE بينما يجب أن تحمل كل صورة confext ملفًا /etc/extension-release.d/extension-release.IMAGE، مع البيانات الواصفة المناسبة التي تطابق RootImage=/RootDirectory= أو المضيف. انظر: os-release(5). لتعطيل فحص السلامة الذي يضمن مطابقة اسم ملف extension-release لاسم ملف الصورة، يمكن إلحاق خيار الوصل x-systemd.relax-extension-release-check.

بدلاً من مسار الصورة، يمكن تحديد دليل بنسخة ".v/"، راجع systemd.v(7) للمزيد من التفاصيل.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

ExtensionDirectories=

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

سيعَد نظام ملفات تراكبي (OverlayFS) للقراءة فقط فوق هرميات /usr/ و /opt/ لصور sysext وهرمية /etc/ لصور confext. يحدد الترتيب الذي تُسرد به الأدلة الترتيب الذي توضع به الطبقات التراكبية: الأدلة المحددة من الأول إلى الآخر سينتج عنها طبقات overlayfs من الأسفل إلى الأعلى.

كل دليل مسرود في ExtensionDirectories= يمكن أن يسبق بعلامة "-"، وفي هذه الحالة سيُتجاهل عندما لا يكون مساره المصدري موجودًا. أي عمليات وصل تُنشأ بهذا الخيار تكون مقتصرة على الوحدة، ولا تظهر في جدول الوصل الخاص بالمضيف.

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

يجب أن يحتوي كل دليل sysext على ملف /usr/lib/extension-release.d/extension-release.IMAGE بينما يجب أن يحمل كل دليل confext ملف /etc/extension-release.d/extension-release.IMAGE، مع البيانات الميتا المناسبة التي تطابق RootImage=/RootDirectory= أو المضيف. انظر: os-release(5).

لاحظ أن الاستخدام من وحدات المستخدم يتطلب دعم overlayfs في مساحات أسماء المستخدمين غير الممتدة الصلاحيات، وهو ما قُدّم لأول مرة في النواة v5.11.

بدلاً من مسار الدليل، يُمكن تحديد دليل ذي إصدار ".v/"، راجع systemd.v(7) للتفاصيل.

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

هوية المستخدم/المجموعة¶

هذه الخيارات متاحة فقط لخدمات النظام وغير مدعومة للخدمات التي تعمل في حالات مدير الخدمات الخاصة بكل مستخدم.

User=, Group=

اضبط مستخدم أو مجموعة UNIX التي تُنفذ العمليات باسمها، على التوالي. يقبل اسم مستخدم أو مجموعة واحد، أو معرّفًا رقميًا كمعامل. بالنسبة لخدمات النظام (الخدمات التي يديرها مدير خدمات النظام، أي التي يديرها PID 1) ولخدمات المستخدم الخاصة بالمستخدم الجذر (الخدمات التي تديرها حالة root من systemd --user)، فإن القيمة المبدئية هي "root"، ولكن يمكن استخدام User= لتحديد مستخدم مختلف. بالنسبة لخدمات المستخدم لأي مستخدم آخر، لا يُسمح بتبديل هوية المستخدم، وبالتالي فإن الإعداد الصالح الوحيد هو نفس المستخدم الذي يعمل مدير خدمات المستخدم باسمه. إذا لم تُضبط أي مجموعة، تُستخدم المجموعة المبدئية للمستخدم. لا يؤثر هذا الإعداد على الأوامر المسبوقة بسطر أوامر يحمل علامة "+".

لاحظ أن هذا يفرض قيودًا ضعيفة فقط على صيغة اسم المستخدم/المجموعة، ولكنه سيولد تحذيرات في حالات كثيرة حيث لا تلتزم أسماء المستخدمين/المجموعات بالقواعد التالية: يجب أن يتكون الاسم المحدد فقط من الحروف a-z و A-Z و 0-9 و "_" و "-"، باستثناء الحرف الأول الذي يجب أن يكون واحدًا من a-z أو A-Z أو "_" (أي أن الأرقام و "-" غير مسموح بها كحرف أول). يجب أن يحتوي اسم المستخدم/المجموعة على حرف واحد على الأقل، وبحد أقصى 31. وُضعت هذه القيود لتجنب الغموض ولضمان بقاء أسماء المستخدمين/المجموعات وملفات الوحدات قابلة للنقل بين أنظمة لينكس. لمزيد من التفاصيل حول الأسماء المقبولة والأسماء المحذر عنها انظر صيغة اسم المستخدم/المجموعة[3].

عند استخدامه بالاقتران مع DynamicUser=، يُخصّص اسم المستخدم/المجموعة المحدد آليًا وديناميكيًا في الوقت الذي تبدأ فيه الخدمة، ويُحرّر في الوقت الذي تتوقف فيه الخدمة — ما لم يكن مخصصًا بشكل ساكن بالفعل (انظر أدناه). إذا لم يُستخدم DynamicUser=، فيجب أن يكون المستخدم والمجموعة المحددان قد أُنشئا بشكل ساكن في قاعدة بيانات المستخدمين في موعد لا يتجاوز لحظة بدء الخدمة، على سبيل المثال باستخدام أداة sysusers.d(5)، والتي تُطبّق عند الإقلاع أو وقت تثبيت الحزمة. إذا لم يكن المستخدم موجودًا بحلول ذلك الوقت، فستفشل عملية استدعاء البرنامج.

إذا أُعمل إعداد User=، فتُهيّأ قائمة المجموعات الإضافية من قائمة المجموعات المبدئية للمستخدم المحدد، كما هي معرفة في قاعدة بيانات المستخدمين والمجموعات الخاصة بالنظام. يمكن ضبط مجموعات إضافية من خلال إعداد SupplementaryGroups= (انظر أدناه).

DynamicUser=

تأخذ معيارًا منطقيًا. إذا ضُبط، يُخصص زوج مستخدم ومجموعة UNIX آليًا عند بدء الوحدة، ويُحرر بمجرد إيقافها. لن يُضاف المستخدم والمجموعة إلى /etc/passwd أو /etc/group، ولكن تُدار بشكل عابر أثناء وقت التشغيل. يوفر ملحق nss-systemd(8) NSS لـ glibc تكامل هؤلاء المستخدمين/المجموعات الديناميكية في قواعد بيانات مستخدمي ومجموعات النظام. يمكن ضبط اسم المستخدم والمجموعة للاستخدام عبر User= و Group= (انظر أعلاه). إذا لم تُستخدم هذه الخيارات ومُكن تخصيص المستخدم/المجموعة الديناميكي لوحدة ما، فسيُشتق اسم المستخدم/المجموعة الديناميكي آليًا من اسم الوحدة. إذا كان اسم الوحدة بدون لاحقة النوع مؤهلًا كاسم مستخدم صالح، فسيُستخدم مباشرة، وإلا فسيُستخدم اسم يتضمن تجزئة (hash) له. إذا كان هناك بالفعل مستخدم أو مجموعة مخصصة ساكنًا بالاسم المكون، فسيُستخدم ولا يُخصص مستخدم/مجموعة ديناميكي. لاحظ أنه إذا حُدد User= وكان هناك مجموعة ساكنة بالاسم موجودة، فمن المطلوب أن يكون المستخدم الساكن بالاسم موجودًا بالفعل. وبالمثل، إذا حُدد Group= وكان هناك مستخدم ساكن بالاسم موجود، فمن المطلوب أن تكون المجموعة الساكنة بالاسم موجودة بالفعل. يُخصص المستخدمين/المجموعات الديناميكية من نطاق UID/GID 61184...65519. يُوصى بتجنب هذا النطاق لمستخدمي النظام العاديين أو مستخدمي تسجيل الدخول. في أي وقت، يتم تعيين كل UID/GID من هذا النطاق لصفر أو واحد من المستخدمين/المجموعات الديناميكية قيد الاستخدام. ومع ذلك، يُعاد تدوير UID/GID بعد إنهاء الوحدة. يجب توخي الحذر لضمان عدم ترك أي عمليات تعمل كجزء من وحدة يُمكن مستخدمين/مجموعات ديناميكية لها ملفات أو أدلة مملوكة لهؤلاء المستخدمين/المجموعات، حيث قد تحصل وحدة أخرى لاحقًا على نفس UID/GID، وبالتالي تكتسب حق الوصول إلى هذه الملفات أو الأدلة. إذا مُكّن DynamicUser=، فسيُضمن RemoveIPC= (ولا يمكن إيقافه). يضمن هذا أن عمر كائنات IPC والملفات المؤقتة التي أنشأتها العمليات المنفذة مقيد بوقت تشغيل الخدمة، وبالتالي بعمر المستخدم/المجموعة الديناميكي. نظرًا لأن /tmp/ و /var/tmp/ هما عادة الأدلة الوحيدة القابلة للكتابة عالميًا على النظام، ما لم يُضبط PrivateTmp= يدويًا على "true"، فسيُضمن "disconnected". يضمن هذا أن الوحدة التي تستخدم تخصيص المستخدم/المجموعة الديناميكي لا يمكنها ترك ملفات بعد إنهاء الوحدة. علاوة على ذلك، يمُكّن NoNewPrivileges= و RestrictSUIDSGID= آليًا (ولا يمكن تعطيلهما)، لضمان أن العمليات المُستدعاة لا يمكنها الاستفادة من أو إنشاء ملفات أو أدلة SUID/SGID. بالإضافة إلى ذلك، يُضمن ProtectSystem=strict و ProtectHome=read-only، مما يمنع الخدمة من الكتابة إلى مواقع نظام ملفات عشوائية. للسماح للخدمة بالكتابة إلى أدلة معينة، يجب إدراجها في قائمة السماح باستخدام ReadWritePaths=، ولكن يجب توخي الحذر حتى لا تؤدي إعادة تدوير UID/GID إلى خلق مشكلات أمنية تتعلق بالملفات التي أنشأتها الخدمة. استخدم RuntimeDirectory= (انظر أدناه) لتخصيص دليل وقت تشغيل قابل للكتابة للخدمة، مملوك للمستخدم/المجموعة الديناميكي ويُزال آليًا عند إنهاء الوحدة. استخدم StateDirectory= و CacheDirectory= و LogsDirectory= لتخصيص مجموعة من الأدلة القابلة للكتابة لأغراض معينة للخدمة بطريقة تحميها من الثغرات الأمنية بسبب إعادة استخدام UID (انظر أدناه). إذا مُكّن هذا الخيار، فيجب توخي الحذر لضمان عدم حصول عمليات الوحدة على حق الوصول إلى أدلة خارج تلك المكونة والمُدارة صراحةً. وتحديدًا، لا تستخدم BindPaths= وتوخَّ الحذر مع تمرير واصف ملف AF_UNIX لواصفات ملفات الأدلة، حيث سيسمح هذا للعمليات بإنشاء ملفات أو أدلة مملوكة للمستخدم/المجموعة الديناميكي غير خاضعة لدورة حياة وضمانات الوصول الخاصة بالخدمة. لاحظ أن هذا الخيار غير متوافق حاليًا مع سياسات D-Bus، لذا قد لا تخصص خدمة تستخدم هذا الخيار حاليًا اسم خدمة D-Bus (لاحظ أن هذا لا يؤثر على الاستدعاء إلى خدمات D-Bus الأخرى). المبدئي هو إيقاف.

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

SupplementaryGroups=

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

SetLoginEnvironment=

يقبل معاملًا منطقيًا يتحكم في ما إذا كان ستُضبط متغيرات البيئة $HOME و $LOGNAME و $SHELL. إذا لم يُضبط، فإن القيمة المبدئية تكون صائبة (true) إذا ضُبط User= أو DynamicUser= أو PAMName=، وتكون خاطئة (false) في غير ذلك. إذا ضُبط على true، فستُضبط المتغيرات دائمًا لخدمات النظام، أي حتى عند استخدام المستخدم المبدئي "root". إذا ضُبط على false، فإن المتغيرات المذكورة لا تُضبط من قِبل مدير الخدمات، بغض النظر عما إذا كان User= أو DynamicUser= أو PAMName= مستخدمًا أم لا. لا يكون لهذا الخيار عادة أي تأثير على خدمات مدير خدمات المستخدم، نظرًا لأن هذه المتغيرات في هذه الحالة تُورث عادة من البيئة الخاصة بمدير المستخدم نفسه على أي حال.

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

PAMName=

يضبط اسم خدمة PAM لإعداد جلسة باسمها. إذا ضُبط، فستُسجّل العملية المنفذة كجلسة PAM تحت اسم الخدمة المحدد. هذا مفيد فقط بالاقتران مع إعداد User=، ويُتجاهل في غير ذلك. إذا لم يُضبط، فلن تُفتح أي جلسة PAM للعمليات المنفذة. انظر pam(8) للتفاصيل.

لاحظ أنه لكل وحدة تستخدم هذا الخيار، ستُصان عملية معالج جلسة PAM كجزء من الوحدة وتظل موجودة طالما أن الوحدة نشطة، لضمان إمكانية اتخاذ الإجراءات المناسبة عند إنهاء الوحدة وبالتالي إنهاء جلسة PAM. تُسمى هذه العملية "(sd-pam)" وهي عملية ابن مباشرة للعملية الرئيسة للوحدة.

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

القدرات¶

هذه الخيارات متاحة فقط لخدمات النظام، أو للخدمات التي تعمل في حالات مدير الخدمات الخاصة بكل مستخدم وفي هذه الحالة يُفعّل PrivateUsers= ضمنيًا (يتطلب تفعيل دعم مساحات أسماء المستخدمين غير الممتدة الصلاحيات في النواة عبر sysctl "kernel.unprivileged_userns_clone=").

CapabilityBoundingSet=

يتحكم في القدرات (capabilities) التي يجب تضمينها في مجموعة حدود القدرات للعملية المنفذة. انظر capabilities(7) للتفاصيل. يقبل قائمة مفصولة بمسافات من أسماء القدرات، مثل CAP_SYS_ADMIN و CAP_DAC_OVERRIDE و CAP_SYS_PTRACE. القدرات المسرودة ستُضمّن في مجموعة الحدود، وتُزال جميع القدرات الأخرى. إذا كانت قائمة القدرات مسبوقة بعلامة "~", فستُضمّن جميع القدرات باستثناء المسرودة، ويُعكس تأثير التعيين. لاحظ أن هذا الخيار يؤثر أيضًا على القدرات المعنية في مجموعات القدرات الفعالة والمسموح بها والموروثة. إذا لم يُستخدم هذا الخيار، فلا تُعدّل مجموعة حدود القدرات عند تنفيذ العملية، وبالتالي لا تُفرض أي قيود على قدرات العملية. قد يظهر هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج مجموعات الحدود بواسطة البوابة المنطقية OR، أو بواسطة AND إذا كانت السطور مسبوقة بعلامة "~" (انظر أدناه). إذا عُيّنت سلسلة نصية فارغة لهذا الخيار، فستُصفّر مجموعة الحدود إلى مجموعة قدرات فارغة، ولن يكون لجميع الإعدادات السابقة أي تأثير. وإذا ضُبط على "~" (بدون أي معامل إضافي)، فستُصفّر مجموعة الحدود إلى المجموعة الكاملة من القدرات المتاحة، مع إلغاء أي إعدادات سابقة أيضًا. لا يؤثر هذا على الأوامر المسبوقة بعلامة "+".

استخدم أمر capability التابع لـ systemd-analyze(1) لاسترداد قائمة بالقدرات المعرفة على النظام المحلي.

مثال: إذا كانت الوحدة تحتوي على ما يلي،

CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=CAP_B CAP_C

فعندئذٍ تُضبط CAP_A و CAP_B و CAP_C. إذا كانت السطر الثاني مسبوقًا بعلامة "~"، على سبيل المثال:

CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=~CAP_B CAP_C

فعندئذٍ، تُضبط CAP_A فقط.

AmbientCapabilities=

يتحكم في القدرات التي يجب تضمينها في مجموعة القدرات المحيطة (ambient) للعملية المنفذة. يقبل قائمة مفصولة بمسافات من أسماء القدرات، مثل CAP_SYS_ADMIN و CAP_DAC_OVERRIDE و CAP_SYS_PTRACE. قد يظهر هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج مجموعات القدرات المحيطة (انظر الأمثلة أعلاه في CapabilityBoundingSet=). إذا كانت قائمة القدرات مسبوقة بعلامة "~", فستُضمّن جميع القدرات باستثناء المسرودة، ويُعكس تأثير التعيين. إذا عُيّنت سلسلة نصية فارغة لهذا الخيار، فستُصفّر مجموعة القدرات المحيطة إلى مجموعة قدرات فارغة، ولن يكون لجميع الإعدادات السابقة أي تأثير. وإذا ضُبط على "~" (بدون أي معامل إضافي)، فستُصفّر مجموعة القدرات المحيطة إلى المجموعة الكاملة من القدرات المتاحة، مع إلغاء أي إعدادات سابقة أيضًا. لاحظ أن إضافة القدرات إلى مجموعة القدرات المحيطة يضيفها إلى مجموعة القدرات الموروثة للعملية.

مجموعات الصلاحيات المحيطة مفيدة إذا كنت تريد تنفيذ عملية كمستخدم غير ذي صلاحيات ولكنك لا تزال ترغب في منحه بعض الصلاحيات. لاحظ أنه في هذه الحالة يُضاف خيار keep-caps آليًا إلى SecureBits= للاحتفاظ بالصلاحيات بعد تغيير المستخدم. AmbientCapabilities= لا تؤثر على الأوامر المسبوقة بـ "+".

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

الأمن¶

NoNewPrivileges=

تأخذ وسيطًا منطقيًا. إذا كانت true، تضمن أن عملية الخدمة وجميع أبنائها لا يمكنهم أبدًا اكتساب صلاحيات جديدة عبر execve() (مثلًا عبر بتات setuid أو setgid، أو صلاحيات نظام الملفات). هذه هي الطريقة الأبسط والأكثر فعالية لضمان أن العملية وأبناءها لا يمكنهم أبدًا رفع الصلاحيات مرة أخرى. المبدئي هو false. في حالة تشغيل الخدمة في مساحة أسماء وصل جديدة على أي حال وكان SELinux معطلًا، تُوصل جميع أنظمة الملفات بعلامة MS_NOSUID. انظر أيضًا علامة لا صلاحيات جديدة[4].

لاحظ أن هذا الإعداد له تأثير فقط على عمليات الوحدة نفسها (أو أي عمليات تفرعت عنها بشكل مباشر أو غير مباشر). وليس له أي تأثير على العمليات التي قد تُستدعى بناءً على طلب منها من خلال أدوات مثل at(1) أو crontab(1) أو systemd-run(1) أو خدمات IPC العشوائية.

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

SecureBits=

يتحكم في البتات الآمنة (secure bits) المضبوطة للعملية المنفذة. يقبل مزيجًا مفصولاً بمسافات من الخيارات من القائمة التالية: keep-caps و keep-caps-locked و no-setuid-fixup و no-setuid-fixup-locked و noroot و noroot-locked. قد يظهر هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج البتات الآمنة بواسطة البوابة المنطقية OR. إذا عُيّنت سلسلة نصية فارغة لهذا الخيار، فستُصفّر البتات إلى 0. لا يؤثر هذا على الأوامر المسبوقة بعلامة "+". انظر capabilities(7) للتفاصيل.

التحكم الإلزامي في الوصول¶

SELinuxContext=

اضبط سياق أمان SELinux للعملية المنفذة. إذا ضُبط، فسيتجاوز هذا انتقال النطاق الآلي. ومع ذلك، لا تزال السياسة بحاجة إلى ترخيص هذا الانتقال. يُتجاهل هذا التوجيه إذا كان SELinux معطلاً. وإذا سُبق بعلامة "-"، فسيُتجاهل الفشل في ضبط سياق أمان SELinux، ولكن لا يزال من الممكن أن تفشل عملية execve() اللاحقة إذا كانت السياسة لا تسمح بالانتقال للسياق غير المتجاوَز. لا يؤثر هذا على الأوامر المسبوقة بعلامة "+". انظر setexeccon(3) للتفاصيل.

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

AppArmorProfile=

يقبل اسم تشكيلة كمعامل. ستنتقل العملية المنفذة بواسطة الوحدة إلى هذه التشكيلة عند بدئها. يجب أن تكون التشكيلات محملة بالفعل في النواة، وإلا فستفشل الوحدة. إذا سُبقت بعلامة "-"، فستُتجاهل جميع الأخطاء. ليس لهذا الإعداد أي تأثير إذا كان AppArmor غير مفعّل. لا يؤثر هذا الإعداد على الأوامر المسبوقة بعلامة "+".

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

SmackProcessLabel=

يقبل وسم أمان SMACK64 كمعامل. ستبدأ العملية المنفذة بواسطة الوحدة تحت هذا الوسم وسيقرر SMACK ما إذا كان يُسمح للعملية بالعمل أم لا بناءً عليه. ستستمر العملية في العمل تحت الوسم المحدد هنا ما لم يكن للملف التنفيذي وسم SMACK64EXEC الخاص به، وفي هذه الحالة ستنتقل العملية للعمل تحت ذلك الوسم. عند عدم تحديده، يُستخدم الوسم الذي يعمل تحته نظام systemd. يُتجاهل هذا التوجيه إذا كان SMACK معطلاً.

يمكن أن تُسبق القيمة بعلامة "-"، وفي هذه الحالة فستُتجاهل جميع الأخطاء. يمكن تحديد قيمة فارغة لإلغاء التعيينات السابقة. لا يؤثر هذا على الأوامر المسبوقة بعلامة "+".

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

خصائص العملية¶

LimitCPU=، LimitFSIZE=، LimitDATA=، LimitSTACK=، LimitCORE=، LimitRSS=، LimitNOFILE=، LimitAS=، LimitNPROC=، LimitMEMLOCK=، LimitLOCKS=، LimitSIGPENDING=، LimitMSGQUEUE=، LimitNICE=، LimitRTPRIO=، LimitRTTIME=

اضبط الحدود المرنة (soft) والصارمة (hard) على الموارد المختلفة للعمليات المنفذة. انظر setrlimit(2) للتفاصيل حول مفهوم حد موارد العملية. يمكن تحديد حدود موارد العملية بصيغتين: إما كقيمة مفردة لضبط حد مرن وصارم محدد على نفس القيمة، أو كزوج مفصول بنقطتين رأسيّتين soft:hard لضبط كلا الحدين بشكل فردي (على سبيل المثال "LimitAS=4G:16G"). استخدم السلسلة النصية infinity لتهيئة عدم وجود حد على مورد معين. يمكن استخدام اللاحقات المضاعفة K و M و G و T و P و E (بالأساس 1024) لحدود الموارد المقاسة بالبايت (على سبيل المثال "LimitAS=16G"). بالنسبة للحدود التي تشير إلى قيم زمنية، يمكن استخدام وحدات الوقت المعتادة ms و s و min و h وما إلى ذلك (انظر systemd.time(7) للتفاصيل). لاحظ أنه إذا لم تُحدد وحدة زمنية لـ LimitCPU= فإن الوحدة المبدئية وهي الثواني تكون ضمنية، بينما لـ LimitRTTIME= فإن الوحدة المبدئية وهي الميكروثانية تكون ضمنية. أيضًا، لاحظ أن الحبيبية (granularity) الفعالة للحدود قد تؤثر على فرضها. على سبيل المثال، الحدود الزمنية المحددة لـ LimitCPU= ستُقرب لأعلى ضمنيًا إلى مضاعفات ثانية واحدة. بالنسبة لـ LimitNICE= يمكن تحديد القيمة بصيغتين: إذا كانت مسبوقة بعلامة "+" أو "-"، فستُفهم القيمة على أنها قيمة nice عادية لنظام Linux في النطاق -20...19. وإذا لم تكن مسبوقة على هذا النحو، فستُفهم القيمة كمعامل حد موارد خام في النطاق 0...40 (حيث يعادل 0 القيمة 1).

لاحظ أن معظم حدود موارد العملية المهيأة بهذه الخيارات تكون لكل عملية (per-process)، ويمكن للعمليات أن تتفرع (fork) للحصول على مجموعة جديدة من الموارد التي تُحتسب بشكل مستقل عن العملية الأصلية، وبالتالي قد تفلت من الحدود المضبوطة. لاحظ أيضًا أن LimitRSS= غير مدعوم في Linux، وضبطه ليس له أي تأثير. يُنصح غالبًا بتفضيل عناصر التحكم في الموارد المسرودة في systemd.resource-control(5) على هذه الحدود التي تكون لكل عملية، لأنها تنطبق على الخدمات ككل، ويمكن تعديلها ديناميكيًا في وقت التشغيل، وهي أكثر تعبيرًا بشكل عام. على سبيل المثال، يُعد MemoryMax= بديلًا أكثر قوة (ويعمل فعليًا) لـ LimitRSS=.

لاحظ أن LimitNPROC= سيحدد عدد العمليات التابعة لمعرّف مستخدم (حقيقي) واحد (UID) وليس عدد العمليات التي بدأتها (أو فرعتها) الخدمة. لذلك فإن الحد تراكمي لجميع العمليات التي تعمل تحت نفس الـ UID. يُرجى أيضًا ملاحظة أن LimitNPROC= لن يُفرض إذا كانت الخدمة تعمل كجزء من حساب root (ولم تتخلَ عن الامتيازات). نظرًا لهذه القيود، فإن خيار TasksMax= (انظر systemd.resource-control(5)) هو عادة خيار أفضل من LimitNPROC=.

تؤول حدود الموارد غير المهيأة صراحةً لوحدة ما مبدئيًا إلى القيمة المهيأة في الخيارات المتنوعة لـ DefaultLimitCPU= و DefaultLimitFSIZE= و ... المتاحة في systemd-system.conf(5)، و—إذا لم تُهيأ هناك—تؤول إلى القيم المبدئية للنواة أو لكل مستخدم، كما هو معرف من قِبل نظام التشغيل (الأخير فقط لخدمات المستخدم، انظر أدناه).

بالنسبة لوحدات النظام، يمكن اختيار حدود الموارد هذه بحرية. عند تهيئة هذه الإعدادات في خدمة مستخدم (أي خدمة تُشغل بواسطة حالة مدير الخدمات الخاصة بكل مستخدم) لا يمكن استخدامها لرفع الحدود أعلى من تلك المضبوطة لمدير المستخدم نفسه عند استدعائه لأول مرة، حيث يفتقر مدير خدمات المستخدم عمومًا إلى الامتيازات اللازمة للقيام بذلك. في سياق المستخدم، تكون خيارات التهيئة هذه مفيدة فقط لخفض الحدود الممررة أو لرفع الحد المرن إلى الحد الأقصى للحد الصارم كما هو مهيأ للمستخدم. لرفع حدود المستخدم بشكل أكبر، تختلف آليات التهيئة المتاحة بين أنظمة التشغيل، ولكنها تتطلب عادةً امتيازات. في معظم الحالات، يمكن تهيئة حدود موارد أعلى لكل مستخدم عبر PAM أو عن طريق ضبط الحدود على خدمة النظام التي تغلف مدير خدمات المستخدم، أي حالة المستعمل من user@.service. بعد إجراء هذه التغييرات، تأكد من إعادة تشغيل مدير خدمات المستخدم.

جدول 1. توجيهات حد الموارد، وما يعادلها من أوامر صدفة ulimit والوحدة المستخدمة

التوجيه	ما يعادل ulimit	الوحدة	ملاحظات
LimitCPU=	ulimit -t	ثوانٍ	-
LimitFSIZE=	ulimit -f	بايتات	-
LimitDATA=	ulimit -d	بايتات	لا تستخدمه. هذا يحدد نطاق العناوين المسموح به، وليس استخدام الذاكرة! القيمة المبدئية هي غير محدود ويجب عدم خفضها. للحد من استخدام الذاكرة، انظر MemoryMax= في systemd.resource-control(5).
LimitSTACK=	ulimit -s	بايتات	-
LimitCORE=	ulimit -c	بايتات	-
LimitRSS=	ulimit -m	بايتات	لا تستخدمه. ليس له تأثير على Linux.
LimitNOFILE=	ulimit -n	عدد واصفات الملفات	لا تستخدمه. كن حذرًا عند رفع الحد المرن فوق 1024، نظرًا لأن وظيفة select(2) لا يمكنها العمل مع واصفات ملفات أعلى من 1023 على Linux. في الوقت الحاضر، يؤول الحد الصارم مبدئيًا إلى 524288، وهي قيمة عالية جدًا مقارنة بالقيم المبدئية التاريخية. وعادةً ما ينبغي للتطبيقات زيادة حدها المرن إلى الحد الصارم من تلقاء نفسها، إذا كانت قادرة على العمل مع واصفات ملفات أعلى من 1023، أي لا تستخدم select(2). لاحظ أن واصفات الملفات تُحتسب في الوقت الحاضر مثل أي شكل آخر من أشكال الذاكرة، وبالتالي لا ينبغي أن تكون هناك أي حاجة لخفض الحد الصارم. استخدم MemoryMax= للتحكم في استخدام ذاكرة الخدمة الإجمالي، بما في ذلك ذاكرة واصفات الملفات.
LimitAS=	ulimit -v	بايتات	لا تستخدمه. هذا يحدد نطاق العناوين المسموح به، وليس استخدام الذاكرة! القيمة المبدئية هي غير محدود ويجب عدم خفضها. للحد من استخدام الذاكرة، انظر MemoryMax= في systemd.resource-control(5).
LimitNPROC=	ulimit -u	عدد العمليات	يُفرض هذا الحد بناءً على عدد العمليات التابعة للمستخدم. وعادةً ما يكون من الأفضل تتبع العمليات لكل خدمة، أي استخدام TasksMax=، انظر systemd.resource-control(5).
LimitMEMLOCK=	ulimit -l	بايتات	-
LimitLOCKS=	ulimit -x	عدد الأقفال	-
LimitSIGPENDING=	ulimit -i	عدد الإشارات في الطابور	-
LimitMSGQUEUE=	ulimit -q	بايتات	-
LimitNICE=	ulimit -e	مستوى الأولوية	-
LimitRTPRIO=	ulimit -r	أولوية الوقت الحقيقي	-
LimitRTTIME=	ulimit -R	ميكروثانية	-

UMask=

يتحكم في قناع إنشاء نمط الملف. يأخذ نمط وصول بالترميز الثماني. انظر umask(2) للتفاصيل. المبدئي هو 0022 لوحدات النظام. بالنسبة لوحدات المستخدم، تُورث القيمة المبدئية من مدير خدمة كل مستخدم (الذي يُورث مبدئيه بدوره من مدير خدمة النظام، وبالتالي عادة ما يكون أيضًا 0022 - ما لم يُتجاوز بواسطة ملحق PAM). لتغيير قناع كل مستخدم لجميع خدمات المستخدم، فكر في ضبط إعداد UMask= لمثيل خدمة نظام المستخدم user@.service. يمكن أيضًا ضبط umask لكل مستخدم عبر حقل umask الخاص بـ سجل مستخدم JSON[5] (للمستخدمين المُدارين بواسطة systemd-homed.service(8) يمكن التحكم في هذا الحقل عبر homectl --umask=). يمكن ضبطه أيضًا عبر ملحق PAM، مثل pam_umask(8).

CoredumpFilter=

يتحكم في أنواع تخطيطات الذاكرة التي ستُحفظ إذا قامت العملية بتفريغ الذاكرة القلبية (core dump) (باستخدام ملف /proc/pid/coredump_filter). يقبل مزيجًا مفصولاً بمسافات من أسماء أنواع التخطيط أو أرقامها (مع الأساس المبدئي 16). أسماء أنواع التخطيط هي private-anonymous و shared-anonymous و private-file-backed و shared-file-backed و elf-headers و private-huge و shared-huge و private-dax و shared-dax، بالإضافة إلى القيم الخاصة all (جميع الأنواع) و default (القيمة المبدئية للنواة وهي "private-anonymous shared-anonymous elf-headers private-huge"). انظر core(5) لمعنى أنواع التخطيط. عند تحديدها عدة مرات، تُدمج جميع الأقنعة المحددة بواسطة بوابة OR المنطقية. عند عدم ضبطها، أو إذا عُيّنت قيمة فارغة، فلن تُغيّر القيمة الموروثة.

مثال 2. إضافة صفحات DAX إلى مرشح التفريغ

CoredumpFilter=default private-dax shared-dax

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

KeyringMode=

يتحكم في كيفية إعداد حلقة مفاتيح جلسة النواة (kernel session keyring) للخدمة (انظر session-keyring(7) للتفاصيل حول حلقة مفاتيح الجلسة). يقبل أحد الخيارات inherit أو private أو shared. إذا ضُبط على inherit، فلن يُجرى أي إعداد خاص لحلقة المفاتيح، ويُطبّق السلوك المبدئي للنواة. وإذا استخدم private، فتُخصّص حلقة مفاتيح جلسة جديدة عند استدعاء عملية الخدمة، ولا تُربط بأي حلقة مفاتيح مستخدم. هذا هو الإعداد الموصى به لخدمات النظام، لأن هذا يضمن أن الخدمات المتعددة التي تعمل تحت نفس معرّف مستخدم النظام (خاصة المستخدم root) لا تشارك مواد المفاتيح الخاصة بها فيما بينها. وإذا استخدم shared، فتُخصّص حلقة مفاتيح جلسة جديدة كما في private، ولكن حلقة مفاتيح المستخدم للمستعمل المهيأ بـ User= تُربط بها، بحيث يمكن لعمليات الوحدة طلب المفاتيح المعينة للمستخدم. في هذا الوضع، قد تشارك وحدات متعددة تشغل عمليات تحت نفس معرّف المستخدم مواد المفاتيح. ما لم يُحدد inherit، فإن معرّف الاستدعاء الفريد للوحدة (انظر أدناه) يُضاف كمفتاح محمي باسم "invocation_id" إلى حلقة مفاتيح الجلسة التي أُنشئت حديثًا. يؤول مبدئيًا إلى private لخدمات مدير خدمات النظام وإلى inherit للوحدات التي ليست خدمات ولخدمات مدير خدمات المستخدم.

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

OOMScoreAdjust=

يضبط قيمة التعديل لنتيجة قاتل "خارج الذاكرة" (OOM) لنواة لينكس للعمليات المُنفذة. يأخذ عددًا صحيحًا بين -1000 (لتعطيل قتل OOM لعمليات هذه الوحدة) و 1000 (لجعل قتل عمليات هذه الوحدة تحت ضغط الذاكرة مرجحًا جدًا). انظر نظام ملفات /proc[6] للتفاصيل. إذا لم يحُدد، يُعين مبدئيًا على مستوى تعديل نتيجة OOM لمدير الخدمة نفسه، والذي يكون عادة عند 0.

استخدم إعداد OOMPolicy= لوحدات الخدمة لتهيئة كيفية تفاعل مدير الخدمات مع قاتل OOM للنواة أو إنهاء systemd-oomd لعملية تابعة للخدمة. انظر systemd.service(5) للتفاصيل.

TimerSlackNSec=

يضبط فترة الارتخاء المؤقت (timer slack) بالنانوثانية للعمليات المنفذة. تتحكم فترة الارتخاء المؤقت في دقة عمليات الاستيقاظ الناتجة عن المؤقتات. انظر prctl(2) لمزيد من المعلومات. لاحظ أنه على عكس معظم تعريفات الفترة الزمنية الأخرى، يقبل هذا المعامل قيمة عددية صحيحة بالنانوثانية إذا لم تُحدد وحدة زمنية. تُفهم وحدات الوقت المعتادة أيضًا.

Personality=

يتحكم في معمارية النواة التي يجب أن يبلغ عنها امر uname(2)، عندما تُستدعى بواسطة عمليات الوحدة. يقبل أحد معرفات المعمارية التالية arm64 أو arm64-be أو arm أو arm-be أو x86 أو x86-64 أو ppc أو ppc-le أو ppc64 أو ppc64-le أو s390 أو s390x. تعتمد معماريات الشخصية (personality architectures) المدعومة على المعمارية الأصلية للنواة. تدعم إصدارات 64-بت من معماريات النظام المختلفة عادةً نظيرتها المباشرة من معمارية الشخصية 32-بت، ولكن ليس غيرها. على سبيل المثال، تدعم أنظمة x86-64 شخصيات x86-64 و x86 ولكن ليس غيرها. ميزة الشخصية مفيدة عند تشغيل خدمات 32-بت على نظام مضيف 64-بت. إذا لم تُحدد، تُترك الشخصية دون تعديل وبالتالي تعكس شخصية نواة النظام المضيف. هذا الخيار ليس مفيدًا في المعماريات التي لم تتوفر لها سوى وحدة عرض كلمة أصلية واحدة فقط، مثل m68k (32-بت فقط) أو alpha (64-بت فقط).

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

IgnoreSIGPIPE=

يقبل معاملًا منطقيًا. إذا كان صائبًا (true)، تُتجاهل إشارة SIGPIPE في العملية المنفذة. يؤول مبدئيًا إلى true لأن SIGPIPE تكون مفيدة عمومًا فقط في خطوط أنابيب الصدفة (shell pipelines).

جدولة¶

Nice=

يضبط مستوى nice المبدئي (أولوية الجدولة) للعمليات المنفذة. يقبل عددًا صحيحًا بين -20 (أعلى أولوية) و19 (أقل أولوية). في حالة التنازع على الموارد، تعني القيم الأصغر إتاحة المزيد من الموارد لعمليات الوحدة، بينما تعني القيم الأكبر إتاحة موارد أقل. انظر setpriority(2) للتفاصيل.

CPUSchedulingPolicy=

يضبط سياسة جدولة المعالج للعمليات المنفَّذة. يأخذ إحدى القيم other، batch، idle، fifo أو rr. طالع sched_setscheduler(2) للمزيد من التفاصيل.

CPUSchedulingPriority=

يضبط أولوية جدولة وحدة المعالجة المركزية (CPU) للعمليات المنفذة. يعتمد نطاق الأولوية المتاح على سياسة جدولة CPU المحددة (انظر أعلاه). بالنسبة لسياسات جدولة الوقت الحقيقي، يمكن استخدام عدد صحيح بين 1 (أقل أولوية) و99 (أعلى أولوية). في حالة التنازع على موارد وحدة المعالجة المركزية، تعني القيم الأصغر إتاحة وقت أقل من المعالج للخدمة، وتعني القيم الأكبر إتاحة وقت أطول. انظر sched_setscheduler(2) للتفاصيل.

CPUSchedulingResetOnFork=

يأخذ معاملًا منطقيًا (boolean). إذا كان صحيحًا (true)، فستُصفّر أولويات وسياسات جدولة المعالج المرفوعة عندما تستدعي العمليات المنفذة fork(2)، وبالتالي لا تتسرب إلى العمليات الابنة. انظر sched_setscheduler(2) للتفاصيل. القيمة المبدئية هي خطأ (false).

CPUAffinity=

يتحكم في أُلفة المعالج (CPU affinity) للعمليات المنفذة. يأخذ قائمة بمؤشرات أو نطاقات المعالجات مفصولة إما بمسافات بيضاء أو فواصل. بدلاً من ذلك، يأخذ قيمة "numa" الخاصة وفي هذه الحالة يستنتج systemd آليًا نطاق المعالجات المسموح به بناءً على قيمة خيار NUMAMask=. تُحدد نطاقات المعالج بالمؤشرات الدنيا والعليا للمعالج مفصولة بشرطة. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج أقنعة ألفة المعالج المحددة. إذا أُسندت سلسلة نصية فارغة، فسيُصفّر القناع، ولن يكون لأي تعيينات سابقة لهذا أي مفعول. انظر sched_setaffinity(2) للتفاصيل.

NUMAPolicy=

يتحكم في سياسة ذاكرة NUMA للعمليات المنفذة. يأخذ نوع السياسة، وهي واحدة من: default و preferred و bind و interleave و local. يجب تحديد قائمة بعقد NUMA التي ينبغي أن ترتبط بالسياسة في NUMAMask=. لمزيد من التفاصيل حول كل سياسة، يرجى الاطلاع على set_mempolicy(2). للحصول على نظرة عامة شاملة لدعم NUMA في لينكس، انظر numa(7).

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

NUMAMask=

يتحكم في قائمة عقد NUMA التي ستُطبق جنبًا إلى جنب مع سياسة NUMA المحددة. يأخذ قائمة بعقد NUMA وله نفس صيغة قائمة المعالجات لخيار CPUAffinity= أو القيمة الخاصة "all" التي ستشمل جميع عقد NUMA المتاحة في القناع. لاحظ أن قائمة عقد NUMA ليست مطلوبة للسياستين default و local، وبالنسبة لسياسة preferred فإننا نتوقع عقدة NUMA واحدة.

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

IOSchedulingClass=

يضبط فئة جدولة الإدخال/الإخراج للعمليات المنفذة. يأخذ إحدى السلاسل النصية realtime أو best-effort أو idle. فئة الجدولة المبدئية للنواة هي best-effort بأولوية قدرها 4. إذا أُسندت السلسلة النصية الفارغة إلى هذا الخيار، فلن يكون لجميع التعيينات السابقة لكل من IOSchedulingClass= و IOSchedulingPriority= أي مفعول. انظر ioprio_set(2) للتفاصيل.

IOSchedulingPriority=

يضبط أولوية جدولة الإدخال/الإخراج للعمليات المنفذة. يأخذ عددًا صحيحًا بين 0 (أعلى أولوية) و 7 (أقل أولوية). في حالة تزاحم الإدخال/الإخراج، تعني القيم الأصغر إتاحة المزيد من عرض نطاق الإدخال/الإخراج لعمليات الوحدة، وتعني القيم الأكبر عرض نطاق أقل. تعتمد الأولويات المتاحة على فئة جدولة الإدخال/الإخراج المحددة (انظر أعلاه). إذا أُسندت السلسلة النصية الفارغة إلى هذا الخيار، فلن يكون لجميع التعيينات السابقة لكل من IOSchedulingClass= و IOSchedulingPriority= أي مفعول. بالنسبة لفئة الجدولة المبدئية للنواة (best-effort)، فإن هذا يؤول مبدئيًا إلى 4. انظر ioprio_set(2) للتفاصيل.

العزل¶

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

لاحظ أيضًا أن بعض وظائف عزل العمليات لا تتوفر عمومًا في خدمات المستخدم (أي الخدمات التي يديرها مدير الخدمات الخاص بكل مستخدم). وتحديدًا، فإن الإعدادات المتنوعة التي تتطلب دعم نطاقات أسماء نظام الملفات (مثل ProtectSystem=) ليست متاحة، حيث لا يمكن الوصول إلى وظائف النواة الأساسية إلا من خلال العمليات ذات الامتيازات. ومع ذلك، فإن معظم إعدادات نطاقات الأسماء، التي لن تعمل بمفردها في خدمات المستخدم، ستعمل عند استخدامها بالاقتران مع PrivateUsers=true.

لاحظ أن الخيارات المتنوعة التي تحول الدلائل إلى وضع القراءة فقط (مثل ProtectSystem= و ReadOnlyPaths= و ...) لا تؤثر على قدرة البرامج على الاتصال ومخاطبة مقابس AF_UNIX في هذه الدلائل. وبالتالي لا يمكن استخدام هذه الخيارات لقفل الوصول إلى خدمات الاتصال بين العمليات (IPC).

ProtectSystem=

يأخذ معاملًا منطقيًا أو القيم الخاصة "full" أو "strict". إذا كان صحيحًا (true)، فيُوصل /usr/ ودلائل محمل الإقلاع (/boot و /efi) بوضع القراءة فقط للعمليات التي تستدعيها هذه الوحدة. إذا ضُبط على "full"، فيُوصل الدليل /etc/ بوضع القراءة فقط أيضًا. وإذا ضُبط على "strict"، فيُوصل هيكل نظام الملفات بأكمله بوضع القراءة فقط، باستثناء أشجار نظام ملفات واجهة برمجة التطبيقات (API) الفرعية /dev/ و /proc/ و /sys/ (احمِ هذه الدلائل باستخدام PrivateDevices= و ProtectKernelTunables= و ProtectControlGroups=). يضمن هذا الإعداد حظر أي تعديل على نظام التشغيل المزود من المورد (واختياريًا تكوينه، والوصولات المحلية) على الخدمة. ويُوصى بتمكين هذا الإعداد لجميع الخدمات طويلة التشغيل، ما لم تكن مشاركة في تحديثات النظام أو تحتاج إلى تعديل نظام التشغيل بطرق أخرى. إذا استُخدم هذا الخيار، فيمكن استخدام ReadWritePaths= لاستبعاد دلائل معينة من جعلها للقراءة فقط. وبالمثل، فإن StateDirectory= و LogsDirectory= و ... وإعدادات الدلائل ذات الصلة (انظر أدناه) تستثني أيضًا دلائل معينة من تأثير ProtectSystem=. هذا الإعداد ضمني إذا ضُبط DynamicUser=. لا يمكن لهذا الإعداد ضمان الحماية في جميع الحالات. وعمومًا له نفس قيود ReadOnlyPaths=، انظر أدناه. القيمة المبدئية هي إيقاف (off).

لاحظ أنه إذا ضُبط ProtectSystem= على "strict" ومُكّن PrivateTmp=، فإن /tmp/ و /var/tmp/ ستكون قابلة للكتابة.

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

ProtectHome=

يأخذ معاملًا منطقيًا أو القيم الخاصة "read-only" أو "tmpfs". إذا كان صحيحًا، تُجعل الدلائل /home/ و /root و /run/user غير قابلة للوصول وفارغة للعمليات التي تستدعيها هذه الوحدة. وإذا ضُبط على "read-only"، تُجعل الدلائل الثلاثة للقراءة فقط بدلاً من ذلك. وإذا ضُبط على "tmpfs"، تُوصل أنظمة ملفات مؤقتة على الدلائل الثلاثة في وضع القراءة فقط. قيمة "tmpfs" مفيدة لإخفاء الدلائل المنزلية غير ذات الصلة بالعمليات التي تستدعيها الوحدة، مع السماح ببروز الدلائل الضرورية عند إدراجها في BindPaths= أو BindReadOnlyPaths=.

ضبط هذا على "yes" يعادل في الغالب ضبط الدلائل الثلاثة في InaccessiblePaths=. وبالمثل، فإن "read-only" يعادل في الغالب ReadOnlyPaths=، و "tmpfs" يعادل في الغالب TemporaryFileSystem= مع ":ro".

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

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

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

RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory=

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

إذا استُخدم DynamicUser=، وإذا كانت نسخة النواة تدعم id-mapped mounts[7]، فستكون الأدلة المحددة مملوكة للمستخدم "nobody" في نطاق الأسماء الخاص بالمضيف، وستُربط بـ (وستُصبح مملوكة لـ) معرف المستخدم/المجموعة (UID/GID) الخاص بالخدمة في نطاق الأسماء الخاص بها. للحفاظ على التوافقية مع الإصدارات السابقة، ستبقى الأدلة الموجودة التي أُنشئت دون عمليات وصل برمجية المعرف (id-mapped mounts) دون مساس.

جدول 2. إنشاء الدلائل آليًا ومتغيرات البيئة

الدليل	أسفل مسار وحدات النظام	أسفل مسار وحدات المستخدم	متغير البيئة المعين
RuntimeDirectory=	/run/	$XDG_RUNTIME_DIR	$RUNTIME_DIRECTORY
StateDirectory=	/var/lib/	$XDG_STATE_HOME	$STATE_DIRECTORY
CacheDirectory=	/var/cache/	$XDG_CACHE_HOME	$CACHE_DIRECTORY
LogsDirectory=	/var/log/	$XDG_STATE_HOME/log/	$LOGS_DIRECTORY
ConfigurationDirectory=	/etc/	$XDG_CONFIG_HOME	$CONFIGURATION_DIRECTORY

في حالة RuntimeDirectory= تُزال الدلائل الفرعية الأكثر عمقًا عند إيقاف الوحدة. ومن الممكن الحفاظ على الدلائل المحددة في هذه الحالة إذا ضُبط RuntimeDirectoryPreserve= على restart أو yes (انظر أدناه). لا تُزال الدلائل المحددة مع StateDirectory= و CacheDirectory= و LogsDirectory= و ConfigurationDirectory= عند إيقاف الوحدة.

باستثناء حالة ConfigurationDirectory=، ستكون الدلائل المحددة الأكثر عمقًا مملوكة للمستخدم والمجموعة المحددين في User= و Group=. إذا كانت الدلائل المحددة موجودة بالفعل وكان المستخدم أو المجموعة المالكة لها لا تطابق تلك المضبوطة، فستُغير ملكية جميع الملفات والدلائل الموجودة أسفل الدلائل المحددة بالإضافة إلى الدلائل نفسها تكراريًا لتطابق ما ضُبط. كتحسين، إذا كانت الدلائل المحددة مملوكة بالفعل للمستخدم والمجموعة الصحيحين، تُترك الملفات والدلائل الموجودة أسفلها كما هي، حتى لو لم تكن تطابق ما هو مطلوب. ستُعدل صلاحيات الوصول للدلائل المحددة الأكثر عمقًا لتطابق ما هو محدد في RuntimeDirectoryMode= و StateDirectoryMode= و CacheDirectoryMode= و LogsDirectoryMode= و ConfigurationDirectoryMode=.

تتضمن هذه الخيارات BindPaths= للمسارات المحددة. وعند دمجها مع RootDirectory= أو RootImage=، فإن هذه المسارات تقع دائمًا على المضيف وتُوصل من هناك إلى نطاق أسماء نظام ملفات الوحدة.

إذا استُخدم DynamicUser=، فإن منطق CacheDirectory= و LogsDirectory= و StateDirectory= يتغير قليلاً: تُنشأ الدلائل أسفل /var/cache/private و /var/log/private و /var/lib/private على التوالي، وهي دلائل مضيف تُجعل غير قابلة للوصول للمستخدمين غير ذوي الامتيازات، مما يضمن عدم إمكانية الوصول إلى هذه الدلائل من خلال إعادة تدوير معرف المستخدم الديناميكي. تُنشأ روابط رمزية لإخفاء هذا الاختلاف في السلوك. وبالتالي، تظهر الدلائل ذات الصلة دائمًا مباشرة أسفل /var/cache و /var/log و /var/lib، سواء من منظور المضيف أو من داخل الوحدة.

استخدم RuntimeDirectory= لإدارة دليل تشغيل واحد أو أكثر للوحدة وربط عمرها بعمر تشغيل العفريت (daemon). هذا مفيد بشكل خاص للعفاريت غير ذات الامتيازات التي لا يمكنها إنشاء دلائل تشغيل في /run/ بسبب الافتقار إلى الامتيازات، وللتأكد من تنظيف دليل التشغيل آليًا بعد الاستخدام. بالنسبة لدلائل التشغيل التي تتطلب تكوينًا أكثر تعقيدًا أو اختلافًا أو ضمانات لعمرها، يرجى التفكير في استخدام tmpfiles.d(5).

تدعم خيارات RuntimeDirectory= و StateDirectory= و CacheDirectory= و LogsDirectory= اختياريًا معامِلين إضافيين، يفصل بينهما ":". سيُفسر المعامل الثاني كمسار وجهة سيُنشأ كرابط رمزي للدليل. ستُنشأ الروابط الرمزية بعد إعداد أي خيارات BindPaths= أو TemporaryFileSystem=، لإتاحة إمكانية الربط الرمزي سريع الزوال. يمكن للمصدر نفسه أن يمتلك روابط رمزية متعددة، باستخدام المعامل الأول نفسه، ولكن بمعامل ثاني مختلف. المعامل الثالث هو حقل علم، ومنذ الإصدار v257 يمكنه أخذ القيمة ro لجعل الدليل للقراءة فقط للخدمة. هذا مدعوم أيضًا لـ ConfigurationDirectory=. إذا أُعدت روابط رمزية متعددة، فسيكون الدليل للقراءة فقط إذا ضُبط رابط واحد على الأقل ليكون للقراءة فقط. لتمرير علم بدون رابط رمزي للوجهة، يمكن أن يكون المعامل الثاني فارغًا، على سبيل المثال:

ConfigurationDirectory=foo::ro

تُنشأ الدلائل المحددة بواسطة هذه الخيارات دائمًا تحت المسارات القياسية التي يستخدمها systemd (/var/ و /run/ و /etc/ و ...). إذا كانت الخدمة بحاجة إلى دلائل في موقع مختلف، فيجب استخدام آلية مختلفة لإنشائها.

يوفر tmpfiles.d(5) وظائف تتداخل مع هذه الخيارات. ويُوصى باستخدام هذه الخيارات، لأن عمر الدلائل مرتبط مباشرة بعمر الوحدة، وليس من الضروري التأكد من تنفيذ تكوين tmpfiles.d قبل بدء الوحدة.

لإزالة أي من الدلائل المنشأة بواسطة هذه الإعدادات، استخدم الأمر systemctl clean ... على الوحدات ذات الصلة، انظر systemctl(1) للتفاصيل.

مثال: إذا كانت وحدة خدمة النظام تحتوي على ما يلي،

RuntimeDirectory=foo/bar baz

يُنشئ مدير الخدمة /run/foo (إذا لم يكن موجودًا)، و /run/foo/bar، و /run/baz. تكون الدلائل /run/foo/bar و /run/baz باستثناء /run/foo مملوكة للمخدم والمجموعة المحددين في User= و Group=، وتُزال عند إيقاف الخدمة.

مثال: إذا كانت وحدة خدمة النظام تحتوي على ما يلي،

RuntimeDirectory=foo/bar
StateDirectory=aaa/bbb ccc

عندئذٍ يُضبط متغير البيئة "RUNTIME_DIRECTORY" بـ "/run/foo/bar"، ويُضبط "STATE_DIRECTORY" بـ "/var/lib/aaa/bbb:/var/lib/ccc".

مثال: إذا كانت وحدة خدمة النظام تحتوي على ما يلي،

RuntimeDirectory=foo:bar foo:baz

يُنشئ مدير الخدمة /run/foo (إذا لم يكن موجودًا)، و /run/bar بالإضافة إلى /run/baz كروابط رمزية إلى /run/foo.

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

RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode=, ConfigurationDirectoryMode=

يحدد وضع الوصول للدلائل المحددة في RuntimeDirectory= أو StateDirectory= أو CacheDirectory= أو LogsDirectory= أو ConfigurationDirectory=، على التوالي، كعدد ثماني. القيمة المبدئية هي 0755. انظر "Permissions" في path_resolution(7) لمناقشة معنى بتات الصلاحيات.

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

RuntimeDirectoryPreserve=

يأخذ معاملًا منطقيًا أو القيمة restart. إذا ضُبط على no (المبدئي)، تُزال الدلائل المحددة في RuntimeDirectory= دائمًا عند توقف الخدمة. وإذا ضُبط على restart، فيُحتفظ بالدلائل عند إعادة تشغيل الخدمة آليًا ويدويًا على حد سواء. هنا، تعني إعادة التشغيل الآلية العملية المحددة في Restart=، وتعني إعادة التشغيل اليدوية تلك التي يُطلقها الأمر systemctl restart foo.service. وإذا ضُبط على yes، فلا تُزال الدلائل عند إيقاف الخدمة. لاحظ أنه نظرًا لأن دليل التشغيل /run/ هو نقطة وصل لنظام "tmpfs"، فإن الدلائل المحددة في RuntimeDirectory= لخدمات النظام تُزال عند إعادة تشغيل النظام.

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

TimeoutCleanSec=

يضبط مهلة لعملية التنظيف المطلوبة من خلال systemctl clean ...، انظر systemctl(1) للتفاصيل. يأخذ قيم الوقت المعتادة ويؤول مبدئيًا إلى اللانهاية (infinity)، أي لا تُطبق أي مهلة مبدئيًا. إذا ضُبطت مهلة، فستُجهض عملية التنظيف قسريًا عند الوصول إلى المهلة، مما قد يترك موارد على القرص.

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

ReadWritePaths=، ReadOnlyPaths=، InaccessiblePaths=، ExecPaths=، NoExecPaths=

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

المسارات المدرجة في ReadWritePaths= يمكن الوصول إليها من داخل نطاق الأسماء بنفس أوضاع الوصول كما من خارجه. المسارات المدرجة في ReadOnlyPaths= يمكن الوصول إليها للقراءة فقط، وستُرفض الكتابة حتى لو كانت ضوابط الوصول المعتادة للملف تسمح بذلك. يمكن تعشيش ReadWritePaths= داخل ReadOnlyPaths= لتوفير دلائل فرعية قابلة للكتابة داخل دلائل للقراءة فقط. استخدم ReadWritePaths= لإدراج مسارات معينة في القائمة المسموحة للوصول المكتوب إذا استُخدم ProtectSystem=strict. لاحظ أنه لا يمكن استخدام ReadWritePaths= للحصول على وصول مكتوب لنظام ملفات وُصلت كتلته الفائقة (superblock) بوضع القراءة فقط. في لينكس، يُمنح وصول الكتابة لكل نقطة وصل فقط إذا لم تكن نقطة الوصل نفسها و الكتلة الفائقة لنظام الملفات التي تدعمها مؤشرة بوضع القراءة فقط. يتحكم ReadWritePaths= في الأول فقط وليس الأخير، وبالتالي تظل الكتلة الفائقة لنظام الملفات للقراءة فقط محمية.

المسارات المدرجة في InaccessiblePaths= ستُجعل غير قابلة للوصول للعمليات داخل نطاق الأسماء جنبًا إلى جنب مع كل شيء أسفلها في هيكل نظام الملفات. قد يكون هذا أكثر تقييدًا مما هو مرغوب فيه، لأنه ليس من الممكن تعشيش ReadWritePaths= أو ReadOnlyPaths= أو BindPaths= أو BindReadOnlyPaths= داخلها. للحصول على خيار أكثر مرونة، انظر TemporaryFileSystem=.

المحتوى في المسارات المدرجة في NoExecPaths= ليس قابلاً للتنفيذ حتى لو كانت ضوابط الوصول المعتادة للملف تسمح بذلك. عشّش ExecPaths= داخل NoExecPaths= لتوفير محتوى قابل للتنفيذ داخل دلائل غير قابلة للتنفيذ.

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

المسارات في ReadWritePaths= و ReadOnlyPaths= و InaccessiblePaths= و ExecPaths= و NoExecPaths= يمكن أن تُسبق بـ "-"، وفي هذه الحالة سيُتجاهل وجودها إذا لم تكن موجودة. إذا سُبقت بـ "+" تؤخذ المسارات نسبة إلى الدليل الجذر للوحدة، كما هو مضبوط مع RootDirectory=/RootImage=، بدلاً من كونها نسبة إلى الدليل الجذر للمضيف (انظر أعلاه). عند الجمع بين "-" و "+" على المسار نفسه، تأكد من تحديد "-" أولاً، و "+" ثانياً.

لاحظ أن هذه الإعدادات ستفصل انتشار الوصولات (propagation of mounts) من عمليات الوحدة إلى المضيف. هذا يعني أنه لا يجوز استخدام هذا الإعداد للخدمات التي ينبغي أن تكون قادرة على تثبيت نقاط وصل في نطاق أسماء الوصل الرئيس. بالنسبة لـ ReadWritePaths= و ReadOnlyPaths=، لا يتأثر الانتشار في الاتجاه الآخر، أي أن الوصولات المنشأة على المضيف تظهر عمومًا في نطاق أسماء عمليات الوحدة، والوصولات المزالة على المضيف تختفي هناك أيضًا. على وجه الخصوص، لاحظ أن انتشار الوصل من المضيف إلى الوحدة سينتج عنه إنشاء وصولات غير معدلة في نطاق أسماء الوحدة، أي أن الوصولات القابلة للكتابة التي تظهر على المضيف ستكون قابلة للكتابة في نطاق أسماء الوحدة أيضًا، حتى عند انتشارها أسفل مسار مؤشر بـ ReadOnlyPaths=! وبالتالي فإن تقييد الوصول بهذه الخيارات لا يمتد إلى الوصولات الفرعية للدليل التي تُنشأ لاحقًا. هذا يعني أن الإغلاق الذي يقدمه هذا الإعداد ليس كاملاً، ولا يقدم حماية كاملة.

لاحظ أن مفعول هذه الإعدادات يمكن إبطاله بواسطة العمليات ذات الامتيازات. ولإعداد بيئة معزولة فعالة لوحدة ما، يُوصى بدمج هذه الإعدادات إما مع CapabilityBoundingSet=~CAP_SYS_ADMIN أو SystemCallFilter=~@mount.

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

مثال بسيط للقائمة المسموحة باستخدام هذه التوجيهات:

[Service]
ReadOnlyPaths=/
ReadWritePaths=/var /run
InaccessiblePaths=-/lost+found
NoExecPaths=/
ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64

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

TemporaryFileSystem=

يأخذ قائمة مفصولة بمسافات لنقاط وصل أنظمة الملفات المؤقتة (tmpfs). إذا ضُبط، يُعد نطاق أسماء نظام ملفات جديد للعمليات المنفذة، ويُوصل نظام ملفات مؤقت على كل نقطة وصل. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُوصل أنظمة ملفات مؤقتة على جميع نقاط الوصل المدرجة. إذا أُسندت السلسلة النصية الفارغة إلى هذا الخيار، فستُصفّر القائمة، ولن يكون لجميع التعيينات السابقة أي مفعول. يمكن اختياريًا إلحاق كل نقطة وصل بنقطتين رئيستين (":") وخيارات وصل مثل "size=10%" أو "ro". مبدئيًا، يُوصل كل نظام ملفات مؤقت بـ "nodev,strictatime,mode=0755". ويمكن تعطيل هذه الخيارات عن طريق تحديد خيارات الوصل المقابلة صراحةً، مثل "dev" أو "nostrictatime".

هذا مفيد لإخفاء الملفات أو الدلائل غير ذات الصلة بالعمليات التي تستدعيها الوحدة، بينما لا يزال من الكن الوصول إلى الملفات أو الدلائل الضرورية من خلال الدمج مع BindPaths= أو BindReadOnlyPaths=:

مثال: إذا كانت الوحدة تحتوي على ما يلي،

TemporaryFileSystem=/var:ro
BindReadOnlyPaths=/var/lib/systemd

عندئذٍ لا يمكن للعمليات المستدعاة بواسطة الوحدة رؤية أي ملفات أو دلائل تحت /var/ باستثناء /var/lib/systemd أو محتوياته.

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

PrivateTmp=

يأخذ وسيطًا منطقيًا (boolean)، أو "disconnected". إذا فُعّل، سيُعدُّ نطاق أسماء جديد لنظام الملفات للعمليات المنفَّذة، ولن تُشارك الأدلة /tmp/ و /var/tmp/ بداخلها مع العمليات خارج نطاق الأسماء، بالإضافة إلى أن كل الملفات المؤقتة التي تنشئها الخدمة في هذه الأدلة ستُحذف بعد إيقاف الخدمة. إذا ضُبط على "true"، سيبقى التخزين الداعم للأدلة المؤقتة الخاصة على أدلة /tmp/ و /var/tmp/ الخاصة بالمضيف. إذا ضُبط على "disconnected"، فستُدعم الأدلة بمثيل tmpfs جديد بالكامل، مما يعني أن التخزين مفصول بالكامل عن نطاق أسماء المضيف. القيمة المبدئية هي false.

هذا الإعداد مفيد لتأمين الوصول إلى الملفات المؤقتة للعملية، لكنه يجعل المشاركة بين العمليات عبر /tmp/ أو /var/tmp/ مستحيلة. إذا لم يُضبط على "disconnected"، فمن الممكن تشغيل وحدتين أو أكثر ضمن نفس نطاق الأسماء الخاص لـ /tmp/ و /var/tmp/ باستخدام التوجيه JoinsNamespaceOf=، طالع systemd.unit(5) للمزيد من التفاصيل. هذا الإعداد مُضمن إذا ضُبط DynamicUser=. بالنسبة لهذا الإعداد، تُطبق نفس القيود المتعلقة بانتشار الوصل (mount propagation) والصلاحيات كما هو الحال بالنسبة لـ ReadOnlyPaths= والاستدعاءات ذات الصلة، طالع أعلاه. إذا ضُبط على "true" (على عكس "disconnected")، فهذا سيُنتج عنه أثر جانبي يتمثل في إضافة تبعيات Requires= و After= على كل وحدات الوصل الضرورية للوصول إلى /tmp/ و /var/tmp/ على المضيف. علاوة على ذلك، تُضاف ترتيبية After= ضمنية على systemd-tmpfiles-setup.service(8).

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

PrivateDevices=

يأخذ معاملًا منطقيًا. إذا كان صحيحًا، يُعد وصل /dev/ جديد للعمليات المنفذة ويضيف إليه فقط الأجهزة الوهمية لواجهة برمجة التطبيقات (API pseudo devices) مثل /dev/null و /dev/zero أو /dev/random (بالإضافة إلى نظام TTY الوهمي الفرعي)، ولكن لا يضيف أي أجهزة مادية مثل /dev/sda، وذاكرة النظام /dev/mem، ومنافذ النظام /dev/port وغيرها. هذا مفيد لإيقاف وصول العملية المنفذة إلى الأجهزة المادية. القيمة المبدئية هي خطأ (false).

سيؤدي تمكين هذا الخيار إلى تثبيت مرشح استدعاءات النظام لحظر استدعاءات نظام الإدخال/الإخراج منخفضة المستوى المجمعة في مجموعة @raw-io، وإزالة CAP_MKNOD و CAP_SYS_RAWIO من مجموعة حدود القدرات للوحدة، وضبط DevicePolicy=closed (انظر systemd.resource-control(5) للتفاصيل). لاحظ أن استخدام هذا الإعداد سيفصل انتشار الوصولات من الخدمة إلى المضيف (ويستمر الانتشار في الاتجاه المعاكس في العمل). هذا يعني أنه لا يجوز استخدام هذا الإعداد للخدمات التي ينبغي أن تكون قادرة على تثبيت نقاط وصل في نطاق أسماء الوصل رئيس. سيُوصل دليل /dev/ الجديد بوضع القراءة فقط وبوسم 'noexec'. قد يؤدي الأخير إلى كسر البرامج القديمة التي تحاول إعداد ذاكرة قابلة للتنفيذ باستخدام mmap(2) لـ /dev/zero بدلاً من استخدام MAP_ANON. تنطبق على هذا الإعداد نفس القيود المتعلقة بانتشار الوصل والامتيازات كما في ReadOnlyPaths= والاستدعاءات ذات الصلة، انظر أعلاه.

عندما يجب أن يكون الوصول إلى بعض الأجهزة ممكنًا وليس كلها، يمكن استخدام إعداد DeviceAllow= بدلاً من ذلك. انظر systemd.resource-control(5).

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

PrivateNetwork=

يأخذ معاملًا منطقيًا. إذا كان صحيحًا، يُعد نطاق أسماء شبكة جديد للعمليات المنفذة ويضبط جهاز شبكة الارتداد الملوى "lo" فقط بداخله. لن تتوفر أي أجهزة شبكة أخرى للعملية المنفذة. هذا مفيد لإيقاف وصول العملية المنفذة إلى الشبكة. القيمة المبدئية هي خطأ (false). ومن الممكن تشغيل وحدتين أو أكثر داخل نفس نطاق أسماء الشبكة الخاص باستخدام توجيه JoinsNamespaceOf=، انظر systemd.unit(5) للتفاصيل. لاحظ أن هذا الخيار سيفصل جميع عائلات المقابس عن المضيف، بما في ذلك AF_NETLINK و AF_UNIX. فعليًا، بالنسبة لـ AF_NETLINK، هذا يعني أن أحداث تكوين الجهاز المستلمة من systemd-udevd.service(8) لا تُسلم إلى عمليات الوحدة. وبالنسبة لـ AF_UNIX، فإن هذا يؤدي إلى جعل مقابس AF_UNIX في نطاق أسماء المقابس المجرد للمضيف غير متاحة لعمليات الوحدة (ومع ذلك، فإن تلك الموجودة في نظام الملفات ستظل قابلة للوصول).

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

عند تمكين هذا الخيار، يكون PrivateMounts= ضمنيًا ما لم يُعطل صراحةً، وسيُعاد وصل /sys لربطه بنطاق أسماء الشبكة الجديد.

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

NetworkNamespacePath=

يأخذ مسار نظام ملفات مطلقًا يشير إلى ملف زائف لنطاق أسماء شبكة لينكس (أي ملفًا مثل /proc/$PID/ns/net أو وصلة ربط أو وصلة رمزية تؤدي إليه). عند ضبطه تُضاف العمليات المُستدعاة إلى نطاق أسماء الشبكة المشار إليه بهذا المسار. يجب أن يشير المسار إلى ملف نطاق أسماء صالح في لحظة تفريع العمليات. وإذا اسْتُخدم هذا الخيار فلن يكون لـ PrivateNetwork= أي أثر. وإذا اسْتُخدم هذا الخيار مع JoinsNamespaceOf= فإنه يؤثر فقط إذا بُدئت هذه الوحدة قبل أي من الوحدات المدرجة التي ضُبط فيها PrivateNetwork= أو NetworkNamespacePath=، وإلا فستُعاد استخدام نطاق أسماء الشبكة لتلك الوحدات.

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

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

PrivateIPC=

يأخذ معاملًا منطقيًا. إذا كان صحيحًا (true)، يُهيئ نطاق أسماء IPC جديد للعمليات المُنفذة. لكل نطاق أسماء IPC مجموعته الخاصة من معرفات System V IPC ونظام ملفات صف رسائل POSIX الخاص به. هذا مفيد لتفادي تضارب أسماء معرفات IPC. القيمة المبدئية هي خطأ (false). يمكن تشغيل وحدتين أو أكثر داخل نطاق أسماء IPC الخاص نفسه باستخدام توجيه JoinsNamespaceOf=، انظر systemd.unit(5) للتفاصيل.

لاحظ أن نطاقات أسماء IPC ليس لها أثر على مقابس AF_UNIX، والتي تعد الشكل الأكثر شيوعًا لـ IPC المستخدم على لينكس. بدلًا من ذلك، تخضع مقابس AF_UNIX في نظام الملفات لنطاق أسماء الوصل، وتلك الموجودة في نطاق الأسماء المجرد تخضع لنطاق أسماء الشبكة. يؤثر نطاق أسماء IPC فقط على SysV IPC (والذي يعد قديمًا في الغالب) بالإضافة إلى صفوف رسائل POSIX (والتي تعد مقابس AF_UNIX/SOCK_SEQPACKET بديلًا أفضل لها عادة). وليس لنطاق أسماء IPC أي أثر على ذاكرة POSIX المشتركة (والتي تخضع لنطاق أسماء الوصل) أيضًا. انظر ipc_namespaces(7) للتفاصيل.

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

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

IPCNamespacePath=

يأخذ مسار نظام ملفات مطلقًا يشير إلى ملف زائف لنطاق أسماء IPC لينكس (أي ملفًا مثل /proc/$PID/ns/ipc أو وصلة ربط أو وصلة رمزية تؤدي إليه). عند ضبطه تُضاف العمليات المُستدعاة إلى نطاق أسماء الشبكة المشار إليه بهذا المسار. يجب أن يشير المسار إلى ملف نطاق أسماء صالح في لحظة تفريع العمليات. وإذا اسْتُخدم هذا الخيار فلن يكون لـ PrivateIPC= أي أثر. وإذا اسْتُخدم هذا الخيار مع JoinsNamespaceOf= فإنه يؤثر فقط إذا بُدئت هذه الوحدة قبل أي من الوحدات المدرجة التي ضُبط فيها PrivateIPC= أو IPCNamespacePath=، وإلا فستُعاد استخدام نطاق أسماء الشبكة لتلك الوحدات.

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

MemoryKSM=

يأخذ وسيطًا منطقيًا. عند ضبطه، فإنه يفعّل KSM (دمج نفس الصفحة في النواة) للعمليات. KSM هي ميزة لإلغاء التكرار توفر الذاكرة. يمكن استبدال صفحات الذاكرة المجهولة ذات المحتوى المتطابق بصفحة واحدة محمية من الكتابة. يجب تفعيل هذه الميزة فقط للمهام التي تشترك في نفس نطاق الأمان. للمزيد من التفاصيل، طالع Kernel Samepage Merging[8] في وثائق النواة.

لاحظ أن هذه الوظيفة قد لا تكون متوفرة، على سبيل المثال إذا كانت KSM معطلة في النواة، أو إذا كانت النواة لا تدعم التحكم في KSM على مستوى العملية عبر prctl(2).

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

PrivatePIDs=

يأخذ معاملًا منطقيًا. القيمة المبدئية هي خطأ (false). إذا فُعِّل، يُهيئ نطاق أسماء PID جديد للعمليات المُنفذة. تصبح كل عملية مُنفذة الآن هي PID 1 - عملية بدء التشغيل (init) - في نطاق الأسماء الجديد. ويُوصَل /proc/ بحيث لا تظهر سوى العمليات الموجودة في نطاق أسماء PID. إذا ضُبط PrivatePIDs=، فإن هذا يتضمن ضُمنًا MountAPIVFS=yes.

خيار PrivatePIDs= مدعوم فقط لوحدات الخدمة. هذا الضبط غير مدعوم مع Type=forking لأن النواة ستقتل جميع العمليات في نطاق أسماء PID إذا انتهت عملية init.

سيُتجاهل هذا الضبط إذا كانت النواة لا تدعم نطاقات أسماء PID.

لاحظ أن خدمات المستخدمين غير الممتلِكين للامتيازات (أي الخدمة التي تديرها نسخة مدير الخدمات الخاصة بكل مستخدم) ستفشل مع PrivatePIDs=yes إذا كان /proc/ مقنعًا (أي إذا وُصل /proc/kmsg بشكل متراكب باستخدام tmpfs كما يفعل systemd-nspawn(1)). يرجع هذا إلى قيد في النواة لا يسمح لنطاقات أسماء المستخدمين غير الممتلكين للامتيازات بوصل نسخة أقل قيودًا من /proc/.

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

PrivateUsers=

يأخذ وسيطًا منطقيًا أو إحدى القيمتين "self" أو "identity". القيمة المبدئية هي false. إذا فُعِّل، يُعَدّ فضاء أسماء مستخدمين جديد للعمليات المُنفَّذة ويُضبط تعيين للمستخدمين والمجموعات. إذا ضُبط على قيمة صحيحة أو "self"، يُعَدّ تعيين مستخدم ومجموعة حدّي يربط المستخدم والمجموعة "root" بالإضافة إلى مستخدم ومجموعة الوحدة ذاتها بأنفسهم، وكل شيء آخر بالمستخدم والمجموعة "nobody". هذا مفيد لفصل قواعد بيانات المستخدمين والمجموعات المستخدمة من قِبل الوحدة عن باقي النظام بشكل آمن، وبالتالي إنشاء بيئة معزولة فعالة. ستظل جميع الملفات والمجلدات والعمليات وكائنات IPC والموارد الأخرى التي تملكها مستخدمون/مجموعات لا تساوي "root" أو مستخدم/مجموعة الوحدة مرئية من داخل الوحدة ولكن ستظهر كأنها مملوكة للمستخدم والمجموعة "nobody".

إذا كان المعامل هو "identity"، يُهيئ نطاق أسماء المستخدمين مع تخطيط مطابقة لأول 65536 من معرفات UIDs/GIDs. وأي معرفات UIDs/GIDs فوق 65536 ستُخطط إلى المستخدم والمجموعة "nobody" على التوالي. ومع أن هذا لا يوفر عزلًا لمعرفات UID/GID، نظرًا لاختيار جميع معرفات UIDs/GIDs بشكل متطابق، فإنه يوفر عزلًا لقدرات العملية، وبالتالي غالبًا ما يكون خيارًا جيدًا إذا كان نطاق أسماء المستخدمين المناسب مع خرائط UID متميزة غير ملائم.

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

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

هذا الضبط مفيد بشكل خاص بالاقتران مع RootDirectory=/RootImage=، حيث تقل الحاجة إلى مزامنة قواعد بيانات المستخدمين والمجموعات في الدليل الجذر وعلى المضيف، إذ إن المستخدمين والمجموعات الوحيدين الذين يجب مطابقتهم هم "root" و "nobody" ومستخدم ومجموعة الوحدة نفسها.

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

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

ProtectHostname=

يأخذ وسيطًا منطقيًا. عند ضبطه، يُعَدّ فضاء أسماء UTS جديد للعمليات المُنفَّذة. بالإضافة إلى ذلك، يُمنع تغيير اسم المضيف أو اسم النطاق. القيمة المبدئية هي off.

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

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

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

ProtectClock=

يأخذ معاملًا منطقيًا. إذا ضُبط، ستُرفض عمليات الكتابة في ساعة العتاد أو ساعة النظام. القيمة المبدئية هي الإيقاف (off). يؤدي تفعيل هذا الخيار إلى إزالة CAP_SYS_TIME و CAP_WAKE_ALARM من مجموعة تحديد القدرات لهذه الوحدة، ويُثبّت مرشح نداءات النظام لحظر النداءات التي يمكنها ضبط الساعة، ويتضمن ضُمنًا DeviceAllow=char-rtc r. لاحظ أن نداءات النظام تُحظر تمامًا، ولا يأخذ المرشح في الحسبان أن بعض النداءات يمكن استخدامها لقراءة حالة الساعة مع بعض مجموعات المعاملات. وعمليًا، تصبح الملفات /dev/rtc0 و /dev/rtc1 وغيرها للقراءة فقط بالنسبة للخدمة. انظر systemd.resource-control(5) للتفاصيل حول DeviceAllow=.

يُوصى بتشغيل هذا لمعظم الخدمات التي لا تحتاج إلى تعديل الساعة أو التحقق من حالتها.

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

ProtectKernelTunables=

يأخذ معاملًا منطقيًا. إذا كان صحيحًا (true)، فإن متغيرات النواة التي يمكن الوصول إليها عبر /proc/sys/ و /sys/ و /proc/sysrq-trigger و /proc/latency_stats و /proc/acpi و /proc/timer_stats و /proc/fs و /proc/irq ستصبح للقراءة فقط، وسيتعذر الوصول إلى /proc/kallsyms و /proc/kcore لجميع عمليات الوحدة. عادةً، ينبغي تهيئة متغيرات النواة القابلة للضبط في وقت بدء التشغيل فقط، على سبيل المثال باستخدام آلية sysctl.d(5). وقليل من الخدمات تحتاج إلى الكتابة فيها في وقت التشغيل؛ لذا يُوصى بتشغيل هذا الخيار لمعظم الخدمات. ينطبق على هذا الضبط القيود نفسها المتعلقة بانتشار الوصل والامتيازات كما في ReadOnlyPaths= والنداءات ذات الصلة، انظر أعلاه. القيمة المبدئية هي الإيقاف (off). لاحظ أن هذا الخيار لا يمنع التغييرات غير المباشرة لمتغيرات النواة القابلة للضبط المتأثرة بنداءات IPC لعمليات أخرى. ومع ذلك، يمكن استخدام InaccessiblePaths= لجعل كائنات نظام ملفات IPC ذات الصلة غير قابلة للوصول. إذا ضُبط ProtectKernelTunables=، يتضمن هذا ضُمنًا MountAPIVFS=yes.

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

ProtectKernelModules=

يأخذ معاملًا منطقيًا. إذا كان صحيحًا (true)، سيرفض تحميل الوحدات النمطية الصريح. يتيح هذا إيقاف عمليات تحميل وتفريغ الوحدات النمطية في النوايا المجزأة. يُوصى بتشغيل هذا لمعظم الخدمات التي لا تحتاج إلى أنظمة ملفات خاصة أو وحدات نمطية إضافية للنواة لكي تعمل. القيمة المبدئية هي الإيقاف (off). يؤدي تفعيل هذا الخيار إلى إزالة CAP_SYS_MODULE من مجموعة تحديد القدرات للوحدة، ويُثبّت مرشح نداءات النظام لحظر نداءات نظام الوحدات النمطية، كما يجعل الدليل /usr/lib/modules غير قابل للوصول. ينطبق على هذا الضبط القيود نفسها المتعلقة بانتشار الوصل والامتيازات كما في ReadOnlyPaths= والنداءات ذات الصلة، انظر أعلاه. لاحظ أن التحميل التلقائي المحدود للوحدات النمطية بسبب تهيئة المستخدم أو جداول تخطيط النواة قد يحدث كأثر جانبي لعمليات المستخدم المطلوبة، سواء كانت ممتلكة للامتيازات أم لا. لتعطيل ميزة التحميل التلقائي للوحدات النمطية، يرجى مراجعة آلية kernel.modules_disabled في sysctl.d(5) وتوثيق /proc/sys/kernel/modules_disabled.

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

ProtectKernelLogs=

يأخذ معاملًا منطقيًا. إذا كان صحيحًا (true)، سيُرفض الوصول إلى المخزن المؤقت الدائري لسجلات النواة. يُوصى بتشغيل هذا الخيار لمعظم الخدمات التي لا تحتاج إلى القراءة من المخزن المؤقت الدائري لسجلات النواة أو الكتابة فيه. يؤدي تفعيل هذا الخيار إلى إزالة CAP_SYSLOG من مجموعة تحديد القدرات لهذه الوحدة، ويُثبّت مرشح نداءات النظام لحظر نداء النظام syslog(2) (لا ينبغي الخلط بينه وبين واجهة برمجة تطبيقات libc المسماة syslog(3) للتسجيل في مساحة المستخدم). تعرض النواة مخزن سجلاتها المؤقت لمساحة المستخدم عبر /dev/kmsg و /proc/kmsg. إذا فُعِّل، تصبح هذه الملفات غير قابلة للوصول لجميع العمليات في الوحدة.

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

ProtectControlGroups=

يأخذ معاملًا منطقيًا أو القيم الخاصة "private" أو "strict". إذا كان صحيحًا (true)، فإن تسلسلات مجموعات التحكم في لينكس (cgroups(7)) التي يمكن الوصول إليها عبر /sys/fs/cgroup/ ستصبح للقراءة فقط لجميع عمليات الوحدة. وإذا ضُبط على "private"، فستعمل الوحدة في نطاق أسماء cgroup مع وصلة مستقلة قابلة للكتابة لـ /sys/fs/cgroup/. وإذا ضُبط على "strict"، فستعمل الوحدة في نطاق أسماء cgroup مع وصلة مستقلة للقراءة فقط لـ /sys/fs/cgroup/. القيمة المبدئية هي الإيقاف (off). إذا ضُبط ProtectControlGroups=، يتضمن هذا ضُمنًا MountAPIVFS=yes. لاحظ أن القيمة "private" تُخفّض إلى خطأ (false) والقيمة "strict" تُخفّض إلى صحيح (true) ما لم يكن النظام يستخدم تسلسل مجموعات التحكم الموحد وكانت النواة تدعم نطاقات أسماء cgroup.

باستثناء مديري الحاويات، لا ينبغي لأي خدمات أن تتطلب صلاحية الكتابة في تسلسلات مجموعات التحكم؛ لذا يُوصى بضبط ProtectControlGroups= على صحيح (true) أو "strict" لمعظم الخدمات. ينطبق على هذا الضبط القيود نفسها المتعلقة بانتشار الوصل والامتيازات كما في ReadOnlyPaths= والضبط ذي الصلة، انظر أعلاه.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

RestrictAddressFamilies=

يقيّد مجموعة عائلات عناوين المقابس المتاحة لعمليات هذه الوحدة. يأخذ "none" أو قائمة مفصولة بمسافات بأسماء عائلات العناوين للسماح بها، مثل AF_UNIX أو AF_INET أو AF_INET6. عند تحديد "none"، سيُرفَض الوصول لجميع عائلات العناوين. عند البادئة بـ "~" ستُطبَّق عائلات العناوين المدرجة كقائمة رفض، وإلا فكقائمة سماح.

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

استخدم هذا الخيار للحد من تعرض العمليات للوصول عن بعد، لا سيما عبر بروتوكولات الشبكة الغريبة والحساسة، مثل AF_PACKET. لاحظ أنه في معظم الحالات، ينبغي إدراج عائلة العناوين المحلية AF_UNIX في قائمة المسموحات المضبوطة لأنها تُستخدم بكثرة للاتصال المحلي، بما في ذلك تسجيل سجلات syslog(2).

لاحظ أن هذا يقيد الوصول إلى نداء النظام socket(2) فقط. ولا تتأثر المقابس الممررة إلى العملية بوسائل أخرى (على سبيل المثال، باستخدام تنشيط المقابس مع وحدات المقابس، انظر systemd.socket(5)). وكذلك المقابس المنشأة باستخدام socketpair() (والتي تنشئ مقابس AF_UNIX متصلة) أو وظائف io_uring(7)، لا تتأثر. لذا، يُوصى بدمج هذا الضبط مع SystemCallFilter=@service للسماح فقط بمجموعة فرعية محدودة من نداءات النظام.

لاحظ أن هذا الخيار يقتصر على بعض واجهات ABI، لا سيما x86-64، ولكن ليس له أي أثر حاليًا على المعماريات 32-bit x86 أو s390 أو s390x أو mips أو mips-le أو ppc أو ppc-le أو ppc64 أو ppc64-le، ويُتجاهل فيها. في الأنظمة التي تدعم واجهات ABI متعددة (مثل x86/x86-64) يُوصى بإيقاف واجهات ABI البديلة للخدمات، حتى لا يمكن استخدامها للاحتيال على قيود هذا الخيار. وتحديدًا، يُوصى بدمج هذا الخيار مع SystemCallArchitectures=native أو ما شابه.

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

RestrictFileSystems=

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

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

مثال: إذا كانت الوحدة تحتوي على ما يلي،

RestrictFileSystems=ext4 tmpfs
RestrictFileSystems=ext2 ext4

عندئذٍ يُسمح بالوصول إلى ext4 و tmpfs و ext2 ويُرفض الوصول إلى أنظمة الملفات الأخرى.

مثال: إذا كانت الوحدة تحتوي على ما يلي،

RestrictFileSystems=ext4 tmpfs
RestrictFileSystems=~ext4

عندئذٍ يُسمح فقط بالوصول إلى tmpfs.

مثال: إذا كانت الوحدة تحتوي على ما يلي،

RestrictFileSystems=~ext4 tmpfs
RestrictFileSystems=ext4

عندئذٍ يُحظر فقط الوصول إلى tmpfs.

بما أن عدد أنظمة الملفات الممكنة كبير، توجد مجموعات مسبقة التعريف لأنظمة الملفات. تبدأ المجموعة بالحرف "@"، يليه اسم المجموعة.

جدول 3. مجموعات نظام الملفات المُعرَّفة مسبقًا حاليًا

المجموعة	الوصف
@basic-api	واجهة برمجة تطبيقات نظام الملفات الأساسية.
@auxiliary-api	واجهة برمجة تطبيقات نظام الملفات المساعدة.
@common-block	أنظمة ملفات الأجهزة الكتلية الشائعة.
@historical-block	أنظمة ملفات الأجهزة الكتلية القديمة.
@network	أنظمة ملفات الشبكة المعروفة جزيلاً.
@privileged-api	واجهة برمجة تطبيقات نظام الملفات ذات الامتيازات.
@temporary	أنظمة الملفات المؤقتة: tmpfs, ramfs.
@known	جميع أنظمة الملفات المعروفة والمعرفة من قبل النواة. هذه القائمة معرفة استاتيكيًا في systemd بناءً على نسخة النواة التي كانت متوفرة عند إصدار نسخة systemd هذه. ستصبح قديمة تدريجيًا مع تحديث النواة.

استخدم أمر filesystems الخاص بأداة systemd-analyze(1) لجلب قائمة بأنظمة الملفات المعرفة على النظام المحلي.

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

لا يمكن تجاوز هذا الخيار ببدء مسار الملف التنفيذي بـ "+" في وحدة الخدمة، لأنه ينطبق على مجموعة التحكم بأكملها.

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

RestrictNamespaces=

يقيّد الوصول إلى وظائف فضاء أسماء لينكس لعمليات هذه الوحدة. للحصول على تفاصيل حول فضاءات أسماء لينكس، انظر namespaces(7). يأخذ إما وسيطًا منطقيًا، أو قائمة مفصولة بمسافات من معرفات أنواع فضاءات الأسماء. إذا كانت القيمة false (القيمة المبدئية)، فلا توجد قيود على إنشاء فضاءات الأسماء والتبديل بينها. إذا كانت true، يُحظَر الوصول إلى أي نوع من فضاءات الأسماء. خلاف ذلك، يجب تحديد قائمة مفصولة بمسافات من معرفات أنواع فضاءات الأسماء، مكونة من أي مزيج من: cgroup و ipc و net و mnt و pid و user و uts. يُجعَل أي نوع فضاء أسماء مدرج متاحًا لعمليات الوحدة، ويُحظَر الوصول إلى أنواع فضاءات الأسماء غير المدرجة (قائمة سماح). عن طريق إضافة محرف التلدة ("~") قبل القائمة يمكن عكس التأثير: فقط أنواع فضاءات الأسماء المدرجة ستُجعَل غير متاحة، وجميع الأنواع غير المدرجة مسموح بها (قائمة رفض). إذا عُيّنت سلسلة فارغة، تُطبَّق قيود فضاء الأسماء المبدئية، وهو ما يعادل false. قد يظهر هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمَج أنواع فضاءات الأسماء بواسطة OR، أو بواسطة AND إذا سُبِقت الأسطر بـ "~" (انظر الأمثلة أدناه). داخليًا، يحد هذا الإعداد من الوصول إلى استدعاءات النظام unshare(2) و clone(2) و setns(2)، مع مراعاة وسائط الأعلام المحددة. لاحظ أنه — إذا استُخدِم هذا الخيار — بالإضافة إلى تقييد إنشاء وتبديل الأنواع المحددة من فضاءات الأسماء (أو جميعها، إذا كانت true) يُحظَر الوصول إلى استدعاء النظام setns() مع وسيط أعلام صفري. هذا الإعداد مدعوم فقط على x86 و x86-64 و mips و mips-le و mips64 و mips64-le و mips64-n32 و mips64-le-n32 و ppc64 و ppc64-le و s390 و s390x، ولا يفرض أي قيود على البنيات الأخرى.

مثال: إذا كانت الوحدة تحتوي على ما يلي،

RestrictNamespaces=cgroup ipc
RestrictNamespaces=cgroup net

عندئذٍ تُضبط cgroup و ipc و net. وإذا كانت السطر الثاني مسبوقًا بـ "~"، على سبيل المثال:

RestrictNamespaces=cgroup ipc
RestrictNamespaces=~cgroup net

عندئذٍ، تُضبط ipc فقط.

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

LockPersonality=

يأخذ معاملًا منطقيًا. إذا ضُبط، يُغلق نداء النظام personality(2) بحيث لا يمكن تغيير نطاق تنفيذ النواة عن النطاق المبدئي أو السمة (personality) المحددة عبر توجيه Personality=. قد يكون هذا مفيدًا لتحسين الأمان، لأن محاكاة السمات الغريبة قد لا تكون مختبرة جيدًا وتعد مصدرًا للثغرات الأمنية.

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

MemoryDenyWriteExecute=

يأخذ معاملًا منطقيًا. إذا ضُبط، تُحظر محاولات إنشاء تخطيطات ذاكرة قابلة للكتابة والتنفيذ في الوقت نفسه، أو تغيير تخطيطات الذاكرة الموجودة لتصبح قابلة للتنفيذ، أو تخطيط أجزاء الذاكرة المشتركة كأجزاء قابلة للتنفيذ. وتحديدًا، يُضاف مرشح نداءات النظام (أو يُفضل تفعيل فحص نواة مكافئ عبر prctl(2)) يرفض نداءات نظام mmap(2) التي تضبط كلا العلمين PROT_EXEC و PROT_WRITE، أو نداءات نظام mprotect(2) أو pkey_mprotect(2) التي تضبط العلم PROT_EXEC، ونداءات نظام shmat(2) التي تضبط العلم SHM_EXEC. لاحظ أن هذا الخيار غير متوافق مع البرامج والمكتبات التي تولد كود البرامج ديناميكيًا في وقت التشغيل، بما في ذلك محركات تنفيذ JIT، والمكدسات القابلة للتنفيذ، وميزة "trampoline" للكود في مختلف مجمعات لغة C. يحسن هذا الخيار أمان الخدمة، حيث يجعل من الصعب على استغلال البرمجيات الخبيثة تغيير الكود المشغل ديناميكيًا. ومع ذلك، يمكن الاحتيال على هذه الحماية إذا كانت الخدمة قادرة على الكتابة في نظام ملفات غير موصول بالعلم noexec (مثل /dev/shm)، أو إذا كانت قادرة على استخدام memfd_create(). يمكن منع ذلك بجعل أنظمة الملفات تلك غير قابلة للوصول من الخدمة (مثل InaccessiblePaths=/dev/shm) وتثبيت مرشحات نداءات نظام إضافية (SystemCallFilter=~memfd_create). لاحظ أن هذه الميزة متاحة بالكامل على معمارية x86-64، وجزئيًا على معمارية x86. وتحديدًا، حماية shmat() غير متاحة على معمارية x86. لاحظ أنه في الأنظمة التي تدعم واجهات ABI متعددة (مثل x86/x86-64) يُوصى بإيقاف واجهات ABI البديلة للخدمات، حتى لا يمكن استخدامها للاحتيال على قيود هذا الخيار. وتحديدًا، يُوصى بدمج هذا الخيار مع SystemCallArchitectures=native أو ما شابه.

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

RestrictRealtime=

يأخذ معاملًا منطقيًا. إذا ضُبط، تُرفض أي محاولات لتمكين الجدولة في الوقت الحقيقي في أي عملية تابعة للوحدة. يحد هذا من الوصول إلى سياسات جدولة مهام الوقت الحقيقي مثل SCHED_FIFO أو SCHED_RR أو SCHED_DEADLINE. انظر sched(7) لتفاصيل حول سياسات الجدولة هذه. قد تُستخدم سياسات جدولة الوقت الحقيقي لاحتكار وقت المعالج لفترات زمنية أطول، وبالتالي قد تُستخدم لتعطيل النظام أو التسبب في حالات حجب الخدمة. لذا يوصى بتقييد الوصول إلى جدولة الوقت الحقيقي واقتصارها على البرامج القليلة التي تحتاجها فعليًا. القيمة المبدئية هي الإيقاف.

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

RestrictSUIDSGID=

يأخذ معاملًا منطقيًا. إذا ضُبط، تُرفض أي محاولات لتعيين بتات معرف المستخدم المعين (SUID) أو معرف المجموعة المعين (SGID) على الملفات أو الأدلة (للمزيد من التفاصيل حول هذه البتات انظر inode(7)). بما أن بتات SUID/SGID هي آليات لترقية الصلاحيات والسماح للمستخدمين بانتحال هوية مستخدمين آخرين، فإنه يوصى بتقييد إنشاء ملفات SUID/SGID واقتصارها على البرامج القليلة التي تحتاجها فعليًا. لاحظ أن هذا يمنع وسم أي نوع من كائنات نظام الملفات بهذه البتات، بما في ذلك الملفات العادية والأدلة على حد سواء (حيث يحمل SGID معنى مختلفًا في الأدلة عنه في الملفات، انظر التوثيق). يُضمن هذا الخيار تلقائيًا إذا فُعّل DynamicUser=.. المبدئي off.

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

RemoveIPC=

يأخذ معاملًا منطقيًا. إذا ضُبط، تُزال جميع كائنات IPC الخاصة بنظام System V وPOSIX المملوكة للمستخدم والمجموعة اللذين تُشغّل عمليات هذه الوحدة باسمهما عند إيقاف الوحدة. ليس لهذه التهيئة أي تأثير إلا إذا استُخدم واحد على الأقل من User= أو Group= أو DynamicUser=. وليس لها أي تأثير على كائنات IPC المملوكة للمستخدم الجَذر (root). وتحديدًا، يزيل هذا إشارات السيمافور الخاصة بـ System V، بالإضافة إلى مقاطع الذاكرة المشتركة وطوابير الرسائل الخاصة بـ System V وPOSIX. إذا استخدمت وحدات متعددة نفس المستخدم أو المجموعة، تُزال كائنات IPC عند إيقاف آخر وحدة منها. يُضمن هذا الإعداد تلقائيًا إذا ضُبط DynamicUser=.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

PrivateMounts=

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

عند تشغيله، ينفذ ثلاث عمليات لكل عملية مُستدعاة: تُنشأ مساحة أسماء CLONE_NEWNS جديدة، وبعدها يُعاد وصل جميع الوصلات الموجودة إلى MS_SLAVE لتعطيل التوجيه من عمليات الوحدة إلى المضيف (مع ترك التوجيه في الاتجاه المعاكس ساري المفعول). وأخيرًا، يُعاد وصل الوصلات مجددًا إلى وضع التوجيه المتهيأ باستخدام MountFlags=، انظر أدناه.

تُضبط مساحات أسماء نظام ملفات بشكل فردي لكل عملية متفرعة يطلقها مدير الخدمة. بالتالي، فإن الوصلات المنشأة في مساحة أسماء العملية التي أنشأتها ExecStartPre= سوف تُنظّف آليًا بمجرد خروج تلك العملية، ولن تكون متاحة للعمليات اللاحقة المتفرعة لأجل ExecStart= (وينطبق أمر مماثل على الأوامر المتنوعة الأخرى المهيأة للوحدات). وبالمثل، لا يسمح JoinsNamespaceOf= بمشاركة مساحات أسماء وصل النواة بين الوحدات، بل يتيح فقط مشاركة الدليلين /tmp/ و /var/tmp/.

إعدادات وحدة مساحة أسماء نظام ملفات الأخرى — مثل PrivateTmp= و PrivateDevices= و ProtectSystem= و ProtectHome= و ReadOnlyPaths= و InaccessiblePaths= و ReadWritePaths= و BindPaths= و BindReadOnlyPaths=، إلخ — تُمكّن أيضًا وضع مساحات أسماء نظام ملفات بأسلوب مكافئ لهذا الخيار. وبالتالي، تبرز فائدته أساسًا لطلب هذا السلوك صراحةً إذا لم يُستخدم أي من الإعدادات الأخرى.

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

MountFlags=

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

يتحكم هذا الإعداد فقط في إعداد التوجيه النهائي المعمول به في جميع نقاط وصل مساحة أسماء نظام ملفات المنشأة لكل عملية في هذه الوحدة. ستعطّل إعدادات وحدة مساحات أسماء نظام ملفات الأخرى (انظر النقاش في PrivateMounts= أعلاه) توجيه الوصل والفصل ضمنيًا من عمليات الوحدة نحو المضيف عبر تغيير إعداد التوجيه لجميع نقاط الوصل في مساحة أسماء نظام ملفات للوحدة إلى slave أولًا. وضبط هذا الخيار على shared لا يعيد تأسيس التوجيه في هذه الحالة.

إذا لم يُضبط — ولكن كانت مساحات أسماء نظام ملفات مُمكّنة عبر إعداد وحدة آخر لمساحة أسماء نظام ملفات — يُستخدم توجيه الوصل shared، ولكن — كما ذُكر — بما أن slave يُطبق أولًا، فإن التوجيه من عمليات الوحدة إلى المضيف يظل موقوفًا.

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

عادةً، من الأفضل ترك هذا الإعداد دون تعديل، واستخدام خيارات مساحات أسماء نظام ملفات ذات المستوى الأعلى بدلًا منه، وتحديدًا PrivateMounts=، انظر أعلاه.

ترشيح استدعاءات النظام¶

SystemCallFilter=

يأخذ قائمة مفصولة بمسافات لأسماء استدعاءات النظام أو مجموعات استدعاءات النظام. إذا استُخدم هذا الإعداد، فإن استدعاءات النظام التي تنفذها عمليات الوحدة باستثناء تلك المدرجة في القائمة ستُرفض (قائمة السماح). إذا كان المحرف الأول في القائمة هو "~", ينعكس التأثير: حيث تُرفض فقط استدعاءات النظام المدرجة (قائمة المنع). يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج أقنعة المرشحات. إذا عُيّنت سلسلة فارغة، يُعاد ضبط المرشح، وتصبح جميع التعيينات السابقة بلا تأثير.

الأوامر المسبوقة بـ "+" لا تخضع للترشيح. تُدرج استدعاءات النظام execve() و exit() و exit_group() و getrlimit() و rt_sigreturn() و sigreturn() واستدعاءات النظام الخاصة بالاستعلام عن الوقت والنوم ضمنيًا في قائمة السماح ولا حاجة لإدراجها صراحةً.

الإجراء المبدئي عند رفض استدعاء النظام هو إنهاء العمليات باستخدام إشارة SIGSYS. يمكن تغيير هذا باستخدام SystemCallErrorNumber=، انظر أدناه. بالإضافة إلى ذلك، يمكن اختياريًا إلحاق استدعاءات النظام ومجموعات استدعاءات النظام المدرجة في قائمة المنع بنقطتين (":") ومعامل بنفس تنسيق SystemCallErrorNumber=، لاتخاذ هذا الإجراء عند إجراء استدعاء النظام المطابق. هذا له الأسبقية على الإجراء المحدد في SystemCallErrorNumber=.

تستخدم هذه الميزة واجهات وضع الحوسبة الآمنة 2 (Secure Computing Mode 2) للنواة ('ترشيح seccomp') وهي مفيدة لفرض بيئة عزل مخففة بأقل الحدود.

لاحظ أنه في الأنظمة التي تدعم واجهات تطبيق ثنائية (ABIs) متعددة (مثل x86/x86-64)، يوصى بإيقاف تشغيل واجهات ABI البديلة للخدمات، حتى لا يمكن استخدامها للتحايل على قيود هذا الخيار. وتحديدًا، يوصى بدمج هذا الخيار مع SystemCallArchitectures=native أو ما شابه ذلك.

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

إذا حددت كلا نوعي هذا الخيار (أي قائمة السماح وقائمة المنع)، فإن أول ما يواجهه البرنامج سيكون له الأسبقية ويملي الإجراء المبدئي (إنهاء استدعاء النظام أو الموافقة عليه). ثم ستقوم الحالات التالية لهذا الخيار بإضافة أو حذف استدعاءات النظام المدرجة من مجموعة استدعاءات النظام المرشحة، اعتمادًا على نوعها والإجراء المبدئي. (على سبيل المثال، إذا بدأت بقاعدة قائمة سماح لـ read() و write()، وأضفت بعدها مباشرة قاعدة قائمة منع لـ write()، فسيُزال write() من المجموعة.)

بما أن عدد استدعاءات النظام الممكنة كبير، تُوفّر مجموعات مسبقة التعريف من استدعاءات النظام. تبدأ المجموعة بالمحرف "@"، يليه اسم المجموعة.

جدول 4. مجموعات استدعاءات النظام المُعرَّفة مسبقًا حاليًا

المجموعة	الوصف
@aio	الإدخال/الإخراج غير المتزامن (io_setup(2) و io_submit(2) والاستدعاءات ذات الصلة)
@basic-io	استدعاءات النظام للإدخال/الإخراج الأساسي: القراءة والكتابة والتقديم وتكرار واصف الملف وإغلاقه (read(2) و write(2) والاستدعاءات ذات الصلة)
@chown	تغيير ملكية الملف (chown(2) و fchownat(2) والاستدعاءات ذات الصلة)
@clock	استدعاءات النظام لتغيير ساعة النظام (adjtimex(2) و settimeofday(2) والاستدعاءات ذات الصلة)
@cpu-emulation	استدعاءات النظام لوظائف محاكاة المعالج (vm86(2) والاستدعاءات ذات الصلة)
@debug	وظائف التنقيح ومراقبة الأداء والتتبع (ptrace(2) و perf_event_open(2) والاستدعاءات ذات الصلة)
@file-system	عمليات نظام الملفات: فتح وإنشاء الملفات والأدلة للقراءة والكتابة، وإعادة تسميتها وإزالتها، وقراءة خصائص الملفات، أو إنشاء روابط صلبة ورمزية
@io-event	استدعاءات نظام حلقة الأحداث (poll(2) و select(2) و epoll(7) و eventfd(2) والاستدعاءات ذات الصلة)
@ipc	الأنابيب، و SysV IPC، وطوابير رسائل POSIX ووسائل IPC الأخرى (mq_overview(7) و svipc(7))
@keyring	الوصول إلى حلقة مفاتيح النواة (keyctl(2) والاستدعاءات ذات الصلة)
@memlock	قفل الذاكرة في رام (mlock(2) و mlockall(2) والاستدعاءات ذات الصلة)
@module	تحميل وإلغاء تحميل وحدات النواة (init_module(2) و delete_module(2) والاستدعاءات ذات الصلة)
@mount	وصل وفصل نظم الملفات (mount(2) و chroot(2) والاستدعاءات ذات الصلة)
@network-io	مدخلات/مخرجات المقابس (بما في ذلك AF_UNIX المحلي): socket(7) و unix(7)
@obsolete	غير معتادة، أو مهجورة، أو غير مدعومة (create_module(2) و gtty(2)، إلخ)
@pkey	استدعاءات النظام التي تتعامل مع مفاتيح حماية الذاكرة (pkeys(7))
@privileged	جميع استدعاءات النظام التي تحتاج إلى صلاحيات المستخدم الفائق (capabilities(7))
@process	التحكم في العمليات، والتنفيذ، وعمليات مساحات الأسماء (clone(2) و kill(2) و namespaces(7)، إلخ)
@raw-io	الوصول المباشر إلى منافذ الإدخال/الإخراج (ioperm(2) و iopl(2) و pciconfig_read()‎، إلخ)
@reboot	استدعاءات النظام لإعادة التشغيل والتحضير لها (reboot(2) و kexec()‎، إلخ)
@resources	استدعاءات النظام لتغيير حدود الموارد، ومعاملات الذاكرة والجدولة (setrlimit(2) و setpriority(2)، إلخ)
@sandbox	استدعاءات النظام لعزل البرامج (seccomp(2)، واستدعاءات نظام Landlock، إلخ)
@setuid	استدعاءات النظام لتغيير بيانات اعتماد معرف المستخدم ومعرف المجموعة (setuid(2) و setgid(2) و setresuid(2)، إلخ)
@signal	استدعاءات النظام للتلاعب بإشارات العمليات ومعالجتها (signal(2) و sigprocmask(2)، إلخ)
@swap	استدعاءات النظام لتمكين/تعطيل أجهزة التبديل (swapon(2) و swapoff(2))
@sync	مزامنة الملفات والذاكرة مع القرص (fsync(2) و msync(2) والاستدعاءات ذات الصلة)
@system-service	مجموعة معقولة من استدعاءات النظام التي تستخدمها خدمات النظام الشائعة، باستثناء أي استدعاءات ذات أغراض خاصة. هذه هي نقطة البداية الموصى بها لإنشاء قوائم السماح باستدعاءات النظام لخدمات النظام، لأنها تحتوي على ما تحتاجه عادةً خدمات النظام، ولكنها تستثني الواجهات المفرطة في الخصوصية. على سبيل المثال، تُستثنى واجهات البرمجة التالية: "@clock" و "@mount" و "@swap" و "@reboot".
@timer	استدعاءات النظام لجدولة العمليات حسب الوقت (alarm(2) و timer_create(2)، إلخ)
@known	جميع استدعاءات النظام التي تحددها النواة. تُعرّف هذه القائمة بشكل ثابت في systemd بناءً على إصدار النواة المتوفر عند إصدار نسخة systemd هذه. وستصبح قديمة تدريجيًا مع تحديث النواة.

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

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

[Service]
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

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

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

يوصى بدمج الخيارات المتعلقة بوضع مساحات أسماء نظام ملفات مع SystemCallFilter=~@mount، وذلك لمنع عمليات الوحدة من التراجع عن الارتباطات. وتحديدًا هذه الخيارات هي: PrivateTmp= و PrivateDevices= و ProtectSystem= و ProtectHome= و ProtectKernelTunables= و ProtectControlGroups= و ProtectKernelLogs= و ProtectClock= و ReadOnlyPaths= و InaccessiblePaths= و ReadWritePaths=.

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

SystemCallErrorNumber=

يأخذ رقم خطأ "errno" (بين 1 و 4095) أو اسم خطأ مثل EPERM أو EACCES أو EUCLEAN، لإعادته عندما يُثار مرشح استدعاءات النظام المهيأ بـ SystemCallFilter=، بدلاً من إنهاء العملية فورًا. انظر errno(3) للقائمة الكاملة لرموز الأخطاء. عندما لا يُستخدم هذا الإعداد، أو عند تعيين سلسلة فارغة أو الإعداد الخاص "kill"، تُنهى العملية فورًا عند إثارة المرشح.

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

SystemCallArchitectures=

يأخذ قائمة مفصولة بمسافات لمعرفات البنيات المعمارية لتضمينها في مرشح استدعاءات النظام. معرفات البنيات المعروفة هي نفسها الخاصة بـ ConditionArchitecture= الموصوفة في systemd.unit(5)، بالإضافة إلى x32 و mips64-n32 و mips64-le-n32، والمعرّف الخاص native. يُطابق المعرّف الخاص native ضمنيًا البنية المعمارية الأصلية للنظام (أو بمزيد من الدقة: البنية التي جُمع مدير النظام لأجلها). مبدئيًا، يُضبط هذا الخيار على قائمة فارغة، أي لا يُطبّق أي ترشيح.

إذا استُخدم هذا الإعداد، فسيُسمح لعمليات هذه الوحدة فقط بإجراء استدعاءات النظام الأصلية (native)، واستدعاءات النظام للبنيات المعمارية المحددة. لأغراض هذا الخيار، تُعامل معمارية x32 على أنها تتضمن استدعاءات نظام x86-64. ومع ذلك، فإن هذا الإعداد لا يزال يؤدي غرضه، كما هو موضح أدناه، على x32.

لا يتسم ترشيح استدعاءات النظام بنفس الفعالية في جميع البنيات المعمارية. على سبيل المثال، لا يمكن ترشيح الاستدعاءات المتعلقة بمقابس الشبكة على x86 بسبب قيود واجهة ABI — وهو قيد لا وجود له في x86-64 ومع ذلك. في الأنظمة التي تدعم واجهات ABI متعددة في نفس الوقت — مثل x86/x86-64 — يوصى بالتالي بتقييد مجموعة بنيات استدعاءات النظام المسموح بها حتى لا يمكن استخدام واجهات ABI الثانوية للتحايل على القيود المفروضة على واجهة ABI الأصلية للنظام. وتحديدًا، يعد ضبط SystemCallArchitectures=native خيارًا جيدًا لتعطيل واجهات ABI غير الأصلية.

يمكن أيضًا تقييد بنيات استدعاءات النظام على مستوى النظام ككل عبر خيار SystemCallArchitectures= في التهيئة العامة. انظر systemd-system.conf(5) للتفاصيل.

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

SystemCallLog=

يأخذ قائمة مفصولة بمسافات لأسماء استدعاءات النظام. إذا استُخدم هذا الإعداد، فسيُسجّل كل استدعاء نظام تنفذه عمليات الوحدة يطابق الاستدعاءات المدرجة. إذا كان المحرف الأول في القائمة هو "~", ينعكس التأثير: حيث تُسجّل جميع استدعاءات النظام باستثناء تلك المدرجة في القائمة. تستخدم هذه الميزة واجهات وضع الحوسبة الآمنة 2 (Secure Computing Mode 2) للنواة ('ترشيح seccomp') وهي مفيدة للمراجعة التدقيقية أو لإعداد بيئة عزل مخففة بأقل الحدود. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج أقنعة المرشحات. إذا عُيّنت سلسلة فارغة، يُعيد ضبط المرشح، وتصبح جميع التعيينات السابقة بلا تأثير. ولا يؤثر هذا على الأوامر المسبوقة بـ "+".

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

البيئة¶

Environment=

يعين متغيرات البيئة للعمليات المنفذة Orc. يزال الاقتباس عن كل سطر باستخدام القواعد الموصوفة في قسم "Quoting" في systemd.syntax(7) ويتحول إلى قائمة من تعيينات المتغيرات. إذا كنت بحاجة إلى تعيين قيمة تحتوي على مسافات أو علامة التساوي لمتغير ما، فضع علامات اقتباس حول التعيين بأكمله. لا يجرى توسيع المتغيرات داخل السلاسل النصية ولا يحمل المحرف "$" أي معنى خاص. يجرى توسيع المحددات، انظر قسم "Specifiers" في systemd.unit(5).

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

يمكن أن تحتوي أسماء المتغيرات على أحرف ASCII وأرقام ومحرف الشرطة السفلية (_). لا يمكن أن تكون أسماء المتغيرات فارغة أو تبدأ برقم. في قيم المتغيرات، يُسمح بمعظم المحارف، ولكن تُرفض المحارف غير القابلة للطباعة حاليًا.

مثال:

Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"

يعطي ثلاثة متغيرات "VAR1" و "VAR2" و "VAR3" بالقيم "word1 word2" و "word3" و "$word 5 6".

انظر environ(7) لتفاصيل حول متغيرات البيئة.

لاحظ أن متغيرات البيئة ليست مناسبة لتمرير الأسرار (مثل كلمات المرور، ومواد المفاتيح، وما إلى ذلك) إلى عمليات الخدمة. متغيرات البيئة المعينة لوحدة ما تكون مكشوفة للعملاء غير المتميزين عبر نظام D-Bus IPC، ولا تُفهم عمومًا على أنها بيانات تتطلب حماية. علاوة على ذلك، تُوجّه متغيرات البيئة إلى أسفل شجرة العمليات، بما في ذلك عبر الحدود الأمنية (مثل الملفات التنفيذية ذات صلاحيات setuid/setgid)، وبالتالي قد تتسرب إلى عمليات لا ينبغي لها الوصول إلى البيانات السرية. استخدم LoadCredential= أو LoadCredentialEncrypted= أو SetCredentialEncrypted= (انظر أدناه) لتمرير البيانات إلى عمليات الوحدة بشكل آمن.

EnvironmentFile=

مماثل لـ Environment=، ولكنه يقرأ متغيرات البيئة من ملف نصي. يجب أن يحتوي الملف النصي على تعيينات متغيرات مفصولة بأسطر جديدة. الأسطر الفارغة، أو الأسطر التي لا تحتوي على فاصل "="، أو الأسطر التي تبدأ بـ ";" أو "#" سوف تُتجاهل، ويمكن استخدامها للتعليق. يجب أن يكون الملف مرمّزًا بـ UTF-8. المحارف الصالحة هي unicode scalar values[9] بخلاف unicode noncharacters[10]، و U+0000 NUL، و U+FEFF unicode byte order mark[11]. رموز التحكم بخلاف NUL مسموح بها.

في الملف، تُحلل القيمة غير المحاطة بعلامات اقتباس بعد علامة "=" باستخدام نفس قواعد هروب الخط المائل العكسي المستخدمة في نص صدفة POSIX غير المحاط بعلامات اقتباس[12]، ولكن على عكس الصدفة، تُحفظ المسافات البيضاء الداخلية وتُحفظ علامات الاقتباس التي تأتي بعد أول محرف غير مسافة بيضاء. تُهمَل المسافات البيضاء البادئة والختامية (المسافة، وعلامة الجدولة، وإرجاع العربة)، ولكن تُحفظ المسافات البيضاء الداخلية داخل السطر حرفيًا. السطر الذي ينتهي بخط مائل عكسي سيتصل بالسطر التالي، مع إهمال السطر الجديد نفسه. الخط المائل العكسي "\" المتبوع بأي محرف آخر غير السطر الجديد سيحفظ المحرف التالي، بحيث تصبح "\\" هي القيمة "\".

في الملف، يمكن للقيمة المحاطة بعلامة اقتباس مفردة "'" بعد علامة "=" أن تمتد عبر أسطر متعددة وأن تحتوي على أي محرف حرفيًا باستثناء علامة الاقتباس المفردة، مثل نص صدفة POSIX المحاط بعلامة اقتباس مفردة[13]. لا تُفسَّر أي تسلسلات هروب بالخط المائل العكسي. تُهمَل المسافات البيضاء البادئة والختامية خارج علامات الاقتباس المفردة.

في الملف، يمكن للقيمة المحاطة بعلامات اقتباس مزدوجة """ بعد علامة "=" أن تمتد عبر أسطر متعددة، وتُفسَّر نفس تسلسلات الهروب كما في نص صدفة POSIX المحاط بعلامات اقتباس مزدوجة[14]. الخط المائل العكسي ("\") المتبوع بأي من ""\`$" سيحفظ ذلك المحرف. الخط المائل العكسي المتبوع بسطر جديد يعد استمرارًا للسطر، ويُهمَل السطر الجديد نفسه. الخط المائل العكسي المتبوع بأي محرف آخر يُتجاهل؛ ويُحفظ كل من الخط المائل العكسي والمحرف التالي حرفيًا. تُهمَل المسافات البيضاء البادئة والختامية خارج علامات الاقتباس المزدوجة.

يجب أن يكون الوسيط المُمرَّر اسم ملف مطلق أو تعبير بديل، مسبوقًا اختياريًا بـ "-"، مما يشير إلى أنه إذا لم يكن الملف موجودًا، فلن يُقرأ ولن تُسجَّل أي رسالة خطأ أو تحذير. قد يُحدَّد هذا الخيار أكثر من مرة وفي هذه الحالة تُقرأ جميع الملفات المحددة. إذا عُيّنت سلسلة فارغة لهذا الخيار، تُعاد تهيئة قائمة الملفات المراد قراءتها، ولا يكون لجميع التعيينات السابقة أي تأثير.

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

تتخطى الإعدادات القادمة من هذه الملفات الإعدادات المعينة باستخدام Environment=. إذا عُيّن نفس المتغير مرتين من هذه الملفات، فستُقرأ الملفات بالترتيب الذي حددت به، وسيتخطى الإعداد اللاحق الإعداد السابق.

PassEnvironment=

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

المتغيرات المعينة للعمليات المستدعاة بسبب هذا الإعداد تخضع للتخطي بواسطة تلك المضبوطة باستخدام Environment= أو EnvironmentFile=.

مثال:

PassEnvironment=VAR1 VAR2 VAR3

يمرر ثلاثة متغيرات "VAR1" و "VAR2" و "VAR3" مع القيم المعينة لتلك المتغيرات في PID1.

انظر environ(7) لتفاصيل حول متغيرات البيئة.

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

UnsetEnvironment=

ألغِ صراحةً تعيينات متغيرات البيئة التي تُمرر عادةً من مدير الخدمة إلى العمليات المستدعاة لهذه الوحدة. يأخذ قائمة بأسماء المتغيرات أو تعيينات المتغيرات المفصولة بمسافات. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة يُلغى تعيين جميع المتغيرات/التعيينات المدرجة. إذا أُسندت سلسلة نصية فارغة إلى هذا الخيار، فستُصفّر قائمة متغيرات/تعيينات البيئة المراد إلغاء تعيينها. إذا حُدد تعيين متغير (أي: اسم متغير، متبوعًا بـ "="، متبوعًا بقيمته)، فسيُزال أي متغير بيئة يطابق هذا التعيين الدقيق. إذا حُدد اسم متغير (أي اسم متغير دون أي "=" أو قيمة تالية)، فسيُزال أي تعيين يطابق اسم المتغير بغض النظر عن قيمته. لاحظ أن تأثير UnsetEnvironment= يُطبَّق كخطوة نهائية عند تجميع قائمة البيئة الممررة إلى العمليات المنفذة. هذا يعني أنه قد يتراجع عن التعيينات من أي مصدر ضبط، بما في ذلك التعيينات التي تمت من خلال Environment= أو EnvironmentFile=، أو الموروثة من مجموعة متغيرات البيئة العالمية لمدير النظام، أو الموروثة عبر PassEnvironment=، أو المعينة بواسطة مدير الخدمة نفسه (مثل $NOTIFY_SOCKET وما شابه)، أو المعينة بواسطة وحدة PAM (في حال استخدام PAMName=).

انظر "متغيرات البيئة في العمليات المولدة" أدناه للحصول على وصف لكيفية دمج هذه الإعدادات لتشكيل البيئة الموروثة. انظر environ(7) للحصول على معلومات عامة عن متغيرات البيئة.

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

التسجيل والإدخال/الإخراج القياسي¶

StandardInput=

يتحكم في مكان اتصال واصف الملف 0 (STDIN) للعمليات المنفذة. يأخذ أحد الخيارات التالية: null، أو tty، أو tty-force، أو tty-fail، أو data، أو file:path، أو socket، أو fd:name.

إذا اختير null، فسيُوصَل الإدخال القياسي بـ /dev/null، أي أن جميع محاولات القراءة بواسطة العملية ستؤدي إلى نهاية ملف (EOF) فورية.

إذا اختير tty، فسيُوصَل الإدخال القياسي بمثيرة TTY (كما هي مضبوطة بواسطة TTYPath=، انظر أدناه) وتصبح العملية المنفذة هي العملية المتحكمة في الطرفية. إذا كانت الطرفية خاضعة بالفعل لتحكم عملية أخرى، فستنتظر العملية المنفذة حتى تحرر العملية المتحكمة الحالية الطرفية.

الخيار tty-force مشابه لـ tty، ولكن تُجعل العملية المنفذة قسرًا وفورًا هي العملية المتحكمة في الطرفية، مما قد يؤدي إلى إزالة العمليات المتحكمة السابقة من الطرفية.

الخيار tty-fail مشابه لـ tty، ولكن إذا كانت الطرفية تمتلك بالفعل عملية متحكمة، فإن بدء تشغيل العملية المنفذة يفشل.

يمكن استخدام الخيار data لِضبط بيانات نصية أو ثنائية اختيارية لتمريرها عبر الإدخال القياسي إلى العملية المنفذة. تُضبط البيانات المراد تمريرها عبر StandardInputText=/StandardInputData= (انظر أدناه). لاحظ أن نوع واصف الملف الفعلي الممرر (ملف ذاكرة، ملف عادي، أنبوب UNIX، ...) قد يعتمد على النواة والامتيازات المتاحة. في كل الأحوال، يكون واصف الملف للقراءة فقط، وعند قراءته يُرجع البيانات المحددة متبوعة بنهاية الملف EOF.

يمكن استخدام الخيار file:path لوصل كائن نظام ملفات معين بالإدخال القياسي. يُتوقع مسار مطلق يتبع محرف ":"، والذي قد يشير إلى ملف عادي، أو FIFO، أو ملف خاص. إذا حُدد مقبس AF_UNIX في نظام الملفات، فسيُوصَل مقبس تدفق به. هذا الأخير مفيد لوصل الإدخال القياسي للعمليات بخدمات النظام الاختيارية.

خيار socket صالح في الخدمات المُفعلة بالمقابس فقط، ويتطلب أن يكون لملف وحدة المقبس ذات الصلة (انظر systemd.socket(5) للتفاصيل) إعداد Accept=yes، أو أن يحدد مقبسًا واحدًا فقط. إذا عُيّن هذا الخيار، فسيُوصَل الإدخال القياسي بالمقبس الذي أُنشطت الخدمة منه، وهو مفيد في المقام الأول للتوافق مع العفاريت (daemons) المصممة للاستخدام مع عفريت تنشيط المقابس التقليدي inetd(8) (لا تُمرر متغيرات البيئة $LISTEN_FDS (وما يتصل بها) عند ضبط قيمة socket).

يوصل الخيار fd:name الإدخال القياسي بواصف ملف معين ومسمى توفره وحدة مقبس. يمكن تحديد الاسم كجزء من هذا الخيار، متبوعًا بمحرف ":" (على سبيل المثال: "fd:foobar"). إذا لم يُحدد اسم، فإن الاسم "stdin" يكون ضمنيًا (أي أن "fd" تكافئ "fd:stdin"). يجب توفير وحدة مقبس واحدة على الأقل تُعرّف الاسم المحدد عبر خيار Sockets=، وقد يختلف اسم واصف الملف عن اسم وحدة المقبس التي تحتويه. إذا عُثر على مطابقات متعددة، فستُستخدم المطابقة الأولى. انظر FileDescriptorName= في systemd.socket(5) لمزيد من التفاصيل حول واصفات الملفات المسماة وترتيبها.

يكون هذا الإعداد مبدئيًا هو null، ما لم يُعيّن StandardInputText= أو StandardInputData=، وفي هذه الحالة يكون مبدئيًا هو data.

StandardOutput=

يتحكم في مكان اتصال واصف الملف 1 (stdout) للعمليات المنفذة. يأخذ أحد الخيارات التالية: inherit، أو null، أو tty، أو journal، أو kmsg، أو journal+console، أو kmsg+console، أو file:path، أو append:path، أو truncate:path، أو socket، أو fd:name.

يقوم الخيار inherit بمضاعفة واصف ملف الإدخال القياسي لِيُستخدم للإخراج القياسي.

يوصل الخيار null الإخراج القياسي بـ /dev/null، أي أن كل ما يُكتب فيه سَيُفقد.

يوصل الخيار tty الإخراج القياسي بمثيرة tty (كما هي مضبوطة عبر TTYPath=، انظر أدناه). إذا استُخدمت TTY للإخراج فقط، فلن تصبح العملية المنفذة هي العملية المتحكمة في الطرفية، ولن تفشل أو تنتظر العمليات الأخرى لتحرير الطرفية. ملاحظة: إذا حاولت وحدة طباعة أسطر متعددة إلى TTY أثناء بدء التشغيل أو الإيقاف، فهناك احتمال أن تُجزأ تلك الأسطر بواسطة رسائل الحالة. يمكن استخدام SetShowStatus() لمنع هذه المشكلة. انظر org.freedesktop.systemd1(5) للتفاصيل.

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

يوصل الخيار kmsg الإخراج القياسي بمخزن سجل النواة المؤقت الذي يمكن الوصول إليه عبر dmesg(1)، بالإضافة إلى السجل. قد يكون عفريت السجل مضبوطًا لإرسال جميع السجلات إلى kmsg على أي حال، وفي هذه الحالة لا يختلف هذا الخيار عن journal.

يعمل الخياران journal+console و kmsg+console بطريقة مشابهة للخيارين أعلاه ولكنهما ينسخان الإخراج إلى محطة تحكم النظام (console) أيضًا.

يمكن استخدام الخيار file:path لوصل كائن نظام ملفات معين بالإخراج القياسي. الدلالات مشابهة لنفس الخيار في StandardInput=، انظر أعلاه. إذا كان path يشير إلى ملف عادي في نظام الملفات، فإنه يُفتح (ويُنشأ إذا لم يكن موجودًا بعد باستخدام امتيازات المستخدم الذي ينفذ عملية systemd) للكتابة في بداية الملف، ولكن دون اقتطاعه. إذا وُجّه الإدخال والإخراج القياسيان إلى نفس مسار الملف، فإنه يُفتح مرة واحدة فقط — للقراءة والكتابة معًا — ويُضاعَف واصف الملف. هذا مفيد بشكل خاص عندما يشير المسار المحدد إلى مقبس AF_UNIX في نظام الملفات، حيث لا يُنشأ في هذه الحالة سوى اتصال تدفق واحد لكل من الإدخال والإخراج.

الخيار append:path مشابه لـ file:path أعلاه، ولكنه يفتح الملف في وضع الإلحاق (append mode).

الخيار truncate:path مشابه لـ file:path أعلاه، ولكنه يقتطع الملف عند فتحه. بالنسبة للوحدات التي تحتوي على أسطر أوامر متعددة، مثل خدمات Type=oneshot التي تحتوي على خيارات ExecStart= متعددة، أو الخدمات التي تحتوي على ExecCondition= أو ExecStartPre= أو ExecStartPost=، يُعاد فتح ملف الإخراج وبالتالي يُعاد اقتطاعه لكل سطر أمر. إذا أُقتطع ملف الإخراج بينما لا يزال هناك عملية أخرى تفتح الملف، على سبيل المثال بواسطة ExecReload= يعمل بالتزامن مع ExecStart=، واستمرت العملية الأخرى في الكتابة إلى الملف دون ضبط إزاحتها، فإن المسافة بين مؤشري الملف للعمليتين قد تُملأ ببايتات NUL، مما ينتج ملفًا مخلخلًا (sparse file). وبالتالي، فإن truncate:path عادةً ما يكون مفيدًا فقط للوحدات التي تعمل فيها عملية واحدة فقط في كل مرة، مثل الخدمات التي تحتوي على ExecStart= واحد ولا تحتوي على ExecStartPost= أو ExecReload= أو ExecStop= أو ما شابه.

يوصل الخيار socket الإخراج القياسي بمقبس حُصل عليه عبر تنشيط المقابس. الدلالات مشابهة لنفس الخيار في StandardInput=، انظر أعلاه.

يوصل الخيار fd:name الإخراج القياسي بواصف ملف معين ومسمى توفره وحدة مقبس. يمكن تحديد الاسم كجزء من هذا الخيار، متبوعًا بمحرف ":" (على سبيل المثال: "fd:foobar"). إذا لم يُحدد اسم، فإن الاسم "stdout" يكون ضمنيًا (أي أن "fd" تكافئ "fd:stdout"). يجب توفير وحدة مقبس واحدة على الأقل تُعرّف الاسم المحدد عبر خيار Sockets=، وقد يختلف اسم واصف الملف عن اسم وحدة المقبس التي تحتويه. إذا عُثر على مطابقات متعددة، فستُستخدم المطابقة الأولى. انظر FileDescriptorName= في systemd.socket(5) لمزيد من التفاصيل حول الواصفات المسماة وترتيبها.

إذا وُصل الإخراج القياسي (أو إخراج الخطأ، انظر أدناه) لوحدة ما بالسجل أو بمخزن سجل النواة المؤقت، فستكتسب الوحدة ضمنيًا اعتمادية من نوع After= على systemd-journald.socket (انظر أيضًا قسم "الاعتماديات الضمنية" أعلاه). لاحظ أيضًا أنه في هذه الحالة، سيكون stdout (أو stderr، انظر أدناه) عبارة عن مقبس تدفق AF_UNIX، وليس أنبوبًا أو FIFO يمكن إعادة فتحه. هذا يعني أنه عند تنفيذ برمجيات الصدفة النصية، فإن البنية echo "hello" > /dev/stderr لكتابة نص إلى stderr لن تعمل. للتخفيف من ذلك، استخدم البنية echo "hello" >&2 بدلاً منها، والتي تكافئها في الغالب وتتجنب هذا المأزق.

إذا عُيّن StandardInput= إلى أحد الخيارات tty، أو tty-force، أو tty-fail، أو socket، أو fd:name، فإن هذا الإعداد يكون مبدئيًا هو inherit.

في الحالات الأخرى، يكون هذا الإعداد مبدئيًا هو القيمة المعينة في DefaultStandardOutput= في systemd-system.conf(5)، والتي تكون مبدئيًا هي journal. لاحظ أن تعيين هذا المعامل قد يؤدي إلى إضافة اعتماديات إضافية إلى الوحدة (انظر أعلاه).

StandardError=

يتحكم في مكان اتصال واصف الملف 2 (stderr) للعمليات المنفذة. الخيارات المتاحة مطابقة لخيارات StandardOutput=، مع بعض الاستثناءات: إذا عُيّن إلى inherit فإن واصف الملف المستخدم للإخراج القياسي يُضاعَف لِيُستخدم للخطأ القياسي، بينما سَيستخدم fd:name اسم واصف ملف مبدئي هو "stderr".

يكون هذا الإعداد مبدئيًا هو القيمة المعينة في DefaultStandardError= في systemd-system.conf(5)، والتي تكون مبدئيًا هي inherit. لاحظ أن تعيين هذا المعامل قد يؤدي إلى إضافة اعتماديات إضافية إلى الوحدة (انظر أعلاه).

StandardInputText=، StandardInputData=

يضبط بيانات نصية أو ثنائية اختيارية لتمريرها عبر واصف الملف 0 (STDIN) إلى العمليات المنفذة. ليس لهذه الإعدادات أي تأثير ما لم يُعيّن StandardInput= إلى data (وهو الخيار المبدئي إذا لم يُضبط StandardInput= بخلاف ذلك، ولكن عُيّن StandardInputText=/StandardInputData=). استخدم هذا الخيار لتضمين بيانات إدخال العملية مباشرة في ملف الوحدة.

يقبل StandardInputText= بيانات نصية اختيارية. تُفسَّر تتابعات هروب لغة C للمحارف الخاصة بالإضافة إلى محددات "%" المعتادة. في كل مرة يُستخدم فيها هذا الإعداد، يُلحق النص المحدد بمخزن بيانات الوحدة المؤقت، متبوعًا بمحرف سطر جديد (وبالتالي فإن كل استخدام يلحق سطرًا جديدًا بنهاية المخزن المؤقت). لاحظ أن المسافات البيضاء البادئة والختامية للأسطر المضبوطة بهذا الخيار تُزال. إذا حُدد سطر فارغ، فسيُمسح المخزن المؤقت (وبالتالي، لإدراج سطر فارغ، أضف "\n" إضافية إلى نهاية السطر أو بدايته).

يقبل StandardInputData= بيانات ثنائية اختيارية، مَرموزة بـ Base64[15]. لا تُفسَّر أي تسلسلات هروب أو محددات. تُتجاهل أي مسافة بيضاء في النسخة المرموزة أثناء فك الترميز.

لاحظ أن StandardInputText= و StandardInputData= يعملان على نفس مخزن البيانات المؤقت، ويمكن المزج بينهما لِضبط كل من البيانات الثنائية والنصية لنفس تدفق الإدخال. تُضم البيانات النصية أو الثنائية بدقة حسب ترتيب ظهور الإعدادات في ملف الوحدة. يؤدي إسناد سلسلة نصية فارغة لأي منهما إلى تصفير مخزن البيانات المؤقت.

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

...
StandardInput=data
StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZXMgYW5kIHNvIGRv \


                  IEkKQSBmdWxsIGNvbW1pdG1lbnQncyB3aGF0IEnigLJtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4n \


                  dCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJ \


                  J20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCgpOZXZlciBnb25uYSBnaXZlIHlv \


                  dSB1cApOZXZlciBnb25uYSBsZXQgeW91IGRvd24KTmV2ZXIgZ29ubmEgcnVuIGFyb3VuZCBhbmQg \


                  ZGVzZXJ0IHlvdQpOZXZlciBnb25uYSBtYWtlIHlvdSBjcnkKTmV2ZXIgZ29ubmEgc2F5IGdvb2Ri \


                  eWUKTmV2ZXIgZ29ubmEgdGVsbCBhIGxpZSBhbmQgaHVydCB5b3UK
...

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

LogLevelMax=

يضبط تصفية رسائل السجل المُولَّدة بواسطة هذه الوحدة حسب مستوى السجل. يأخذ مستوى سجل syslog، أحد المستويات: emerg (أدنى مستوى سجل، فقط الرسائل ذات الأولوية القصوى)، alert، crit، err، warning، notice، info، debug (أعلى مستوى سجل، وأيضًا الرسائل ذات الأولوية الدنيا). انظر syslog(3) للحصول على تفاصيل. مبدئيًا لا تُطبَّق أي تصفية (أي أن الحد الأقصى المبدئي لمستوى السجل هو debug). استخدم هذا الخيار لضبط نظام التسجيل لإسقاط رسائل سجل خدمة معينة فوق المستوى المحدد. على سبيل المثال، اضبط LogLevelMax=info لإيقاف تسجيل التنقيح لوحدة كثيرة الثرثرة. لاحظ أن المستوى المضبط يُطبَّق على أي رسائل سجل مكتوبة بواسطة أي من العمليات التابعة لهذه الوحدة، وكذلك أي رسائل سجل مكتوبة بواسطة عملية مدير النظام (PID 1) فيما يتعلق بهذه الوحدة، والمُرسَلة عبر أي بروتوكول تسجيل مدعوم. تُطبَّق التصفية في وقت مبكر من خط أنابيب التسجيل، قبل إجراء أي نوع من المعالجة الإضافية. علاوة على ذلك، الرسائل التي تجتاز هذه المرشحة بنجاح قد لا تزال تُسقَط بواسطة المرشحات المطبقة في مرحلة لاحقة في النظام الفرعي للتسجيل. على سبيل المثال، MaxLevelStore= المضبط في journald.conf(5) قد يمنع تخزين رسائل مستويات السجل الأعلى على القرص، على الرغم من أن LogLevelMax= لكل وحدة سمح بمعالجتها.

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

LogExtraFields=

يضبط حقول بيانات وصفية إضافية للسجل لتضمينها في جميع سجلات الأحداث التي تولدها العمليات المرتبطة بهذه الوحدة، بما في ذلك systemd. يأخذ هذا الإعداد تعيين حقل سجل واحد أو أكثر بتنسيق "FIELD=VALUE" مفصولة بمسافات بيضاء. انظر systemd.journal-fields(7) للحصول على تفاصيل حول مفهوم حقل السجل. على الرغم من أن آلية السجل الأساسية تسمح بقيم حقول ثنائية، فإن هذا الإعداد لا يقبل إلا قيم UTF-8 صالحة. لتضمين محارف مسافات في قيمة حقل السجل، أحط التعيين بعلامات اقتباس مزدوجة ("). تُوسَّع المحددات المعتادة في جميع التعيينات (انظر أدناه). لاحظ أن هذا الإعداد ليس مفيدًا فقط لإرفاق بيانات وصفية إضافية بسجلات أحداث الوحدة، ولكن بما أن جميع الحقول والقيم مفهرسة، فيمكن استخدامه أيضًا لتنفيذ مطابقة سجلات الأحداث عبر الوحدات المختلفة. أسند سلسلة نصية فارغة لتصفير القائمة.

لاحظ أن هذه الوظيفة متاحة حاليًا في خدمات النظام فقط، وليس في الخدمات الخاصة بكل مستخدم.

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

LogRateLimitIntervalSec=, LogRateLimitBurst=

يضبط حد المعدل الذي يُطبَّق على رسائل السجل المولدة بواسطة هذه الوحدة. إذا سُجّلت رسائل بواسطة خدمة ما في الفاصل الزمني المحدد بواسطة LogRateLimitIntervalSec= أكثر مما هو محدد في LogRateLimitBurst=، فستُسقط جميع الرسائل اللاحقة خلال الفاصل الزمني حتى ينتهي الفاصل الزمني. وتُولَّد رسالة تفيد بعدد الرسائل المسقطة. يمكن تحديد مواصفات الوقت لـ LogRateLimitIntervalSec= بالوحدات التالية: "s"، و "min"، و "h"، و "ms"، و "us". انظر systemd.time(7) للتفاصيل. تُعيّن الإعدادات المبدئية بواسطة RateLimitIntervalSec= و RateLimitBurst= المضبوطين في journald.conf(5). لاحظ أن هذا ينطبق فقط على رسائل السجل التي يُعالجها نظام التسجيل الفرعي، أي بواسطة systemd-journald.service(8). هذا يعني أنه إذا وُصل stderr الخاص بالخدمة مباشرة بملف عبر StandardOutput=file:... أو إعداد مشابه، فلن يُطبَّق حد المعدل على الرسائل المكتوبة بتلك الطريقة (ولكن سيُفرض على الرسائل المولدة عبر syslog(3) والدوال المشابهة).

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

LogFilterPatterns=

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

نظرًا لأن المحرف "~" يُستخدم لتحديد الأنماط المرفوضة، فيجب استبداله بـ "\x7e" للسماح برسالة تبدأ بـ "~". على سبيل المثال، "~foobar" سيضيف نمطًا يطابق "foobar" إلى قائمة الرفض، بينما "\x7efoobar" سيضيف نمطًا يطابق "~foobar" إلى قائمة السماح.

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

تعتمد التصفية على الوحدة التي عُرّف لها LogFilterPatterns=، مما يعني أن رسائل السجل القادمة من systemd(1) حول الوحدة لا تُؤخذ في الحسبان. لن تُوجّه رسائل السجل المصفاة إلى عفاريت syslog التقليدية، أو مخزن سجل النواة المؤقت (kmsg)، أو محطة تحكم systemd، ولن تُرسل كرسائل حائط (wall messages) إلى جميع المستخدمين المسجلين دخولهم.

لاحظ أن هذه الوظيفة متاحة حاليًا في خدمات النظام فقط، وليس في الخدمات الخاصة بكل مستخدم.

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

LogNamespace=

تشغيل عمليات الوحدة في فضاء أسماء السجل المحدد. يتوقع سلسلة قصيرة مُعرَّفة من قِبل المستخدم تحدد فضاء الأسماء. إذا لم تُستخدم، تُشغَّل عمليات الخدمة في فضاء أسماء السجل المبدئي، أي أن دفق سجلها يُجمَع ويُعالَج بواسطة systemd-journald.service. إذا استُخدِم هذا الخيار، فإن أي بيانات سجل مُولَّدة بواسطة عمليات هذه الوحدة (بغض النظر عما إذا كان ذلك عبر syslog()، أو تسجيل journal الأصلي، أو تسجيل stdout/stderr) تُجمَع وتُعالَج بواسطة نسخة من وحدة القالب systemd-journald@.service، التي تدير فضاء الأسماء المحدد. تُخزَّن بيانات السجل في مخزن بيانات مستقل عن مخزن بيانات فضاء أسماء السجل المبدئي. انظر systemd-journald.service(8) للحصول على تفاصيل حول فضاءات أسماء السجل.

داخليًا، تُنفَّذ مساحات اسم السجل من خلال مساحات اسم الوصل في لينكس (Linux mount namespacing) وفوق الوصل (over-mounting) للدليل الذي يحتوي على مقابس AF_UNIX ذات الصلة والمستخدمة للتسجيل في مساحة اسم الوصل الخاصة بالوحدة. نظرًا لاستخدام مساحات اسم الوصل، فإن هذا الإعداد يفصل انتشار عمليات الوصل من عمليات الوحدة إلى المضيف، بشكل مشابه لكيفية عمل ReadOnlyPaths= والإعدادات المماثلة الموصوفة أعلاه. وبالتالي، لا يجوز استخدام مساحات اسم السجل للخدمات التي تحتاج إلى إنشاء نقاط وصل على المضيف.

عند استخدام هذا الخيار، ستكتسب الوحدة آليًا اعتماديات ترتيب ومتطلبات على وحدتي المقبس المرتبطتين بمثيل systemd-journald@.service بحيث تُنشأ آليًا قبل بدء تشغيل الوحدة. لاحظ أنه عند استخدام هذا الخيار، لا يظهر مخرج السجل لهذه الخدمة في مخرج journalctl(1) العادي، ما لم يُستخدَم خيار --namespace=.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

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

SyslogIdentifier=

يعين اسم العملية ("وسم syslog") لِتبدأ به أسطر السجل المرسلة إلى نظام التسجيل أو مخزن سجل النواة المؤقت. إذا لم يُضبط، يكون مبدئيًا هو اسم العملية للعملية المنفذة. يكون هذا الخيار مفيدًا فقط عندما يُعيّن StandardOutput= أو StandardError= إلى journal أو kmsg (أو نفس الإعدادات بالاشتراك مع +console) وينطبق فقط على رسائل السجل المكتوبة إلى stdout أو stderr.

SyslogFacility=

يعين معرف مرفق syslog لاستخدامه عند التسجيل. أحد الخيارات التالية: kern، أو user، أو mail، أو daemon، أو auth، أو syslog، أو lpr، أو news، أو uucp، أو cron، أو authpriv، أو ftp، أو local0، أو local1، أو local2، أو local3، أو local4، أو local5، أو local6، أو local7. انظر syslog(3) للتفاصيل. يكون هذا الخيار مفيدًا فقط عندما يُعيّن StandardOutput= أو StandardError= إلى journal أو kmsg (أو نفس الإعدادات بالاشتراك مع +console)، وينطبق فقط على رسائل السجل المكتوبة إلى stdout أو stderr. ويكون مبدئيًا هو daemon.

SyslogLevel=

مستوى تسجيل syslog المبدئي للاستخدام عند التسجيل في نظام التسجيل أو مخزن سجل النواة المؤقت. أحد الخيارات التالية: emerg، أو alert، أو crit، أو err، أو warning، أو notice، أو info، أو debug. انظر syslog(3) للتفاصيل. يكون هذا الخيار مفيدًا فقط عندما يُعيّن StandardOutput= أو StandardError= إلى journal أو kmsg (أو نفس الإعدادات بالاشتراك مع +console)، وينطبق فقط على رسائل السجل المكتوبة إلى stdout أو stderr. لاحظ أن الأسطر الفردية التي تخرجها العمليات المنفذة قد تبدأ بمستوى تسجيل مختلف يمكن استخدامه لتخطي مستوى التسجيل المبدئي المحدد هنا. يمكن تعطيل تفسير هذه البوادئ باستخدام SyslogLevelPrefix=، انظر أدناه. للتفاصيل، انظر sd-daemon(3). ويكون مبدئيًا هو info.

SyslogLevelPrefix=

يأخذ معطى منطقيًا. إذا كان صحيحًا (true) وعُيّن StandardOutput= أو StandardError= إلى journal أو kmsg (أو نفس الإعدادات بالاشتراك مع +console)، فإن أسطر السجل التي تكتبها العملية المنفذة والتي تبدأ بمستوى تسجيل سَتعالج مع تعيين مستوى التسجيل هذا ولكن مع إزالة البادئة. إذا عُيّن إلى خطأ (false)، يُعطّل تفسير هذه البوادئ وتُمرر الأسطر المسجلة كما هي. ينطبق هذا فقط على رسائل السجل المكتوبة إلى stdout أو stderr. لمزيد من التفاصيل حول هذه البوادئ، انظر sd-daemon(3). ويكون مبدئيًا هو صحيح (true).

TTYPath=

يعين عقدة جهاز الطرفية للاستخدام إذا كان الإدخال، أو الإخراج، أو الخطأ القياسي موصولًا بمثيرة TTY (انظر أعلاه). ويكون مبدئيًا هو /dev/console.

TTYReset=

أعد ضبط جهاز الطرفية المحدد بـ TTYPath= قبل التنفيذ وبعده. هذا لا يمسح الشاشة (انظر TTYVTDisallocate= أدناه من أجل ذلك). ويكون مبدئيًا هو "no".

TTYVHangup=

افصل جميع العملاء الذين فتحوا جهاز الطرفية المحدد بـ TTYPath= قبل التنفيذ وبعده. ويكون مبدئيًا هو "no".

TTYColumns=, TTYRows=

اضبط حجم TTY المحددة بـ TTYPath=. إذا لم يُعين أو عُيّن إلى سلسلة نصية فارغة، فستُجرى محاولة لاسترداد أبعاد شاشة الطرفية عبر تتابعات ANSI، وإذا فشل ذلك، تُستخدم القيم المبدئية للنواة (عادةً 80x24).

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

TTYVTDisallocate=

إذا كان جهاز الطرفية المحدد بـ TTYPath= عبارة عن طرفية وحدة تحكم افتراضية، فحاول إلغاء تخصيص TTY قبل التنفيذ وبعده. هذا يضمن مسح الشاشة ومخزن التمرير الخلفي المؤقت. إذا كان جهاز الطرفية من أي نوع آخر من TTY، تُجرى محاولة لمسح الشاشة عبر تتابعات ANSI. ويكون مبدئيًا هو "no".

بيانات الاستيثاق¶

LoadCredential=ID[:PATH]، LoadCredentialEncrypted=ID[:PATH]

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

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

إذا لم يكن المسار المحدد مطلقًا وكان هو نفسه مؤهلًا كمعرّف اعتمادية صالح، يُحاوَل العثور على اعتمادية تلقاها مدير الخدمة نفسه تحت الاسم المحدد — والتي يمكن استخدامها لنشر الاعتمادات من بيئة مستدعية (على سبيل المثال، مدير حاوية استدعى مدير الخدمة) إلى خدمة. إذا لم يُعثَر على اعتمادية نظام مطابقة، يُبحَث في المجلدات /etc/credstore/ و /run/credstore/ و /usr/lib/credstore/ عن ملفات تحت اسم الاعتمادية — والتي تُعد بالتالي مواقع موصى بها لبيانات الاعتمادية على القرص. إذا استُخدِم LoadCredentialEncrypted=، يُبحَث أيضًا في /run/credstore.encrypted/ و /etc/credstore.encrypted/ و /usr/lib/credstore.encrypted/.

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

لاحظ أنه إذا لم يُحدد المسار أو أُعطي مُعرِّف اعتماد صالح، أي في الحالتين أعلاه، فلا يُعتبر فقدان الاعتماد أمرًا حاسمًا.

إذا حُدد مسار مطلق يشير إلى دليل، فسيُحمَّل كل ملف في ذلك الدليل (بشكل متكرر) كاعتماد منفصل. سيكون مُعرِّف كل اعتماد هو المُعرِّف المُقدَّم متبوعًا بـ "_$FILENAME" (مثال: "Key_file1"). عند التحميل من دليل، ستُتجاهل الروابط الرمزية.

قد تكون محتويات الملف/المقبس بيانات ثنائية أو نصية اعتباطية، بما في ذلك محارف الأسطر الجديدة وبايتات NUL.

إعداد LoadCredentialEncrypted= مطابق لـ LoadCredential=، باستثناء أن بيانات الاعتمادية تُفك تعميتها وتُوثَّق قبل تمريرها إلى العمليات المُنفَّذة. تحديدًا، يجب أن يشير المسار المُشار إليه إلى ملف أو مقبس به اعتمادية مُعمَّاة، كما هو مُنفَّذ بواسطة systemd-creds(1). تُحمَّل هذه الاعتمادية وتُفك تعميتها وتُوثَّق ثم تُمرَّر إلى التطبيق في صورة نص صريح، بنفس الطريقة التي ستكون عليها الاعتمادية العادية المحددة عبر LoadCredential=. يمكن تعمية/توثيق اعتمادية مضبوطة بهذه الطريقة بشكل متناظر باستخدام مفتاح سري مُشتق من رقاقة أمن TPM2 الخاصة بالنظام، أو باستخدام مفتاح سري مخزن في /var/lib/systemd/credentials.secret، أو بكليهما. يؤدي استخدام الاعتمادات المُعمَّاة والمُوثَّقة إلى تحسين الأمان حيث لا تُخزَّن الاعتمادات كنص صريح ولا تُوثَّق وتُفك تعميتها إلى نص صريح إلا في اللحظة التي تُبدأ فيها الخدمة التي تتطلبها. علاوة على ذلك، يمكن ربط الاعتمادات بالأجهزة والتثبيتات المحلية، بحيث لا يمكن تحليلها بسهولة في وضع عدم الاتصال، أو إنشاؤها خارجيًا. عندما يُضبط DevicePolicy= على "closed" أو "strict"، أو يُضبط على "auto" ويكون DeviceAllow= مضبوطًا، أو يكون PrivateDevices= مضبوطًا، فإن هذا الإعداد يضيف /dev/tpmrm0 بوضع rw إلى DeviceAllow=. انظر systemd.resource-control(5) للحصول على تفاصيل حول DevicePolicy= أو DeviceAllow=.

لاحظ أن الاعتمادات المُعمَّاة الموجهة لخدمات مدير الخدمة لكل مستخدم يجب أن تُعمَّى باستخدام systemd-creds encrypt --user، وتلك الخاصة بمدير خدمات النظام بدون مفتاح --user. الاعتمادات المُعمَّاة تكون دائمًا موجهة لمستخدم معين أو للنظام ككل، ويُضمن أن مديري خدمات لكل مستخدم لا يمكنهم فك تعمية الأسرار المخصصة للنظام أو لمستخدمين آخرين.

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

للإشارة إلى المسار الذي يمكن قراءة اعتماد منه داخل سطر أوامر ExecStart= استخدم "${CREDENTIALS_DIRECTORY}/mycred"، مثال: "ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred". للإشارة إلى المسار الذي يمكن قراءة اعتماد منه داخل سطر Environment= استخدم "%d/mycred"، مثال: "Environment=MYCREDPATH=%d/mycred". بالنسبة لخدمات النظام، يمكن أيضًا الإشارة إلى المسار كـ "/run/credentials/UNITNAME" في الحالات التي لا يكون فيها الاستيفاء ممكنًا، مثال: ملفات إعداد برمجيات لا تدعم الاعتمادات أصليًا بعد. يُعتبر $CREDENTIALS_DIRECTORY الواجهة الرئيسية للبحث عن الاعتمادات، مع ذلك، لأنه يعمل أيضًا لخدمات المستخدم.

حاليًا، يُفرض حد أقصى متراكم لحجم الاعتماد يبلغ 1 ميجابايت لكل وحدة.

قد يتلقى مدير الخدمة نفسه اعتمادات نظام يمكن نشرها للخدمات من مدير حاوية مستضيف أو مُراقب آلة افتراضية (VM hypervisor). طالع وثائق Container Interface[16] للحصول على تفاصيل حول الأول. بالنسبة للأخير، مرِّر مدخلات جدول سلاسل OEM DMI/SMBIOS[17] (نوع الحقل 11) مع بادئة "iosystemd.credential:" أو "io.systemd.credential.binary:". في كلتا الحالتين، يُتوقع زوج مفتاح/قيمة مفصول بـ "=". في الحالة الأخيرة، يُفك ترميز الجانب الأيمن بـ Base64 عند التحليل (مما يسمح بتمرير بيانات ثنائية). مثال لمفتاح qemu[18]: "-smbios type=11,value=io.systemd.credential:xx=yy"، أو "-smbios type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=". بدلًا من ذلك، استخدم عقدة "fw_cfg" الخاصة بـ qemu "opt/io.systemd.credentials/". مثال لمفتاح qemu: "-fw_cfg name=opt/io.systemd.credentials/mycred,string=supersecret". قد تُمرر أيضًا من بيئة برمجيات UEFI الثابتة عبر systemd-stub(7)، أو من initrd (طالع systemd(1))، أو تُحدد في سطر أوامر النواة باستخدام مفتاحي "systemd.set_credential=" و"systemd.set_credential_binary=" (طالع systemd(1) – هذا غير موصى به لأن مساحة المستخدم غير ذات الصلاحيات يمكنها قراءة سطر أوامر النواة).

عند الإشارة إلى مقبس تدفق AF_UNIX للاتصال به، سينشأ الاتصال من مقبس فضاء أسماء مجرد، يتضمن معلومات حول الوحدة ومعرف الاستيثاق في اسم المقبس الخاص به. استخدم getpeername(2) للاستعلام عن هذه المعلومات. يُنسّق اسم المقبس المُعاد كـ NUL RANDOM "/unit/" UNIT "/" ID، أي بايت NUL (كما هو مطلوب لأسماء مقابس فضاء الأسماء المجردة)، متبوعًا بسلسلة عشوائية (تتكون من محارف أبجدية رقمية)، متبوعة بالسلسلة الحرفية "/unit/"، متبوعة باسم الوحدة الطالبة، متبوعة بالمحرف الحرفي "/"، متبوعًا بمعرف الاستيثاق النصي المطلوب. مثال: "\0adf9d86b6eda275e/unit/foobar.service/credx" في حال طُلب الاستيثاق "credx" للوحدة "foobar.service". هذه الوظيفية مفيدة لاستخدام مقبس استماع واحد لتقديم الاستيثاقات لعدة مستهلكين.

لمزيد من المعلومات انظر توثيق بيانات اعتماد النظام والخدمة[19].

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

ImportCredential=GLOB

مرّر استيثاقًا واحدًا أو أكثر إلى الوحدة. يأخذ اسم استيثاق سنحاول العثور على استيثاق استلمه مدير الخدمة نفسه تحت الاسم المحدد — والذي قد يُستخدم لنشر الاستيثاقات من بيئة مستدعية (مثلًا: مدير حاويات استدعى مدير الخدمة) إلى داخل خدمة. إذا كان اسم الاستيثاق عبارة عن نمط (glob)، تُمرّر جميع الاستيثاقات المطابقة للنمط إلى الوحدة. يُبحث عن الاستيثاقات المطابقة في استيثاقات النظام، واستيثاقات النظام المُعمّاة، وتحت /etc/credstore/، و/run/credstore/، و/usr/lib/credstore/، و/run/credstore.encrypted/، و/etc/credstore.encrypted/، و/usr/lib/credstore.encrypted/ بهذا الترتيب. عند العثور على استيثاقات متعددة تحمل نفس الاسم، يُستخدم أول واحد يُعثر عليه.

يطبق تعبير النمط مجموعة فرعية تقييدية من glob(7): يمكن تحديد محرف بدل "*" واحد فقط في النهاية. لا يُسمح بمحرفي البدل "?" و "[]"، كما لا يُسمح بمحارف البدل "*" في أي مكان باستثناء نهاية تعبير النمط.

اختياريًا، يمكن أن يتبع اسم الاستيثاق أو النمط نقطتان متبوعتان بنمط إعادة تسمية. إذا حُدّد، تُعاد تسمية جميع الاستيثاقات المطابقة لاسم الاستيثاق أو النمط وفقًا لنمط معين. على سبيل المثال، إذا حُدّد "ImportCredential=my.original.cred:my.renamed.cred"، سيقرأ مدير الخدمة استيثاق "my.original.cred" ويجعله متاحًا كاستيثاق "my.renamed.cred" للخدمة. وبالمثل، إذا حُدّد "ImportCredential=my.original.*:my.renamed."، فسيقرأ مدير الخدمة جميع الاستيثاقات التي تبدأ بـ "my.original." ويجعلها متاحة كـ "my.renamed.xxx" للخدمة.

إذا حُدّد ImportCredential= عدة مرات وانتهى الأمر باستيثاقات متعددة تحمل نفس الاسم بعد إعادة التسمية، يُحتفظ بالأول ويُسقط ما تلاه.

عند العثور على استيثاقات متعددة تحمل نفس الاسم، تكون للأولوية للاستيثاقات التي عُثر عليها بواسطة LoadCredential= و LoadCredentialEncrypted= على الاستيثاقات التي عُثر عليها بواسطة ImportCredential=.

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

SetCredential=ID:VALUE، SetCredentialEncrypted=ID:VALUE

إعداد SetCredential= مشابه لـ LoadCredential= ولكنه يقبل قيمة حرفية لاستخدامها كبيانات للاستيثاق، بدلًا من مسار نظام ملفات لقراءة البيانات منه. لا تستخدم هذا الخيار للبيانات المفترض أن تكون سرية، لأنها متاحة للعمليات غير الممتلكة لصلاحيات عبر IPC. من الآمن فقط استخدامه لمعرفات المستخدم، ومواد المفتاح العام، والبيانات غير الحساسة المشابهة. لكل شيء آخر، استخدم LoadCredential=. لتضمين بيانات ثنائية في بيانات الاستيثاق، استخدم الهروب بأسلوب C (أي "\n" لتضمين سطر جديد، أو "\x00" لتضمين بايت NUL).

إعداد SetCredentialEncrypted= مطابق لـ SetCredential= ولكنه يتوقع استيثاقًا مُعمّى بصيغة حرفية كقيمة. يسمح هذا بتضمين استيثاقات سرية بشكل آمن مباشرة في ملفات الوحدة. استخدم مفتاح -p لـ systemd-creds(1) لتوليد أسطر SetCredentialEncrypted= مناسبة مباشرة من الاستيثاقات بنص صريح. للمزيد من التفاصيل انظر LoadCredentialEncrypted= أعلاه.

عند العثور على عدة اعتمادات بنفس الاسم، يكون للاعتمادات التي يعثر عليها LoadCredential= و LoadCredentialEncrypted= و ImportCredential= أولوية على الاعتمادات التي يعثر عليها SetCredential=. وهكذا، سيعمل SetCredential= كمبدئي إذا لم يُعثَر على أي اعتمادات بواسطة أي مما سبق. في هذه الحالة، لا يُعتبر عدم القدرة على استرداد الاعتمادية من المسار المحدد في LoadCredential= أو LoadCredentialEncrypted= أمرًا قاتلًا.

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

توافقية SYSTEM V¶

UtmpIdentifier=

يأخذ سلسلة معرف من أربعة محارف لمدخل utmp(5) و wtmp لهذه الخدمة. يجب ضبط هذا فقط للخدمات مثل تنفيذات getty (مثل agetty(8)) حيث يجب إنشاء وتنظيف مدخلات utmp/wtmp قبل وبعد التنفيذ، أو للخدمات التي ستُنفذ كما لو كانت مُشغلة بواسطة عملية getty (انظر أدناه). إذا كانت السلسلة المضبوطة أطول من أربعة محارف، فستُقتطع وتُستخدم المحارف الأربعة الأخيرة. يفسّر هذا الإعداد استبدالات السلاسل بنمط %I. هذا الإعداد غير مضبوط مبدئيًا، أي لا تُنشأ أو تُنظف أي مدخلات utmp/wtmp لهذه الخدمة.

UtmpMode=

يأخذ إحدى القيم "init" أو "login" أو "user". إذا ضُبط UtmpIdentifier=، يتحكم في نوع مدخلات utmp(5)/wtmp المُنشأة لهذه الخدمة. ليس لهذا الإعداد أي تأثير ما لم يُضبط UtmpIdentifier= أيضًا. إذا ضُبط على "init"، يُنشأ مدخل INIT_PROCESS فقط ويجب أن تطبق العملية المستدعاة منطق utmp/wtmp متوافقًا مع getty. إذا ضُبط على "login"، يُنشأ أولًا مدخل INIT_PROCESS، متبوعًا بمدخل LOGIN_PROCESS. في هذه الحالة، يجب أن تطبق العملية المستدعاة منطق utmp/wtmp متوافقًا مع login(1). إذا ضُبط على "user"، يُنشأ أولًا مدخل INIT_PROCESS، ثم مدخل LOGIN_PROCESS وأخيرًا مدخل USER_PROCESS. في هذه الحالة، قد تكون العملية المستدعاة أي عملية مناسبة لتُشغل كقائد جلسة. القيمة المبدئية هي "init".

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

متغيرات البيئة في العمليات المُنشأة¶

العمليات التي يبدأها مدير الخدمة تُنفذ مع كتلة متغيرات بيئة مُجمّعة من مصادر متعددة. العمليات التي يبدأها مدير خدمة النظام لا ترث عمومًا متغيرات البيئة المضبوطة لمدير الخدمة نفسه (لكن يمكن تغيير هذا عبر PassEnvironment=)، لكن العمليات التي تبدأها نسخ مدير خدمة المستخدم ترث عمومًا جميع متغيرات البيئة المضبوطة لمدير الخدمة نفسه.

لكل عملية مستدعاة، تُجمع قائمة متغيرات البيئة المضبوطة من المصادر التالية:

•المتغيرات المضبوطة عالميًا لمدير الخدمة، باستخدام إعداد DefaultEnvironment= في systemd-system.conf(5)، أو خيار سطر أوامر النواة systemd.setenv= المفهوم بواسطة systemd(1)، أو عبر فعل set-environment الخاص بـ systemctl(1).

•المتغيرات المُعرّفة بواسطة مدير الخدمة نفسه (انظر القائمة أدناه).

•المتغيرات المضبوطة في كتلة متغيرات بيئة مدير الخدمة نفسه (خاضعة لـ PassEnvironment= لمدير خدمة النظام).

•المتغيرات المضبوطة عبر Environment= في ملف الوحدة.

•المتغيرات المقروءة من الملفات المحددة عبر EnvironmentFile= في ملف الوحدة.

•المتغيرات المضبوطة بواسطة أي ملاحق PAM في حال كان PAMName= ساري المفعول، راجع pam_env(8).

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

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

تلميح: systemd-run -P env و systemd-run --user -P env تطبع كتل بيئة خدمة النظام والمستخدم الفعلية.

متغيرات البيئة المضبوطة أو المنشورة بواسطة مدير الخدمة¶

تُنشر متغيرات البيئة التالية بواسطة مدير الخدمة أو تُنشأ داخليًا لكل عملية مُستدعاة:

$PATH

قائمة مفصولة بنقطتين من المجلدات لاستخدامها عند إطلاق الملفات التنفيذية. يستخدم systemd قيمة ثابتة هي "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin" في مدير النظام. في حالة مدير المستخدم، قد تُضبط مسارات مختلفة بواسطة التوزيعة. يُنصح بعدم الاعتماد على ترتيب المدخلات، وأن يوجد برنامج واحد فقط يحمل اسمًا معينًا في $PATH.

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

$LANG

الإعدادات المحلية (Locale). يمكن ضبطها في locale.conf(5) أو في سطر أوامر النواة (طالع systemd(1) و kernel-command-line(7)).

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

$USER, $LOGNAME, $HOME, $SHELL

اسم المستخدم (مرتين)، مجلد المنزل، وصدفة الولوج. يُضبط $USER دون قيد، بينما لا تُضبط $HOME و $LOGNAME و $SHELL إلا للوحدات التي ضُبط فيها User= وكان SetLoginEnvironment= غير مضبوط أو مضبوطًا إلى true. بالنسبة لخدمات المستخدم، عادةً ما تُورث هذه المتغيرات من مدير المستخدم نفسه. طالع passwd(5).

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

$INVOCATION_ID

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

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

$XDG_RUNTIME_DIR

المجلد المراد استخدامه لكائنات وقت التشغيل (مثل كائنات IPC) والحالة المتطايرة. يُضبط لجميع الخدمات التي تشغلها نسخة systemd الخاصة بالمستخدم، وكذلك لأي خدمات نظام تستخدم PAMName= مع مكدس PAM يتضمن pam_systemd. طالع أدناه و pam_systemd(8) لمزيد من المعلومات.

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

$RUNTIME_DIRECTORY, $STATE_DIRECTORY, $CACHE_DIRECTORY, $LOGS_DIRECTORY, $CONFIGURATION_DIRECTORY

المسارات المطلقة للمجلدات المُعرَّفة بـ RuntimeDirectory= و StateDirectory= و CacheDirectory= و LogsDirectory= و ConfigurationDirectory= عند استخدام تلك الإعدادات.

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

$CREDENTIALS_DIRECTORY

مسار مطلق للمجلد الخاص بالوحدة الذي يحتوي على أوراق الاعتماد المضبوطة عبر ImportCredential=/LoadCredential=/SetCredential=. يُعلَّم المجلد كـ للقراءة فقط ويُوضع في ذاكرة غير قابلة للتبديل (إذا كان ذلك مدعومًا ومسموحًا به)، ولا يمكن الوصول إليه إلا بواسطة UID المقترن بالوحدة عبر User= أو DynamicUser= (وكذلك المستخدم الخارق).

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

$MAINPID

معرّف العملية (PID) لعملية الوحدة الرئيسية إذا كان معروفًا. يُضبط هذا فقط لعمليات التحكم كما هي مستدعاة بواسطة ExecReload= وما شابه ذلك.

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

$MANAGERPID

معرّف العملية (PID) لنسخة systemd الخاصة بالمستخدم، مضبوط للعمليات التي تنشأ عنها.

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

$LISTEN_FDS، $LISTEN_PID، $LISTEN_FDNAMES

معلومات حول واصفات الملفات الممررة إلى خدمة من أجل تفعيل المقبس. طالع sd_listen_fds(3).

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

$NOTIFY_SOCKET

المقبس الذي تتحدث إليه sd_notify(). طالع sd_notify(3).

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

$WATCHDOG_PID, $WATCHDOG_USEC

معلومات حول إشعارات إبقاء الاتصال (keep-alive) للمراقب (watchdog). طالع sd_watchdog_enabled(3).

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

$SYSTEMD_EXEC_PID

معرِّف العملية (PID) لعملية الوحدة (مثل العملية التي استُدعيت بواسطة ExecStart=). يمكن للعملية الابنة استخدام هذه المعلومات لتحديد ما إذا كانت العملية مُستدعاة مباشرةً بواسطة مدير الخدمة أو بشكل غير مباشر كابن لعملية أخرى، وذلك بمقارنة هذه القيمة بـ PID الحالي (على غرار المخطط المستخدم في sd_listen_fds(3) مع $LISTEN_PID و $LISTEN_FDS).

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

$TERM

نوع الطرفية، يُضبط فقط للوحدات المتصلة بطرفية (StandardInput=tty أو StandardOutput=tty أو StandardError=tty). طالع termcap(5).

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

$LOG_NAMESPACE

يحتوي على اسم مساحة اسم السجلات المحددة عند استخدام إعداد الخدمة LogNamespace=.

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

$JOURNAL_STREAM

إذا كان الإخراج القياسي أو خطأ الإخراج القياسي للعمليات المُنفَّذة متصلاً بدفتر اليومية (على سبيل المثال، عن طريق ضبط StandardError=journal)، فإن $JOURNAL_STREAM يحتوي على أرقام الجهاز والـ inode لواصف ملف الاتصال، منسقة بالنظام العشري ومفصولة بنقطتين (":"). يسمح هذا للعمليات المُستدعاة باكتشاف ما إذا كان إخراجها القياسي أو خطأ الإخراج القياسي متصلاً بدفتر اليومية بأمان. يجب مقارنة أرقام الجهاز والـ inode لواصفات الملفات بالقيم المحددة في متغير البيئة لتحديد ما إذا كان إخراج العملية لا يزال متصلاً بدفتر اليومية. لاحظ أنه لا يكفي عمومًا التحقق فقط مما إذا كان $JOURNAL_STREAM مضبوطًا على الإطلاق، حيث قد تستدعي الخدمات عمليات خارجية تستبدل إخراجها القياسي أو خطأ الإخراج القياسي الخاص بها، دون إلغاء ضبط متغير البيئة.

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

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

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

$SERVICE_RESULT

يُستخدم فقط لنوع وحدة الخدمة. يُمرر متغير البيئة هذا إلى جميع عمليات ExecStop= و ExecStopPost=، ويُرمِّز "نتيجة" الخدمة. حاليًا، القيم التالية مُعرَّفة:

جدول 5. قيم $SERVICE_RESULT المعرفة

القيمة	المعنى
"success"	عملت الخدمة بنجاح وخرجت بشكل نظيف.
"protocol"	حدث انتهاك للبروتوكول: لم تتخذ الخدمة الخطوات المطلوبة بواسطة ضبط وحدتها (تحديدًا ما هو مضبوط في إعداد Type= الخاص بها).
"timeout"	انتهت مهلة إحدى الخطوات.
"exit-code"	خرجت عملية الخدمة برمز خروج غير صفري؛ طالع $EXIT_CODE أدناه لمعرفة رمز الخروج الفعلي المُرجع.
"signal"	أُنهيت عملية خدمة بشكل غير طبيعي بواسطة إشارة، دون تفريغ الذاكرة (core dump). طالع $EXIT_CODE أدناه لمعرفة الإشارة الفعلية التي تسببت في الإنهاء.
"core-dump"	أُنهيت عملية خدمة بشكل غير طبيعي بإشارة مع تفريغ الذاكرة (core dump). طالع $EXIT_CODE أدناه لمعرفة الإشارة التي تسببت في الإنهاء.
"watchdog"	عُلِّق نبض الحفاظ على العمل (Watchdog keep-alive ping) للخدمة، ولكن فُوِّت الموعد النهائي.
"exec-condition"	لم تعمل الخدمة لأن ExecCondition= فشل (أي أن أمره خرج بحالة خروج تتراوح من 1 إلى 254 (شاملة)).
"oom-kill"	أُنهيت عملية الخدمة بواسطة قاتل نقص الذاكرة (OOM killer).
"start-limit-hit"	عُرِّف حد للبدء للوحدة ووُصِل إليه، مما تسبب في فشل الوحدة في البدء. راجع StartLimitIntervalSec= و StartLimitBurst= الخاصَّيْن بـ systemd.unit(5) للتفاصيل.
"resources"	حالة شاملة في حال فشلت عملية للنظام.

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

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

$EXIT_CODE, $EXIT_STATUS

عُرِّف فقط لنوع وحدة الخدمة. تُمرَّر متغيرات البيئة هذه إلى جميع عمليات ExecStop= و ExecStopPost= وتحتوي على معلومات حالة/رمز الخروج لعملية الخدمة الرئيسية. لمعرفة التعريف الدقيق لرمز وحالة الخروج، راجع wait(2). $EXIT_CODE هو أحد القيم "exited"، أو "killed"، أو "dumped". يحتوي $EXIT_STATUS على رمز الخروج الرقمي منسقاً كسلسلة نصية إذا كان $EXIT_CODE هو "exited"، واسم الإشارة في جميع الحالات الأخرى. لاحظ أن متغيرات البيئة هذه تُضبط فقط إذا نجح مدير الخدمة في بدء وتحديد العملية الرئيسية للخدمة.

جدول 6. ملخص لقيم متغير نتيجة الخدمة الممكنة

$SERVICE_RESULT	$EXIT_CODE	$EXIT_STATUS
"success"	"killed"	"HUP", "INT", "TERM", "PIPE"
"success"	"exited"	"0"
"protocol"	not set	not set
"protocol"	"exited"	"0"
"timeout"	"killed"	"TERM", "KILL"
"timeout"	"exited"	"0", "1", "2", "3", ..., "255"
"exit-code"	"exited"	"1", "2", "3", ..., "255"
"signal"	"killed"	"HUP", "INT", "KILL", ...
"core-dump"	"dumped"	"ABRT", "SEGV", "QUIT", ...
"watchdog"	"dumped"	"ABRT"
	"killed"	"TERM", "KILL"
	"exited"	"0", "1", "2", "3", ..., "255"
"exec-condition"	"exited"	"1", "2", "3", "4", ..., "254"
"oom-kill"	"killed"	"TERM", "KILL"
"start-limit-hit"	not set	not set
"resources"	أي مما سبق	أي مما سبق
ملاحظة: قد تُنهى العملية أيضًا بواسطة إشارة لم يرسلها systemd. وبشكل خاص، قد ترسل العملية إشارة تعسفية إلى نفسها في معالج لأي من الإشارات غير القابلة للقناع. ومع ذلك، في صفوف "timeout" و "watchdog" أعلاه، أُدرجت فقط الإشارات التي يرسلها systemd. علاوة على ذلك، باستخدام SuccessExitStatus=، يمكن التصريح عن حالات خروج إضافية للإشارة إلى الإنهاء النظيف، وهو ما لا ينعكس في هذا الجدول.

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

$MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE, $MONITOR_EXIT_STATUS, $MONITOR_INVOCATION_ID, $MONITOR_UNIT

عُرِّف فقط لنوع وحدة الخدمة. تُمرَّر متغيرات البيئة تلك إلى جميع عمليات ExecStart= و ExecStartPre= التي تعمل في الخدمات المثارَة بواسطة تبعيات OnFailure= أو OnSuccess=.

تأخذ المتغيرات $MONITOR_SERVICE_RESULT و $MONITOR_EXIT_CODE و $MONITOR_EXIT_STATUS نفس القيم الخاصة بعمليات ExecStop= و ExecStopPost=. تُضبط المتغيرات $MONITOR_INVOCATION_ID و $MONITOR_UNIT على معرف الاستدعاء واسم الوحدة للخدمة التي أثارت التبعية.

لاحظ أنه عندما تحدد خدمات متعددة نفس الوحدة كمعالج OnFailure= أو OnSuccess= خاص بها، فإن هذه المتغيرات لن تُمرَّر. فكِّر في استخدام وحدة معالجة قالب (template handler unit) لتلك الحالة بدلاً من ذلك: "OnFailure=handler@%n.service" للوحدات غير المقولبة، أو "OnFailure=handler@%p-%i.service" للوحدات المقولبة.

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

$PIDFILE

المسار إلى ملف PID المضبوط، في حالة تشعب العملية نيابةً عن خدمة تستخدم الإعداد PIDFile=، طالع systemd.service(5) للتفاصيل. قد يستخدم كود الخدمة متغير البيئة هذا لإنشاء ملف PID آلياً في الموقع المضبوط في ملف الوحدة. ضُبط هذا الحقل على مسار مطلق في نظام الملفات.

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

$REMOTE_ADDR, $REMOTE_PORT

إذا كانت هذه وحدة بدأت عبر تفعيل المقبس لكل اتصال (أي عبر وحدة مقبس مع Accept=yes)، فإن متغيرات البيئة هذه تحتوي على معلومات حول الطرف البعيد لاتصال المقبس.

بالنسبة لاتصالات IPv4 و IPv6، يحتوي $REMOTE_ADDR على عنوان IP، ويحتوي $REMOTE_PORT على رقم المنفذ الخاص بالطرف البعيد.

بالنسبة لاتصالات مقبس AF_UNIX، يحتوي $REMOTE_ADDR إما على مسار نظام ملفات المقبس البعيد الذي يبدأ بشرطة مائلة ("/")، أو عنوانه في فضاء الاسم المجرد الذي يبدأ برمز ("@")، أو يكون غير معين في حالة المقبس غير المسمى. $REMOTE_PORT غير معين لمقابس AF_UNIX.

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

$TRIGGER_UNIT, $TRIGGER_PATH, $TRIGGER_TIMER_REALTIME_USEC, $TRIGGER_TIMER_MONOTONIC_USEC

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

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

$MEMORY_PRESSURE_WATCH, $MEMORY_PRESSURE_WRITE

إذا كانت مراقبة ضغط الذاكرة مُفعَّلة لوحدة الخدمة هذه، فالمسار المطلوب مراقبته والبيانات المطلوب كتابتها فيه. انظر Memory Pressure Handling[20] للحصول على تفاصيل حول هذه المتغيرات وبيانات بروتوكول الخدمة التي تنقلها.

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

$FDSTORE

العدد الأقصى لواصفات الملفات التي يمكن تخزينها في المدير للخدمة. يُضبط هذا المتغير عند تفعيل مخزن واصفات الملفات للخدمة، أي FileDescriptorStoreMax= مضبوط على قيمة غير صفرية (طالع systemd.service(5) للتفاصيل). قد تتحقق التطبيقات من متغير البيئة هذا قبل إرسال واصفات الملفات إلى مدير الخدمة عبر sd_pid_notify_with_fds(3).

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

$DEBUG_INVOCATION

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

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

بالنسبة لخدمات النظام، عند تفعيل PAMName= وكون pam_systemd جزءاً من رزمة PAM المختارة، قد تُضبط متغيرات بيئة إضافية معرفة بواسطة systemd للخدمات. وتحديداً، هذه هي $XDG_SEAT، و $XDG_VTNR، طالع pam_systemd(8) للتفاصيل.

رموز خروج العملية¶

عند استدعاء عملية وحدة، ربما يفشل مدير الخدمة في تطبيق معاملات التنفيذ المضبوطة بالإعدادات أعلاه. في تلك الحالة ستخرج عملية الخدمة المنشأة بالفعل برمز خروج غير صفري قبل تنفيذ سطر الأوامر المضبوط. (أو بعبارة أخرى، ربما تخرج العملية الابنة برموز الخطأ هذه، بعد إنشائها بواسطة نداء النظام fork(2)، ولكن قبل استدعاء نداء النظام المطابق execve(2).) تحديداً، تُستخدم رموز الخروج المعرفة بواسطة مكتبة C، ومواصفة LSB، ومدير خدمة systemd نفسه.

رموز خروج الخدمة الأساسية التالية معرفة بواسطة مكتبة C.

جدول 7. رموز الخروج المبدئية لمكتبة C

رمز الخروج	الاسم الرمزي	الوصف
0	EXIT_SUCCESS	رمز نجاح عام.
1	EXIT_FAILURE	فشل عام أو خطأ غير محدد.

رموز خروج الخدمة التالية مُعرَّفة بواسطة LSB specification[21].

جدول 8. رموز خروج خدمة LSB

رمز الخروج	الاسم الرمزي	الوصف
2	EXIT_INVALIDARGUMENT	وسائط غير صالحة أو فائضة.
3	EXIT_NOTIMPLEMENTED	ميزة غير مطبقة.
4	EXIT_NOPERMISSION	المستخدم لديه امتيازات غير كافية.
5	EXIT_NOTINSTALLED	البرنامج غير مثبت.
6	EXIT_NOTCONFIGURED	البرنامج غير مضبوط.
7	EXIT_NOTRUNNING	البرنامج لا يعمل.

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

جدول 9. رموز خروج خاصة بـ systemd

رمز الخروج	الاسم الرمزي	الوصف
200	EXIT_CHDIR	فشل التغيير إلى دليل العمل المطلوب. طالع WorkingDirectory= أعلاه.
201	EXIT_NICE	فشل ضبط أولوية جدولة العملية (مستوى nice). طالع Nice= أعلاه.
202	EXIT_FDS	فشل إغلاق واصفات الملفات غير المرغوب فيها، أو تعديل واصفات الملفات الممررة.
203	EXIT_EXEC	فشل تنفيذ العملية الفعلي (تحديداً، نداء النظام execve(2)). على الأرجح يسبب هذا ملف تنفيذي مفقود أو غير قابل للوصول.
204	EXIT_MEMORY	فشل تنفيذ إجراء بسبب نقص الذاكرة.
205	EXIT_LIMITS	فشل في ضبط حدود الموارد. انظر LimitCPU= والإعدادات المتعلقة أعلاه.
206	EXIT_OOM_ADJUST	فشل في ضبط إعداد OOM. انظر OOMScoreAdjust= أعلاه.
207	EXIT_SIGNAL_MASK	فشل في ضبط قناع إشارة العملية.
208	EXIT_STDIN	فشل في إعداد الدخل القياسي. انظر StandardInput= أعلاه.
209	EXIT_STDOUT	فشل في إعداد الخرج القياسي. انظر StandardOutput= أعلاه.
210	EXIT_CHROOT	فشل في تغيير دليل الجذر (chroot(2)). انظر RootDirectory=/RootImage= أعلاه.
211	EXIT_IOPRIO	فشل في إعداد أولوية جدولة دخل/خرج. انظر IOSchedulingClass=/IOSchedulingPriority= أعلاه.
212	EXIT_TIMERSLACK	فشل في إعداد تراخي المؤقت. انظر TimerSlackNSec= أعلاه.
213	EXIT_SECUREBITS	فشل في ضبط بتات أمن العملية. انظر SecureBits= أعلاه.
214	EXIT_SETSCHEDULER	فشل في إعداد جدولة المعالج. انظر CPUSchedulingPolicy=/CPUSchedulingPriority= أعلاه.
215	EXIT_CPUAFFINITY	فشل في إعداد تقارب المعالج. انظر CPUAffinity= أعلاه.
216	EXIT_GROUP	فشل في تحديد أو تغيير بيانات اعتماد المجموعة. انظر Group=/SupplementaryGroups= أعلاه.
217	EXIT_USER	فشل في تحديد أو تغيير بيانات اعتماد المستخدم، أو في إعداد تجميع مساحات أسماء المستخدم. انظر User=/PrivateUsers= أعلاه.
218	EXIT_CAPABILITIES	فشل في إسقاط الصلاحيات، أو تطبيق الصلاحيات المحيطة. انظر CapabilityBoundingSet=/AmbientCapabilities= أعلاه.
219	EXIT_CGROUP	فشل إعداد مجموعة تحكم الخدمة.
220	EXIT_SETSID	فشل في إنشاء جلسة عملية جديدة.
221	EXIT_CONFIRM	أُلغِي التنفيذ من قبل المستخدم. انظر إعداد سطر الأوامر للنواة systemd.confirm_spawn= في kernel-command-line(7) للحصول على تفاصيل.
222	EXIT_STDERR	فشل في إعداد خرج الخطأ القياسي. انظر StandardError= أعلاه.
224	EXIT_PAM	فشل في إعداد جلسة PAM. انظر PAMName= أعلاه.
225	EXIT_NETWORK	فشل في إعداد تجميع مساحات أسماء الشبكة. انظر PrivateNetwork= أعلاه.
226	EXIT_NAMESPACE	فشل في إعداد تجميع مساحات أسماء الوصل، UTS، أو IPC. انظر ReadOnlyPaths=، ProtectHostname=، PrivateIPC=، والإعدادات المتعلقة أعلاه.
227	EXIT_NO_NEW_PRIVILEGES	فشل في تعطيل الامتيازات الجديدة. انظر NoNewPrivileges=yes أعلاه.
228	EXIT_SECCOMP	فشل في تطبيق مرشحات نداءات النظام. انظر SystemCallFilter= والإعدادات المتعلقة أعلاه.
229	EXIT_SELINUX_CONTEXT	فشل تحديد أو تغيير سياق SELinux. انظر SELinuxContext= أعلاه.
230	EXIT_PERSONALITY	فشل في إعداد نطاق التنفيذ (الشخصية). انظر Personality= أعلاه.
231	EXIT_APPARMOR_PROFILE	فشل في التحضير لتغيير تشكيلة AppArmor. انظر AppArmorProfile= أعلاه.
232	EXIT_ADDRESS_FAMILIES	فشل في تقييد عائلات العناوين. انظر RestrictAddressFamilies= أعلاه.
233	EXIT_RUNTIME_DIRECTORY	فشل في إعداد دليل وقت التشغيل. انظر RuntimeDirectory= والإعدادات ذات الصلة أعلاه.
235	EXIT_CHOWN	فشل في ضبط ملكية المقبس. يُستخدم لوحدات المقابس فقط.
236	EXIT_SMACK_PROCESS_LABEL	فشل في ضبط لصيقة SMACK. انظر SmackProcessLabel= أعلاه.
237	EXIT_KEYRING	فشل في إعداد حلقة مفاتيح النواة.
238	EXIT_STATE_DIRECTORY	فشل في إعداد دليل حالة الوحدة. انظر StateDirectory= أعلاه.
239	EXIT_CACHE_DIRECTORY	فشل في إعداد دليل خبيئة الوحدة. انظر CacheDirectory= أعلاه.
240	EXIT_LOGS_DIRECTORY	فشل في إعداد دليل تسجيل الوحدة. انظر LogsDirectory= أعلاه.
241	EXIT_CONFIGURATION_DIRECTORY	فشل في إعداد دليل ضبط الوحدة. انظر ConfigurationDirectory= أعلاه.
242	EXIT_NUMA_POLICY	فشل في إعداد سياسة ذاكرة NUMA للوحدة. انظر NUMAPolicy= و NUMAMask= أعلاه.
243	EXIT_CREDENTIALS	فشل في إعداد بيانات اعتماد الوحدة. انظر ImportCredential=، LoadCredential= و SetCredential= أعلاه.
245	EXIT_BPF	فشل في تطبيق قيود BPF. انظر RestrictFileSystems= أعلاه.

أخيرًا، تُعرّف أنظمة تشغيل BSD مجموعة من رموز الخروج، وعادة ما تكون مُعرّفة على أنظمة لينكس أيضًا:

جدول 10. رموز خروج BSD

رمز الخروج	الاسم الرمزي	الوصف
64	EX_USAGE	خطأ في استخدام سطر الأوامر
65	EX_DATAERR	خطأ في تنسيق البيانات
66	EX_NOINPUT	يتعذر فتح المدخلات
67	EX_NOUSER	المُرسل إليه مجهول
68	EX_NOHOST	اسم المضيف مجهول
69	EX_UNAVAILABLE	الخدمة غير متاحة
70	EX_SOFTWARE	خطأ داخلي في البرمجيات
71	EX_OSERR	خطأ في النظام (مثلًا، يتعذر التفرع (fork))
72	EX_OSFILE	ملف نظام تشغيل حرج مفقود
73	EX_CANTCREAT	يتعذر إنشاء ملف مخرجات (المستخدم)
74	EX_IOERR	خطأ في الإدخال/الإخراج
75	EX_TEMPFAIL	فشل مؤقت؛ يُدعى المستخدم لإعادة المحاولة
76	EX_PROTOCOL	خطأ عن بُعد في البروتوكول
77	EX_NOPERM	رُفض الإذن
78	EX_CONFIG	خطأ في الضبط

أمثلة¶

مثال 3. استخدام $MONITOR_*

خدمة myfailer.service التي يمكن أن تُشغِّل تبعية OnFailure=.

[Unit]
Description=Service which can trigger an OnFailure= dependency
OnFailure=myhandler.service
[Service]
ExecStart=/bin/myprogram

خدمة mysuccess.service التي يمكن أن تُشغِّل تبعية OnSuccess=.

[Unit]
Description=Service which can trigger an OnSuccess= dependency
OnSuccess=myhandler.service
[Service]
ExecStart=/bin/mysecondprogram

خدمة myhandler.service التي يمكن تشغيلها بواسطة أي من الخدمات أعلاه.

[Unit]
Description=Acts on service failing or succeeding
[Service]
ExecStart=/bin/bash -c "echo $MONITOR_SERVICE_RESULT $MONITOR_EXIT_CODE $MONITOR_EXIT_STATUS $MONITOR_INVOCATION_ID $MONITOR_UNIT"

إذا شُغِّلت الخدمة myfailer.service وأنهت عملها بفشل، فستُطلَق الخدمة myhandler.service وستُضبط متغيرات المراقبة كما يلي:

MONITOR_SERVICE_RESULT=exit-code
MONITOR_EXIT_CODE=exited
MONITOR_EXIT_STATUS=1
MONITOR_INVOCATION_ID=cc8fdc149b2b4ca698d4f259f4054236
MONITOR_UNIT=myfailer.service

إذا شُغِّلت الخدمة mysuccess.service وأنهت عملها بنجاح، فستُطلَق الخدمة myhandler.service وستُضبط متغيرات المراقبة كما يلي:

MONITOR_SERVICE_RESULT=success
MONITOR_EXIT_CODE=exited
MONITOR_EXIT_STATUS=0
MONITOR_INVOCATION_ID=6ab9af147b8c4a3ebe36e7a5f8611697
MONITOR_UNIT=mysuccess.service