-.slice


                     /       \


              /-----/         \--------------\


             /                                \


      system.slice                       user.slice


        /       \                          /      \


       /         \                        /        \


      /           \              user@42.service  user@1000.service


     /             \             Delegate=        Delegate=yes
a.service       b.slice                             /        \
CPUWeight=20   DisableControllers=cpu              /          \


                 /  \                      app.slice      session.slice


                /    \                     CPUWeight=100  CPUWeight=100


               /      \


       b1.service   b2.service


                    CPUWeight=1000

تقبل هذه الخيارات قيمة عددية صحيحة أو السلسلة النصية الخاصة "idle":

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

بالإضافة إلى تخصيص الموارد الذي يقوم به متحكم cpu، يجوز للنواة تقسيم الموارد آليًا بناءً على التجميع حسب معرف الجلسة (session-id)، انظر "ميزة المجموعة التلقائية" (The autogroup feature) في sched(7). تأثير هذه الميزة مشابه لمتحكم cpu بدون ضبط صريح، لذا يجب على المستخدمين توخي الحذر لعدم الخلط بينهما.

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

يخصّص حصة وقت وحدة المعالجة المركزية المحددة للعمليات المنفذة. يأخذ قيمة مئوية، متبوعة بـ "%". تحدد النسبة المئوية مقدار وقت وحدة المعالجة المركزية الذي ستحصل عليه الوحدة كحد أقصى، بالنسبة إلى إجمالي وقت وحدة المعالجة المركزية المتاح على وحدة معالجة مركزية واحدة. استخدم قيمًا أكبر من 100% لتخصيص وقت وحدة المعالجة المركزية على أكثر من وحدة معالجة مركزية واحدة. يتحكم هذا في سمة "cpu.max" في هرمية مجموعات التحكم الموحدة و "cpu.cfs_quota_us" في الهرمية القديمة. للحصول على تفاصيل حول سمات مجموعة التحكم هذه، انظر Control Groups v2[2] و CFS Bandwidth Control[4]. يؤدي تعيين CPUQuota= إلى قيمة فارغة إلى إلغاء تعيين الحصة.

مثال: يضمن CPUQuota=20% ألا تحصل العمليات المنفذة أبدًا على أكثر من 20% من وقت وحدة المعالجة المركزية على وحدة معالجة مركزية واحدة.

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

يخصّص المدة التي تُقاس خلالها حصة وقت وحدة المعالجة المركزية المحددة بواسطة CPUQuota=. يأخذ قيمة مدة زمنية بالثواني، مع لاحقة اختيارية مثل "ms" للملي ثانية (أو "s" للثواني.) الإعداد المبدئي هو 100 ملي ثانية. تُقيد الفترة بالنطاق الذي تدعمه النواة، وهو [1ms, 1000ms]. بالإضافة إلى ذلك، تُعدّل الفترة صعودًا بحيث تكون فترة الحصة أيضًا 1 ملي ثانية على الأقل. يؤدي تعيين CPUQuotaPeriodSec= إلى قيمة فارغة إلى إعادة تعيينه إلى القيمة المبدئية.

يتحكم هذا في الحقل الثاني من سمة "cpu.max" في هرمية مجموعات التحكم الموحدة و "cpu.cfs_period_us" في الهرمية القديمة. للحصول على تفاصيل حول سمات مجموعة التحكم هذه، انظر Control Groups v2[2] و CFS Scheduler[3].

مثال: CPUQuotaPeriodSec=10ms لطلب قياس حصة وحدة المعالجة المركزية في فترات مدتها 10 ملي ثانية.

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

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

لا يضمن تعيين AllowedCPUs= أو StartupAllowedCPUs= استخدام جميع وحدات المعالجة المركزية بواسطة العمليات إذ قد يكون ذلك محدودًا بواسطة الوحدات الأبوية. يُبلّغ عن الضبط الفعلي باسم EffectiveCPUs=.

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

هذا الإعداد مدعوم فقط مع هرمية مجموعات التحكم الموحدة.

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

يُفعّل محاسبة ذاكرة العمليات والنواة لهذه الوحدة. يأخذ وسيطًا منطقيًا (boolean). لاحظ أن تفعيل محاسبة الذاكرة لوحدة واحدة سيؤدي أيضًا إلى تفعيله ضمنيًا لجميع الوحدات الموجودة في الشريحة نفسها ولجميع شرائحها الأبوية والوحدات الموجودة فيها. يمكن التحكم في القيمة المبدئية للنظام لهذا الإعداد باستخدام DefaultMemoryAccounting= في systemd-system.conf(5).

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

يحدد حماية استخدام الذاكرة للعمليات المنفذة في هذه الوحدة. عند استعادة الذاكرة، تُعامل الوحدة كما لو كانت تستخدم ذاكرة أقل مما يؤدي إلى استعادة الذاكرة بشكل تفضيلي من الوحدات غير المحمية. يؤدي استخدام MemoryLow= إلى حماية أضعف حيث قد يُستعاد جزء من الذاكرة لتجنب استدعاء قاتل الذاكرة الممتلئة (OOM killer) في حالة عدم وجود ذاكرة أخرى قابلة للاستعادة.

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

يأخذ حجم الذاكرة بالبايت. إذا كانت القيمة متبوعة بـ K أو M أو G أو T، يُحلّل حجم الذاكرة المحدد على أنه كيلوبايت، أو ميجابايت، أو جيجابايت، أو تيرابايت (بالأساس 1024)، على التوالي. بدلاً من ذلك، يمكن تحديد قيمة مئوية، والتي تُحسب نسبة إلى الذاكرة الفيزيائية المثبتة على النظام. إذا عُيّنت القيمة الخاصة "infinity"، تُحمى جميع الذاكرة المتاحة، والذي قد يكون مفيدًا لوراثة جميع الحماية التي يوفرها الأسلاف دائمًا. يتحكم هذا في سمة مجموعة التحكم "memory.min" أو "memory.low". للحصول على تفاصيل حول سمة مجموعة التحكم هذه، انظر ملفات واجهة الذاكرة[5].

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

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

يحدد حد الخنق (throttling limit) لاستخدام الذاكرة للعمليات المنفذة في هذه الوحدة. قد يتجاوز استخدام الذاكرة الحد إذا كان ذلك لا مفر منه، ولكن العمليات تُبطأ بشدة وتُسحب الذاكرة بشكل هجومي في مثل هذه الحالات. هذه هي الآلية رئيسة للتحكم في استخدام الذاكرة لوحدة ما.

يأخذ حجم الذاكرة بالبايت. إذا كانت القيمة متبوعة بـ K أو M أو G أو T، يُحلّل حجم الذاكرة المحدد على أنه كيلوبايت، أو ميجابايت، أو جيجابايت، أو تيرابايت (بالأساس 1024)، على التوالي. بدلاً من ذلك، يمكن تحديد قيمة مئوية، والتي تُحسب نسبة إلى الذاكرة الفيزيائية المثبتة على النظام. إذا عُيّنت القيمة الخاصة "infinity"، فلن يُطبّق أي خنق للذاكرة. يتحكم هذا في سمة مجموعة التحكم "memory.high". للحصول على تفاصيل حول سمة مجموعة التحكم هذه، انظر ملفات واجهة الذاكرة[5]. يُبلّغ عن الضبط الفعلي باسم EffectiveMemoryHigh= (انظر أيضًا EffectiveMemoryMax=).

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

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

يحدد الحد المطلق لاستخدام الذاكرة للعمليات المنفذة في هذه الوحدة. إذا تعذر احتواء استخدام الذاكرة تحت الحد، يُستدعى قاتل الذاكرة الممتلئة (out-of-memory killer) داخل الوحدة. يُوصى باستخدام MemoryHigh= كآلية تحكم رئيسة واستخدام MemoryMax= كخط دفاع أخير.

يأخذ حجم الذاكرة بالبايت. إذا كانت القيمة متبوعة بـ K أو M أو G أو T، يُحلّل حجم الذاكرة المحدد على أنه كيلوبايت، أو ميجابايت، أو جيجابايت، أو تيرابايت (بالأساس 1024)، على التوالي. بدلاً من ذلك، يمكن تحديد قيمة مئوية، والتي تُحسب نسبة إلى الذاكرة الفيزيائية المثبتة على النظام. إذا عُيّنت القيمة الخاصة "infinity"، فلن يُطبّق أي حد للذاكرة. يتحكم هذا في سمة مجموعة التحكم "memory.max". للحصول على تفاصيل حول سمة مجموعة التحكم هذه، انظر ملفات واجهة الذاكرة[5]. يُبلّغ عن الضبط الفعلي باسم EffectiveMemoryMax= (القيمة هي الحد الأكثر صرامة للوحدة والشرائح الأبوية وتُقيد بالذاكرة الفيزيائية).

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

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

يحدد الحد المطلق لاستخدام مساحة التبديل (swap) للعمليات المنفذة في هذه الوحدة.

يأخذ حجم مساحة التبديل بالبايت. إذا كانت القيمة متبوعة بـ K أو M أو G أو T، يُحلّل حجم مساحة التبديل المحدد على أنه كيلوبايت، أو ميجابايت، أو جيجابايت، أو تيرابايت (بالأساس 1024)، على التوالي. بدلاً من ذلك، يمكن تحديد قيمة مئوية، والتي تُحسب نسبة إلى حجم مساحة التبديل المحدد على النظام. إذا عُيّنت القيمة الخاصة "infinity"، فلن يُطبّق أي حد لمساحة التبديل. تتحكم هذه الإعدادات في سمة مجموعة التحكم "memory.swap.max". للحصول على تفاصيل حول سمة مجموعة التحكم هذه، انظر ملفات واجهة الذاكرة[5].

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

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

يحدد الحد المطلق لاستخدام zswap للعمليات في هذه الوحدة. إن zswap عبارة عن خبيئة مضغوطة خفيفة الوزن لصفحات التبديل. تأخذ الصفحات التي هي في طور النقل إلى مساحة التبديل وتحاول ضغطها في مجمع ذاكرة مستند إلى ذاكرة الوصول العشوائي (RAM) ومخصّص ديناميكيًا. إذا رُطم الحد المحدد، فلن تُخزّن أي إدخالات من هذه الوحدة في المجمع حتى تُسترجع الإدخالات الحالية أو تُكتب على القرص. انظر توثيق Zswap[6] الخاص بالنواة لمزيد من التفاصيل.

يأخذ حجمًا بالبايت. إذا كانت القيمة متبوعة بـ K أو M أو G أو T، يُحلّل الحجم المحدد على أنه كيلوبايت، أو ميجابايت، أو جيجابايت، أو تيرابايت (بالأساس 1024)، على التوالي. إذا عُيّنت القيمة الخاصة "infinity"، فلن يُطبّق أي حد. تتحكم هذه الإعدادات في سمة مجموعة التحكم "memory.zswap.max". للحصول على تفاصيل حول سمة مجموعة التحكم هذه، انظر ملفات واجهة الذاكرة[5].

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

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

يأخذ وسيطًا منطقيًا (boolean). عندما يكون صحيحًا (true)، يُسمح بكتابة الصفحات المخزنة في خبيئة Zswap إلى وحدة التخزين الاحتياطية، وخلاف ذلك يكون خاطئًا (false). القيمة المبدئية هي صحيح (true). يتيح هذا تعطيل إعادة الكتابة (writeback) لصفحات التبديل للتطبيقات كثيفة الإدخال/الإخراج، مع الاحتفاظ بالقدرة على تخزين الصفحات المضغوطة في Zswap. انظر توثيق Zswap[6] الخاص بالنواة لمزيد من التفاصيل.

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

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

لا يضمن تعيين AllowedMemoryNodes= أو StartupAllowedMemoryNodes= استخدام جميع عقد NUMA للذاكرة بواسطة العمليات إذ قد يكون ذلك محدودًا بواسطة الوحدات الأبوية. يُبلّغ عن الضبط الفعلي باسم EffectiveMemoryNodes=.

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

هذا الإعداد مدعوم فقط مع هرمية مجموعات التحكم الموحدة.

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

يُفعّل محاسبة المهام (task accounting) لهذه الوحدة. يأخذ وسيطًا منطقيًا (boolean). في حال تمكينه، ستتتبع النواة إجمالي عدد المهام في الوحدة وأبنائها. يشمل هذا العدد كلاً من خيوط النواة (kernel threads) وعمليات مساحة المستخدم، مع عدّ كل خيط بشكل فردي. لاحظ أن تفعيل محاسبة المهام لوحدة واحدة سيؤدي أيضًا إلى تفعيله ضمنيًا لجميع الوحدات الموجودة في الشريحة نفسها ولجميع شرائحها الأبوية والوحدات الموجودة فيها. يمكن التحكم في القيمة المبدئية للنظام لهذا الإعداد باستخدام DefaultTasksAccounting= في systemd-system.conf(5).

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

يحدد الحد الأقصى لعدد المهام التي يمكن إنشاؤها في الوحدة. يضمن هذا بقاء عدد المهام المحسوبة للوحدة (انظر أعلاه) دون حد معين. يأخذ هذا إما عددًا مطلقًا للمهام أو قيمة مئوية تُحسب بالنسبة إلى الحد الأقصى المهيأ لعدد المهام على النظام. إذا عُيّنت القيمة الخاصة "infinity"، فلن يُطبّق أي حد للمهام. يتحكم هذا في سمة مجموعة التحكم "pids.max". للحصول على تفاصيل حول سمة مجموعة التحكم هذه، انظر متحكم pids[7]. يُبلّغ عن الضبط الفعلي باسم EffectiveTasksMax=.

يمكن التحكم في القيمة المبدئية للنظام لهذا الإعداد باستخدام DefaultTasksMax= في systemd-system.conf(5).

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

يُفعّل حسابات الإدخال/الإخراج الكتلي لهذه الوحدة، إذا كان تدرج مجموعات التحكم الموحد مستخدمًا في النظام. يقبل معاملًا منطقيًا. لاحظ أن تفعيل حسابات الإدخال/الإخراج الكتلي لوحدة واحدة سيُفعّله أيضًا ضمنيًا لجميع الوحدات الموجودة في الشريحة نفسها ولجميع شرائحها الآباء والوحدات المحتواة فيها. يمكن التحكم في المبدأ الافتراضي للنظام لهذا الإعداد عبر DefaultIOAccounting= في systemd-system.conf(5).

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

يضبط الوزن الإجمالي المبدئي للإدخال/الإخراج الكتلي للعمليات المنفذة، إذا كان تدرج مجموعات التحكم الموحد مستخدمًا في النظام. يقبل قيمة وزن واحدة (بين 1 و 10000) لضبط الوزن المبدئي للإدخل/الإخراج الكتلي. يتحكم هذا في سمة مجموعة التحكم "io.weight"، والتي تكون قيمتها المبدئية 100. للتفاصيل حول سمة مجموعة التحكم هذه، انظر ملفات واجهة الإدخال/الإخراج[8]. تُقسّم عرض النطاق الترددي المتاح للإدخال/الإخراج بين جميع الوحدات داخل شريحة واحدة نسبيًا إلى وزن الإدخال/الإخراج الكتلي الخاص بها. الوزن الأعلى يعني عرض نطاق ترددي أكبر للإدخال/الإخراج، والوزن الأقل يعني أقل.

بينما يُطبّق StartupIOWeight= على مرحلتي بدء تشغيل وإيقاف النظام، يُطبّق IOWeight= على وقت التشغيل اللاحق للنظام، وإذا لم يُضبط الأول فإنه يُطبّق أيضًا على مرحلتي بدء التشغيل والإيقاف. يتيح هذا إعطاء الأولوية لخدمات معينة عند بدء التشغيل والإيقاف بشكل مختلف عن وقت التشغيل.

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

يضبط وزن الإدخال/الإخراج الكتلي الإجمالي لكل جهاز للعمليات المنفذة، إذا كان تدرج مجموعات التحكم الموحد مستخدمًا في النظام. يقبل زوجًا مفصولًا بمسافة من مسار ملف وقيمة وزن لتحديد قيمة الوزن الخاصة بالجهاز، بين 1 و 10000. (مثال: "/dev/sda 1000"). يمكن تحديد مسار الملف كمصار لعقدة جهاز كتلي أو كأي ملف آخر، وفي هذه الحالة يُحدّد الجهاز الكتلي الخلفي لنظام ملفات الملف. يتحكم هذا في سمة مجموعة التحكم "io.weight"، والتي تكون قيمتها المبدئية 100. استخدم هذا الخيار لمرات متعددة لضبط الأوزان للأجهزة المتعددة. للتفاصيل حول سمة مجموعة التحكم هذه، انظر ملفات واجهة الإدخال/الإخراج[8].

ينبغي أن تشير عقدة الجهاز المحددة إلى جهاز كتلي مرتبط به مجدول إدخال/إخراج، أي لا ينبغي أن تشير إلى قسم أو أجهزة كتلية تكرارية (loopback)، بل إلى الجهاز المادي الأصيل. عند تحديد مسار لملف عادي أو دليل، يُحاول اكتشاف الجهاز الأصيل الصحيح الذي يدعم نظام ملفات المسار المحدد. يعمل هذا بشكل صحيح فقط في الحالات البسيطة، حيث يوضع نظام الملفات مباشرة على قسم أو جهاز كتلي مادي، أو عند استخدام تعمية بسيطة بنسبة 1:1 باستخدام dm-crypt/LUKS. لا يغطي هذا الاكتشاف التخزين المعقد وبوجه رئيس أجهزة تخزين مصفوفات RAID وإدارة الأحجام الكتلية.

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

يضبط الحد الأقصى لعرض النطاق الترددي الإجمالي للإدخال/الإخراج الكتلي لكل جهاز للعمليات المنفذة، إذا كان تدرج مجموعات التحكم الموحد مستخدمًا في النظام. هذا الحد ليس محافظًا على العمل (not work-conserving) ولا يُسمح للعمليات المنفذة باستخدام المزيد حتى لو كان الجهاز يحتوي على سعة خاملة. يقبل زوجًا مفصولًا بمسافة من مسار ملف وقيمة عرض النطاق الترددي (بالبايت في الثانية) لتحديد عرض النطاق الترددي الخاص بالجهاز. قد يكون مسار الملف مسارًا لعقدة جهاز كتلي، أو كأي ملف آخر وفي هذه الحالة يُستخدم الجهاز الكتلي الخلفي لنظام ملفات الملف. إذا لُحق عرض النطاق الترددي بالحروف K أو M أو G أو T، فإن عرض النطاق الترددي المحدد يُحلّل ككيلوبايت، أو ميجابايت، أو جيجابايت، أو تيرابايت، على التوالي، على أساس 1000. (مثال: "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). يتحكم هذا في سمات مجموعة التحكم "io.max". استخدم هذا الخيار لمرات متعددة لضبط حدود عرض النطاق الترددي للأجهزة المتعددة. للتفاصيل حول سمة مجموعة التحكم هذه، انظر ملفات واجهة الإدخال/الإخراج[8].

تُطبّق قيود مماثلة على اكتشاف الأجهزة الكتلية كما هو الحال في IODeviceWeight=، انظر أعلاه.

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

يضبط الحد الأقصى لعدد عمليات الإدخال/الإخراج في الثانية (IOPS) الإجمالي للإدخال/الإخراج الكتلي لكل جهاز للعمليات المنفذة، إذا كان تدرج مجموعات التحكم الموحد مستخدمًا في النظام. هذا الحد ليس محافظًا على العمل ولا يُسمح للعمليات المنفذة باستخدام المزيد حتى لو كان الجهاز يحتوي على سعة خاملة. يقبل زوجًا مفصولًا بمسافة من مسار ملف وقيمة IOPS لتحديد الـ IOPS الخاص بالجهاز. قد يكون مسار الملف مسارًا لعقدة جهاز كتلي، أو كأي ملف آخر وفي هذه الحالة يُستخدم الجهاز الكتلي الخلفي لنظام ملفات الملف. إذا لُحق الـ IOPS بالحروف K أو M أو G أو T، فإن الـ IOPS المحدد يُحلّل كـ KiloIOPS، أو MegaIOPS، أو GigaIOPS، أو TeraIOPS، على التوالي، على أساس 1000. (مثال: "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). يتحكم هذا في سمات مجموعة التحكم "io.max". استخدم هذا الخيار لمرات متعددة لضبط حدود IOPS لأجهزة متعددة. للتفاصيل حول سمة مجموعة التحكم هذه، انظر ملفات واجهة الإدخال/الإخراج[8].

تُطبّق قيود مماثلة على اكتشاف الأجهزة الكتلية كما هو الحال في IODeviceWeight=، انظر أعلاه.

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

يضبط متوسط زمن الاستجابة المستهدف للإدخال/الإخراج لكل جهاز للعمليات المنفذة، إذا كان تدرج مجموعات التحكم الموحد مستخدمًا في النظام. يقبل مسار ملف وفترة زمنية مفصولين بمسافة لتحديد مستهدف زمن الاستجابة الخاص بالجهاز. (مثال: "/dev/sda 25ms"). يمكن تحديد مسار الملف كمصار لعقدة جهاز كتلي أو كأي ملف آخر، وفي هذه الحالة يُحدّد الجهاز الكتلي الخلفي لنظام ملفات الملف. يتحكم هذا في سمة مجموعة التحكم "io.latency". استخدم هذا الخيار لمرات متعددة لضبط مستهدف زمن الاستجابة لأجهزة متعددة. للتفاصيل حول سمة مجموعة التحكم هذه، انظر ملفات واجهة الإدخال/الإخراج[8].

يتضمن "IOAccounting=yes".

هذه الإعدادات مدعومة فقط في حال استخدام تدرج مجموعات التحكم الموحد.

تُطبّق قيود مماثلة على اكتشاف الأجهزة الكتلية كما هو الحال في IODeviceWeight=، انظر أعلاه.

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

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

يمكن التحكم في المبدأ الافتراضي للنظام لهذا الإعداد عبر DefaultIPAccounting= في systemd-system.conf(5).

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

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

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

من أجل تنفيذ جدار حماية لـ IP يعتمد على القائمة البيضاء (السماح)، يُوصى باستخدام إعداد IPAddressDeny=any على وحدة شريحة ذات مستوى أعلى (مثل الشريحة الجذر -.slice أو الشريحة التي تحتوي على جميع خدمات النظام system.slice — انظر systemd.special(7) للتفاصيل حول وحدات الشرائح هذه)، بالإضافة إلى أسطر IPAddressAllow= فردية لكل خدمة تسمح بالوصول إلى الشبكة للخدمات المعنية، ولها فقط.

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

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

بدلًا من مواصفات عناوين IPv4 أو IPv6 الصريحة وطول البادئة، يمكن استخدام مجموعة صغيرة من الأسماء الرمزية. الأسماء التالية معرّفة:

الجدول 1. أسماء العناوين/الشبكات الخاصة

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

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

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

يصف bind-rule خصائص المقبس مثل address-family و transport-protocol و ip-ports.

bind-rule := { [address-family:][transport-protocol:][ip-ports] | any }

address-family := { ipv4 | ipv6 }

transport-protocol := { tcp | udp }

ip-ports := { ip-port | ip-port-range }

يتوقع خيار address-family الاختياري قيم ipv4 أو ipv6. إذا لم يُحدّد، فستُطابق القاعدة مع كل من عناوين IPv4 و IPv6 وتُطبّق اعتمادًا على حقول المقابس الأخرى، مثل transport-protocol و ip-port.

يتوقع خيار transport-protocol الاختياري أسماء بروتوكولات النقل tcp أو udp. إذا لم يُحدّد، فستُطابق القاعدة مع أي بروتوكول نقل.

يجب أن تقع قيمة ip-port الاختيارية ضمن النطاق من 1...65535 شمولًا، أي أن المنفذ الديناميكي 0 غير مسموح به. يُوصف نطاق المنافذ المتتالية بواسطة ip-port-range := ip-port-low-ip-port-high، حيث يكون ip-port-low أصغر من أو مساويًا لـ ip-port-high وكلاهما يقعان ضمن 1...65535 شمولًا.

يمكن استخدام قيمة خاصة any لتطبيق قاعدة على أي عائلة عناوين، وبروتوكول نقل، وأي منفذ ذي قيمة موجبة.

للسماح بقواعد متعددة، أسند SocketBindAllow= أو SocketBindDeny= لمرات متعددة. لتصفير التعيينات الحالية، مرر إسنادًا فارغًا لـ SocketBindAllow= أو SocketBindDeny=.

الحد الأقصى المسموح به للتعيينات لكل من SocketBindAllow= و SocketBindDeny= هو 128.

نُفّذت هذه الميزة باستخدام خطافات cgroup-bpf من النوع cgroup/bind4 و cgroup/bind6.

لاحظ أن هذه الإعدادات تُطبّق على أي استدعاء لنظام bind(2) بواسطة عمليات الوحدة، بغض النظر عن مساحة اسم الشبكة الموضوعة فيها. أو بعبارة أخرى: تغيير مساحة اسم الشبكة ليس آلية مناسبة للهروب من هذه القيود المفروضة على bind().

أمثلة:

...
# Allow binding IPv6 socket addresses with a port greater than or equal to 10000.
[Service]
SocketBindAllow=ipv6:10000-65535
SocketBindDeny=any
...
# Allow binding IPv4 and IPv6 socket addresses with 1234 and 4321 ports.
[Service]
SocketBindAllow=1234
SocketBindAllow=4321
SocketBindDeny=any
...
# Deny binding IPv6 socket addresses.
[Service]
SocketBindDeny=ipv6
...
# Deny binding IPv4 and IPv6 socket addresses.
[Service]
SocketBindDeny=any
...
# Allow binding only over TCP
[Service]
SocketBindAllow=tcp
SocketBindDeny=any
...
# Allow binding only over IPv6/TCP
[Service]
SocketBindAllow=ipv6:tcp
SocketBindDeny=any
...
# Allow binding ports within 10000-65535 range over IPv4/UDP.
[Service]
SocketBindAllow=ipv4:udp:10000-65535
SocketBindDeny=any
...

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

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

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

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

لا تُعامل واجهة التكرار المحلي ("lo") بأي طريقة خاصة، يجب عليك تهيئتها صراحة في ملف الوحدة.

مثال 1: قائمة مسموح بها

RestrictNetworkInterfaces=eth1
RestrictNetworkInterfaces=eth2

ستتمكن البرامج الموجودة في الوحدة فقط من استخدام واجهتي الشبكة eth1 و eth2.

مثال 2: قائمة ممنوعة

RestrictNetworkInterfaces=~eth1 eth2

ستتمكن البرامج الموجودة في الوحدة من استخدام أي واجهة شبكة باستثناء eth1 و eth2.

مثال 3: مختلط

RestrictNetworkInterfaces=eth1 eth2
RestrictNetworkInterfaces=~eth1

ستتمكن البرامج الموجودة في الوحدة فقط من استخدام واجهة الشبكة eth2.

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

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

إنه مفيد بشكل خاص لحصر عملية ما في VRF، عندما لا يدمج البرنامج دعمًا أصيلًا لها. وهو يعادل تشغيل البرنامج باستخدام ip vrf exec.

في الأنظمة التي تستخدم nss-resolve، يمكن اختيار الواجهة المستخدمة لحل DNS باستخدام متغير البيئة SYSTEMD_NSS_RESOLVE_IFINDEX.

نُفّذت الميزة باستخدام خطافات cgroup-bpf من النوع cgroup/sock_create.

مثال:

[Service]
BindNetworkInterface=vrf-mgmt

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

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

يتوقع هذا الخيار قائمة مفصولة بمسافات بيضاء من تعريفات مجموعات NFT. يتكون كل تعريف من صف مفصول بنقطتين لنوع المصدر (أحد الخيارات "cgroup" أو "user" أو "group")، وعائلة عناوين NFT (إحدى الخيارات "arp" أو "bridge" أو "inet" أو "ip" أو "ip6" أو "netdev")، واسم الجدول واسم المجموعة. يجب أن تتوافق أسماء الجداول والمجموعات مع القيود المعجمية لأسماء جداول NFT. يجب أن يطابق نوع العنصر المستخدم في مرشح NFT النوع المضمن في التوجيه ("cgroup" أو "user" أو "group") كما هو موضح في الجدول أدناه. عند تحقيق مجموعة تحكم أو وحدة، سيُلحق المعرف المطابق بمجموعات NFT وسيُزال عند إزالة مجموعة التحكم أو الوحدة. يقوم systemd فقط بإدراج العناصر في المجموعات (أو إزالتها منها)، لذا يجب إعداد قواعد وجداول ومجموعات NFT ذات الصلة في مكان آخر مسبقًا. سيُتجاهل الفشل في إدارة المجموعات.

الجدول 2. قيم source type المعرّفة

إذا أُعيد تثبيت قواعد جدار الحماية بحيث دُمرت محتويات مجموعات NFT، يمكن استخدام الأمر systemctl daemon-reload لإعادة ملء المجموعات.

مثال:

[Unit]
NFTSet=cgroup:inet:filter:my_service user:inet:filter:serviceuser

قواعد NFT المقابلة:

table inet filter {


        set my_service {


                type cgroupsv2


        }


        set serviceuser {


                typeof meta skuid


        }


        chain x {


                socket cgroupv2 level 2 @my_service accept


                drop


        }


        chain y {


                meta skuid @serviceuser accept


                drop


        }
}

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

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

تُطبّق المرشحات المهيأة بهذا الخيار على جميع المقابس التي أنشأتها عمليات هذه الوحدة (أو المرتبطة بها في حالة وحدات المقابس). تُحمّل المرشحات بالإضافة إلى مرشحات أي من وحدات الشرائح الآباء التي قد تكون هذه الوحدة عضوًا فيها بالإضافة إلى أي مرشحات IPAddressAllow= و IPAddressDeny= في أي من هذه الوحدات. بشكل مبدئي، لا توجد مرشحات محددة.

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

إذا كان المسار BPF_FS_PROGRAM_PATH في تعيين IPIngressFilterPath= يُعالج بالفعل بواسطة خطاف الدخول BPFProgram=، على سبيل المثال BPFProgram=ingress:BPF_FS_PROGRAM_PATH، فسيظل التعيين صالحًا وسيُربط البرنامج بمجموعة تحكم (cgroup). ينطبق الشيء نفسه على مسار IPEgressFilterPath= وخطاف الخروج egress.

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

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

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

يتكون توصيف برنامج BPF من زوج من نوع برنامج BPF ومسار البرنامج في نظام الملفات، مع استخدام ":" كفاصل: type:program-path.

نوع برنامج BPF مكافئ لنوع ربط BPF المستخدم في bpftool(8) وقد يكون أحد الأنواع التالية: egress، أو ingress، أو sock_create، أو sock_ops، أو device، أو bind4، أو bind6، أو connect4، أو connect6، أو post_bind4، أو post_bind6، أو sendmsg4، أو sendmsg6، أو sysctl، أو recvmsg4، أو recvmsg6، أو getsockopt، أو setsockopt.

يجب أن يكون مسار البرنامج المحدد مسارًا مطلقًا يشير إلى عقدة فهرسة (inode) لبرنامج BPF في نظام ملفات bpffs (مما يعني عمومًا أنه يجب أن يبدأ بـ /sys/fs/bpf/). وإذا كان البرنامج المحدد غير موجود (أي لم يُرفع إلى نظام BPF الفرعي للنواة بعد)، فلن يُثبّت ولكن تنشيط الوحدة سيستمر (سيُطبع تحذير في السجلات).

ضبط BPFProgram= على قيمة فارغة يجعل التعيينات السابقة غير فعالة.

التعيينات المتعددة لنفس زوج نوع/مسار البرنامج لها نفس تأثير التعيين الواحد: سيرتبط البرنامج مرة واحدة فقط.

إذا كان خطاف BPF egress المثبت على مسار program-path يُعالج بالفعل بواسطة IPEgressFilterPath=، فسيُعتبر تعيين BPFProgram= صالحًا وسيُربط BPFProgram= بمجموعة تحكم (cgroup). وبالمثل بالنسبة لخطاف ingress وتعيين IPIngressFilterPath=.

ترتبط برامج BPF الممررة مع BPFProgram= بمجموعة تحكم الوحدة باستخدام علم ربط BPF‏ multi، مما يسمح بمزيد من الارتباطات من نفس النوع type داخل هرمية مجموعات التحكم التي ترأسها مجموعة تحكم الوحدة.

أمثلة:

BPFProgram=egress:/sys/fs/bpf/egress-hook
BPFProgram=bind6:/sys/fs/bpf/sock-addr-hook

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

عندما ينبغي عدم السماح بالوصول إلى جميع الأجهزة المادية، يمكن استخدام PrivateDevices= بدلاً من ذلك. انظر systemd.exec(5).

محدد عقدة الجهاز هو إما مسار إلى عقدة جهاز في نظام الملفات يبدأ بـ /dev/، أو سلسلة نصية تبدأ بـ "char-" أو "block-" تليها اسم مجموعة أجهزة، كما هو مدرج في /proc/devices. الخيار الأخير مفيد لإدراج جميع الأجهزة الحالية والمستقبلية التي تنتمي إلى مجموعة أجهزة معينة في القائمة البيضاء دفعة واحدة. وتُطابق مجموعة الأجهزة وفقًا لقواعد مطابقة أسماء الملفات (globbing)، وبالتالي يمكنك استخدام المحارف النائبة "*" و "?". (لاحظ أن محارف المطابقة هذه غير متاحة لمواصفات مسار عقدة الجهاز!) لمطابقة عقد الأجهزة حسب الرقم الرئيس أو الثانوي الرقمي، استخدم مسارات عقد الأجهزة في الدليلين /dev/char/ و /dev/block/. ومع ذلك، فإن مطابقة الأجهزة حسب الرقم الرئيس أو الثانوي لا يُوصى بها عمومًا لأن التعيينات ليست مستقرة ولا قابلة للنقل بين الأنظمة أو إصدارات النواة المختلفة.

أمثلة: /dev/sda5 هو مسار لعقدة جهاز، يشير إلى جهاز كتلي من نوع ATA أو SCSI. و "char-pts" و "char-alsa" هما محددان لجميع أجهزة TTY الزائفة وجميع أجهزة صوت ALSA، على التوالي. و "char-cpu/*" هو محدد يطابق جميع مجموعات الأجهزة ذات الصلة بالمعالج.

لاحظ أن قوائم السماح المعرفة بهذه الطريقة يجب أن تشير فقط إلى مجموعات الأجهزة القابلة للحل في وقت بدء تشغيل الوحدة. وأي مجموعات أجهزة غير قابلة للحل في ذلك الوقت لا تُضاف إلى قائمة السماح للأجهزة. وللتغلب على هذا القيد، فكر في توسيع وحدات الخدمة بزوج من السطور After=modprobe@xyz.service و Wants=modprobe@xyz.service التي تحمّل وحدة النواة اللازمة التي تنفذ مجموعة الأجهزة إذا كانت مفقودة. مثال:

...
[Unit]
Wants=modprobe@loop.service
After=modprobe@loop.service
[Service]
DeviceAllow=block-loop
DeviceAllow=/dev/loop-control
...

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

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

strict

closed

auto

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

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

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

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

ينبغي توخي حذر خاص عند الاعتماد على تعيين الشريحة المبدئي في وحدات الخدمة المقوْلَبة التي ضُبط فيها DefaultDependencies=no، انظر systemd.service(5)، قسم "الاعتمادات المبدئية" للحصول على التفاصيل.

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

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

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

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

يمكن تحديد أسماء المتحكمات التالية: cpu، و cpuset، و io، و memory، و pids، و bpf-firewall، و bpf-devices، و bpf-foreign، و bpf-socket-bind، و bpf-restrict-network-interfaces، و bpf-bind-network-interface.

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

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

لمزيد من التفاصيل حول نموذج التفويض، راجع واجهات برمجة تطبيقات مجموعة التحكم والتفويض[12].

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

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

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

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

قد لا يكون من الممكن تعطيل متحكم بعد بدء تشغيل الوحدات، إذا كانت الوحدة أو أي ابن للوحدة المعنية يفوض متحكمات لأبنائه، لأن أي شجرة فرعية مفوضة من هرمية cgroup غير مدارة بواسطة systemd.

يمكن تحديد أسماء المتحكمات التالية: cpu، و cpuset، و io، و memory، و pids، و bpf-firewall، و bpf-devices، و bpf-foreign، و bpf-socket-bind، و bpf-restrict-network-interfaces، و bpf-bind-network-interface.

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

عند ضبطه على kill، تصبح الوحدة مرشحة للمراقبة بواسطة systemd-oomd. وإذا تجاوزت مجموعة التحكم الحدود التي حددها oomd.conf(5) أو تهيئة الوحدة، فسيختار systemd-oomd مجموعة تحكم منحدرة ويرسل إشارة SIGKILL إلى جميع العمليات التي تحتها. يمكنك العثور على مزيد من التفاصيل حول المرشحين وسلوك الإنهاء في systemd-oomd.service(8) و oomd.conf(5).

يؤدي ضبط أي من هذه الخصائص على kill أيضًا إلى نشوء اعتمادات After= و Wants= على systemd-oomd.service ما لم يكن DefaultDependencies=no.

عند ضبطه على auto، لن يستخدم systemd-oomd بيانات مجموعة التحكم هذه بشكل نشط للمراقبة والكشف. ومع ذلك، إذا كان لمجموعة تحكم أصلية إحدى هذه الخصائص مضبوطة على kill، فإن الوحدة المضبوطة على auto يمكن أن تظل مرشحة للإنهاء بواسطة systemd-oomd.

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

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

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

عند حساب المرشحين لتخفيف استخدام مساحة التبديل (swap)، سيحترم systemd-oomd هذه السمات الممتدة فقط إذا كانت مجموعة تحكم الوحدة مملوكة للمستخدم الجذر (root).

عند حساب المرشحين لتخفيف ضغط الذاكرة، سيحترم systemd-oomd هذه السمات الممتدة فقط إذا كانت مجموعة تحكم الوحدة مملوكة للمستخدم الجذر (root)، أو إذا كان مالك مجموعة تحكم الوحدة ومالك مجموعة التحكم الأصلية المراقبة هما نفسهما. على سبيل المثال، إذا كان systemd-oomd يحسب المرشحين لـ -.slice، فإن السمات الممتدة المضبوطة على منحدرات /user.slice/user-1000.slice/user@1000.service/ ستُتجاهل لأن المنحدرين مملوكون لمعرف المستخدم UID 1000، و -.slice مملوكة لمعرف المستخدم UID 0. ولكن، إذا كان يحسب المرشحين لـ /user.slice/user-1000.slice/user@1000.service/، فستُحترم السمات الممتدة المضبوطة على المنحدرين.

إذا ضُبطت هذه الخاصية على avoid، فسينقل مدير الخدمة هذا إلى systemd-oomd، والذي سيختار مجموعة التحكم هذه فقط إذا لم يكن هناك مرشحون آخرون قابلون للتطبيق.

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

يُوصى باستخدام avoid و omit باعتدال، لأنه يمكن أن يؤثر سلبًا على سلوك الإنهاء لـ systemd-oomd. لاحظ أيضًا أن هذه السمات الممتدة لا تُطبق بشكل تداخلي على مجموعات التحكم الموجودة أسفل مجموعة تحكم هذه الوحدة.

القيمة المبدئية هي none مما يعني أن systemd-oomd سيرتب مجموعة تحكم هذه الوحدة كما هو محدد في systemd-oomd.service(8) و oomd.conf(5).

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

لاحظ أن الخدمات حرة في استخدام متغيري البيئة هذين، ولكن ليس هناك مشكلة إذا تجاهلتهما. يجب تنفيذ معالجة ضغط الذاكرة بشكل فردي في كل خدمة، وعادة ما تعني أشياء مختلفة للبرمجيات المختلفة. لمزيد من التفاصيل حول معالجة ضغط الذاكرة، انظر معالجة ضغط الذاكرة في systemd[13].

الخدمات المنفذة باستخدام sd-event(3) يمكنها استخدام sd_event_add_memory_pressure(3) لمراقبة أحداث ضغط الذاكرة ومعالجتها.

إذا لم يُضبط صراحةً، فإنه يؤول مبدئيًا إلى إعداد DefaultMemoryPressureWatch= في systemd-system.conf(5).

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

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

عندما يتعامل systemd-coredump مع تفريغ ذاكرة لعملية من حاوية، إذا كانت العملية القائدة للحاوية منحدرة من مجموعة تحكم تستخدم CoredumpReceive=yes و Delegate=yes، فسيحاول systemd-coredump إعادة توجيه تفريغ الذاكرة إلى systemd-coredump داخل الحاوية. انظر أيضًا systemd-coredump(8).

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