SYSTEMD.RESOURCE-CONTROL(5) systemd.resource-control SYSTEMD.RESOURCE-CONTROL(5)

systemd.resource-control - تنظیمات کنترل منابع و مدیریت گروه‌های کنترلی (cgroups) در systemd

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

فایل‌های پیکربندی واحد برای سرویس‌ها (services)، برش‌ها (slices)، دامنه‌ها (scopes)، سوکت‌ها (sockets)، نقاط اتصال (mount points) و دستگاه‌های حافظه مجازی (swap devices) زیرمجموعه‌ای از گزینه‌های پیکربندی مشترک را برای کنترل منابع فرآیندهای ایجادشده به اشتراک می‌گذارند. در لایه‌های درونی، این قابلیت به مفهوم هسته لینوکس یعنی گروه‌های کنترلی (Control Groups یا 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 دارای ساختار سلسله‌مراتبی هستند و کنترل منابع از طریق توزیع سهمیه‌های منابع میان هم‌سطح‌ها (siblings) در شاخه‌های سلسله‌مراتب cgroup محقق می‌شود. نیازی به فعال‌سازی صریح یک کنترل‌کننده cgroup برای یک واحد وجود ندارد. زمانی که واحدی دارای پیکربندی برای یک کنترل‌کننده معین باشد، systemd به هسته دستور می‌دهد تا کنترل‌کننده مربوطه را برای آن واحد فعال کند. برای مثال، هنگامی که CPUWeight= تنظیم شده باشد، کنترل‌کننده cpu فعال خواهد شد و هنگامی که TasksMax= تنظیم شود، کنترل‌کننده pids فعال می‌شود. علاوه بر این، کنترل‌کننده‌های مختلف را می‌توان به‌صورت صریح از طریق تنظیمات MemoryAccounting=/TasksAccounting=/IOAccounting= نیز فعال کرد. با توجه به شیوه کارکرد سلسله‌مراتب cgroup، کنترل‌کننده‌ها به‌طور خودکار برای تمامی واحدهای والد و برای هر واحد هم‌سطح از پایین‌ترین سطحی که یک کنترل‌کننده در آن فعال شده است، فعال خواهند شد. واحدهایی که یک کنترل‌کننده برای آن‌ها فعال شده است ممکن است تحت کنترل منابع قرار گیرند، حتی اگر پیکربندی صریحی نداشته باشند.

تنظیم Delegate= هر کنترل‌کننده واگذارشده را برای آن واحد فعال می‌کند (به زیر مراجعه کنید). نماینده (delegatee) ممکن است در صورت لزوم کنترل‌کننده‌ها را برای فرزندان خود فعال سازد. به‌ویژه، اگر نماینده 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 برای واحدهای درون آن برش‌ها فعال نخواهد شد و منابع CPU با استفاده از سازوکارهای دیگر، مانند سطوح nice تخصیص خواهند یافت. مدیر مربوط به کاربر 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 تخصیص خواهند یافت.

همان‌طور که در 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 قرار داد. این دایرکتوری آخر بر تمام برش‌های کاربری اعمال می‌شود.

برای آشنایی با نحوه استفاده از APIهای کنترل منابع از طریق برنامه‌ها به واسط‌های جدید گروه کنترلی (New Control Group Interfaces)[1] مراجعه کنید.

وابستگی‌های زیر به‌طور ضمنی اضافه می‌شوند:

•واحدهایی که تنظیم Slice= برای آن‌ها تعیین شده باشد، به‌طور خودکار وابستگی‌های Requires= و After= را نسبت به واحد برش مشخص‌شده به دست می‌آورند.

واحدهایی از انواع فهرست‌شده در بالا می‌توانند دارای تنظیماتی برای پیکربندی کنترل منابع باشند:

CPUAccounting=

حسابداری مصرف پردازنده (CPU) را برای این واحد فعال می‌کند. یک آرگومان بولی می‌گیرد. توجه داشته باشید که فعال کردن حسابداری پردازنده برای یک واحد به‌طور ضمنی آن را برای تمامی واحدهای موجود در همان برش و برای تمام برش‌های والد آن و واحدهای موجود در آن‌ها نیز فعال می‌کند. مقدار پیش‌فرض سیستم برای این تنظیم را می‌توان با DefaultCPUAccounting= در systemd-system.conf(5) کنترل کرد.

در سلسله‌مراتب یکپارچه cgroup (unified cgroup hierarchy)، حسابداری CPU برای تمامی واحدها در دسترس است و این تنظیم هیچ تأثیری ندارد.

در نسخه 208 اضافه شد.

CPUWeight=weight, StartupCPUWeight=weight

این تنظیمات، کنترل‌کننده cpu را در سلسله‌مراتب یکپارچه کنترل می‌کنند.

این گزینه‌ها یک مقدار عدد صحیح یا رشته ویژه "idle" را می‌پذیرند:

•اگر روی یک مقدار عددی صحیح تنظیم شود، در صورتی که سلسله‌مراتب یکپارچه گروه کنترلی در سیستم استفاده شود، وزن زمان CPU مشخص‌شده را به فرآیندهای اجراشده اختصاص می‌دهد. این گزینه‌ها ویژگی گروه کنترلی "cpu.weight" را کنترل می‌کنند. محدوده مجاز از 1 تا 10000 است. پیش‌فرض روی مقدار تنظیم‌نشده (unset) است، اما مقدار پیش‌فرض هسته 100 است. برای جزئیات در مورد این ویژگی گروه کنترلی، به گروه‌های کنترلی نسخه 2 (Control Groups v2)[2] و زمان‌بند CFS (CFS Scheduler)[3] مراجعه کنید. زمان در دسترس CPU بر اساس وزن زمان پردازنده میان تمامی واحدهای درون یک برش تقسیم می‌شود. وزن بالاتر به معنای زمان پردازنده بیشتر و وزن کمتر به معنای زمان کمتر است.
•اگر روی رشته ویژه "idle" تنظیم شود، cgroup را برای "زمان‌بندی بیکاری" (idle scheduling) علامت‌گذاری می‌کند، به این معنی که منابع CPU را تنها زمانی دریافت خواهد کرد که هیچ فرآیندی که بدین صورت علامت‌گذاری نشده باشد در این cgroup یا هم‌سطح‌های آن برای اجرا وجود نداشته باشد. این تنظیم متناظر با ویژگی cgroup با نام "cpu.idle" است.

توجه داشته باشید که این مقدار تنها روی cgroup-v2 اثر دارد و برای cgroup-v1 معادل کمترین وزن ممکن است.

در حالی که StartupCPUWeight= بر مراحل راه‌اندازی (startup) و خاموش شدن (shutdown) سیستم اعمال می‌شود، CPUWeight= بر زمان اجرای عادی سیستم اعمال می‌گردد و در صورتی که گزینه اول تنظیم نشده باشد، بر مراحل راه‌اندازی و خاموش شدن نیز اعمال خواهد شد. استفاده از StartupCPUWeight= امکان اولویت‌بندی سرویس‌های خاص را در زمان بوت و خاموش شدن، به شکلی متفاوت از زمان اجرای عادی فراهم می‌کند.

علاوه بر تخصیص منابع انجام‌شده توسط کنترل‌کننده cpu، هسته ممکن است به‌طور خودکار منابع را بر اساس گروه‌بندی شناسه‌های نشست (session-id) تقسیم کند؛ به بخش "The autogroup feature" در sched(7) مراجعه کنید. تأثیر این ویژگی مشابه کنترل‌کننده cpu بدون پیکربندی صریح است، بنابراین کاربران باید دقت کنند که یکی را با دیگری اشتباه نگیرند.

در نسخه 232 اضافه شد.

CPUQuota=

این تنظیم، کنترل‌کننده cpu را در سلسله‌مراتب یکپارچه کنترل می‌کند.

سهمیه زمان CPU مشخص‌شده را به فرآیندهای اجراشده اختصاص می‌دهد. یک مقدار درصدی را دریافت می‌کند که با "%" پسوند خورده است. این درصد مشخص می‌کند که واحد حداکثر چه مقدار زمان پردازنده را نسبت به کل زمان پردازنده در دسترس در یک CPU دریافت خواهد کرد. برای اختصاص زمان CPU در بیش از یک پردازنده از مقادیر > 100% استفاده کنید. این تنظیم ویژگی "cpu.max" را در سلسله‌مراتب یکپارچه گروه کنترلی و "cpu.cfs_quota_us" را در سلسله‌مراتب سنتی (legacy) کنترل می‌کند. برای جزئیات در مورد این ویژگی‌های گروه کنترلی به گروه‌های کنترلی نسخه 2 (Control Groups v2)[2] و کنترل پهنای باند CFS (CFS Bandwidth Control)[4] مراجعه کنید. تنظیم CPUQuota= با یک مقدار خالی سهمیه را لغو می‌کند.

مثال: CPUQuota=20% تضمین می‌کند که فرآیندهای اجراشده هرگز بیش از 20% زمان CPU را روی یک پردازنده دریافت نخواهند کرد.

در نسخه 213 اضافه شد.

CPUQuotaPeriodSec=

این تنظیم، کنترل‌کننده cpu را در سلسله‌مراتب یکپارچه کنترل می‌کند.

مدت زمانی را تعیین می‌کند که سهمیه زمان پردازنده مشخص‌شده توسط CPUQuota= طی آن اندازه‌گیری می‌شود. یک مقدار بازه زمانی را به ثانیه می‌گیرد، با پسوند اختیاری مانند "ms" برای میلی‌ثانیه (یا "s" برای ثانیه). مقدار پیش‌فرض 100ms است. این دوره به بازه پشتیبانی‌شده توسط هسته، یعنی [1ms, 1000ms] محدود می‌شود. علاوه بر این، دوره به‌سمت بالا تنظیم می‌شود تا فاصله سهمیه نیز حداقل 1ms باشد. تنظیم CPUQuotaPeriodSec= روی یک مقدار خالی، آن را به پیش‌فرض بازنشانی می‌کند.

این گزینه فیلد دوم ویژگی "cpu.max" را در سلسله‌مراتب یکپارچه گروه کنترلی و "cpu.cfs_period_us" را در مدل سنتی کنترل می‌کند. برای جزئیات درباره این ویژگی‌های گروه کنترلی به گروه‌های کنترلی نسخه 2 (Control Groups v2)[2] و زمان‌بند CFS (CFS Scheduler)[3] مراجعه کنید.

مثال: CPUQuotaPeriodSec=10ms برای درخواست اینکه سهمیه پردازنده در دوره‌های 10 میلی‌ثانیه‌ای اندازه‌گیری شود.

در نسخه 242 اضافه شد.

AllowedCPUs=, StartupAllowedCPUs=

این تنظیم، کنترل‌کننده cpuset را در سلسله‌مراتب یکپارچه کنترل می‌کند.

فرآیندها را محدود می‌کند تا فقط روی پردازنده‌های خاصی اجرا شوند. فهرستی از نمایه‌ها (indices) یا بازه‌های CPU جداشده با فاصله یا کاما را می‌گیرد. بازه‌های CPU با نمایه‌های پایینی و بالایی پردازنده که با خط تیره جدا شده‌اند مشخص می‌شوند.

تنظیم AllowedCPUs= یا StartupAllowedCPUs= تضمین نمی‌کند که تمامی پردازنده‌ها توسط فرآیندها استفاده شوند، زیرا ممکن است توسط واحدهای والد محدود شده باشند. پیکربندی مؤثر به‌صورت EffectiveCPUs= گزارش می‌شود.

در حالی که StartupAllowedCPUs= بر مراحل راه‌اندازی و خاموش شدن سیستم اعمال می‌شود، AllowedCPUs= بر زمان اجرای عادی سیستم اعمال می‌گردد و در صورتی که گزینه اول تنظیم نشده باشد بر مراحل راه‌اندازی و خاموش شدن نیز اعمال خواهد شد. استفاده از StartupAllowedCPUs= امکان اولویت‌بندی سرویس‌های خاص را در زمان بوت و خاموش شدن، به شکلی متفاوت از زمان اجرای عادی فراهم می‌کند.

این تنظیم تنها در سلسله‌مراتب یکپارچه گروه کنترلی پشتیبانی می‌شود.

در نسخه 244 اضافه شد.

MemoryAccounting=

این تنظیم، کنترل‌کننده memory را در سلسله‌مراتب یکپارچه کنترل می‌کند.

حسابداری حافظه فرآیند و هسته را برای این واحد فعال می‌کند. یک آرگومان بولی می‌گیرد. توجه داشته باشید که فعال کردن حسابداری حافظه برای یک واحد به‌طور ضمنی آن را برای تمام واحدهای موجود در همان برش و برای تمام برش‌های والد آن و واحدهای موجود در آن‌ها نیز فعال می‌سازد. پیش‌فرض سیستم برای این تنظیم را می‌توان با DefaultMemoryAccounting= در systemd-system.conf(5) کنترل کرد.

در نسخه 208 اضافه شد.

MemoryMin=bytes, MemoryLow=bytes, StartupMemoryLow=bytes, DefaultStartupMemoryLow=bytes

این تنظیمات، کنترل‌کننده memory را در سلسله‌مراتب یکپارچه کنترل می‌کنند.

حفاظت از مصرف حافظه فرآیندهای اجراشده در این واحد را تعیین می‌کنند. هنگام بازپس‌گیری حافظه (memory reclaiming)، با واحد به‌گونه‌ای رفتار می‌شود که گویی حافظه کمتری مصرف می‌کند، که منجر می‌شود حافظه ترجیحاً از واحدهای محافظت‌نشده بازپس گرفته شود. استفاده از MemoryLow= منجر به حفاظتی ضعیف‌تر می‌شود که در آن همچنان ممکن است حافظه بازپس گرفته شود تا در صورت نبود حافظه قابل بازپس‌گیری دیگر، از فراخوانی قاتل کمبود حافظه (OOM killer) جلوگیری شود.

برای اینکه حفاظت مؤثر باشد، معمولاً لازم است تخصیص متناظر در تمامی نیاکان (ancestors) تنظیم شود، که سپس میان فرزندان توزیع می‌شود (به‌استثنای برش ریشه). هرگونه تخصیص MemoryMin= یا MemoryLow= که به‌طور صریح به فرزندان خاصی توزیع نشده باشد، برای ایجاد یک حفاظت مشترک برای تمام فرزندان استفاده می‌شود. از آنجا که این یک حفاظت مشترک است، فرزندان آزادانه برای حافظه با یکدیگر رقابت خواهند کرد.

اندازه حافظه را بر حسب بایت می‌گیرد. اگر مقدار با K، M، G یا T پسوند داشته باشد، اندازه حافظه مشخص‌شده به‌ترتیب بر حسب کیلوبایت، مگابایت، گیگابایت یا ترابایت (با پایه 1024) تجزیه می‌شود. همچنین می‌توان یک مقدار درصدی را مشخص کرد که نسبت به حافظه فیزیکی نصب‌شده روی سیستم در نظر گرفته می‌شود. در صورت انتساب مقدار ویژه "infinity"، تمامی حافظه در دسترس محافظت می‌شود، که ممکن است برای به ارث بردن همیشگی تمامی حفاظت‌های ارائه‌شده توسط نیاکان مفید باشد. این گزینه‌ها ویژگی گروه کنترلی "memory.min" یا "memory.low" را کنترل می‌کنند. برای جزئیات درباره این ویژگی‌های گروه کنترلی به فایل‌های واسط حافظه (Memory Interface Files)[5] مراجعه کنید.

واحدها می‌توانند با مشخص کردن DefaultMemoryMin= یا DefaultMemoryLow= کاری کنند که فرزندانشان از یک مقدار پیش‌فرض "memory.min" یا "memory.low" استفاده کنند، که معنایی مشابه با MemoryMin= و MemoryLow= دارد، یا DefaultStartupMemoryLow= که معنایی مشابه با StartupMemoryLow= دارد. این تنظیم بر "memory.min" یا "memory.low" در خود واحد تأثیری ندارد. استفاده از آن برای تنظیم تخصیص پیش‌فرض فرزندان تنها روی هسته‌های قدیمی‌تر از 5.7 مفید است، که از گزینه اتصال cgroup2 با نام "memory_recursiveprot" پشتیبانی نمی‌کنند.

در حالی که StartupMemoryLow= بر مراحل راه‌اندازی و خاموش شدن سیستم اعمال می‌شود، MemoryMin= بر زمان اجرای عادی سیستم اعمال می‌گردد و در صورتی که گزینه اول تنظیم نشده باشد بر مراحل راه‌اندازی و خاموش شدن نیز اعمال خواهد شد. استفاده از StartupMemoryLow= امکان اولویت‌بندی سرویس‌های خاص را در زمان راه‌اندازی و خاموش شدن متفاوت از زمان اجرای عادی فراهم می‌کند.

در نسخه 240 اضافه شد.

MemoryHigh=bytes, StartupMemoryHigh=bytes

این تنظیمات، کنترل‌کننده memory را در سلسله‌مراتب یکپارچه کنترل می‌کنند.

حد مهارکننده (throttling limit) مصرف حافظه فرآیندهای اجراشده در این واحد را تعیین می‌کنند. در صورت غیرقابل اجتناب بودن، مصرف حافظه ممکن است فراتر از حد مجاز برود، اما در چنین مواردی فرآیندها به‌شدت کند می‌شوند و حافظه به‌صورت تهاجمی بازپس گرفته می‌شود. این سازوکار اصلی برای کنترل مصرف حافظه یک واحد است.

اندازه حافظه را بر حسب بایت می‌گیرد. اگر مقدار با K، M، G یا T پسوند داشته باشد، اندازه حافظه مشخص‌شده به‌ترتیب بر حسب کیلوبایت، مگابایت، گیگابایت یا ترابایت (با پایه 1024) تجزیه می‌شود. همچنین می‌توان یک مقدار درصدی را مشخص کرد که نسبت به حافظه فیزیکی نصب‌شده روی سیستم محاسبه می‌شود. در صورت انتساب مقدار ویژه "infinity"، هیچ مهاری روی حافظه اعمال نمی‌شود. این گزینه ویژگی گروه کنترلی "memory.high" را کنترل می‌کند. برای جزئیات در مورد این ویژگی گروه کنترلی به فایل‌های واسط حافظه (Memory Interface Files)[5] مراجعه کنید. پیکربندی مؤثر به‌صورت EffectiveMemoryHigh= گزارش می‌شود (همچنین EffectiveMemoryMax= را ببینید).

در حالی که StartupMemoryHigh= بر مراحل راه‌اندازی و خاموش شدن سیستم اعمال می‌شود، MemoryHigh= بر زمان اجرای عادی سیستم اعمال می‌گردد و در صورتی که گزینه اول تنظیم نشده باشد بر مراحل راه‌اندازی و خاموش شدن نیز اعمال خواهد شد. استفاده از StartupMemoryHigh= امکان اولویت‌بندی سرویس‌های خاص را در زمان راه‌اندازی و خاموش شدن متفاوت از زمان اجرای عادی فراهم می‌سازد.

در نسخه 231 اضافه شد.

MemoryMax=bytes, StartupMemoryMax=bytes

این تنظیمات، کنترل‌کننده memory را در سلسله‌مراتب یکپارچه کنترل می‌کنند.

حد مطلق مصرف حافظه فرآیندهای اجراشده در این واحد را تعیین می‌کنند. اگر مصرف حافظه نتواند زیر این حد مهار شود، قاتل کمبود حافظه (OOM killer) در درون واحد فراخوانی می‌شود. توصیه می‌شود که از MemoryHigh= به عنوان سازوکار اصلی کنترل و از MemoryMax= به عنوان آخرین خط دفاعی استفاده شود.

اندازه حافظه را بر حسب بایت می‌گیرد. اگر مقدار با K، M، G یا T پسوند داشته باشد، اندازه حافظه مشخص‌شده به‌ترتیب بر حسب کیلوبایت، مگابایت، گیگابایت یا ترابایت (با پایه 1024) تجزیه می‌شود. همچنین می‌توان یک مقدار درصدی را مشخص کرد که نسبت به حافظه فیزیکی نصب‌شده روی سیستم محاسبه می‌شود. در صورت انتساب مقدار ویژه "infinity"، هیچ محدودیتی بر حافظه اعمال نمی‌شود. این گزینه ویژگی گروه کنترلی "memory.max" را کنترل می‌کند. برای جزئیات در مورد این ویژگی گروه کنترلی به فایل‌های واسط حافظه (Memory Interface Files)[5] مراجعه کنید. پیکربندی مؤثر به‌صورت EffectiveMemoryMax= گزارش می‌شود (این مقدار سخت‌گیرانه‌ترین حد واحد و برش‌های والد است و توسط حافظه فیزیکی محدود می‌شود).

در حالی که StartupMemoryMax= بر مراحل راه‌اندازی و خاموش شدن سیستم اعمال می‌شود، MemoryMax= بر زمان اجرای عادی سیستم اعمال می‌گردد و در صورتی که گزینه اول تنظیم نشده باشد بر مراحل راه‌اندازی و خاموش شدن نیز اعمال خواهد شد. استفاده از StartupMemoryMax= امکان اولویت‌بندی سرویس‌های خاص را در زمان راه‌اندازی و خاموش شدن متفاوت از زمان اجرای عادی فراهم می‌کند.

در نسخه 231 اضافه شد.

MemorySwapMax=bytes, StartupMemorySwapMax=bytes

این تنظیمات، کنترل‌کننده memory را در سلسله‌مراتب یکپارچه کنترل می‌کنند.

حد مطلق مصرف حافظه مبادله (swap) فرآیندهای اجراشده در این واحد را تعیین می‌کنند.

اندازه swap را بر حسب بایت می‌گیرد. اگر مقدار با K، M، G یا T پسوند داشته باشد، اندازه swap مشخص‌شده به‌ترتیب بر حسب کیلوبایت، مگابایت، گیگابایت یا ترابایت (با پایه 1024) تجزیه می‌شود. همچنین می‌توان یک مقدار درصدی را مشخص کرد که نسبت به کل اندازه swap مشخص‌شده روی سیستم محاسبه می‌شود. در صورت انتساب مقدار ویژه "infinity"، هیچ محدودیتی بر swap اعمال نمی‌شود. این تنظیمات ویژگی گروه کنترلی "memory.swap.max" را کنترل می‌کنند. برای جزئیات درباره این ویژگی گروه کنترلی به فایل‌های واسط حافظه (Memory Interface Files)[5] مراجعه کنید.

در حالی که StartupMemorySwapMax= بر مراحل راه‌اندازی و خاموش شدن سیستم اعمال می‌شود، MemorySwapMax= بر زمان اجرای عادی سیستم اعمال می‌گردد و در صورتی که گزینه اول تنظیم نشده باشد بر مراحل راه‌اندازی و خاموش شدن نیز اعمال خواهد شد. استفاده از StartupMemorySwapMax= امکان اولویت‌بندی سرویس‌های خاص را در زمان راه‌اندازی و خاموش شدن متفاوت از زمان اجرای عادی فراهم می‌کند.

در نسخه 232 اضافه شد.

MemoryZSwapMax=bytes, StartupMemoryZSwapMax=bytes

این تنظیمات، کنترل‌کننده memory را در سلسله‌مراتب یکپارچه کنترل می‌کنند.

حد مطلق مصرف zswap فرآیندهای این واحد را تعیین می‌کنند. قابلیت Zswap یک حافظه نهان فشرده‌سازی‌شده سبک برای صفحات swap است. این قابلیت صفحاتی را که در شرف انتقال به حافظه swap هستند دریافت کرده و تلاش می‌کند آن‌ها را در یک استخر حافظه پویا بر پایه RAM فشرده کند. اگر حد مشخص‌شده فرابرسد، هیچ ورودی از این واحد در استخر ذخیره نخواهد شد تا زمانی که ورودی‌های موجود دوباره به حافظه بازگردند (faulted back) یا روی دیسک نوشته شوند. برای جزئیات بیشتر به مستندات Zswap[6] در هسته مراجعه کنید.

اندازه‌ای را بر حسب بایت می‌گیرد. اگر مقدار با K، M، G یا T پسوند داشته باشد، اندازه مشخص‌شده به‌ترتیب بر حسب کیلوبایت، مگابایت، گیگابایت یا ترابایت (با پایه 1024) تجزیه می‌شود. در صورت انتساب مقدار ویژه "infinity"، هیچ محدودیتی اعمال نمی‌شود. این تنظیمات ویژگی گروه کنترلی "memory.zswap.max" را کنترل می‌کنند. برای جزئیات درباره این ویژگی گروه کنترلی به فایل‌های واسط حافظه (Memory Interface Files)[5] مراجعه کنید.

در حالی که StartupMemoryZSwapMax= بر مراحل راه‌اندازی و خاموش شدن سیستم اعمال می‌شود، MemoryZSwapMax= بر زمان اجرای عادی سیستم اعمال می‌گردد و در صورتی که گزینه اول تنظیم نشده باشد بر مراحل راه‌اندازی و خاموش شدن نیز اعمال خواهد شد. استفاده از StartupMemoryZSwapMax= امکان اولویت‌بندی سرویس‌های خاص را در زمان راه‌اندازی و خاموش شدن متفاوت از زمان اجرای عادی فراهم می‌کند.

در نسخه 253 اضافه شد.

MemoryZSwapWriteback=

این تنظیم، کنترل‌کننده memory را در سلسله‌مراتب یکپارچه کنترل می‌کند.

یک آرگومان بولی می‌گیرد. وقتی true باشد، صفحاتی که در حافظه نهان Zswap ذخیره شده‌اند مجازند در فضای ذخیره‌سازی پشتیبان نوشته شوند، و در غیر این صورت false است. پیش‌فرض true است. این ویژگی امکان غیرفعال کردن بازنویسی (writeback) صفحات swap را برای برنامه‌های با شدت ورودی/خروجی (I/O) بالا فراهم می‌کند، در حالی که توانایی ذخیره صفحات فشرده در Zswap همچنان حفظ می‌شود. برای جزئیات بیشتر به مستندات Zswap[6] در هسته مراجعه کنید.

در نسخه 256 اضافه شد.

AllowedMemoryNodes=, StartupAllowedMemoryNodes=

این تنظیمات، کنترل‌کننده cpuset را در سلسله‌مراتب یکپارچه کنترل می‌کنند.

فرآیندها را محدود می‌کنند تا فقط روی گره‌های حافظه NUMA خاصی اجرا شوند. فهرستی از نمایه‌ها یا بازه‌های گره‌های حافظه NUMA جداشده با فاصله یا کاما را دریافت می‌کنند. بازه‌های گره‌های NUMA با نمایه‌های پایینی و بالایی گره‌ها که با خط تیره جدا شده‌اند مشخص می‌شوند.

تنظیم AllowedMemoryNodes= یا StartupAllowedMemoryNodes= تضمین نمی‌کند که تمامی گره‌های حافظه NUMA توسط فرآیندها استفاده شوند، زیرا ممکن است توسط واحدهای والد محدود شده باشند. پیکربندی مؤثر به‌صورت EffectiveMemoryNodes= گزارش می‌شود.

در حالی که StartupAllowedMemoryNodes= بر مراحل راه‌اندازی و خاموش شدن سیستم اعمال می‌شود، AllowedMemoryNodes= بر زمان اجرای عادی سیستم اعمال می‌گردد و در صورتی که گزینه اول تنظیم نشده باشد بر مراحل راه‌اندازی و خاموش شدن نیز اعمال خواهد شد. استفاده از StartupAllowedMemoryNodes= امکان اولویت‌بندی سرویس‌های خاص را در زمان راه‌اندازی و خاموش شدن متفاوت از زمان اجرای عادی فراهم می‌سازد.

این تنظیم تنها در سلسله‌مراتب یکپارچه گروه کنترلی پشتیبانی می‌شود.

در نسخه 244 اضافه شد.

TasksAccounting=

این تنظیم، کنترل‌کننده pids را در سلسله‌مراتب یکپارچه کنترل می‌کند.

حسابداری وظایف (tasks) را برای این واحد فعال می‌کند. یک آرگومان بولی می‌گیرد. در صورت فعال بودن، هسته تعداد کل وظایف موجود در واحد و فرزندان آن را پیگیری می‌کند. این تعداد شامل ریسه‌های هسته و فرآیندهای فضای کاربری می‌شود و هر ریسه به‌صورت جداگانه شمرده می‌شود. توجه داشته باشید که فعال کردن حسابداری وظایف برای یک واحد به‌طور ضمنی آن را برای تمامی واحدهای موجود در همان برش و برای تمام برش‌های والد آن و واحدهای موجود در آن‌ها نیز فعال می‌کند. پیش‌فرض سیستم برای این تنظیم را می‌توان با DefaultTasksAccounting= در systemd-system.conf(5) کنترل کرد.

در نسخه 227 اضافه شد.

TasksMax=N

این تنظیم، کنترل‌کننده pids را در سلسله‌مراتب یکپارچه کنترل می‌کند.

حداکثر تعداد وظایفی را که می‌توان در واحد ایجاد کرد مشخص می‌کند. این اطمینان حاصل می‌کند که تعداد وظایف حسابداری‌شده برای واحد (به بالا مراجعه کنید) زیر یک حد معین باقی بماند. این گزینه یا یک تعداد مطلق از وظایف یا یک مقدار درصدی را دریافت می‌کند که نسبت به حداکثر تعداد وظایف پیکربندی‌شده روی سیستم محاسبه می‌شود. در صورت انتساب مقدار ویژه "infinity"، هیچ محدودیتی بر تعداد وظایف اعمال نمی‌شود. این گزینه ویژگی گروه کنترلی "pids.max" را کنترل می‌کند. برای جزئیات در مورد این ویژگی گروه کنترلی به مستندات کنترل‌کننده pids (pids controller)[7] مراجعه کنید. پیکربندی مؤثر به‌صورت EffectiveTasksMax= گزارش می‌شود.

پیش‌فرض سیستم برای این تنظیم را می‌توان با DefaultTasksMax= در systemd-system.conf(5) کنترل کرد.

در نسخه 227 اضافه شد.

IOAccounting=

این تنظیم، کنترل‌کننده io را در سلسله‌مراتب یکپارچه کنترل می‌کند.

حسابداری ورودی/خروجی بلوکی (Block I/O) را برای این واحد فعال می‌کند، در صورتی که سلسله‌مراتب یکپارچه گروه کنترلی در سیستم استفاده شود. یک آرگومان بولی می‌گیرد. توجه داشته باشید که فعال کردن حسابداری ورودی/خروجی بلوکی برای یک واحد به‌طور ضمنی آن را برای تمام واحدهای موجود در همان برش و برای تمام برش‌های والد آن و واحدهای موجود در آن‌ها نیز فعال می‌کند. پیش‌فرض سیستم برای این تنظیم را می‌توان با DefaultIOAccounting= در systemd-system.conf(5) کنترل کرد.

در نسخه 230 اضافه شد.

IOWeight=weight, StartupIOWeight=weight

این تنظیمات، کنترل‌کننده io را در سلسله‌مراتب یکپارچه کنترل می‌کنند.

وزن کلی پیش‌فرض ورودی/خروجی بلوکی را برای فرآیندهای اجراشده تعیین می‌کنند، در صورتی که سلسله‌مراتب یکپارچه گروه کنترلی در سیستم استفاده شود. یک مقدار وزن واحد (بین 1 تا 10000) را برای تنظیم وزن پیش‌فرض Block I/O می‌گیرند. این گزینه ویژگی گروه کنترلی "io.weight" را کنترل می‌کند که پیش‌فرض آن 100 است. برای جزئیات در مورد این ویژگی گروه کنترلی به فایل‌های واسط IO (IO Interface Files)[8] مراجعه کنید. پهنای باند I/O در دسترس بر اساس وزن ورودی/خروجی بلوکی میان تمامی واحدهای درون یک برش تقسیم می‌شود. وزن بالاتر به معنای پهنای باند I/O بیشتر و وزن کمتر به معنای پهنای باند کمتر است.

در حالی که StartupIOWeight= بر مراحل راه‌اندازی و خاموش شدن سیستم اعمال می‌شود، IOWeight= بر زمان اجرای بعدی سیستم اعمال می‌گردد و در صورتی که گزینه اول تنظیم نشده باشد بر مراحل راه‌اندازی و خاموش شدن نیز اعمال خواهد شد. این ویژگی امکان اولویت‌بندی سرویس‌های خاص را در زمان بوت و خاموش شدن متفاوت از زمان اجرا فراهم می‌سازد.

در نسخه 230 اضافه شد.

IODeviceWeight=device weight

این تنظیم، کنترل‌کننده io را در سلسله‌مراتب یکپارچه کنترل می‌کند.

وزن کلی ورودی/خروجی بلوکی را به‌ازای هر دستگاه برای فرآیندهای اجراشده تعیین می‌کند، در صورتی که سلسله‌مراتب یکپارچه گروه کنترلی در سیستم استفاده شود. یک جفت جداشده با فاصله شامل مسیر فایل و یک مقدار وزن را برای تعیین مقدار وزن مخصوص دستگاه (بین 1 تا 10000) می‌گیرد. (مثال: "/dev/sda 1000"). مسیر فایل ممکن است به‌صورت مسیر به یک گره دستگاه بلوکی یا هر فایل دیگری مشخص شود، که در این حالت دستگاه بلوکی پشتیبان سیستم فایل آن فایل شناسایی می‌شود. این گزینه ویژگی گروه کنترلی "io.weight" را کنترل می‌کند که پیش‌فرض آن 100 است. از این گزینه چندین بار برای تنظیم وزن برای چندین دستگاه استفاده کنید. برای جزئیات درباره این ویژگی گروه کنترلی به فایل‌های واسط IO (IO Interface Files)[8] مراجعه کنید.

گره دستگاه مشخص‌شده باید به یک دستگاه بلوکی ارجاع دهد که یک زمان‌بند I/O به آن مرتبط است، یعنی نباید به دستگاه‌های بلوکی پارتیشن یا loopback ارجاع دهد، بلکه باید به دستگاه فیزیکی اصلی اشاره کند. هنگامی که مسیری به یک فایل یا دایرکتوری معمولی مشخص می‌شود، تلاش می‌شود دستگاه اصلی صحیح که پشتیبان سیستم فایل مسیر مشخص‌شده است کشف شود. این کار تنها برای موارد ساده‌تر به‌درستی عمل می‌کند، جایی که سیستم فایل مستقیماً روی یک پارتیشن یا دستگاه بلوکی فیزیکی قرار دارد، یا جایی که رمزنگاری ساده 1:1 با استفاده از dm-crypt/LUKS به کار رفته است. این کشف شامل دستگاه‌های ذخیره‌سازی پیچیده و به‌ویژه دستگاه‌های ذخیره‌سازی با مدیریت حجم (volume management) و RAID نمی‌شود.

در نسخه 230 اضافه شد.

IOReadBandwidthMax=device bytes, IOWriteBandwidthMax=device bytes

این تنظیمات، کنترل‌کننده io را در سلسله‌مراتب یکپارچه کنترل می‌کنند.

حداکثر حد پهنای باند ورودی/خروجی بلوکی را به‌ازای هر دستگاه برای فرآیندهای اجراشده تعیین می‌کنند، در صورتی که سلسله‌مراتب یکپارچه گروه کنترلی در سیستم استفاده شود. این حد از نوع ذخیره‌کننده کار (work-conserving) نیست و فرآیندهای اجراشده حتی در صورت داشتن ظرفیت بیکار توسط دستگاه مجاز به استفاده بیشتر نیستند. یک جفت جداشده با فاصله شامل مسیر فایل و یک مقدار پهنای باند (بر حسب بایت بر ثانیه) را برای تعیین پهنای باند مخصوص دستگاه دریافت می‌کنند. مسیر فایل می‌تواند مسیری به گره یک دستگاه بلوکی باشد، یا هر فایل دیگری که در این حالت دستگاه بلوکی پشتیبان سیستم فایل آن فایل استفاده می‌شود. اگر پهنای باند با K، M، G یا T پسوند داشته باشد، مقدار به‌ترتیب بر حسب کیلوبایت، مگابایت، گیگابایت یا ترابایت در مبنای 1000 تجزیه می‌شود. (مثال: "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). این گزینه‌ها ویژگی‌های گروه کنترلی "io.max" را کنترل می‌کنند. از این گزینه چندین بار برای تعیین حدود پهنای باند برای چندین دستگاه استفاده کنید. برای جزئیات در مورد این ویژگی گروه کنترلی به فایل‌های واسط IO (IO Interface Files)[8] مراجعه کنید.

محدودیت‌های مشابه در کشف دستگاه بلوکی همانند IODeviceWeight= در اینجا نیز اعمال می‌شود؛ به توضیحات بالا مراجعه کنید.

در نسخه 230 اضافه شد.

IOReadIOPSMax=device IOPS, IOWriteIOPSMax=device IOPS

این تنظیمات، کنترل‌کننده io را در سلسله‌مراتب یکپارچه کنترل می‌کنند.

حداکثر حد عملیات ورودی/خروجی در ثانیه (IOs-Per-Second یا IOPS) بلوکی را به‌ازای هر دستگاه برای فرآیندهای اجراشده تعیین می‌کنند، در صورتی که سلسله‌مراتب یکپارچه گروه کنترلی در سیستم استفاده شود. این حد از نوع work-conserving نیست و فرآیندهای اجراشده حتی در صورت داشتن ظرفیت بیکار توسط دستگاه مجاز به استفاده بیشتر نیستند. یک جفت جداشده با فاصله شامل یک مسیر فایل و یک مقدار IOPS را برای تعیین IOPS مخصوص دستگاه دریافت می‌کنند. مسیر فایل می‌تواند مسیری به یک گره دستگاه بلوکی باشد یا هر فایل دیگری که در این حالت دستگاه بلوکی پشتیبان سیستم فایل فایل استفاده می‌شود. اگر مقدار IOPS با K، M، G یا T پسوند داشته باشد، مقدار مشخص‌شده به‌ترتیب بر حسب KiloIOPS، MegaIOPS، GigaIOPS یا TeraIOPS بر مبنای 1000 تجزیه می‌شود. (مثال: "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). این گزینه‌ها ویژگی‌های گروه کنترلی "io.max" را کنترل می‌کنند. از این گزینه چندین بار برای تنظیم حدود IOPS برای چندین دستگاه استفاده کنید. برای جزئیات درباره این ویژگی گروه کنترلی به فایل‌های واسط IO (IO Interface Files)[8] مراجعه کنید.

محدودیت‌های مشابه در کشف دستگاه بلوکی همانند IODeviceWeight= در اینجا نیز اعمال می‌شود؛ به توضیحات بالا مراجعه کنید.

در نسخه 230 اضافه شد.

IODeviceLatencyTargetSec=device target

این تنظیم، کنترل‌کننده io را در سلسله‌مراتب یکپارچه کنترل می‌کند.

هدف میانگین تأخیر I/O را به‌ازای هر دستگاه برای فرآیندهای اجراشده تعیین می‌کند، در صورتی که سلسله‌مراتب یکپارچه گروه کنترلی در سیستم استفاده شود. یک مسیر فایل و یک بازه زمانی جداشده با فاصله را برای تعیین هدف تأخیر مخصوص دستگاه می‌گیرد. (مثال: "/dev/sda 25ms"). مسیر فایل ممکن است به‌صورت مسیر به یک گره دستگاه بلوکی یا هر فایل دیگری مشخص شود که در این حالت دستگاه بلوکی پشتیبان سیستم فایل آن فایل تعیین می‌گردد. این گزینه ویژگی گروه کنترلی "io.latency" را کنترل می‌کند. از این گزینه چندین بار برای تنظیم هدف تأخیر برای چندین دستگاه استفاده کنید. برای جزئیات در مورد این ویژگی گروه کنترلی به فایل‌های واسط IO (IO Interface Files)[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 جداشده با فاصله را دریافت می‌کنند که هر کدام می‌توانند به‌صورت اختیاری با یک طول پیشوند آدرس بر حسب بیت بعد از یک نویسه "/" همراه باشند. اگر پسوند حذف شود، آدرس به عنوان یک آدرس میزبان (host) در نظر گرفته می‌شود، یعنی فیلتر تمام آدرس را پوشش می‌دهد (32 بیت برای IPv4، 128 بیت برای IPv6).

فهرست‌های دسترسی پیکربندی‌شده با این گزینه بر تمامی سوکت‌های ایجادشده توسط فرآیندهای این واحد (یا در مورد واحدهای سوکت، مرتبط با آن) اعمال می‌شوند. این فهرست‌ها به‌طور ضمنی با هر فهرستی که برای هر یک از واحدهای برش والد که این واحد ممکن است عضوی از آن باشد پیکربندی شده است، ترکیب می‌شوند. به‌طور پیش‌فرض، هر دو فهرست دسترسی خالی هستند. هم ترافیک ورودی (ingress) و هم ترافیک خروجی (egress) توسط این تنظیمات فیلتر می‌شوند. در مورد ترافیک ورودی، آدرس IP مبدأ در برابر این فهرست‌های دسترسی بررسی می‌شود و در مورد ترافیک خروجی، آدرس IP مقصد بررسی می‌گردد. قوانین زیر به‌ترتیب اعمال می‌شوند:

•اگر آدرس IP بررسی‌شده با ورودی‌ای در فهرست IPAddressAllow= تطابق داشته باشد، دسترسی داده می‌شود.
•در غیر این صورت، اگر آدرس IP بررسی‌شده با ورودی‌ای در فهرست IPAddressDeny= تطابق داشته باشد، دسترسی رد می‌شود.
•در غیر این صورت، دسترسی داده می‌شود.

به‌منظور پیاده‌سازی یک فایروال IP بر پایه فهرست مجاز (allow-list)، توصیه می‌شود از تنظیم 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 تمام آدرس‌های loopback محلی
link-local 169.254.0.0/16 fe80::/64 تمام آدرس‌های IP پیوند-محلی
multicast 224.0.0.0/4 ff00::/8 تمام آدرس‌های چندپخشی IP

توجه داشته باشید که این تنظیمات ممکن است در برخی سیستم‌ها پشتیبانی نشوند (برای مثال اگر پشتیبانی از گروه کنترلی eBPF در هسته زیرین یا مدیر کانتینر فعال نباشد). در این صورت این تنظیمات هیچ اثری نخواهند داشت. بنابراین در صورت تمایل به سازگاری با چنین سیستم‌هایی، توصیه می‌شود منحصراً به آن‌ها برای امنیت IP تکیه نکنید.

این گزینه را نمی‌توان با افزودن پیشوند "+" به مسیر اجرایی در واحد سرویس دور زد، زیرا بر کل گروه کنترلی اعمال می‌شود.

در نسخه 235 اضافه شد.

SocketBindAllow=bind-rule, SocketBindDeny=bind-rule

محدودیت‌هایی را بر توانایی فرآیندهای واحد برای فراخوانی bind(2) روی یک سوکت پیکربندی می‌کند. هر دو امکان تعریف قوانین مجاز و غیرمجاز را فراهم می‌سازند که مشخص می‌کنند یک سوکت به چه آدرس‌هایی می‌تواند متصل (bound) شود.

قاعده 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) توسط فرآیندهای واحد اعمال می‌شود، صرف‌نظر از اینکه در کدام فضای نام شبکه (network namespace) قرار گرفته باشند. یا به عبارت دیگر: تغییر فضای نام شبکه سازوکار مناسبی برای فرار از این محدودیت‌ها روی bind() نیست.

مثال‌ها:

...
# اجازه اتصال آدرس‌های سوکت IPv6 با پورت بزرگ‌تر یا مساوی 10000.
[Service]
SocketBindAllow=ipv6:10000-65535
SocketBindDeny=any
...
# اجازه اتصال آدرس‌های سوکت IPv4 و IPv6 با پورت‌های 1234 و 4321.
[Service]
SocketBindAllow=1234
SocketBindAllow=4321
SocketBindDeny=any
...
# رد اتصال آدرس‌های سوکت IPv6.
[Service]
SocketBindDeny=ipv6
...
# رد اتصال آدرس‌های سوکت IPv4 و IPv6.
[Service]
SocketBindDeny=any
...
# اجازه اتصال فقط روی TCP
[Service]
SocketBindAllow=tcp
SocketBindDeny=any
...
# اجازه اتصال فقط روی IPv6/TCP
[Service]
SocketBindAllow=ipv6:tcp
SocketBindDeny=any
...
# اجازه اتصال پورت‌های در بازه 10000-65535 روی IPv4/UDP.
[Service]
SocketBindAllow=ipv4:udp:10000-65535
SocketBindDeny=any
...

این گزینه را نمی‌توان با افزودن پیشوند "+" به مسیر اجرایی در واحد سرویس دور زد، زیرا بر کل گروه کنترلی اعمال می‌شود.

در نسخه 249 اضافه شد.

RestrictNetworkInterfaces=

فهرستی از نام‌های واسط شبکه جداشده با فاصله را می‌گیرد. این گزینه واسط‌های شبکه‌ای را که فرآیندهای این واحد می‌توانند استفاده کنند محدود می‌سازد. به‌طور پیش‌فرض، فرآیندها فقط می‌توانند از واسط‌های شبکه فهرست‌شده استفاده کنند (فهرست مجاز یا allow-list). اگر اولین نویسه قاعده "~" باشد، اثر آن معکوس می‌شود: فرآیندها فقط می‌توانند از واسط‌های شبکه‌ای استفاده کنند که در فهرست نیستند (فهرست غیرمجاز یا deny-list).

این گزینه می‌تواند چندین بار ظاهر شود، که در این حالت نام‌های واسط شبکه ادغام می‌شوند. اگر رشته خالی اختصاص داده شود، مجموعه بازنشانی شده و تمام انتساب‌های قبلی بی‌اثر خواهند شد.

اگر هر دو نوع این گزینه را مشخص کنید (یعنی فهرست مجاز و فهرست غیرمجاز)، اولین موردی که با آن مواجه می‌شود اولویت خواهد داشت و اقدام پیش‌فرض (مجاز در برابر غیرمجاز) را دیکته می‌کند. سپس موارد بعدی این گزینه بسته به نوع آن و اقدام پیش‌فرض، نام‌های واسط شبکه فهرست‌شده را از مجموعه اضافه یا حذف خواهند کرد.

با واسط loopback ("lo") به هیچ روش خاصی رفتار نمی‌شود، شما باید آن را به‌طور صریح در فایل واحد پیکربندی کنید.

مثال 1: فهرست مجاز (allow-list)

RestrictNetworkInterfaces=eth1
RestrictNetworkInterfaces=eth2

برنامه‌های درون واحد فقط قادر به استفاده از واسط‌های شبکه eth1 و eth2 خواهند بود.

مثال 2: فهرست غیرمجاز (deny-list)

RestrictNetworkInterfaces=~eth1 eth2

برنامه‌های درون واحد قادر به استفاده از هر واسط شبکه‌ای به جز eth1 و eth2 خواهند بود.

مثال 3: ترکیبی

RestrictNetworkInterfaces=eth1 eth2
RestrictNetworkInterfaces=~eth1

برنامه‌های درون واحد فقط قادر به استفاده از واسط شبکه eth2 خواهند بود.

این گزینه را نمی‌توان با افزودن پیشوند "+" به مسیر اجرایی در واحد سرویس دور زد، زیرا بر کل گروه کنترلی اعمال می‌شود.

در نسخه 250 اضافه شد.

NFTSet=family:table:set

این تنظیم روشی برای ادغام شناسه‌های پویای cgroup، کاربر و گروه در قوانین فایروال با مجموعه‌های NFT[9] فراهم می‌کند. مزیت استفاده از این تنظیم این است که می‌توان شناسه‌ها را به‌راحتی به عنوان انتخاب‌کننده‌ها (selectors) در قوانین فایروال استفاده کرد و این به نوبه خود امکان فیلتر کردن دقیق‌تر را فراهم می‌سازد. قوانین NFT برای تطابق cgroup از شناسه‌های عددی cgroup استفاده می‌کنند، که با هر بار راه‌اندازی مجدد سرویس تغییر می‌کنند و استفاده از آن‌ها را در محیط systemd بدون این تنظیم دشوار می‌سازند. شناسه‌های پویا و تصادفی استفاده‌شده توسط DynamicUser= نیز می‌توانند با این تنظیم ادغام شوند.

این گزینه فهرستی از تعاریف مجموعه NFT جداشده با فاصله را انتظار دارد. هر تعریف شامل یک چندتایی (tuple) جداشده با دونقطه از نوع منبع (یکی از "cgroup", "user" یا "group")، خانواده آدرس NFT (یکی از "arp", "bridge", "inet", "ip", "ip6" یا "netdev")، نام جدول و نام مجموعه است. نام‌های جداول و مجموعه‌ها باید با محدودیت‌های لغوی نام‌های جدول NFT مطابقت داشته باشند. نوع عنصر استفاده‌شده در فیلتر NFT باید با نوع ضمنی دستورالعمل ("cgroup"، "user" یا "group") مطابق جدول زیر مطابقت داشته باشد. هنگامی که یک گروه کنترلی یا یک واحد ایجاد و محقق می‌شود، شناسه مربوطه به مجموعه‌های NFT اضافه می‌شود و هنگامی که گروه کنترلی یا واحد حذف می‌شود، از مجموعه حذف خواهد شد. systemd تنها عناصر را به مجموعه‌ها وارد (یا از آن‌ها حذف) می‌کند، بنابراین قوانین، جداول و مجموعه‌های NFT مرتبط باید از قبل در جای دیگری آماده شده باشند. خطاهای ناشی از مدیریت مجموعه‌ها نادیده گرفته خواهند شد.

جدول 2. مقادیر تعریف‌شده برای type منبع

نوع منبع توضیحات نام نوع NFT متناظر
"cgroup" شناسه گروه کنترلی "cgroupsv2"
"user" شناسه کاربر "meta skuid"
"group" شناسه گروه "meta skgid"

اگر قوانین فایروال مجدداً نصب شوند به‌طوری که محتوای مجموعه‌های 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 اضافه شد.

IPIngressFilterPath=BPF_FS_PROGRAM_PATH, IPEgressFilterPath=BPF_FS_PROGRAM_PATH

فیلترهای ترافیک شبکه سفارشی پیاده‌سازی‌شده به عنوان برنامه‌های BPF را اضافه می‌کند، که بر تمامی بسته‌های IP ارسال‌شده و دریافت‌شده روی سوکت‌های AF_INET و AF_INET6 اعمال می‌شود. یک مسیر مطلق به یک برنامه پین‌شده BPF در سیستم فایل مجازی BPF (/sys/fs/bpf/) را می‌گیرد.

فیلترهای پیکربندی‌شده با این گزینه بر تمامی سوکت‌های ایجادشده توسط فرآیندهای این واحد (یا در مورد واحدهای سوکت، مرتبط با آن) اعمال می‌شوند. این فیلترها علاوه بر فیلترهای هر یک از واحدهای برش والد که این واحد ممکن است عضوی از آن‌ها باشد و همچنین فیلترهای IPAddressAllow= و IPAddressDeny= در هر یک از این واحدها بارگذاری می‌شوند. به‌طور پیش‌فرض، هیچ فیلتری مشخص نشده است.

اگر این تنظیمات چندین بار در همان واحد استفاده شوند، تمامی برنامه‌های مشخص‌شده پیوست (attached) می‌شوند. اگر یک رشته خالی به این تنظیمات اختصاص داده شود، فهرست برنامه‌ها بازنشانی شده و تمام برنامه‌های مشخص‌شده قبلی نادیده گرفته می‌شوند.

اگر مسیر BPF_FS_PROGRAM_PATH در انتساب IPIngressFilterPath= پیش‌تر توسط قلاب ورودی (ingress hook) گزینه 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 (BPF documentation)[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 به cgroup واحد پیوست می‌شوند، که امکان پیوست‌های بعدی از همان type را در سلسله‌مراتب cgroup که در راس آن cgroup واحد قرار دارد فراهم می‌سازد.

مثال‌ها:

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) انجام می‌شود، بنابراین می‌توانید از نویسه‌های عام "*" و "?" استفاده کنید. (توجه داشته باشید که چنین نویسه‌های عامی برای مشخص‌کردن مسیر گره دستگاه در دسترس نیستند!). برای تطابق گره‌های دستگاه بر اساس شماره‌های اصلی/فرعی (major/minor) عددی، از مسیرهای گره دستگاه در دایرکتوری‌های /dev/char/ و /dev/block/ استفاده کنید. با این حال، تطابق دستگاه‌ها بر اساس major/minor عموماً توصیه نمی‌شود زیرا انتساب‌ها نه پایدار هستند و نه بین سیستم‌ها یا نسخه‌های مختلف هسته قابل حمل می‌باشند.

مثال‌ها: /dev/sda5 مسیری به یک گره دستگاه است که به یک دستگاه بلوکی ATA یا SCSI ارجاع می‌دهد. "char-pts" و "char-alsa" به‌ترتیب مشخص‌کننده‌هایی برای تمام شبه‌TTYها و تمام دستگاه‌های صوتی ALSA هستند. "char-cpu/*" مشخص‌کننده‌ای است که با تمامی گروه‌های دستگاه مرتبط با CPU تطابق دارد.

توجه داشته باشید که فهرست‌های مجاز تعریف‌شده به این روش تنها باید به گروه‌های دستگاهی ارجاع دهند که در زمان شروع واحد قابل شناسایی (resolvable) هستند. هر گروه دستگاهی که در آن زمان قابل شناسایی نباشد به فهرست مجاز دستگاه اضافه نخواهد شد. برای دور زدن این محدودیت، می‌توانید واحدهای سرویس را با یک جفت خط 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=

نام واحد برشی (slice unit) است که واحد باید در آن قرار گیرد. پیش‌فرض system.slice برای تمام واحدهای نمونه‌سازی‌نشده از تمام انواع واحدها است (به جز خود واحدهای برش که در زیر آمده است). واحدهای نمونه به‌طور پیش‌فرض در یک زیربرش از system.slice قرار می‌گیرند که بر اساس نام الگو نام‌گذاری شده است.

این گزینه ممکن است برای چینش واحدهای systemd در سلسله‌مراتبی از برش‌ها استفاده شود که هر کدام ممکن است تنظیمات منبع روی آن‌ها اعمال شده باشد.

برای واحدهای از نوع برش، تنها مقدار پذیرفته‌شده برای این تنظیم، برش والد است. از آنجا که نام یک واحد برش نشان‌دهنده برش والد است، بنابراین تنظیم مستقیم این پارامتر برای واحدهای برش همیشه زائد و اضافی است.

هنگام تکیه بر انتساب برش پیش‌فرض در واحدهای سرویس الگودار که DefaultDependencies=no روی آن‌ها تنظیم شده است، باید دقت ویژه‌ای به عمل آید؛ برای جزئیات به systemd.service(5)، بخش "Default Dependencies" مراجعه کنید.

در نسخه 208 اضافه شد.

Delegate=

واگذاری تقسیم‌بندی بیشتر کنترل منابع به فرآیندهای واحد را فعال می‌کند. واحدهایی که این قابلیت در آن‌ها فعال باشد می‌توانند زیرسلسله‌مراتب اختصاصی خود از گروه‌های کنترلی را در زیر گروه کنترلی خود واحد ایجاد و مدیریت کنند. برای سرویس‌های غیرممتاز (یعنی آن‌هایی که از تنظیم User= استفاده می‌کنند)، گروه کنترلی واحد برای کاربر مربوطه قابل دسترسی خواهد شد.

هنگامی که فعال باشد، مدیر سرویس از دستکاری گروه‌های کنترلی یا انتقال فرآیندها به زیر گروه کنترلی واحد خودداری می‌کند، به‌طوری که مفهوم روشنی از مالکیت برقرار می‌شود: درخت گروه کنترلی در سطح گروه کنترلی واحد و بالاتر از آن (یعنی به‌سمت گروه کنترلی ریشه) متعلق به مدیر سرویس میزبان بوده و توسط آن مدیریت می‌شود، در حالی که درخت گروه کنترلی زیر گروه کنترلی واحد متعلق به خود واحد بوده و توسط آن مدیریت می‌شود.

یک آرگومان بولی یا فهرستی (احتمالاً خالی) از نام‌های کنترل‌کننده‌های گروه کنترلی را می‌گیرد. اگر true باشد، واگذاری فعال شده و تمام کنترل‌کننده‌های پشتیبانی‌شده برای واحد فعال می‌شوند و برای مدیریت در دسترس فرآیندهای واحد قرار می‌گیرند. اگر false باشد، واگذاری کاملاً غیرفعال می‌شود (و هیچ کنترل‌کننده اضافی فعال نخواهد شد). اگر روی فهرستی از کنترل‌کننده‌ها تنظیم شود، واگذاری فعال شده و کنترل‌کننده‌های مشخص‌شده برای واحد فعال می‌گردند. انتساب رشته خالی واگذاری را فعال می‌کند، اما فهرست کنترل‌کننده‌ها را بازنشانی کرده و تمام انتساب‌های قبل از این بی‌اثر خواهند شد. توجه داشته باشید که علاوه بر موارد مشخص‌شده، ممکن است کنترل‌کننده‌های دیگری نیز بسته به پیکربندی واحد برش دربرگیرنده یا سایر واحدهای موجود در آن در دسترس قرار گیرند. پیش‌فرض false است.

توجه داشته باشید که واگذاری کنترل‌کننده به کدهای با امتیاز کمتر تنها روی سلسله‌مراتب یکپارچه گروه کنترلی ایمن است. بر این اساس، دسترسی به کنترل‌کننده‌های مشخص‌شده به سرویس‌های غیرممتاز در سلسله‌مراتب سنتی داده نخواهد شد، حتی در صورت درخواست.

نام‌های کنترل‌کننده‌های زیر را می‌توان مشخص کرد: cpu, cpuacct, cpuset, io, blkio, memory, devices, pids, bpf-firewall و bpf-devices.

با این حال همه این کنترل‌کننده‌ها روی تمام هسته‌ها در دسترس نیستند، و برخی مختص سلسله‌مراتب یکپارچه هستند در حالی که برخی دیگر مختص سلسله‌مراتب سنتی می‌باشند. همچنین توجه داشته باشید که هسته ممکن است از کنترل‌کننده‌های دیگری پشتیبانی کند که هنوز در اینجا پوشش داده نشده‌اند، زیرا واگذاری یا اصلاً برای آن‌ها پشتیبانی نمی‌شود یا به‌صورت تمیز تعریف نشده است.

توجه داشته باشید که به دلیل ماهیت سلسله‌مراتبی cgroup، هر کنترل‌کننده‌ای که واگذار شود برای واحدهای والد و هم‌سطح واحد دارای واگذاری فعال خواهد شد.

برای جزئیات بیشتر درباره مدل واگذاری به واسط‌های گروه‌های کنترلی و واگذاری (Control Group APIs and Delegation)[12] مراجعه کنید.

در نسخه 218 اضافه شد.

DelegateSubgroup=

فرآیندهای واحد را در زیرگروه مشخص‌شده از گروه کنترلی واحد قرار می‌دهد. یک نام معتبر گروه کنترلی (نه یک مسیر!) را به عنوان پارامتر می‌گیرد، یا یک رشته خالی برای غیرفعال کردن این ویژگی. پیش‌فرض غیرفعال (off) است. نام گروه کنترلی باید به عنوان نام فایل قابل استفاده باشد و از تداخل با فایل‌های ویژگی گروه کنترلی هسته جلوگیری کند (یعنی cgroup.procs نام قابل قبولی نیست، زیرا هسته یک فایل ویژگی بومی گروه کنترلی با این نام ارائه می‌دهد). این گزینه هیچ اثری ندارد مگر اینکه واگذاری گروه کنترلی از طریق Delegate= فعال شده باشد؛ به بالا مراجعه کنید. توجه داشته باشید که این تنظیم تنها بر فرآیندهای "اصلی" یک واحد اعمال می‌شود، یعنی برای سرویس‌ها بر ExecStart=، اما بر ExecReload= و موارد مشابه اعمال نمی‌شود. در صورت فعال بودن واگذاری، موارد اخیر همیشه درون زیرگروهی به نام .control قرار می‌گیرند. هنگامی که فرآیندی در زیرگروه مشخص‌شده شروع می‌شود، آن زیرگروه به‌طور خودکار ایجاد می‌گردد (و احتمالاً مالکیت آن به کاربر/گروه پیکربندی‌شده واحد منتقل می‌شود).

این گزینه برای جلوگیری از انتقال دستی فرآیند فراخوانی‌شده به یک زیرگروه پس از شروع آن مفید است. از آنجا که هیچ فرآیندی نباید در گره‌های داخلی درخت گروه کنترلی قرار گیرد، تقریباً همیشه لازم است که فرآیند اصلی ("نظارت‌کننده") یک واحد که واگذاری در آن فعال است در یک زیرگروه اجرا شود.

در نسخه 254 اضافه شد.

DisableControllers=

از فعال شدن کنترل‌کننده‌ها برای فرزندان یک واحد جلوگیری می‌کند. اگر کنترل‌کننده فهرست‌شده قبلاً در زیردرخت آن در حال استفاده باشد، کنترل‌کننده از زیردرخت حذف خواهد شد. این ویژگی می‌تواند برای جلوگیری از توانایی پیکربندی در واحدهای فرزند برای فعال‌سازی ضمنی یا صریح یک کنترل‌کننده استفاده شود. پیش‌فرض خالی است.

می‌توان چندین کنترل‌کننده را که با فاصله جدا شده‌اند مشخص کرد. همچنین می‌توانید DisableControllers= را چندین بار ارسال کنید، که در این حالت هر نمونه جدید کنترل‌کننده دیگری را برای غیرفعال‌سازی اضافه می‌کند. ارسال DisableControllers= به‌تنهایی بدون وجود نام هیچ کنترل‌کننده‌ای، فهرست کنترل‌کننده‌های غیرفعال‌شده را بازنشانی می‌کند.

ممکن است غیرفعال کردن یک کنترل‌کننده پس از شروع واحدها امکان‌پذیر نباشد، در صورتی که واحد یا هر فرزندی از واحد مورد نظر، کنترل‌کننده‌ها را به فرزندان خود واگذار کرده باشد، زیرا هر زیردرخت واگذارشده از سلسله‌مراتب cgroup توسط systemd مدیریت نمی‌شود.

نام‌های کنترل‌کننده‌های زیر را می‌توان مشخص کرد: cpu, cpuacct, cpuset, io, blkio, memory, devices, pids, bpf-firewall و bpf-devices.

در نسخه 240 اضافه شد.

ManagedOOMSwap=auto|kill, ManagedOOMMemoryPressure=auto|kill

مشخص می‌کند که systemd-oomd.service(8) چگونه روی cgroups این واحد عمل خواهد کرد. پیش‌فرض auto است.

هنگامی که روی kill تنظیم شود، واحد به نامزدی برای نظارت توسط systemd-oomd تبدیل می‌شود. اگر cgroup از محدودیت‌های تعیین‌شده توسط oomd.conf(5) یا پیکربندی واحد فراتر رود، systemd-oomd یک cgroup نواده را انتخاب کرده و سیگنال SIGKILL را به تمام فرآیندهای زیر آن ارسال می‌کند. می‌توانید جزئیات بیشتری درباره نامزدها و رفتار خاتمه (kill behavior) در systemd-oomd.service(8) و oomd.conf(5) بیابید.

تنظیم هر یک از این ویژگی‌ها روی kill همچنین منجر به ایجاد وابستگی‌های After= و Wants= روی systemd-oomd.service می‌شود مگر اینکه DefaultDependencies=no تنظیم شده باشد.

هنگامی که روی auto تنظیم شود، systemd-oomd به‌طور فعال از داده‌های این cgroup برای نظارت و تشخیص استفاده نخواهد کرد. با این حال، اگر یک cgroup نیاکان یکی از این ویژگی‌ها را روی kill تنظیم کرده باشد، واحد دارای auto همچنان می‌تواند نامزدی برای خاتمه توسط systemd-oomd باشد.

در نسخه 247 اضافه شد.

ManagedOOMMemoryPressureLimit=

حد پیش‌فرض فشار حافظه تعیین‌شده توسط oomd.conf(5) را برای cgroup این واحد بازنویسی (override) می‌کند. یک مقدار درصدی بین 0% تا 100% به‌صورت فراگیر را می‌گیرد. پیش‌فرض 0% است که به معنای استفاده از پیش‌فرض تعیین‌شده توسط oomd.conf(5) است. این ویژگی نادیده گرفته می‌شود مگر اینکه ManagedOOMMemoryPressure=kill تنظیم شده باشد.

در نسخه 247 اضافه شد.

ManagedOOMMemoryPressureDurationSec=

مدت زمان پیش‌فرض فشار حافظه تعیین‌شده توسط oomd.conf(5) را برای cgroup این واحد بازنویسی می‌کند. مقدار مشخص‌شده از واحدهای زمانی مانند "ms" یا "μs" پشتیبانی می‌کند؛ برای جزئیات درباره نحو مجاز به systemd.time(7) مراجعه کنید. باید روی مقدار خالی یا مقداری حداقل برابر با 1s تنظیم شود. پیش‌فرض خالی است که به معنای استفاده از مقدار پیش‌فرض تعیین‌شده توسط oomd.conf(5) می‌باشد. این ویژگی نادیده گرفته می‌شود مگر اینکه ManagedOOMMemoryPressure=kill تنظیم شده باشد.

در نسخه 257 اضافه شد.

ManagedOOMPreference=none|avoid|omit

امکان کاهش اولویت یا نادیده گرفتن cgroup این واحد را به عنوان نامزد در هنگامی که systemd-oomd نیاز به اقدام دارد فراهم می‌سازد. برای استفاده از avoid یا omit نیازمند پشتیبانی از ویژگی‌های گسترش‌یافته (به xattr(7) مراجعه کنید) است.

هنگام محاسبه نامزدها برای کاهش مصرف swap، systemd-oomd تنها در صورتی به این ویژگی‌های گسترش‌یافته احترام می‌گذارد که cgroup واحد متعلق به root باشد.

هنگام محاسبه نامزدها برای کاهش فشار حافظه، systemd-oomd تنها در صورتی به این ویژگی‌های گسترش‌یافته احترام می‌گذارد که cgroup واحد متعلق به root باشد، یا اگر مالک cgroup واحد و مالک cgroup نیاکان نظارت‌شده یکسان باشند. برای مثال اگر 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 منتقل می‌کند، که تنها در صورتی این cgroup را انتخاب خواهد کرد که نامزد مناسب دیگری وجود نداشته باشد.

اگر این ویژگی روی omit تنظیم شود، مدیر سرویس این موضوع را به systemd-oomd منتقل می‌کند، که این cgroup را به عنوان نامزد نادیده خواهد گرفت و هیچ اقدامی روی آن انجام نخواهد داد.

توصیه می‌شود از avoid و omit با احتیاط استفاده شود، زیرا می‌تواند تأثیر نامطلوبی بر رفتار خاتمه‌دهی systemd-oomd بگذارد. همچنین توجه داشته باشید که این ویژگی‌های گسترش‌یافته به‌صورت بازگشتی روی cgroupهای زیر cgroup این واحد اعمال نمی‌شوند.

پیش‌فرض none است که به این معنی است systemd-oomd گروه کنترلی این واحد را همان‌طور که در systemd-oomd.service(8) و oomd.conf(5) تعریف شده است رتبه‌بندی خواهد کرد.

در نسخه 248 اضافه شد.

MemoryPressureWatch=

نظارت بر فشار حافظه را برای فرآیندهای فراخوانی‌شده کنترل می‌کند. یک مقدار بولی یا یکی از مقادیر "auto" و "skip" را می‌گیرد. اگر "no" باشد، با تنظیم متغیر محیطی $MEMORY_PRESSURE_WATCH روی رشته دقیق /dev/null به سرویس می‌گوید که رویدادهای فشار حافظه را تماشا نکند. اگر "yes" باشد، به سرویس می‌گوید رویدادهای فشار حافظه را زیر نظر بگیرد. این کار حسابداری حافظه را برای سرویس فعال کرده و اطمینان حاصل می‌کند که فایل ویژگی cgroup با نام memory.pressure برای خواندن و نوشتن توسط کاربر سرویس قابل دسترسی است. سپس متغیر محیطی $MEMORY_PRESSURE_WATCH را برای فرآیندهای فراخوانی‌شده توسط واحد روی مسیر سیستم فایل به این فایل تنظیم می‌کند. اطلاعات آستانه پیکربندی‌شده با MemoryPressureThresholdSec= در متغیر محیطی $MEMORY_PRESSURE_WRITE کدگذاری می‌شود. اگر مقدار "auto" تنظیم شده باشد، در صورتی که حسابداری حافظه به هر حال برای واحد فعال باشد، پروتکل فعال می‌شود و در غیر این صورت غیرفعال خواهد بود. اگر روی "skip" تنظیم شود، این منطق نه فعال و نه غیرفعال می‌شود و این دو متغیر محیطی تنظیم نخواهند شد.

توجه داشته باشید که سرویس‌ها در استفاده از این دو متغیر محیطی آزاد هستند، اما اگر آن‌ها را نادیده بگیرند نیز مشکلی ایجاد نمی‌شود. مدیریت فشار حافظه باید به‌صورت اختصاصی در هر سرویس پیاده‌سازی شود و معمولاً برای نرم‌افزارهای مختلف معانی متفاوتی دارد. برای جزئیات بیشتر در مورد مدیریت فشار حافظه به مدیریت فشار حافظه در systemd (Memory Pressure Handling in systemd)[13] مراجعه کنید.

سرویس‌های پیاده‌سازی‌شده با استفاده از sd-event(3) می‌توانند از sd_event_add_memory_pressure(3) برای نظارت و مدیریت رویدادهای فشار حافظه استفاده کنند.

اگر به‌صراحت تنظیم نشده باشد، پیش‌فرض روی تنظیم DefaultMemoryPressureWatch= در systemd-system.conf(5) است.

در نسخه 254 اضافه شد.

MemoryPressureThresholdSec=

زمان آستانه فشار حافظه را برای ناظر فشار حافظه همان‌طور که از طریق MemoryPressureWatch= پیکربندی شده است تنظیم می‌کند. حداکثر تأخیر تخصیص را قبل از اینکه یک رویداد فشار حافظه به سرویس علامت داده شود، در هر پنجره 2 ثانیه‌ای مشخص می‌سازد. در صورت عدم تعیین، پیش‌فرض روی تنظیم DefaultMemoryPressureThresholdSec= در systemd-system.conf(5) خواهد بود (که خود به‌طور پیش‌فرض 200ms است). مقدار مشخص‌شده یک واحد زمانی مانند "ms" یا "μs" را انتظار دارد؛ برای جزئیات درباره نحو مجاز به systemd.time(7) مراجعه کنید.

در نسخه 254 اضافه شد.

CoredumpReceive=

یک آرگومان بولی می‌گیرد. این تنظیم برای فعال‌سازی هدایت coredump برای کانتینرهایی که متعلق به cgroup این واحد هستند استفاده می‌شود. واحدهایی با CoredumpReceive=yes باید با Delegate=yes نیز پیکربندی شده باشند. پیش‌فرض false است.

هنگامی که systemd-coredump در حال مدیریت یک coredump برای فرآیندی از یک کانتینر است، اگر فرآیند رهبر کانتینر از نوادگان یک cgroup با CoredumpReceive=yes و Delegate=yes باشد، آنگاه systemd-coredump تلاش خواهد کرد تا coredump را به systemd-coredump درون کانتینر هدایت کند. همچنین systemd-coredump(8) را ببینید.

در نسخه 255 اضافه شد.

systemd 252

گزینه‌ها برای کنترل سلسله‌مراتب سنتی گروه کنترلی (گروه‌های کنترلی نسخه 1 (Control Groups version 1)[14]) اکنون کاملاً منسوخ (deprecated) شده‌اند: CPUShares=weight, StartupCPUShares=weight, MemoryLimit=bytes, BlockIOAccounting=, BlockIOWeight=weight, StartupBlockIOWeight=weight, BlockIODeviceWeight=device weight, BlockIOReadBandwidth=device bytes, BlockIOWriteBandwidth=device bytes. لطفاً به سلسله‌مراتب یکپارچه cgroup مهاجرت کنید.

در نسخه 252 اضافه شد.

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 (Control Groups v2)[2]

1.
New Control Group Interfaces
https://systemd.io/CONTROL_GROUP_INTERFACE
2.
Control Groups v2
https://docs.kernel.org/admin-guide/cgroup-v2.html
3.
CFS Scheduler
https://docs.kernel.org/scheduler/sched-design-CFS.html
4.
CFS Bandwidth Control
https://docs.kernel.org/scheduler/sched-bwc.html
5.
Memory Interface Files
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 controller
https://docs.kernel.org/admin-guide/cgroup-v2.html#pid
8.
IO Interface Files
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 documentation
https://docs.kernel.org/bpf
12.
Control Group APIs and Delegation
https://systemd.io/CGROUP_DELEGATION
13.
Memory Pressure Handling in systemd
https://systemd.io/MEMORY_PRESSURE
14.
Control Groups version 1
https://docs.kernel.org/admin-guide/cgroup-v1/index.html
systemd 257.13