SYSTEMD.RESOURCE-CONTROL(5)

الاسم
systemd.resource-control - إعدادات وحدة التحكم في الموارد

موجز

slice.slice, scope.scope, service.service, socket.socket, mount.mount, swap.swap

الوصف

تتشارك ملفات ضبط الوحدات للخدمات (services)، والشرائح (slices)، والنطاقات (scopes)، والقباسات (sockets)، ونقاط الوصل (mount points)، وأجهزة التبديل (swap devices) في مجموعة فرعية من خيارات الضبط للتحكم في موارد العمليات المولدة. يعتمد هذا داخليًا على مفهوم مجموعات التحكم في لينكس (cgroups) في النواة لتنظيم العمليات في شجرة هرمية من مجموعات مسماة لغرض إدارة الموارد.

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

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

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

المتحكمات في هرمية cgroup هرمية الشكل، ويتحقق التحكم في الموارد عن طريق توزيع تعيينات الموارد بين الأشقاء في فروع هرمية cgroup. لا توجد حاجة إلى تمكين متحكم cgroup صراحة لوحدة ما. سيصدر systemd تعليمات للنواة لتمكين متحكم لوحدة معينة عندما تحتوي هذه الوحدة على ضبط لمتحكم معين. على سبيل المثال، عند تعيين CPUWeight=، سيُمكّن متحكم cpu، وعند تعيين TasksMax=، سيُمكّن متحكم pids. بالإضافة إلى ذلك، يمكن أيضًا تمكين متحكمات مختلفة صراحة عبر إعدادات MemoryAccounting=/TasksAccounting=/IOAccounting=. ونظرًا لآلية عمل هرمية cgroup، ستُمكّن المتحكمات آليًا لجميع الوحدات الأبوية ولأي وحدات شقيقة بدءًا من أدنى مستوى يُمكّن فيه المتحكم. وقد تخضع الوحدات التي مُكّن لها متحكم للتحكم في الموارد حتى لو لم يكن لديها أي ضبط صريح.

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

يمكن تعطيل المتحكمات لأجزاء من هرمية cgroup باستخدام DisableControllers= (انظر أدناه).

مثال 1. تمكين وتعطيل المتحكمات

                          -.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

في هذه الهرمية، يُكّن متحكم cpu لجميع الوحدات الموضحة باستثناء b1.service و b2.service. نظرًا لعدم وجود ضبط صريح لـ system.slice و user.slice، ستُقسّم موارد وحدة المعالجة المركزية (CPU) بالتساوي بينهما. وبالمثل، تُخصّص الموارد بالتساوي بين أبناء user.slice وبين الشرائح الأبناء تحت user@1000.service. بفرض عدم وجود ضبط إضافي للموارد أو التفويض أسفل الشرائح app.slice أو session.slice، فلن يُكّن متحكم cpu للوحدات في تلك الشرائح وستُخصّص موارد وحدة المعالجة المركزية بشكل أكبر باستخدام آليات أخرى، مثل الاعتماد على مستويات الجودة (nice levels). يمتلك مدير المستخدم 42 التفويض مُمكّنًا دون أي متحكمات، أي يمكنه التلاعب بشجرته الفرعية في هرمية cgroup، ولكن دون التحكم في الموارد.

في الشريحة system.slice، تُقسّم موارد وحدة المعالجة المركزية بنسبة 1:6 للخدمة a.service، و 5:6 للشريحة b.slice، لأن الشريحة b.slice تحصل على القيمة المبدئية 100 لـ cpu.weight عندما لا يكون CPUWeight= مُعيّنًا.

أُبطل إعداد CPUWeight= في الخدمة b2.service بواسطة DisableControllers= في الشريحة b.slice، لذا لن يُمكّن متحكم cpu للخدمات b1.service و b2.service، وستُخصّص موارد وحدة المعالجة المركزية بشكل أكبر باستخدام آليات أخرى، مثل الاعتماد على مستويات الجودة (nice levels).

  ضبط عناصر التحكم في الموارد لمجموعة من الوحدات ذات الصلة

كما هو موضح في systemd.unit(5)، يمكن تعيين الإعدادات المدرجة هنا من خلال الملف رئيس لوحدة ما وقصاصات الإسقاط (drop-in) في أدلة *.d/. تتضمن قائمة الأدلة التي يُبحث فيها عن قصاصات الإسقاط أسماءً تشكّلت عن طريق اقتطاع اسم الوحدة بشكل متكرر بعد كل الشرطات. هذا مناسب بشكل خاص لتعيين حدود الموارد لمجموعة من الوحدات ذات الأسماء المتشابهة.

على سبيل المثال، يحصل كل مستخدم على شريحته الخاصة user-nnn.slice. يمكن وضع قصاصات الإسقاط ذات الضبط المحلي والتي تؤثر على المستخدم 1000 في /etc/systemd/system/user-1000.slice، أو /etc/systemd/system/user-1000.slice.d/*.conf، وأيضًا في /etc/systemd/system/user-.slice.d/*.conf. وينطبق هذا الدليل الأخير على جميع شرائح المستخدمين.

انظر واجهات مجموعات التحكم الجديدة[1] للحصول على مقدمة حول كيفية الاستفادة من واجهات برمجة تطبيقات (APIs) التحكم في الموارد من البرامج.

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

تُضاف التبعيات التالية ضمنيًا:

    • تكتسب الوحدات التي عُيّن لها إعداد Slice= آليًا اعتماديات Requires= و After= على وحدة الشريحة المحددة.

الخيارات

يمكن أن تحتوي الوحدات من الأنواع المدرجة أعلاه على إعدادات لضبط التحكم في الموارد:

  التحكم في وحدة المعالجة المركزية (CPU)

CPUWeight=weight, StartupCPUWeight=weight
    تتحكم هذه الإعدادات في متحكم cpu في الهرمية الموحدة.

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

        • في حالة تعيين قيمة عددية، خصص وزن وقت وحدة المعالجة المركزية المحدد للمعالجات المنفذة، إذا استخدمت التسلسل الهرمي لمجموعة التحكم الموحدة في النظام. تتحكم هذه الخيارات في سمة مجموعة التحكم ”cpu.weight“ . النطاق المسموح به هو من 1 إلى 10000. القيمة المبدئية هي غير محددة، لكن القيمة المبدئية للنواة هي 100. للحصول على تفاصيل حول سمة مجموعة التحكم هذه، انظر مجموعات التحكم v2[2] و مجدول CFS[3]. يقسم وقت وحدة المعالجة المركزية المتاح بين جميع الوحدات داخل شريحة واحدة وفقًا لوزن وقت وحدة المعالجة المركزية الخاص بها . يعني الوزن الأعلى مزيدًا من وقت وحدة المعالجة المركزية، في حين يعني الوزن الأقل وقتًا أقل.

        • إذا عُيّن إلى السلسلة النصية الخاصة "idle"، فإنه يعلّم cgroup لـ "الجدولة الخاملة"، مما يعني أنها ستحصل على موارد وحدة المعالجة المركزية فقط عندما لا توجد عمليات غير معلمة بهذه الطريقة لتنفيذها في cgroup هذه أو أشقائها. يتوافق هذا الإعداد مع سمة cgroup‏ "cpu.idle".

        لاحظ أن هذه القيمة لها تأثير فقط على cgroup-v2، وبالنسبة لـ cgroup-v1 فإنها تعادل الحد الأدنى للوزن.

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

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

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

CPUQuota=
    تحكم هذا الإعداد في متحكم cpu في الهرمية الموحدة.

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

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

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

CPUQuotaPeriodSec=
    تحكم هذا الإعداد في متحكم cpu في الهرمية الموحدة.

    يخصّص المدة التي تُقاس خلالها حصة وقت وحدة المعالجة المركزية المحددة بواسطة 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=
    تحكم هذا الإعداد في متحكم cpuset في الهرمية الموحدة.

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

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

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

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

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

  محاسبة الذاكرة والتحكم فيها

MemoryAccounting=
    تحكم هذا الإعداد في متحكم memory في الهرمية الموحدة.

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

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

MemoryMin=bytes, MemoryLow=bytes, StartupMemoryLow=bytes
    تتحكم هذه الإعدادات في متحكم memory في الهرمية الموحدة.

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

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

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

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

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

MemoryHigh=bytes, StartupMemoryHigh=bytes
    تتحكم هذه الإعدادات في متحكم memory في الهرمية الموحدة.

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

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

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

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

MemoryMax=bytes, StartupMemoryMax=bytes
    تتحكم هذه الإعدادات في متحكم memory في الهرمية الموحدة.

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

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

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

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

MemorySwapMax=bytes, StartupMemorySwapMax=bytes
    تتحكم هذه الإعدادات في متحكم memory في الهرمية الموحدة.

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

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

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

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

MemoryZSwapMax=bytes, StartupMemoryZSwapMax=bytes
    تتحكم هذه الإعدادات في متحكم memory في الهرمية الموحدة.

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

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

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

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

MemoryZSwapWriteback=
    تحكم هذا الإعداد في متحكم memory في الهرمية الموحدة.

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

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

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

AllowedMemoryNodes=, StartupAllowedMemoryNodes=
    تتحكم هذه الإعدادات في متحكم cpuset في الهرمية الموحدة.

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

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

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

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

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

CPUSetPartition=
    يضبط نوع قسم cpuset للعمليات المنفذة. يأخذ إحدى القيم "member" أو "root" أو "isolated". يتحكم هذا الإعداد في سمة cgroup "cpuset.cpus.partition".

    عند الضبط على "member"، يعمل cpuset في الوضع العادي. يُنشئ "root" جذر قسم، يمكنه تقسيم وحدات المعالجة المركزية (CPUs) بين مجموعات cgroup الفرعية. يوفر "isolated" عزلًا كاملاً لوحدة المعالجة المركزية، وهو مفيد لأعباء العمل في الوقت الفعلي التي تتطلب موارد CPU مخصصة دون تداخل من عمليات أخرى. المبدئي هو المبدئي للنواة، وهو "member". لمزيد من التفاصيل حول سمة مجموعة التحكم هذه، راجع Control Groups v2[2].

    يتطلب هذا الإعداد ضبط AllowedCPUs= أيضًا.

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

  محاسبة العمليات والتحكم فيها

TasksAccounting=
    تحكم هذا الإعداد في متحكم pids في الهرمية الموحدة.

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

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

TasksMax=N
    تحكم هذا الإعداد في متحكم pids في الهرمية الموحدة.

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

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

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

  محاسبة الإدخال/الإخراج والتحكم فيه

IOAccounting=
    تحكم هذا الإعداد في متحكم io في الهرمية الموحدة.

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

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

IOWeight=weight, StartupIOWeight=weight
    تتحكم هذه الإعدادات في متحكم الإدخال/الإخراج io في التدرج الموحد.

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

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

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

IODeviceWeight=device weight
    تحكم هذا الإعداد في متحكم io في الهرمية الموحدة.

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

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

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

IOReadBandwidthMax=device bytes, IOWriteBandwidthMax=device bytes
    تتحكم هذه الإعدادات في متحكم الإدخال/الإخراج io في التدرج الموحد.

    يضبط الحد الأقصى لعرض النطاق الترددي الإجمالي للإدخال/الإخراج الكتلي لكل جهاز للعمليات المنفذة، إذا كان تدرج مجموعات التحكم الموحد مستخدمًا في النظام. هذا الحد ليس محافظًا على العمل (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.

IOReadIOPSMax=device IOPS, IOWriteIOPSMax=device IOPS
    تتحكم هذه الإعدادات في متحكم الإدخال/الإخراج io في التدرج الموحد.

    يضبط الحد الأقصى لعدد عمليات الإدخال/الإخراج في الثانية (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.

IODeviceLatencyTargetSec=device target
    تحكم هذا الإعداد في متحكم io في الهرمية الموحدة.

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

    يتضمن "IOAccounting=yes".

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

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

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

  حسابات الشبكة والتحكم فيها

IPAccounting=
    يقبل معاملًا منطقيًا. إذا كان صحيحًا (true)، فسيُفعّل حسابات حركة مرور الشبكة لبروتوكولي IPv4 و IPv6 للحزم المرسلة أو المستقبلة بواسطة الوحدة. عند تفعيل هذا الخيار، تُحسب جميع مقابس IPv4 و IPv6 التي أنشأتها أي عملية في الوحدة.

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

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

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

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

IPAddressAllow=ADDRESS[/PREFIXLENGTH]..., IPAddressDeny=ADDRESS[/PREFIXLENGTH]...
    يُفعّل ترشيح حركة مرور الشبكة لحزم IP المرسلة والمستقبلة عبر مقابس AF_INET و AF_INET6. تأخذ كلتا التوجيهين قائمة مفصولة بمسافات من عناوين IPv4 أو IPv6، وكل منها يمكن أن يُلحق اختياريًا بطول بادئة العنوان بالبتات بعد محرف "/". إذا حُذفت اللاحقة، يُعتبر العنوان عنوان مستضيف، أي أن المرشح يغطي العنوان بأكمله (32 بت لـ IPv4، و 128 بت لـ IPv6).

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

        • يُمنح الوصول عندما يطابق عنوان IP المفحوص مدخلًا في قائمة IPAddressAllow=.

        • خلاف ذلك، يُرفض الوصول عندما يطابق عنوان IP المفحوص مدخلًا في قائمة IPAddressDeny=.

        • خلاف ذلك، يُمنح الوصول.

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

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

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

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

    الجدول 1. أسماء العناوين/الشبكات الخاصة
    الاسم الرمزي | التعريف | المعنى
    any | 0.0.0.0/0 ::/0 | أي مضيف
    localhost | 127.0.0.0/8 ::1/128 | جميع العناوين على التكرار المحلي
    link-local | 169.254.0.0/16 fe80::/64 | جميع عناوين IP المحلية للوصلة (link-local)
    multicast | 224.0.0.0/4 ff00::/8 | جميع عناوين البث المتعدد لـ IP

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

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

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

SocketBindAllow=bind-rule, SocketBindDeny=bind-rule
    يُهيئ القيود المفروضة على قدرة عمليات الوحدة على استدعاء bind(2) على مقبس. تُعرّف قواعد السماح والمنع التي تقيد العناوين التي قد يُربط بها المقبس.

    يصف 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.

        • يُسمح بالربط بمقبس عندما يطابق عنوان المقبس مدخلًا في قائمة SocketBindAllow=.

        • خلاف ذلك، يُرفض الربط عندما يطابق عنوان المقبس مدخلًا في قائمة SocketBindDeny=.

        • خلاف ذلك، يُسمح بالربط.

    نُفّذت هذه الميزة باستخدام خطافات 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.

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

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

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

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

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

        RestrictNetworkInterfaces=eth1
        RestrictNetworkInterfaces=eth2

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

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

        RestrictNetworkInterfaces=~eth1 eth2

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

    مثال 3: مختلط

        RestrictNetworkInterfaces=eth1 eth2
        RestrictNetworkInterfaces=~eth1

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

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

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

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

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

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

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

    مثال:

        [Service]
        BindNetworkInterface=vrf-mgmt

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

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

NFTSet=family:table:set
    يوفر هذا الإعداد طريقة لدمج معرفات المجموعات (cgroup) والمستخدمين والمجموعات الديناميكية في قواعد جدار الحماية باستخدام مجموعات NFT[9]. تتمثل فائدة استخدام هذا الإعداد في القدرة على استخدام المعرفات كمحددات في قواعد جدار الحماية بسهولة، وهذا بدوره يسمح بترشيح أكثر دقة. تستخدم قواعد NFT لمطابقة cgroup معرفات cgroup رقمية، والتي تتغير في كل مرة تُعاد فيها تشغيل الخدمة، مما يجعل استخدامها صعبًا في بيئة systemd بخلاف ذلك. المعرفات الديناميكية والعشوائية المستخدمة بواسطة DynamicUser= يمكن دمجها أيضًا مع هذا الإعداد.

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

    الجدول 2. قيم source type المعرّفة
    نوع المصدر | الوصف | اسم نوع NFT المقابل
    "cgroup" | معرف مجموعة التحكم (control group ID) | "cgroupsv2"
    "user" | معرف المستخدم (user ID) | "meta skuid"
    "group" | معرف المجموعة (group ID) | "meta skgid"

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

    مثال:

        [Service]
        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.

  برامج BPF

IPIngressFilterPath=BPF_FS_PROGRAM_PATH, IPEgressFilterPath=BPF_FS_PROGRAM_PATH
    يضيف مرشحات مخصصة لحركة مرور الشبكة المنفذة كبرامج BPF، وتُطبّق على جميع حزم IP المرسلة والمستقبلة عبر مقابس AF_INET و AF_INET6. يقبل مسارًا مطلقًا لبرنامج BPF مثبت في نظام الملفات الافتراضي لـ BPF (/sys/fs/bpf/).

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

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

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

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

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

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

BPFProgram=type:program-path
    يسمح BPFProgram= بربط برامج BPF مخصصة بمجموعة التحكم (cgroup) الخاصة بالوحدة. (هذا يعمم الوظيفة المعروضة عبر IPEgressFilterPath= و IPIngressFilterPath= لخطافات أخرى.) خطافات Cgroup-bpf في شكل برامج BPF محملة في نظام ملفات BPF تُرتبط بأعلام ربط cgroup-bpf تحددها الوحدة. لمعرفة التفاصيل حول أنواع وأعلام الربط، انظر bpf.h[10]. راجع أيضًا توثيق BPF العام[11].

    يتكون توصيف برنامج 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.

  الوصول إلى الأجهزة

DeviceAllow=
    التحكم في وصول العمليات المنفذة إلى عقد أجهزة محددة. يأخذ سلسلتين نصيتين مفصولتين بمسافة: محدد عقدة الجهاز يليه مزيج من r أو w أو m للتحكم في القراءة (reading)، أو الكتابة (writing)، أو إنشاء عقد الأجهزة المحددة بواسطة الوحدة (mknod)، على التوالي. نُفذت هذه الوظيفة باستخدام ترشيح eBPF.

    عندما ينبغي عدم السماح بالوصول إلى جميع الأجهزة المادية، يمكن استخدام 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.

DevicePolicy=auto|closed|strict
    التحكم في سياسة السماح بالوصول إلى الأجهزة:

    strict
        يعني السماح فقط بأنواع الوصول المحددة صراحةً.

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

    closed
        بالإضافة إلى ذلك، يسمح بالوصول إلى الأجهزة الزائفة القياسية بما في ذلك /dev/null و /dev/zero و /dev/full و /dev/random و /dev/urandom.

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

    auto
        بالإضافة إلى ذلك، يسمح بالوصول إلى جميع الأجهزة إذا لم يكن هناك DeviceAllow= صريح. هذا هو المبدئي.

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

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

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

  إدارة مجموعات التحكم

Slice=
    اسم وحدة الشريحة لوضع الوحدة فيها. القيمة المبدئية هي system.slice لجميع الوحدات غير المجسدة من جميع أنواع الوحدات (باستثناء وحدات الشرائح نفسها انظر أدناه). توضع وحدات التجسيد مبدئيًا في شريحة فرعية من system.slice تُسمى باسم القالب.

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

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

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

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

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

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

    يأخذ إما وسيطًا منطقيًا أو قائمة (قد تكون فارغة) بأسماء متحكمات مجموعات التحكم. إذا كان صحيحًا (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.

DelegateSubgroup=
    وضع عمليات الوحدة في المجموعة الفرعية المحددة من مجموعة تحكم الوحدة. يأخذ اسم مجموعة تحكم صالح (وليس مسارًا!) كمعلمة، أو سلسلة نصية فارغة لإيقاف تشغيل هذه الميزة. القيمة المبدئية هي إيقاف التشغيل (off). يجب أن يكون اسم مجموعة التحكم قابلاً للاستخدام كاسم ملف وتجنب التعارضات مع ملفات سمات مجموعة تحكم النواة (أي أن cgroup.procs ليس اسمًا مقبولاً، لأن النواة تعرض ملف سمة مجموعة تحكم أصيل بهذا الاسم). ليس لهذا الخيار أي تأثير ما لم يُشغّل تفويض مجموعة التحكم عبر Delegate=، انظر أعلاه. لاحظ أن هذا الإعداد ينطبق فقط على العمليات "الرئيسة" للوحدة، أي بالنسبة للخدمات على ExecStart=، ولكن ليس على ExecReload= وما شابه. إذا مكن التفويض، تُوضع الأخيرة دائمًا داخل مجموعة فرعية تسمى .control. وتُنشأ المجموعة الفرعية المحددة آليًا (ويُحتمل تمرير الملكية إلى المستخدم/المجموعة المهيأة للوحدة) عند بدء عملية فيها.

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

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

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

    يمكن تحديد متحكمات متعددة، مفصولة بمسافات. يمكنك أيضًا تمرير 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.

  التحكم في ضغط الذاكرة

ManagedOOMSwap=auto|kill, ManagedOOMMemoryPressure=auto|kill
    يحدد كيف ستتصرف خدمة systemd-oomd.service(8) تجاه مجموعات تحكم (cgroups) هذه الوحدة. القيمة المبدئية هي auto.

    عند ضبطه على 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.

ManagedOOMMemoryPressureLimit=
    يتجاوز حد ضغط الذاكرة المبدئي المحدد بواسطة oomd.conf(5) لمجموعة تحكم هذه الوحدة. يأخذ قيمة مئوية بين 0% و 100%، شاملاً الطرفين. القيمة المبدئية هي 0%، مما يعني استخدام القيمة المبدئية المحددة بواسطة oomd.conf(5). تُتجاهل هذه الخاصية ما لم يكن ManagedOOMMemoryPressure=kill.

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

ManagedOOMMemoryPressureDurationSec=
    يتجاوز مدة ضغط الذاكرة المبدئية المحددة بواسطة oomd.conf(5) لمجموعة تحكم هذه الوحدة. تدعم القيمة المحددة وحدة زمنية مثل "ms" أو "μs"، انظر systemd.time(7) للحصول على تفاصيل حول الصيغة المسموح بها. يجب ضبطها إاما على قيمة فارغة أو قيمة لا تقل عن ثانية واحدة (1s). القيمة المبدئية هي فارغة، مما يعني استخدام القيمة المبدئية المحددة بواسطة oomd.conf(5). تُتجاهل هذه الخاصية ما لم يكن ManagedOOMMemoryPressure=kill.

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

ManagedOOMPreference=none|avoid|omit
    يسمح بخفض أولوية مجموعة تحكم هذه الوحدة أو حذفها كمرشح عندما يحتاج systemd-oomd إلى التصرف. يتطلب دعمًا للسمات الممتدة (انظر xattr(7)) من أجل استخدام avoid أو omit.

    عند حساب المرشحين لتخفيف استخدام مساحة التبديل (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.

OOMRules=
    يأخذ قائمة مفصولة بمسافات من أسماء مجموعات قواعد OOM. تُعرف مجموعات القواعد في ملفات .oomrule الموضوعة في /etc/systemd/oomd/rules.d/ أو /run/systemd/oomd/rules.d/ أو /usr/local/lib/systemd/oomd/rules.d/ أو /usr/lib/systemd/oomd/rules.d/. عند الضبط، سيراقب systemd-oomd.service(8) مجموعة cgroup لهذه الوحدة ويقيم مجموعات القواعد المحددة مقابلها. تحدد كل مجموعة قواعد شروطًا (مثل عتبات ضغط الذاكرة أو استخدام المبادلة) وإجراءً يُتخذ عند استيفاء تلك الشروط. راجع oomd.conf(5) للحصول على تفاصيل حول خيارات مجموعات القواعد المتاحة.

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

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

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

MemoryPressureWatch=
    التحكم في مراقبة ضغط الذاكرة للعمليات المستدعاة. يأخذ قيمة منطقية أو أحد الخيارين "auto" و "skip". إذا كان "no"، فإنه يخبر الخدمة بعدم مراقبة أحداث ضغط الذاكرة، عن طريق ضبط متغير البيئة $MEMORY_PRESSURE_WATCH على السلسلة النصية الحرفية /dev/null. وإذا كان "yes"، فإنه يخبر الخدمة بمراقبة أحداث ضغط الذاكرة. وهذا يمكّن محاسبة الذاكرة للخدمة، ويضمن أن ملف سمة مجموعة التحكم memory.pressure متاح للقراءة والكتابة من قبل مستخدم الخدمة. ثم يضبط متغير البيئة $MEMORY_PRESSURE_WATCH للعمليات المستدعاة بواسطة الوحدة على مسار نظام الملفات المؤدي إلى هذا الملف. وتُرمّز معلومات الحد المهيأة باستخدام MemoryPressureThresholdSec= في متغير البيئة $MEMORY_PRESSURE_WRITE. وإذا ضُبطت قيمة "auto"، يُ مكن البروتوكول إذا كانت محاسبة الذاكرة مُمكّنة على أي حال للوحدة، ويُعطّل بخلاف ذلك. وإذا ضُبط على "skip"، لا يُمكّن المنطق ولا يُعطّل ولا يُضبط متغيرا البيئة هذان.

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

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

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

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

MemoryPressureThresholdSec=
    يضبط وقت حد ضغط الذاكرة لمراقب ضغط الذاكرة كما هو مهيأ عبر MemoryPressureWatch=. يحدد الحد الأقصى لزمن انتقال التخصيص قبل إرسال إشارة حدث ضغط الذاكرة إلى الخدمة، لكل نافذة مدتها ثانيتان. وإذا لم يُحدد، يؤول مبدئيًا إلى إعداد DefaultMemoryPressureThresholdSec= في systemd-system.conf(5) (والذي يؤول بدوره مبدئيًا إلى 200ms). تتوقع القيمة المحددة وحدة زمنية مثل "ms" أو "μs"، انظر systemd.time(7) للحصول على تفاصيل حول الصيغة المسموح بها.

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

CPUPressureWatch=
    يتحكم في مراقبة ضغط CPU للعمليات المستدعاة. يأخذ قيمة منطقية أو إحدى القيم "auto" و"skip". إذا كان "no"، يُخبر الخدمة بعدم مراقبة أحداث ضغط CPU، عن طريق ضبط متغير البيئة $CPU_PRESSURE_WATCH على السلسلة الحرفية /dev/null. إذا كان "yes"، يُخبر الخدمة بمراقبة أحداث ضغط CPU. يضمن هذا أن ملف سمة cgroup cpu.pressure يمكن الوصول إليه للقراءة والكتابة من قبل مستخدم الخدمة. ثم يضبط متغير البيئة $CPU_PRESSURE_WATCH للعمليات المستدعاة من قبل الوحدة على مسار نظام الملفات لهذا الملف. تُرمَز معلومات العتبة المكونة مع CPUPressureThresholdSec= في متغير البيئة $CPU_PRESSURE_WRITE. إذا ضُبطت القيمة "auto"، يُفعّل البروتوكول إذا كانت ضوابط موارد CPU مكونة للوحدة (مثلًا لأن CPUWeight= أو CPUQuota= مضبوط)، ويُعطّل بخلاف ذلك. إذا ضُبطت على "skip"، لا يُفعّل المنطق ولا يُعطّل، ولا يُضبط متغيرا البيئة.

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

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

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

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

CPUPressureThresholdSec=
    يضبط وقت عتبة ضغط CPU لمراقب ضغط CPU كما هو مكون عبر CPUPressureWatch=. يحدد أقصى وقت توقف CPU قبل الإشارة إلى حدث ضغط CPU للخدمة، لكل نافذة زمنية مدتها 2 ثانية. إذا لم يُحدد، المبدئي هو إعداد DefaultCPUPressureThresholdSec= في systemd-system.conf(5) (والذي بدوره المبدئي له هو 200 مللي ثانية). تتوقع القيمة المحددة وحدة زمنية مثل "ms" أو "μs"، راجع systemd.time(7) للحصول على تفاصيل حول الصياغة المسموح بها.

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

IOPressureWatch=
    يتحكم في مراقبة ضغط IO للعمليات المستدعاة. يأخذ قيمة منطقية أو إحدى القيم "auto" و"skip". إذا كان "no"، يُخبر الخدمة بعدم مراقبة أحداث ضغط IO، عن طريق ضبط متغير البيئة $IO_PRESSURE_WATCH على السلسلة الحرفية /dev/null. إذا كان "yes"، يُخبر الخدمة بمراقبة أحداث ضغط IO. يُفعّل هذا محاسبة IO للخدمة، ويضمن أن ملف سمة cgroup io.pressure يمكن الوصول إليه للقراءة والكتابة من قبل مستخدم الخدمة. ثم يضبط متغير البيئة $IO_PRESSURE_WATCH للعمليات المستدعاة من قبل الوحدة على مسار نظام الملفات لهذا الملف. تُرمَز معلومات العتبة المكونة مع IOPressureThresholdSec= في متغير البيئة $IO_PRESSURE_WRITE. إذا ضُبطت القيمة "auto"، يُفعّل البروتوكول إذا كانت محاسبة IO مفعلة على أي حال للوحدة (مثلًا لأن IOWeight= أو IODeviceWeight= مضبوط)، ويُعطّل بخلاف ذلك. إذا ضُبطت على "skip"، لا يُفعّل المنطق ولا يُعطّل، ولا يُضبط متغيرا البيئة.

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

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

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

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

IOPressureThresholdSec=
    يضبط وقت عتبة ضغط IO لمراقب ضغط IO كما هو مكون عبر IOPressureWatch=. يحدد أقصى وقت توقف IO قبل الإشارة إلى حدث ضغط IO للخدمة، لكل نافذة زمنية مدتها 2 ثانية. إذا لم يُحدد، المبدئي هو إعداد DefaultIOPressureThresholdSec= في systemd-system.conf(5) (والذي بدوره المبدئي له هو 200 مللي ثانية). تتوقع القيمة المحددة وحدة زمنية مثل "ms" أو "μs"، راجع systemd.time(7) للحصول على تفاصيل حول الصياغة المسموح بها.

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

  التحكم في تفريغ الذاكرة (Coredump)

CoredumpReceive=
    يأخذ وسيطًا منطقيًا. يُستخدم هذا الإعداد لتمكين إعادة توجيه تفريغ الذاكرة (coredump) للحاويات التي تنتمي إلى مجموعة تحكم هذه الوحدة. والوحدات التي تستخدم CoredumpReceive=yes يجب أيضًا تهيئتها باستخدام Delegate=yes. القيمة المبدئية هي false.

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

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

التاريخ

systemd 252
    خيارات التحكم في هرمية مجموعات التحكم القديمة (مجموعات التحكم الإصدار 1[14]) أصبحت الآن مهجورة تمامًا: CPUShares=weight، و StartupCPUShares=weight، و MemoryLimit=bytes، و BlockIOAccounting=، و BlockIOWeight=weight، و StartupBlockIOWeight=weight، و BlockIODeviceWeight=device weight، و BlockIOReadBandwidth=device bytes، و BlockIOWriteBandwidth=device bytes. يرجى الانتقال إلى هرمية cgroup الموحدة.

systemd 258
    إعداد CPUAccounting= مهجور، لأنه متاح دائمًا في هرمية cgroup الموحدة وليس لمثل هذا الإعداد أي تأثير.

انظر أيضًا

systemd(1)، و systemd-system.conf(5)، و systemd.unit(5)، و systemd.service(5)، و systemd.slice(5)، و systemd.scope(5)، و systemd.socket(5)، و systemd.mount(5)، و systemd.swap(5)، و systemd.exec(5)، و systemd.directives(7)، و systemd.special(7)، و systemd-oomd.service(8)، توثيق مجموعات التحكم ومتحكمات معينة في نواة لينكس: مجموعات التحكم الإصدار 2[2]

ملاحظات

1.  واجهات مجموعات التحكم الجديدة
    https://systemd.io/CONTROL_GROUP_INTERFACE

2.  مجموعات التحكم النسخة 2
    https://docs.kernel.org/admin-guide/cgroup-v2.html

3.  مجدول CFS
    https://docs.kernel.org/scheduler/sched-design-CFS.html

4.  التحكم في عرض النطاق الترددي لـ CFS
    https://docs.kernel.org/scheduler/sched-bwc.html

5.  ملفات واجهة الذاكرة
    https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files

6.  Zswap
    https://docs.kernel.org/admin-guide/mm/zswap.html

7.  متحكم pids
    https://docs.kernel.org/admin-guide/cgroup-v2.html#pid

8.  ملفات واجهة الإدخال والإخراج
    https://docs.kernel.org/admin-guide/cgroup-v2.html#io-interface-files

9.  NFT
    https://netfilter.org/projects/nftables/index.html

10. bpf.h
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf.h

11. توثيق BPF
    https://docs.kernel.org/bpf/

12. واجهات برمجة تطبيقات مجموعة التحكم والتفويض
    https://systemd.io/CGROUP_DELEGATION

13. معالجة ضغط الموارد في systemd
    https://systemd.io/PRESSURE

14. مجموعات التحكم الإصدار 1
    https://docs.kernel.org/admin-guide/cgroup-v1/index.html

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

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

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