'\" t
.TH "SYSTEMD\&.EXEC" "5" "" "systemd 257.13" "systemd.exec"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "نام (NAME)"
systemd.exec \- تنظیمات محیط و پارامترهای اجرای فرآیندها در واحدهای systemd
.SH "خلاصه دستور (SYNOPSIS)"
.PP
\fIservice\fR\&.service,
\fIsocket\fR\&.socket,
\fImount\fR\&.mount,
\fIswap\fR\&.swap
.SH "توضیحات (DESCRIPTION)"
.PP
فایل‌های پیکربندی واحد برای سرویس‌ها (services)، سوکت‌ها (sockets)، نقاط اتصال (mount points) و دستگاه‌های حافظه مجازی (swap devices) زیرمجموعه‌ای از گزینه‌های پیکربندی را به اشتراک می‌گذارند که محیط اجرای فرآیندهای ایجادشده را تعریف می‌کنند\&.
.PP
این صفحه راهنما، گزینه‌های پیکربندی مشترک بین این چهار نوع واحد را فهرست می‌کند\&. برای گزینه‌های عمومی تمامی فایل‌های پیکربندی واحد به
\fBsystemd.unit\fR(5)
و برای اطلاعات بیشتر درباره فایل‌های پیکربندی واحدهای خاص به
\fBsystemd.service\fR(5)،
\fBsystemd.socket\fR(5)،
\fBsystemd.swap\fR(5) و
\fBsystemd.mount\fR(5)
مراجعه کنید\&. گزینه‌های پیکربندی مربوط به اجرا، بسته به نوع واحد، در بخش‌های [Service]، [Socket]، [Mount] یا [Swap] پیکربندی می‌شوند\&.
.PP
علاوه بر این، گزینه‌هایی که منابع را از طریق گروه‌های کنترلی لینوکس (cgroups) کنترل می‌کنند در
\fBsystemd.resource-control\fR(5)
فهرست شده‌اند\&. این گزینه‌ها مکمل گزینه‌های فهرست‌شده در اینجا هستند\&.
.SH "وابستگی‌های ضمنی (IMPLICIT DEPENDENCIES)"
.PP
چند پارامتر اجرایی منجر به اضافه شدن خودکار وابستگی‌های اضافی می‌شوند:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
واحدهایی که
\fIWorkingDirectory=\fR،
\fIRootDirectory=\fR،
\fIRootImage=\fR،
\fIRuntimeDirectory=\fR،
\fIStateDirectory=\fR،
\fICacheDirectory=\fR،
\fILogsDirectory=\fR
یا
\fIConfigurationDirectory=\fR
در آن‌ها تنظیم شده باشد، به‌طور خودکار وابستگی‌هایی از نوع
\fIRequires=\fR
و
\fIAfter=\fR
روی تمامی واحدهای اتصالی که برای دسترسی به مسیرهای مشخص‌شده لازم هستند به دست می‌آورند\&. این معادل فهرست کردن صریح آن‌ها در
\fIRequiresMountsFor=\fR
است\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
مشابهاً، واحدهایی که
\fIPrivateTmp=\fR
در آن‌ها فعال است، به‌طور خودکار وابستگی‌های واحد اتصال برای تمام اتصالات لازم جهت دسترسی به
/tmp/
و
/var/tmp/
را دریافت می‌کنند\&. آن‌ها همچنین یک وابستگی خودکار
\fIAfter=\fR
روی
\fBsystemd-tmpfiles-setup.service\fR(8)
کسب خواهند کرد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
واحدهایی که خروجی استاندارد یا خروجی خطای آن‌ها به
\fBjournal\fR
یا
\fBkmsg\fR
(یا ترکیب آن‌ها با خروجی کنسول، به شرح زیر) متصل است، به‌طور خودکار وابستگی‌هایی از نوع
\fIAfter=\fR
روی
systemd\-journald\&.socket
به دست می‌آورند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
واحدهایی که از
\fILogNamespace=\fR
استفاده می‌کنند، به‌طور خودکار وابستگی‌های ترتیب و نیازمندی روی دو واحد سوکت مرتبط با نمونه‌های
systemd\-journald@\&.service
به دست خواهند آورد\&.
.RE
.SH "مسیرها (PATHS)"
.PP
تنظیمات زیر ممکن است برای تغییر دیدگاه یک سرویس از سیستم‌فایل استفاده شوند\&. لطفاً توجه داشته باشید که مسیرها باید مطلق باشند و نباید شامل جزء مسیر
"\&.\&."
باشند\&.
.PP
\fIExecSearchPath=\fR
.RS 4
یک فهرست جداشده با دونقطه از مسیرهای مطلق را می‌پذیرد که فایل اجرایی مورد استفاده توسط ویژگی‌های
\fIExec*=\fR
(مانند
\fIExecStart=\fR،
\fIExecStop=\fR
و غیره) می‌تواند نسبت به آن‌ها یافت شود\&.
\fIExecSearchPath=\fR
متغیر
\fI/home/debian/.cargo/bin:/home/debian/.local/bin:/home/debian/.local/bin:/usr/local/bin:/home/debian/.cargo/bin:/home/debian/.local/bin:/mnt/data/mahdidev/ollama/bin/bin:/home/debian/.deno/bin:/home/debian/.npm-global/bin:/home/debian/.local/bin:/home/debian/.cargo/bin:/home/debian/.local/bin:/usr/bin:/bin:/usr/games:/usr/local/games\fR
را بازنویسی می‌کند، اگر
\fI/home/debian/.cargo/bin:/home/debian/.local/bin:/home/debian/.local/bin:/usr/local/bin:/home/debian/.cargo/bin:/home/debian/.local/bin:/mnt/data/mahdidev/ollama/bin/bin:/home/debian/.deno/bin:/home/debian/.npm-global/bin:/home/debian/.local/bin:/home/debian/.cargo/bin:/home/debian/.local/bin:/usr/bin:/bin:/usr/games:/usr/local/games\fR
توسط کاربر از طریق
\fIEnvironment=\fR،
\fIEnvironmentFile=\fR
یا
\fIPassEnvironment=\fR
ارائه نشده باشد\&. اختصاص یک رشته خالی، مقدارهای اختصاص‌یافته قبلی را حذف می‌کند و تنظیم
\fIExecSearchPath=\fR
به یک مقدار به دفعات متعدد، به مقدار قبلی اضافه خواهد شد\&.
.sp
اضافه‌شده در نسخه 250\&.
.RE
.PP
\fIWorkingDirectory=\fR
.RS 4
یک مسیر دایرکتوری نسبی به دایرکتوری ریشه سرویس مشخص‌شده توسط
\fIRootDirectory=\fR،
یا مقدار ویژه
"~"
را می‌پذیرد\&. دایرکتوری کاری را برای فرآیندهای اجراشده تنظیم می‌کند\&. اگر روی
"~"
تنظیم شود، از دایرکتوری خانگی کاربر مشخص‌شده در
\fIUser=\fR
استفاده می‌شود\&. در صورت عدم تنظیم، زمانی که systemd به صورت نمونه سیستمی اجرا می‌شود پیش‌فرض روی دایرکتوری ریشه، و در صورت اجرا به عنوان کاربر، پیش‌فرض روی دایرکتوری خانگی کاربر مربوطه قرار می‌گیرد\&. اگر این تنظیم با نویسه
"\-"
پیشوندگذاری شود، نبود دایرکتوری کاری یک خطای مرگبار تلقی نمی‌شود\&. اگر
\fIRootDirectory=\fR/\fIRootImage=\fR
تنظیم نشده باشد، آن‌گاه
\fIWorkingDirectory=\fR
نسبت به ریشه سیستمی که مدیر سرویس را اجرا می‌کند در نظر گرفته می‌شود\&. توجه داشته باشید که تنظیم این پارامتر ممکن است منجر به اضافه شدن وابستگی‌های اضافی به واحد شود (به بالا مراجعه کنید)\&.
.RE
.PP
\fIRootDirectory=\fR
.RS 4
یک مسیر دایرکتوری نسبت به دایرکتوری ریشه میزبان (یعنی ریشه سیستمی که مدیر سرویس را اجرا می‌کند) می‌پذیرد\&. دایرکتوری ریشه را برای فرآیندهای اجراشده، با فراخوانی سیستمی
\fBpivot_root\fR(2)
یا
\fBchroot\fR(2)
تنظیم می‌کند\&. اگر از این گزینه استفاده شود، باید اطمینان حاصل شود که فایل اجرایی فرآیند و تمام فایل‌های کمکی آن در ریشه جدید در دسترس هستند\&. توجه داشته باشید که تنظیم این پارامتر ممکن است منجر به اضافه شدن وابستگی‌های اضافی به واحد شود (به بالا مراجعه کنید)\&.
.sp
تنظیمات
\fIMountAPIVFS=\fR
و
\fIPrivateUsers=\fR
به‌ویژه در ترکیب با
\fIRootDirectory=\fR
مفید هستند\&. برای جزئیات، به بخش‌های زیر مراجعه کنید\&.
.sp
اگر
\fIRootDirectory=\fR/\fIRootImage=\fR
همراه با
\fINotifyAccess=\fR
استفاده شوند، سوکت اطلاع‌رسانی به‌طور خودکار از میزبان در محیط ریشه متصل (mount) می‌شود تا اطمینان حاصل شود که رابط اطلاع‌رسانی می‌تواند به درستی کار کند\&.
.sp
توجه داشته باشید که سرویس‌هایی که از
\fIRootDirectory=\fR/\fIRootImage=\fR
استفاده می‌کنند، نمی‌توانند از طریق پروتکل‌های syslog یا journal در زیرساخت ثبت وقایع میزبان گزارش ثبت کنند، مگر اینکه سوکت‌های مربوطه از میزبان متصل شوند، به‌ویژه:
.sp
فایل
\fBos-release\fR(5)
میزبان برای سرویس (به صورت فقط‌خواندنی) در مسیر
/run/host/os\-release
در دسترس قرار خواهد گرفت\&. این فایل در صورت راه‌اندازی مجدد نرم (soft reboot، مراجعه کنید به:
\fBsystemd-soft-reboot.service\fR(8))،
در صورتی که سرویس برای بقا در برابر آن پیکربندی شده باشد، به‌طور خودکار به‌روزرسانی می‌شود\&.
.PP
\fBمثال\& 1.\& اتصال سوکت‌های گزارش‌گیری به محیط ریشه\fR
.sp
.if n \{\
.RS 4
.\}
.nf
BindReadOnlyPaths=/dev/log /run/systemd/journal/socket /run/systemd/journal/stdout
.fi
.if n \{\
.RE
.\}

به جای مسیر دایرکتوری، می‌توان یک دایرکتوری نسخه‌بندی‌شده
"\&.v/"
را مشخص کرد؛ برای جزئیات به
\fBsystemd.v\fR(7)
مراجعه کنید\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی یا سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.RE
.PP
\fIRootImage=\fR
.RS 4
مسیری به یک گره دستگاه بلوکی یا فایل معمولی را به عنوان آرگومان می‌پذیرد\&. این فراخوانی مشابه
\fIRootDirectory=\fR
است اما یک سلسله‌مراتب سیستم‌فایل را از یک گره دستگاه بلوکی یا فایل loopback به جای یک دایرکتوری متصل (mount) می‌کند\&. گره دستگاه یا فایل ایمیج سیستم‌فایل باید حاوی یک سیستم‌فایل بدون جدول پارتیشن، یا یک سیستم‌فایل درون یک جدول پارتیشن MBR/MS\-DOS یا GPT با تنها یک پارتیشن سازگار با لینوکس، یا مجموعه‌ای از سیستم‌های فایل درون یک جدول پارتیشن GPT باشد که از
\m[blue]\fBDiscoverable Partitions Specification\fR\m[]\&\s-2\u[1]\d\s+2
پیروی می‌کند\&.
.sp
هنگامی که
\fIDevicePolicy=\fR
روی
"closed"
یا
"strict"
تنظیم شده باشد، یا روی
"auto"
تنظیم شده و
\fIDeviceAllow=\fR
تنظیم شده باشد، این تنظیم
/dev/loop\-control
را با حالت
\fBrw\fR،
و
"block\-loop"
و
"block\-blkext"
را با حالت
\fBrwm\fR
به
\fIDeviceAllow=\fR
اضافه می‌کند\&. برای جزئیات درباره
\fIDevicePolicy=\fR
یا
\fIDeviceAllow=\fR
به
\fBsystemd.resource-control\fR(5)
مراجعه کنید\&. همچنین
\fIPrivateDevices=\fR
در زیر را ببینید، زیرا ممکن است تنظیم
\fIDevicePolicy=\fR
را تغییر دهد\&.
.sp
واحدهایی که از
\fIRootImage=\fR
استفاده می‌کنند، به‌طور خودکار یک وابستگی
\fIAfter=\fR
روی
systemd\-udevd\&.service
کسب می‌کنند\&.
.sp
فایل
\fBos-release\fR(5)
میزبان برای سرویس (به صورت فقط‌خواندنی) به عنوان
/run/host/os\-release
در دسترس خواهد بود\&. این فایل در راه‌اندازی مجدد نرم (soft reboot، مراجعه کنید به:
\fBsystemd-soft-reboot.service\fR(8))،
در صورتی که سرویس برای بقا در برابر آن پیکربندی شده باشد، به‌طور خودکار به‌روزرسانی می‌شود\&.
.sp
به جای مسیر ایمیج، می‌توان یک دایرکتوری نسخه‌بندی‌شده
"\&.v/"
را مشخص کرد؛ برای جزئیات به
\fBsystemd.v\fR(7)
مراجعه کنید\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 233\&.
.RE
.PP
\fIRootImageOptions=\fR
.RS 4
یک فهرست جداشده با ویرگول از گزینه‌های اتصال (mount options) را می‌پذیرد که بر روی ایمیج‌های دیسک مشخص‌شده توسط
\fIRootImage=\fR
استفاده خواهند شد\&. در صورتی که ایمیج دارای چندین پارتیشن باشد، اختیاری است که یک نام پارتیشن با پسوند دونقطه در ابتدا قرار گیرد، در غیر این صورت نام پارتیشن
"root"
به صورت ضمنی در نظر گرفته می‌شود\&. گزینه‌ها برای چندین پارتیشن را می‌توان در یک سطر با جداکننده‌های فاصله مشخص کرد\&. اختصاص یک رشته خالی، تخصیص‌های قبلی را حذف می‌کند\&. گزینه‌های تکراری نادیده گرفته می‌شوند\&. برای فهرستی از گزینه‌های معتبر اتصال، لطفاً به
\fBmount\fR(8)
مراجعه کنید\&.
.sp
نام‌های معتبر پارتیشن از
\m[blue]\fBDiscoverable Partitions Specification\fR\m[]\&\s-2\u[1]\d\s+2
پیروی می‌کنند:
\fBroot\fR،
\fBusr\fR،
\fBhome\fR،
\fBsrv\fR،
\fBesp\fR،
\fBxbootldr\fR،
\fBtmp\fR،
\fBvar\fR\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 247\&.
.RE
.PP
\fIRootEphemeral=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. در صورت فعال بودن، فرآیندهای اجراشده در یک رونوشت زودگذر (ephemeral) از دایرکتوری ریشه یا ایمیج ریشه اجرا خواهند شد\&. رونوشت زودگذر در حین فعال بودن سرویس در
/var/lib/systemd/ephemeral\-trees/
قرار می‌گیرد و هنگامی که سرویس متوقف یا راه‌اندازی مجدد شود، پاک‌سازی می‌گردد\&. اگر از
\fIRootDirectory=\fR
استفاده شود و دایرکتوری ریشه یک زیرحجم (subvolume) باشد، رونوشت زودگذر با ایجاد یک تصویر لحظه‌ای (snapshot) از زیرحجم ایجاد می‌شود\&.
.sp
برای اطمینان از اینکه ایجاد رونوشت‌های زودگذر به صورت کارآمد انجام می‌شود، دایرکتوری ریشه یا ایمیج ریشه باید روی همان سیستم‌فایلی قرار داشته باشد که
/var/lib/systemd/ephemeral\-trees/
قرار دارد\&. هنگام استفاده از
\fIRootEphemeral=\fR
با دایرکتوری‌های ریشه،
\fBbtrfs\fR(5)
باید به عنوان سیستم‌فایل استفاده شود و دایرکتوری ریشه در حالت ایده‌آل باید یک زیرحجم باشد که
\fBsystemd\fR
بتواند برای ایجاد رونوشت زودگذر از آن snapshot بگیرد\&. برای ایمیج‌های ریشه، باید از سیستم‌فایلی با پشتیبانی از reflinkها استفاده شود تا رونوشت زودگذر کارآمد تضمین گردد\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 254\&.
.RE
.PP
\fIRootHash=\fR
.RS 4
یک هش ریشه صحت داده (dm\-verity) مشخص‌شده به صورت هگزادسیمال، یا مسیر فایلی حاوی هش ریشه با قالب هگزادسیمال ASCII را می‌پذیرد\&. این گزینه بررسی‌های صحت داده را با استفاده از dm\-verity فعال می‌کند، اگر ایمیج مورد استفاده حاوی داده‌های صحت مناسب باشد (به بالا مراجعه کنید) یا اگر
\fIRootVerity=\fR
استفاده شود\&. هش مشخص‌شده باید با هش ریشه داده‌های صحت مطابقت داشته باشد و معمولاً حداقل 256 بیتی (و بنابراین 64 نویسه هگزادسیمال قالب‌بندی‌شده) است (به عنوان مثال در مورد SHA256)\&. اگر این گزینه مشخص نشده باشد، اما فایل ایمیج دارای ویژگی گسترش‌یافته فایل
"user\&.verity\&.roothash"
باشد (به
\fBxattr\fR(7)
مراجعه کنید)، هش ریشه از آن خوانده می‌شود، همچنین به صورت نویسه‌های هگزادسیمال قالب‌بندی‌شده\&. اگر ویژگی گسترش‌یافته فایل یافت نشود (یا توسط سیستم‌فایل زیرین پشتیبانی نشود)، اما فایلی با پسوند
\&.roothash
در کنار فایل ایمیج با همان نام یافت شود (مگر اینکه ایمیج دارای پسوند
\&.raw
باشد که در این صورت فایل هش ریشه نباید آن را در نام خود داشته باشد)، هش ریشه از آن خوانده شده و به‌طور خودکار استفاده می‌شود، همچنین به عنوان نویسه‌های هگزادسیمال قالب‌بندی‌شده\&.
.sp
اگر ایمیج دیسک شامل یک پارتیشن جداگانه
/usr/
باشد، آن نیز ممکن است با Verity محافظت شود که در این صورت هش ریشه ممکن است از طریق ویژگی گسترش‌یافته
"user\&.verity\&.usrhash"
یا یک فایل
\&.usrhash
در کنار ایمیج دیسک پیکربندی شود\&. در حال حاضر گزینه‌ای برای پیکربندی مستقیم هش ریشه برای سیستم‌فایل
/usr/
از طریق فایل واحد وجود ندارد\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 246\&.
.RE
.PP
\fIRootHashSignature=\fR
.RS 4
یک امضای PKCS7 از گزینه
\fIRootHash=\fR
را به عنوان مسیری به یک فایل امضای کدگذاری‌شده با DER، یا به عنوان یک رشته هگزادسیمال base64 از یک امضای کدگذاری‌شده با DER با پیشوند
"base64:"
می‌پذیرد\&. حجم dm\-verity تنها در صورتی باز خواهد شد که امضای هش ریشه معتبر باشد و توسط یک کلید عمومی موجود در دسته‌کلید (keyring) هسته امضا شده باشد\&. اگر این گزینه مشخص نشده باشد، اما فایلی با پسوند
\&.roothash\&.p7s
در کنار فایل ایمیج با همان نام یافت شود (مگر اینکه ایمیج دارای پسوند
\&.raw
باشد که در این صورت فایل امضا نباید آن را در نام خود داشته باشد)، امضا از آن خوانده شده و به‌طور خودکار استفاده می‌شود\&.
.sp
اگر ایمیج دیسک شامل یک پارتیشن جداگانه
/usr/
باشد، آن نیز ممکن است با Verity محافظت شود که در این صورت امضا برای هش ریشه ممکن است از طریق یک فایل
\&.usrhash\&.p7s
در کنار ایمیج دیسک پیکربندی شود\&. در حال حاضر گزینه‌ای برای پیکربندی مستقیم امضای هش ریشه برای
/usr/
از طریق فایل واحد وجود ندارد\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 246\&.
.RE
.PP
\fIRootVerity=\fR
.RS 4
مسیری به یک فایل صحت داده (dm\-verity) را می‌پذیرد\&. این گزینه بررسی‌های صحت داده را با استفاده از dm\-verity فعال می‌کند، اگر از
\fIRootImage=\fR
استفاده شود و یک هش ریشه منتقل شود و اگر خود ایمیج استفاده‌شده فاقد داده‌های صحت باشد\&. داده‌های صحت باید با هش ریشه مطابقت داشته باشند\&. اگر این گزینه مشخص نشود، اما فایلی با پسوند
\&.verity
در کنار فایل ایمیج با همان نام یافت شود (مگر اینکه ایمیج دارای پسوند
\&.raw
باشد که در این صورت فایل داده‌های verity نباید آن را در نام خود داشته باشد)، داده‌های verity از آن خوانده شده و به‌طور خودکار استفاده می‌شوند\&.
.sp
این گزینه فقط برای ایمیج‌های دیسکی پشتیبانی می‌شود که شامل یک سیستم‌فایل منفرد، بدون جدول پارتیشن احاطه‌کننده هستند\&. ایمیج‌هایی که حاوی جدول پارتیشن GPT هستند باید در عوض هم سیستم‌فایل ریشه و هم داده‌های Verity منطبق را در همان ایمیج بگنجانند و از
\m[blue]\fBDiscoverable Partitions Specification\fR\m[]\&\s-2\u[1]\d\s+2
پیروی کنند\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 246\&.
.RE
.PP
\fIRootImagePolicy=\fR، \fIMountImagePolicy=\fR، \fIExtensionImagePolicy=\fR
.RS 4
یک رشته خط‌مشی ایمیج طبق
\fBsystemd.image-policy\fR(7)
را می‌پذیرد تا هنگام اتصال ایمیج‌های دیسک (DDI) مشخص‌شده در
\fIRootImage=\fR،
\fIMountImage=\fR،
\fIExtensionImage=\fR
به ترتیب استفاده شود\&. در صورت عدم تعیین، رشته خط‌مشی زیر پیش‌فرض برای
\fIRootImagePolicy=\fR
و
\fIMountImagePolicy=\fR
است:
.sp
.if n \{\
.RS 4
.\}
.nf
root=verity+signed+encrypted+unprotected+absent: \e
        usr=verity+signed+encrypted+unprotected+absent: \e
        home=encrypted+unprotected+absent: \e
        srv=encrypted+unprotected+absent: \e
        tmp=encrypted+unprotected+absent: \e
        var=encrypted+unprotected+absent
.fi
.if n \{\
.RE
.\}
.sp
خط‌مشی پیش‌فرض برای
\fIExtensionImagePolicy=\fR
عبارت است از:
.sp
.if n \{\
.RS 4
.\}
.nf
root=verity+signed+encrypted+unprotected+absent: \e
        usr=verity+signed+encrypted+unprotected+absent
.fi
.if n \{\
.RE
.\}
.sp
اضافه‌شده در نسخه 254\&.
.RE
.PP
\fIMountAPIVFS=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. در صورت فعال بودن، یک فضای نام اتصال (mount namespace) خصوصی برای فرآیندهای واحد ایجاد می‌شود و سیستم‌های فایل API شامل
/proc/،
/sys/،
/dev/
و
/run/
(به عنوان یک
"tmpfs"
خالی) در داخل آن متصل می‌شوند، مگر اینکه از قبل متصل شده باشند\&. توجه داشته باشید که این گزینه هیچ تأثیری ندارد مگر اینکه در ترکیب با
\fIRootDirectory=\fR/\fIRootImage=\fR
استفاده شود، زیرا این چهار اتصال به هر حال عموماً در میزبان متصل هستند، و مگر اینکه دایرکتوری ریشه تغییر کند، فضای نام اتصال خصوصی یک رونوشت 1:1 از فضای نام میزبان خواهد بود و شامل این چهار اتصال خواهد شد\&. توجه داشته باشید که اگر از این گزینه بدون
\fIPrivateDevices=\fR
استفاده شود، سیستم‌فایل
/dev/
میزبان به صورت bind متصل می‌شود\&. برای اجرای سرویس با یک نسخه خصوصی و کمینه از
/dev/،
این گزینه را با
\fIPrivateDevices=\fR
ترکیب کنید\&.
.sp
به منظور امکان‌پذیر ساختن انتشار ایمن اتصالات در زمان اجرا، مسیر
/run/systemd/propagate/
روی میزبان برای تنظیم اتصالات جدید استفاده خواهد شد، و مسیر
/run/host/incoming/
در فضای نام خصوصی به عنوان یک مرحله میانی برای ذخیره آن‌ها قبل از انتقال به نقطه اتصال نهایی استفاده می‌شود\&.
.sp
اضافه‌شده در نسخه 233\&.
.RE
.PP
\fIBindLogSockets=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. در صورت درست بودن، سوکت‌های حاصل از
\fBsystemd-journald.socket\fR(8)
به درون فضای نام اتصال، bind mount خواهند شد\&. این گزینه به‌ویژه هنگامی مفید است که نمونه متفاوتی از
/run/
به کار گرفته شده باشد، تا اطمینان حاصل شود که فرآیندهای در حال اجرا در فضای نام همچنان می‌توانند از
\fBsd-journal\fR(3)
استفاده کنند\&.
.sp
این گزینه هنگامی که
\fILogNamespace=\fR
استفاده می‌شود، زمانی که
\fIMountAPIVFS=yes\fR
باشد، یا زمانی که
\fIPrivateDevices=yes\fR
در ترکیب با
\fIRootDirectory=\fR
یا
\fIRootImage=\fR
استفاده شود، به صورت ضمنی اعمال می‌گردد\&.
.sp
اضافه‌شده در نسخه 257\&.
.RE
.PP
\fIProtectProc=\fR
.RS 4
یکی از مقادیر
"noaccess"،
"invisible"،
"ptraceable"
یا
"default"
(که پیش‌فرض آن است) را می‌پذیرد\&. هنگامی که تنظیم شود، گزینه اتصال
"hidepid="
نمونه
"procfs"
را برای واحد کنترل می‌کند که مشخص می‌سازد کدام دایرکتوری‌های حاوی فرااطلاعات فرآیند (/proc/\fIPID\fR) قابل مشاهده و در دسترس هستند: هنگامی که روی
"noaccess"
تنظیم شود، امکان دسترسی به بیشتر فراداده‌های فرآیند کاربران دیگر در
/proc/
از فرآیندهای سرویس سلب می‌شود\&. هنگامی که روی
"invisible"
تنظیم شود، فرآیندهای متعلق به سایر کاربران از دید
/proc/
مخفی می‌شوند\&. اگر روی
"ptraceable"
تنظیم شود، تمام فرآیندهایی که نمی‌توانند توسط یک فرآیند
\fBptrace()\fR
شوند، برای آن مخفی خواهند بود\&. اگر روی
"default"
باشد، هیچ محدودیتی در دسترسی یا قابلیت مشاهده
/proc/
ایجاد نمی‌شود\&. برای جزئیات بیشتر به
\m[blue]\fBThe /proc Filesystem\fR\m[]\&\s-2\u[2]\d\s+2
مراجعه کنید\&. عموماً توصیه می‌شود که بیشتر سرویس‌های سیستمی با این گزینه که روی
"invisible"
تنظیم شده اجرا شوند\&. این گزینه از طریق فضاسازی نام سیستم‌فایل پیاده‌سازی شده است، و بنابراین نمی‌تواند با سرویس‌هایی استفاده شود که باید بتوانند نقاط اتصال را در سلسله‌مراتب سیستم‌فایل میزبان نصب کنند\&. توجه داشته باشید که کاربر root تحت تأثیر این گزینه قرار نمی‌گیرد، بنابراین برای مؤثر بودن باید همراه با
\fIUser=\fR
یا
\fIDynamicUser=yes\fR،
و همچنین بدون قابلیت
"CAP_SYS_PTRACE"
استفاده شود، که این قابلیت نیز به فرآیند اجازه می‌دهد این ویژگی را دور بزند\&. این گزینه برای سرویس‌هایی که نیاز به دسترسی به فرااطلاعات درباره فرآیندهای سایر کاربران دارند قابل استفاده نیست\&. این گزینه به‌طور ضمنی
\fIMountAPIVFS=\fR
را فعال می‌کند\&.
.sp
اگر هسته از گزینه‌های اتصال
\fBhidepid=\fR
به ازای هر نقطه اتصال پشتیبانی نکند، این تنظیم بدون اثر باقی می‌ماند، و فرآیندهای واحد قادر خواهند بود به سایر فرآیندها دسترسی داشته و آن‌ها را ببینند گویی که این گزینه استفاده نشده است\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 247\&.
.RE
.PP
\fIProcSubset=\fR
.RS 4
یکی از مقادیر
"all"
(پیش‌فرض) و
"pid"
را می‌پذیرد\&. اگر روی
"pid"
باشد، تمام فایل‌ها و دایرکتوری‌هایی که مستقیماً با مدیریت و بازرسی فرآیند مرتبط نیستند در سیستم‌فایل
/proc/
پیکربندی‌شده برای فرآیندهای واحد، نامرئی می‌شوند\&. این گزینه، گزینه اتصال
"subset="
نمونه
"procfs"
را برای واحد کنترل می‌کند\&. برای جزئیات بیشتر به
\m[blue]\fBThe /proc Filesystem\fR\m[]\&\s-2\u[2]\d\s+2
مراجعه کنید\&. توجه داشته باشید که لینوکس APIهای مختلف هسته را از طریق
/proc/
ارائه می‌دهد که با این تنظیم غیرقابل دسترس می‌شوند\&. از آنجا که این APIها مکرراً استفاده می‌شوند، این گزینه فقط در چند مورد خاص مفید است و برای اکثر برنامه‌های غیربدیهی مناسب نیست\&.
.sp
همانند
\fIProtectProc=\fR
در بالا، این گزینه از طریق فضای نام اتصال سیستم‌فایل پیاده‌سازی شده است، و از این رو محدودیت‌های یکسانی اعمال می‌شود: فقط برای سرویس‌های سیستمی در دسترس است، انتشار اتصال به جدول اتصال میزبان را غیرفعال می‌کند، و به‌طور ضمنی
\fIMountAPIVFS=\fR
را فعال می‌نماید\&. همچنین، مانند
\fIProtectProc=\fR،
این تنظیم در صورتی که هسته استفاده‌شده از گزینه اتصال
"subset="
برای
"procfs"
پشتیبانی نکند، با ظرافت غیرفعال می‌شود\&.
.sp
اضافه‌شده در نسخه 247\&.
.RE
.PP
\fIBindPaths=\fR، \fIBindReadOnlyPaths=\fR
.RS 4
اتصالات bind خاص واحد را پیکربندی می‌کند\&. یک اتصال bind یک فایل یا دایرکتوری خاص را در مکانی اضافی در دیدگاه واحد از سیستم‌فایل در دسترس قرار می‌دهد\&. هرگونه اتصال bind ایجادشده با این گزینه مختص واحد است و در جدول اتصالات میزبان قابل مشاهده نیست\&. این گزینه منتظر فهرستی جداشده با فاصله از تعاریف اتصال bind است\&. هر تعریف شامل یک سه‌تایی جداشده با دونقطه از مسیر مبدا، مسیر مقصد و رشته گزینه‌ها است که دو مورد آخر اختیاری هستند\&. اگر فقط یک مسیر مبدا مشخص شود، مبدا و مقصد یکسان در نظر گرفته می‌شوند\&. رشته گزینه‌ها می‌تواند
"rbind"
یا
"norbind"
برای پیکربندی یک اتصال bind بازگشتی یا غیربازگشتی باشد\&. در صورت حذف مسیر مقصد، رشته گزینه‌ها نیز باید حذف شود\&. هر تعریف اتصال bind ممکن است با پیشوند
"\-"
همراه باشد، که در این صورت اگر مسیر مبدا آن وجود نداشته باشد، نادیده گرفته خواهد شد\&.
.sp
\fIBindPaths=\fR
اتصالات bind معمولی قابل نوشتن ایجاد می‌کند (مگر اینکه اتصال سیستم‌فایل مبدا قبلاً به صورت فقط‌خواندنی علامت‌گذاری شده باشد)، در حالی که
\fIBindReadOnlyPaths=\fR
اتصالات bind فقط‌خواندنی ایجاد می‌کند\&. این تنظیمات ممکن است بیش از یک بار استفاده شوند، هر استفاده به فهرست اتصالات bind واحد اضافه می‌کند\&. اگر رشته خالی به هر یک از این دو گزینه اختصاص یابد، کل فهرست اتصالات bind تعریف‌شده قبل از این بازنشانی می‌شود\&. توجه داشته باشید که در این حالت، صرف‌نظر از اینکه کدام یک از دو تنظیم استفاده شده باشد، هم اتصالات فقط‌خواندنی و هم اتصالات معمولی bind بازنشانی می‌شوند\&.
.sp
استفاده از این گزینه مستلزم آن است که یک فضای نام اتصال برای واحد اختصاص داده شود، یعنی تأثیر
\fIPrivateMounts=\fR
را به همراه دارد (به زیر مراجعه کنید)\&.
.sp
این گزینه به‌ویژه زمانی مفید است که از
\fIRootDirectory=\fR/\fIRootImage=\fR
استفاده شود\&. در این حالت مسیر مبدا به مسیری در سیستم‌فایل میزبان اشاره دارد، در حالی که مسیر مقصد به مسیری در زیر دایرکتوری ریشه واحد اشاره می‌کند\&.
.sp
توجه داشته باشید که دایرکتوری مقصد باید وجود داشته باشد یا systemd بتواند آن را ایجاد کند\&. بنابراین، استفاده از این گزینه‌ها برای نقاط اتصال تو‌در‌تو در زیر مسیرهای مشخص‌شده در
\fIInaccessiblePaths=\fR،
یا زیر
/home/
و سایر دایرکتوری‌های محافظت‌شده در صورت مشخص شدن
\fIProtectHome=yes\fR
امکان‌پذیر نیست\&. در عوض باید از
\fITemporaryFileSystem=\fR
با
":ro"
یا
\fIProtectHome=tmpfs\fR
استفاده شود\&.
.sp
اضافه‌شده در نسخه 233\&.
.RE
.PP
\fIMountImages=\fR
.RS 4
این تنظیم مشابه
\fIRootImage=\fR
است از این نظر که یک سلسله‌مراتب سیستم‌فایل را از یک گره دستگاه بلوکی یا فایل loopback متصل می‌کند، اما دایرکتوری مقصد و همچنین گزینه‌های اتصال را نیز می‌توان مشخص کرد\&. این گزینه منتظر فهرستی جداشده با فاصله از تعاریف اتصال است\&. هر تعریف شامل یک دوتایی جداشده با دونقطه از مسیر مبدا و تعاریف مقصد است، که به‌طور اختیاری یک دونقطه دیگر و فهرستی از گزینه‌های اتصال به دنبال آن می‌آید\&.
.sp
گزینه‌های اتصال ممکن است به صورت یک فهرست تکی جداشده با ویرگول از گزینه‌ها تعریف شوند، که در این صورت به‌طور ضمنی بر روی پارتیشن ریشه روی ایمیج اعمال می‌شوند، یا مجموعه‌ای از دوتایی‌های جداشده با دونقطه از نام پارتیشن و گزینه‌های اتصال باشند\&. نام‌های معتبر پارتیشن و گزینه‌های معتبر اتصال همان مواردی هستند که برای تنظیم
\fIRootImageOptions=\fR
در بالا شرح داده شد\&.
.sp
هر تعریف اتصال ممکن است با پیشوند
"\-"
همراه باشد، که در این صورت اگر مسیر مبدا آن وجود نداشته باشد نادیده گرفته می‌شود\&. آرگومان مبدا، مسیری به یک گره دستگاه بلوکی یا فایل معمولی است\&. اگر مبدا یا مقصد حاوی
":"
باشد، باید به صورت
"\e:"
گریزانده (escape) شود\&. گره دستگاه یا فایل ایمیج سیستم‌فایل باید از همان قوانینی پیروی کند که برای
\fIRootImage=\fR
مشخص شده است\&. هر اتصالی که با این گزینه ایجاد شود مختص واحد است و در جدول اتصالات میزبان قابل مشاهده نیست\&.
.sp
این تنظیمات ممکن است بیش از یک بار استفاده شوند، هر استفاده به فهرست مسیرهای اتصال واحد اضافه می‌کند\&. اگر رشته خالی اختصاص یابد، کل فهرست مسیرهای اتصال که پیش از این تعریف شده‌اند بازنشانی می‌شود\&.
.sp
توجه داشته باشید که دایرکتوری مقصد باید وجود داشته باشد یا systemd بتواند آن را ایجاد کند\&. بنابراین، استفاده از این گزینه‌ها برای نقاط اتصال تو‌در‌تو در زیر مسیرهای مشخص‌شده در
\fIInaccessiblePaths=\fR،
یا زیر
/home/
و سایر دایرکتوری‌های محافظت‌شده در صورت مشخص شدن
\fIProtectHome=yes\fR
امکان‌پذیر نیست\&.
.sp
هنگامی که
\fIDevicePolicy=\fR
روی
"closed"
یا
"strict"
تنظیم شده باشد، یا روی
"auto"
تنظیم شده و
\fIDeviceAllow=\fR
تنظیم شده باشد، این تنظیم
/dev/loop\-control
را با حالت
\fBrw\fR،
و
"block\-loop"
و
"block\-blkext"
را با حالت
\fBrwm\fR
به
\fIDeviceAllow=\fR
اضافه می‌کند\&. برای جزئیات درباره
\fIDevicePolicy=\fR
یا
\fIDeviceAllow=\fR
به
\fBsystemd.resource-control\fR(5)
مراجعه کنید\&. همچنین
\fIPrivateDevices=\fR
در زیر را ببینید، زیرا ممکن است تنظیم
\fIDevicePolicy=\fR
را تغییر دهد\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 247\&.
.RE
.PP
\fIExtensionImages=\fR
.RS 4
این تنظیم مشابه
\fIMountImages=\fR
است از این جهت که یک سلسله‌مراتب سیستم‌فایل را از یک گره دستگاه بلوکی یا فایل loopback متصل می‌کند، اما به جای ارائه مسیر مقصد، یک لایه پوششی (overlay) راه‌اندازی خواهد شد\&. این گزینه منتظر فهرستی جداشده با فاصله از تعاریف اتصال است\&. هر تعریف شامل یک مسیر مبدا است، که به‌طور اختیاری یک دونقطه و فهرستی از گزینه‌های اتصال به دنبال آن می‌آید\&.
.sp
یک OverlayFS فقط‌خواندنی بر روی سلسله‌مراتب‌های
/usr/
و
/opt/
برای ایمیج‌های sysext و سلسله‌مراتب
/etc/
برای ایمیج‌های confext راه‌اندازی خواهد شد\&. ترتیبی که ایمیج‌ها فهرست می‌شوند ترتیبی را که overlay روی هم قرار می‌گیرد مشخص می‌کند: ایمیج‌هایی که از اول به آخر مشخص شده‌اند، منجر به لایه‌های overlayfs از پایین به بالا خواهند شد\&.
.sp
گزینه‌های اتصال ممکن است به عنوان یک فهرست تکی جداشده با ویرگول از گزینه‌ها تعریف شوند، که در این صورت به‌طور ضمنی بر روی پارتیشن ریشه روی ایمیج اعمال می‌شوند، یا مجموعه‌ای از دوتایی‌های جداشده با دونقطه از نام پارتیشن و گزینه‌های اتصال باشند\&. نام‌های معتبر پارتیشن و گزینه‌های اتصال همان مواردی هستند که برای تنظیم
\fIRootImageOptions=\fR
در بالا شرح داده شد\&.
.sp
هر تعریف اتصال ممکن است با پیشوند
"\-"
همراه باشد، که در این صورت اگر مسیر مبدا آن وجود نداشته باشد نادیده گرفته می‌شود\&. آرگومان مبدا، مسیری به یک گره دستگاه بلوکی یا فایل معمولی است\&. اگر مسیر مبدا حاوی
":"
باشد، باید به صورت
"\e:"
گریزانده شود\&. گره دستگاه یا فایل ایمیج سیستم‌فایل باید از همان قوانینی پیروی کند که برای
\fIRootImage=\fR
مشخص شده است\&. هر اتصالی که با این گزینه ایجاد شود مختص واحد است و در جدول اتصالات میزبان قابل مشاهده نیست\&.
.sp
این تنظیمات ممکن است بیش از یک بار استفاده شوند، هر استفاده به فهرست مسیرهای ایمیج واحد اضافه می‌کند\&. اگر رشته خالی اختصاص یابد، کل فهرست مسیرهای اتصال تعریف‌شده پیش از این بازنشانی می‌شود\&.
.sp
هر ایمیج sysext باید حامل یک فایل
/usr/lib/extension\-release\&.d/extension\-release\&.IMAGE
باشد در حالی که هر ایمیج confext باید حامل یک فایل
/etc/extension\-release\&.d/extension\-release\&.IMAGE
با فراداده‌های مناسب باشد که با
\fIRootImage=\fR/\fIRootDirectory=\fR
یا میزبان مطابقت دارد\&. ببینید:
\fBos-release\fR(5)\&. برای غیرفعال کردن بررسی ایمنی مبنی بر مطابقت نام فایل extension\-release با نام فایل ایمیج، می‌توان گزینه اتصال
\fIx\-systemd\&.relax\-extension\-release\-check\fR
را اضافه کرد\&.
.sp
هنگامی که
\fIDevicePolicy=\fR
روی
"closed"
یا
"strict"
تنظیم شده باشد، یا روی
"auto"
تنظیم شده و
\fIDeviceAllow=\fR
تنظیم شده باشد، این تنظیم
/dev/loop\-control
را با حالت
\fBrw\fR،
و
"block\-loop"
و
"block\-blkext"
را با حالت
\fBrwm\fR
به
\fIDeviceAllow=\fR
اضافه می‌کند\&. برای جزئیات درباره
\fIDevicePolicy=\fR
یا
\fIDeviceAllow=\fR
به
\fBsystemd.resource-control\fR(5)
مراجعه کنید\&. همچنین
\fIPrivateDevices=\fR
در زیر را ببینید، زیرا ممکن است تنظیم
\fIDevicePolicy=\fR
را تغییر دهد\&.
.sp
به جای مسیر ایمیج، می‌توان یک دایرکتوری نسخه‌بندی‌شده
"\&.v/"
را مشخص کرد؛ برای جزئیات به
\fBsystemd.v\fR(7)
مراجعه کنید\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 248\&.
.RE
.PP
\fIExtensionDirectories=\fR
.RS 4
این تنظیم مشابه
\fIBindReadOnlyPaths=\fR
است از این جهت که یک سلسله‌مراتب سیستم‌فایل را از یک دایرکتوری متصل می‌کند، اما به جای ارائه مسیر مقصد، یک پوشش (overlay) راه‌اندازی خواهد شد\&. این گزینه منتظر فهرستی جداشده با فاصله از دایرکتوری‌های مبدا است\&.
.sp
یک OverlayFS فقط‌خواندنی بر روی سلسله‌مراتب‌های
/usr/
و
/opt/
برای ایمیج‌های sysext و سلسله‌مراتب
/etc/
برای ایمیج‌های confext راه‌اندازی خواهد شد\&. ترتیبی که دایرکتوری‌ها فهرست می‌شوند ترتیبی را که overlay روی هم قرار می‌گیرد مشخص می‌کند: دایرکتوری‌هایی که از ابتدا تا انتها مشخص شده‌اند منجر به لایه‌های overlayfs از پایین به بالا خواهند شد\&.
.sp
هر دایرکتوری فهرست‌شده در
\fIExtensionDirectories=\fR
ممکن است دارای پیشوند
"\-"
باشد، که در این صورت اگر مسیر مبدا آن وجود نداشته باشد نادیده گرفته می‌شود\&. هر اتصالی که با این گزینه ایجاد شود مختص واحد است و در جدول اتصالات میزبان قابل مشاهده نیست\&.
.sp
این تنظیمات ممکن است بیش از یک بار استفاده شوند، هر استفاده به فهرست مسیرهای دایرکتوری واحد اضافه می‌کند\&. اگر رشته خالی اختصاص یابد، کل فهرست مسیرهای اتصال تعریف‌شده پیش از این بازنشانی می‌شود\&.
.sp
هر دایرکتوری sysext باید شامل یک فایل
/usr/lib/extension\-release\&.d/extension\-release\&.IMAGE
باشد در حالی که هر دایرکتوری confext باید حاوی یک فایل
/etc/extension\-release\&.d/extension\-release\&.IMAGE
با فراداده‌های مناسب باشد که با
\fIRootImage=\fR/\fIRootDirectory=\fR
یا میزبان مطابقت دارد\&. ببینید:
\fBos-release\fR(5)\&.
.sp
توجه داشته باشید که استفاده از واحدهای کاربر نیازمند پشتیبانی از overlayfs در فضاهای نام کاربری بدون امتیاز است که برای اولین بار در هسته نسخه 5.11 معرفی شد\&.
.sp
به جای مسیر دایرکتوری، می‌توان یک دایرکتوری نسخه‌بندی‌شده
"\&.v/"
مشخص کرد؛ برای جزئیات به
\fBsystemd.v\fR(7)
مراجعه کنید\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافه‌شده در نسخه 251\&.
.RE
.SH "شناسه کاربر/گروه (USER/GROUP IDENTITY)"
.PP
این گزینه‌ها فقط برای سرویس‌های سیستمی در دسترس هستند و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شوند\&.
.PP
\fIUser=\fR، \fIGroup=\fR
.RS 4
کاربر یا گروه یونیکس (UNIX) را که فرآیندها به ترتیب تحت آن اجرا می‌شوند تنظیم می‌کند\&. یک نام کاربر یا گروه منفرد، یا یک شناسه عددی (ID) را به عنوان آرگومان می‌پذیرد\&. برای سرویس‌های سیستمی (سرویس‌هایی که توسط مدیر سرویس سیستم اجرا می‌شوند، یعنی توسط PID 1 مدیریت می‌شوند) و برای سرویس‌های کاربری کاربر root (سرویس‌های مدیریت‌شده توسط نمونه root از
\fBsystemd \-\-user\fR)،
پیش‌فرض
"root"
است، اما
\fIUser=\fR
ممکن است برای تعیین یک کاربر متفاوت استفاده شود\&. برای سرویس‌های کاربری هر کاربر دیگر، تغییر شناسه کاربر مجاز نیست، از این رو تنها تنظیم معتبر، همان کاربری است که مدیر سرویس کاربر تحت آن در حال اجرا است\&. اگر هیچ گروهی تنظیم نشده باشد، از گروه پیش‌فرض کاربر استفاده می‌شود\&. این تنظیم بر دستوراتی که خط فرمان آن‌ها با پیشوند
"+"
همراه است تأثیری نمی‌گذارد\&.
.sp
توجه داشته باشید که این گزینه فقط محدودیت‌های ضعیفی را روی نحو نام کاربر/گروه اعمال می‌کند، اما در بسیاری از مواردی که نام‌های کاربر/گروه از قوانین زیر پیروی نمی‌کنند هشدارهایی ایجاد خواهد کرد: نام مشخص‌شده باید فقط شامل نویسه‌های a\-z، A\-Z، 0\-9،
"_"
و
"\-"
باشد، به جز نویسه اول که باید یکی از a\-z، A\-Z و
"_"
باشد (یعنی ارقام و
"\-"
به عنوان نویسه اول مجاز نیستند)\&. نام کاربر/گروه باید حداقل یک نویسه و حداکثر ۳۱ نویسه داشته باشد\&. این محدودیت‌ها به منظور جلوگیری از ابهام و اطمینان از سازگاری و قابل حمل بودن نام‌های کاربر/گروه و فایل‌های واحد در میان سیستم‌های لینوکسی اعمال شده‌اند\&. برای جزئیات بیشتر در مورد نام‌های پذیرفته‌شده و نام‌هایی که هشدار دریافت می‌کنند به
\m[blue]\fBUser/Group Name Syntax\fR\m[]\&\s-2\u[3]\d\s+2
مراجعه کنید\&.
.sp
هنگامی که همراه با
\fIDynamicUser=\fR
استفاده می‌شود، نام کاربر/گروه مشخص‌شده به صورت پویا در زمان شروع به کار سرویس تخصیص داده شده و در زمان توقف سرویس آزاد می‌شود \(em مگر اینکه از قبل به صورت ایستا تخصیص داده شده باشد (به زیر مراجعه کنید)\&. اگر از
\fIDynamicUser=\fR
استفاده نشود، کاربر و گروه مشخص‌شده باید حداکثر تا زمان شروع به کار سرویس به صورت ایستا در پایگاه‌داده کاربر ایجاد شده باشند، برای مثال با استفاده از امکانات
\fBsysusers.d\fR(5)
که در زمان بوت یا زمان نصب بسته اعمال می‌شود\&. اگر تا آن زمان کاربر وجود نداشته باشد، فراخوانی برنامه با شکست مواجه خواهد شد\&.
.sp
اگر تنظیم
\fIUser=\fR
استفاده شود، فهرست گروه‌های تکمیلی (supplementary groups) از فهرست گروه‌های پیش‌فرض کاربر مشخص‌شده، همان‌طور که در پایگاه‌داده کاربر و گروه سیستم تعریف شده است مقداردهی اولیه می‌شود\&. گروه‌های اضافی را می‌توان از طریق تنظیم
\fISupplementaryGroups=\fR
پیکربندی کرد (به زیر مراجعه کنید)\&.
.RE
.PP
\fIDynamicUser=\fR
.RS 4
یک پارامتر بولی می‌پذیرد\&. در صورت تنظیم، یک جفت کاربر و گروه یونیکس (UNIX) در زمان شروع واحد به صورت پویا تخصیص داده می‌شود و به محض متوقف شدن آن آزاد می‌گردد\&. کاربر و گروه به
/etc/passwd
یا
/etc/group
اضافه نخواهند شد، بلکه در طول زمان اجرا به صورت گذرا مدیریت می‌شوند\&. ماژول glibc NSS با نام
\fBnss-systemd\fR(8)
یکپارچه‌سازی این کاربران/گروه‌های پویا را در پایگاه‌های داده کاربر و گروه سیستم فراهم می‌کند\&. نام کاربر و گروه مورد استفاده ممکن است از طریق
\fIUser=\fR
و
\fIGroup=\fR
پیکربندی شود (به بالا مراجعه کنید)\&. اگر این گزینه‌ها استفاده نشوند و تخصیص پویای کاربر/گروه برای یک واحد فعال باشد، نام کاربر/گروه پویا به صورت ضمنی از نام واحد مشتق می‌شود\&. اگر نام واحد بدون پسوند نوع به عنوان نام کاربری معتبر واجد شرایط باشد مستقیماً استفاده می‌شود، در غیر این صورت نامی شامل یک هش از آن استفاده خواهد شد\&. اگر یک کاربر یا گروه با تخصیص ایستا با نام پیکربندی‌شده از قبل وجود داشته باشد، از آن استفاده می‌شود و هیچ کاربر/گروه پویایی تخصیص داده نمی‌شود\&. توجه داشته باشید که اگر
\fIUser=\fR
مشخص شود و گروه ایستایی با این نام وجود داشته باشد، لازم است که کاربر ایستایی با این نام نیز از قبل وجود داشته باشد\&. مشابهاً، اگر
\fIGroup=\fR
مشخص شود و کاربر ایستایی با این نام وجود داشته باشد، لازم است که گروه ایستایی با این نام نیز از قبل وجود داشته باشد\&. کاربران/گروه‌های پویا از محدوده UID/GID بین 61184 تا 65519 تخصیص داده می‌شوند\&. توصیه می‌شود از این محدوده برای کاربران عادی سیستم یا ورود به سیستم اجتناب شود\&. در هر لحظه از زمان، هر UID/GID از این محدوده فقط به صفر یا یک کاربر/گروه با تخصیص پویا در حال استفاده اختصاص می‌یابد\&. با این حال، UID/GIDها پس از خاتمه واحد بازیافت می‌شوند\&. باید مراقبت شود که هر فرآیندی که به عنوان بخشی از واحدی که کاربران/گروه‌های پویا برای آن فعال است اجرا می‌شود، فایل‌ها یا دایرکتوری‌های متعلق به این کاربران/گروه‌ها را بر جای نگذارد، زیرا ممکن است بعداً همان UID/GID به واحد متفاوتی اختصاص یابد، و در نتیجه به این فایل‌ها یا دایرکتوری‌ها دسترسی پیدا کند\&. اگر
\fIDynamicUser=\fR
فعال باشد،
\fIRemoveIPC=\fR
به صورت ضمنی اعمال می‌شود (و نمی‌توان آن را خاموش کرد)\&. این امر تضمین می‌کند که طول عمر اشیاء IPC و فایل‌های موقت ایجادشده توسط فرآیندهای اجراشده به زمان اجرای سرویس، و از این رو به طول عمر کاربر/گروه پویا پیوند خورده است\&. از آنجا که
/tmp/
و
/var/tmp/
معمولاً تنها دایرکتوری‌های با قابلیت نوشتن همگانی در یک سیستم هستند، مگر اینکه
\fIPrivateTmp=\fR
به صورت دستی روی
"true"
تنظیم شود، مقدار
"disconnected"
به صورت ضمنی اعمال خواهد شد\&. این امر تضمین می‌کند که واحدی که از تخصیص پویای کاربر/گروه استفاده می‌کند نتواند پس از پایان کار فایل‌هایی بر جای بگذارد\&. علاوه بر این
\fINoNewPrivileges=\fR
و
\fIRestrictSUIDSGID=\fR
به‌طور ضمنی فعال هستند (و نمی‌توان آن‌ها را غیرفعال کرد)، تا اطمینان حاصل شود که فرآیندهای فراخوانده‌شده نمی‌توانند از فایل‌ها یا دایرکتوری‌های SUID/SGID بهره‌مند شوند یا آن‌ها را ایجاد کنند\&. علاوه بر این
\fIProtectSystem=strict\fR
و
\fIProtectHome=read\-only\fR
به صورت ضمنی اعمال می‌شوند، بنابراین نوشتن در مکان‌های دلخواه سیستم‌فایل توسط سرویس ممنوع می‌شود\&. به منظور اجازه دادن به سرویس برای نوشتن در دایرکتوری‌های خاص، آن‌ها باید با استفاده از
\fIReadWritePaths=\fR
در فهرست مجاز قرار گیرند، اما باید مراقبت شود تا بازیافت UID/GID مسائل امنیتی مربوط به فایل‌های ایجادشده توسط سرویس ایجاد نکند\&. از
\fIRuntimeDirectory=\fR
(به زیر مراجعه کنید) برای اختصاص یک دایرکتوری زمان اجرای قابل نوشتن به سرویس استفاده کنید که متعلق به کاربر/گروه پویا باشد و پس از خاتمه واحد به‌طور خودکار حذف شود\&. از
\fIStateDirectory=\fR،
\fICacheDirectory=\fR
و
\fILogsDirectory=\fR
برای اختصاص مجموعه‌ای از دایرکتوری‌های قابل نوشتن برای اهداف خاص به سرویس استفاده کنید به‌گونه‌ای که از آسیب‌پذیری‌های ناشی از استفاده مجدد از UID محافظت شوند (به زیر مراجعه کنید)\&. اگر این گزینه فعال باشد، باید مراقبت شود که فرآیندهای واحد به دایرکتوری‌هایی خارج از این دایرکتوری‌های صریحاً پیکربندی‌شده و مدیریت‌شده دسترسی پیدا نکنند\&. به ویژه، از
\fIBindPaths=\fR
استفاده نکنید و در مورد انتقال توصیف‌گر فایل
\fBAF_UNIX\fR
برای توصیف‌گرهای فایل دایرکتوری محتاط باشید، زیرا این امر به فرآیندها اجازه می‌دهد فایل‌ها یا دایرکتوری‌های متعلق به کاربر/گروه پویا ایجاد کنند که مشمول تضمین‌های چرخه حیات و دسترسی سرویس نیستند\&. توجه داشته باشید که این گزینه در حال حاضر با خط‌مشی‌های D\-Bus ناسازگار است، بنابراین سرویسی که از این گزینه استفاده می‌کند در حال حاضر ممکن است نتواند یک نام سرویس D\-Bus را تخصیص دهد (توجه داشته باشید که این امر بر فراخوانی سایر سرویس‌های D\-Bus تأثیری ندارد)\&. پیش‌فرض روی خاموش (off) است\&.
.sp
اضافه‌شده در نسخه 232\&.
.RE
.PP
\fISupplementaryGroups=\fR
.RS 4
گروه‌های تکمیلی یونیکس (Unix) را که فرآیندها تحت آن‌ها اجرا می‌شوند تنظیم می‌کند\&. این گزینه فهرستی از نام‌ها یا شناسه‌های گروه جداشده با فاصله را می‌پذیرد\&. این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت تمام گروه‌های فهرست‌شده به عنوان گروه‌های تکمیلی تنظیم می‌شوند\&. هنگامی که رشته خالی اختصاص داده شود، فهرست گروه‌های تکمیلی بازنشانی می‌شود و تمام تخصیص‌های قبلی بی‌اثر خواهند بود\&. در هر صورت، این گزینه فهرست گروه‌های تکمیلی پیکربندی‌شده در پایگاه‌داده گروه سیستم برای کاربر را بازنویسی نمی‌کند، بلکه آن را گسترش می‌دهد\&. این گزینه بر دستوراتی که با پیشوند
"+"
همراه هستند تأثیری ندارد\&.
.RE
.PP
\fISetLoginEnvironment=\fR
.RS 4
یک پارامتر بولی می‌پذیرد که تنظیم متغیرهای محیطی
\fI/home/debian\fR،
\fIdebian\fR
و
\fI/usr/bin/zsh\fR
را کنترل می‌کند\&. در صورت عدم تنظیم، اگر
\fIUser=\fR،
\fIDynamicUser=\fR
یا
\fIPAMName=\fR
تنظیم شده باشند پیش‌فرض روی true و در غیر این صورت false است\&. اگر روی true تنظیم شود، این متغیرها همیشه برای سرویس‌های سیستمی تنظیم می‌شوند، یعنی حتی زمانی که از کاربر پیش‌فرض
"root"
استفاده می‌شود\&. اگر روی false تنظیم شود، متغیرهای ذکرشده توسط مدیر سرویس تنظیم نمی‌شوند، صرف‌نظر از اینکه
\fIUser=\fR،
\fIDynamicUser=\fR
یا
\fIPAMName=\fR
استفاده شده باشند یا خیر\&. این گزینه معمولاً بر سرویس‌های مدیر سرویس کاربر-محور تأثیری ندارد، زیرا در آن حالت این متغیرها معمولاً به هر حال از محیط خود مدیر کاربر به ارث برده می‌شوند\&.
.sp
اضافه‌شده در نسخه 255\&.
.RE
.PP
\fIPAMName=\fR
.RS 4
نام سرویس PAM را برای راه‌اندازی نشست (session) تنظیم می‌کند\&. در صورت تنظیم، فرآیند اجراشده به عنوان یک نشست PAM تحت نام سرویس مشخص‌شده ثبت خواهد شد\&. این گزینه تنها در ترکیب با تنظیم
\fIUser=\fR
مفید است و در غیر این صورت نادیده گرفته می‌شود\&. اگر تنظیم نشود، هیچ نشست PAM برای فرآیندهای اجراشده باز نخواهد شد\&. برای جزئیات به
\fBpam\fR(8)
مراجعه کنید\&.
.sp
توجه داشته باشید که برای هر واحدی که از این گزینه استفاده می‌کند، یک فرآیند گرداننده نشست PAM به عنوان بخشی از واحد نگهداری می‌شود و تا زمانی که واحد فعال است باقی می‌ماند تا اطمینان حاصل شود که هنگام خاتمه واحد و در نتیجه نشست PAM، اقدامات مناسب انجام می‌شود\&. این فرآیند
"(sd\-pam)"
نامیده می‌شود و یک فرآیند فرزند مستقیم فرآیند اصلی واحد است\&.
.sp
توجه داشته باشید که هنگامی که از این گزینه برای یک واحد استفاده می‌شود، بسیار محتمل است (بسته به پیکربندی PAM) که فرآیند اصلی واحد در زمان فعال‌سازی به واحد دامنه نشست (session scope unit) اختصاصی خود منتقل شود\&. بنابراین این فرآیند با دو واحد مرتبط خواهد بود: واحدی که در ابتدا از آن راه‌اندازی شده است (و برای آن
\fIPAMName=\fR
پیکربندی شده بود)، و واحد دامنه نشست\&. با این حال، هر فرآیند فرزند آن فرآیند فقط با واحد دامنه نشست مرتبط خواهد بود\&. این امر پیامدهایی در صورت استفاده در ترکیب با
\fINotifyAccess=\fR\fBall\fR
دارد، زیرا این فرآیندهای فرزند نمی‌توانند از طریق پیام‌های اطلاع‌رسانی بر تغییرات در واحد اصلی تأثیر بگذارند\&. این پیام‌ها متعلق به واحد دامنه نشست و نه واحد اصلی در نظر گرفته می‌شوند\&. بنابراین توصیه نمی‌شود که از
\fIPAMName=\fR
در ترکیب با
\fINotifyAccess=\fR\fBall\fR
استفاده شود\&.
.RE
.SH "قابلیت‌ها (CAPABILITIES)"
.PP
این گزینه‌ها فقط برای سرویس‌های سیستمی، یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس هستند که در این صورت
\fIPrivateUsers=\fR
به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.PP
\fICapabilityBoundingSet=\fR
.RS 4
کنترل می‌کند کدام قابلیت‌ها در مجموعه محدودکننده قابلیت‌ها (bounding set) برای فرآیند اجراشده گنجانده شوند\&. برای جزئیات به
\fBcapabilities\fR(7)
مراجعه کنید\&. فهرستی جداشده با فاصله از نام‌های قابلیت‌ها را می‌پذیرد، مانند
\fBCAP_SYS_ADMIN\fR،
\fBCAP_DAC_OVERRIDE\fR،
\fBCAP_SYS_PTRACE\fR\&.
قابلیت‌های فهرست‌شده در مجموعه محدودکننده گنجانده می‌شوند و بقیه حذف می‌گردند\&. اگر فهرست قابلیت‌ها دارای پیشوند
"~"
باشد، تمام قابلیت‌ها به جز قابلیت‌های فهرست‌شده گنجانده می‌شوند، که اثر انتساب را معکوس می‌کند\&. توجه داشته باشید که این گزینه بر قابلیت‌های مربوطه در مجموعه‌های قابلیت‌های مؤثر (effective)، مجاز (permitted) و قابل وراثت (inheritable) نیز تأثیر می‌گذارد\&. اگر از این گزینه استفاده نشود، مجموعه محدودکننده قابلیت در زمان اجرای فرآیند اصلاح نمی‌شود، بنابراین هیچ محدودیتی بر قابلیت‌های فرآیند اعمال نخواهد شد\&. این گزینه ممکن است بیش از یک بار ظاهر شود، که در این صورت مجموعه‌های محدودکننده با عملگر
\fBOR\fR
(یا در صورتی که سطرها با پیشوند
"~"
همراه باشند با عملگر
\fBAND\fR)
ادغام می‌شوند (به زیر مراجعه کنید)\&. اگر رشته خالی به این گزینه اختصاص یابد، مجموعه محدودکننده به مجموعه قابلیت خالی بازنشانی می‌شود و تمام تنظیمات قبلی بی‌اثر می‌شوند\&. اگر روی
"~"
(بدون هیچ آرگومان دیگری) تنظیم شود، مجموعه محدودکننده به مجموعه کامل قابلیت‌های موجود بازنشانی می‌شود و همچنین هرگونه تنظیم قبلی را باطل می‌کند\&. این گزینه بر دستوراتی که با پیشوند
"+"
همراه هستند تأثیری ندارد\&.
.sp
از دستور
\fBcapability\fR
در
\fBsystemd-analyze\fR(1)
برای بازیابی فهرستی از قابلیت‌های تعریف‌شده در سیستم محلی استفاده کنید\&.
.sp
مثال: اگر یک واحد دارای موارد زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=CAP_B CAP_C
.fi
.if n \{\
.RE
.\}
.sp
آن‌گاه
\fBCAP_A\fR،
\fBCAP_B\fR
و
\fBCAP_C\fR
تنظیم می‌شوند\&. اگر سطر دوم دارای پیشوند
"~"
باشد، به عنوان مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=~CAP_B CAP_C
.fi
.if n \{\
.RE
.\}
.sp
آن‌گاه تنها
\fBCAP_A\fR
تنظیم می‌شود\&.
.RE
.PP
\fIAmbientCapabilities=\fR
.RS 4
کنترل می‌کند که کدام قابلیت‌ها در مجموعه قابلیت‌های فراگیر (ambient capabilities) برای فرآیند اجراشده گنجانده شوند\&. فهرستی از نام‌های قابلیت جداشده با فاصله را می‌پذیرد، مانند
\fBCAP_SYS_ADMIN\fR،
\fBCAP_DAC_OVERRIDE\fR،
\fBCAP_SYS_PTRACE\fR\&.
این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت مجموعه‌های قابلیت فراگیر ادغام می‌شوند (به مثال‌های بالا در
\fICapabilityBoundingSet=\fR
مراجعه کنید)\&. اگر فهرست قابلیت‌ها با پیشوند
"~"
همراه باشد، تمام قابلیت‌ها به جز موارد فهرست‌شده گنجانده می‌شوند، که اثر انتساب را معکوس می‌کند\&. اگر رشته خالی به این گزینه اختصاص یابد، مجموعه قابلیت‌های فراگیر به مجموعه خالی بازنشانی می‌شود و تمام تنظیمات قبلی بی‌اثر خواهند بود\&. اگر روی
"~"
(بدون هیچ آرگومان دیگری) تنظیم شود، مجموعه قابلیت‌های فراگیر به مجموعه کامل قابلیت‌های موجود بازنشانی می‌شود و تنظیمات قبلی را نیز باطل می‌کند\&. توجه داشته باشید که افزودن قابلیت‌ها به مجموعه قابلیت‌های فراگیر، آن‌ها را به مجموعه قابلیت‌های موروثی فرآیند اضافه می‌کند\&.
.sp
مجموعه‌های قابلیت فراگیر در صورتی مفید هستند که بخواهید فرآیندی را به عنوان یک کاربر بدون امتیاز اجرا کنید اما همچنان به آن قابلیت‌هایی بدهید\&. توجه داشته باشید که در این حالت گزینه
\fBkeep\-caps\fR
به‌طور خودکار به
\fISecureBits=\fR
اضافه می‌شود تا قابلیت‌ها در طول تغییر کاربر حفظ شوند\&.
\fIAmbientCapabilities=\fR
بر دستورات دارای پیشوند
"+"
تأثیری ندارد\&.
.sp
اضافه‌شده در نسخه 229\&.
.RE
.SH "امنیت (SECURITY)"
.PP
\fINoNewPrivileges=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. در صورت true بودن، تضمین می‌کند که فرآیند سرویس و تمام فرزندان آن هرگز نتوانند از طریق
\fBexecve()\fR
امتیازات جدیدی کسب کنند (مثلاً از طریق بیت‌های setuid یا setgid، یا قابلیت‌های سیستم‌فایل)\&. این ساده‌ترین و مؤثرترین راه برای اطمینان از این است که یک فرآیند و فرزندانش هرگز نتوانند دوباره امتیازات خود را ارتقا دهند\&. پیش‌فرض false است\&. در صورتی که سرویس به هر حال در یک فضای نام اتصال جدید اجرا شود و SELinux غیرفعال باشد، تمام سیستم‌های فایل با پرچم
\fBMS_NOSUID\fR
متصل می‌شوند\&. همچنین به
\m[blue]\fBNo New Privileges Flag\fR\m[]\&\s-2\u[4]\d\s+2
مراجعه کنید\&.
.sp
توجه داشته باشید که این تنظیم فقط بر فرآیندهای خود واحد (یا هر فرآیندی که مستقیماً یا غیرمستقیم از آن‌ها ایجاد شده است) تأثیر می‌گذارد\&. این تنظیم بر فرآیندهایی که ممکن است به درخواست آن‌ها از طریق ابزارهایی مانند
\fBat\fR(1)،
\fBcrontab\fR(1)،
\fBsystemd-run\fR(1)
یا سرویس‌های دلخواه IPC فراخوانده شوند، تأثیری ندارد\&.
.sp
اضافه‌شده در نسخه 187\&.
.RE
.PP
\fISecureBits=\fR
.RS 4
بیت‌های امنیتی (secure bits) تنظیم‌شده برای فرآیند اجراشده را کنترل می‌کند\&. ترکیبی جداشده با فاصله از گزینه‌ها را از فهرست زیر می‌پذیرد:
\fBkeep\-caps\fR،
\fBkeep\-caps\-locked\fR،
\fBno\-setuid\-fixup\fR،
\fBno\-setuid\-fixup\-locked\fR،
\fBnoroot\fR
و
\fBnoroot\-locked\fR\&.
این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت بیت‌های امنیتی با هم OR می‌شوند\&. اگر رشته خالی به این گزینه اختصاص یابد، بیت‌ها به 0 بازنشانی می‌شوند\&. این گزینه بر دستورات دارای پیشوند
"+"
تأثیری ندارد\&. برای جزئیات به
\fBcapabilities\fR(7)
مراجعه کنید\&.
.RE
.SH "کنترل دسترسی اجباری (MANDATORY ACCESS CONTROL)"
.PP
\fISELinuxContext=\fR
.RS 4
زمینه امنیتی (security context) SELinux فرآیند اجراشده را تنظیم می‌کند\&. در صورت تنظیم، این گزینه انتقال خودکار دامنه (automated domain transition) را بازنویسی خواهد کرد\&. با این حال، خط‌مشی همچنان باید انتقال را مجاز بداند\&. اگر SELinux غیرفعال باشد، این دستورالعمل نادیده گرفته می‌شود\&. اگر با
"\-"
پیشوندگذاری شود، عدم موفقیت در تنظیم زمینه امنیتی SELinux نادیده گرفته خواهد شد، اما هنوز این امکان وجود دارد که
\fBexecve()\fR
بعدی در صورتی که خط‌مشی اجازه انتقال برای زمینه بازنویسی‌نشده را ندهد، با شکست مواجه شود\&. این گزینه بر دستورات دارای پیشوند
"+"
تأثیری ندارد\&. برای جزئیات به
\fBsetexeccon\fR(3)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 209\&.
.RE
.PP
\fIAppArmorProfile=\fR
.RS 4
یک نام نمایه (profile) را به عنوان آرگومان می‌پذیرد\&. فرآیند اجراشده توسط واحد در هنگام شروع به این نمایه تغییر وضعیت می‌دهد\&. نمایه‌ها باید قبلاً در هسته بارگذاری شده باشند، در غیر این صورت واحد با شکست مواجه خواهد شد\&. اگر با
"\-"
پیشوندگذاری شود، تمام خطاها نادیده گرفته می‌شوند\&. اگر AppArmor فعال نباشد، این تنظیم هیچ تأثیری ندارد\&. این تنظیم بر دستورات دارای پیشوند
"+"
تأثیری ندارد\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 210\&.
.RE
.PP
\fISmackProcessLabel=\fR
.RS 4
یک برچسب امنیتی
\fBSMACK64\fR
را به عنوان آرگومان می‌پذیرد\&. فرآیند اجراشده توسط واحد تحت این برچسب شروع به کار خواهد کرد و SMACK بر اساس آن تصمیم می‌گیرد که آیا فرآیند مجاز به اجرا است یا خیر\&. فرآیند به اجرای خود تحت برچسب مشخص‌شده در اینجا ادامه خواهد داد مگر اینکه فایل اجرایی دارای برچسب اختصاصی
\fBSMACK64EXEC\fR
باشد، که در این صورت فرآیند برای اجرا تحت آن برچسب تغییر وضعیت می‌دهد\&. در صورت عدم تعیین، از برچسبی که systemd تحت آن اجرا می‌شود استفاده خواهد شد\&. اگر SMACK غیرفعال باشد، این دستورالعمل نادیده گرفته می‌شود\&.
.sp
مقدار ممکن است با
"\-"
پیشوندگذاری شود، که در این صورت تمام خطاها نادیده گرفته می‌شوند\&. یک مقدار خالی ممکن است برای لغو تخصیص‌های قبلی مشخص شود\&. این گزینه بر دستورات دارای پیشوند
"+"
تأثیری ندارد\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 218\&.
.RE
.SH "ویژگی‌های فرآیند (PROCESS PROPERTIES)"
.PP
\fILimitCPU=\fR، \fILimitFSIZE=\fR، \fILimitDATA=\fR، \fILimitSTACK=\fR، \fILimitCORE=\fR، \fILimitRSS=\fR، \fILimitNOFILE=\fR، \fILimitAS=\fR، \fILimitNPROC=\fR، \fILimitMEMLOCK=\fR، \fILimitLOCKS=\fR، \fILimitSIGPENDING=\fR، \fILimitMSGQUEUE=\fR، \fILimitNICE=\fR، \fILimitRTPRIO=\fR، \fILimitRTTIME=\fR
.RS 4
محدودیت‌های نرم (soft) و سخت (hard) را روی منابع مختلف برای فرآیندهای اجراشده تنظیم می‌کند\&. برای جزئیات در مورد مفهوم محدودیت منابع فرآیند به
\fBsetrlimit\fR(2)
مراجعه کنید\&. محدودیت‌های منابع فرآیند ممکن است در دو قالب مشخص شوند: یا به صورت یک مقدار واحد برای تنظیم هر دو محدودیت نرم و سخت به همان مقدار، یا به صورت یک جفت جداشده با دونقطه
\fBsoft:hard\fR
برای تنظیم جداگانه هر دو محدودیت (به عنوان مثال
"LimitAS=4G:16G")\&.
از رشته
\fBinfinity\fR
برای پیکربندی نامحدود بودن روی یک منبع خاص استفاده کنید\&. پسوندهای ضرب‌شونده K، M، G، T، P و E (بر مبنای 1024) ممکن است برای محدودیت‌های منابع اندازه‌گیری‌شده بر حسب بایت استفاده شوند (مانند
"LimitAS=16G")\&.
برای محدودیت‌های مربوط به مقادیر زمانی، واحدهای زمانی معمول ms، s، min، h و غیره ممکن است استفاده شوند (برای جزئیات به
\fBsystemd.time\fR(7)
مراجعه کنید)\&. توجه داشته باشید که اگر هیچ واحد زمانی برای
\fILimitCPU=\fR
مشخص نشده باشد، واحد پیش‌فرض ثانیه در نظر گرفته می‌شود، در حالی که برای
\fILimitRTTIME=\fR
واحد پیش‌فرض میکروثانیه است\&. همچنین، توجه داشته باشید که دانه‌بندی (granularity) مؤثر محدودیت‌ها ممکن است بر اجرای آن‌ها تأثیر بگذارد\&. به عنوان مثال، محدودیت‌های زمانی مشخص‌شده برای
\fILimitCPU=\fR
به صورت ضمنی به مضارب 1s گرد می‌شوند\&. برای
\fILimitNICE=\fR
مقدار ممکن است در دو نحو مشخص شود: اگر با
"+"
یا
"\-"
پیشوندگذاری شود، مقدار به عنوان مقدار استاندارد nice لینوکس در محدوده \-20 تا 19 فهمیده می‌شود\&. اگر به این صورت پیشوندگذاری نشود، مقدار به عنوان پارامتر خام محدودیت منبع در محدوده 0 تا 40 (که در آن 0 معادل 1 است) درک می‌شود\&.
.sp
توجه داشته باشید که اکثر محدودیت‌های منابع فرآیند که با این گزینه‌ها پیکربندی شده‌اند به ازای هر فرآیند هستند، و فرآیندها ممکن است برای به دست آوردن مجموعه جدیدی از منابع که مستقل از فرآیند اصلی محاسبه می‌شوند فرآیند فرعی (fork) ایجاد کنند و بنابراین ممکن است از محدودیت‌های تعیین‌شده فرار کنند\&. همچنین توجه داشته باشید که
\fILimitRSS=\fR
در لینوکس پیاده‌سازی نشده است و تنظیم آن هیچ اثری ندارد\&. اغلب توصیه می‌شود که کنترل‌های منابع فهرست‌شده در
\fBsystemd.resource-control\fR(5)
را بر این محدودیت‌های به ازای هر فرآیند ترجیح دهید، زیرا آن‌ها بر سرویس‌ها به عنوان یک کل اعمال می‌شوند، ممکن است به صورت پویا در زمان اجرا تغییر یابند، و عموماً گویاتر هستند\&. به عنوان مثال،
\fIMemoryMax=\fR
یک جایگزین بسیار قدرتمندتر (و کاربردی) برای
\fILimitRSS=\fR
است\&.
.sp
توجه داشته باشید که
\fILimitNPROC=\fR
تعداد فرآیندهای مربوط به یک UID (واقعی) را محدود می‌کند و نه تعداد فرآیندهای شروع‌شده (fork شده) توسط سرویس را\&. بنابراین این محدودیت برای همه فرآیندهایی که تحت همان UID اجرا می‌شوند تجمیعی است\&. لطفاً توجه داشته باشید که اگر سرویس به عنوان root اجرا شود (و امتیازات خود را کاهش ندهد)،
\fILimitNPROC=\fR
اعمال نخواهد شد\&. به دلیل این محدودیت‌ها،
\fITasksMax=\fR
(به
\fBsystemd.resource-control\fR(5)
مراجعه کنید) معمولاً انتخابی بهتر از
\fILimitNPROC=\fR
است\&.
.sp
محدودیت‌های منابعی که به صراحت برای یک واحد پیکربندی نشده‌اند، پیش‌فرض روی مقدار پیکربندی‌شده در گزینه‌های مختلف
\fIDefaultLimitCPU=\fR،
\fIDefaultLimitFSIZE=\fR
و غیره موجود در
\fBsystemd-system.conf\fR(5)
قرار می‌گیرند، و \(en در صورت عدم پیکربندی در آنجا \(en پیش‌فرض‌های هسته یا پیش‌فرض‌های کاربر-محور که توسط سیستم‌عامل تعریف شده است (مورد دوم فقط برای سرویس‌های کاربری، به زیر مراجعه کنید)\&.
.sp
برای واحدهای سیستمی این محدودیت‌های منابع ممکن است آزادانه انتخاب شوند\&. هنگامی که این تنظیمات در یک سرویس کاربری پیکربندی می‌شوند (یعنی سرویسی که توسط نمونه کاربر-محور مدیر سرویس اجرا می‌شود) نمی‌توان از آن‌ها برای افزایش محدودیت‌ها به بالاتر از مقادیر تعیین‌شده برای خود مدیر کاربر در زمان اولین فراخوانی استفاده کرد، زیرا مدیر سرویس کاربر معمولاً فاقد امتیازات لازم برای انجام این کار است\&. در چارچوب کاربری، این گزینه‌های پیکربندی فقط برای کاهش محدودیت‌های دریافت‌شده یا افزایش محدودیت نرم به حداکثر محدودیت سخت همان‌طور که برای کاربر پیکربندی شده است مفید هستند\&. برای افزایش بیشتر محدودیت‌های کاربر، سازوکارهای پیکربندی موجود در بین سیستم‌های عامل متفاوت است، اما معمولاً نیازمند امتیازات مدیریتی است\&. در بیشتر موارد می‌توان محدودیت‌های منابع بالاتر به ازای هر کاربر را از طریق PAM یا با تنظیم محدودیت‌ها روی سرویس سیستمی که مدیر سرویس کاربر را کپسوله‌سازی می‌کند، یعنی نمونه
user@\&.service
کاربر، پیکربندی کرد\&. پس از اعمال چنین تغییراتی، حتماً مدیر سرویس کاربر را مجدداً راه‌اندازی کنید\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B جدول\& 1.\& دستورالعمل‌های محدودیت منابع، معادل‌های آن‌ها در دستور ulimit شل و واحد مورد استفاده
.TS
allbox tab(:);
lB lB lB lB.
T{
دستورالعمل
T}:T{
معادل \fBulimit\fR
T}:T{
واحد
T}:T{
یادداشت‌ها
T}
.T&
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l.
T{
LimitCPU=
T}:T{
ulimit \-t
T}:T{
ثانیه
T}:T{
\-
T}
T{
LimitFSIZE=
T}:T{
ulimit \-f
T}:T{
بایت
T}:T{
\-
T}
T{
LimitDATA=
T}:T{
ulimit \-d
T}:T{
بایت
T}:T{
استفاده نکنید\&. این گزینه محدوده آدرس مجاز را محدود می‌کند، نه مصرف حافظه را! پیش‌فرض نامحدود است و نباید کاهش یابد\&. برای محدود کردن مصرف حافظه، \fIMemoryMax=\fR را در \fBsystemd.resource-control\fR(5) ببینید\&.
T}
T{
LimitSTACK=
T}:T{
ulimit \-s
T}:T{
بایت
T}:T{
\-
T}
T{
LimitCORE=
T}:T{
ulimit \-c
T}:T{
بایت
T}:T{
\-
T}
T{
LimitRSS=
T}:T{
ulimit \-m
T}:T{
بایت
T}:T{
استفاده نکنید\&. در لینوکس هیچ اثری ندارد\&.
T}
T{
LimitNOFILE=
T}:T{
ulimit \-n
T}:T{
تعداد توصیف‌کننده‌های فایل
T}:T{
استفاده نکنید\&. هنگام افزایش محدودیت نرم به بالای 1024 محتاط باشید، زیرا \fBselect\fR(2) نمی‌تواند با توصیف‌کننده‌های فایل بالای 1023 در لینوکس کار کند\&. امروزه، حد سخت به طور پیش‌فرض روی 524288 است که در مقایسه با پیش‌فرض‌های تاریخی بسیار بالاست\&. به طور معمول برنامه‌ها در صورتی که با کار کردن با توصیف‌کننده‌های فایل بالای 1023 مشکلی نداشته باشند (یعنی از \fBselect\fR(2) استفاده نکنند)، باید خودشان حد نرم را تا حد سخت افزایش دهند\&. توجه داشته باشید که توصیف‌کننده‌های فایل امروزه مانند هر شکل دیگری از حافظه محاسبه می‌شوند، بنابراین نیازی به کاهش حد سخت وجود ندارد\&. از \fIMemoryMax=\fR برای کنترل مصرف کلی حافظه سرویس، از جمله حافظه توصیف‌کننده‌های فایل استفاده کنید\&.
T}
T{
LimitAS=
T}:T{
ulimit \-v
T}:T{
بایت
T}:T{
استفاده نکنید\&. این گزینه محدوده آدرس مجاز را محدود می‌کند، نه مصرف حافظه را! پیش‌فرض نامحدود است و نباید کاهش یابد\&. برای محدود کردن مصرف حافظه، \fIMemoryMax=\fR را در \fBsystemd.resource-control\fR(5) ببینید\&.
T}
T{
LimitNPROC=
T}:T{
ulimit \-u
T}:T{
تعداد فرآیندها
T}:T{
این محدودیت بر اساس تعداد فرآیندهای متعلق به کاربر اعمال می‌شود\&. به طور معمول بهتر است فرآیندها را به ازای هر سرویس ردیابی کنید، یعنی از \fITasksMax=\fR استفاده کنید، \fBsystemd.resource-control\fR(5) را ببینید\&.
T}
T{
LimitMEMLOCK=
T}:T{
ulimit \-l
T}:T{
بایت
T}:T{
\-
T}
T{
LimitLOCKS=
T}:T{
ulimit \-x
T}:T{
تعداد قفل‌ها
T}:T{
\-
T}
T{
LimitSIGPENDING=
T}:T{
ulimit \-i
T}:T{
تعداد سیگنال‌های در صف
T}:T{
\-
T}
T{
LimitMSGQUEUE=
T}:T{
ulimit \-q
T}:T{
بایت
T}:T{
\-
T}
T{
LimitNICE=
T}:T{
ulimit \-e
T}:T{
سطح Nice
T}:T{
\-
T}
T{
LimitRTPRIO=
T}:T{
ulimit \-r
T}:T{
اولویت زمان‌واقعی
T}:T{
\-
T}
T{
LimitRTTIME=
T}:T{
ulimit \-R
T}:T{
میکروثانیه
T}:T{
\-
T}
.TE
.sp
.RE
.PP
\fIUMask=\fR
.RS 4
ماسک ایجاد حالت فایل (umask) را کنترل می‌کند\&. یک حالت دسترسی در نماد هشت‌هشتی (octal) می‌پذیرد\&. برای جزئیات به
\fBumask\fR(2)
مراجعه کنید\&. پیش‌فرض 0022 برای واحدهای سیستمی است\&. برای واحدهای کاربری مقدار پیش‌فرض از مدیر سرویس کاربر-محور به ارث برده می‌شود (که پیش‌فرض آن نیز به نوبه خود از مدیر سرویس سیستم به ارث برده شده و بنابراین معمولاً 0022 است \(em مگر اینکه توسط یک ماژول PAM بازنویسی شده باشد)\&. به منظور تغییر umask کاربر-محور برای همه سرویس‌های کاربری، تنظیم
\fIUMask=\fR
در نمونه سرویس سیستمی
user@\&.service
کاربر را در نظر بگیرید\&. همچنین umask کاربر ممکن است از طریق فیلد
\fIumask\fR
از یک
\m[blue]\fBJSON User Record\fR\m[]\&\s-2\u[5]\d\s+2
کاربر تنظیم شود (برای کاربرانی که توسط
\fBsystemd-homed.service\fR(8)
مدیریت می‌شوند این فیلد ممکن است از طریق
\fBhomectl \-\-umask=\fR
کنترل شود)\&. همچنین ممکن است از طریق یک ماژول PAM مانند
\fBpam_umask\fR(8)
تنظیم شود\&.
.RE
.PP
\fICoredumpFilter=\fR
.RS 4
کنترل می‌کند که در صورت ایجاد تخلیه حافظه هسته (core dump) توسط فرآیند، کدام انواع نگاشت‌های حافظه ذخیره شوند (با استفاده از فایل
/proc/\fIpid\fR/coredump_filter)\&.
ترکیبی جداشده با فاصله از نام‌ها یا شماره‌های نوع نگاشت را می‌پذیرد (با مبنای پیش‌فرض 16)\&. نام‌های نوع نگاشت عبارتند از:
\fBprivate\-anonymous\fR،
\fBshared\-anonymous\fR،
\fBprivate\-file\-backed\fR،
\fBshared\-file\-backed\fR،
\fBelf\-headers\fR،
\fBprivate\-huge\fR،
\fBshared\-huge\fR،
\fBprivate\-dax\fR،
\fBshared\-dax\fR،
و مقادیر ویژه
\fBall\fR
(همه انواع) و
\fBdefault\fR
(پیش‌فرض هسته یعنی
"\fBprivate\-anonymous\fR \fBshared\-anonymous\fR \fBelf\-headers\fR \fBprivate\-huge\fR")\&.
برای معنای انواع نگاشت به
\fBcore\fR(5)
مراجعه کنید\&. هنگامی که چندین بار مشخص شود، تمام ماسک‌های مشخص‌شده با هم OR می‌شوند\&. در صورت عدم تنظیم، یا اگر مقدار خالی اختصاص یابد، مقدار به ارث برده شده تغییر نمی‌کند\&.
.PP
\fBمثال\& 2.\& افزودن صفحات DAX به فیلتر تخلیه حافظه\fR
.sp
.if n \{\
.RS 4
.\}
.nf
CoredumpFilter=default private\-dax shared\-dax
.fi
.if n \{\
.RE
.\}

اضافه‌شده در نسخه 246\&.
.RE
.PP
\fIKeyringMode=\fR
.RS 4
نحوه راه‌اندازی دسته کلید (keyring) نشست هسته را برای سرویس کنترل می‌کند (برای جزئیات درباره keyring نشست به
\fBsession-keyring\fR(7)
مراجعه کنید)\&. یکی از مقادیر
\fBinherit\fR،
\fBprivate\fR،
\fBshared\fR
را می‌پذیرد\&. اگر روی
\fBinherit\fR
تنظیم شود، هیچ راه‌اندازی خاصی برای دسته‌کلید انجام نمی‌شود و رفتار پیش‌فرض هسته اعمال می‌شود\&. اگر
\fBprivate\fR
استفاده شود، هنگام فراخوانی فرآیند سرویس، یک دسته‌کلید نشست جدید اختصاص داده می‌شود و با هیچ دسته‌کلید کاربری پیوند داده نمی‌شود\&. این تنظیم توصیه‌شده برای سرویس‌های سیستمی است، زیرا تضمین می‌کند که چندین سرویس که تحت یک شناسه کاربر سیستمی یکسان اجرا می‌شوند (به‌ویژه کاربر root) محتوای کلیدهای خود را با یکدیگر به اشتراک نگذارند\&. اگر
\fBshared\fR
استفاده شود، یک دسته‌کلید نشست جدید همانند حالت
\fBprivate\fR
اختصاص داده می‌شود، اما دسته‌کلید کاربرِ پیکربندی‌شده با
\fIUser=\fR
به درون آن پیوند داده می‌شود، به طوری که کلیدهای اختصاص‌یافته به کاربر توسط فرآیندهای واحد قابل درخواست باشد\&. در این حالت، چندین واحد که فرآیندهایی را تحت همان شناسه کاربری اجرا می‌کنند ممکن است محتوای کلید را به اشتراک بگذارند\&. مگر اینکه
\fBinherit\fR
انتخاب شده باشد، شناسه فراخوانی یکتا برای واحد (invocation ID، به زیر مراجعه کنید) به عنوان یک کلید محافظت‌شده با نام
"invocation_id"
به دسته‌کلید نشست تازه ایجادشده اضافه می‌شود\&. پیش‌فرض برای سرویس‌های مدیر سرویس سیستم روی
\fBprivate\fR
و برای واحدهای غیرسرویسی و سرویس‌های مدیر سرویس کاربر روی
\fBinherit\fR
است\&.
.sp
اضافه‌شده در نسخه 235\&.
.RE
.PP
\fIOOMScoreAdjust=\fR
.RS 4
مقدار تعدیل امتیاز قاتل کمبود حافظه هسته لینوکس (OOM Killer) را برای فرآیندهای اجراشده تنظیم می‌کند\&. یک عدد صحیح بین \-1000 (برای غیرفعال کردن کشتن فرآیندهای این واحد توسط OOM) و 1000 (برای بسیار محتمل کردن کشتن فرآیندهای این واحد تحت فشار حافظه) می‌پذیرد\&. برای جزئیات به
\m[blue]\fBThe /proc Filesystem\fR\m[]\&\s-2\u[6]\d\s+2
مراجعه کنید\&. در صورت عدم تعیین، پیش‌فرض روی سطح تعدیل امتیاز OOM خود مدیر سرویس قرار می‌گیرد که معمولاً روی 0 است\&.
.sp
از تنظیم
\fIOOMPolicy=\fR
در واحدهای سرویس برای پیکربندی نحوه واکنش مدیر سرویس به پایان دادن به یک فرآیند سرویس توسط قاتل OOM هسته یا
\fBsystemd\-oomd\fR
استفاده کنید\&. برای جزئیات به
\fBsystemd.service\fR(5)
مراجعه کنید\&.
.RE
.PP
\fITimerSlackNSec=\fR
.RS 4
میزان سستی تایمر (timer slack) را بر حسب نانوثانیه برای فرآیندهای اجراشده تنظیم می‌کند\&. سستی تایمر دقت بیدارباش‌های ناشی از تایمرها را کنترل می‌کند\&. برای اطلاعات بیشتر به
\fBprctl\fR(2)
مراجعه کنید\&. توجه داشته باشید که بر خلاف بیشتر تعاریف بازه زمانی دیگر، در صورتی که هیچ واحدی مشخص نشده باشد، این پارامتر یک مقدار صحیح بر حسب نانوثانیه دریافت می‌کند\&. واحدهای زمانی معمول نیز قابل درک هستند\&.
.RE
.PP
\fIPersonality=\fR
.RS 4
کنترل می‌کند که
\fBuname\fR(2)
هنگامی که توسط فرآیندهای واحد فراخوانده می‌شود، کدام معماری هسته را گزارش دهد\&. یکی از شناسه‌های معماری شامل
\fBarm64\fR،
\fBarm64\-be\fR،
\fBarm\fR،
\fBarm\-be\fR،
\fBx86\fR،
\fBx86\-64\fR،
\fBppc\fR،
\fBppc\-le\fR،
\fBppc64\fR،
\fBppc64\-le\fR،
\fBs390\fR
یا
\fBs390x\fR
را می‌پذیرد\&. اینکه کدام معماری‌های personality پشتیبانی می‌شوند به معماری بومی هسته بستگی دارد\&. معمولاً نسخه‌های ۶۴ بیتی معماری‌های مختلف سیستم از همتای معماری personality ۳۲ بیتی مستقیم خود پشتیبانی می‌کنند، اما نه دیگر معماری‌ها\&. به عنوان مثال، سیستم‌های
\fBx86\-64\fR
از personalityهای
\fBx86\-64\fR
و
\fBx86\fR
پشتیبانی می‌کنند اما نه دیگر موارد\&. ویژگی personality هنگام اجرای سرویس‌های ۳۲ بیتی روی یک سیستم میزبان ۶۴ بیتی مفید است\&. در صورت عدم تعیین، personality بدون تغییر باقی می‌ماند و بنابراین personality هسته سیستم میزبان را منعکس می‌کند\&. این گزینه در معماری‌هایی که همیشه تنها یک عرض کلمه بومی برای آن‌ها در دسترس بوده است، مانند
\fBm68k\fR
(فقط ۳۲ بیتی) یا
\fBalpha\fR
(فقط ۶۴ بیتی) مفید نیست\&.
.sp
اضافه‌شده در نسخه 209\&.
.RE
.PP
\fIIgnoreSIGPIPE=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. در صورت true بودن،
\fBSIGPIPE\fR
در فرآیند اجراشده نادیده گرفته می‌شود\&. پیش‌فرض true است زیرا
\fBSIGPIPE\fR
عموماً فقط در خط لوله‌های شل (shell pipelines) مفید است\&.
.RE
.SH "زمان‌بندی (SCHEDULING)"
.PP
\fINice=\fR
.RS 4
سطح nice پیش‌فرض (اولویت زمان‌بندی) را برای فرآیندهای اجراشده تنظیم می‌کند\&. یک عدد صحیح بین \-20 (بالاترین اولویت) و 19 (پایین‌ترین اولویت) می‌پذیرد\&. در صورت رقابت بر سر منابع، مقادیر کوچکتر به معنای منابع بیشتر در دسترس فرآیندهای واحد است و مقادیر بزرگتر به معنای منابع کمتر است\&. برای جزئیات به
\fBsetpriority\fR(2)
مراجعه کنید\&.
.RE
.PP
\fICPUSchedulingPolicy=\fR
.RS 4
خط‌مشی زمان‌بندی CPU را برای فرآیندهای اجراشده تنظیم می‌کند\&. یکی از مقادیر
\fBother\fR،
\fBbatch\fR،
\fBidle\fR،
\fBfifo\fR
یا
\fBrr\fR
را می‌پذیرد\&. برای جزئیات به
\fBsched_setscheduler\fR(2)
مراجعه کنید\&.
.RE
.PP
\fICPUSchedulingPriority=\fR
.RS 4
اولویت زمان‌بندی CPU را برای فرآیندهای اجراشده تنظیم می‌کند\&. محدوده اولویت موجود بستگی به خط‌مشی زمان‌بندی CPU انتخاب‌شده دارد (به بالا مراجعه کنید)\&. برای خط‌مشی‌های زمان‌بندی بی‌درنگ (real\-time) یک عدد صحیح بین 1 (پایین‌ترین اولویت) و 99 (بالاترین اولویت) می‌تواند استفاده شود\&. در صورت رقابت بر سر منابع CPU، مقادیر کوچکتر به معنای زمان CPU کمتر در دسترس برای سرویس است و مقادیر بزرگتر به معنای زمان بیشتر است\&. برای جزئیات به
\fBsched_setscheduler\fR(2)
مراجعه کنید\&.
.RE
.PP
\fICPUSchedulingResetOnFork=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. در صورت true بودن، اولویت‌ها و خط‌مشی‌های ارتقایافته زمان‌بندی CPU زمانی که فرآیندهای اجراشده
\fBfork\fR(2)
را فراخوانی کنند بازنشانی می‌شوند و از این رو نمی‌توانند به فرآیندهای فرزند نشت کنند\&. برای جزئیات به
\fBsched_setscheduler\fR(2)
مراجعه کنید\&. پیش‌فرض false است\&.
.RE
.PP
\fICPUAffinity=\fR
.RS 4
وابستگی CPU (همبستگی پردازنده‌ای یا CPU affinity) فرآیندهای اجراشده را کنترل می‌کند\&. فهرستی از شاخص‌ها یا محدوده‌های CPU جداشده با فاصله یا ویرگول را می‌پذیرد\&. به عنوان روش جایگزین، مقدار ویژه "numa" را می‌پذیرد که در این حالت systemd به طور خودکار محدوده مجاز CPU را بر اساس مقدار گزینه
\fINUMAMask=\fR
مشتق می‌کند\&. محدوده‌های CPU با شاخص‌های پایینی و بالایی CPU که با یک خط تیره جدا شده‌اند مشخص می‌شوند\&. این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت ماسک‌های تعیین‌شده همبستگی CPU ادغام می‌شوند\&. اگر رشته خالی اختصاص یابد، ماسک بازنشانی می‌شود و تمام تخصیص‌های قبلی بی‌اثر خواهند بود\&. برای جزئیات به
\fBsched_setaffinity\fR(2)
مراجعه کنید\&.
.RE
.PP
\fINUMAPolicy=\fR
.RS 4
خط‌مشی حافظه NUMA فرآیندهای اجراشده را کنترل می‌کند\&. یک نوع خط‌مشی، یکی از موارد:
\fBdefault\fR،
\fBpreferred\fR،
\fBbind\fR،
\fBinterleave\fR
و
\fBlocal\fR
را می‌پذیرد\&. فهرستی از گره‌های NUMA که باید با خط‌مشی مرتبط شوند باید در
\fINUMAMask=\fR
مشخص شود\&. برای جزئیات بیشتر درباره هر خط‌مشی لطفاً به
\fBset_mempolicy\fR(2)
مراجعه کنید\&. برای بررسی کلی پشتیبانی از NUMA در لینوکس به
\fBnuma\fR(7)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 243\&.
.RE
.PP
\fINUMAMask=\fR
.RS 4
فهرست گره‌های NUMA را کنترل می‌کند که در کنار خط‌مشی NUMA انتخاب‌شده اعمال خواهند شد\&. فهرستی از گره‌های NUMA را می‌پذیرد و نحوی مشابه فهرست CPUها برای گزینه
\fICPUAffinity=\fR
دارد یا مقدار ویژه "all" که تمام گره‌های NUMA موجود را در ماسک شامل می‌کند\&. توجه داشته باشید که فهرست گره‌های NUMA برای خط‌مشی‌های
\fBdefault\fR
و
\fBlocal\fR
لازم نیست و برای خط‌مشی
\fBpreferred\fR
انتظار یک گره NUMA منفرد را داریم\&.
.sp
اضافه‌شده در نسخه 243\&.
.RE
.PP
\fIIOSchedulingClass=\fR
.RS 4
کلاس زمان‌بندی I/O را برای فرآیندهای اجراشده تنظیم می‌کند\&. یکی از رشته‌های
\fBrealtime\fR،
\fBbest\-effort\fR
یا
\fBidle\fR
را می‌پذیرد\&. کلاس زمان‌بندی پیش‌فرض هسته
\fBbest\-effort\fR
با اولویت 4 است\&. اگر رشته خالی به این گزینه اختصاص یابد، تمام تخصیص‌های قبلی به هر دو گزینه
\fIIOSchedulingClass=\fR
و
\fIIOSchedulingPriority=\fR
بی‌اثر می‌شوند\&. برای جزئیات به
\fBioprio_set\fR(2)
مراجعه کنید\&.
.RE
.PP
\fIIOSchedulingPriority=\fR
.RS 4
اولویت زمان‌بندی I/O را برای فرآیندهای اجراشده تنظیم می‌کند\&. یک عدد صحیح بین 0 (بالاترین اولویت) و 7 (پایین‌ترین اولویت) می‌پذیرد\&. در صورت رقابت I/O، مقادیر کوچکتر به معنای پهنای باند I/O بیشتر در دسترس فرآیندهای واحد است و مقادیر بزرگتر به معنای پهنای باند کمتر است\&. اولویت‌های موجود بستگی به کلاس زمان‌بندی I/O انتخاب‌شده دارد (به بالا مراجعه کنید)\&. اگر رشته خالی به این گزینه اختصاص یابد، تمام تخصیص‌های قبلی به هر دو گزینه
\fIIOSchedulingClass=\fR
و
\fIIOSchedulingPriority=\fR
بی‌اثر می‌شوند\&. برای کلاس زمان‌بندی پیش‌فرض هسته (\fBbest\-effort\fR) این مقدار به طور پیش‌فرض 4 است\&. برای جزئیات به
\fBioprio_set\fR(2)
مراجعه کنید\&.
.RE
.SH "ایزوله‌سازی (SANDBOXING)"
.PP
گزینه‌های ایزوله‌سازی (sandboxing) زیر یک روش مؤثر برای محدود کردن دسترسی فرآیندهای واحد به کل سیستم هستند\&. توصیه می‌شود تا جایی که ممکن است بدون تأثیر منفی بر عملکرد فرآیند، بیشترین تعداد ممکن از این گزینه‌ها برای هر واحد فعال شوند\&. توجه داشته باشید که بسیاری از این ویژگی‌های ایزوله‌سازی در سیستم‌هایی که سازوکار امنیتی زیربنایی در آن‌ها در دسترس نیست، با ظرافت و بدون ایجاد خطا غیرفعال می‌شوند\&. برای مثال،
\fIProtectSystem=\fR
در صورتی که هسته بدون پشتیبانی از فضای نام سیستم‌فایل ساخته شده باشد یا اگر مدیر سرویس در یک مدیر کانتینر اجرا شود که فضای نام سیستم‌فایل را در دسترس بار کاری آن قرار نمی‌دهد، هیچ اثری ندارد\&. مشابهاً،
\fIRestrictRealtime=\fR
در سیستم‌هایی که فاقد پشتیبانی از فیلتر کردن فراخوان‌های سیستمی SECCOMP هستند، یا در کانتینرهایی که پشتیبانی از این قابلیت در آن‌ها خاموش است، هیچ اثری ندارد\&.
.PP
همچنین توجه داشته باشید که برخی از عملکردهای ایزوله‌سازی عموماً در سرویس‌های کاربری (یعنی سرویس‌هایی که توسط مدیر سرویس کاربر-محور اجرا می‌شوند) در دسترس نیستند\&. به طور خاص، تنظیمات مختلفی که نیاز به پشتیبانی از فضای نام سیستم‌فایل دارند (مانند
\fIProtectSystem=\fR)
در دسترس نیستند، زیرا قابلیت زیربنایی هسته فقط برای فرآیندهای باامتیاز قابل دسترسی است\&. با این حال، اکثر تنظیمات فضای نام که به تنهایی در سرویس‌های کاربری کار نمی‌کنند، در صورت استفاده همراه با
\fIPrivateUsers=\fR\fBtrue\fR
کار خواهند کرد\&.
.PP
توجه داشته باشید که گزینه‌های مختلفی که دایرکتوری‌ها را فقط‌خواندنی می‌کنند (مانند
\fIProtectSystem=\fR،
\fIReadOnlyPaths=\fR
و غیره) بر توانایی برنامه‌ها برای اتصال و ارتباط با سوکت‌های
\fBAF_UNIX\fR
در این دایرکتوری‌ها تأثیری ندارند\&. بنابراین نمی‌توان از این گزینه‌ها برای مسدود کردن دسترسی به سرویس‌های IPC استفاده کرد\&.
.PP
\fIProtectSystem=\fR
.RS 4
یک آرگومان بولی یا مقادیر ویژه
"full"
یا
"strict"
را می‌پذیرد\&. در صورت true بودن، دایرکتوری‌های
/usr/
و دایرکتوری‌های بارگذار بوت (/boot و /efi) را برای فرآیندهای فراخوانده‌شده توسط این واحد به صورت فقط‌خواندنی متصل می‌کند\&. اگر روی
"full"
تنظیم شود، دایرکتوری
/etc/
نیز به صورت فقط‌خواندنی متصل می‌شود\&. اگر روی
"strict"
تنظیم شود، کل سلسله‌مراتب سیستم‌فایل به صورت فقط‌خواندنی متصل می‌شود، به جز زیردرخت‌های سیستم‌فایل API شامل
/dev/،
/proc/
و
/sys/
(این دایرکتوری‌ها را با استفاده از
\fIPrivateDevices=\fR،
\fIProtectKernelTunables=\fR،
\fIProtectControlGroups=\fR
محافظت کنید)\&. این تنظیم تضمین می‌کند که هرگونه تغییر در سیستم‌عامل ارائه‌شده توسط توزیع‌کننده (و به صورت اختیاری پیکربندی آن و اتصالات محلی) برای سرویس ممنوع است\&. توصیه می‌شود این تنظیم برای تمام سرویس‌های با اجرای طولانی‌مدت فعال شود، مگر اینکه با به‌روزرسانی‌های سیستم در ارتباط باشند یا به روش‌های دیگر نیاز به تغییر سیستم‌عامل داشته باشند\&. در صورت استفاده از این گزینه،
\fIReadWritePaths=\fR
ممکن است برای مستثنی کردن دایرکتوری‌های خاص از فقط‌خواندنی شدن استفاده شود\&. مشابهاً،
\fIStateDirectory=\fR،
\fILogsDirectory=\fR
و تنظیمات دایرکتوری مرتبط (به زیر مراجعه کنید) نیز دایرکتوری‌های خاص را از اثر
\fIProtectSystem=\fR
مستثنی می‌کنند\&. این تنظیم در صورت تنظیم
\fIDynamicUser=\fR
به صورت ضمنی اعمال می‌شود\&. این تنظیم نمی‌تواند محافظت را در همه موارد تضمین کند\&. به طور کلی همان محدودیت‌های
\fIReadOnlyPaths=\fR
را دارد، به زیر مراجعه کنید\&. پیش‌فرض خاموش (off) است\&.
.sp
توجه داشته باشید که اگر
\fIProtectSystem=\fR
روی
"strict"
تنظیم شده باشد و
\fIPrivateTmp=\fR
فعال باشد، آن‌گاه
/tmp/
و
/var/tmp/
قابل نوشتن خواهند بود\&.
.sp
اضافه‌شده در نسخه 214\&.
.RE
.PP
\fIProtectHome=\fR
.RS 4
یک آرگومان بولی یا مقادیر ویژه
"read\-only"
یا
"tmpfs"
را می‌پذیرد\&. در صورت true بودن، دایرکتوری‌های
/home/،
/root
و
/run/user
برای فرآیندهای فراخوانده‌شده توسط این واحد غیرقابل دسترس و خالی می‌شوند\&. اگر روی
"read\-only"
تنظیم شود، این سه دایرکتوری در عوض فقط‌خواندنی می‌شوند\&. اگر روی
"tmpfs"
تنظیم شود، سیستم‌های فایل موقت روی این سه دایرکتوری در حالت فقط‌خواندنی متصل می‌شوند\&. مقدار
"tmpfs"
برای پنهان کردن دایرکتوری‌های خانگی که به فرآیندهای فراخوانده‌شده توسط واحد مربوط نیستند مفید است، در حالی که همچنان اجازه می‌دهد دایرکتوری‌های لازم در صورت فهرست شدن در
\fIBindPaths=\fR
یا
\fIBindReadOnlyPaths=\fR
قابل مشاهده باشند\&.
.sp
تنظیم این گزینه روی
"yes"
عمدتاً معادل تنظیم این سه دایرکتوری در
\fIInaccessiblePaths=\fR
است\&. مشابهاً،
"read\-only"
عمدتاً معادل
\fIReadOnlyPaths=\fR
است، و
"tmpfs"
عمدتاً معادل
\fITemporaryFileSystem=\fR
با
":ro"
است\&.
.sp
توصیه می‌شود این تنظیم برای تمام سرویس‌های با اجرای طولانی‌مدت (به‌ویژه سرویس‌های متصل به شبکه) فعال شود تا اطمینان حاصل گردد که نمی‌توانند به داده‌های خصوصی کاربر دسترسی پیدا کنند، مگر اینکه سرویس‌ها واقعاً به دسترسی به داده‌های خصوصی کاربر نیاز داشته باشند\&. این تنظیم در صورت تنظیم
\fIDynamicUser=\fR
به صورت ضمنی اعمال می‌شود\&. این تنظیم نمی‌تواند در تمام موارد محافظت را تضمین کند\&. به طور کلی همان محدودیت‌های
\fIReadOnlyPaths=\fR
را دارد، به زیر مراجعه کنید\&.
.sp
توجه داشته باشید که اگر دایرکتوری‌های خانگی در مکانی غیراستاندارد، یعنی خارج از سلسله‌مراتب‌های فهرست‌شده در بالا قرار گیرند، این تنظیم هیچ محافظتی ارائه نمی‌دهد\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافه‌شده در نسخه 214\&.
.RE
.PP
\fIRuntimeDirectory=\fR، \fIStateDirectory=\fR، \fICacheDirectory=\fR، \fILogsDirectory=\fR، \fIConfigurationDirectory=\fR
.RS 4
این گزینه‌ها فهرستی از نام‌های دایرکتوری جداشده با فاصله را می‌پذیرند\&. نام‌های دایرکتوری مشخص‌شده باید نسبی باشند و نباید شامل
"\&.\&."
باشند\&. در صورت تنظیم، هنگامی که واحد شروع به کار می‌کند، یک یا چند دایرکتوری با نام‌های مشخص‌شده (شامل والدین آن‌ها) در زیر مکان‌های تعریف‌شده در جدول زیر ایجاد خواهند شد\&. همچنین، متغیر محیطی متناظر با مسیرهای کامل دایرکتوری‌ها تعریف خواهد شد\&. اگر چندین دایرکتوری تنظیم شده باشد، در متغیر محیطی مسیرها با دونقطه (":") به هم متصل می‌شوند\&.
.sp
اگر
\fIDynamicUser=\fR
استفاده شود و اگر نسخه هسته از
\m[blue]\fBاتصالات با نگاشت شناسه (id-mapped mounts)\fR\m[]\&\s-2\u[7]\d\s+2
پشتیبانی کند، دایرکتوری‌های مشخص‌شده متعلق به "nobody" در فضای نام میزبان خواهند بود و به UID/GID سرویس در فضای نام خودش نگاشت می‌شوند (و تحت مالکیت آن قرار می‌گیرند)\&. برای سازگاری با گذشته، دایرکتوری‌های موجود ایجادشده بدون اتصالات با نگاشت شناسه بدون دستکاری باقی خواهند ماند\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B جدول\& 2.\& ایجاد خودکار دایرکتوری و متغیرهای محیطی
.TS
allbox tab(:);
lB lB lB lB.
T{
دایرکتوری
T}:T{
مسیر زیرین برای واحدهای سیستمی
T}:T{
مسیر زیرین برای واحدهای کاربری
T}:T{
متغیر محیطی تنظیم‌شده
T}
.T&
l l l l
l l l l
l l l l
l l l l
l l l l.
T{
\fIRuntimeDirectory=\fR
T}:T{
/run/
T}:T{
\fI/run/user/1000\fR
T}:T{
\fI\fR
T}
T{
\fIStateDirectory=\fR
T}:T{
/var/lib/
T}:T{
\fI\fR
T}:T{
\fI\fR
T}
T{
\fICacheDirectory=\fR
T}:T{
/var/cache/
T}:T{
\fI\fR
T}:T{
\fI\fR
T}
T{
\fILogsDirectory=\fR
T}:T{
/var/log/
T}:T{
\fI\fR/log/
T}:T{
\fI\fR
T}
T{
\fIConfigurationDirectory=\fR
T}:T{
/etc/
T}:T{
\fI\fR
T}:T{
\fI\fR
T}
.TE
.sp 1
در مورد
\fIRuntimeDirectory=\fR
درونی‌ترین زیردایرکتوری‌ها در هنگام متوقف شدن واحد حذف می‌شوند\&. در این حالت در صورتی که
\fIRuntimeDirectoryPreserve=\fR
روی
\fBrestart\fR
یا
\fByes\fR
پیکربندی شده باشد، حفظ دایرکتوری‌های مشخص‌شده امکان‌پذیر است (به زیر مراجعه کنید)\&. دایرکتوری‌های مشخص‌شده با
\fIStateDirectory=\fR،
\fICacheDirectory=\fR،
\fILogsDirectory=\fR،
\fIConfigurationDirectory=\fR
هنگام توقف واحد حذف نمی‌شوند\&.
.sp
به جز در مورد
\fIConfigurationDirectory=\fR،
درونی‌ترین دایرکتوری‌های مشخص‌شده تحت مالکیت کاربر و گروه مشخص‌شده در
\fIUser=\fR
و
\fIGroup=\fR
خواهند بود\&. اگر دایرکتوری‌های مشخص‌شده از قبل وجود داشته باشند و کاربر یا گروه مالک آن‌ها با موارد پیکربندی‌شده مطابقت نداشته باشد، مالکیت تمام فایل‌ها و دایرکتوری‌های زیر دایرکتوری‌های مشخص‌شده و همچنین خود دایرکتوری‌ها به صورت بازگشتی تغییر می‌کند تا با موارد پیکربندی‌شده مطابقت یابد\&. به عنوان یک بهینه‌سازی، اگر دایرکتوری‌های مشخص‌شده از قبل متعلق به کاربر و گروه مناسب باشند، فایل‌ها و دایرکتوری‌های زیرین آن‌ها دست‌نخورده باقی می‌مانند، حتی اگر با آنچه درخواست شده مطابقت نداشته باشند\&. حالت دسترسی درونی‌ترین دایرکتوری‌های مشخص‌شده مطابق با آنچه در
\fIRuntimeDirectoryMode=\fR،
\fIStateDirectoryMode=\fR،
\fICacheDirectoryMode=\fR،
\fILogsDirectoryMode=\fR
و
\fIConfigurationDirectoryMode=\fR
مشخص شده است تنظیم خواهد شد\&.
.sp
این گزینه‌ها به صورت ضمنی
\fIBindPaths=\fR
را برای مسیرهای مشخص‌شده فعال می‌کنند\&. هنگامی که با
\fIRootDirectory=\fR
یا
\fIRootImage=\fR
ترکیب شوند، این مسیرها همیشه روی میزبان قرار دارند و از آنجا به درون فضای نام سیستم‌فایل واحد متصل می‌شوند\&.
.sp
اگر از
\fIDynamicUser=\fR
استفاده شود، منطق
\fICacheDirectory=\fR،
\fILogsDirectory=\fR
و
\fIStateDirectory=\fR
کمی تغییر می‌کند: دایرکتوری‌ها به ترتیب در زیر
/var/cache/private،
/var/log/private
و
/var/lib/private
ایجاد می‌شوند که دایرکتوری‌های میزبانی هستند که برای کاربران بدون امتیاز غیرقابل دسترسی شده‌اند، که این امر تضمین می‌کند دسترسی به این دایرکتوری‌ها از طریق بازیافت شناسه کاربر پویا حاصل نمی‌شود\&. پیوندهای نمادین (symlinks) برای پنهان کردن این تفاوت در رفتار ایجاد می‌شوند\&. از این رو، چه از دید میزبان و چه از درون واحد، دایرکتوری‌های مربوطه همیشه مستقیماً در زیر
/var/cache،
/var/log
و
/var/lib
ظاهر می‌شوند\&.
.sp
از
\fIRuntimeDirectory=\fR
برای مدیریت یک یا چند دایرکتوری زمان اجرا برای واحد و پیوند دادن طول عمر آن‌ها به زمان اجرای دیمون استفاده کنید\&. این گزینه به‌ویژه برای دیمون‌های بدون امتیازی که به دلیل فقدان امتیاز نمی‌توانند دایرکتوری‌های زمان اجرا در
/run/
ایجاد کنند، و برای اطمینان از اینکه دایرکتوری زمان اجرا پس از استفاده به‌طور خودکار پاک‌سازی می‌شود، مفید است\&. برای دایرکتوری‌های زمان اجرایی که به پیکربندی پیچیده‌تر یا متفاوت یا تضمین‌های طول عمر نیاز دارند، لطفاً استفاده از
\fBtmpfiles.d\fR(5)
را در نظر بگیرید\&.
.sp
گزینه‌های
\fIRuntimeDirectory=\fR،
\fIStateDirectory=\fR،
\fICacheDirectory=\fR
و
\fILogsDirectory=\fR
به صورت اختیاری از دو پارامتر دیگر، جداشده با
":"
پشتیبانی می‌کنند\&. پارامتر دوم به عنوان یک مسیر مقصد تفسیر خواهد شد که به عنوان یک پیوند نمادین (symlink) به دایرکتوری ایجاد می‌شود\&. پیوندهای نمادین پس از تنظیم هر یک از گزینه‌های
\fIBindPaths=\fR
یا
\fITemporaryFileSystem=\fR
ایجاد می‌شوند تا پیوند نمادین زودگذر امکان‌پذیر شود\&. یک منبع یکسان می‌تواند چندین پیوند نمادین داشته باشد، با استفاده از همان پارامتر اول یکسان اما یک پارامتر دوم متفاوت\&. پارامتر سوم یک فیلد پرچم است و از نسخه 257 می‌تواند مقدار
\fBro\fR
را بگیرد تا دایرکتوری را برای سرویس فقط‌خواندنی کند\&. این مورد برای
\fIConfigurationDirectory=\fR
نیز پشتیبانی می‌شود\&. اگر چندین پیوند نمادین تنظیم شده باشد، در صورتی که حداقل یکی به صورت فقط‌خواندنی پیکربندی شده باشد، دایرکتوری فقط‌خواندنی خواهد بود\&. برای ارسال یک پرچم بدون پیوند نمادین مقصد، پارامتر دوم می‌تواند خالی باشد، به عنوان مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
ConfigurationDirectory=foo::ro
.fi
.if n \{\
.RE
.\}
.sp
دایرکتوری‌های تعریف‌شده توسط این گزینه‌ها همیشه در زیر مسیرهای استاندارد مورد استفاده توسط systemd (/var/، /run/، /etc/ و غیره) ایجاد می‌شوند\&. اگر سرویس به دایرکتوری‌هایی در مکانی متفاوت نیاز دارد، باید از سازوکار دیگری برای ایجاد آن‌ها استفاده شود\&.
.sp
ابزار
\fBtmpfiles.d\fR(5)
عملکردی را ارائه می‌دهد که با این گزینه‌ها همپوشانی دارد\&. استفاده از این گزینه‌ها توصیه می‌شود زیرا طول عمر دایرکتوری‌ها مستقیماً به طول عمر واحد گره خورده است، و نیازی به اطمینان از اجرای پیکربندی tmpfiles\&.d قبل از شروع واحد نیست\&.
.sp
برای حذف هر یک از دایرکتوری‌های ایجادشده توسط این تنظیمات، از دستور
\fBsystemctl clean \&...\fR
روی واحدهای مربوطه استفاده کنید، برای جزئیات به
\fBsystemctl\fR(1)
مراجعه کنید\&.
.sp
مثال: اگر یک واحد سرویس سیستمی دارای موارد زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
RuntimeDirectory=foo/bar baz
.fi
.if n \{\
.RE
.\}
.sp
مدیر سرویس مسیر
/run/foo
(اگر وجود نداشته باشد)،
/run/foo/bar
و
/run/baz
را ایجاد می‌کند\&. دایرکتوری‌های
/run/foo/bar
و
/run/baz
به جز
/run/foo
تحت مالکیت کاربر و گروه مشخص‌شده در
\fIUser=\fR
و
\fIGroup=\fR
هستند و با توقف سرویس حذف می‌شوند\&.
.sp
مثال: اگر یک واحد سرویس سیستمی دارای موارد زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
RuntimeDirectory=foo/bar
StateDirectory=aaa/bbb ccc
.fi
.if n \{\
.RE
.\}
.sp
آن‌گاه متغیر محیطی
"RUNTIME_DIRECTORY"
با مقدار
"/run/foo/bar"
و
"STATE_DIRECTORY"
با مقدار
"/var/lib/aaa/bbb:/var/lib/ccc"
تنظیم می‌شود\&.
.sp
مثال: اگر یک واحد سرویس سیستمی دارای موارد زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
RuntimeDirectory=foo:bar foo:baz
.fi
.if n \{\
.RE
.\}
.sp
مدیر سرویس
/run/foo
(اگر وجود نداشته باشد) و
/run/bar
به همراه
/run/baz
را به عنوان پیوندهای نمادین به
/run/foo
ایجاد می‌کند\&.
.sp
اضافه‌شده در نسخه 211\&.
.RE
.PP
\fIRuntimeDirectoryMode=\fR، \fIStateDirectoryMode=\fR، \fICacheDirectoryMode=\fR، \fILogsDirectoryMode=\fR، \fIConfigurationDirectoryMode=\fR
.RS 4
حالت دسترسی دایرکتوری‌های مشخص‌شده در
\fIRuntimeDirectory=\fR،
\fIStateDirectory=\fR،
\fICacheDirectory=\fR،
\fILogsDirectory=\fR
یا
\fIConfigurationDirectory=\fR
را به ترتیب به عنوان یک عدد هشت‌هشتی (octal) مشخص می‌کند\&. پیش‌فرض
\fB0755\fR
است\&. برای بحث درباره معنای بیت‌های مجوز به Permissions در
\fBpath_resolution\fR(7)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 234\&.
.RE
.PP
\fIRuntimeDirectoryPreserve=\fR
.RS 4
یک آرگومان بولی یا
\fBrestart\fR
را می‌پذیرد\&. اگر روی
\fBno\fR
(پیش‌فرض) تنظیم شود، دایرکتوری‌های مشخص‌شده در
\fIRuntimeDirectory=\fR
همیشه با توقف سرویس حذف می‌شوند\&. اگر روی
\fBrestart\fR
تنظیم شود، دایرکتوری‌ها هنگام راه‌اندازی مجدد خودکار و دستی سرویس حفظ می‌شوند\&. در اینجا، راه‌اندازی مجدد خودکار به معنای عملیات مشخص‌شده در
\fIRestart=\fR
و راه‌اندازی مجدد دستی به معنای عملیاتی است که توسط
\fBsystemctl restart foo\&.service\fR
آغاز می‌شود\&. اگر روی
\fByes\fR
تنظیم شود، دایرکتوری‌ها هنگام توقف سرویس حذف نمی‌شوند\&. توجه داشته باشید که از آنجا که دایرکتوری زمان اجرای
/run/
یک نقطه اتصال از نوع
"tmpfs"
است، برای سرویس‌های سیستمی دایرکتوری‌های مشخص‌شده در
\fIRuntimeDirectory=\fR
هنگام راه‌اندازی مجدد سیستم حذف می‌شوند\&.
.sp
اضافه‌شده در نسخه 235\&.
.RE
.PP
\fITimeoutCleanSec=\fR
.RS 4
یک مهلت زمانی را برای عملیات پاک‌سازی درخواست‌شده از طریق
\fBsystemctl clean \&...\fR
پیکربندی می‌کند، برای جزئیات به
\fBsystemctl\fR(1)
مراجعه کنید\&. مقادیر زمانی معمول را می‌پذیرد و پیش‌فرض آن
\fBinfinity\fR
است، یعنی به طور پیش‌فرض هیچ مهلت زمانی اعمال نمی‌شود\&. اگر یک مهلت زمانی پیکربندی شود، عملیات پاک‌سازی در صورت رسیدن به مهلت زمانی به اجبار متوقف می‌شود، که احتمالاً منابعی را روی دیسک باقی می‌گذارد\&.
.sp
اضافه‌شده در نسخه 244\&.
.RE
.PP
\fIReadWritePaths=\fR، \fIReadOnlyPaths=\fR، \fIInaccessiblePaths=\fR، \fIExecPaths=\fR، \fINoExecPaths=\fR
.RS 4
یک فضای نام سیستم‌فایل جدید برای فرآیندهای اجراشده راه‌اندازی می‌کند\&. این گزینه‌ها ممکن است برای محدود کردن دسترسی یک فرآیند به سیستم‌فایل استفاده شوند\&. هر تنظیم فهرستی جداشده با فاصله از مسیرها را نسبت به دایرکتوری ریشه میزبان (یعنی سیستمی که مدیر سرویس را اجرا می‌کند) می‌پذیرد\&. توجه داشته باشید که اگر مسیرها حاوی پیوندهای نمادین باشند، نسبت به دایرکتوری ریشه تنظیم‌شده با
\fIRootDirectory=\fR/\fIRootImage=\fR
حل‌وفصل می‌شوند\&.
.sp
مسیرهای فهرست‌شده در
\fIReadWritePaths=\fR
از درون فضای نام با همان حالت‌های دسترسی مانند بیرون از آن قابل دسترسی هستند\&. مسیرهای فهرست‌شده در
\fIReadOnlyPaths=\fR
فقط برای خواندن قابل دسترسی هستند و نوشتن در آن‌ها رد خواهد شد حتی اگر کنترل‌های دسترسی معمول فایل این اجازه را بدهند\&. برای ارائه زیردایرکتوری‌های قابل نوشتن در داخل دایرکتوری‌های فقط‌خواندنی،
\fIReadWritePaths=\fR
را در داخل
\fIReadOnlyPaths=\fR
تودرتو قرار دهید\&. اگر از
\fIProtectSystem=strict\fR
استفاده می‌شود، از
\fIReadWritePaths=\fR
برای قرار دادن مسیرهای خاص در فهرست مجاز برای دسترسی نوشتن استفاده کنید\&. توجه داشته باشید که نمی‌توان از
\fIReadWritePaths=\fR
برای به دست آوردن دسترسی نوشتن به سیستم‌فایلی که ابربلوک (superblock) آن فقط‌خواندنی متصل شده است استفاده کرد\&. در لینوکس، برای هر نقطه اتصال، دسترسی نوشتن تنها در صورتی اعطا می‌شود که خود نقطه اتصال
\fIو\fR
ابربلوک سیستم‌فایل پشتیبان آن به صورت فقط‌خواندنی علامت‌گذاری نشده باشند\&.
\fIReadWritePaths=\fR
فقط اولی را کنترل می‌کند نه دومی را، بنابراین یک ابربلوک سیستم‌فایل فقط‌خواندنی همچنان محافظت‌شده باقی می‌ماند\&.
.sp
مسیرهای فهرست‌شده در
\fIInaccessiblePaths=\fR
برای فرآیندهای درون فضای نام به همراه همه موارد زیر آن‌ها در سلسله‌مراتب سیستم‌فایل غیرقابل دسترسی خواهند شد\&. این ممکن است محدودکننده‌تر از حد مورد نظر باشد، زیرا امکان تودرتو کردن
\fIReadWritePaths=\fR،
\fIReadOnlyPaths=\fR،
\fIBindPaths=\fR
یا
\fIBindReadOnlyPaths=\fR
در داخل آن وجود ندارد\&. برای گزینه‌ای انعطاف‌پذیرتر، به
\fITemporaryFileSystem=\fR
مراجعه کنید\&.
.sp
محتوای موجود در مسیرهای فهرست‌شده در
\fINoExecPaths=\fR
قابل اجرا نیست حتی اگر کنترل‌های دسترسی معمول فایل این اجازه را بدهند\&. برای ارائه محتوای قابل اجرا در دایرکتوری‌های غیرقابل اجرا،
\fIExecPaths=\fR
را در داخل
\fINoExecPaths=\fR
تودرتو قرار دهید\&.
.sp
مسیرهای غیردایرکتوری نیز ممکن است مشخص شوند\&. این گزینه‌ها ممکن است بیش از یک بار مشخص شوند، که در این صورت تمام مسیرهای فهرست‌شده دسترسی محدودی از درون فضای نام خواهند داشت\&. اگر رشته خالی به این گزینه اختصاص یابد، فهرست مربوطه بازنشانی می‌شود و تمام تخصیص‌های قبلی بی‌اثر خواهند بود\&.
.sp
مسیرها در
\fIReadWritePaths=\fR،
\fIReadOnlyPaths=\fR،
\fIInaccessiblePaths=\fR،
\fIExecPaths=\fR
و
\fINoExecPaths=\fR
ممکن است دارای پیشوند
"\-"
باشند، که در این صورت در صورت عدم وجود نادیده گرفته می‌شوند\&. اگر با
"+"
پیشوندگذاری شوند، مسیرها نسبت به دایرکتوری ریشه واحد، همان‌طور که با
\fIRootDirectory=\fR/\fIRootImage=\fR
پیکربندی شده است، به جای نسبت به دایرکتوری ریشه میزبان در نظر گرفته می‌شوند (به بالا مراجعه کنید)\&. هنگام ترکیب
"\-"
و
"+"
روی یک مسیر یکسان، حتماً ابتدا
"\-"
و سپس
"+"
را مشخص کنید\&.
.sp
توجه داشته باشید که این تنظیمات انتشار اتصالات از فرآیندهای واحد به میزبان را قطع خواهد کرد\&. این بدان معناست که این تنظیم ممکن است برای سرویس‌هایی که باید بتوانند نقاط اتصال را در فضای نام اصلی اتصال نصب کنند، استفاده نشود\&. برای
\fIReadWritePaths=\fR
و
\fIReadOnlyPaths=\fR،
انتشار در جهت دیگر تحت تأثیر قرار نمی‌گیرد، یعنی اتصالات ایجادشده در میزبان عموماً در فضای نام فرآیندهای واحد ظاهر می‌شوند، و اتصالات حذف‌شده در میزبان نیز در آنجا ناپدید می‌شوند\&. به ویژه، توجه داشته باشید که انتشار اتصال از میزبان به واحد منجر به ایجاد اتصالات بدون تغییر در فضای نام واحد می‌شود، یعنی اتصالات قابل نوشتنی که در میزبان ظاهر می‌شوند در فضای نام واحد نیز قابل نوشتن خواهند بود، حتی زمانی که در زیر مسیری که با
\fIReadOnlyPaths=\fR
علامت‌گذاری شده منتشر شوند! بنابراین محدود کردن دسترسی با این گزینه‌ها به اتصالات فرعی دایرکتوری که بعداً ایجاد می‌شوند تعمیم نمی‌یابد\&. این بدان معناست که قفل امنیتی ارائه‌شده توسط این تنظیم کامل نیست و محافظت تمام و کمال ارائه نمی‌دهد\&.
.sp
توجه داشته باشید که اثر این تنظیمات ممکن است توسط فرآیندهای دارای امتیاز باطل شود\&. بنابراین برای راه‌اندازی یک محیط ایزوله مؤثر برای یک واحد، توصیه می‌شود این تنظیمات را با
\fICapabilityBoundingSet=~CAP_SYS_ADMIN\fR
یا
\fISystemCallFilter=~@mount\fR
ترکیب کنید\&.
.sp
لطفاً هنگام اعمال این گزینه‌ها روی سیستم‌های فایل API (فهرستی از آن‌ها در
\fIMountAPIVFS=\fR
یافت می‌شود) بسیار محتاط باشید، زیرا ممکن است برای عملکردهای اساسی سیستم مورد نیاز باشند\&. علاوه بر این،
/run/
برای راه‌اندازی فضای نام اتصال و انتشار باید قابل نوشتن باشد\&.
.sp
مثال ساده فهرست مجاز با استفاده از این دستورالعمل‌ها:
.sp
.if n \{\
.RS 4
.\}
.nf
[Service]
ReadOnlyPaths=/
ReadWritePaths=/var /run
InaccessiblePaths=\-/lost+found
NoExecPaths=/
ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64
.fi
.if n \{\
.RE
.\}
.sp
این گزینه‌ها فقط برای سرویس‌های سیستمی یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس هستند که در این صورت
\fIPrivateUsers=\fR
به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافه‌شده در نسخه 231\&.
.RE
.PP
\fITemporaryFileSystem=\fR
.RS 4
فهرستی جداشده با فاصله از نقاط اتصال برای سیستم‌های فایل موقت (tmpfs) را می‌پذیرد\&. در صورت تنظیم، یک فضای نام سیستم‌فایل جدید برای فرآیندهای اجراشده راه‌اندازی می‌شود و یک سیستم‌فایل موقت روی هر نقطه اتصال متصل می‌شود\&. این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت سیستم‌های فایل موقت روی تمام نقاط اتصال فهرست‌شده متصل می‌شوند\&. اگر رشته خالی به این گزینه اختصاص یابد، فهرست بازنشانی می‌شود و تمام تخصیص‌های قبلی بی‌اثر خواهند بود\&. هر نقطه اتصال ممکن است به صورت اختیاری با یک دونقطه (":") و گزینه‌های اتصال مانند
"size=10%"
یا
"ro"
پسوندگذاری شود\&. به طور پیش‌فرض، هر سیستم‌فایل موقت با
"nodev,strictatime,mode=0755"
متصل می‌شود\&. این موارد را می‌توان با مشخص کردن صریح گزینه‌های اتصال متناظر، مانند
"dev"
یا
"nostrictatime"
غیرفعال کرد\&.
.sp
این گزینه برای پنهان کردن فایل‌ها یا دایرکتوری‌هایی که به فرآیندهای فراخوانده‌شده توسط واحد مربوط نیستند مفید است، در حالی که فایل‌ها یا دایرکتوری‌های ضروری همچنان می‌توانند با ترکیب با
\fIBindPaths=\fR
یا
\fIBindReadOnlyPaths=\fR
قابل دسترسی باشند:
.sp
مثال: اگر یک واحد دارای موارد زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
TemporaryFileSystem=/var:ro
BindReadOnlyPaths=/var/lib/systemd
.fi
.if n \{\
.RE
.\}
.sp
آن‌گاه فرآیندهای فراخوانده‌شده توسط واحد نمی‌توانند هیچ فایل یا دایرکتوری زیر
/var/
را ببینند به جز
/var/lib/systemd
یا محتویات آن\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافه‌شده در نسخه 238\&.
.RE
.PP
\fIPrivateTmp=\fR
.RS 4
یک آرگومان بولی، یا
"disconnected"
را می‌پذیرد\&. در صورت فعال بودن، یک فضای نام سیستم‌فایل جدید برای فرآیندهای اجراشده راه‌اندازی می‌شود و دایرکتوری‌های
/tmp/
و
/var/tmp/
درون آن با فرآیندهای خارج از فضای نام به اشتراک گذاشته نمی‌شوند، به علاوه تمام فایل‌های موقت ایجادشده توسط یک سرویس در این دایرکتوری‌ها پس از توقف سرویس حذف خواهند شد\&. اگر
"true"
باشد، حافظه ذخیره‌سازی پشتیبان دایرکتوری‌های موقت خصوصی روی دایرکتوری‌های
/tmp/
و
/var/tmp/
میزبان باقی می‌ماند\&. اگر
"disconnected"
باشد، دایرکتوری‌ها توسط یک نمونه کاملاً جدید tmpfs پشتیبانی می‌شوند، به این معنی که فضای ذخیره‌سازی کاملاً از فضای نام میزبان جدا شده است\&. پیش‌فرض false است\&.
.sp
این تنظیم برای ایمن‌سازی دسترسی به فایل‌های موقت فرآیند مفید است، اما اشتراک‌گذاری بین فرآیندها از طریق
/tmp/
یا
/var/tmp/
را غیرممکن می‌سازد\&. اگر روی
"disconnected"
تنظیم نشده باشد، اجرای دو یا چند واحد در یک فضای نام خصوصی مشترک
/tmp/
و
/var/tmp/
با استفاده از دستورالعمل
\fIJoinsNamespaceOf=\fR
امکان‌پذیر است؛ برای جزئیات به
\fBsystemd.unit\fR(5)
مراجعه کنید\&. این تنظیم در صورت تنظیم
\fIDynamicUser=\fR
به صورت ضمنی اعمال می‌شود\&. برای این تنظیم، همان محدودیت‌های مربوط به انتشار اتصالات و امتیازات مانند
\fIReadOnlyPaths=\fR
و فراخوانی‌های مرتبط اعمال می‌شود، به بالا مراجعه کنید\&. در صورت تنظیم روی
"true"
(بر خلاف
"disconnected")،
این گزینه اثر جانبی افزودن وابستگی‌های
\fIRequires=\fR
و
\fIAfter=\fR
روی تمام واحدهای اتصال لازم برای دسترسی به
/tmp/
و
/var/tmp/
روی میزبان را دارد\&. علاوه بر این، یک ترتیب‌بندی ضمنی
\fIAfter=\fR
روی
\fBsystemd-tmpfiles-setup.service\fR(8)
اضافه می‌شود\&.
.sp
توجه داشته باشید که اجرای این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام اتصال در دسترس نباشند)، و واحد باید به‌گونه‌ای نوشته شود که فقط به این تنظیم برای امنیت تکیه نکند\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.RE
.PP
\fIPrivateDevices=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت true بودن، یک اتصال جدید
/dev/
برای فرآیندهای اجراشده راهاندازی میکند و فقط شبهدستگاههای API مانند
/dev/null،
/dev/zero
یا
/dev/random
(و همچنین زیرسیستم شبه TTY) را به آن اضافه میکند، اما هیچ دستگاه فیزیکی مانند
/dev/sda،
حافظه سیستم
/dev/mem،
پورتهای سیستم
/dev/port
و غیره را به آن اضافه نمیکند\&. این برای غیرفعال کردن دسترسی به دستگاههای فیزیکی توسط فرآیند اجراشده مفید است\&. پیشفرض false است\&.
.sp
فعال کردن این گزینه یک فیلتر فراخوانی سیستمی برای مسدود کردن فراخوانیهای سطح پایین I/O که در مجموعه
\fI@raw\-io\fR
گروهبندی شدهاند نصب میکند،
\fBCAP_MKNOD\fR
و
\fBCAP_SYS_RAWIO\fR
را از مجموعه محدودکننده قابلیت برای واحد حذف میکند و
\fIDevicePolicy=closed\fR
را تنظیم میکند (برای جزئیات به
\fBsystemd.resource-control\fR(5)
مراجعه کنید)\&. توجه داشته باشید که استفاده از این تنظیم، انتشار اتصالات از سرویس به میزبان را قطع میکند (انتشار در جهت مخالف همچنان کار میکند)\&. این بدان معناست که این تنظیم ممکن است برای سرویسهایی که باید بتوانند نقاط اتصال را در فضای نام اصلی اتصال نصب کنند، استفاده نشود\&. مسیر جدید
/dev/
به صورت فقطخواندنی و با پرچم \(aqnoexec\(aq متصل خواهد شد\&. مورد دوم ممکن است برنامههای قدیمی را که سعی میکنند با استفاده از
\fBmmap\fR(2)
روی
/dev/zero
به جای استفاده از
\fBMAP_ANON\fR
حافظه قابل اجرا راهاندازی کنند، با مشکل مواجه کند\&. برای این تنظیم همان محدودیتهای مربوط به انتشار اتصال و امتیازات مانند
\fIReadOnlyPaths=\fR
و فراخوانیهای مرتبط اعمال میشود، به بالا مراجعه کنید\&.
.sp
توجه داشته باشید که اجرای این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام اتصال در دسترس نباشند)، و واحد باید بهگونهای نوشته شود که فقط به این تنظیم برای امنیت تکیه نکند\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
هنگامی که دسترسی به برخی دستگاهها (و نه همه) باید امکانپذیر باشد، ممکن است به جای آن از تنظیم
\fIDeviceAllow=\fR
استفاده شود\&. به
\fBsystemd.resource-control\fR(5)
مراجعه کنید\&.
.sp
اضافهشده در نسخه 209\&.
.RE
.PP
\fIPrivateNetwork=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت true بودن، یک فضای نام شبکه جدید برای فرآیندهای اجراشده راهاندازی میکند و فقط دستگاه شبکه loopback یعنی
"lo"
را در داخل آن پیکربندی مینماید\&. هیچ دستگاه شبکه دیگری در دسترس فرآیند اجراشده نخواهد بود\&. این برای قطع دسترسی به شبکه توسط فرآیند اجراشده مفید است\&. پیشفرض false است\&. اجرای دو یا چند واحد در یک فضای نام شبکه خصوصی یکسان با استفاده از دستورالعمل
\fIJoinsNamespaceOf=\fR
امکانپذیر است؛ برای جزئیات به
\fBsystemd.unit\fR(5)
مراجعه کنید\&. توجه داشته باشید که این گزینه تمام خانوادههای سوکت را از میزبان جدا میکند، از جمله
\fBAF_NETLINK\fR
و
\fBAF_UNIX\fR\&.
در عمل، برای
\fBAF_NETLINK\fR
این بدان معناست که رویدادهای پیکربندی دستگاه دریافت شده از
\fBsystemd-udevd.service\fR(8)
به فرآیندهای واحد تحویل داده نمیشوند\&. و برای
\fBAF_UNIX\fR
این اثر را دارد که سوکتهای
\fBAF_UNIX\fR
در فضای نام سوکت انتزاعی میزبان برای فرآیندهای واحد غیرقابل دسترس خواهند شد (با این حال، سوکتهای واقع در سیستمفایل همچنان قابل دسترسی خواهند بود)\&.
.sp
توجه داشته باشید که پیادهسازی این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام شبکه در دسترس نباشند)، و واحد باید بهگونهای نوشته شود که فقط به این تنظیم برای امنیت متکی نباشد\&.
.sp
هنگامی که این گزینه فعال باشد،
\fIPrivateMounts=\fR
به صورت ضمنی فعال میشود مگر اینکه صریحاً غیرفعال شده باشد، و
/sys
مجدداً متصل میشود تا با فضای نام شبکه جدید مرتبط گردد\&.
.sp
هنگامی که این گزینه در یک واحد سوکت استفاده شود، هر سوکتی که از طرف این واحد متصل (bind) شود درون یک فضای نام شبکه خصوصی متصل خواهد شد\&. این ممکن است با
\fIJoinsNamespaceOf=\fR
ترکیب شود تا روی سوکتهای داخل فضاهای نام شبکه سایر سرویسها گوش فرا داده شود\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.RE
.PP
\fINetworkNamespacePath=\fR
.RS 4
یک مسیر مطلق سیستمفایل را میپذیرد که به یک شبهفایل فضای نام شبکه لینوکس اشاره دارد (یعنی فایلی مانند
/proc//ns/net
یا یک bind mount یا symlink به آن)\&. هنگام تنظیم، فرآیندهای فراخواندهشده به فضای نام شبکه ارجاعشده توسط آن مسیر اضافه میشوند\&. مسیر باید در لحظهای که فرآیندها fork میشوند به یک فایل فضای نام معتبر اشاره کند\&. اگر از این گزینه استفاده شود،
\fIPrivateNetwork=\fR
هیچ اثری ندارد\&. اگر این گزینه همراه با
\fIJoinsNamespaceOf=\fR
استفاده شود، تنها در صورتی اثر دارد که این واحد قبل از هر یک از واحدهای فهرستشدهای که
\fIPrivateNetwork=\fR
یا
\fINetworkNamespacePath=\fR
برای آنها پیکربندی شده است شروع شود، زیرا در غیر این صورت از فضای نام شبکه آن واحدها مجدداً استفاده میشود\&.
.sp
هنگامی که این گزینه فعال باشد،
\fIPrivateMounts=\fR
به صورت ضمنی فعال میشود مگر اینکه صریحاً غیرفعال شده باشد، و
/sys
مجدداً متصل میشود تا با فضای نام شبکه جدید مرتبط گردد\&.
.sp
هنگامی که این گزینه در یک واحد سوکت استفاده شود، هر سوکتی که از طرف این واحد bind شود، درون فضای نام شبکه مشخصشده متصل خواهد شد\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافهشده در نسخه 242\&.
.RE
.PP
\fIPrivateIPC=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت true بودن، یک فضای نام IPC جدید برای فرآیندهای اجراشده راهاندازی میکند\&. هر فضای نام IPC مجموعه شناسههای System V IPC و سیستمفایل صف پیام POSIX اختصاصی خود را دارد\&. این برای جلوگیری از تداخل نام شناسههای IPC مفید است\&. پیشفرض false است\&. اجرای دو یا چند واحد در یک فضای نام خصوصی IPC مشترک با استفاده از دستورالعمل
\fIJoinsNamespaceOf=\fR
امکانپذیر است؛ برای جزئیات به
\fBsystemd.unit\fR(5)
مراجعه کنید\&.
.sp
توجه داشته باشید که فضاسازی نام IPC بر سوکتهای
\fBAF_UNIX\fR
که رایجترین شکل IPC در لینوکس هستند، تأثیری ندارد\&. در عوض، سوکتهای
\fBAF_UNIX\fR
در سیستمفایل مشمول فضاسازی نام اتصال، و سوکتهای موجود در فضای نام انتزاعی مشمول فضاسازی نام شبکه هستند\&. فضاسازی نام IPC فقط بر System V IPC (که عمدتاً قدیمی و موروثی است) و همچنین صفهای پیام POSIX (که سوکتهای
\fBAF_UNIX\fR/\fBSOCK_SEQPACKET\fR
معمولاً جایگزین بهتری برای آنها هستند) اثر دارد\&. فضاسازی نام IPC همچنین بر حافظه اشتراکی POSIX (که مشمول فضاسازی نام اتصال است) نیز تأثیری ندارد\&. برای جزئیات به
\fBipc_namespaces\fR(7)
مراجعه کنید\&.
.sp
توجه داشته باشید که پیادهسازی این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام IPC در دسترس نباشند)، و واحد باید بهگونهای نوشته شود که فقط به این تنظیم برای امنیت متکی نباشد\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافهشده در نسخه 248\&.
.RE
.PP
\fIIPCNamespacePath=\fR
.RS 4
یک مسیر مطلق سیستمفایل را میپذیرد که به یک شبهفایل فضای نام IPC لینوکس اشاره دارد (یعنی فایلی مانند
/proc//ns/ipc
یا یک bind mount یا symlink به آن)\&. هنگام تنظیم، فرآیندهای فراخواندهشده به فضای نام ارجاعشده توسط آن مسیر اضافه میشوند\&. مسیر باید در لحظهای که فرآیندها fork میشوند به یک فایل فضای نام معتبر اشاره کند\&. اگر از این گزینه استفاده شود،
\fIPrivateIPC=\fR
هیچ اثری ندارد\&. اگر این گزینه همراه با
\fIJoinsNamespaceOf=\fR
استفاده شود، تنها در صورتی اثر دارد که این واحد قبل از هر یک از واحدهای فهرستشدهای که
\fIPrivateIPC=\fR
یا
\fIIPCNamespacePath=\fR
برای آنها پیکربندی شده است شروع شود، زیرا در غیر این صورت از فضای نام شبکه آن واحدها مجدداً استفاده میشود\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافهشده در نسخه 248\&.
.RE
.PP
\fIMemoryKSM=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. هنگامی که تنظیم شود، قابلیت KSM (ادغام صفحات یکسان هسته یا Kernel Samepage Merging) را برای فرآیندها فعال میکند\&. قابلیت KSM یک ویژگی حذف تکرار دادهها برای صرفهجویی در حافظه است\&. صفحات حافظه ناشناس با محتوای یکسان میتوانند با یک صفحه منفرد محافظتشده در برابر نوشتن جایگزین شوند\&. این ویژگی فقط باید برای کارهایی فعال شود که دامنه امنیتی یکسانی را به اشتراک میگذارند\&. برای جزئیات به
\m[blue]\fBKernel Samepage Merging\fR\m[]\&\s-2\u[8]\d\s+2
در مستندات هسته مراجعه کنید\&.
.sp
توجه داشته باشید که این عملکرد ممکن است در دسترس نباشد، برای مثال اگر KSM در هسته غیرفعال باشد، یا هسته از کنترل KSM در سطح فرآیند از طریق
\fBprctl\fR(2)
پشتیبانی نکند\&.
.sp
اضافهشده در نسخه 254\&.
.RE
.PP
\fIPrivatePIDs=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. پیشفرض false است\&. در صورت فعال بودن، یک فضای نام PID جدید برای فرآیندهای اجراشده راهاندازی میکند\&. هر فرآیند اجراشده اکنون PID 1 \(em فرآیند init \(em در فضای نام جدید خواهد بود\&.
/proc/
بهگونهای متصل میشود که فقط فرآیندهای موجود در فضای نام PID قابل مشاهده باشند\&. اگر
\fIPrivatePIDs=\fR
تنظیم شود،
\fIMountAPIVFS=yes\fR
به صورت ضمنی اعمال میشود\&.
.sp
گزینه
\fIPrivatePIDs=\fR
فقط برای واحدهای سرویس پشتیبانی میشود\&. این تنظیم با
\fIType=forking\fR
پشتیبانی نمیشود زیرا در صورت پایان یافتن فرآیند init، هسته تمام فرآیندهای موجود در فضای نام PID را از بین خواهد برد\&.
.sp
اگر هسته از فضاهای نام PID پشتیبانی نکند، این تنظیم نادیده گرفته خواهد شد\&.
.sp
توجه داشته باشید که سرویسهای کاربری بدون امتیاز (یعنی سرویسی که توسط نمونه کاربر-محور مدیر سرویس اجرا میشود) در صورتی که
/proc/
پوشش داده شده باشد (یعنی
/proc/kmsg
با
\fBtmpfs\fR
پوشانده شده باشد همانطور که
\fBsystemd-nspawn\fR(1)
انجام میدهد) با
\fIPrivatePIDs=yes\fR
شکست خواهند خورد\&. این به دلیل محدودیت هسته است که به فضاهای نام کاربری بدون امتیاز اجازه نمیدهد نمونهای با محدودیت کمتر از
/proc/
را متصل کنند\&.
.sp
اضافهشده در نسخه 257\&.
.RE
.PP
\fIPrivateUsers=\fR
.RS 4
یک آرگومان بولی یا یکی از مقادیر
"self"
یا
"identity"
را میپذیرد\&. پیشفرض false است\&. در صورت فعال بودن، یک فضای نام کاربری جدید برای فرآیندهای اجراشده راهاندازی کرده و یک نگاشت کاربر و گروه را پیکربندی میکند\&. اگر روی یک مقدار بولی درست یا
"self"
تنظیم شود، یک نگاشت کمینه کاربر و گروه پیکربندی میشود که کاربر و گروه
"root"
و همچنین کاربر و گروه خود واحد را به خودشان و بقیه موارد را به کاربر و گروه
"nobody"
نگاشت میکند\&. این برای جدا کردن ایمن پایگاههای داده کاربر و گروه مورد استفاده واحد از بقیه سیستم و در نتیجه ایجاد یک محیط ایزوله مؤثر مفید است\&. تمام فایلها، دایرکتوریها، فرآیندها، اشیاء IPC و سایر منابع متعلق به کاربران/گروههایی غیر از
"root"
یا کاربر/گروه خود واحد از درون واحد قابل مشاهده خواهند بود اما به عنوان متعلق به کاربر و گروه
"nobody"
ظاهر میشوند\&.
.sp
اگر پارامتر
"identity"
باشد، فضاسازی نام کاربر با یک نگاشت همانی برای اولین 65536 شناسه UID/GID راهاندازی میشود\&. هر UID/GID بالاتر از 65536 به ترتیب به کاربر و گروه
"nobody"
نگاشت خواهد شد\&. در حالی که این حالت جداسازی UID/GID را ارائه نمیدهد، زیرا همه UID/GIDها به صورت یکسان انتخاب شدهاند، جداسازی قابلیتهای فرآیند را فراهم میکند و از این رو اغلب اگر فضاسازی نام کاربری مناسب با نقشههای UID متمایز مناسب نباشد، یک انتخاب خوب است\&.
.sp
اگر این حالت فعال باشد، تمام فرآیندهای واحد بدون امتیاز در فضای نام کاربری میزبان اجرا میشوند (صرفنظر از اینکه کاربر/گروه خود واحد
"root"
باشد یا خیر)\&. به طور خاص این بدان معناست که فرآیند دارای صفر قابلیت فرآیند در فضای نام کاربری میزبان خواهد بود، اما قابلیتهای کامل را در فضای نام کاربری سرویس خواهد داشت\&. تنظیماتی مانند
\fICapabilityBoundingSet=\fR
فقط بر دومی تأثیر میگذارد، و هیچ راهی برای به دست آوردن قابلیتهای اضافی در فضای نام کاربری میزبان وجود ندارد\&.
.sp
هنگامی که این تنظیم توسط یک نمونه کاربر-محور مدیر سرویس راهاندازی میشود، نگاشت کاربر و گروه
"root"
به خودش حذف میشود (مگر اینکه مدیر کاربر root باشد)\&. علاوه بر این، در حالت مدیر نمونه کاربر-محور، فضای نام کاربر قبل از بیشتر فضاهای نام دیگر راهاندازی میشود\&. این بدان معناست که ترکیب
\fIPrivateUsers=\fR\fBtrue\fR
با سایر فضاهای نام، امکان استفاده از ویژگیهایی را که معمولاً توسط نمونههای کاربر-محور مدیر سرویس پشتیبانی نمیشوند فراهم میکند\&.
.sp
این تنظیم بهویژه در ترکیب با
\fIRootDirectory=\fR/\fIRootImage=\fR
مفید است، زیرا نیاز به همگامسازی پایگاههای داده کاربر و گروه در دایرکتوری ریشه و روی میزبان را کاهش میدهد، زیرا تنها کاربران و گروههایی که باید مطابقت داشته باشند
"root"،
"nobody"
و کاربر و گروه خود واحد هستند\&.
.sp
توجه داشته باشید که اجرای این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام کاربری در دسترس نباشند)، و واحد باید بهگونهای نوشته شود که فقط به این تنظیم برای امنیت تکیه نکند\&.
.sp
اضافهشده در نسخه 232\&.
.RE
.PP
\fIProtectHostname=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. هنگام تنظیم، یک فضای نام UTS جدید برای فرآیندهای اجراشده راهاندازی میکند\&. علاوه بر این، از تغییر نام میزبان یا نام دامنه جلوگیری میشود\&. پیشفرض خاموش است\&.
.sp
توجه داشته باشید که اجرای این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام UTS در دسترس نباشند)، و واحد باید بهگونهای نوشته شود که فقط به این تنظیم برای امنیت متکی نباشد\&.
.sp
توجه داشته باشید که هنگامی که این گزینه برای یک سرویس فعال است، تغییرات نام میزبان دیگر از سیستم به سرویس منتشر نمیشود، بنابراین برای سرویسهایی که باید تغییرات نام میزبان سیستم را به صورت پویا متوجه شوند مناسب نیست\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافهشده در نسخه 242\&.
.RE
.PP
\fIProtectClock=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت تنظیم، نوشتن در ساعت سختافزاری یا ساعت سیستم رد خواهد شد\&. پیشفرض خاموش است\&. فعال کردن این گزینه
\fBCAP_SYS_TIME\fR
و
\fBCAP_WAKE_ALARM\fR
را از مجموعه محدودکننده قابلیت برای این واحد حذف میکند، یک فیلتر فراخوانی سیستمی برای مسدود کردن فراخوانیهایی که میتوانند ساعت را تنظیم کنند نصب مینماید و
\fIDeviceAllow=char\-rtc r\fR
به صورت ضمنی اعمال میشود\&. توجه داشته باشید که فراخوانیهای سیستمی به طور کامل مسدود میشوند و فیلتر این موضوع را در نظر نمیگیرد که برخی از فراخوانیها میتوانند برای خواندن وضعیت ساعت با برخی ترکیبات پارامتر استفاده شوند\&. در عمل،
/dev/rtc0،
/dev/rtc1
و غیره برای سرویس فقطخواندنی میشوند\&. برای جزئیات درباره
\fIDeviceAllow=\fR
به
\fBsystemd.resource-control\fR(5)
مراجعه کنید\&.
.sp
توصیه میشود این گزینه برای اکثر سرویسهایی که نیازی به تغییر ساعت یا بررسی وضعیت آن ندارند روشن شود\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافهشده در نسخه 245\&.
.RE
.PP
\fIProtectKernelTunables=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت true بودن، متغیرهای هسته قابل دسترسی از طریق
/proc/sys/،
/sys/،
/proc/sysrq\-trigger،
/proc/latency_stats،
/proc/acpi،
/proc/timer_stats،
/proc/fs
و
/proc/irq
فقطخواندنی خواهند شد و
/proc/kallsyms
و همچنین
/proc/kcore
برای تمام فرآیندهای واحد غیرقابل دسترس خواهند بود\&. معمولاً متغیرهای قابل تنظیم هسته باید فقط در زمان بوت مقداردهی اولیه شوند، برای مثال با سازوکار
\fBsysctl.d\fR(5)\&.
تعداد کمی از سرویسها نیاز به نوشتن در این موارد در زمان اجرا دارند؛ از این رو توصیه میشود این گزینه برای بیشتر سرویسها روشن شود\&. برای این تنظیم، همان محدودیتهای مربوط به انتشار اتصال و امتیازات مانند
\fIReadOnlyPaths=\fR
و فراخوانیهای مرتبط اعمال میشود، به بالا مراجعه کنید\&. پیشفرض خاموش است\&. توجه داشته باشید که این گزینه از تغییرات غیرمستقیم در پارامترهای تنظیمی هسته که تحت تأثیر فراخوانیهای IPC به فرآیندهای دیگر ایجاد میشوند جلوگیری نمیکند\&. با این حال،
\fIInaccessiblePaths=\fR
ممکن است برای غیرقابل دسترس کردن اشیاء سیستمفایل IPC مربوطه استفاده شود\&. اگر
\fIProtectKernelTunables=\fR
تنظیم شود،
\fIMountAPIVFS=yes\fR
به صورت ضمنی اعمال خواهد شد\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافهشده در نسخه 232\&.
.RE
.PP
\fIProtectKernelModules=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت true بودن، بارگذاری صریح ماژول ممنوع خواهد شد\&. این امر امکان غیرفعال کردن عملیات بارگذاری و تخلیه ماژول را در هستههای ماژولار فراهم میکند\&. توصیه میشود این گزینه برای اکثر سرویسهایی که برای کار کردن به سیستمهای فایل خاص یا ماژولهای اضافی هسته نیاز ندارند روشن شود\&. پیشفرض خاموش است\&. فعال کردن این گزینه
\fBCAP_SYS_MODULE\fR
را از مجموعه محدودکننده قابلیت برای واحد حذف میکند و یک فیلتر فراخوانی سیستمی برای مسدود کردن فراخوانیهای سیستمی ماژول نصب مینماید، همچنین
/usr/lib/modules
غیرقابل دسترس میشود\&. برای این تنظیم، همان محدودیتهای مربوط به انتشار اتصال و امتیازات مانند
\fIReadOnlyPaths=\fR
و فراخوانیهای مرتبط اعمال میشود، به بالا مراجعه کنید\&. توجه داشته باشید که بارگذاری خودکار محدود ماژول به دلیل پیکربندی کاربر یا جداول نگاشت هسته ممکن است همچنان به عنوان اثر جانبی عملیات درخواستی کاربر، چه دارای امتیاز و چه بدون امتیاز، اتفاق بیفتد\&. برای غیرفعال کردن ویژگی بارگذاری خودکار ماژول، لطفاً سازوکار
\fBkernel\&.modules_disabled\fR
در
\fBsysctl.d\fR(5)
و مستندات
/proc/sys/kernel/modules_disabled
را ببینید\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافهشده در نسخه 232\&.
.RE
.PP
\fIProtectKernelLogs=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت true بودن، دسترسی به بافر حلقهای لاگ هسته (kernel log ring buffer) رد خواهد شد\&. توصیه میشود این گزینه برای اکثر سرویسهایی که نیازی به خواندن یا نوشتن در بافر لاگ هسته ندارند روشن شود\&. فعال کردن این گزینه
\fBCAP_SYSLOG\fR
را از مجموعه محدودکننده قابلیت برای این واحد حذف میکند و یک فیلتر فراخوانی سیستمی برای مسدود کردن فراخوانی سیستمی
\fBsyslog\fR(2)
(که نباید با API کتابخانه C یعنی
\fBsyslog\fR(3)
برای ثبت وقایع فضای کاربری اشتباه گرفته شود) نصب مینماید\&. هسته بافر لاگ خود را از طریق
/dev/kmsg
و
/proc/kmsg
در دسترس فضای کاربری قرار میدهد\&. در صورت فعال بودن، این موارد برای تمام فرآیندهای موجود در واحد غیرقابل دسترس میشوند\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافهشده در نسخه 244\&.
.RE
.PP
\fIProtectControlGroups=\fR
.RS 4
یک آرگومان بولی یا مقادیر ویژه
"private"
یا
"strict"
را میپذیرد\&. در صورت true بودن، سلسلهمراتبهای گروههای کنترلی لینوکس (\fBcgroups\fR(7)) قابل دسترسی از طریق
/sys/fs/cgroup/
برای تمام فرآیندهای واحد فقطخواندنی خواهند شد\&. اگر روی
"private"
تنظیم شود، واحد در یک فضای نام cgroup با یک اتصال قابل نوشتن خصوصی از
/sys/fs/cgroup/
اجرا خواهد شد\&. اگر روی
"strict"
تنظیم شود، واحد در یک فضای نام cgroup با یک اتصال فقطخواندنی خصوصی از
/sys/fs/cgroup/
اجرا خواهد شد\&. پیشفرض خاموش است\&. اگر
\fIProtectControlGroups=\fR
تنظیم شود،
\fIMountAPIVFS=yes\fR
به صورت ضمنی اعمال میشود\&. توجه داشته باشید که
"private"
و
"strict"
به ترتیب به false و true تنزل مییابند مگر اینکه سیستم از سلسلهمراتب گروه کنترلی یکپارچه استفاده کند و هسته از فضاهای نام cgroup پشتیبانی نماید\&.
.sp
به جز مدیران کانتینر، هیچ سرویسی نباید به دسترسی نوشتن به سلسلهمراتبهای گروههای کنترلی نیاز داشته باشد؛ از این رو توصیه میشود برای اکثر سرویسها
\fIProtectControlGroups=\fR
روی true یا
"strict"
تنظیم شود\&. برای این تنظیم، همان محدودیتهای مربوط به انتشار اتصالات و امتیازات مانند
\fIReadOnlyPaths=\fR
و تنظیمات مرتبط اعمال میشود، به بالا مراجعه کنید\&.
.sp
این گزینه فقط برای سرویسهای سیستمی در دسترس است و برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند پشتیبانی نمیشود\&.
.sp
اضافهشده در نسخه 232\&.
.RE
.PP
\fIRestrictAddressFamilies=\fR
.RS 4
مجموعه خانوادههای آدرس سوکت قابل دسترسی برای فرآیندهای این واحد را محدود میکند\&. مقدار
"none"،
یا فهرستی جداشده با فاصله از نامهای خانواده آدرس را برای قرار دادن در فهرست مجاز میپذیرد، مانند
\fBAF_UNIX\fR،
\fBAF_INET\fR
یا
\fBAF_INET6\fR\&.
هنگامی که
"none"
مشخص شود، تمام خانوادههای آدرس رد خواهند شد\&. هنگامی که با
"~"
پیشوندگذاری شود، خانوادههای آدرس فهرستشده به عنوان فهرست مسدود اعمال میشوند، در غیر این صورت به عنوان فهرست مجاز عمل خواهند کرد\&.
.sp
به طور پیشفرض، هیچ محدودیتی اعمال نمیشود و تمام خانوادههای آدرس برای فرآیندها قابل دسترسی هستند\&. اگر رشته خالی اختصاص داده شود، هرگونه تغییر قبلی در محدودیت خانواده آدرس لغو میشود\&. این تنظیم بر دستورات دارای پیشوند
"+"
تأثیری ندارد\&.
.sp
از این گزینه برای محدود کردن قرار گرفتن فرآیندها در معرض دسترسی از راه دور، به ویژه از طریق پروتکلهای شبکه غیرمتعارف و حساس مانند
\fBAF_PACKET\fR
استفاده کنید\&. توجه داشته باشید که در بیشتر موارد، خانواده آدرس محلی
\fBAF_UNIX\fR
باید در فهرست مجاز پیکربندیشده گنجانده شود زیرا مکرراً برای ارتباطات محلی، از جمله برای ثبت لاگ
\fBsyslog\fR(2)
استفاده میشود\&.
.sp
توجه داشته باشید که این گزینه فقط دسترسی به فراخوانی سیستمی
\fBsocket\fR(2)
را محدود میکند\&. سوکتهایی که به روشهای دیگر به فرآیند منتقل میشوند (مثلاً با استفاده از فعالسازی سوکت با واحدهای سوکت، به
\fBsystemd.socket\fR(5)
مراجعه کنید) تحت تأثیر قرار نمیگیرند\&. همچنین سوکتهای ایجادشده با
\fBsocketpair()\fR
(که سوکتهای متصل AF_UNIX ایجاد میکند) یا توابع
\fBio_uring\fR(7)
تحت تأثیر قرار نمیگیرند\&. بنابراین توصیه میشود این تنظیم را با
\fISystemCallFilter=@service\fR
ترکیب کنید تا فقط به زیرمجموعه محدودی از فراخوانیهای سیستمی اجازه داده شود\&.
.sp
توجه داشته باشید که این گزینه محدود به برخی ABIها، به ویژه x86\-64 است، اما در حال حاضر روی معماریهای 32 بیتی x86، s390، s390x، mips، mips\-le، ppc، ppc\-le، ppc64 یا ppc64\-le هیچ اثری ندارد و نادیده گرفته میشود\&. در سیستمهایی که از چندین ABI پشتیبانی میکنند (مانند x86/x86\-64) توصیه میشود ABIهای جایگزین را برای سرویسها غیرفعال کنید تا نتوان از آنها برای دور زدن محدودیتهای این گزینه استفاده کرد\&. به طور خاص، توصیه میشود این گزینه را با
\fISystemCallArchitectures=native\fR
یا مشابه آن ترکیب نمایید\&.
.sp
اضافهشده در نسخه 211\&.
.RE
.PP
\fIRestrictFileSystems=\fR
.RS 4
مجموعه سیستمهای فایلی را که فرآیندهای این واحد میتوانند فایلها را روی آنها باز کنند محدود میکند\&. فهرستی جداشده با فاصله از نامهای سیستمفایل را میپذیرد\&. هر سیستمفایل فهرستشده برای فرآیندهای واحد قابل دسترسی میشود و دسترسی به انواع سیستمفایل فهرستنشده ممنوع میگردد (فهرست مجاز)\&. اگر اولین نویسه فهرست
"~"
باشد، اثر معکوس میشود: دسترسی به سیستمهای فایل فهرستشده ممنوع میگردد (فهرست مسدود)\&. اگر رشته خالی اختصاص یابد، دسترسی به سیستمهای فایل محدود نمیشود\&.
.sp
اگر هر دو نوع این گزینه را مشخص کنید (یعنی فهرست مجاز و فهرست مسدود)، اولین موردی که با آن مواجه میشوید اولویت خواهد داشت و اقدام پیشفرض را دیکته میکند (اجازه دسترسی به سیستمفایل یا رد آن)\&. سپس رخدادهای بعدی این گزینه بسته به نوع آن و اقدام پیشفرض، سیستمهای فایل فهرستشده را از مجموعه سیستمهای فایل محدودشده اضافه یا حذف میکنند\&.
.sp
مثال: اگر یک واحد دارای موارد زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
RestrictFileSystems=ext4 tmpfs
RestrictFileSystems=ext2 ext4
.fi
.if n \{\
.RE
.\}
.sp
آنگاه دسترسی به
\fBext4\fR،
\fBtmpfs\fR
و
\fBext2\fR
مجاز است و دسترسی به سایر سیستمهای فایل رد میشود\&.
.sp
مثال: اگر یک واحد دارای موارد زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
RestrictFileSystems=ext4 tmpfs
RestrictFileSystems=~ext4
.fi
.if n \{\
.RE
.\}
.sp
آنگاه فقط دسترسی به
\fBtmpfs\fR
مجاز است\&.
.sp
مثال: اگر یک واحد دارای موارد زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
RestrictFileSystems=~ext4 tmpfs
RestrictFileSystems=ext4
.fi
.if n \{\
.RE
.\}
.sp
آنگاه فقط دسترسی به
\fBtmpfs\fR
رد میشود\&.
.sp
از آنجا که تعداد سیستمهای فایل ممکن زیاد است، مجموعههای از پیش تعریفشدهای از سیستمهای فایل ارائه شدهاند\&. یک مجموعه با نویسه
"@"
شروع میشود که نام مجموعه به دنبال آن میآید\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B جدول\& 3.\& مجموعههای سیستمفایل از پیش تعریفشده کنونی
.TS
allbox tab(:);
lB lB.
T{
مجموعه
T}:T{
توضیحات
T}
.T&
l l
l l
l l
l l
l l
l l
l l
l l.
T{
@basic\-api
T}:T{
API پایه سیستمفایل\&.
T}
T{
@auxiliary\-api
T}:T{
API کمکی سیستمفایل\&.
T}
T{
@common\-block
T}:T{
سیستمهای فایل رایج دستگاه بلوکی\&.
T}
T{
@historical\-block
T}:T{
سیستمهای فایل تاریخی دستگاه بلوکی\&.
T}
T{
@network
T}:T{
سیستمهای فایل شبکهای شناختهشده\&.
T}
T{
@privileged\-api
T}:T{
API با امتیاز سیستمفایل\&.
T}
T{
@temporary
T}:T{
سیستمهای فایل موقت: tmpfs, ramfs\&.
T}
T{
@known
T}:T{
تمام سیستمهای فایل شناختهشده تعریفشده توسط هسته\&. این فهرست به صورت ایستا در systemd بر اساس نسخه هستهای که هنگام انتشار این نسخه systemd در دسترس بود تعریف شده است\&. با بهروزرسانی هسته، این فهرست به تدریج قدیمیتر خواهد شد\&.
T}
.TE
.sp 1
از دستور
\fBfilesystems\fR
در
\fBsystemd-analyze\fR(1)
برای بازیابی فهرستی از سیستمهای فایل تعریفشده در سیستم محلی استفاده کنید\&.
.sp
توجه داشته باشید که این تنظیم ممکن است در برخی سیستمها پشتیبانی نشود (مثلاً اگر قلاب LSM eBPF در هسته زیربنایی فعال نباشد یا اگر از سلسلهمراتب گروه کنترلی یکپارچه استفاده نشود)\&. در این حالت این تنظیم هیچ اثری ندارد\&.
.sp
این گزینه را نمیتوان با پیشوندگذاری
"+"
به مسیر اجرایی در واحد سرویس دور زد، زیرا برای کل گروه کنترلی اعمال میشود\&.
.sp
اضافهشده در نسخه 250\&.
.RE
.PP
\fIRestrictNamespaces=\fR
.RS 4
دسترسی به عملکرد فضای نام لینوکس را برای فرآیندهای این واحد محدود میکند\&. برای جزئیات بیشتر درباره فضاهای نام لینوکس به
\fBnamespaces\fR(7)
مراجعه کنید\&. یا یک آرگومان بولی یا فهرستی جداشده با فاصله از شناسههای نوع فضای نام را میپذیرد\&. اگر false باشد (پیشفرض)، هیچ محدودیتی در ایجاد و تغییر فضای نام اعمال نمیشود\&. اگر true باشد، دسترسی به هر نوع فضاسازی نام ممنوع است\&. در غیر این صورت، باید فهرستی جداشده با فاصله از شناسههای نوع فضای نام مشخص شود که شامل هر ترکیبی از موارد زیر باشد:
\fBcgroup\fR،
\fBipc\fR،
\fBnet\fR،
\fBmnt\fR،
\fBpid\fR،
\fBuser\fR
و
\fButs\fR\&.
هر نوع فضای نام فهرستشده برای فرآیندهای واحد قابل دسترسی میشود و دسترسی به انواع فضای نام فهرستنشده ممنوع است (فهرست مجاز)\&. با افزودن یک نویسه مدک منفرد ("~") به ابتدای فهرست، اثر ممکن است معکوس شود: فقط انواع فضای نام فهرستشده غیرقابل دسترسی خواهند شد و تمام موارد فهرستنشده مجاز خواهند بود (فهرست مسدود)\&. اگر رشته خالی اختصاص داده شود، محدودیتهای پیشفرض فضای نام اعمال میشوند که معادل false است\&. این گزینه ممکن است بیش از یک بار ظاهر شود، که در این صورت انواع فضای نام با
\fBOR\fR
(یا در صورتی که سطرها با پیشوند
"~"
همراه باشند با
\fBAND\fR)
ادغام میشوند (به مثالهای زیر مراجعه کنید)\&. در درون برنامه، این تنظیم دسترسی به فراخوانیهای سیستمی
\fBunshare\fR(2)،
\fBclone\fR(2)
و
\fBsetns\fR(2)
را با در نظر گرفتن پارامترهای پرچم مشخصشده محدود میکند\&. توجه داشته باشید که \(em در صورت استفاده از این گزینه \(em علاوه بر محدود کردن ایجاد و تغییر انواع مشخصشده فضاهای نام (یا همه آنها در صورت true بودن)، دسترسی به فراخوانی سیستمی
\fBsetns()\fR
با پارامتر پرچم صفر ممنوع است\&. این تنظیم فقط روی x86، x86\-64، mips، mips\-le، mips64، mips64\-le، mips64\-n32، mips64\-le\-n32، ppc64، ppc64\-le، s390 و s390x پشتیبانی میشود و هیچ محدودیتی را روی معماریهای دیگر اعمال نمیکند\&.
.sp
مثال: اگر یک واحد دارای موارد زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
RestrictNamespaces=cgroup ipc
RestrictNamespaces=cgroup net
.fi
.if n \{\
.RE
.\}
.sp
آنگاه
\fBcgroup\fR،
\fBipc\fR
و
\fBnet\fR
تنظیم میشوند\&. اگر سطر دوم دارای پیشوند
"~"
باشد، به عنوان مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
RestrictNamespaces=cgroup ipc
RestrictNamespaces=~cgroup net
.fi
.if n \{\
.RE
.\}
.sp
آنگاه تنها
\fBipc\fR
تنظیم میشود\&.
.sp
اضافهشده در نسخه 233\&.
.RE
.PP
\fILockPersonality=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت تنظیم، فراخوانی سیستمی
\fBpersonality\fR(2)
را قفل میکند بهگونهای که دامنه اجرای هسته ممکن است از حالت پیشفرض یا personality انتخابشده با دستورالعمل
\fIPersonality=\fR
تغییر نیابد\&. این ممکن است برای بهبود امنیت مفید باشد، زیرا شبیهسازیهای متفرقه personality ممکن است به اندازه کافی آزمایش نشده باشند و منبع آسیبپذیری باشند\&.
.sp
اضافهشده در نسخه 235\&.
.RE
.PP
\fIMemoryDenyWriteExecute=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت تنظیم، تلاش برای ایجاد نگاشتهای حافظهای که همزمان قابل نوشتن و قابل اجرا هستند، یا تغییر نگاشتهای حافظه موجود برای تبدیل شدن به قابل اجرا، یا نگاشت بخشهای حافظه مشترک به عنوان قابل اجرا ممنوع است\&. به طور خاص، یک فیلتر فراخوانی سیستمی اضافه میشود (یا ترجیحاً یک بررسی معادل هسته با
\fBprctl\fR(2)
فعال میشود) که فراخوانیهای سیستمی
\fBmmap\fR(2)
را که هر دو پرچم
\fBPROT_EXEC\fR
و
\fBPROT_WRITE\fR
را دارند، فراخوانیهای سیستمی
\fBmprotect\fR(2)
یا
\fBpkey_mprotect\fR(2)
با پرچم
\fBPROT_EXEC\fR
و فراخوانیهای سیستمی
\fBshmat\fR(2)
با پرچم
\fBSHM_EXEC\fR
را رد میکند\&. توجه داشته باشید که این گزینه با برنامهها و کتابخانههایی که کد برنامه را به صورت پویا در زمان اجرا تولید میکنند، از جمله موتورهای اجرای JIT، پشتههای قابل اجرا، و ویژگی کد "trampoline" در کامپایلرهای مختلف C ناسازگار است\&. این گزینه امنیت سرویس را بهبود میبخشد، زیرا تغییر پویای کد در حال اجرا را برای اکسپلویتهای نرمافزاری دشوارتر میسازد\&. با این حال، اگر سرویس بتواند در یک سیستمفایلی بنویسد که با
\fBnoexec\fR
متصل نشده است (مانند
/dev/shm)،
یا بتواند از
\fBmemfd_create()\fR
استفاده کند، این حفاظت قابل دور زدن است\&. این امر را میتوان با غیرقابل دسترسی کردن چنین سیستمهای فایلی برای سرویس (مثلاً
\fIInaccessiblePaths=/dev/shm\fR)
و نصب فیلترهای فراخوانی سیستمی بیشتر (\fISystemCallFilter=~memfd_create\fR)
جلوگیری کرد\&. توجه داشته باشید که این ویژگی به طور کامل در x86\-64 و تا حدی در x86 در دسترس است\&. به طور خاص، حفاظت
\fBshmat()\fR
در x86 در دسترس نیست\&. توجه داشته باشید که در سیستمهایی که از چندین ABI پشتیبانی میکنند (مانند x86/x86\-64) توصیه میشود ABIهای جایگزین را برای سرویسها غیرفعال کنید تا نتوان از آنها برای دور زدن محدودیتهای این گزینه استفاده کرد\&. به طور خاص، توصیه میشود این گزینه را با
\fISystemCallArchitectures=native\fR
یا مشابه آن ترکیب نمایید\&.
.sp
اضافهشده در نسخه 231\&.
.RE
.PP
\fIRestrictRealtime=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت تنظیم، هرگونه تلاش برای فعال کردن زمانبندی بیدرنگ (realtime) در یک فرآیند واحد رد میشود\&. این گزینه دسترسی به خطمشیهای زمانبندی وظایف بیدرنگ مانند
\fBSCHED_FIFO\fR،
\fBSCHED_RR\fR
یا
\fBSCHED_DEADLINE\fR
را محدود میکند\&. برای جزئیات در مورد این خطمشیهای زمانبندی به
\fBsched\fR(7)
مراجعه کنید\&. خطمشیهای زمانبندی بیدرنگ ممکن است برای انحصار زمان CPU برای دورههای طولانیتر استفاده شوند، و از این رو ممکن است برای قفل کردن یا ایجاد شرایط منع سرویس (Denial\-of\-Service) روی سیستم استفاده شوند\&. از این رو توصیه میشود دسترسی به زمانبندی بیدرنگ به برنامههای اندکی که واقعاً به آنها نیاز دارند محدود شود\&. پیشفرض خاموش است\&.
.sp
اضافهشده در نسخه 231\&.
.RE
.PP
\fIRestrictSUIDSGID=\fR
.RS 4
یک آرگومان بولی میپذیرد\&. در صورت تنظیم، هرگونه تلاش برای تنظیم بیتهای set\-user\-ID (SUID) یا set\-group\-ID (SGID) روی فایلها یا دایرکتوریها رد خواهد شد (برای جزئیات در مورد این بیتها به
\fBinode\fR(7)
مراجعه کنید)\&. از آنجا که بیتهای SUID/SGID سازوکارهایی برای ارتقای امتیازات هستند و به کاربران اجازه میدهند هویت سایر کاربران را کسب کنند، توصیه میشود ایجاد فایلهای SUID/SGID به برنامههای اندکی که واقعاً به آنها نیاز دارند محدود شود\&. توجه داشته باشید که این گزینه علامتگذاری هر نوع شیء سیستمفایل را با این بیتها، شامل هر دو فایلهای معمولی و دایرکتوریها (که در آنها SGID معنایی متفاوت از فایلها دارد، مستندات را ببینید) محدود میکند\&. این گزینه در صورت فعال بودن
\fIDynamicUser=\fR
به صورت ضمنی اعمال میشود\&. پیشفرض خاموش است\&.
.sp
اضافهشده در نسخه 242\&.
.RE
.PP
\fIRemoveIPC=\fR
.RS 4
یک پارامتر بولی میپذیرد\&. در صورت تنظیم، تمام اشیاء System V و POSIX IPC متعلق به کاربر و گروهی که فرآیندهای این واحد تحت آن اجرا میشوند هنگام توقف واحد حذف خواهند شد\&. این تنظیم فقط در صورتی اثر دارد که حداقل یکی از گزینههای
\fIUser=\fR،
\fIGroup=\fR
و
\fIDynamicUser=\fR
استفاده شده باشد\&. بر اشیاء IPC متعلق به کاربر root هیچ اثری ندارد\&. به طور خاص، این گزینه سمافورهای System V، و همچنین بخشهای حافظه اشتراکی و صفهای پیام System V و POSIX را حذف میکند\&. اگر چندین واحد از یک کاربر یا گروه یکسان استفاده کنند، اشیاء IPC هنگامی که آخرین واحد از این واحدها متوقف شود حذف میشوند\&. این تنظیم در صورت تنظیم
\fIDynamicUser=\fR
به صورت ضمنی اعمال میگردد\&.
.sp
این گزینه فقط برای سرویسهای سیستمی در دسترس است و برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند پشتیبانی نمیشود\&.
.sp
اضافهشده در نسخه 232\&.
.RE
.PP
\fIPrivateMounts=\fR
.RS 4
یک پارامتر بولی میپذیرد\&. در صورت تنظیم، فرآیندهای این واحد در فضای نام سیستمفایل (اتصال) خصوصی خود اجرا خواهند شد و تمام انتشار اتصالات از فرآیندها به سمت فضای نام سیستمفایل اصلی میزبان خاموش میشود\&. این بدان معناست که هر نقطه اتصال سیستمفایلی که توسط فرآیندهای واحد برقرار یا حذف شود برای آنها خصوصی خواهد بود و در میزبان قابل مشاهده نیست\&. با این حال، نقاط اتصال سیستمفایلی که در میزبان برقرار یا حذف شوند به فرآیندهای واحد منتشر خواهند شد\&. برای جزئیات در مورد فضاهای نام سیستمفایل به
\fBmount_namespaces\fR(7)
مراجعه کنید\&. پیشفرض خاموش است\&.
.sp
هنگامی که روشن شود، این گزینه سه عملیات را برای هر فرآیند فراخواندهشده اجرا میکند: یک فضای نام جدید
\fBCLONE_NEWNS\fR
ایجاد میشود، پس از آن تمام اتصالات موجود مجدداً به
\fBMS_SLAVE\fR
متصل میشوند تا انتشار از فرآیندهای واحد به میزبان غیرفعال شود (اما انتشار در جهت مخالف همچنان برقرار باقی میماند)\&. در نهایت، اتصالات دوباره به حالت انتشار پیکربندیشده با
\fIMountFlags=\fR
متصل میشوند، به زیر مراجعه کنید\&.
.sp
فضاهای نام سیستمفایل به صورت جداگانه برای هر فرآیندی که توسط مدیر سرویس fork شده است راهاندازی میشوند\&. اتصالات برقرارشده در فضای نام فرآیند ایجادشده توسط
\fIExecStartPre=\fR
بنابراین به محض خروج آن فرآیند بهطور خودکار پاکسازی میشوند و برای فرآیندهای بعدی fork شده برای
\fIExecStart=\fR
در دسترس نخواهند بود (و موارد مشابه برای دستورات مختلف دیگری که برای واحدها پیکربندی شدهاند نیز صدق میکند)\&. مشابهاً،
\fIJoinsNamespaceOf=\fR
اجازه اشتراک فضاهای نام اتصال هسته بین واحدها را نمیدهد، بلکه فقط امکان اشتراکگذاری دایرکتوریهای
/tmp/
و
/var/tmp/
را فراهم میکند\&.
.sp
سایر تنظیمات واحد فضای نام سیستمفایل \(em
\fIPrivateTmp=\fR،
\fIPrivateDevices=\fR،
\fIProtectSystem=\fR،
\fIProtectHome=\fR،
\fIReadOnlyPaths=\fR،
\fIInaccessiblePaths=\fR،
\fIReadWritePaths=\fR،
\fIBindPaths=\fR،
\fIBindReadOnlyPaths=\fR
و غیره \(em نیز فضاسازی نام سیستمفایل را به روشی معادل با این گزینه فعال میکنند\&. از این رو در درجه اول در صورتی مفید است که صریحاً این رفتار درخواست شود اگر هیچ یک از تنظیمات دیگر استفاده نشده باشد\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.sp
اضافهشده در نسخه 239\&.
.RE
.PP
\fIMountFlags=\fR
.RS 4
یک تنظیم انتشار اتصال را میپذیرد:
\fBshared\fR،
\fBslave\fR
یا
\fBprivate\fR،
که کنترل میکند آیا نقاط اتصال سیستمفایل در فضاهای نام سیستمفایل راهاندازیشده برای فرآیندهای این واحد، اتصالات و جداسازیها را از سایر فضاهای نام سیستمفایل دریافت یا منتشر میکنند یا خیر\&. برای جزئیات در مورد انتشار اتصالات و به ویژه سه پرچم انتشار به
\fBmount\fR(2)
مراجعه کنید\&.
.sp
این تنظیم فقط تنظیم انتشار
\fIنهایی\fR
را که بر روی تمام نقاط اتصال فضای نام سیستمفایل ایجادشده برای هر فرآیند این واحد مؤثر است کنترل میکند\&. سایر تنظیمات واحد فضاسازی نام سیستمفایل (به بحث در
\fIPrivateMounts=\fR
در بالا مراجعه کنید) با تغییر تنظیم انتشار تمام نقاط اتصال در فضای نام سیستمفایل واحد به
\fBslave\fR
در ابتدا، انتشار اتصال و جداسازی را از فرآیندهای واحد به سمت میزبان به صورت ضمنی غیرفعال میکنند\&. تنظیم این گزینه روی
\fBshared\fR
در آن حالت انتشار را دوباره برقرار نمیکند\&.
.sp
اگر تنظیم نشده باشد \(en اما فضاهای نام سیستمفایل از طریق یک تنظیم واحد دیگر فضای نام سیستمفایل فعال شده باشد \(en انتشار اتصال
\fBshared\fR
استفاده میشود، اما \(en همانطور که ذکر شد \(en از آنجا که ابتدا
\fBslave\fR
اعمال میشود، انتشار از فرآیندهای واحد به میزبان همچنان خاموش است\&.
.sp
استفاده از انتشار اتصال
\fBprivate\fR
برای واحدها توصیه نمیشود، زیرا این بدان معناست که اتصالات موقت (مانند رسانههای جداشدنی) میزبان در فرآیندهای fork شده متصل و بنابراین برای همیشه مشغول باقی میمانند، زیرا رویدادهای انتشار جداسازی توسط فضای نام سیستمفایل واحد دریافت نخواهند شد\&.
.sp
معمولاً بهتر است این تنظیم را بدون تغییر باقی بگذارید و به جای آن از گزینههای سطح بالاتر فضاسازی نام سیستمفایل، به ویژه
\fIPrivateMounts=\fR
استفاده کنید، به بالا مراجعه کنید\&.
.sp
این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت
\fIPrivateUsers=\fR
بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام
"kernel\&.unprivileged_userns_clone="
است)\&.
.RE
.SH "فیلتر کردن فراخوان‌های سیستمی (SYSTEM CALL FILTERING)"
.PP
\fISystemCallFilter=\fR
.RS 4
فهرستی جداشده با فاصله از نام‌های فراخوانی سیستمی یا گروه‌های فراخوانی سیستمی را می‌پذیرد\&. در صورت استفاده از این تنظیم، فراخوانی‌های سیستمی اجراشده توسط فرآیندهای واحد به جز موارد فهرست‌شده، منجر به رد شدن فراخوانی سیستمی خواهند شد (فهرست مجاز)\&. اگر اولین نویسه فهرست
"~"
باشد، اثر معکوس می‌شود: تنها فراخوانی‌های سیستمی فهرست‌شده رد خواهند شد (فهرست مسدود)\&. این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت ماسک‌های فیلتر ادغام می‌شوند\&. اگر رشته خالی اختصاص یابد، فیلتر بازنشانی می‌شود و تمام تخصیص‌های قبلی بی‌اثر خواهند بود\&.
.sp
دستورات با پیشوند
"+"
مشمول فیلتر کردن نیستند\&. فراخوانی‌های سیستمی
\fBexecve()\fR،
\fBexit()\fR،
\fBexit_group()\fR،
\fBgetrlimit()\fR،
\fBrt_sigreturn()\fR،
\fBsigreturn()\fR
و فراخوانی‌های سیستمی برای پرس‌وجوی زمان و خواب (sleep) به صورت ضمنی در فهرست مجاز قرار دارند و نیازی به فهرست کردن صریح آن‌ها نیست\&.
.sp
اقدام پیش‌فرض هنگام رد شدن یک فراخوانی سیستمی، خاتمه دادن به فرآیندها با سیگنال
\fBSIGSYS\fR
است\&. این مورد را می‌توان با استفاده از
\fISystemCallErrorNumber=\fR
تغییر داد، به زیر مراجعه کنید\&. علاوه بر این، فراخوانی‌های سیستمی و گروه‌های فراخوانی سیستمیِ موجود در فهرست مسدود ممکن است به صورت اختیاری با یک دونقطه (":") و یک آرگومان در همان قالب
\fISystemCallErrorNumber=\fR
پسوندگذاری شوند تا هنگام انجام فراخوانی سیستمی منطبق، این اقدام انجام شود\&. این بر اقدام مشخص‌شده در
\fISystemCallErrorNumber=\fR
اولویت دارد\&.
.sp
این ویژگی از رابط‌های حالت محاسباتی امن ۲ هسته (\(aqseccomp filtering\(aq) استفاده می‌کند و برای اعمال یک محیط ایزوله کمینه مفید است\&.
.sp
توجه داشته باشید که در سیستم‌هایی که از چندین ABI پشتیبانی می‌کنند (مانند x86/x86\-64) توصیه می‌شود ABIهای جایگزین را برای سرویس‌ها غیرفعال کنید تا نتوان از آن‌ها برای دور زدن محدودیت‌های این گزینه استفاده کرد\&. به طور خاص، توصیه می‌شود این گزینه را با
\fISystemCallArchitectures=native\fR
یا مشابه آن ترکیب نمایید\&.
.sp
توجه داشته باشید که فیلترهای دقیق فراخوانی سیستمی ممکن است بر مسیرهای کد اجرا و مدیریت خطای فراخوانی سرویس تأثیر بگذارند\&. به طور خاص، دسترسی به فراخوانی سیستمی
\fBexecve()\fR
برای اجرای باینری سرویس لازم است \(em در صورت مسدود شدن آن، فراخوانی سرویس لزوماً با شکست مواجه خواهد شد\&. همچنین اگر اجرای باینری سرویس به دلایلی با شکست مواجه شود (مثلاً: فایل اجرایی سرویس وجود نداشته باشد)، منطق مدیریت خطا ممکن است برای پردازش و ثبت صحیح این خطا به دسترسی به مجموعه‌ای از فراخوانی‌های سیستمی اضافی نیاز داشته باشد\&. ممکن است لازم باشد موقتاً فیلترهای فراخوانی سیستمی را غیرفعال کنید تا امکان اشکال‌زدایی چنین خطاهایی فراهم شود\&.
.sp
اگر هر دو نوع این گزینه را مشخص کنید (یعنی فهرست مجاز و فهرست مسدود)، اولین موردی که با آن مواجه می‌شوید اولویت خواهد داشت و اقدام پیش‌فرض را دیکته می‌کند (خاتمه یا تأیید یک فراخوانی سیستمی)\&. سپس رخدادهای بعدی این گزینه بسته به نوع آن و اقدام پیش‌فرض، فراخوانی‌های سیستمی فهرست‌شده را از مجموعه فراخوانی‌های سیستمی فیلترشده اضافه یا حذف می‌کنند\&. (به عنوان مثال، اگر با یک قانون فهرست مجاز برای
\fBread()\fR
و
\fBwrite()\fR
شروع کرده باشید، و بلافاصله پس از آن یک قانون فهرست مسدود برای
\fBwrite()\fR
اضافه کنید، آن‌گاه
\fBwrite()\fR
از مجموعه حذف خواهد شد\&.)
.sp
از آنجا که تعداد فراخوانی‌های سیستمی ممکن زیاد است، گروه‌های از پیش تعریف‌شده‌ای از فراخوانی‌های سیستمی ارائه شده است\&. یک گروه با نویسه
"@"
شروع می‌شود که نام مجموعه به دنبال آن می‌آید\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B جدول\ &4.\ &مجموعه‌های فراخوانی سیستمی از پیش تعریف‌شده کنونی
.TS
allbox tab(:);
lB lB.
T{
مجموعه
T}:T{
توضیحات
T}
.T&
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l.
T{
@aio
T}:T{
ورودی/خروجی ناهمگام (\fBio_setup\fR(2)، \fBio_submit\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@basic\-io
T}:T{
فراخوانی‌های سیستمی برای I/O پایه: خواندن، نوشتن، جستجو (seek)، تکثیر توصیف‌کننده فایل و بستن (\fBread\fR(2)، \fBwrite\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@chown
T}:T{
تغییر مالکیت فایل (\fBchown\fR(2)، \fBfchownat\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@clock
T}:T{
فراخوانی‌های سیستمی برای تغییر ساعت سیستم (\fBadjtimex\fR(2)، \fBsettimeofday\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@cpu\-emulation
T}:T{
فراخوانی‌های سیستمی برای عملکرد شبیه‌سازی پردازنده (\fBvm86\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@debug
T}:T{
عملکرد اشکال‌زدایی، نظارت بر کارایی و ردیابی (\fBptrace\fR(2)، \fBperf_event_open\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@file\-system
T}:T{
عملیات سیستم‌فایل: باز کردن، ایجاد فایل‌ها و دایرکتوری‌ها برای خواندن و نوشتن، تغییر نام و حذف آن‌ها، خواندن ویژگی‌های فایل، یا ایجاد پیوندهای سخت و نمادین
T}
T{
@io\-event
T}:T{
فراخوانی‌های سیستمی حلقه رویداد (\fBpoll\fR(2)، \fBselect\fR(2)، \fBepoll\fR(7)، \fBeventfd\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@ipc
T}:T{
لوله‌ها (Pipes)، SysV IPC، صف‌های پیام POSIX و سایر روش‌های IPC (\fBmq_overview\fR(7)، \fBsvipc\fR(7))
T}
T{
@keyring
T}:T{
دسترسی به دسته‌کلید (keyring) هسته (\fBkeyctl\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@memlock
T}:T{
قفل کردن حافظه در RAM (\fBmlock\fR(2)، \fBmlockall\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@module
T}:T{
بارگذاری و تخلیه ماژول‌های هسته (\fBinit_module\fR(2)، \fBdelete_module\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@mount
T}:T{
اتصال و جداسازی سیستم‌های فایل (\fBmount\fR(2)، \fBchroot\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@network\-io
T}:T{
ورودی/خروجی سوکت (شامل AF_UNIX محلی): \fBsocket\fR(7)، \fBunix\fR(7)
T}
T{
@obsolete
T}:T{
غیرمعمول، منسوخ یا پیاده‌سازی‌نشده (\fBcreate_module\fR(2)، \fBgtty\fR(2) و غیره)
T}
T{
@pkey
T}:T{
فراخوانی‌های سیستمی مربوط به کلیدهای حفاظت از حافظه (\fBpkeys\fR(7))
T}
T{
@privileged
T}:T{
تمام فراخوانی‌های سیستمی که به قابلیت‌های کاربر ارشد نیاز دارند (\fBcapabilities\fR(7))
T}
T{
@process
T}:T{
کنترل فرآیند، اجرا، عملیات فضاسازی نام (\fBclone\fR(2)، \fBkill\fR(2)، \fBnamespaces\fR(7) و غیره)
T}
T{
@raw\-io
T}:T{
دسترسی خام به پورت I/O (\fBioperm\fR(2)، \fBiopl\fR(2)، \fBpciconfig_read()\fR و غیره)
T}
T{
@reboot
T}:T{
فراخوانی‌های سیستمی برای راه‌اندازی مجدد و آماده‌سازی راه‌اندازی مجدد (\fBreboot\fR(2)، \fBkexec()\fR و غیره)
T}
T{
@resources
T}:T{
فراخوانی‌های سیستمی برای تغییر محدودیت‌های منابع، حافظه و پارامترهای زمان‌بندی (\fBsetrlimit\fR(2)، \fBsetpriority\fR(2) و غیره)
T}
T{
@sandbox
T}:T{
فراخوانی‌های سیستمی برای ایزوله‌سازی برنامه‌ها (\fBseccomp\fR(2)، فراخوانی‌های سیستمی Landlock و غیره)
T}
T{
@setuid
T}:T{
فراخوانی‌های سیستمی برای تغییر شناسه‌های کاربری و گروهی (\fBsetuid\fR(2)، \fBsetgid\fR(2)، \fBsetresuid\fR(2) و غیره)
T}
T{
@signal
T}:T{
فراخوانی‌های سیستمی برای دستکاری و مدیریت سیگنال‌های فرآیند (\fBsignal\fR(2)، \fBsigprocmask\fR(2) و غیره)
T}
T{
@swap
T}:T{
فراخوانی‌های سیستمی برای فعال/غیرفعال کردن دستگاه‌های swap (\fBswapon\fR(2)، \fBswapoff\fR(2))
T}
T{
@sync
T}:T{
همگام‌سازی فایل‌ها و حافظه روی دیسک (\fBfsync\fR(2)، \fBmsync\fR(2) و فراخوانی‌های مرتبط)
T}
T{
@system\-service
T}:T{
مجموعه‌ای منطقی از فراخوانی‌های سیستمی مورد استفاده سرویس‌های سیستمی رایج، به استثنای هرگونه فراخوانی با هدف خاص\&. این نقطه شروع پیشنهادی برای قرار دادن فراخوانی‌های سیستمی در فهرست مجاز برای سرویس‌های سیستمی است، زیرا شامل آنچه معمولاً توسط سرویس‌های سیستمی مورد نیاز است بوده، اما رابط‌های بسیار خاص را مستثنی می‌کند\&. برای مثال، APIهای زیر مستثنی شده‌اند: "@clock"، "@mount"، "@swap"، "@reboot"\&.
T}
T{
@timer
T}:T{
فراخوانی‌های سیستمی برای زمان‌بندی عملیات بر حسب زمان (\fBalarm\fR(2)، \fBtimer_create\fR(2) و غیره)
T}
T{
@known
T}:T{
تمام فراخوانی‌های سیستمی تعریف‌شده توسط هسته\&. این فهرست به صورت ایستا در systemd بر اساس نسخه هسته‌ای که در زمان انتشار این نسخه systemd در دسترس بود تعریف شده است\&. با به‌روزرسانی هسته، به تدریج قدیمی‌تر خواهد شد\&.
T}
.TE
.sp 1
توجه داشته باشید که با اضافه شدن فراخوانی‌های سیستمی جدید به هسته، ممکن است فراخوانی‌های سیستمی بیشتری به گروه‌های بالا اضافه شوند\&. محتویات مجموعه‌ها نیز ممکن است بین نسخه‌های systemd تغییر کند\&. علاوه بر این، فهرست فراخوانی‌های سیستمی به نسخه هسته و معماری که systemd برای آن کامپایل شده است بستگی دارد\&. از
\fBsystemd\-analyze\ \&syscall\-filter\fR
برای فهرست کردن لیست واقعی فراخوانی‌های سیستمی در هر فیلتر استفاده کنید\&.
.sp
به طور کلی، قرار دادن فراخوانی‌های سیستمی در فهرست مجاز (به جای فهرست مسدود) حالت عملکرد ایمن‌تری است\&. توصیه می‌شود فهرست‌های مجاز فراخوانی سیستمی برای تمام سرویس‌های سیستمی با اجرای طولانی اعمال شود\&. به طور خاص، خطوط زیر یک انتخاب پایه نسبتاً ایمن برای اکثر سرویس‌های سیستمی هستند:
.sp
.if n \{\
.RS 4
.\}
.nf
[Service]
SystemCallFilter=@system\-service
SystemCallErrorNumber=EPERM
.fi
.if n \{\
.RE
.\}
.sp
توجه داشته باشید که فراخوانی‌های سیستمی مختلف هسته به صورت تکراری تعریف شده‌اند: چندین فراخوانی سیستمی برای اجرای یک عملیات یکسان وجود دارد\&. به عنوان مثال، فراخوانی سیستمی
\fBpidfd_send_signal()\fR
ممکن است برای اجرای عملیات مشابه آنچه می‌توان با فراخوانی سیستمی قدیمی‌تر
\fBkill()\fR
انجام داد استفاده شود، از این رو مسدود کردن دومی بدون اولی فقط محافظت ضعیفی ارائه می‌دهد\&. از آنجا که فراخوانی‌های سیستمی جدید به طور منظم با پیشرفت توسعه به هسته اضافه می‌شوند، جامع نگه داشتن فهرست‌های مسدود فراخوانی سیستمی نیاز به کار مداوم دارد\&. بنابراین توصیه می‌شود به جای آن از فهرست مجاز استفاده شود، که این مزیت را دارد که فراخوانی‌های سیستمی جدید به طور پیش‌فرض به صورت ضمنی مسدود می‌شوند تا زمانی که فهرست مجاز به‌روزرسانی شود\&.
.sp
همچنین توجه داشته باشید که تعدادی از فراخوانی‌های سیستمی برای کارکرد پیونددهنده پویا (dynamic linker) باید قابل دسترسی باشند\&. پیونددهنده پویا برای اجرای اکثر برنامه‌های معمولی مورد نیاز است (به ویژه: تمام باینری‌های پویای ELF، که روشی است که اکثر توزیع‌ها برنامه‌های بسته‌بندی‌شده را می‌سازند)\&. این بدان معناست که مسدود کردن این فراخوانی‌های سیستمی (شامل
\fBopen()\fR،
\fBopenat()\fR
یا
\fBmmap()\fR)
اکثر برنامه‌هایی را که معمولاً با توزیع‌های عمومی ارائه می‌شوند، غیرقابل استفاده خواهد کرد\&.
.sp
توصیه می‌شود گزینه‌های مربوط به فضاسازی نام سیستم‌فایل را با
\fISystemCallFilter=~@mount\fR
ترکیب کنید، تا فرآیندهای واحد از باطل کردن نگاشت‌ها منع شوند\&. به طور خاص این‌ها گزینه‌های زیر هستند:
\fIPrivateTmp=\fR،
\fIPrivateDevices=\fR،
\fIProtectSystem=\fR،
\fIProtectHome=\fR،
\fIProtectKernelTunables=\fR،
\fIProtectControlGroups=\fR،
\fIProtectKernelLogs=\fR،
\fIProtectClock=\fR،
\fIReadOnlyPaths=\fR،
\fIInaccessiblePaths=\fR
و
\fIReadWritePaths=\fR\&.
.sp
اضافه‌شده در نسخه 187\&.
.RE
.PP
\fISystemCallErrorNumber=\fR
.RS 4
یک شماره خطای
"errno"
(بین 1 و 4095) یا نام errno مانند
\fBEPERM\fR،
\fBEACCES\fR
یا
\fBEUCLEAN\fR
را می‌پذیرد تا هنگام تحریک فیلتر فراخوانی سیستمیِ پیکربندی‌شده با
\fISystemCallFilter=\fR،
به جای خاتمه فوری فرآیند بازگردانده شود\&. برای فهرست کامل کدهای خطا به
\fBerrno\fR(3)
مراجعه کنید\&. هنگامی که از این تنظیم استفاده نمی‌شود، یا هنگامی که رشته خالی یا تنظیم ویژه
"kill"
اختصاص داده می‌شود، فرآیند بلافاصله پس از تحریک فیلتر خاتمه می‌یابد\&.
.sp
اضافه‌شده در نسخه 209\&.
.RE
.PP
\fISystemCallArchitectures=\fR
.RS 4
فهرستی جداشده با فاصله از شناسه‌های معماری را برای گنجاندن در فیلتر فراخوانی سیستمی می‌پذیرد\&. شناسه‌های معماری شناخته‌شده همان مواردی هستند که برای
\fIConditionArchitecture=\fR
در
\fBsystemd.unit\fR(5)
شرح داده شده است، و همچنین
\fBx32\fR،
\fBmips64\-n32\fR،
\fBmips64\-le\-n32\fR
و شناسه ویژه
\fBnative\fR\&.
شناسه ویژه
\fBnative\fR
به طور ضمنی به معماری بومی سیستم (یا دقیق‌تر: به معماری که مدیر سیستم برای آن کامپایل شده است) نگاشت می‌شود\&. به طور پیش‌فرض، این گزینه روی فهرست خالی تنظیم شده است، یعنی هیچ فیلتری اعمال نمی‌شود\&.
.sp
اگر از این تنظیم استفاده شود، فرآیندهای این واحد فقط مجاز خواهند بود فراخوانی‌های سیستمی بومی و فراخوانی‌های سیستمی معماری‌های مشخص‌شده را فراخوانی کنند\&. برای اهداف این گزینه، معماری x32 شامل فراخوانی‌های سیستمی x86\-64 در نظر گرفته می‌شود\&. با این حال، این تنظیم همچنان هدف خود را، همان‌طور که در زیر توضیح داده شده است، در x32 برآورده می‌کند\&.
.sp
فیلتر کردن فراخوانی سیستمی در همه معماری‌ها به یک اندازه مؤثر نیست\&. برای مثال، در x86 فیلتر کردن فراخوانی‌های مربوط به سوکت شبکه به دلیل محدودیت‌های ABI امکان‌پذیر نیست \(em محدودیتی که البته x86\-64 ندارد\&. در سیستم‌هایی که همزمان از چندین ABI پشتیبانی می‌کنند \(em مانند x86/x86\-64 \(em از این رو توصیه می‌شود مجموعه معماری‌های مجاز فراخوانی سیستمی را محدود کنید تا ABIهای ثانویه نتوانند برای دور زدن محدودیت‌های اعمال‌شده بر ABI بومی سیستم استفاده شوند\&. به ویژه، تنظیم
\fISystemCallArchitectures=native\fR
یک انتخاب خوب برای غیرفعال کردن ABIهای غیربومی است\&.
.sp
معماری‌های فراخوانی سیستمی ممکن است در سراسر سیستم از طریق گزینه
\fISystemCallArchitectures=\fR
در پیکربندی سراسری نیز محدود شوند\&. برای جزئیات به
\fBsystemd-system.conf\fR(5)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 209\&.
.RE
.PP
\fISystemCallLog=\fR
.RS 4
فهرستی جداشده با فاصله از نام‌های فراخوانی سیستمی را می‌پذیرد\&. اگر از این تنظیم استفاده شود، تمام فراخوانی‌های سیستمی اجراشده توسط فرآیندهای واحد برای موارد فهرست‌شده ثبت خواهند شد\&. اگر اولین نویسه فهرست
"~"
باشد، اثر معکوس می‌شود: تمام فراخوانی‌های سیستمی به جز فراخوانی‌های سیستمی فهرست‌شده ثبت خواهند شد\&. این ویژگی از رابط‌های Secure Computing Mode 2 هسته (\(aqseccomp filtering\(aq) استفاده می‌کند و برای ممیزی یا راه‌اندازی یک محیط ایزوله کمینه مفید است\&. این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت ماسک‌های فیلتر ادغام می‌شوند\&. اگر رشته خالی اختصاص یابد، فیلتر بازنشانی می‌شود و تمام تخصیص‌های قبلی بی‌اثر خواهند بود\&. این گزینه بر دستورات دارای پیشوند
"+"
تأثیری ندارد\&.
.sp
اضافه‌شده در نسخه 247\&.
.RE
.SH "محیط (ENVIRONMENT)"
.PP
\fIEnvironment=\fR
.RS 4
متغیرهای محیطی را برای فرآیندهای اجراشده تنظیم می‌کند\&. هر خط با استفاده از قوانین شرح داده شده در بخش "Quoting" در
\fBsystemd.syntax\fR(7)
از نقل‌قول خارج شده و به فهرستی از انتساب‌های متغیر تبدیل می‌شود\&. اگر نیاز دارید مقداری حاوی فاصله‌ها یا علامت مساوی را به یک متغیر اختصاص دهید، دور کل انتساب نقل‌قول قرار دهید\&. بسط متغیر درون رشته‌ها انجام نمی‌شود و نویسه
"$"
هیچ معنای خاصی ندارد\&. بسط تعیین‌کننده‌ها (specifiers) انجام می‌شود، بخش "Specifiers" را در
\fBsystemd.unit\fR(5)
ببینید\&.
.sp
این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت تمام متغیرهای فهرست‌شده تنظیم خواهند شد\&. اگر یک متغیر دو بار فهرست شود، تنظیم بعدی تنظیم قبلی را بازنویسی خواهد کرد\&. اگر رشته خالی به این گزینه اختصاص یابد، فهرست متغیرهای محیطی بازنشانی می‌شود و تمام تخصیص‌های قبلی بی‌اثر خواهند بود\&.
.sp
نام متغیرها می‌تواند شامل حروف ASCII، ارقام و نویسه زیرخط باشد\&. نام متغیر نمی‌تواند خالی باشد یا با یک رقم شروع شود\&. در مقادیر متغیر، بیشتر نویسه‌ها مجاز هستند، اما نویسه‌های غیرقابل چاپ در حال حاضر رد می‌شوند\&.
.sp
مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"
.fi
.if n \{\
.RE
.\}
.sp
سه متغیر
"VAR1"،
"VAR2"،
"VAR3"
را با مقادیر
"word1 word2"،
"word3"،
"$word 5 6"
ایجاد می‌کند\&.
.sp
برای جزئیات درباره متغیرهای محیطی به
\fBenviron\fR(7)
مراجعه کنید\&.
.sp
توجه داشته باشید که متغیرهای محیطی برای انتقال داده‌های محرمانه (مانند گذرواژه‌ها، داده‌های کلید و غیره) به فرآیندهای سرویس مناسب نیستند\&. متغیرهای محیطی تنظیم‌شده برای یک واحد از طریق D\-Bus IPC در دسترس کلاینت‌های بدون امتیاز قرار می‌گیرند، و عموماً به عنوان داده‌هایی که نیاز به حفاظت دارند درک نمی‌شوند\&. علاوه بر این، متغیرهای محیطی در درخت فرآیندها، از جمله در مرزهای امنیتی (مانند فایل‌های اجرایی setuid/setgid) منتشر می‌شوند، و از این رو ممکن است به فرآیندهایی که نباید به داده‌های محرمانه دسترسی داشته باشند نشت کنند\&. از
\fILoadCredential=\fR،
\fILoadCredentialEncrypted=\fR
یا
\fISetCredentialEncrypted=\fR
(به زیر مراجعه کنید) برای ارسال ایمن داده‌ها به فرآیندهای واحد استفاده کنید\&.
.RE
.PP
\fIEnvironmentFile=\fR
.RS 4
مشابه
\fIEnvironment=\fR
است، اما متغیرهای محیطی را از یک فایل متنی می‌خواند\&. فایل متنی باید حاوی انتساب‌های متغیر جداشده با خط جدید باشد\&. سطرهای خالی، سطرهای بدون جداکننده
"="
یا سطرهایی که با
";"
یا
"#"
شروع می‌شوند نادیده گرفته خواهند شد، که می‌تواند برای یادداشت‌گذاری (کامنت) استفاده شود\&. فایل باید با UTF\-8 کدگذاری شود\&. نویسه‌های معتبر عبارتند از
\m[blue]\fBمقادیر اسکالر یونیکد (unicode scalar values)\fR\m[]\&\s-2\u[9]\d\s+2
به جز
\m[blue]\fBغیرنویسه‌های یونیکد (unicode noncharacters)\fR\m[]\&\s-2\u[10]\d\s+2،
\fBU+0000\fR
\fBNUL\fR
و
\fBU+FEFF\fR
\m[blue]\fBنشانگر ترتیب بایت یونیکد (unicode byte order mark)\fR\m[]\&\s-2\u[11]\d\s+2\&.
کدهای کنترلی غیر از
\fBNUL\fR
مجاز هستند\&.
.sp
در فایل، یک مقدار بدون نقل‌قول بعد از
"="
با همان قوانین گریز با بک‌اسلش مانند
\m[blue]\fBمتن بدون نقل‌قول شل POSIX\fR\m[]\&\s-2\u[12]\d\s+2
تجزیه می‌شود، اما بر خلاف شل، فضای خالی داخلی حفظ می‌شود و نقل‌قول‌ها پس از اولین نویسه غیرفضای‌خالی حفظ می‌گردند\&. فاصله‌های خالی ابتدا و انتهای سطر (فاصله، تب، carriage return) دور ریخته می‌شوند، اما فاصله‌های خالی داخلی درون سطر به همان صورت حفظ می‌شوند\&. سطری که با یک بک‌اسلش پایان می‌یابد به سطر بعدی ادامه می‌یابد، در حالی که خود خط جدید دور ریخته می‌شود\&. یک بک‌اسلش
"\e"
به دنبال هر نویسه‌ای غیر از خط جدید، نویسه بعدی را حفظ می‌کند، به طوری که
"\e\e"
تبدیل به مقدار
"\e"
می‌شود\&.
.sp
در فایل، یک مقدار نقل‌قول‌شده با
"\(aq"
بعد از
"="
می‌تواند چندین سطر را در بر بگیرد و شامل هر نویسه‌ای به همان صورت به جز نقل‌قول تکی باشد، مانند
\m[blue]\fBمتن با نقل‌قول تکی شل POSIX\fR\m[]\&\s-2\u[13]\d\s+2\&.
هیچ توالی گریز با بک‌اسلش شناسایی نمی‌شود\&. فاصله‌های خالی ابتدا و انتها در خارج از نقل‌قول تکی دور ریخته می‌شوند\&.
.sp
در فایل، یک مقدار نقل‌قول‌شده با
'\"'
بعد از
"="
می‌تواند چندین سطر را در بر بگیرد، و همان توالی‌های گریز مانند
\m[blue]\fBمتن با نقل‌قول دوتایی شل POSIX\fR\m[]\&\s-2\u[14]\d\s+2
شناسایی می‌شوند\&. بک‌اسلش ("\e") به دنبال هر یک از
"\"\e`$"
آن نویسه را حفظ می‌کند\&. یک بک‌اسلش به دنبال خط جدید ادامه سطر است و خود خط جدید دور ریخته می‌شود\&. یک بک‌اسلش به دنبال هر نویسه دیگری نادیده گرفته می‌شود؛ هم بک‌اسلش و هم نویسه بعدی به همان صورت حفظ می‌شوند\&. فاصله‌های خالی ابتدا و انتها در خارج از نقل‌قول دوتایی دور ریخته می‌شوند\&.
.sp
آرگومان ارسال‌شده باید یک نام فایل مطلق یا عبارت wildcard باشد، به صورت اختیاری با پیشوند
"\-"،
که نشان می‌دهد اگر فایل وجود نداشته باشد، خوانده نخواهد شد و هیچ پیام خطا یا هشداری ثبت نمی‌شود\&. این گزینه ممکن است بیش از یک بار مشخص شود که در این صورت تمام فایل‌های مشخص‌شده خوانده می‌شوند\&. اگر رشته خالی به این گزینه اختصاص یابد، فهرست فایل‌های خواندنی بازنشانی می‌شود و تمام انتساب‌های قبلی بی‌اثر خواهند بود\&.
.sp
فایل‌های فهرست‌شده با این دستورالعمل کمی قبل از اجرای فرآیند خوانده می‌شوند (دقیق‌تر: پس از خاتمه تمام فرآیندهای مربوط به وضعیت قبلی واحد\&. این بدان معناست که می‌توانید این فایل‌ها را در یک وضعیت واحد تولید کنید و با این گزینه در وضعیت بعدی بخوانید\&. فایل‌ها از سیستم‌فایل مدیر سرویس، قبل از هرگونه تغییر سیستم‌فایل مانند bind mount خوانده می‌شوند)\&.
.sp
تنظیمات حاصل از این فایل‌ها تنظیمات انجام‌شده با
\fIEnvironment=\fR
را بازنویسی می‌کنند\&. اگر یک متغیر دو بار از این فایل‌ها تنظیم شود، فایل‌ها به ترتیبی که مشخص شده‌اند خوانده می‌شوند و تنظیم بعدی تنظیم قبلی را بازنویسی خواهد کرد\&.
.RE
.PP
\fIPassEnvironment=\fR
.RS 4
متغیرهای محیطی تنظیم‌شده برای مدیر سرویس سیستم را به فرآیندهای اجراشده منتقل می‌کند\&. فهرستی جداشده با فاصله از نام متغیرها را می‌پذیرد\&. این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت تمام متغیرهای فهرست‌شده منتقل خواهند شد\&. اگر رشته خالی به این گزینه اختصاص یابد، فهرست متغیرهای محیطی برای انتقال بازنشانی می‌شود و تمام تخصیص‌های قبلی بی‌اثر خواهند بود\&. متغیرهای مشخص‌شده‌ای که برای مدیر سیستم تنظیم نشده‌اند منتقل نخواهند شد و بی‌صدا نادیده گرفته می‌شوند\&. توجه داشته باشید که این گزینه فقط برای مدیر سرویس سیستم مرتبط است، زیرا سرویس‌های سیستمی به طور پیش‌فرض هیچ متغیر محیطی تنظیم‌شده برای خود مدیر سرویس را به طور خودکار به ارث نمی‌برند\&. با این حال، در مورد مدیر سرویس کاربر، تمام متغیرهای محیطی به هر حال به فرآیندهای اجراشده منتقل می‌شوند، از این رو این گزینه برای مدیر سرویس کاربر بدون اثر است\&.
.sp
متغیرهای تنظیم‌شده برای فرآیندهای فراخوانده‌شده ناشی از این تنظیم، مشمول بازنویسی توسط موارد پیکربندی‌شده با
\fIEnvironment=\fR
یا
\fIEnvironmentFile=\fR
هستند\&.
.sp
مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
PassEnvironment=VAR1 VAR2 VAR3
.fi
.if n \{\
.RE
.\}
.sp
سه متغیر
"VAR1"،
"VAR2"،
"VAR3"
را با مقادیر تنظیم‌شده برای آن متغیرها در PID1 منتقل می‌کند\&.
.sp
برای جزئیات درباره متغیرهای محیطی به
\fBenviron\fR(7)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 228\&.
.RE
.PP
\fIUnsetEnvironment=\fR
.RS 4
انتساب‌های متغیرهای محیطی را که معمولاً از مدیر سرویس به فرآیندهای فراخوانده‌شده این واحد منتقل می‌شوند، به صراحت لغو می‌کند\&. فهرستی جداشده با فاصله از نام‌های متغیر یا انتساب‌های متغیر را می‌پذیرد\&. این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت تمام متغیرها/انتساب‌های فهرست‌شده لغو خواهند شد\&. اگر رشته خالی به این گزینه اختصاص یابد، فهرست متغیرها/انتساب‌های محیطی برای لغو، بازنشانی می‌شود\&. اگر یک انتساب متغیر مشخص شود (یعنی: یک نام متغیر، به دنبال آن
"="،
به دنبال مقدار آن)، آن‌گاه هر متغیر محیطی مطابق با این انتساب دقیق حذف می‌شود\&. اگر یک نام متغیر مشخص شود (یعنی یک نام متغیر بدون هیچ
"="
یا مقدار بعدی)، آن‌گاه هر انتسابی مطابق با نام متغیر، صرف‌نظر از مقدار آن حذف می‌شود\&. توجه داشته باشید که اثر
\fIUnsetEnvironment=\fR
به عنوان مرحله نهایی هنگام تدوین فهرست محیطی منتقل‌شده به فرآیندهای اجراشده اعمال می‌شود\&. این بدان معناست که ممکن است انتساب‌ها را از هر منبع پیکربندی لغو کند، از جمله انتساب‌های انجام‌شده از طریق
\fIEnvironment=\fR
یا
\fIEnvironmentFile=\fR،
به ارث برده شده از مجموعه سراسری متغیرهای محیطی مدیر سیستم، به ارث برده شده از طریق
\fIPassEnvironment=\fR،
تنظیم‌شده توسط خود مدیر سرویس (مانند
\fI$NOTIFY_SOCKET\fR
و نظایر آن)، یا تنظیم‌شده توسط یک ماژول PAM (در صورتی که
\fIPAMName=\fR
استفاده شده باشد)\&.
.sp
برای توصیف نحوه ترکیب این تنظیمات برای تشکیل محیط موروثی، به "متغیرهای محیطی در فرآیندهای ایجادشده" در زیر مراجعه کنید\&. برای اطلاعات عمومی درباره متغیرهای محیطی به
\fBenviron\fR(7)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 235\&.
.RE
.SH "گزارش‌گیری و ورودی/خروجی استاندارد (LOGGING AND STANDARD INPUT/OUTPUT)"
.PP
\fIStandardInput=\fR
.RS 4
کنترل می‌کند که توصیف‌کننده فایل 0 (STDIN) فرآیندهای اجراشده به کجا متصل شود\&. یکی از مقادیر
\fBnull\fR،
\fBtty\fR،
\fBtty\-force\fR،
\fBtty\-fail\fR،
\fBdata\fR،
\fBfile:\fR\fB\fIpath\fR\fR،
\fBsocket\fR
یا
\fBfd:\fR\fB\fIname\fR\fR
را می‌پذیرد\&.
.sp
اگر
\fBnull\fR
انتخاب شود، ورودی استاندارد به
/dev/null
متصل خواهد شد، یعنی تمام تلاش‌های خواندن توسط فرآیند منجر به EOF فوری می‌شود\&.
.sp
اگر
\fBtty\fR
انتخاب شود، ورودی استاندارد به یک TTY متصل می‌شود (همان‌طور که توسط
\fITTYPath=\fR
پیکربندی شده است، به زیر مراجعه کنید) و فرآیند اجراشده به فرآیند کنترل‌کننده ترمینال تبدیل می‌شود\&. اگر ترمینال قبلاً توسط فرآیند دیگری کنترل شده باشد، فرآیند اجراشده تا زمانی که فرآیند کنترل‌کننده فعلی ترمینال را آزاد کند منتظر می‌ماند\&.
.sp
گزینه
\fBtty\-force\fR
مشابه
\fBtty\fR
است، اما فرآیند اجراشده به اجبار و بلافاصله به فرآیند کنترل‌کننده ترمینال تبدیل می‌شود و احتمالاً فرآیندهای کنترل‌کننده قبلی را از ترمینال حذف می‌کند\&.
.sp
گزینه
\fBtty\-fail\fR
مشابه
\fBtty\fR
است، اما اگر ترمینال از قبل دارای یک فرآیند کنترل‌کننده باشد، راه‌اندازی فرآیند اجراشده با شکست مواجه می‌شود\&.
.sp
گزینه
\fBdata\fR
ممکن است برای پیکربندی داده‌های متنی یا دودویی دلخواه جهت ارسال از طریق ورودی استاندارد به فرآیند اجراشده استفاده شود\&. داده‌های ارسالی از طریق
\fIStandardInputText=\fR/\fIStandardInputData=\fR
پیکربندی می‌شوند (به زیر مراجعه کنید)\&. توجه داشته باشید که نوع واقعی توصیف‌کننده فایل ارسالی (فایل حافظه، فایل معمولی، لوله UNIX و غیره) ممکن است به هسته و امتیازات موجود بستگی داشته باشد\&. در هر صورت، توصیف‌کننده فایل فقط‌خواندنی است و هنگام خواندن، داده‌های مشخص‌شده را به همراه EOF بازمی‌گرداند\&.
.sp
گزینه
\fBfile:\fR\fB\fIpath\fR\fR
ممکن است برای اتصال یک شیء سیستم‌فایل خاص به ورودی استاندارد استفاده شود\&. یک مسیر مطلق به دنبال نویسه
":"
انتظار می‌رود که ممکن است به یک فایل معمولی، یک FIFO یا فایل ویژه اشاره داشته باشد\&. اگر یک سوکت
\fBAF_UNIX\fR
در سیستم‌فایل مشخص شود، یک سوکت جریانی (stream socket) به آن متصل می‌شود\&. مورد دوم برای اتصال ورودی استاندارد فرآیندها به سرویس‌های دلخواه سیستم مفید است\&.
.sp
گزینه
\fBsocket\fR
فقط در سرویس‌های فعال‌شده با سوکت معتبر است و مستلزم آن است که فایل واحد سوکت مربوطه (برای جزئیات به
\fBsystemd.socket\fR(5)
مراجعه کنید) دارای
\fIAccept=yes\fR
باشد، یا فقط یک سوکت منفرد را مشخص کند\&. اگر این گزینه تنظیم شود، ورودی استاندارد به سوکتی که سرویس از آن فعال شده است متصل خواهد شد، که این در درجه اول برای سازگاری با دیمون‌هایی مفید است که برای استفاده با دیمون فعال‌سازی سنتی سوکت
\fBinetd\fR(8)
طراحی شده‌اند (متغیرهای محیطی
\fI$LISTEN_FDS\fR
و متغیرهای مرتبط در هنگام پیکربندی مقدار
\fBsocket\fR
منتقل نمی‌شوند)\&.
.sp
گزینه
\fBfd:\fR\fB\fIname\fR\fR
ورودی استاندارد را به یک توصیف‌کننده فایل خاص و نام‌گذاری‌شده ارائه‌شده توسط یک واحد سوکت متصل می‌کند\&. نام ممکن است به عنوان بخشی از این گزینه، پس از نویسه
":"
مشخص شود (مانند
"fd:foobar")\&.
اگر هیچ نامی مشخص نشود، نام
"stdin"
به صورت ضمنی در نظر گرفته می‌شود (یعنی
"fd"
معادل
"fd:stdin"
است)\&. حداقل یک واحد سوکت که نام مشخص‌شده را تعریف می‌کند باید از طریق گزینه
\fISockets=\fR
ارائه شود، و نام توصیف‌کننده فایل ممکن است با نام واحد سوکت حاوی آن متفاوت باشد\&. اگر چندین تطابق یافت شود، از اولین مورد استفاده خواهد شد\&. برای جزئیات بیشتر درباره توصیف‌کننده‌های فایل نام‌گذاری‌شده و ترتیب آن‌ها به
\fIFileDescriptorName=\fR
در
\fBsystemd.socket\fR(5)
مراجعه کنید\&.
.sp
پیش‌فرض این تنظیم روی
\fBnull\fR
است، مگر اینکه
\fIStandardInputText=\fR/\fIStandardInputData=\fR
تنظیم شده باشند که در این صورت پیش‌فرض روی
\fBdata\fR
خواهد بود\&.
.RE
.PP
\fIStandardOutput=\fR
.RS 4
کنترل می‌کند که توصیف‌کننده فایل 1 (stdout) فرآیندهای اجراشده به کجا متصل شود\&. یکی از مقادیر
\fBinherit\fR،
\fBnull\fR،
\fBtty\fR،
\fBjournal\fR،
\fBkmsg\fR،
\fBjournal+console\fR،
\fBkmsg+console\fR،
\fBfile:\fR\fB\fIpath\fR\fR،
\fBappend:\fR\fB\fIpath\fR\fR،
\fBtruncate:\fR\fB\fIpath\fR\fR،
\fBsocket\fR
یا
\fBfd:\fR\fB\fIname\fR\fR
را می‌پذیرد\&.
.sp
گزینه
\fBinherit\fR
توصیف‌کننده فایل ورودی استاندارد را برای خروجی استاندارد تکثیر می‌کند\&.
.sp
گزینه
\fBnull\fR
خروجی استاندارد را به
/dev/null
متصل می‌کند، یعنی هر چیزی که در آن نوشته شود از دست خواهد رفت\&.
.sp
گزینه
\fBtty\fR
خروجی استاندارد را به یک tty متصل می‌کند (همان‌طور که از طریق
\fITTYPath=\fR
پیکربندی شده است، به زیر مراجعه کنید)\&. اگر TTY فقط برای خروجی استفاده شود، فرآیند اجراشده به فرآیند کنترل‌کننده ترمینال تبدیل نخواهد شد، و متوقف نمی‌شود یا منتظر نمی‌ماند تا فرآیندهای دیگر ترمینال را آزاد کنند\&. نکته: اگر یک واحد سعی کند چندین خط را در حین بوت یا خاموش شدن در TTY چاپ کند، این احتمال وجود دارد که آن خطوط توسط پیام‌های وضعیت شکسته شوند\&. می‌توان از
\fBSetShowStatus()\fR
برای جلوگیری از این مشکل استفاده کرد\&. برای جزئیات به
\fBorg.freedesktop.systemd1\fR(5)
مراجعه کنید\&.
.sp
گزینه
\fBjournal\fR
خروجی استاندارد را به ژورنال (journal) متصل می‌کند که از طریق
\fBjournalctl\fR(1)
قابل دسترسی است\&. توجه داشته باشید که هر آنچه در kmsg نوشته می‌شود (به زیر مراجعه کنید) به صورت ضمنی در ژورنال نیز ذخیره می‌شود، بنابراین گزینه خاص فهرست‌شده در زیر یک superset از این گزینه است\&. (همچنین توجه داشته باشید که هرگونه دیمون syslog خارجی و اضافی نیز داده‌های لاگ خود را از ژورنال دریافت می‌کند، از این رو هنگامی که ثبت وقایع باید با چنین دیمونی پردازش شود، این گزینه مورد استفاده قرار می‌گیرد\&.)
.sp
گزینه
\fBkmsg\fR
خروجی استاندارد را علاوه بر ژورنال، به بافر لاگ هسته که از طریق
\fBdmesg\fR(1)
قابل دسترسی است متصل می‌کند\&. دیمون ژورنال ممکن است به هر حال برای ارسال تمام لاگ‌ها به kmsg پیکربندی شده باشد، که در این صورت این گزینه تفاوتی با
\fBjournal\fR
ندارد\&.
.sp
گزینه‌های
\fBjournal+console\fR
و
\fBkmsg+console\fR
به روشی مشابه دو گزینه بالا عمل می‌کنند اما خروجی را در کنسول سیستم نیز کپی می‌کنند\&.
.sp
گزینه
\fBfile:\fR\fB\fIpath\fR\fR
ممکن است برای اتصال یک شیء خاص سیستم‌فایل به خروجی استاندارد استفاده شود\&. معنای آن مشابه همان گزینه در
\fIStandardInput=\fR
است، به بالا مراجعه کنید\&. اگر
\fIpath\fR
به یک فایل معمولی در سیستم‌فایل اشاره کند، برای نوشتن در ابتدای فایل باز می‌شود (در صورت عدم وجود با استفاده از امتیازات کاربر اجراکننده فرآیند systemd ایجاد می‌شود)، اما بدون کوتاه کردن (truncate) آن\&. اگر ورودی و خروجی استاندارد به همان مسیر فایل هدایت شوند، فقط یک بار باز می‌شود \(em هم برای خواندن و هم برای نوشتن \(em و تکثیر می‌شود\&. این امر به‌ویژه هنگامی مفید است که مسیر مشخص‌شده به یک سوکت
\fBAF_UNIX\fR
در سیستم‌فایل اشاره داشته باشد، زیرا در آن صورت فقط یک اتصال جریانی واحد برای هر دو ورودی و خروجی ایجاد می‌شود\&.
.sp
گزینه
\fBappend:\fR\fB\fIpath\fR\fR
مشابه
\fBfile:\fR\fB\fIpath\fR\fR
در بالا است، اما فایل را در حالت الحاق (append mode) باز می‌کند\&.
.sp
گزینه
\fBtruncate:\fR\fB\fIpath\fR\fR
مشابه
\fBfile:\fR\fB\fIpath\fR\fR
در بالا است، اما فایل را هنگام باز کردن کوتاه (truncate) می‌کند\&. برای واحدهایی با چندین خط فرمان، به عنوان مثال سرویس‌های
\fIType=oneshot\fR
با چندین
\fIExecStart=\fR،
یا سرویس‌های دارای
\fIExecCondition=\fR،
\fIExecStartPre=\fR
یا
\fIExecStartPost=\fR،
فایل خروجی دوباره باز می‌شود و بنابراین برای هر خط فرمان مجدداً truncate می‌شود\&. اگر فایل خروجی در حالی که فرآیند دیگری هنوز فایل را باز نگه داشته است truncate شود، به عنوان مثال توسط یک
\fIExecReload=\fR
که همزمان با یک
\fIExecStart=\fR
اجرا می‌شود، و فرآیند دیگر بدون تنظیم افست خود به نوشتن در فایل ادامه دهد، ممکن است فضای بین اشاره‌گرهای فایل دو فرآیند با بایت‌های
\fBNUL\fR
پر شود و یک فایل پراکنده (sparse file) ایجاد کند\&. بنابراین،
\fBtruncate:\fR\fB\fIpath\fR\fR
معمولاً فقط برای واحدهایی مفید است که در آن‌ها فقط یک فرآیند در هر زمان اجرا می‌شود، مانند سرویس‌هایی با یک
\fIExecStart=\fR
منفرد و بدون
\fIExecStartPost=\fR،
\fIExecReload=\fR،
\fIExecStop=\fR
یا نظایر آن\&.
.sp
گزینه
\fBsocket\fR
خروجی استاندارد را به سوکتی که از طریق فعال‌سازی سوکت به دست آمده متصل می‌کند\&. معنای آن مشابه همان گزینه در
\fIStandardInput=\fR
است، به بالا مراجعه کنید\&.
.sp
گزینه
\fBfd:\fR\fB\fIname\fR\fR
خروجی استاندارد را به یک توصیف‌کننده فایل مشخص و نام‌گذاری‌شده ارائه‌شده توسط یک واحد سوکت متصل می‌کند\&. یک نام ممکن است به عنوان بخشی از این گزینه، پس از نویسه
":"
مشخص شود (مانند
"fd:\fIfoobar\fR")\&.
اگر هیچ نامی مشخص نشود، نام
"stdout"
به صورت ضمنی در نظر گرفته می‌شود (یعنی
"fd"
معادل
"fd:stdout"
است)\&. حداقل یک واحد سوکت که نام مشخص‌شده را تعریف می‌کند باید از طریق گزینه
\fISockets=\fR
ارائه شود، و نام توصیف‌کننده فایل ممکن است با نام واحد سوکت حاوی آن متفاوت باشد\&. اگر چندین تطابق یافت شود، از اولین مورد استفاده خواهد شد\&. برای جزئیات بیشتر درباره توصیف‌کننده‌های نام‌گذاری‌شده و ترتیب آن‌ها به
\fIFileDescriptorName=\fR
در
\fBsystemd.socket\fR(5)
مراجعه کنید\&.
.sp
اگر خروجی استاندارد (یا خروجی خطا، به زیر مراجعه کنید) یک واحد به ژورنال یا بافر لاگ هسته متصل باشد، واحد به طور ضمنی وابستگی از نوع
\fIAfter=\fR
روی
systemd\-journald\&.socket
کسب خواهد کرد (همچنین به بخش "وابستگی‌های ضمنی" در بالا مراجعه کنید)\&. همچنین توجه داشته باشید که در این حالت stdout (یا stderr، به زیر مراجعه کنید) یک سوکت جریانی
\fBAF_UNIX\fR
خواهد بود و نه یک لوله یا FIFO که بتواند دوباره باز شود\&. این بدان معناست که هنگام اجرای اسکریپت‌های شل، ساختار
\fBecho "hello" > /dev/stderr\fR
برای نوشتن متن در stderr کار نخواهد کرد\&. برای رفع این مشکل از ساختار
\fBecho "hello" >&2\fR
استفاده کنید که عمدتاً معادل است و از این دام جلوگیری می‌کند\&.
.sp
اگر
\fIStandardInput=\fR
روی یکی از موارد
\fBtty\fR،
\fBtty\-force\fR،
\fBtty\-fail\fR،
\fBsocket\fR
یا
\fBfd:\fR\fB\fIname\fR\fR
تنظیم شده باشد، پیش‌فرض این تنظیم روی
\fBinherit\fR
خواهد بود\&.
.sp
در سایر موارد، این تنظیم پیش‌فرض روی مقدار تعیین‌شده با
\fIDefaultStandardOutput=\fR
در
\fBsystemd-system.conf\fR(5)
قرار می‌گیرد که پیش‌فرض آن
\fBjournal\fR
است\&. توجه داشته باشید که تنظیم این پارامتر ممکن است منجر به اضافه شدن وابستگی‌های اضافی به واحد شود (به بالا مراجعه کنید)\&.
.RE
.PP
\fIStandardError=\fR
.RS 4
کنترل می‌کند که توصیف‌کننده فایل 2 (stderr) فرآیندهای اجراشده به کجا متصل شود\&. گزینه‌های موجود با گزینه‌های
\fIStandardOutput=\fR
یکسان هستند، با چند استثنا: اگر روی
\fBinherit\fR
تنظیم شود، توصیف‌کننده فایل مورد استفاده برای خروجی استاندارد برای خروجی خطا تکثیر می‌شود، در حالی که
\fBfd:\fR\fB\fIname\fR\fR
از نام توصیف‌کننده فایل پیش‌فرض
"stderr"
استفاده خواهد کرد\&.
.sp
این تنظیم پیش‌فرض روی مقدار تعیین‌شده با
\fIDefaultStandardError=\fR
در
\fBsystemd-system.conf\fR(5)
قرار می‌گیرد که پیش‌فرض آن
\fBinherit\fR
است\&. توجه داشته باشید که تنظیم این پارامتر ممکن است منجر به اضافه شدن وابستگی‌های اضافی به واحد شود (به بالا مراجعه کنید)\&.
.RE
.PP
\fIStandardInputText=\fR، \fIStandardInputData=\fR
.RS 4
داده‌های متنی یا دودویی دلخواه را برای انتقال از طریق توصیف‌کننده فایل 0 (STDIN) به فرآیندهای اجراشده پیکربندی می‌کند\&. این تنظیمات هیچ اثری ندارند مگر اینکه
\fIStandardInput=\fR
روی
\fBdata\fR
تنظیم شده باشد (که اگر
\fIStandardInput=\fR
به روش دیگری تنظیم نشده باشد، اما
\fIStandardInputText=\fR/\fIStandardInputData=\fR
تنظیم شده باشد، پیش‌فرض است)\&. از این گزینه برای گنجاندن مستقیم داده‌های ورودی فرآیند در فایل واحد استفاده کنید\&.
.sp
تنظیم
\fIStandardInputText=\fR
داده‌های متنی دلخواه را می‌پذیرد\&. توالی‌های گریز به سبک C برای نویسه‌های خاص و همچنین تعیین‌کننده‌های معمول "%" حل‌وفصل می‌شوند\&. هر بار که از این تنظیم استفاده می‌شود، متن مشخص‌شده به بافر داده به ازای هر واحد اضافه می‌شود، به همراه یک نویسه خط جدید (بنابراین هر استفاده یک خط جدید را به انتهای بافر اضافه می‌کند)\&. توجه داشته باشید که فاصله‌های خالی ابتدا و انتهای خطوط پیکربندی‌شده با این گزینه حذف می‌شوند\&. اگر یک خط خالی مشخص شود، بافر پاک می‌شود (بنابراین، برای درج یک خط خالی، یک
"\en"
اضافی به ابتدا یا انتهای یک خط اضافه کنید)\&.
.sp
تنظیم
\fIStandardInputData=\fR
داده‌های باینری دلخواه را که با
\m[blue]\fBBase64\fR\m[]\&\s-2\u[15]\d\s+2
کدگذاری شده‌اند می‌پذیرد\&. هیچ توالی گریز یا تعیین‌کننده‌ای حل‌وفصل نمی‌شود\&. هرگونه فضای خالی در نسخه کدگذاری‌شده هنگام رمزگشایی نادیده گرفته می‌شود\&.
.sp
توجه داشته باشید که
\fIStandardInputText=\fR
و
\fIStandardInputData=\fR
روی یک بافر داده یکسان عمل می‌کنند و ممکن است برای پیکربندی هر دو داده باینری و متنی برای یک جریان ورودی یکسان ترکیب شوند\&. داده‌های متنی یا باینری دقیقاً به ترتیبی که تنظیمات در فایل واحد ظاهر می‌شوند به هم متصل می‌گردند\&. اختصاص یک رشته خالی به هر یک، بافر داده را بازنشانی می‌کند\&.
.sp
لطفاً به خاطر داشته باشید که به منظور حفظ خوانایی، تنظیمات طولانی فایل واحد ممکن است با پسوندگذاری هر خط (به جز خط آخر) با یک نویسه
"\e"
به چندین خط تقسیم شوند (برای جزئیات به
\fBsystemd.unit\fR(5)
مراجعه کنید)\&. این امر به‌ویژه برای داده‌های بزرگ پیکربندی‌شده با این دو گزینه مفید است\&. مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
\&...
StandardInput=data
StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZXMgYW5kIHNvIGRv \e
                  IEkKQSBmdWxsIGNvbW1pdG1lbnQncyB3aGF0IEnigLJtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4n \e
                  dCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJ \e
                  J20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCgpOZXZlciBnb25uYSBnaXZlIHlv \e
                  dSB1cApOZXZlciBnb25uYSBsZXQgeW91IGRvd24KTmV2ZXIgZ29ubmEgcnVuIGFyb3VuZCBhbmQg \e
                  ZGVzZXJ0IHlvdQpOZXZlciBnb25uYSBtYWtlIHlvdSBjcnkKTmV2ZXIgZ29ubmEgc2F5IGdvb2Ri \e
                  eWUKTmV2ZXIgZ29ubmEgdGVsbCBhIGxpZSBhbmQgaHVydCB5b3UK
\&...
.fi
.if n \{\
.RE
.\}
.sp
اضافه‌شده در نسخه 236\&.
.RE
.PP
\fILogLevelMax=\fR
.RS 4
فیلتر کردن بر اساس سطح لاگ پیام‌های لاگ تولیدشده توسط این واحد را پیکربندی می‌کند\&. یک سطح لاگ
\fBsyslog\fR
را می‌پذیرد که یکی از موارد زیر است:
\fBemerg\fR
(پایین‌ترین سطح لاگ، فقط پیام‌های با بالاترین اولویت)،
\fBalert\fR،
\fBcrit\fR،
\fBerr\fR،
\fBwarning\fR،
\fBnotice\fR،
\fBinfo\fR،
\fBdebug\fR
(بالاترین سطح لاگ، همچنین پیام‌های با کمترین اولویت)\&. برای جزئیات به
\fBsyslog\fR(3)
مراجعه کنید\&. به طور پیش‌فرض هیچ فیلتری اعمال نمی‌شود (یعنی حداکثر سطح لاگ پیش‌فرض
\fBdebug\fR
است)\&. از این گزینه برای پیکربندی سیستم لاگ‌گیری جهت نادیده گرفتن پیام‌های لاگ یک سرویس خاص بالاتر از سطح مشخص‌شده استفاده کنید\&. برای مثال،
\fILogLevelMax=\fR\fBinfo\fR
را تنظیم کنید تا ثبت لاگ‌های اشکال‌زدایی (debug) یک واحد بسیار پرحرف خاموش شود\&. توجه داشته باشید که سطح پیکربندی‌شده برای هر پیام لاگی که توسط هر یک از فرآیندهای متعلق به این واحد نوشته شده است، و همچنین هر پیام لاگی که توسط فرآیند مدیر سیستم (PID 1) در رابطه با این واحد نوشته شده و از طریق هر پروتکل لاگ‌گیری پشتیبانی‌شده ارسال شده باشد اعمال می‌شود\&. فیلتر کردن در مراحل اولیه خط لوله لاگ‌گیری اعمال می‌شود، قبل از اینکه هر نوع پردازش دیگری انجام شود\&. علاوه بر این، پیام‌هایی که با موفقیت از این فیلتر عبور می‌کنند ممکن است همچنان توسط فیلترهای اعمال‌شده در مرحله بعدی در زیرسیستم لاگ‌گیری حذف شوند\&. به عنوان مثال،
\fIMaxLevelStore=\fR
پیکربندی‌شده در
\fBjournald.conf\fR(5)
ممکن است از ذخیره پیام‌های با سطوح لاگ بالاتر روی دیسک جلوگیری کند، حتی اگر
\fILogLevelMax=\fR
به ازای هر واحد اجازه پردازش آن را داده باشد\&.
.sp
اضافه‌شده در نسخه 236\&.
.RE
.PP
\fILogExtraFields=\fR
.RS 4
فیلدهای متادیتای لاگ اضافی را برای گنجاندن در تمام رکوردهای لاگ تولیدشده توسط فرآیندهای مرتبط با این واحد، از جمله systemd پیکربندی می‌کند\&. این تنظیم یک یا چند انتساب فیلد ژورنال را در قالب
"FIELD=VALUE"
جداشده با فاصله می‌پذیرد\&. برای جزئیات در مورد مفهوم فیلد ژورنال به
\fBsystemd.journal-fields\fR(7)
مراجعه کنید\&. با وجود اینکه پیاده‌سازی زیربنایی ژورنال مقادیر باینری فیلد را مجاز می‌داند، این تنظیم فقط مقادیر معتبر UTF\-8 را می‌پذیرد\&. برای گنجاندن نویسه‌های فاصله در یک مقدار فیلد ژورنال، انتساب را در علامت نقل‌قول دوتایی (") قرار دهید\&.
تعیین‌کننده‌های معمول در تمام انتساب‌ها بسط داده می‌شوند (به زیر مراجعه کنید)\&. توجه داشته باشید که این تنظیم نه تنها برای پیوست کردن فراداده‌های اضافی به رکوردهای لاگ یک واحد مفید است، بلکه با توجه به اینکه همه فیلدها و مقادیر ایندکس شده‌اند، ممکن است برای پیاده‌سازی تطابق رکوردهای لاگ بین واحدهای مختلف نیز استفاده شود\&. برای بازنشانی فهرست، یک رشته خالی اختصاص دهید\&.
.sp
توجه داشته باشید که این عملکرد در حال حاضر فقط در سرویس‌های سیستمی در دسترس است، نه در سرویس‌های کاربر-محور\&.
.sp
اضافه‌شده در نسخه 236\&.
.RE
.PP
\fILogRateLimitIntervalSec=\fR، \fILogRateLimitBurst=\fR
.RS 4
محدودیت نرخ (rate limiting) اعمال‌شده بر پیام‌های لاگ تولیدشده توسط این واحد را پیکربندی می‌کند\&. اگر در بازه زمانی تعریف‌شده توسط
\fILogRateLimitIntervalSec=\fR،
پیام‌های بیشتری نسبت به آنچه در
\fILogRateLimitBurst=\fR
مشخص شده است توسط یک سرویس لاگ شود، تمام پیام‌های بعدی در این بازه تا پایان بازه دور ریخته می‌شوند\&. پیامی درباره تعداد پیام‌های دور ریخته شده تولید می‌شود\&. مشخصات زمانی برای
\fILogRateLimitIntervalSec=\fR
ممکن است در واحدهای زیر مشخص شود: "s"، "min"، "h"، "ms"، "us"\&. برای جزئیات به
\fBsystemd.time\fR(7)
مراجعه کنید\&. تنظیمات پیش‌فرض توسط
\fIRateLimitIntervalSec=\fR
و
\fIRateLimitBurst=\fR
پیکربندی‌شده در
\fBjournald.conf\fR(5)
تنظیم می‌شوند\&. توجه داشته باشید که این فقط برای پیام‌های لاگی اعمال می‌شود که توسط زیرسیستم لاگ‌گیری پردازش می‌شوند، یعنی توسط
\fBsystemd-journald.service\fR(8)\&.
این بدان معناست که اگر stderr یک سرویس را مستقیماً از طریق
\fIStandardOutput=file:\&...\fR
یا یک تنظیم مشابه به یک فایل متصل کنید، محدودیت نرخ برای پیام‌هایی که به این روش نوشته می‌شوند اعمال نخواهد شد (اما برای پیام‌های تولیدشده از طریق
\fBsyslog\fR(3)
و توابع مشابه اعمال خواهد شد)\&.
.sp
اضافه‌شده در نسخه 240\&.
.RE
.PP
\fILogFilterPatterns=\fR
.RS 4
یک عبارت باقاعده گسترش‌یافته (extended regular expression) را برای فیلتر کردن پیام‌های لاگ بر اساس فیلد
\fIMESSAGE=\fR
پیام ساختاریافته تعریف می‌کند\&. اگر اولین نویسه الگو
"~"
باشد، ورودی‌های لاگ منطبق با الگو باید دور ریخته شوند\&. این گزینه یک الگوی منفرد را به عنوان آرگومان می‌پذیرد اما می‌تواند چندین بار برای ایجاد فهرستی از الگوهای مجاز و ردشده استفاده شود\&. اگر رشته خالی اختصاص یابد، فیلتر بازنشانی می‌شود و تمام انتساب‌های قبلی بی‌اثر خواهند بود\&.
.sp
از آنجا که نویسه
"~"
برای تعریف الگوهای ردشده استفاده می‌شود، باید با
"\ex7e"
جایگزین شود تا اجازه داده شود پیامی که با
"~"
شروع می‌شود ثبت گردد\&. برای مثال،
"~foobar"
الگویی منطبق بر
"foobar"
را به فهرست مسدود اضافه می‌کند، در حالی که
"\ex7efoobar"
الگویی منطبق بر
"~foobar"
را به فهرست مجاز اضافه می‌نماید\&.
.sp
پیام‌های لاگ ابتدا در برابر الگوهای ردشده (در صورت وجود) و سپس در برابر الگوهای مجاز (در صورت وجود) آزمایش می‌شوند\&. اگر یک پیام لاگ با هر یک از الگوهای ردشده مطابقت داشته باشد، بلافاصله بدون در نظر گرفتن الگوهای مجاز دور ریخته می‌شود\&. پیام‌های لاگ باقیمانده در برابر الگوهای مجاز آزمایش می‌شوند\&. پیام‌هایی که با هیچ یک از الگوهای مجاز مطابقت ندارند دور ریخته می‌شوند\&. اگر هیچ الگوی مجازی تعریف نشده باشد، تمام پیام‌ها مستقیماً پس از عبور از فیلترهای ردشده پردازش می‌شوند\&.
.sp
فیلتر کردن بر اساس واحدی است که
\fILogFilterPatterns=\fR
برای آن تعریف شده است، به این معنی که پیام‌های لاگ دریافتی از
\fBsystemd\fR(1)
درباره واحد در نظر گرفته نمی‌شوند\&. پیام‌های لاگ فیلترشده به دیمون‌های سنتی syslog، بافر لاگ هسته (kmsg)، کنسول systemd فوروارد نمی‌شوند و به عنوان پیام‌های سراسری (wall) برای تمام کاربران واردشده ارسال نمی‌گردند\&.
.sp
توجه داشته باشید که این عملکرد در حال حاضر فقط در سرویس‌های سیستمی در دسترس است، نه در سرویس‌های کاربر-محور\&.
.sp
اضافه‌شده در نسخه 253\&.
.RE
.PP
\fILogNamespace=\fR
.RS 4
فرآیندهای واحد را در فضای نام ژورنال مشخص‌شده اجرا می‌کند\&. یک رشته کوتاه تعریف‌شده توسط کاربر را که فضای نام را مشخص می‌کند می‌پذیرد\&. در صورت عدم استفاده، فرآیندهای سرویس در فضای نام ژورنال پیش‌فرض اجرا می‌شوند، یعنی جریان لاگ آن‌ها توسط
systemd\-journald\&.service
جمع‌آوری و پردازش می‌شود\&. اگر از این گزینه استفاده شود، هرگونه داده لاگ تولیدشده توسط فرآیندهای این واحد (صرف‌نظر از اینکه از طریق
\fBsyslog()\fR،
لاگ‌گیری بومی ژورنال یا لاگ‌گیری stdout/stderr باشد) توسط نمونه‌ای از الگوی واحد
systemd\-journald@\&.service
که فضای نام مشخص‌شده را مدیریت می‌کند جمع‌آوری و پردازش می‌شود\&. داده‌های لاگ در یک مخزن داده مستقل از مخزن داده فضای نام لاگ پیش‌فرض ذخیره می‌شوند\&. برای جزئیات در مورد فضاهای نام ژورنال به
\fBsystemd-journald.service\fR(8)
مراجعه کنید\&.
.sp
در لایه‌های درونی، فضاهای نام ژورنال از طریق فضاسازی نام اتصال لینوکس و پوشاندن دایرکتوری حاوی سوکت‌های مربوطه
\fBAF_UNIX\fR
که برای لاگ‌گیری استفاده می‌شوند در فضای نام اتصال واحد پیاده‌سازی می‌شوند\&. از آنجا که از فضاهای نام اتصال استفاده می‌شود، این تنظیم انتشار اتصالات از فرآیندهای واحد به میزبان را قطع می‌کند، مشابه نحوه کار
\fIReadOnlyPaths=\fR
و تنظیمات مشابه که در بالا شرح داده شد\&. بنابراین فضاهای نام ژورنال ممکن است برای سرویس‌هایی که نیاز به ایجاد نقاط اتصال روی میزبان دارند استفاده نشوند\&.
.sp
هنگامی که از این گزینه استفاده می‌شود، واحد به طور خودکار وابستگی‌های ترتیب و نیازمندی روی دو واحد سوکت مرتبط با نمونه
systemd\-journald@\&.service
کسب می‌کند تا قبل از راه‌اندازی واحد به طور خودکار ایجاد شوند\&. توجه داشته باشید که هنگامی که از این گزینه استفاده می‌شود، خروجی لاگ این سرویس در خروجی معمولی
\fBjournalctl\fR(1)
ظاهر نمی‌شود، مگر اینکه از گزینه
\fB\-\-namespace=\fR
استفاده شود\&.
.sp
این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 245\&.
.RE
.PP
\fISyslogIdentifier=\fR
.RS 4
نام فرآیند ("برچسب \fBsyslog\fR") را برای پیشوندگذاری خطوط لاگ ارسالی به سیستم لاگ‌گیری یا بافر لاگ هسته تنظیم می‌کند\&. در صورت عدم تنظیم، پیش‌فرض روی نام فرآیندِ فرآیند اجراشده قرار می‌گیرد\&. این گزینه فقط زمانی مفید است که
\fIStandardOutput=\fR
یا
\fIStandardError=\fR
روی
\fBjournal\fR
یا
\fBkmsg\fR
(یا روی همان تنظیمات در ترکیب با
\fB+console\fR)
تنظیم شده باشند و فقط برای پیام‌های لاگ نوشته‌شده در stdout یا stderr اعمال می‌شود\&.
.RE
.PP
\fISyslogFacility=\fR
.RS 4
شناسه بخش (facility)
\fBsyslog\fR
را برای استفاده در زمان لاگ‌گیری تنظیم می‌کند\&. یکی از مقادیر
\fBkern\fR،
\fBuser\fR،
\fBmail\fR،
\fBdaemon\fR،
\fBauth\fR،
\fBsyslog\fR،
\fBlpr\fR،
\fBnews\fR،
\fBuucp\fR،
\fBcron\fR،
\fBauthpriv\fR،
\fBftp\fR،
\fBlocal0\fR،
\fBlocal1\fR،
\fBlocal2\fR،
\fBlocal3\fR،
\fBlocal4\fR،
\fBlocal5\fR،
\fBlocal6\fR
یا
\fBlocal7\fR\&.
برای جزئیات به
\fBsyslog\fR(3)
مراجعه کنید\&. این گزینه فقط زمانی مفید است که
\fIStandardOutput=\fR
یا
\fIStandardError=\fR
روی
\fBjournal\fR
یا
\fBkmsg\fR
(یا همان تنظیمات در ترکیب با
\fB+console\fR)
تنظیم شده باشند، و فقط برای پیام‌های لاگ نوشته‌شده در stdout یا stderr اعمال می‌شود\&. پیش‌فرض
\fBdaemon\fR
است\&.
.RE
.PP
\fISyslogLevel=\fR
.RS 4
سطح لاگ پیش‌فرض
\fBsyslog\fR
را برای استفاده هنگام ثبت وقایع در سیستم لاگ‌گیری یا بافر لاگ هسته مشخص می‌کند\&. یکی از مقادیر
\fBemerg\fR،
\fBalert\fR،
\fBcrit\fR،
\fBerr\fR،
\fBwarning\fR،
\fBnotice\fR،
\fBinfo\fR،
\fBdebug\fR\&.
برای جزئیات به
\fBsyslog\fR(3)
مراجعه کنید\&. این گزینه فقط زمانی مفید است که
\fIStandardOutput=\fR
یا
\fIStandardError=\fR
روی
\fBjournal\fR
یا
\fBkmsg\fR
(یا روی همان تنظیمات در ترکیب با
\fB+console\fR)
تنظیم شده باشند، و فقط برای پیام‌های لاگ نوشته‌شده در stdout یا stderr اعمال می‌شود\&. توجه داشته باشید که خطوط جداگانه خروجی توسط فرآیندهای اجراشده ممکن است با یک سطح لاگ متفاوت پیشوندگذاری شوند که می‌تواند برای بازنویسی سطح لاگ پیش‌فرض مشخص‌شده در اینجا استفاده شود\&. تفسیر این پیشوندها ممکن است با
\fISyslogLevelPrefix=\fR
غیرفعال شود، به زیر مراجعه کنید\&. برای جزئیات، به
\fBsd-daemon\fR(3)
مراجعه کنید\&. پیش‌فرض
\fBinfo\fR
است\&.
.RE
.PP
\fISyslogLevelPrefix=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. در صورت true بودن و تنظیم
\fIStandardOutput=\fR
یا
\fIStandardError=\fR
روی
\fBjournal\fR
یا
\fBkmsg\fR
(یا روی همان تنظیمات در ترکیب با
\fB+console\fR)،
خطوط لاگ نوشته‌شده توسط فرآیند اجراشده که دارای پیشوند سطح لاگ هستند با همان سطح لاگ تنظیم‌شده اما با حذف پیشوند پردازش می‌شوند\&. در صورت تنظیم روی false، تفسیر این پیشوندها غیرفعال شده و خطوط لاگ‌شده به همان صورت منتقل می‌شوند\&. این فقط برای پیام‌های لاگ نوشته‌شده در stdout یا stderr اعمال می‌شود\&. برای جزئیات در مورد این پیشوندگذاری به
\fBsd-daemon\fR(3)
مراجعه کنید\&. پیش‌فرض true است\&.
.RE
.PP
\fITTYPath=\fR
.RS 4
گره دستگاه ترمینال را برای استفاده در صورتی که ورودی، خروجی یا خطای استاندارد به یک TTY متصل باشند تنظیم می‌کند (به بالا مراجعه کنید)\&. پیش‌فرض
/dev/console
است\&.
.RE
.PP
\fITTYReset=\fR
.RS 4
دستگاه ترمینال مشخص‌شده با
\fITTYPath=\fR
را قبل و بعد از اجرا بازنشانی می‌کند\&. این گزینه صفحه را پاک نمی‌کند (برای این منظور
\fITTYVTDisallocate=\fR
در زیر را ببینید)\&. پیش‌فرض
"no"
است\&.
.RE
.PP
\fITTYVHangup=\fR
.RS 4
ارتباط تمام کلاینت‌هایی را که دستگاه ترمینال مشخص‌شده با
\fITTYPath=\fR
را باز کرده‌اند، قبل و بعد از اجرا قطع می‌کند\&. پیش‌فرض
"no"
است\&.
.RE
.PP
\fITTYColumns=\fR، \fITTYRows=\fR
.RS 4
اندازه TTY مشخص‌شده با
\fITTYPath=\fR
را پیکربندی می‌کند\&. در صورت عدم تنظیم یا تنظیم روی رشته خالی، تلاش می‌شود ابعاد صفحه ترمینال از طریق توالی‌های ANSI بازیابی شود، و اگر این تلاش با شکست مواجه شود، پیش‌فرض‌های هسته (معمولاً 80x24) استفاده می‌شوند\&.
.sp
اضافه‌شده در نسخه 250\&.
.RE
.PP
\fITTYVTDisallocate=\fR
.RS 4
اگر دستگاه ترمینال مشخص‌شده با
\fITTYPath=\fR
یک ترمینال کنسول مجازی باشد، سعی می‌کند TTY را قبل و بعد از اجرا لغو تخصیص (deallocate) کند\&. این امر تضمین می‌کند که صفحه و بافر پیمایش به عقب (scrollback) پاک می‌شوند\&. اگر دستگاه ترمینال از هر نوع دیگری از TTY باشد، تلاشی برای پاک کردن صفحه از طریق توالی‌های ANSI انجام می‌شود\&. پیش‌فرض
"no"
است\&.
.RE
.SH "اطلاعات اعتبارسنجی (CREDENTIALS)"
.PP
\fILoadCredential=\fR\fIID\fR[:\fIPATH\fR]، \fILoadCredentialEncrypted=\fR\fIID\fR[:\fIPATH\fR]
.RS 4
یک فقره اطلاعات اعتبارسنجی (credential) را به واحد ارسال می‌کند\&. اطلاعات اعتبارسنجی اشیاء دودویی یا متنی با اندازه محدود هستند که ممکن است به فرآیندهای واحد ارسال شوند\&. آن‌ها در درجه اول برای انتقال کلیدهای رمزنگاری (هم عمومی و هم خصوصی) یا گواهی‌ها، اطلاعات حساب کاربری یا اطلاعات هویتی از میزبان به سرویس‌ها استفاده می‌شوند\&. این داده‌ها از طریق سیستم‌فایل، در یک مکان فقط‌خواندنی که (در صورت امکان و اجازه) توسط حافظه غیرقابل swap پشتیبانی می‌شود، برای فرآیندهای واحد قابل دسترسی هستند\&. داده‌ها فقط برای کاربر مرتبط با واحد، از طریق تنظیمات
\fIUser=\fR/\fIDynamicUser=\fR
(و همچنین کاربر ارشد) قابل دسترسی هستند\&. در صورت در دسترس بودن، مکان اطلاعات اعتبارسنجی به عنوان متغیر محیطی
\fI$CREDENTIALS_DIRECTORY\fR
به فرآیندهای واحد صادر می‌شود\&.
.sp
تنظیم
\fILoadCredential=\fR
یک شناسه متنی را برای استفاده به عنوان نام برای اعتبارنامه به اضافه یک مسیر سیستم‌فایل، جداشده با دونقطه می‌پذیرد\&. شناسه باید یک رشته کوتاه ASCII مناسب به عنوان نام فایل در سیستم‌فایل باشد، و ممکن است آزادانه توسط کاربر انتخاب شود\&. اگر مسیر مشخص‌شده مطلق باشد، به عنوان یک فایل معمولی باز می‌شود و داده‌های اعتبارنامه از آن خوانده می‌شود\&. اگر مسیر مطلق به یک سوکت جریانی
\fBAF_UNIX\fR
در سیستم‌فایل اشاره کند، اتصالی به آن برقرار می‌شود (فقط یک بار در زمان شروع واحد) و داده‌های اعتبارنامه از اتصال خوانده می‌شود، که یک نقطه یکپارچه‌سازی آسان IPC را برای انتقال پویای داده‌های اعتبارنامه از سایر سرویس‌ها فراهم می‌کند\&.
.sp
اگر مسیر مشخص‌شده مطلق نباشد و خود به عنوان شناسه معتبر اعتبارنامه واجد شرایط باشد، تلاش می‌شود یک اعتبارنامه که خود مدیر سرویس تحت نام مشخص‌شده دریافت کرده است پیدا شود \(em که ممکن است برای انتشار اعتبارنامه‌ها از یک محیط فراخواننده (مانند یک مدیر کانتینر که مدیر سرویس را فراخوانده است) به درون یک سرویس استفاده شود\&. اگر هیچ اعتبارنامه سیستمی منطبقی یافت نشود، دایرکتوری‌های
/etc/credstore/،
/run/credstore/
و
/usr/lib/credstore/
برای یافتن فایل‌هایی تحت نام اعتبارنامه جستجو می‌شوند \(em که از این رو مکان‌های توصیه‌شده برای داده‌های اعتبارنامه روی دیسک هستند\&. اگر از
\fILoadCredentialEncrypted=\fR
استفاده شود، دایرکتوری‌های
/run/credstore\&.encrypted/،
/etc/credstore\&.encrypted/
و
/usr/lib/credstore\&.encrypted/
نیز جستجو می‌شوند\&.
.sp
اگر مسیر سیستم‌فایل حذف شود، همانند نام اعتبارنامه انتخاب می‌شود، یعنی این روشی مختصر برای اعلام اعتبارنامه‌ها برای به ارث بردن از مدیر سرویس به درون یک سرویس است\&. این گزینه ممکن است چندین بار استفاده شود، که هر بار یک اعتبارنامه اضافی را برای ارسال به واحد تعریف می‌کند\&.
.sp
توجه داشته باشید که اگر مسیر مشخص نشده باشد یا یک شناسه معتبر اعتبارنامه داده شده باشد، یعنی در دو حالت فوق، نبود یک اعتبارنامه خطای مرگبار تلقی نمی‌شود\&.
.sp
اگر یک مسیر مطلق اشاره‌کننده به یک دایرکتوری مشخص شود، هر فایلی در آن دایرکتوری (به صورت بازگشتی) به عنوان یک اعتبارنامه جداگانه بارگذاری خواهد شد\&. شناسه هر اعتبارنامه، شناسه ارائه‌شده به همراه پسوند
"_$FILENAME"
خواهد بود (به عنوان مثال
"Key_file1")\&.
هنگام بارگذاری از یک دایرکتوری، پیوندهای نمادین نادیده گرفته می‌شوند\&.
.sp
محتوای فایل/سوکت ممکن است داده‌های دودویی یا متنی دلخواه باشد، از جمله نویسه‌های خط جدید و بایت‌های
\fBNUL\fR\&.
.sp
تنظیم
\fILoadCredentialEncrypted=\fR
مشابه
\fILoadCredential=\fR
است، به جز اینکه داده‌های اعتبارنامه قبل از ارسال به فرآیندهای اجراشده رمزگشایی و احراز اصالت می‌شوند\&. به طور خاص، مسیر ارجاع‌شده باید به یک فایل یا سوکت با اعتبارنامه رمزگذاری‌شده اشاره کند، همان‌طور که توسط
\fBsystemd-creds\fR(1)
پیاده‌سازی شده است\&. این اعتبارنامه بارگذاری، رمزگشایی، احراز اصالت شده و سپس به همان روشی که یک اعتبارنامه معمولی مشخص‌شده از طریق
\fILoadCredential=\fR
ارسال می‌شود، به شکل متن ساده به برنامه ارسال می‌گردد\&. اعتبارنامه‌ای که به این روش پیکربندی شده است ممکن است با یک کلید مخفی مشتق‌شده از تراشه امنیتی TPM2 سیستم، یا با یک کلید مخفی ذخیره‌شده در
/var/lib/systemd/credentials\&.secret،
یا با هر دو به صورت متقارن رمزگذاری/احراز اصالت شود\&. استفاده از اعتبارنامه‌های رمزگذاری‌شده و احراز اصالت‌شده امنیت را بهبود می‌بخشد زیرا اعتبارنامه‌ها به صورت متن ساده ذخیره نمی‌شوند و تنها در لحظه‌ای که سرویس نیازمند به آن‌ها شروع به کار می‌کند احراز اصالت شده و به متن ساده رمزگشایی می‌شوند\&. علاوه بر این، اعتبارنامه‌ها ممکن است به سخت‌افزار و نصب‌های محلی متصل شوند، به طوری که نتوان آن‌ها را به راحتی به صورت آفلاین تجزیه و تحلیل کرد یا به صورت خارجی تولید نمود\&. هنگامی که
\fIDevicePolicy=\fR
روی
"closed"
یا
"strict"
تنظیم شده باشد، یا روی
"auto"
تنظیم شده و
\fIDeviceAllow=\fR
تنظیم شده باشد، یا
\fIPrivateDevices=\fR
تنظیم شده باشد، این تنظیم
/dev/tpmrm0
را با حالت
\fBrw\fR
به
\fIDeviceAllow=\fR
اضافه می‌کند\&. برای جزئیات درباره
\fIDevicePolicy=\fR
یا
\fIDeviceAllow=\fR
به
\fBsystemd.resource-control\fR(5)
مراجعه کنید\&.
.sp
توجه داشته باشید که اعتبارنامه‌های رمزگذاری‌شده که برای سرویس‌های مدیر سرویس کاربر-محور در نظر گرفته شده‌اند باید با
\fBsystemd\-creds encrypt \-\-user\fR
رمزگذاری شوند، و موارد مربوط به مدیر سرویس سیستم بدون سوئیچ
\fB\-\-user\fR
رمزگذاری شوند\&. اعتبارنامه‌های رمزگذاری‌شده همیشه یک کاربر خاص یا کل سیستم را هدف قرار می‌دهند، و این اطمینان حاصل می‌شود که مدیران سرویس کاربر نمی‌توانند اسرار در نظر گرفته‌شده برای سیستم یا سایر کاربران را رمزگشایی کنند\&.
.sp
فایل‌های اعتبارنامه/سوکت‌های IPC باید برای مدیر سرویس قابل دسترسی باشند، اما لازم نیست مستقیماً برای فرآیندهای واحد قابل دسترسی باشند: داده‌های اعتبارنامه خوانده شده و در نسخه‌های جداگانه و فقط‌خواندنی برای واحد کپی می‌شوند که برای فرآیندهای با امتیاز مناسب قابل دسترسی هستند\&. این امر به‌ویژه در ترکیب با
\fIDynamicUser=\fR
مفید است، زیرا از این طریق می‌توان داده‌های دارای امتیاز را در دسترس فرآیندهایی قرار داد که تحت یک UID پویا (یعنی نه یک UID شناخته‌شده از قبل) اجرا می‌شوند، بدون اینکه نیازی به باز کردن دسترسی برای همه کاربران باشد\&.
.sp
به منظور ارجاع به مسیری که یک اعتبارنامه ممکن است از داخل یک خط فرمان
\fIExecStart=\fR
خوانده شود، از
"${CREDENTIALS_DIRECTORY}/mycred"
استفاده کنید، مانند
"ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred"\&.
به منظور ارجاع به مسیری که یک اعتبارنامه ممکن است از داخل یک خط
\fIEnvironment=\fR
خوانده شود، از
"%d/mycred"
استفاده کنید، مانند
"Environment=MYCREDPATH=%d/mycred"\&.
برای سرویس‌های سیستمی در مواردی که هیچ جایگذاری امکان‌پذیر نیست (مثلاً فایل‌های پیکربندی نرم‌افزاری که هنوز به صورت بومی از اعتبارنامه‌ها پشتیبانی نمی‌کند)، مسیر ممکن است به عنوان
"/run/credentials/\fIUNITNAME\fR"
نیز ارجاع داده شود\&. با این حال،
\fI$CREDENTIALS_DIRECTORY\fR
رابط اصلی برای جستجوی اعتبارنامه‌ها در نظر گرفته می‌شود، زیرا برای سرویس‌های کاربری نیز کار می‌کند\&.
.sp
در حال حاضر، محدودیت اندازه کل انباشته اعتبارنامه به میزان 1 مگابایت به ازای هر واحد اعمال می‌شود\&.
.sp
خود مدیر سرویس ممکن است اعتبارنامه‌های سیستمی را دریافت کند که می‌توانند از یک مدیر کانتینر میزبان یا هایپروایزر ماشین مجازی به سرویس‌ها منتشر شوند\&. برای جزئیات در مورد مورد اول، مستندات
\m[blue]\fBContainer Interface\fR\m[]\&\s-2\u[16]\d\s+2
را ببینید\&. برای مورد دوم، ورودی‌های جدول رشته OEM در
\m[blue]\fBDMI/SMBIOS\fR\m[]\&\s-2\u[17]\d\s+2
(نوع فیلد 11) را با پیشوند
"io\&.systemd\&.credential:"
یا
"io\&.systemd\&.credential\&.binary:"
ارسال کنید\&. در هر دو حالت یک جفت کلید/مقدار جداشده با
"="
انتظار می‌رود؛ در حالت دوم سمت راست هنگام تجزیه Base64 رمزگشایی می‌شود (بنابراین اجازه می‌دهد داده‌های دودویی ارسال شوند)\&. سوئیچ مثال
\m[blue]\fBqemu\fR\m[]\&\s-2\u[18]\d\s+2:
"\-smbios type=11,value=io\&.systemd\&.credential:xx=yy"، یا
"\-smbios type=11,value=io\&.systemd\&.credential\&.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA="\&.
به عنوان روش جایگزین، از گره
"fw_cfg"
در
\fBqemu\fR
به صورت
"opt/io\&.systemd\&.credentials/"
استفاده کنید\&. سوئیچ مثال
\fBqemu\fR:
"\-fw_cfg name=opt/io\&.systemd\&.credentials/mycred,string=supersecret"\&.
آن‌ها همچنین ممکن است از محیط سفت‌افزار UEFI از طریق
\fBsystemd-stub\fR(7)،
از initrd (به
\fBsystemd\fR(1)
مراجعه کنید)، یا در خط فرمان هسته با استفاده از سوئیچ‌های
"systemd\&.set_credential="
و
"systemd\&.set_credential_binary="
مشخص شوند (به
\fBsystemd\fR(1)
مراجعه کنید \(em این مورد توصیه نمی‌شود زیرا فضای کاربری بدون امتیاز می‌تواند خط فرمان هسته را بخواند)\&.
.sp
در صورت ارجاع به یک سوکت جریانی
\fBAF_UNIX\fR
برای اتصال، اتصال از یک سوکت فضای نام انتزاعی سرچشمه می‌گیرد که شامل اطلاعاتی درباره واحد و شناسه اعتبارنامه در نام سوکت خود است\&. از
\fBgetpeername\fR(2)
برای پرس‌وجوی این اطلاعات استفاده کنید\&. نام سوکت بازگردانده‌شده به صورت
\fBNUL\fR
\fIRANDOM\fR
"/unit/"
\fIUNIT\fR
"/"
\fIID\fR
قالب‌بندی می‌شود، یعنی یک بایت
\fBNUL\fR
(همان‌طور که برای نام‌های سوکت فضای نام انتزاعی لازم است)، به دنبال آن یک رشته تصادفی (شامل نویسه‌های الفبایی-عددی)، به دنبال آن رشته لغوی
"/unit/"،
به دنبال آن نام واحد درخواست‌کننده، به دنبال آن نویسه لغوی
"/"،
به دنبال آن شناسه متنی اعتبارنامه درخواستی\&. مثال:
"\e0adf9d86b6eda275e/unit/foobar\&.service/credx"
در صورتی که اعتبارنامه
"credx"
برای یک واحد
"foobar\&.service"
درخواست شده باشد\&. این عملکرد برای استفاده از یک سوکت شنیداری منفرد برای ارائه اعتبارنامه‌ها به چندین مصرف‌کننده مفید است\&.
.sp
برای اطلاعات بیشتر، مستندات
\m[blue]\fBSystem and Service Credentials\fR\m[]\&\s-2\u[19]\d\s+2
را ببینید\&.
.sp
اضافه‌شده در نسخه 247\&.
.RE
.PP
\fIImportCredential=\fR\fIGLOB\fR
.RS 4
یک یا چند اعتبارنامه را به واحد ارسال می‌کند\&. یک نام اعتبارنامه را می‌پذیرد که برای آن تلاش خواهیم کرد اعتبارنامه‌ای را که خود مدیر سرویس تحت نام مشخص‌شده دریافت کرده است پیدا کنیم \(em که ممکن است برای انتشار اعتبارنامه‌ها از یک محیط فراخواننده (مانند یک مدیر کانتینر که مدیر سرویس را فراخوانده است) به درون یک سرویس استفاده شود\&. اگر نام اعتبارنامه یک glob باشد، تمام اعتبارنامه‌های منطبق بر glob به واحد ارسال می‌شوند\&. اعتبارنامه‌های منطبق به ترتیب در اعتبارنامه‌های سیستم، اعتبارنامه‌های رمزگذاری‌شده سیستم، و در زیر
/etc/credstore/،
/run/credstore/،
/usr/lib/credstore/،
/run/credstore\&.encrypted/،
/etc/credstore\&.encrypted/
و
/usr/lib/credstore\&.encrypted/
جستجو می‌شوند\&. هنگامی که چندین اعتبارنامه با همان نام پیدا شود، از اولین مورد یافت‌شده استفاده می‌شود\&.
.sp
عبارت globbing زیرمجموعه محدودی از
\fBglob\fR(7)
را پیاده‌سازی می‌کند: فقط یک نویسه عام پایانی
"*"
ممکن است مشخص شود\&. هر دو نویسه عام
"?"
و
"[]"
مجاز نیستند، و نویسه عام
"*"
نیز در هیچ جایی به جز انتهای عبارت glob مجاز نیست\&.
.sp
به صورت اختیاری، نام یا الگوی اعتبارنامه ممکن است با یک دونقطه و سپس یک الگوی تغییر نام همراه باشد\&. در صورت مشخص شدن، تمام اعتبارنامه‌های منطبق بر نام اعتبارنامه یا glob طبق الگوی ارائه‌شده تغییر نام می‌یابند\&. برای مثال، اگر
"ImportCredential=my\&.original\&.cred:my\&.renamed\&.cred"
مشخص شود، مدیر سرویس اعتبارنامه
"my\&.original\&.cred"
را خوانده و آن را به عنوان اعتبارنامه
"my\&.renamed\&.cred"
در دسترس سرویس قرار می‌دهد\&. مشابهاً، اگر
"ImportCredential=my\&.original\&.*:my\&.renamed\&."
مشخص شود، مدیر سرویس تمام اعتبارنامه‌هایی را که با
"my\&.original\&."
شروع می‌شوند خوانده و آن‌ها را به عنوان
"my\&.renamed\&.xxx"
در دسترس سرویس قرار می‌دهد\&.
.sp
اگر
\fIImportCredential=\fR
چندین بار مشخص شود و چندین اعتبارنامه پس از تغییر نام با نام یکسانی خاتمه یابند، اولین مورد حفظ شده و موارد بعدی حذف می‌شوند\&.
.sp
هنگامی که چندین اعتبارنامه با همان نام یافت شوند، اعتبارنامه‌های یافت‌شده توسط
\fILoadCredential=\fR
و
\fILoadCredentialEncrypted=\fR
بر اعتبارنامه‌های یافت‌شده توسط
\fIImportCredential=\fR
اولویت دارند\&.
.sp
اضافه‌شده در نسخه 254\&.
.RE
.PP
\fISetCredential=\fR\fIID\fR:\fIVALUE\fR، \fISetCredentialEncrypted=\fR\fIID\fR:\fIVALUE\fR
.RS 4
تنظیم
\fISetCredential=\fR
مشابه
\fILoadCredential=\fR
است اما یک مقدار لغوی (literal) را برای استفاده به عنوان داده برای اعتبارنامه می‌پذیرد، به جای یک مسیر سیستم‌فایل برای خواندن داده‌ها از آن\&. از این گزینه برای داده‌هایی که قرار است محرمانه باشند استفاده نکنید، زیرا از طریق IPC برای فرآیندهای بدون امتیاز قابل دسترسی است\&. استفاده از این گزینه فقط برای شناسه‌های کاربری، محتوای کلید عمومی و داده‌های غیرحساس مشابه ایمن است\&. برای هر چیز دیگری از
\fILoadCredential=\fR
استفاده کنید\&. به منظور گنجاندن داده‌های باینری در داده‌های اعتبارنامه از توالی‌های گریز به سبک C استفاده کنید (یعنی
"\en"
برای درج خط جدید، یا
"\ex00"
برای درج بایت
\fBNUL\fR)\&.
.sp
تنظیم
\fISetCredentialEncrypted=\fR
مشابه
\fISetCredential=\fR
است اما یک اعتبارنامه رمزگذاری‌شده را به شکل لغوی به عنوان مقدار انتظار دارد\&. این امر اجازه می‌دهد اعتبارنامه‌های محرمانه مستقیماً در فایل‌های واحد به صورت ایمن تعبیه شوند\&. از سوئیچ
\fB\-p\fR
در
\fBsystemd-creds\fR(1)
برای تولید مستقیم خطوط مناسب
\fISetCredentialEncrypted=\fR
از اعتبارنامه‌های متن ساده استفاده کنید\&. برای جزئیات بیشتر به
\fILoadCredentialEncrypted=\fR
در بالا مراجعه کنید\&.
.sp
هنگامی که چندین اعتبارنامه با همان نام یافت شوند، اعتبارنامه‌های یافت‌شده توسط
\fILoadCredential=\fR،
\fILoadCredentialEncrypted=\fR
و
\fIImportCredential=\fR
بر اعتبارنامه‌های یافت‌شده توسط
\fISetCredential=\fR
اولویت دارند\&. به این ترتیب، اگر هیچ اعتبارنامه‌ای توسط هیچ یک از موارد قبلی یافت نشود،
\fISetCredential=\fR
به عنوان پیش‌فرض عمل خواهد کرد\&. در این حالت، عدم امکان بازیابی اعتبارنامه از مسیر مشخص‌شده در
\fILoadCredential=\fR
یا
\fILoadCredentialEncrypted=\fR
خطای مرگبار تلقی نمی‌شود\&.
.sp
اضافه‌شده در نسخه 247\&.
.RE
.SH "سازگاری با System V (SYSTEM V COMPATIBILITY)"
.PP
\fIUtmpIdentifier=\fR
.RS 4
یک رشته شناسه چهارنویسه‌ای را برای یک ورودی
\fButmp\fR(5)
و wtmp برای این سرویس می‌پذیرد\&. این گزینه فقط باید برای سرویس‌هایی مانند پیاده‌سازی‌های
\fBgetty\fR
(مانند
\fBagetty\fR(8))
تنظیم شود که در آن‌ها ورودی‌های utmp/wtmp باید قبل و بعد از اجرا ایجاد و پاک شوند، یا برای سرویس‌هایی که باید طوری اجرا شوند که گویی توسط یک فرآیند
\fBgetty\fR
اجرا شده‌اند (به زیر مراجعه کنید)\&. اگر رشته پیکربندی‌شده طولانی‌تر از چهار نویسه باشد، کوتاه شده و چهار نویسه انتهایی استفاده می‌شوند\&. این تنظیم جایگزینی‌های رشته‌ای به سبک %I را تفسیر می‌کند\&. این تنظیم به طور پیش‌فرض تنظیم نشده است، یعنی هیچ ورودی utmp/wtmp برای این سرویس ایجاد یا پاک نمی‌شود\&.
.RE
.PP
\fIUtmpMode=\fR
.RS 4
یکی از مقادیر
"init"،
"login"
یا
"user"
را می‌پذیرد\&. اگر
\fIUtmpIdentifier=\fR
تنظیم شده باشد، کنترل می‌کند که کدام نوع از ورودی‌های
\fButmp\fR(5)/wtmp
برای این سرویس تولید شوند\&. این تنظیم هیچ اثری ندارد مگر اینکه
\fIUtmpIdentifier=\fR
نیز تنظیم شده باشد\&. اگر روی
"init"
تنظیم شود، فقط یک ورودی
\fBINIT_PROCESS\fR
تولید می‌شود و فرآیند فراخوانده‌شده باید یک منطق utmp/wtmp سازگار با
\fBgetty\fR
را پیاده‌سازی کند\&. اگر روی
"login"
تنظیم شود، ابتدا یک ورودی
\fBINIT_PROCESS\fR
و سپس یک ورودی
\fBLOGIN_PROCESS\fR
تولید می‌شود\&. در این حالت، فرآیند فراخوانده‌شده باید یک منطق utmp/wtmp سازگار با
\fBlogin\fR(1)
را پیاده‌سازی کند\&. اگر روی
"user"
تنظیم شود، ابتدا یک ورودی
\fBINIT_PROCESS\fR،
سپس یک ورودی
\fBLOGIN_PROCESS\fR
و در نهایت یک ورودی
\fBUSER_PROCESS\fR
تولید می‌شود\&. در این حالت، فرآیند فراخوانده‌شده می‌تواند هر فرآیندی باشد که برای اجرا به عنوان رهبر نشست (session leader) مناسب است\&. پیش‌فرض
"init"
است\&.
.sp
اضافه‌شده در نسخه 225\&.
.RE
.SH "متغیرهای محیطی در فرآیندهای ایجادشده (ENVIRONMENT VARIABLES IN SPAWNED PROCESSES)"
.PP
فرآیندهایی که توسط مدیر سرویس شروع می‌شوند، با یک بلوک متغیر محیطی که از چندین منبع گردآوری شده است اجرا می‌گردند\&. فرآیندهایی که توسط مدیر سرویس سیستم شروع می‌شوند عموماً متغیرهای محیطی تنظیم‌شده برای خود مدیر سرویس را به ارث نمی‌برند (اما این مورد ممکن است از طریق
\fIPassEnvironment=\fR
تغییر کند)، اما فرآیندهایی که توسط نمونه‌های مدیر سرویس کاربر شروع می‌شوند عموماً تمام متغیرهای محیطی تنظیم‌شده برای خود مدیر سرویس را به ارث می‌برند\&.
.PP
برای هر فرآیند فراخوانده‌شده، فهرست متغیرهای محیطی تنظیم‌شده از منابع زیر گردآوری می‌شود:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
متغیرهایی که به صورت سراسری برای مدیر سرویس پیکربندی شده‌اند، با استفاده از تنظیم
\fIDefaultEnvironment=\fR
در
\fBsystemd-system.conf\fR(5)،
گزینه خط فرمان هسته
\fIsystemd\&.setenv=\fR
که توسط
\fBsystemd\fR(1)
فهمیده می‌شود، یا از طریق فعل
\fBset\-environment\fR
در
\fBsystemctl\fR(1)\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
متغیرهایی که توسط خود مدیر سرویس تعریف شده‌اند (فهرست زیر را ببینید)\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
متغیرهای تنظیم‌شده در بلوک متغیرهای محیطی خود مدیر سرویس (مشمول
\fIPassEnvironment=\fR
برای مدیر سرویس سیستم)\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
متغیرهای تنظیم‌شده از طریق
\fIEnvironment=\fR
در فایل واحد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
متغیرهای خوانده‌شده از فایل‌های مشخص‌شده از طریق
\fIEnvironmentFile=\fR
در فایل واحد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
متغیرهای تنظیم‌شده توسط هر یک از ماژول‌های PAM در صورتی که
\fIPAMName=\fR
در حال اجرا باشد، مقایسه کنید با
\fBpam_env\fR(8)\&.
.RE
.PP
اگر یک متغیر محیطی یکسان توسط چندین مورد از این منابع تنظیم شود، منبع بعدی \(em طبق ترتیب فهرست بالا \(em برنده خواهد شد\&. توجه داشته باشید که به عنوان مرحله نهایی، تمام متغیرهای فهرست‌شده در
\fIUnsetEnvironment=\fR
دقیقاً قبل از ارسال فهرست متغیرهای محیطی گردآوری‌شده به فرآیند اجراشده، از آن حذف می‌شوند\&.
.PP
فلسفه کلی این است که فهرست گزینش‌شده و کوچکی از متغیرهای محیطی در دسترس فرآیندها قرار گیرد\&. سرویس‌هایی که توسط مدیر سیستم (PID 1) شروع می‌شوند، بدون پیکربندی اضافی مخصوص سرویس، فقط با چند متغیر محیطی راه‌اندازی خواهند شد\&. مدیر کاربر متغیرهای محیطی را مانند هر سرویس سیستمی دیگر به ارث می‌برد، اما علاوه بر آن ممکن است متغیرهای محیطی اضافی را از PAM و معمولاً متغیرهای واردشده اضافی را زمانی که کاربر یک نشست گرافیکی را شروع می‌کند دریافت کند\&. توصیه می‌شود بلوک‌های محیطی را در هر دو مدیر سیستم و کاربر کم‌حجم نگه دارید\&. وارد کردن تمام متغیرهای به ارث برده شده توسط نشست گرافیکی یا توسط یکی از شل‌های کاربر اکیداً توصیه نمی‌شود\&.
.PP
نکته:
\fBsystemd\-run \-P env\fR
و
\fBsystemd\-run \-\-user \-P env\fR
بلوک‌های محیطی مؤثر سرویس سیستم و کاربر را چاپ می‌کنند\&.
.SS "متغیرهای محیطی تنظیم یا منتقل‌شده توسط مدیر سرویس (Environment Variables Set or Propagated by the Service Manager)"
.PP
متغیرهای محیطی زیر توسط مدیر سرویس منتقل می‌شوند یا به صورت داخلی برای هر فرآیند فراخوانده‌شده تولید می‌گردند:
.PP
\fI$PATH\fR
.RS 4
فهرست جداشده با دونقطه از دایرکتوری‌ها برای استفاده در هنگام راه‌اندازی فایل‌های اجرایی\&.
\fBsystemd\fR
از مقدار ثابت
"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
در مدیر سیستم استفاده می‌کند\&. در مورد مدیر کاربر، ممکن است مسیر متفاوتی توسط توزیع پیکربندی شود\&. توصیه می‌شود به ترتیب ورودی‌ها تکیه نکنید، و فقط یک برنامه با نام مشخص در
\fI$PATH\fR
داشته باشید\&.
.sp
اضافه‌شده در نسخه 208\&.
.RE
.PP
\fI$LANG\fR
.RS 4
اطلاعات محلی (Locale)\&. می‌تواند در
\fBlocale.conf\fR(5)
یا در خط فرمان هسته تنظیم شود (به
\fBsystemd\fR(1)
و
\fBkernel-command-line\fR(7)
مراجعه کنید)\&.
.sp
اضافه‌شده در نسخه 208\&.
.RE
.PP
\fI$USER\fR، \fI$LOGNAME\fR، \fI$HOME\fR، \fI$SHELL\fR
.RS 4
نام کاربر (دو بار)، دایرکتوری خانگی و شل ورود به سیستم\&.
\fI$USER\fR
بدون قید و شرط تنظیم می‌شود، در حالی که
\fI$HOME\fR،
\fI$LOGNAME\fR
و
\fI$SHELL\fR
فقط برای واحدهایی تنظیم می‌شوند که
\fIUser=\fR
در آن‌ها تنظیم شده و
\fISetLoginEnvironment=\fR
تنظیم نشده یا روی true باشد\&. برای سرویس‌های کاربری، این متغیرها معمولاً از خود مدیر کاربر به ارث برده می‌شوند\&. به
\fBpasswd\fR(5)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 208\&.
.RE
.PP
\fI$INVOCATION_ID\fR
.RS 4
حاوی یک شناسه تصادفی و یکتای 128 بیتی است که هر چرخه زمان اجرای واحد را مشخص می‌کند و به عنوان رشته هگزادسیمال 32 نویسه‌ای قالب‌بندی شده است\&. هر بار که واحد از حالت غیرفعال به حالت در حال فعال‌سازی یا فعال تغییر می‌کند، یک شناسه جدید اختصاص می‌یابد و ممکن است برای شناسایی این چرخه زمان اجرای خاص، به ویژه در داده‌های ذخیره‌شده به صورت آفلاین، مانند ژورنال، استفاده شود\&. همان شناسه به تمام فرآیندهایی که به عنوان بخشی از واحد اجرا می‌شوند منتقل می‌گردد\&.
.sp
اضافه‌شده در نسخه 232\&.
.RE
.PP
\fI$XDG_RUNTIME_DIR\fR
.RS 4
دایرکتوری مورد استفاده برای اشیاء زمان اجرا (مانند اشیاء IPC) و وضعیت‌های ناپایدار (volatile)\&. برای تمام سرویس‌های اجراشده توسط نمونه کاربری
\fBsystemd\fR،
و همچنین هر سرویس سیستمی که از
\fIPAMName=\fR
همراه با یک پشته PAM شامل
\fBpam_systemd\fR
استفاده می‌کند تنظیم می‌شود\&. برای اطلاعات بیشتر به زیر و
\fBpam_systemd\fR(8)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 208\&.
.RE
.PP
\fI$RUNTIME_DIRECTORY\fR، \fI$STATE_DIRECTORY\fR، \fI$CACHE_DIRECTORY\fR، \fI$LOGS_DIRECTORY\fR، \fI$CONFIGURATION_DIRECTORY\fR
.RS 4
مسیرهای مطلق به دایرکتوری‌های تعریف‌شده با
\fIRuntimeDirectory=\fR،
\fIStateDirectory=\fR،
\fICacheDirectory=\fR،
\fILogsDirectory=\fR
و
\fIConfigurationDirectory=\fR
در صورت استفاده از آن تنظیمات\&.
.sp
اضافه‌شده در نسخه 244\&.
.RE
.PP
\fI$CREDENTIALS_DIRECTORY\fR
.RS 4
یک مسیر مطلق به دایرکتوری به ازای هر واحد با اعتبارنامه‌های پیکربندی‌شده از طریق
\fIImportCredential=\fR/\fILoadCredential=\fR/\fISetCredential=\fR\&.
دایرکتوری به صورت فقط‌خواندنی علامت‌گذاری شده و در حافظه غیرقابل swap (در صورت پشتیبانی و اجازه) قرار می‌گیرد، و فقط برای UID مرتبط با واحد از طریق
\fIUser=\fR
یا
\fIDynamicUser=\fR
(و کاربر ارشد) قابل دسترسی است\&.
.sp
اضافه‌شده در نسخه 247\&.
.RE
.PP
\fI$MAINPID\fR
.RS 4
شناسه فرآیند (PID) فرآیند اصلی واحد در صورتی که شناخته شده باشد\&. این فقط برای فرآیندهای کنترلی همان‌طور که توسط
\fIExecReload=\fR
و موارد مشابه فراخوانده می‌شوند تنظیم می‌گردد\&.
.sp
اضافه‌شده در نسخه 209\&.
.RE
.PP
\fI$MANAGERPID\fR
.RS 4
شناسه فرآیند (PID) نمونه کاربری
\fBsystemd\fR،
که برای فرآیندهای ایجادشده توسط آن تنظیم می‌شود\&.
.sp
اضافه‌شده در نسخه 208\&.
.RE
.PP
\fI$LISTEN_FDS\fR، \fI$LISTEN_PID\fR، \fI$LISTEN_FDNAMES\fR
.RS 4
اطلاعات مربوط به توصیف‌کننده‌های فایل ارسالی به یک سرویس برای فعال‌سازی سوکت\&. به
\fBsd_listen_fds\fR(3)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 208\&.
.RE
.PP
\fI$NOTIFY_SOCKET\fR
.RS 4
سوکتی که
\fBsd_notify()\fR
با آن صحبت می‌کند\&. به
\fBsd_notify\fR(3)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 229\&.
.RE
.PP
\fI$WATCHDOG_PID\fR، \fI$WATCHDOG_USEC\fR
.RS 4
اطلاعات درباره اعلان‌های زنده ماندن (keep\-alive) ناظر سگ نگهبان (watchdog)\&. به
\fBsd_watchdog_enabled\fR(3)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 229\&.
.RE
.PP
\fI$SYSTEMD_EXEC_PID\fR
.RS 4
شناسه فرآیند (PID) فرآیند واحد (مانند فرآیند فراخوانده‌شده توسط
\fIExecStart=\fR)\&.
فرآیند فرزند می‌تواند از این اطلاعات با مقایسه این مقدار با PID فعلی تعیین کند که آیا فرآیند مستقیماً توسط مدیر سرویس فراخوانده شده است یا به صورت غیرمستقیم به عنوان فرزند فرآیند دیگری فراخوانی شده است (مشابه طرح مورد استفاده در
\fBsd_listen_fds\fR(3)
با
\fI$LISTEN_PID\fR
و
\fI$LISTEN_FDS\fR)\&.
.sp
اضافه‌شده در نسخه 248\&.
.RE
.PP
\fI$TERM\fR
.RS 4
نوع ترمینال، فقط برای واحدهای متصل به ترمینال تنظیم می‌شود (\fIStandardInput=tty\fR،
\fIStandardOutput=tty\fR
یا
\fIStandardError=tty\fR)\&.
به
\fBtermcap\fR(5)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 209\&.
.RE
.PP
\fI$LOG_NAMESPACE\fR
.RS 4
حاوی نام فضای نام لاگ‌گیری انتخاب‌شده در هنگام استفاده از تنظیم سرویس
\fILogNamespace=\fR
است\&.
.sp
اضافه‌شده در نسخه 246\&.
.RE
.PP
\fI$JOURNAL_STREAM\fR
.RS 4
اگر خروجی استاندارد یا خروجی خطای استاندارد فرآیندهای اجراشده به ژورنال متصل باشد (به عنوان مثال، با تنظیم
\fIStandardError=journal\fR)،
\fI$JOURNAL_STREAM\fR
حاوی شماره‌های دستگاه و inode توصیف‌کننده فایل اتصال است که به صورت ده‌دهی قالب‌بندی شده و با یک دونقطه (":") از هم جدا شده‌اند\&. این به فرآیندهای فراخوانده‌شده اجازه می‌دهد تا به طور ایمن تشخیص دهند که آیا خروجی استاندارد یا خروجی خطای استاندارد آن‌ها به ژورنال متصل است یا خیر\&. شماره‌های دستگاه و inode توصیف‌کننده‌های فایل باید با مقادیر تنظیم‌شده در متغیر محیطی مقایسه شوند تا مشخص گردد آیا خروجی فرآیند هنوز به ژورنال متصل است یا خیر\&. توجه داشته باشید که معمولاً بررسی صرف اینکه آیا
\fI$JOURNAL_STREAM\fR
اصلاً تنظیم شده است کافی نیست زیرا سرویس‌ها ممکن است فرآیندهای خارجی را فراخوانی کنند که خروجی استاندارد یا خطای استاندارد آن‌ها را جایگزین می‌کنند، بدون اینکه متغیر محیطی را لغو تنظیم نمایند\&.
.sp
اگر هم خروجی استاندارد و هم خطای استاندارد فرآیندهای اجراشده از طریق یک سوکت جریانی به ژورنال متصل باشند، این متغیر محیطی حاوی اطلاعات مربوط به جریان خطای استاندارد خواهد بود، زیرا معمولاً این مقصد ترجیحی برای داده‌های لاگ است\&. (توجه داشته باشید که معمولاً از یک جریان یکسان برای هر دو خروجی استاندارد و خطای استاندارد استفاده می‌شود، بنابراین بسیار محتمل است که متغیر محیطی حاوی اطلاعات دستگاه و inode منطبق بر هر دو توصیف‌کننده فایل جریان باشد\&.)
.sp
این متغیر محیطی در درجه اول برای این مفید است که به سرویس‌ها اجازه دهد در صورتی که خروجی استاندارد یا خروجی خطای استاندارد آن‌ها به هر حال به ژورنال متصل است، پروتکل لاگ مورد استفاده خود را به پروتکل بومی ژورنال ارتقا دهند (با استفاده از
\fBsd_journal_print\fR(3)
و توابع دیگر)، و در نتیجه امکان ارسال فراداده‌های ساختاریافته را به همراه پیام‌های ثبت‌شده فراهم کنند\&.
.sp
اضافه‌شده در نسخه 231\&.
.RE
.PP
\fI$SERVICE_RESULT\fR
.RS 4
فقط برای نوع واحد سرویس استفاده می‌شود\&. این متغیر محیطی به تمام فرآیندهای
\fIExecStop=\fR
و
\fIExecStopPost=\fR
ارسال می‌شود و "نتیجه" سرویس را کدگذاری می‌کند\&. در حال حاضر، مقادیر زیر تعریف شده‌اند:
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B جدول\ &5.\ &مقادیر تعریف‌شده برای \fI$SERVICE_RESULT\fR
.TS
allbox tab(:);
lB lB.
T{
مقدار
T}:T{
معنا
T}
.T&
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l.
T{
"success"
T}:T{
سرویس با موفقیت اجرا شد و به طور تمیز خارج گردید\&.
T}
T{
"protocol"
T}:T{
نقض پروتکل رخ داده است: سرویس اقدامات مورد نیاز توسط پیکربندی واحد خود را انجام نداده است (به طور خاص آنچه در تنظیم \fIType=\fR آن پیکربندی شده است)\&.
T}
T{
"timeout"
T}:T{
مهلت زمانی یکی از مراحل به پایان رسید\&.
T}
T{
"exit\-code"
T}:T{
فرآیند سرویس با کد خروج غیر صفر خارج شد؛ \fI$EXIT_CODE\fR زیر را برای کد خروج واقعی بازگردانده‌شده ببینید\&.
T}
T{
"signal"
T}:T{
فرآیند سرویس به طور غیرعادی توسط یک سیگنال، بدون تخلیه حافظه (core dump) خاتمه یافت\&. \fI$EXIT_CODE\fR زیر را برای سیگنال واقعی عامل خاتمه ببینید\&.
T}
T{
"core\-dump"
T}:T{
فرآیند سرویس به طور غیرعادی با یک سیگنال خاتمه یافت و حافظه هسته را تخلیه کرد\&. \fI$EXIT_CODE\fR زیر را برای سیگنال عامل خاتمه ببینید\&.
T}
T{
"watchdog"
T}:T{
پینگ زنده ماندن ناظر سگ نگهبان برای سرویس فعال بود، اما مهلت زمانی از دست رفت\&.
T}
T{
"exec\-condition"
T}:T{
سرویس اجرا نشد زیرا \fIExecCondition=\fR با شکست مواجه شد (یعنی دستور آن با وضعیت خروج بین 1 تا 254 (شامل هر دو) خارج شد)\&.
T}
T{
"oom\-kill"
T}:T{
فرآیند سرویس توسط قاتل کمبود حافظه (OOM Killer) خاتمه یافت\&.
T}
T{
"start\-limit\-hit"
T}:T{
محدودیت شروع برای واحد تعریف شده بود و به سقف آن رسید، که باعث شد واحد نتواند شروع به کار کند\&. برای جزئیات به \fIStartLimitIntervalSec=\fR و \fIStartLimitBurst=\fR در \fBsystemd.unit\fR(5) مراجعه کنید\&.
T}
T{
"resources"
T}:T{
یک وضعیت فراگیر در صورتی که یک عملیات سیستمی با شکست مواجه شود\&.
T}
.TE
.sp 1
این متغیر محیطی برای نظارت بر شکست یا پایان موفقیت‌آمیز یک سرویس مفید است\&. اگرچه این متغیر در هر دو
\fIExecStop=\fR
و
\fIExecStopPost=\fR
در دسترس است، معمولاً انتخاب بهتری است که ابزارهای نظارتی را در دومی قرار دهید، زیرا اولی فقط برای سرویس‌هایی فراخوانده می‌شود که موفق شده‌اند به درستی راه‌اندازی شوند، و دومی هم سرویس‌هایی را که در حین راه‌اندازی با شکست مواجه شده‌اند و هم سرویس‌هایی را که در حین اجرای خود شکست خورده‌اند پوشش می‌دهد\&.
.sp
اضافه‌شده در نسخه 232\&.
.RE
.PP
\fI$EXIT_CODE\fR، \fI$EXIT_STATUS\fR
.RS 4
فقط برای نوع واحد سرویس تعریف شده‌اند\&. این متغیرهای محیطی به تمام فرآیندهای
\fIExecStop=\fR،
\fIExecStopPost=\fR
ارسال می‌شوند و حاوی اطلاعات وضعیت/کد خروج فرآیند اصلی سرویس هستند\&. برای تعریف دقیق کد و وضعیت خروج، به
\fBwait\fR(2)
مراجعه کنید\&.
\fI$EXIT_CODE\fR
یکی از مقادیر
"exited"،
"killed"،
"dumped"
است\&.
\fI$EXIT_STATUS\fR
اگر
\fI$EXIT_CODE\fR
روی
"exited"
باشد، حاوی کد خروج عددی قالب‌بندی‌شده به عنوان رشته است، و در تمام موارد دیگر حاوی نام سیگنال است\&. توجه داشته باشید که این متغیرهای محیطی فقط در صورتی تنظیم می‌شوند که مدیر سرویس در شروع و شناسایی فرآیند اصلی سرویس موفق شده باشد\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B جدول\ &6.\ &خلاصه مقادیر ممکن متغیرهای نتیجه سرویس
.TS
allbox tab(:);
lB lB lB.
T{
\fI$SERVICE_RESULT\fR
T}:T{
\fI$EXIT_CODE\fR
T}:T{
\fI$EXIT_STATUS\fR
T}
.T&
lt lt l
^ lt l
lt lt l
^ l l
lt lt l
^ lt l
lt lt l
lt lt l
lt lt l
lt l l
^ l l
^ l l
lt l l
lt lt l
l l l
l l l
l s s.
T{
"success"
T}:T{
"killed"
T}:T{
"HUP", "INT", "TERM", "PIPE"
T}
:T{
"exited"
T}:T{
"0"
T}
T{
"protocol"
T}:T{
تنظیم‌نشده
T}:T{
تنظیم‌نشده
T}
:T{
"exited"
T}:T{
"0"
T}
T{
"timeout"
T}:T{
"killed"
T}:T{
"TERM", "KILL"
T}
:T{
"exited"
T}:T{
"0", "1", "2", "3", \&..., "255"
T}
T{
"exit\-code"
T}:T{
"exited"
T}:T{
"1", "2", "3", \&..., "255"
T}
T{
"signal"
T}:T{
"killed"
T}:T{
"HUP", "INT", "KILL", \&...
T}
T{
"core\-dump"
T}:T{
"dumped"
T}:T{
"ABRT", "SEGV", "QUIT", \&...
T}
T{
"watchdog"
T}:T{
"dumped"
T}:T{
"ABRT"
T}
:T{
"killed"
T}:T{
"TERM", "KILL"
T}
:T{
"exited"
T}:T{
"0", "1", "2", "3", \&..., "255"
T}
T{
"exec\-condition"
T}:T{
"exited"
T}:T{
"1", "2", "3", "4", \&..., "254"
T}
T{
"oom\-kill"
T}:T{
"killed"
T}:T{
"TERM", "KILL"
T}
T{
"start\-limit\-hit"
T}:T{
تنظیم‌نشده
T}:T{
تنظیم‌نشده
T}
T{
"resources"
T}:T{
هر یک از موارد فوق
T}:T{
هر یک از موارد فوق
T}
T{
نکته: فرآیند ممکن است توسط سیگنالی که توسط systemd ارسال نشده نیز خاتمه یابد\&. به ویژه فرآیند ممکن است در یک گرداننده برای هر یک از سیگنال‌های غیرقابل ماسک کردن، یک سیگنال دلخواه به خود ارسال کند\&. با این وجود، در سطرهای "timeout" و "watchdog" بالا فقط سیگنال‌هایی که systemd ارسال می‌کند گنجانده شده‌اند\&. علاوه بر این، با استفاده از \fISuccessExitStatus=\fR ممکن است وضعیت‌های خروج اضافی برای نشان دادن پایان تمیز اعلام شوند، که در این جدول منعکس نشده است\&.
T}
.TE
.sp 1
اضافه‌شده در نسخه 232\&.
.RE
.PP
\fI$MONITOR_SERVICE_RESULT\fR، \fI$MONITOR_EXIT_CODE\fR، \fI$MONITOR_EXIT_STATUS\fR، \fI$MONITOR_INVOCATION_ID\fR، \fI$MONITOR_UNIT\fR
.RS 4
فقط برای نوع واحد سرویس تعریف شده‌اند\&. این متغیرهای محیطی به تمام فرآیندهای
\fIExecStart=\fR
و
\fIExecStartPre=\fR
که در سرویس‌های تحریک‌شده توسط وابستگی‌های
\fIOnFailure=\fR
یا
\fIOnSuccess=\fR
اجرا می‌شوند ارسال می‌گردند\&.
.sp
متغیرهای
\fI$MONITOR_SERVICE_RESULT\fR،
\fI$MONITOR_EXIT_CODE\fR
و
\fI$MONITOR_EXIT_STATUS\fR
همان مقادیر مربوط به فرآیندهای
\fIExecStop=\fR
و
\fIExecStopPost=\fR
را می‌گیرند\&. متغیرهای
\fI$MONITOR_INVOCATION_ID\fR
و
\fI$MONITOR_UNIT\fR
روی شناسه فراخوانی و نام واحد سرویسی که وابستگی را تحریک کرده است تنظیم می‌شوند\&.
.sp
توجه داشته باشید که وقتی چندین سرویس، یک واحد یکسان را به عنوان گرداننده
\fIOnFailure=\fR
یا
\fIOnSuccess=\fR
خود مشخص می‌کنند، آن متغیرها ارسال
\fIنخواهند\fR
شد\&. در عوض، استفاده از یک واحد گرداننده الگو را برای آن حالت در نظر بگیرید:
"OnFailure=\fIhandler\fR@%n\&.service"
برای واحدهای بدون الگو، یا
"OnFailure=\fIhandler\fR@%p\-%i\&.service"
برای واحدهای دارای الگو\&.
.sp
اضافه‌شده در نسخه 251\&.
.RE
.PP
\fI$PIDFILE\fR
.RS 4
مسیر فایل PID پیکربندی‌شده، در صورتی که فرآیند از طرف سرویسی که از تنظیم
\fIPIDFile=\fR
استفاده می‌کند ایجاد شده باشد؛ برای جزئیات به
\fBsystemd.service\fR(5)
مراجعه کنید\&. کد سرویس ممکن است از این متغیر محیطی برای تولید خودکار یک فایل PID در مکان پیکربندی‌شده در فایل واحد استفاده کند\&. این فیلد روی یک مسیر مطلق در سیستم‌فایل تنظیم می‌شود\&.
.sp
اضافه‌شده در نسخه 242\&.
.RE
.PP
\fI$REMOTE_ADDR\fR، \fI$REMOTE_PORT\fR
.RS 4
اگر این واحدی است که از طریق فعال‌سازی سوکت به ازای هر اتصال شروع شده است (یعنی از طریق یک واحد سوکت با
\fIAccept=yes\fR)،
این متغیرهای محیطی حاوی اطلاعاتی درباره طرف راه دور (peer) اتصال سوکت هستند\&.
.sp
برای اتصالات IPv4 و IPv6،
\fI$REMOTE_ADDR\fR
حاوی آدرس IP و
\fI$REMOTE_PORT\fR
حاوی شماره پورت طرف مقابل راه دور است\&.
.sp
برای اتصالات سوکت
\fBAF_UNIX\fR،
\fI$REMOTE_ADDR\fR
یا حاوی مسیر سیستم‌فایل سوکت راه دور است که با یک اسلش ("/") شروع می‌شود، یا آدرس آن در فضای نام انتزاعی که با یک علامت at ("@") شروع می‌شود، یا در صورت سوکت بدون نام تنظیم‌نشده است\&.
\fI$REMOTE_PORT\fR
برای سوکت‌های
\fBAF_UNIX\fR
تنظیم نمی‌شود\&.
.sp
اضافه‌شده در نسخه 220\&.
.RE
.PP
\fI$TRIGGER_UNIT\fR، \fI$TRIGGER_PATH\fR، \fI$TRIGGER_TIMER_REALTIME_USEC\fR، \fI$TRIGGER_TIMER_MONOTONIC_USEC\fR
.RS 4
اگر واحد به صورت پویا فعال شده باشد (مانند: یک واحد مسیر یا واحد تایمر متناظر)، واحدی که آن را تحریک کرده و سایر اطلاعات وابسته به نوع از طریق این متغیرها منتقل خواهند شد\&. توجه داشته باشید که این اطلاعات با بهترین تلاش ممکن (best\-effort) ارائه می‌شوند\&. برای مثال، چندین محرک که یکی پس از دیگری رخ می‌دهند ادغام می‌شوند و تنها یکی گزارش خواهد شد، بدون هیچ تضمینی در مورد اینکه کدام یک خواهد بود\&. به همین دلیل، در بیشتر موارد این متغیر عمدتاً جنبه اطلاعاتی خواهد داشت، یعنی برای اهداف اشکال‌زدایی مفید است، با اتلاف اطلاعات همراه است، و نباید برای انتشار دلیل جامع فعال‌سازی به آن تکیه کرد\&.
.sp
اضافه‌شده در نسخه 252\&.
.RE
.PP
\fI$MEMORY_PRESSURE_WATCH\fR، \fI$MEMORY_PRESSURE_WRITE\fR
.RS 4
اگر نظارت بر فشار حافظه برای این واحد سرویس فعال باشد، مسیر برای نظارت و داده‌هایی برای نوشتن در آن\&. برای جزئیات در مورد این متغیرها و داده‌های پروتکل سرویس که آن‌ها منتقل می‌کنند به
\m[blue]\fBMemory Pressure Handling\fR\m[]\&\s-2\u[20]\d\s+2
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 254\&.
.RE
.PP
\fI$FDSTORE\fR
.RS 4
حداکثر تعداد توصیف‌کننده‌های فایل که ممکن است در مدیر برای سرویس ذخیره شوند\&. این متغیر هنگامی تنظیم می‌شود که مخزن توصیف‌کننده فایل برای سرویس فعال باشد، یعنی
\fIFileDescriptorStoreMax=\fR
روی یک مقدار غیر صفر تنظیم شده باشد (برای جزئیات به
\fBsystemd.service\fR(5)
مراجعه کنید)\&. برنامه‌ها ممکن است قبل از ارسال توصیف‌کننده‌های فایل به مدیر سرویس از طریق
\fBsd_pid_notify_with_fds\fR(3)
این متغیر محیطی را بررسی کنند\&.
.sp
اضافه‌شده در نسخه 254\&.
.RE
.PP
\fI$DEBUG_INVOCATION\fR
.RS 4
اگر
\fIRestartMode=debug\fR
تنظیم شده باشد، و تلاش قبلی برای شروع واحد با شکست مواجه شده باشد، این متغیر به سرویس ارسال می‌شود تا نشان دهد که ثبت گزارش اضافی باید در زمان راه‌اندازی فعال شود\&. برای جزئیات بیشتر به
\fBsystemd.service\fR(5)
مراجعه کنید\&.
.sp
اضافه‌شده در نسخه 257\&.
.RE
.PP
برای سرویس‌های سیستمی، هنگامی که
\fIPAMName=\fR
فعال باشد و
\fBpam_systemd\fR
بخشی از پشته PAM انتخاب‌شده باشد، متغیرهای محیطی اضافی تعریف‌شده توسط systemd ممکن است برای سرویس‌ها تنظیم شوند\&. به طور خاص، این متغیرها
\fI$XDG_SEAT\fR،
\fI$XDG_VTNR\fR
هستند، برای جزئیات به
\fBpam_systemd\fR(8)
مراجعه کنید\&.
.SH "کدهای خروج فرآیند (PROCESS EXIT CODES)"
.PP
هنگام فراخوانی یک فرآیند واحد، ممکن است مدیر سرویس نتواند پارامترهای اجرای پیکربندی‌شده با تنظیمات بالا را اعمال کند\&. در این حالت، فرآیند سرویس ایجادشده قبل از اجرای خط فرمان پیکربندی‌شده با یک کد خروج غیر صفر خارج خواهد شد\&. (یا به عبارت دیگر، فرآیند فرزند احتمالاً پس از ایجاد شدن توسط فراخوانی سیستمی
\fBfork\fR(2)،
اما قبل از فراخوانی فراخوانی سیستمی
\fBexecve\fR(2)
منطبق، با این کدهای خطا خارج می‌شود\&.) به طور خاص، کدهای خروج تعریف‌شده توسط کتابخانه C، توسط مشخصات LSB و توسط خود مدیر سرویس systemd استفاده می‌شوند\&.
.PP
کدهای خروج پایه زیر توسط کتابخانه C تعریف شده‌اند\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B جدول\ &7.\ &کدهای خروج پایه کتابخانه C
.TS
allbox tab(:);
lB lB lB.
T{
کد خروج
T}:T{
نام نمادین
T}:T{
توضیحات
T}
.T&
l l l
l l l.
T{
0
T}:T{
\fBEXIT_SUCCESS\fR
T}:T{
کد موفقیت عمومی\&.
T}
T{
1
T}:T{
\fBEXIT_FAILURE\fR
T}:T{
شکست عمومی یا خطای نامشخص\&.
T}
.TE
.sp 1
.PP
کدهای خروج سرویس زیر توسط
\m[blue]\fBمشخصات LSB\fR\m[]\&\s-2\u[21]\d\s+2
تعریف شده‌اند\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B جدول\ &8.\ &کدهای خروج سرویس LSB
.TS
allbox tab(:);
lB lB lB.
T{
کد خروج
T}:T{
نام نمادین
T}:T{
توضیحات
T}
.T&
l l l
l l l
l l l
l l l
l l l
l l l.
T{
2
T}:T{
\fBEXIT_INVALIDARGUMENT\fR
T}:T{
آرگومان‌های نامعتبر یا اضافی\&.
T}
T{
3
T}:T{
\fBEXIT_NOTIMPLEMENTED\fR
T}:T{
قابلیت پیاده‌سازی‌نشده\&.
T}
T{
4
T}:T{
\fBEXIT_NOPERMISSION\fR
T}:T{
کاربر دارای امتیازات کافی نیست\&.
T}
T{
5
T}:T{
\fBEXIT_NOTINSTALLED\fR
T}:T{
برنامه نصب نشده است\&.
T}
T{
6
T}:T{
\fBEXIT_NOTCONFIGURED\fR
T}:T{
برنامه پیکربندی نشده است\&.
T}
T{
7
T}:T{
\fBEXIT_NOTRUNNING\fR
T}:T{
برنامه در حال اجرا نیست\&.
T}
.TE
.sp 1
.PP
مشخصات LSB پیشنهاد می‌کند که کدهای خطای 200 و بالاتر برای پیاده‌سازی‌ها رزرو شوند\&. برخی از آن‌ها توسط مدیر سرویس برای نشان دادن مشکلات در حین فراخوانی فرآیند استفاده می‌شوند:
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B جدول\ &9.\ &کدهای خروج اختصاصی systemd
.TS
allbox tab(:);
lB lB lB.
T{
کد خروج
T}:T{
نام نمادین
T}:T{
توضیحات
T}
.T&
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l.
T{
200
T}:T{
\fBEXIT_CHDIR\fR
T}:T{
تغییر به دایرکتوری کاری درخواستی با شکست مواجه شد\&. \fIWorkingDirectory=\fR را در بالا ببینید\&.
T}
T{
201
T}:T{
\fBEXIT_NICE\fR
T}:T{
راه‌اندازی اولویت زمان‌بندی فرآیند (سطح nice) با شکست مواجه شد\&. \fINice=\fR را در بالا ببینید\&.
T}
T{
202
T}:T{
\fBEXIT_FDS\fR
T}:T{
بستن توصیف‌کننده‌های فایل ناخواسته یا تنظیم توصیف‌کننده‌های فایل ارسالی با شکست مواجه شد\&.
T}
T{
203
T}:T{
\fBEXIT_EXEC\fR
T}:T{
اجرای واقعی فرآیند (به طور خاص، فراخوانی سیستمی \fBexecve\fR(2)) با شکست مواجه شد\&. به احتمال زیاد این ناشی از یک فایل اجرایی مفقود یا غیرقابل دسترسی است\&.
T}
T{
204
T}:T{
\fBEXIT_MEMORY\fR
T}:T{
انجام عملیات به دلیل کمبود حافظه با شکست مواجه شد\&.
T}
T{
205
T}:T{
\fBEXIT_LIMITS\fR
T}:T{
تنظیم محدودیت‌های منابع با شکست مواجه شد\&. \fILimitCPU=\fR و تنظیمات مرتبط را در بالا ببینید\&.
T}
T{
206
T}:T{
\fBEXIT_OOM_ADJUST\fR
T}:T{
تنظیم مقدار OOM با شکست مواجه شد\&. \fIOOMScoreAdjust=\fR را در بالا ببینید\&.
T}
T{
207
T}:T{
\fBEXIT_SIGNAL_MASK\fR
T}:T{
تنظیم ماسک سیگنال فرآیند با شکست مواجه شد\&.
T}
T{
208
T}:T{
\fBEXIT_STDIN\fR
T}:T{
راه‌اندازی ورودی استاندارد با شکست مواجه شد\&. \fIStandardInput=\fR را در بالا ببینید\&.
T}
T{
209
T}:T{
\fBEXIT_STDOUT\fR
T}:T{
راه‌اندازی خروجی استاندارد با شکست مواجه شد\&. \fIStandardOutput=\fR را در بالا ببینید\&.
T}
T{
210
T}:T{
\fBEXIT_CHROOT\fR
T}:T{
تغییر دایرکتوری ریشه (\fBchroot\fR(2)) با شکست مواجه شد\&. \fIRootDirectory=\fR/\fIRootImage=\fR را در بالا ببینید\&.
T}
T{
211
T}:T{
\fBEXIT_IOPRIO\fR
T}:T{
راه‌اندازی اولویت زمان‌بندی IO با شکست مواجه شد\&. \fIIOSchedulingClass=\fR/\fIIOSchedulingPriority=\fR را در بالا ببینید\&.
T}
T{
212
T}:T{
\fBEXIT_TIMERSLACK\fR
T}:T{
راه‌اندازی سستی تایمر با شکست مواجه شد\&. \fITimerSlackNSec=\fR را در بالا ببینید\&.
T}
T{
213
T}:T{
\fBEXIT_SECUREBITS\fR
T}:T{
تنظیم بیت‌های امنیتی فرآیند با شکست مواجه شد\&. \fISecureBits=\fR را در بالا ببینید\&.
T}
T{
214
T}:T{
\fBEXIT_SETSCHEDULER\fR
T}:T{
راه‌اندازی زمان‌بندی پردازنده با شکست مواجه شد\&. \fICPUSchedulingPolicy=\fR/\fICPUSchedulingPriority=\fR را در بالا ببینید\&.
T}
T{
215
T}:T{
\fBEXIT_CPUAFFINITY\fR
T}:T{
راه‌اندازی همبستگی پردازنده‌ای (CPU affinity) با شکست مواجه شد\&. \fICPUAffinity=\fR را در بالا ببینید\&.
T}
T{
216
T}:T{
\fBEXIT_GROUP\fR
T}:T{
تعیین یا تغییر شناسه‌های گروه با شکست مواجه شد\&. \fIGroup=\fR/\fISupplementaryGroups=\fR را در بالا ببینید\&.
T}
T{
217
T}:T{
\fBEXIT_USER\fR
T}:T{
تعیین یا تغییر شناسه‌های کاربر، یا راه‌اندازی فضاسازی نام کاربر با شکست مواجه شد\&. \fIUser=\fR/\fIPrivateUsers=\fR را در بالا ببینید\&.
T}
T{
218
T}:T{
\fBEXIT_CAPABILITIES\fR
T}:T{
حذف قابلیت‌ها یا اعمال قابلیت‌های فراگیر (ambient) با شکست مواجه شد\&. \fICapabilityBoundingSet=\fR/\fIAmbientCapabilities=\fR را در بالا ببینید\&.
T}
T{
219
T}:T{
\fBEXIT_CGROUP\fR
T}:T{
راه‌اندازی گروه کنترلی (cgroup) سرویس با شکست مواجه شد\&.
T}
T{
220
T}:T{
\fBEXIT_SETSID\fR
T}:T{
ایجاد نشست (session) فرآیند جدید با شکست مواجه شد\&.
T}
T{
221
T}:T{
\fBEXIT_CONFIRM\fR
T}:T{
اجرا توسط کاربر لغو شده است\&. برای جزئیات، تنظیم خط فرمان هسته \fIsystemd\&.confirm_spawn=\fR را در \fBkernel-command-line\fR(7) ببینید\&.
T}
T{
222
T}:T{
\fBEXIT_STDERR\fR
T}:T{
راه‌اندازی خروجی خطای استاندارد با شکست مواجه شد\&. \fIStandardError=\fR را در بالا ببینید\&.
T}
T{
224
T}:T{
\fBEXIT_PAM\fR
T}:T{
راه‌اندازی نشست PAM با شکست مواجه شد\&. \fIPAMName=\fR را در بالا ببینید\&.
T}
T{
225
T}:T{
\fBEXIT_NETWORK\fR
T}:T{
راه‌اندازی فضاسازی نام شبکه با شکست مواجه شد\&. \fIPrivateNetwork=\fR را در بالا ببینید\&.
T}
T{
226
T}:T{
\fBEXIT_NAMESPACE\fR
T}:T{
راه‌اندازی فضاسازی نام mount، UTS یا IPC با شکست مواجه شد\&. \fIReadOnlyPaths=\fR، \fIProtectHostname=\fR، \fIPrivateIPC=\fR و تنظیمات مرتبط را در بالا ببینید\&.
T}
T{
227
T}:T{
\fBEXIT_NO_NEW_PRIVILEGES\fR
T}:T{
غیرفعال کردن امتیازات جدید با شکست مواجه شد\&. \fINoNewPrivileges=yes\fR را در بالا ببینید\&.
T}
T{
228
T}:T{
\fBEXIT_SECCOMP\fR
T}:T{
اعمال فیلترهای فراخوانی سیستمی با شکست مواجه شد\&. \fISystemCallFilter=\fR و تنظیمات مرتبط را در بالا ببینید\&.
T}
T{
229
T}:T{
\fBEXIT_SELINUX_CONTEXT\fR
T}:T{
تعیین یا تغییر زمینه امنیتی SELinux با شکست مواجه شد\&. \fISELinuxContext=\fR را در بالا ببینید\&.
T}
T{
230
T}:T{
\fBEXIT_PERSONALITY\fR
T}:T{
راه‌اندازی دامنه اجرا (personality) با شکست مواجه شد\&. \fIPersonality=\fR را در بالا ببینید\&.
T}
T{
231
T}:T{
\fBEXIT_APPARMOR_PROFILE\fR
T}:T{
آماده‌سازی تغییر نمایه AppArmor با شکست مواجه شد\&. \fIAppArmorProfile=\fR را در بالا ببینید\&.
T}
T{
232
T}:T{
\fBEXIT_ADDRESS_FAMILIES\fR
T}:T{
محدود کردن خانواده‌های آدرس با شکست مواجه شد\&. \fIRestrictAddressFamilies=\fR را در بالا ببینید\&.
T}
T{
233
T}:T{
\fBEXIT_RUNTIME_DIRECTORY\fR
T}:T{
راه‌اندازی دایرکتوری زمان اجرا با شکست مواجه شد\&. \fIRuntimeDirectory=\fR و تنظیمات مرتبط را در بالا ببینید\&.
T}
T{
235
T}:T{
\fBEXIT_CHOWN\fR
T}:T{
تنظیم مالکیت سوکت با شکست مواجه شد\&. فقط برای واحدهای سوکت استفاده می‌شود\&.
T}
T{
236
T}:T{
\fBEXIT_SMACK_PROCESS_LABEL\fR
T}:T{
تنظیم برچسب SMACK با شکست مواجه شد\&. \fISmackProcessLabel=\fR را در بالا ببینید\&.
T}
T{
237
T}:T{
\fBEXIT_KEYRING\fR
T}:T{
راه‌اندازی دسته‌کلید هسته با شکست مواجه شد\&.
T}
T{
238
T}:T{
\fBEXIT_STATE_DIRECTORY\fR
T}:T{
راه‌اندازی دایرکتوری وضعیت واحد با شکست مواجه شد\&. \fIStateDirectory=\fR را در بالا ببینید\&.
T}
T{
239
T}:T{
\fBEXIT_CACHE_DIRECTORY\fR
T}:T{
راه‌اندازی دایرکتوری حافظه موقت (cache) واحد با شکست مواجه شد\&. \fICacheDirectory=\fR را در بالا ببینید\&.
T}
T{
240
T}:T{
\fBEXIT_LOGS_DIRECTORY\fR
T}:T{
راه‌اندازی دایرکتوری گزارش‌های واحد با شکست مواجه شد\&. \fILogsDirectory=\fR را در بالا ببینید\&.
T}
T{
241
T}:T{
\fBEXIT_CONFIGURATION_DIRECTORY\fR
T}:T{
راه‌اندازی دایرکتوری پیکربندی واحد با شکست مواجه شد\&. \fIConfigurationDirectory=\fR را در بالا ببینید\&.
T}
T{
242
T}:T{
\fBEXIT_NUMA_POLICY\fR
T}:T{
راه‌اندازی خط‌مشی حافظه NUMA واحد با شکست مواجه شد\&. \fINUMAPolicy=\fR و \fINUMAMask=\fR را در بالا ببینید\&.
T}
T{
243
T}:T{
\fBEXIT_CREDENTIALS\fR
T}:T{
راه‌اندازی اطلاعات اعتبارسنجی واحد با شکست مواجه شد\&. \fIImportCredential=\fR، \fILoadCredential=\fR و \fISetCredential=\fR را در بالا ببینید\&.
T}
T{
245
T}:T{
\fBEXIT_BPF\fR
T}:T{
اعمال محدودیت‌های BPF با شکست مواجه شد\&. \fIRestrictFileSystems=\fR را در بالا ببینید\&.
T}
.TE
.sp 1
.PP
در نهایت، سیستم‌های عامل BSD مجموعه‌ای از کدهای خروج را تعریف می‌کنند که معمولاً در سیستم‌های لینوکس نیز تعریف شده‌اند:
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B جدول\ &10.\ &کدهای خروج BSD
.TS
allbox tab(:);
lB lB lB.
T{
کد خروج
T}:T{
نام نمادین
T}:T{
توضیحات
T}
.T&
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l.
T{
64
T}:T{
\fBEX_USAGE\fR
T}:T{
خطای استفاده در خط فرمان
T}
T{
65
T}:T{
\fBEX_DATAERR\fR
T}:T{
خطای قالب داده
T}
T{
66
T}:T{
\fBEX_NOINPUT\fR
T}:T{
عدم امکان باز کردن ورودی
T}
T{
67
T}:T{
\fBEX_NOUSER\fR
T}:T{
گیرنده نامشخص است
T}
T{
68
T}:T{
\fBEX_NOHOST\fR
T}:T{
نام میزبان نامشخص است
T}
T{
69
T}:T{
\fBEX_UNAVAILABLE\fR
T}:T{
سرویس در دسترس نیست
T}
T{
70
T}:T{
\fBEX_SOFTWARE\fR
T}:T{
خطای نرم‌افزاری داخلی
T}
T{
71
T}:T{
\fBEX_OSERR\fR
T}:T{
خطای سیستمی (مثلاً عدم امکان ایجاد فرآیند با fork)
T}
T{
72
T}:T{
\fBEX_OSFILE\fR
T}:T{
فایل حیاتی سیستم‌عامل موجود نیست
T}
T{
73
T}:T{
\fBEX_CANTCREAT\fR
T}:T{
عدم امکان ایجاد فایل خروجی (کاربر)
T}
T{
74
T}:T{
\fBEX_IOERR\fR
T}:T{
خطای ورودی/خروجی
T}
T{
75
T}:T{
\fBEX_TEMPFAIL\fR
T}:T{
شکست موقت؛ از کاربر دعوت می‌شود دوباره تلاش کند
T}
T{
76
T}:T{
\fBEX_PROTOCOL\fR
T}:T{
خطای راه دور در پروتکل
T}
T{
77
T}:T{
\fBEX_NOPERM\fR
T}:T{
دسترسی رد شد (مجوز ناکافی)
T}
T{
78
T}:T{
\fBEX_CONFIG\fR
T}:T{
خطای پیکربندی
T}
.TE
.sp 1
.SH "مثال‌ها (EXAMPLES)"
.PP
\fBمثال\ &3.\ &کاربرد \fI$MONITOR_\fR\fI\fI*\fR\fR\fR
.PP
یک سرویس
myfailer\&.service
که می‌تواند یک وابستگی
\fIOnFailure=\fR
را تحریک کند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
[Unit]
Description=Service which can trigger an OnFailure= dependency
OnFailure=myhandler\&.service

[Service]
ExecStart=/bin/myprogram
.fi
.if n \{\
.RE
.\}
.PP
یک سرویس
mysuccess\&.service
که می‌تواند یک وابستگی
\fIOnSuccess=\fR
را تحریک کند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
[Unit]
Description=Service which can trigger an OnSuccess= dependency
OnSuccess=myhandler\&.service

[Service]
ExecStart=/bin/mysecondprogram
.fi
.if n \{\
.RE
.\}
.PP
یک سرویس
myhandler\&.service
که می‌تواند توسط هر یک از سرویس‌های بالا تحریک شود\&.
.sp
.if n \{\
.RS 4
.\}
.nf
[Unit]
Description=Acts on service failing or succeeding

[Service]
ExecStart=/bin/bash \-c "echo $MONITOR_SERVICE_RESULT $MONITOR_EXIT_CODE $MONITOR_EXIT_STATUS $MONITOR_INVOCATION_ID $MONITOR_UNIT"
.fi
.if n \{\
.RE
.\}
.PP
اگر
myfailer\&.service
اجرا شود و با شکست خارج شود، آن‌گاه
myhandler\&.service
تحریک می‌شود و متغیرهای ناظر به صورت زیر تنظیم می‌شوند:
.sp
.if n \{\
.RS 4
.\}
.nf
MONITOR_SERVICE_RESULT=exit\-code
MONITOR_EXIT_CODE=exited
MONITOR_EXIT_STATUS=1
MONITOR_INVOCATION_ID=cc8fdc149b2b4ca698d4f259f4054236
MONITOR_UNIT=myfailer\&.service
.fi
.if n \{\
.RE
.\}
.PP
اگر
mysuccess\&.service
اجرا شود و با موفقیت خارج شود، آن‌گاه
myhandler\&.service
تحریک می‌شود و متغیرهای ناظر به صورت زیر تنظیم می‌شوند:
.sp
.if n \{\
.RS 4
.\}
.nf
MONITOR_SERVICE_RESULT=success
MONITOR_EXIT_CODE=exited
MONITOR_EXIT_STATUS=0
MONITOR_INVOCATION_ID=6ab9af147b8c4a3ebe36e7a5f8611697
MONITOR_UNIT=mysuccess\&.service
.fi
.if n \{\
.RE
.\}
.SH "همچنین ببینید (SEE ALSO)"
.PP
\fBsystemd\fR(1), \fBsystemctl\fR(1), \fBsystemd-analyze\fR(1), \fBjournalctl\fR(1), \fBsystemd-system.conf\fR(5), \fBsystemd.unit\fR(5), \fBsystemd.service\fR(5), \fBsystemd.socket\fR(5), \fBsystemd.swap\fR(5), \fBsystemd.mount\fR(5), \fBsystemd.kill\fR(5), \fBsystemd.resource-control\fR(5), \fBsystemd.time\fR(7), \fBsystemd.directives\fR(7), \fBtmpfiles.d\fR(5), \fBexec\fR(3), \fBfork\fR(2)
.SH "یادداشت‌ها (NOTES)"
.IP " 1." 4
Discoverable Partitions Specification
.RS 4
\%https://uapi-group.org/specifications/specs/discoverable_partitions_specification
.RE
.IP " 2." 4
The /proc Filesystem
.RS 4
\%https://docs.kernel.org/filesystems/proc.html#mount-options
.RE
.IP " 3." 4
User/Group Name Syntax
.RS 4
\%https://systemd.io/USER_NAMES
.RE
.IP " 4." 4
No New Privileges Flag
.RS 4
\%https://docs.kernel.org/userspace-api/no_new_privs.html
.RE
.IP " 5." 4
JSON User Record
.RS 4
\%https://systemd.io/USER_RECORD
.RE
.IP " 6." 4
The /proc Filesystem
.RS 4
\%https://docs.kernel.org/filesystems/proc.html
.RE
.IP " 7." 4
id-mapped mounts
.RS 4
\%https://lwn.net/Articles/896255
.RE
.IP " 8." 4
Kernel Samepage Merging
.RS 4
\%https://docs.kernel.org/admin-guide/mm/ksm.html
.RE
.IP " 9." 4
unicode scalar values
.RS 4
\%https://www.unicode.org/glossary/#unicode_scalar_value
.RE
.IP "10." 4
unicode noncharacters
.RS 4
\%https://www.unicode.org/glossary/#noncharacter
.RE
.IP "11." 4
unicode byte order mark
.RS 4
\%https://www.unicode.org/glossary/#byte_order_mark
.RE
.IP "12." 4
POSIX shell unquoted text
.RS 4
\%https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_01
.RE
.IP "13." 4
POSIX shell single-quoted text
.RS 4
\%https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_02
.RE
.IP "14." 4
POSIX shell double-quoted text
.RS 4
\%https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03
.RE
.IP "15." 4
Base64
.RS 4
\%https://tools.ietf.org/html/rfc2045#section-6.8
.RE
.IP "16." 4
Container Interface
.RS 4
\%https://systemd.io/CONTAINER_INTERFACE
.RE
.IP "17." 4
DMI/SMBIOS
.RS 4
\%https://www.dmtf.org/standards/smbios
.RE
.IP "18." 4
qemu
.RS 4
\%https://www.qemu.org/docs/master/system/index.html
.RE
.IP "19." 4
System and Service Credentials
.RS 4
\%https://systemd.io/CREDENTIALS
.RE
.IP "20." 4
Memory Pressure Handling
.RS 4
\%https://systemd.io/MEMORY_PRESSURE
.RE
.IP "21." 4
LSB specification
.RS 4
\%https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
.RE