'\" t
.TH "SYSTEMD\&.SOCKET" "5" "" "systemd 261.2" "systemd.socket"
.\" -----------------------------------------------------------------
.\" * 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.socket \- پیکربندی واحد سوکت
.SH "خلاصه دستور (SYNOPSIS)"
.PP
\fIsocket\fR\&.socket
.SH "توضیحات (DESCRIPTION)"
.PP
یک فایل پیکربندی واحد که نام آن به
"\&.socket"
ختم می‌شود، اطلاعات مربوط به یک سوکت IPC یا شبکه یا یک FIFO در سیستم فایل را که تحت کنترل و نظارت systemd است، برای فعال‌سازی مبتنی بر سوکت کدگذاری می‌کند\&.
.PP
این صفحه راهنما، گزینه‌های پیکربندی مخصوص این نوع واحد را فهرست می‌کند\&. برای گزینه‌های مشترک تمام فایل‌های پیکربندی واحد،
\fBsystemd.unit\fR(5)
را ببینید\&. موارد پیکربندی مشترک در بخش‌های عمومی [Unit] و [Install] پیکربندی می‌شوند\&. گزینه‌های پیکربندی مخصوص سوکت در بخش [Socket] پیکربندی می‌شوند\&.
.PP
گزینه‌های اضافی در
\fBsystemd.exec\fR(5)
فهرست شده‌اند، که محیط اجرایی را که دستورات
\fBExecStartPre=\fR،
\fBExecStartPost=\fR،
\fBExecStopPre=\fR
و
\fBExecStopPost=\fR
در آن اجرا می‌شوند تعریف می‌کند، و در
\fBsystemd.kill\fR(5)،
که نحوه خاتمه فرآیندها را تعریف می‌کند، و در
\fBsystemd.resource-control\fR(5)،
که تنظیمات کنترل منابع را برای فرآیندهای سوکت پیکربندی می‌کند\&.
.PP
برای هر واحد سوکت، باید یک واحد سرویس منطبق وجود داشته باشد که سرویسی را که باید با ترافیک ورودی روی سوکت شروع شود توصیف کند (برای اطلاعات بیشتر درباره واحدهای \&.service به
\fBsystemd.service\fR(5)
مراجعه کنید)\&. نام واحد \&.service به‌طور پیش‌فرض همان نام واحد \&.socket است، اما می‌توان آن را با گزینه
\fBService=\fR
که در زیر توضیح داده شده تغییر داد\&. بسته به تنظیم گزینه
\fBAccept=\fR
که در زیر توضیح داده شده، این واحد \&.service یا باید مانند واحد \&.socket نام‌گذاری شود ولی با پسوند جایگزین‌شده، مگر اینکه با
\fBService=\fR
بازنویسی شود؛ یا باید یک واحد الگو باشد که به همان شیوه نام‌گذاری شده است\&. مثال: یک فایل سوکت
foo\&.socket
در صورت تنظیم
\fBAccept=no\fR
به یک سرویس منطبق
foo\&.service
نیاز دارد\&. اگر
\fBAccept=yes\fR
تنظیم شده باشد، باید یک الگوی سرویس
foo@\&.service
وجود داشته باشد که به ازای هر اتصال ورودی، سرویس‌هایی از روی آن نمونه‌سازی شوند\&.
.PP
هیچ وابستگی ضمنی
\fIWantedBy=\fR
یا
\fIRequiredBy=\fR
از سوکت به سرویس اضافه نمی‌شود\&. این بدان معناست که سرویس ممکن است بدون سوکت شروع شود، که در این صورت باید بتواند خودش سوکت‌ها را باز کند\&. برای جلوگیری از این موضوع، می‌توان یک وابستگی صریح
\fIRequires=\fR
اضافه کرد\&.
.PP
واحدهای سوکت ممکن است برای پیاده‌سازی راه‌اندازی درخواستی سرویس‌ها و همچنین راه‌اندازی موازی سرویس‌ها استفاده شوند\&. برای مقدمه، داستان‌های وبلاگ پیوند داده شده در انتها را ببینید\&.
.PP
توجه داشته باشید که نرم‌افزار دیمن پیکربندی‌شده برای فعال‌سازی از طریق سوکت با واحدهای سوکت باید بتواند سوکت‌ها را از systemd بپذیرد؛ یا از طریق واسط بومی انتقال سوکت systemd (برای جزئیات درباره پروتکل دقیق استفاده‌شده و ترتیبی که توصیف‌کننده‌های فایل منتقل می‌شوند به
\fBsd_listen_fds\fR(3)
مراجعه کنید) یا از طریق انتقال سوکت به سبک سنتی
\fBinetd\fR(8)
(یعنی سوکت‌هایی که از طریق ورودی و خروجی استاندارد، با استفاده از
\fIStandardInput=socket\fR
در فایل سرویس منتقل می‌شوند)\&.
.PP
به‌طور پیش‌فرض، سوکت‌های شبکه‌ای تخصیص‌یافته از طریق واحدهای
\&.socket
در فضای‌نام شبکه میزبان تخصیص می‌یابند (به
\fBnetwork_namespaces\fR(7)
مراجعه کنید)\&. با این حال این بدان معنا نیست که سرویس فعال‌شده توسط یک واحد سوکت پیکربندی‌شده نیز لزوماً باید بخشی از فضای‌نام شبکه میزبان باشد\&. اجرای سرویس‌ها در فضای‌نام شبکه مخصوص خودشان (برای مثال از طریق
\fIPrivateNetwork=\fR،
به
\fBsystemd.exec\fR(5)
مراجعه کنید) کاملاً پشتیبانی می‌شود و حتی یک شیوه کاری خوب است، به طوری که تنها سوکت‌های پیکربندی‌شده از طریق فعال‌سازی سوکت را از فضای‌نام میزبان دریافت کنند\&. در چنین پیکربندی‌ای، ارتباط درون فضای‌نام شبکه میزبان تنها از طریق سوکت‌های فعال‌سازی منتقل‌شده مجاز است، در حالی که تمام سوکت‌های تخصیص‌یافته از خود کد سرویس به فضای‌نام اختصاصی سرویس مرتبط خواهند بود و بنابراین احتمالاً مشمول یک پیکربندی محدودکننده قرار می‌گیرند\&.
.PP
به عنوان روشی دیگر، اجرای یک واحد
\&.socket
در یک فضای‌نام شبکه دیگر با تنظیم
\fBPrivateNetwork=yes\fR
همراه با
\fIJoinsNamespaceOf=\fR
امکان‌پذیر است؛ برای جزئیات به
\fBsystemd.exec\fR(5)
و
\fBsystemd.unit\fR(5)
مراجعه کنید\&.
.SH "وابستگی‌های خودکار (AUTOMATIC DEPENDENCIES)"
.SS "وابستگی‌های ضمنی (Implicit Dependencies)"
.PP
وابستگی‌های زیر به‌طور ضمنی اضافه می‌شوند:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
واحدهای سوکت به‌طور خودکار یک وابستگی
\fIBefore=\fR
نسبت به واحدهای سرویسی که فعال می‌کنند به دست می‌آورند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
واحدهای سوکت که به مسیرهای سیستم فایل اشاره دارند (مانند سوکت‌های
\fBAF_UNIX\fR
یا FIFOها) به‌طور ضمنی وابستگی‌های
\fIRequires=\fR
و
\fIAfter=\fR
نسبت به تمام واحدهای سوار کردنی که برای دسترسی به آن مسیرها ضروری هستند به دست می‌آورند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
واحدهای سوکت که از تنظیم
\fIBindToDevice=\fR
استفاده می‌کنند به‌طور خودکار یک وابستگی
\fIBindsTo=\fR
و
\fIAfter=\fR
نسبت به واحد دستگاهی که رابط شبکه مشخص‌شده را کپسوله‌سازی می‌کند به دست می‌آورند\&.
.RE
.PP
وابستگی‌های ضمنی اضافی ممکن است در نتیجه پارامترهای اجرا و کنترل منابع، همان‌طور که در
\fBsystemd.exec\fR(5)
و
\fBsystemd.resource-control\fR(5)
مستند شده است، اضافه شوند\&.
.SS "وابستگی‌های پیش‌فرض (Default Dependencies)"
.PP
وابستگی‌های زیر اضافه می‌شوند مگر اینکه
\fIDefaultDependencies=no\fR
تنظیم شده باشد:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
واحدهای سوکت به‌طور خودکار یک وابستگی
\fIBefore=\fR
نسبت به
sockets\&.target
به دست می‌آورند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
واحدهای سوکت به‌طور خودکار یک جفت وابستگی
\fIAfter=\fR
و
\fIRequires=\fR
نسبت به
sysinit\&.target،
و یک جفت وابستگی
\fIBefore=\fR
و
\fIConflicts=\fR
نسبت به
shutdown\&.target
به دست می‌آورند\&. این وابستگی‌ها اطمینان حاصل می‌کنند که واحد سوکت قبل از سرویس‌های عادی در زمان بوت شروع شود و در هنگام خاموش شدن متوقف گردد\&. تنها سوکت‌هایی که در مراحل اولیه بوت یا مراحل پایانی خاموش شدن سیستم نقش دارند باید گزینه
\fIDefaultDependencies=\fR
را غیرفعال کنند\&.
.RE
.SH "گزینه‌ها (OPTIONS)"
.PP
فایل‌های واحد سوکت ممکن است شامل بخش‌های [Unit] و [Install] باشند که در
\fBsystemd.unit\fR(5)
توصیف شده‌اند\&.
.PP
فایل‌های واحد سوکت باید شامل بخش [Socket] باشند که حامل اطلاعات مربوط به سوکت یا FIFO تحت نظارت آن است\&. تعدادی از گزینه‌هایی که ممکن است در این بخش استفاده شوند با انواع واحدهای دیگر مشترک هستند\&. این گزینه‌ها در
\fBsystemd.exec\fR(5)،
\fBsystemd.kill\fR(5)
و
\fBsystemd.resource-control\fR(5)
مستند شده‌اند\&. گزینه‌های مخصوص بخش [Socket] واحدهای سوکت به شرح زیر است:
.PP
\fIListenStream=\fR, \fIListenDatagram=\fR, \fIListenSequentialPacket=\fR
.RS 4
آدرسی را برای گوش دادن به‌ترتیب برای یک سوکت جریانی (\fBSOCK_STREAM\fR)، دیتاگرام (\fBSOCK_DGRAM\fR)، یا بسته‌ای متوالی (\fBSOCK_SEQPACKET\fR) مشخص می‌کند\&. آدرس را می‌توان در قالب‌های گوناگونی نوشت:
.sp
اگر آدرس با یک ممیز ("/") شروع شود، به عنوان یک سوکت سیستم فایل در خانواده سوکت
\fBAF_UNIX\fR
خوانده می‌شود\&.
.sp
اگر آدرس با علامت اتساین ("@") شروع شود، به عنوان یک سوکت در فضای‌نام انتزاعی در خانواده
\fBAF_UNIX\fR
خوانده می‌شود\&. علامت
"@"
پیش از مقیدسازی با یک نویسه
\fBNUL\fR
جایگزین می‌شود\&. برای جزئیات،
\fBunix\fR(7)
را ببینید\&.
.sp
اگر رشته آدرس یک عدد منفرد باشد، به عنوان شماره درگاهی برای گوش دادن از طریق IPv6 خوانده می‌شود\&. بسته به مقدار
\fIBindIPv6Only=\fR
(به زیر مراجعه کنید) این ممکن است منجر به در دسترس بودن سرویس از طریق هر دو IPv6 و IPv4 (پیش‌فرض) یا فقط از طریق IPv6 شود\&.
.sp
اگر رشته آدرس رشته‌ای با قالب
"\fIv\&.w\&.x\&.y\fR:\fIz\fR"
باشد، به عنوان آدرس IPv4 با مقدار
\fIv\&.w\&.x\&.y\fR
و درگاه
\fIz\fR
تفسیر می‌شود\&.
.sp
اگر رشته آدرس رشته‌ای با قالب
"[\fIx\fR]:\fIy\fR"
باشد، به عنوان آدرس IPv6 با مقدار
\fIx\fR
و درگاه
\fIy\fR
تفسیر می‌شود\&. یک دامنه رابط اختیاری (نام رابط یا شماره آن) را می‌توان پس از یک نماد
"%"
مشخص کرد:
"[\fIx\fR]:\fIy\fR%\fIdev\fR"\&. دامنه‌های رابط فقط با آدرس‌های محلی پیوند مفید هستند، زیرا هسته در سایر موارد آن‌ها را نادیده می‌گیرد\&. توجه داشته باشید که اگر آدرسی به عنوان IPv6 مشخص شود، ممکن است همچنان بسته به تنظیم
\fIBindIPv6Only=\fR
(به زیر مراجعه کنید) سرویس را از طریق IPv4 نیز در دسترس قرار دهد\&.
.sp
اگر رشته آدرس رشته‌ای با قالب
"vsock:\fIx\fR:\fIy\fR"
باشد، به عنوان CID برابر با
\fIx\fR
روی آدرس درگاه
\fIy\fR
در خانواده
\fBAF_VSOCK\fR
خوانده می‌شود\&. شناسه CID یک شناسه عدد صحیح ۳۲ بیتی منحصر‌به‌فرد در
\fBAF_VSOCK\fR
مشابه با آدرس IP است\&. مشخص کردن CID اختیاری است و می‌تواند روی رشته خالی تنظیم شود\&.
"vsock"
را می‌توان با
"vsock\-stream"،
"vsock\-dgram"
یا
"vsock\-seqpacket"
جایگزین کرد تا استفاده از نوع سوکت متناظر اجباری شود\&.
.sp
توجه داشته باشید که
\fBSOCK_SEQPACKET\fR
(یعنی
\fIListenSequentialPacket=\fR)
تنها برای سوکت‌های
\fBAF_UNIX\fR
در دسترس است\&.
\fBSOCK_STREAM\fR
(یعنی
\fIListenStream=\fR)
هنگامی که برای سوکت‌های IP استفاده می‌شود به سوکت‌های TCP و
\fBSOCK_DGRAM\fR
(یعنی
\fIListenDatagram=\fR)
به UDP اشاره دارد\&.
.sp
این گزینه‌ها ممکن است بیش از یک‌بار مشخص شوند، که در این صورت ترافیک ورودی روی هر یک از سوکت‌ها فعال‌سازی سرویس را راه‌اندازی می‌کند و تمام سوکت‌های فهرست‌شده به سرویس منتقل می‌شوند، صرف‌نظر از اینکه روی آن‌ها ترافیک ورودی وجود داشته باشد یا نه\&. اگر رشته خالی به هر یک از این گزینه‌ها اختصاص یابد، فهرست آدرس‌ها برای گوش دادن بازنشانی می‌شود و تمام استفاده‌های قبلی از هر یک از این گزینه‌ها بی‌اثر خواهد شد\&.
.sp
همچنین هنگام استفاده از
\fIService=\fR،
داشتن بیش از یک واحد سوکت برای یک سرویس امکان‌پذیر است، و سرویس تمام سوکت‌های پیکربندی‌شده در تمام واحدهای سوکت را دریافت خواهد کرد\&. سوکت‌های پیکربندی‌شده در یک واحد به ترتیب پیکربندی منتقل می‌شوند، اما هیچ ترتیبی بین واحدهای سوکت مشخص نشده است\&.
.sp
اگر در اینجا از یک آدرس IP استفاده شود، اغلب مطلوب است که پیش از بالا آمدن و آماده به کار شدن رابطی که روی آن پیکربندی شده است، و حتی صرف‌نظر از اینکه آیا در هر نقطه‌ای بالا خواهد آمد یا خیر، روی آن گوش داده شود\&. برای مواجهه با این موضوع، توصیه می‌شود گزینه
\fIFreeBind=\fR
که در زیر توضیح داده شده تنظیم شود\&.
.RE
.PP
\fIListenFIFO=\fR
.RS 4
یک FIFO سیستم فایل (برای جزئیات به
\fBfifo\fR(7)
مراجعه کنید) را برای گوش دادن مشخص می‌کند\&. این گزینه یک مسیر مطلق سیستم فایل را به عنوان آرگومان انتظار دارد\&. رفتار آن در غیر این صورت بسیار شبیه به دستور
\fIListenDatagram=\fR
در بالا است\&.
.RE
.PP
\fIListenSpecial=\fR
.RS 4
یک فایل ویژه در سیستم فایل را برای گوش دادن مشخص می‌کند\&. این گزینه یک مسیر مطلق سیستم فایل را به عنوان آرگومان انتظار دارد\&. رفتار آن در غیر این صورت بسیار شبیه به دستور
\fIListenFIFO=\fR
در بالا است\&. از این گزینه برای باز کردن گره‌های دستگاه نویسه‌ای و همچنین فایل‌های ویژه در
/proc/
و
/sys/
استفاده کنید\&.
.RE
.PP
\fIListenNetlink=\fR
.RS 4
یک خانواده Netlink را برای ایجاد سوکت جهت گوش دادن مشخص می‌کند\&. این گزینه یک رشته کوتاه اشاره‌کننده به نام خانواده
\fBAF_NETLINK\fR
(مانند
\fIaudit\fR
یا
\fIkobject\-uevent\fR)
را به عنوان آرگومان انتظار دارد، که اختیاری می‌تواند با یک فضای خالی و به دنبال آن یک عدد صحیح گروه چندپخشی پسوند یابد\&. رفتار آن در غیر این صورت بسیار شبیه به دستور
\fIListenDatagram=\fR
در بالا است\&.
.RE
.PP
\fIListenMessageQueue=\fR
.RS 4
نام یک صف پیام POSIX را برای گوش دادن مشخص می‌کند (برای جزئیات به
\fBmq_overview\fR(7)
مراجعه کنید)\&. این گزینه یک نام معتبر صف پیام (یعنی شروع‌شونده با
"/")
را انتظار دارد\&. رفتار آن در غیر این صورت بسیار شبیه به دستور
\fIListenFIFO=\fR
در بالا است\&. در لینوکس توصیف‌کننده‌های صف پیام در واقع توصیف‌کننده‌های فایل هستند و می‌توانند بین فرآیندها به ارث برسند\&.
.RE
.PP
\fIListenUSBFunction=\fR
.RS 4
مکان نقاط پایانی
\m[blue]\fBUSB FunctionFS\fR\m[]\&\s-2\u[1]\d\s+2
را برای گوش دادن، جهت پیاده‌سازی عملکردهای گجت USB مشخص می‌کند\&. این گزینه یک مسیر مطلق سیستم فایل از یک نقطه سوار کردن FunctionFS را به عنوان آرگومان انتظار دارد\&. رفتار آن در غیر این صورت بسیار شبیه به دستور
\fIListenFIFO=\fR
در بالا است\&. از این گزینه برای باز کردن نقطه پایانی FunctionFS با نام
ep0
استفاده کنید\&. هنگام استفاده از این گزینه، سرویس فعال‌شده باید گزینه‌های
\fIUSBFunctionDescriptors=\fR
و
\fIUSBFunctionStrings=\fR
را تنظیم کرده باشد\&.
.sp
در نسخه ۲۲۷ اضافه شد\&.
.RE
.PP
\fISocketProtocol=\fR
.RS 4
یکی از مقادیر
\fBudplite\fR،
\fBsctp\fR
یا
\fBmptcp\fR
را می‌پذیرد\&. سوکت به‌ترتیب از پروتکل UDP\-Lite (\fBIPPROTO_UDPLITE\fR)، پروتکل SCTP (\fBIPPROTO_SCTP\fR) یا پروتکل MPTCP (\fBIPPROTO_MPTCP\fR) استفاده خواهد کرد\&.
.sp
در نسخه ۲۲۹ اضافه شد\&.
.RE
.PP
\fIBindIPv6Only=\fR
.RS 4
یکی از مقادیر
\fBdefault\fR،
\fBboth\fR
یا
\fBipv6\-only\fR
را می‌پذیرد\&. گزینه سوکت IPV6_V6ONLY را کنترل می‌کند (برای جزئیات به
\fBipv6\fR(7)
مراجعه کنید)\&. اگر روی
\fBboth\fR
باشد، سوکت‌های IPv6 مقیدشده از طریق هر دو IPv4 و IPv6 قابل دسترسی خواهند بود\&. اگر روی
\fBipv6\-only\fR
باشد، آن‌ها تنها از طریق IPv6 قابل دسترسی خواهند بود\&. اگر روی
\fBdefault\fR
باشد (که پیش‌فرض است، شگفتا!)، از تنظیم پیش‌فرض سراسری سیستم استفاده می‌شود، همان‌طور که توسط
/proc/sys/net/ipv6/bindv6only
کنترل می‌شود، که آن هم به نوبه خود به‌طور پیش‌فرض معادل
\fBboth\fR
است\&.
.RE
.PP
\fIBacklog=\fR
.RS 4
یک آرگومان عدد صحیح ۳۲ بیتی بدون علامت می‌پذیرد\&. تعداد اتصالاتی را که هنوز پذیرفته نشده‌اند و در صف قرار می‌گیرند مشخص می‌کند\&. این تنظیم تنها برای سوکت‌های جریانی و بسته‌ای متوالی اهمیت دارد\&. برای جزئیات به
\fBlisten\fR(2)
مراجعه کنید\&. مقدار پیش‌فرض 4294967295 است\&. توجه داشته باشید که این مقدار به‌طور ضمنی توسط sysctl با نام
"net\&.core\&.somaxconn"
محدود می‌شود، که معمولاً مقدار پیش‌فرض 4096 دارد، بنابراین معمولاً این مقدار sysctl است که در عمل اهمیت دارد\&.
.RE
.PP
\fIBindToDevice=\fR
.RS 4
نام یک رابط شبکه را برای مقید کردن این سوکت به آن مشخص می‌کند\&. در صورت تنظیم، ترافیک تنها از رابط‌های شبکه مشخص‌شده پذیرفته خواهد شد\&. این گزینه سوکت
\fBSO_BINDTODEVICE\fR
را کنترل می‌کند (برای جزئیات به
\fBsocket\fR(7)
مراجعه کنید)\&. اگر از این گزینه استفاده شود، یک وابستگی ضمنی از این واحد سوکت نسبت به واحد دستگاه رابط شبکه ایجاد می‌شود (به
\fBsystemd.device\fR(5)
مراجعه کنید)\&. توجه داشته باشید که تنظیم این پارامتر ممکن است منجر به اضافه شدن وابستگی‌های اضافی به واحد شود (به بالا مراجعه کنید)\&.
.RE
.PP
\fISocketUser=\fR, \fISocketGroup=\fR
.RS 4
نام یک کاربر/گروه یونیکس را می‌پذیرد\&. در صورت تعیین، مالکیت تمام سوکت‌های
\fBAF_UNIX\fR،
گره‌های FIFO و صف‌های پیام متعلق به کاربر و گروه مشخص‌شده خواهد بود\&. اگر تنظیم نشود (پیش‌فرض)، گره‌ها متعلق به کاربر/گروه root خواهند بود (اگر در زمینه سیستمی اجرا شود) یا متعلق به کاربر/گروه فراخواننده (اگر در زمینه کاربری اجرا شود)\&. اگر فقط یک کاربر مشخص شود اما هیچ گروهی مشخص نشود، آنگاه گروه از گروه پیش‌فرض کاربر مشتق می‌شود\&.
.sp
در نسخه ۲۱۴ اضافه شد\&.
.RE
.PP
\fISocketMode=\fR
.RS 4
در صورت گوش دادن روی یک سوکت سیستم فایل، FIFO یا صف پیام، این گزینه حالت دسترسی به سیستم فایل را که هنگام ایجاد گره فایل استفاده می‌شود مشخص می‌کند\&. یک حالت دسترسی را در نمادگذاری هشت‌هشتی می‌پذیرد\&. مقدار پیش‌فرض 0666 است\&.
.RE
.PP
\fIDirectoryMode=\fR
.RS 4
در صورت گوش دادن روی یک سوکت سیستم فایل یا FIFO، دایرکتوری‌های والد در صورت نیاز به‌طور خودکار ایجاد می‌شوند\&. این گزینه حالت دسترسی سیستم فایل را که هنگام ایجاد این دایرکتوری‌ها استفاده می‌شود مشخص می‌کند\&. یک حالت دسترسی را در نمادگذاری هشت‌هشتی می‌پذیرد\&. مقدار پیش‌فرض 0755 است\&.
.RE
.PP
\fIAccept=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. اگر yes باشد، برای هر اتصال ورودی یک نمونه سرویس ایجاد می‌شود و تنها سوکت اتصال به آن منتقل می‌گردد\&. اگر no باشد، تمام سوکت‌های شنونده خود به واحد سرویس راه‌اندازی‌شده منتقل می‌شوند و تنها یک واحد سرویس برای تمام اتصالات ایجاد می‌شود (همچنین به بالا مراجعه کنید)\&. این مقدار برای سوکت‌های دیتاگرام و FIFOها که در آن‌ها یک واحد سرویس منفرد بدون قید و شرط تمام ترافیک ورودی را مدیریت می‌کند نادیده گرفته می‌شود\&. مقدار پیش‌فرض
\fBno\fR
است\&.
.sp
معمولاً، برای سرویس‌های حساس به عملکرد، انتخاب
\fBAccept=no\fR
ترجیح داده می‌شود، زیرا به این ترتیب تنها اتصال اول باید هزینه منابع فعال‌سازی را بپردازد\&. از سوی دیگر، برای سرویس‌هایی که به ندرت استفاده می‌شوند
\fBAccept=yes\fR
می‌تواند ارجح باشد زیرا پیاده‌سازی را ساده می‌کند (زیرا کد برنامه سرویس تنها باید یک اتصال منفرد را به جای مدیریت چندین اتصال پردازش کند) و امنیت قوی‌تری را فراهم می‌سازد (زیرا می‌توان از گزینه‌های گوناگون سندباکس برای جداسازی اتصالات موازی از یکدیگر استفاده کرد، چرا که هر یک توسط یک نمونه سرویس و فرآیند جداگانه سرویس‌دهی می‌شوند)\&.
.sp
سرویسی که روی یک سوکت
\fBAF_UNIX\fR
گوش می‌دهد می‌تواند، اما نیازی ندارد که، پیش از خروج تابع
\fBclose\fR(2)
را روی سوکت دریافت‌شده فراخوانی کند\&. با این حال، نباید پیوند سوکت را از سیستم فایل لغو کند\&. نباید
\fBshutdown\fR(2)
را روی سوکت‌هایی که با
\fIAccept=no\fR
دریافت کرده است فراخوانی کند، اما می‌تواند این کار را برای سوکت‌هایی که با تنظیم
\fIAccept=yes\fR
دریافت کرده انجام دهد\&.
.sp
تنظیم
\fIAccept=yes\fR
به‌ویژه برای اجازه دادن به دیمن‌هایی که برای استفاده با
\fBinetd\fR(8)
طراحی شده‌اند تا بدون تغییر با فعال‌سازی سوکت systemd کار کنند بسیار مفید است\&.
.sp
توجه داشته باشید که بسته به این تنظیم، سرویس‌های فعال‌شده توسط واحدهای این نوع یا سرویس‌های عادی هستند (در صورت
\fIAccept=\fR\fBno\fR)
یا نمونه‌هایی از سرویس‌های الگودار (در صورت
\fIAccept=\fR\fByes\fR)\&. برای بحث دقیق‌تر درباره قوانین نام‌گذاری سرویس‌های راه‌اندازی‌شده، بخش توضیحات را در بالا ببینید\&.
.sp
برای اتصالات IPv4 و IPv6، متغیر محیطی
\fI$REMOTE_ADDR\fR
شامل آدرس IP راه دور خواهد بود و
\fI$REMOTE_PORT\fR
شامل شماره درگاه راه دور خواهد بود\&. این دو متغیر متناظر با متغیرهای تعریف‌شده توسط واسط CGI برای سرویس‌های وب هستند (به
\m[blue]\fBRFC 3875\fR\m[]\&\s-2\u[2]\d\s+2
مراجعه کنید)\&.
.sp
برای اتصالات سوکت
\fBAF_UNIX\fR،
متغیر محیطی
\fI$REMOTE_ADDR\fR
یا شامل مسیر سیستم فایل سوکت راه دور که با یک ممیز ("/") شروع می‌شود خواهد بود یا شامل آدرس آن در فضای‌نام انتزاعی که با علامت اتساین ("@") شروع می‌شود\&. اگر سوکت بدون نام باشد،
\fI$REMOTE_ADDR\fR
تنظیم نخواهد شد\&.
.sp
اگر
\fIAccept=yes\fR
استفاده شود، فرآیند سرویس فعال‌شده متغیر محیطی
\fI$SO_COOKIE\fR
را برابر با کوکی سوکت لینوکس، قالب‌بندی‌شده به صورت یک عدد صحیح ده‌دهی، تنظیم خواهد کرد\&. کوکی سوکت در غیر این صورت می‌تواند از طریق
\fBgetsockopt\fR(7)
به دست آید\&.
.sp
توصیه می‌شود
\fICollectMode=inactive\-or\-failed\fR
را برای نمونه‌های سرویس فعال‌شده از طریق
\fIAccept=yes\fR
تنظیم کنید تا اطمینان حاصل شود که سرویس‌های اتصال ناموفق پاک‌سازی شده و از حافظه آزاد می‌شوند و انباشته نمی‌گردند\&.
.RE
.PP
\fIWritable=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. فقط می‌تواند در ترکیب با
\fIListenSpecial=\fR
استفاده شود\&. اگر true باشد، فایل ویژه مشخص‌شده در حالت خواندن-نوشتن باز می‌شود؛ اگر false باشد، در حالت فقط‌خواندنی باز می‌شود\&. مقدار پیش‌فرض false است\&.
.sp
در نسخه ۲۲۷ اضافه شد\&.
.RE
.PP
\fIFlushPending=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. فقط زمانی می‌تواند استفاده شود که
\fBAccept=no\fR
باشد\&. اگر yes باشد، بافرهای سوکت پس از خروج سرویس راه‌اندازی‌شده پاک می‌شوند\&. این کار باعث می‌شود هرگونه داده معلق پاک شود و هرگونه اتصال ورودی معلق رد گردد\&. اگر no باشد، بافرهای سوکت پاک نخواهند شد و به سرویس اجازه داده می‌شود پس از راه‌اندازی مجدد، اتصالات معلق را پردازش کند که رفتار معمولاً مورد انتظار است\&. مقدار پیش‌فرض
\fBno\fR
است\&.
.sp
در نسخه ۲۴۷ اضافه شد\&.
.RE
.PP
\fIMaxConnections=\fR
.RS 4
حداکثر تعداد اتصالاتی که در هنگام تنظیم
\fBAccept=yes\fR
می‌توان به‌طور همزمان نمونه‌های سرویس را برای آن‌ها اجرا کرد\&. اگر اتصالات همزمان بیشتری وارد شوند، تا زمانی که حداقل یک اتصال موجود خاتمه یابد، رد خواهند شد\&. این تنظیم هیچ تأثیری بر سوکت‌های پیکربندی‌شده با
\fBAccept=no\fR
یا سوکت‌های دیتاگرام ندارد\&. مقدار پیش‌فرض 64 است\&.
.RE
.PP
\fIMaxConnectionsPerSource=\fR
.RS 4
حداکثر تعداد اتصالات برای یک سرویس به ازای هر آدرس IP مبدأ (در مورد IPv4/IPv6)، به ازای هر CID مبدأ (در مورد
\fBAF_VSOCK\fR)،
یا به ازای هر UID مبدأ (در مورد
\fBAF_UNIX\fR)\&.
این دستور بسیار شبیه به دستور
\fIMaxConnections=\fR
در بالا است\&. مقدار پیش‌فرض 0 است، یعنی غیرفعال است\&.
.sp
در نسخه ۲۳۲ اضافه شد\&.
.RE
.PP
\fIKeepAlive=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. اگر true باشد، پشته TCP/IP پس از ۲ ساعت (بسته به پیکربندی
/proc/sys/net/ipv4/tcp_keepalive_time)
یک پیام زنده نگه‌داشتن برای تمام جریان‌های TCP پذیرفته‌شده روی این سوکت ارسال می‌کند\&. این گزینه سوکت
\fBSO_KEEPALIVE\fR
را کنترل می‌کند (برای جزئیات به
\fBsocket\fR(7)
و
\m[blue]\fBTCP Keepalive HOWTO\fR\m[]\&\s-2\u[3]\d\s+2
مراجعه کنید)\&. مقدار پیش‌فرض
\fBfalse\fR
است\&.
.RE
.PP
\fIKeepAliveTimeSec=\fR
.RS 4
زمان (به ثانیه) را به عنوان آرگومان می‌پذیرد\&. مدت زمانی که اتصال باید پیش از شروع ارسال کاوش‌های زنده نگه‌داشتن توسط TCP بیکار بماند\&. این گزینه سوکت TCP_KEEPIDLE را کنترل می‌کند (برای جزئیات به
\fBsocket\fR(7)
و
\m[blue]\fBTCP Keepalive HOWTO\fR\m[]\&\s-2\u[3]\d\s+2
مراجعه کنید)\&. مقدار پیش‌فرض 7200 ثانیه (۲ ساعت) است\&.
.sp
در نسخه ۲۱۶ اضافه شد\&.
.RE
.PP
\fIKeepAliveIntervalSec=\fR
.RS 4
زمان (به ثانیه) را به عنوان آرگومان بین هر یک از کاوش‌های زنده نگه‌داشتن می‌پذیرد، در صورتی که گزینه سوکت
\fBSO_KEEPALIVE\fR
روی این سوکت تنظیم شده باشد\&. این گزینه سوکت
\fBTCP_KEEPINTVL\fR
را کنترل می‌کند (برای جزئیات به
\fBsocket\fR(7)
و
\m[blue]\fBTCP Keepalive HOWTO\fR\m[]\&\s-2\u[3]\d\s+2
مراجعه کنید)\&. مقدار پیش‌فرض 75 ثانیه است\&.
.sp
در نسخه ۲۱۶ اضافه شد\&.
.RE
.PP
\fIKeepAliveProbes=\fR
.RS 4
یک عدد صحیح را به عنوان آرگومان می‌پذیرد\&. تعداد کاوش‌های تأییدن‌شده‌ای است که باید پیش از مرده در نظر گرفتن اتصال و اطلاع‌رسانی به لایه کاربرد ارسال شود\&. این گزینه سوکت TCP_KEEPCNT را کنترل می‌کند (برای جزئیات به
\fBsocket\fR(7)
و
\m[blue]\fBTCP Keepalive HOWTO\fR\m[]\&\s-2\u[3]\d\s+2
مراجعه کنید)\&. مقدار پیش‌فرض 9 است\&.
.sp
در نسخه ۲۱۶ اضافه شد\&.
.RE
.PP
\fINoDelay=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. الگوریتم نیگل در TCP با ترکیب تعدادی از پیام‌های خروجی کوچک و ارسال یکجای همه آن‌ها کار می‌کند\&. این گزینه سوکت TCP_NODELAY را کنترل می‌کند (به
\fBtcp\fR(7)
مراجعه کنید)\&. مقدار پیش‌فرض
\fBfalse\fR
است\&.
.sp
در نسخه ۲۱۶ اضافه شد\&.
.RE
.PP
\fIPriority=\fR
.RS 4
یک آرگومان عدد صحیح برای کنترل اولویت تمام ترافیک ارسال‌شده از این سوکت می‌پذیرد\&. این گزینه سوکت
\fBSO_PRIORITY\fR
را کنترل می‌کند (برای جزئیات به
\fBsocket\fR(7)
مراجعه کنید)\&.
.RE
.PP
\fIDeferAcceptSec=\fR
.RS 4
زمان (به ثانیه) را به عنوان آرگومان می‌پذیرد\&. در صورت تنظیم، فرآیند شنونده تنها زمانی بیدار می‌شود که داده‌ها روی سوکت وارد شوند، نه بلافاصله پس از برقراری اتصال\&. هنگامی که این گزینه تنظیم شود، از گزینه سوکت
\fBTCP_DEFER_ACCEPT\fR
استفاده خواهد شد (به
\fBtcp\fR(7)
مراجعه کنید)، و هسته بسته‌های اولیه ACK فاقد هرگونه داده را نادیده می‌گیرد\&. این آرگومان مقدار تقریبی زمانی را که هسته باید پیش از بازگشت به رفتار عادی پذیرش بسته‌های ACK خالی منتظر داده‌های ورودی بماند مشخص می‌کند\&. این گزینه برای پروتکل‌هایی که در آن‌ها کارخواه ابتدا داده‌ها را ارسال می‌کند (مانند HTTP، بر خلاف SMTP) سودمند است، زیرا فرآیند کارساز پیش از آنکه بتواند اقدامی انجام دهد، بیهوده بیدار نمی‌شود\&.
.sp
اگر کارخواه نیز از گزینه
\fBTCP_DEFER_ACCEPT\fR
استفاده کند، ممکن است تأخیر اتصال اولیه کاهش یابد، زیرا هسته در بسته نهایی برقرارکننده اتصال (بسته سوم در دست‌تکانی سه‌مرحله‌ای) داده‌ها را ارسال خواهد کرد\&.
.sp
به‌طور پیش‌فرض غیرفعال است\&.
.sp
در نسخه ۲۱۶ اضافه شد\&.
.RE
.PP
\fIReceiveBuffer=\fR, \fISendBuffer=\fR
.RS 4
یک آرگومان عدد صحیح را برای کنترل اندازه‌های بافر دریافت یا ارسال این سوکت، به‌ترتیب، می‌پذیرد\&. این گزینه‌های سوکت
\fBSO_RCVBUF\fR
و
\fBSO_SNDBUF\fR
را کنترل می‌کند (برای جزئیات به
\fBsocket\fR(7)
مراجعه کنید)\&. پسوندهای معمول K، M، G پشتیبانی می‌شوند و بر مبنای 1024 درک می‌گردند\&.
.RE
.PP
\fIIPTOS=\fR
.RS 4
یک آرگومان عدد صحیح را برای کنترل فیلد نوع خدمت IP برای بسته‌های تولیدشده از این سوکت می‌پذیرد\&. این گزینه سوکت
\fBIP_TOS\fR
را کنترل می‌کند (برای جزئیات به
\fBip\fR(7)
مراجعه کنید)\&. می‌توان یک رشته عددی یا یکی از مقادیر
\fBlow\-delay\fR،
\fBthroughput\fR،
\fBreliability\fR
یا
\fBlow\-cost\fR
را مشخص کرد\&.
.RE
.PP
\fIIPTTL=\fR
.RS 4
یک آرگومان عدد صحیح را برای کنترل فیلد طول عمر IPv4 / شمارش جهش IPv6 برای بسته‌های تولیدشده از این سوکت می‌پذیرد\&. این گزینه‌های سوکت
\fBIP_TTL\fR/\fBIPV6_UNICAST_HOPS\fR
را تنظیم می‌کند (برای جزئیات به
\fBip\fR(7)
و
\fBipv6\fR(7)
مراجعه کنید)\&.
.RE
.PP
\fIMark=\fR
.RS 4
یک مقدار عدد صحیح می‌پذیرد\&. نشان دیوار آتش بسته‌های تولیدشده توسط این سوکت را کنترل می‌کند\&. این می‌تواند در منطق دیوار آتش برای فیلتر کردن بسته‌های حاصل از این سوکت استفاده شود\&. این گزینه سوکت
\fBSO_MARK\fR
را تنظیم می‌کند\&. برای جزئیات به
\fBiptables\fR(8)
مراجعه کنید\&.
.RE
.PP
\fIReusePort=\fR
.RS 4
یک مقدار بولی می‌پذیرد\&. اگر true باشد، به چندین
\fBbind\fR(2)
روی این درگاه TCP یا UDP اجازه می‌دهد\&. این گزینه سوکت
\fBSO_REUSEPORT\fR
را کنترل می‌کند\&. برای جزئیات به
\fBsocket\fR(7)
مراجعه کنید\&.
.sp
در نسخه ۲۰۶ اضافه شد\&.
.RE
.PP
\fISmackLabel=\fR, \fISmackLabelIPIn=\fR, \fISmackLabelIPOut=\fR
.RS 4
یک مقدار رشته‌ای می‌پذیرد\&. ویژگی‌های گسترش‌یافته
"security\&.SMACK64"،
"security\&.SMACK64IPIN"
و
"security\&.SMACK64IPOUT"
را به‌ترتیب کنترل می‌کند، یعنی برچسب امنیتی FIFO، یا برچسب امنیتی برای اتصالات ورودی یا خروجی سوکت به‌ترتیب\&. برای جزئیات به
\m[blue]\fBSmack\fR\m[]\&\s-2\u[4]\d\s+2
مراجعه کنید\&.
.sp
در نسخه ۱۹۶ اضافه شد\&.
.RE
.PP
\fISELinuxContextFromNet=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. وقتی true باشد، systemd تلاش خواهد کرد برچسب SELinux استفاده‌شده برای سرویس نمونه‌سازی‌شده را از روی اطلاعات ارائه‌شده توسط طرف مقابل از طریق شبکه تشخیص دهد\&. توجه داشته باشید که از اطلاعات ارائه‌شده توسط همتا فقط سطح امنیت استفاده می‌شود\&. سایر بخش‌های زمینه SELinux حاصل یا از باینری هدف که عملاً توسط واحد سوکت راه‌اندازی شده است، یا از مقدار گزینه
\fISELinuxContext=\fR
سرچشمه می‌گیرند\&. این گزینه پیکربندی تنها زمانی اعمال می‌شود که به سرویس فعال‌شده یک توصیف‌کننده فایل سوکت منفرد منتقل شود، یعنی نمونه‌های سرویسی که ورودی استاندارد متصل به یک سوکت دارند یا سرویس‌هایی که دقیقاً توسط یک واحد سوکت راه‌اندازی شده‌اند\&. همچنین توجه داشته باشید که این گزینه تنها زمانی مفید است که سیاست SELinux از نوع MLS/MCS مستقر شده باشد\&. مقدار پیش‌فرض
"false"
است\&.
.sp
در نسخه ۲۱۷ اضافه شد\&.
.RE
.PP
\fIPipeSize=\fR
.RS 4
اندازه‌ای بر حسب بایت می‌پذیرد\&. اندازه بافر لوله را برای FIFOهای پیکربندی‌شده در این واحد سوکت کنترل می‌کند\&. برای جزئیات به
\fBfcntl\fR(2)
مراجعه کنید\&. پسوندهای معمول K، M، G پشتیبانی می‌شوند و بر مبنای 1024 درک می‌گردند\&.
.RE
.PP
\fIMessageQueueMaxMessages=\fR, \fIMessageQueueMessageSize=\fR
.RS 4
این دو تنظیم مقادیر عدد صحیح می‌پذیرند و به‌ترتیب فیلد mq_maxmsg یا فیلد mq_msgsize را هنگام ایجاد صف پیام کنترل می‌کنند\&. توجه داشته باشید که یا هیچ‌کدام یا هر دوی این متغیرها باید تنظیم شوند\&. برای جزئیات به
\fBmq_setattr\fR(3)
مراجعه کنید\&.
.RE
.PP
\fIFreeBind=\fR
.RS 4
یک مقدار بولی می‌پذیرد\&. این که آیا سوکت می‌تواند به آدرس‌های IP غیرمحلی مقید شود یا خیر را کنترل می‌کند\&. این برای پیکربندی سوکت‌های شنونده روی آدرس‌های IP خاص پیش از آنکه آن آدرس‌های IP با موفقیت روی یک رابط شبکه پیکربندی شوند مفید است\&. این گزینه سوکت
\fBIP_FREEBIND\fR/\fBIPV6_FREEBIND\fR
را تنظیم می‌کند\&. به دلایل تاب‌آوری و پایداری توصیه می‌شود هر زمان که سوکتی را به یک آدرس IP خاص مقید می‌کنید از این گزینه استفاده نمایید\&. مقدار پیش‌فرض
\fBfalse\fR
است\&.
.RE
.PP
\fITransparent=\fR
.RS 4
یک مقدار بولی می‌پذیرد\&. گزینه سوکت
\fBIP_TRANSPARENT\fR/\fBIPV6_TRANSPARENT\fR
را کنترل می‌کند\&. مقدار پیش‌فرض
\fBfalse\fR
است\&.
.RE
.PP
\fIBroadcast=\fR
.RS 4
یک مقدار بولی می‌پذیرد\&. این گزینه سوکت
\fBSO_BROADCAST\fR
را کنترل می‌کند، که به دیتاگرام‌های همگانی اجازه می‌دهد از این سوکت ارسال شوند\&. مقدار پیش‌فرض
\fBfalse\fR
است\&.
.RE
.PP
\fIPassCredentials=\fR
.RS 4
یک مقدار بولی می‌پذیرد\&. این گزینه سوکت
\fBSO_PASSCRED\fR
را کنترل می‌کند، که به سوکت‌های
\fBAF_UNIX\fR
اجازه می‌دهد اطلاعات هویتی فرآیند فرستنده را در یک پیام کمکی دریافت کنند\&. مقدار پیش‌فرض
\fBfalse\fR
است\&.
.RE
.PP
\fIPassPIDFD=\fR
.RS 4
یک مقدار بولی می‌پذیرد\&. این گزینه سوکت
\fBSO_PASSPIDFD\fR
را کنترل می‌کند، که به سوکت‌های
\fBAF_UNIX\fR
اجازه می‌دهد pidfd فرآیند فرستنده را در یک پیام کمکی دریافت کنند\&. مقدار پیش‌فرض
\fBfalse\fR
است\&.
.sp
در نسخه ۲۵۸ اضافه شد\&.
.RE
.PP
\fIPassSecurity=\fR
.RS 4
یک مقدار بولی می‌پذیرد\&. این گزینه سوکت
\fBSO_PASSSEC\fR
را کنترل می‌کند، که به سوکت‌های
\fBAF_UNIX\fR
اجازه می‌دهد زمینه امنیتی فرآیند فرستنده را در یک پیام کمکی دریافت کنند\&. مقدار پیش‌فرض
\fBfalse\fR
است\&.
.RE
.PP
\fIPassPacketInfo=\fR
.RS 4
یک مقدار بولی می‌پذیرد\&. این گزینه‌های سوکت
\fBIP_PKTINFO\fR،
\fBIPV6_RECVPKTINFO\fR،
\fBNETLINK_PKTINFO\fR
یا
\fBPACKET_AUXDATA\fR
را کنترل می‌کند، که دریافت فراداده‌های اضافی به ازای هر بسته را به صورت پیام کمکی، روی سوکت‌های
\fBAF_INET\fR،
\fBAF_INET6\fR،
\fBAF_UNIX\fR
و
\fBAF_PACKET\fR
فعال می‌سازد\&. مقدار پیش‌فرض
\fBfalse\fR
است\&.
.sp
در نسخه ۲۴۶ اضافه شد\&.
.RE
.PP
\fIAcceptFileDescriptors=\fR
.RS 4
یک مقدار بولی می‌پذیرد\&. این گزینه سوکت
\fBSO_PASSRIGHTS\fR
را کنترل می‌کند، که در صورت غیرفعال بودن، طرف مقابل را از ارسال پیام‌های کمکی
\fBSCM_RIGHTS\fR
(همان توصیف‌کننده‌های فایل) از طریق سوکت‌های
\fBAF_UNIX\fR
منع می‌کند\&. مقدار پیش‌فرض
\fBtrue\fR
است\&.
.sp
در نسخه ۲۵۸ اضافه شد\&.
.RE
.PP
\fITimestamping=\fR
.RS 4
یکی از مقادیر
"off"،
"us"
(نام مستعار:
"usec"،
"μs") یا
"ns"
(نام مستعار:
"nsec")
را می‌پذیرد\&. این گزینه‌های سوکت
\fBSO_TIMESTAMP\fR
یا
\fBSO_TIMESTAMPNS\fR
را کنترل می‌کند، و فعال می‌سازد که آیا ترافیک ورودی شبکه باید فراداده برچسب زمانی را به همراه داشته باشد یا خیر\&. مقدار پیش‌فرض
\fBoff\fR
است\&.
.sp
در نسخه ۲۴۷ اضافه شد\&.
.RE
.PP
\fITCPCongestion=\fR
.RS 4
یک مقدار رشته‌ای می‌پذیرد\&. الگوریتم ازدحام TCP استفاده‌شده توسط این سوکت را کنترل می‌کند\&. باید یکی از مقادیر
"westwood"،
"reno"،
"cubic"،
"lp"
یا هر الگوریتم در دسترس دیگری باشد که توسط پشته IP پشتیبانی می‌شود\&. این تنظیم تنها برای سوکت‌های جریانی اعمال می‌شود\&.
.RE
.PP
\fIExecStartPre=\fR, \fIExecStartPost=\fR
.RS 4
یک یا چند خط دستور می‌پذیرد، که به‌ترتیب قبل یا بعد از ایجاد و مقید شدن سوکت‌ها/FIFOهای شنونده اجرا می‌شوند\&. اولین بخش از خط دستور باید یک نام فایل مطلق باشد، و به دنبال آن آرگومان‌های فرآیند بیایند\&. چندین خط دستور را می‌توان با پیروی از همان شیوه‌ای که برای
\fIExecStartPre=\fR
در فایل‌های واحد سرویس استفاده می‌شود مشخص کرد\&.
.RE
.PP
\fIExecStopPre=\fR, \fIExecStopPost=\fR
.RS 4
دستورات اضافی که به‌ترتیب قبل یا بعد از بسته شدن و حذف سوکت‌ها/FIFOهای شنونده اجرا می‌شوند\&. چندین خط دستور را می‌توان با پیروی از همان شیوه‌ای که برای
\fIExecStartPre=\fR
در فایل‌های واحد سرویس استفاده می‌شود مشخص کرد\&.
.RE
.PP
\fITimeoutSec=\fR
.RS 4
مدت زمان انتظار برای پایان یافتن دستورات مشخص‌شده در
\fIExecStartPre=\fR،
\fIExecStartPost=\fR،
\fIExecStopPre=\fR
و
\fIExecStopPost=\fR
را پیکربندی می‌کند\&. اگر دستوری در مدت زمان پیکربندی‌شده خارج نشود، سوکت ناموفق در نظر گرفته شده و مجدداً خاموش می‌شود\&. تمام دستوراتی که هنوز در حال اجرا هستند به اجبار از طریق
\fBSIGTERM\fR
خاتمه می‌یابند، و پس از تأخیر دیگری به همین میزان با
\fBSIGKILL\fR\&.
(به
\fBKillMode=\fR
در
\fBsystemd.kill\fR(5)
مراجعه کنید)\&. مقداری بدون واحد به ثانیه، یا مقداری با بازه زمانی مانند "5min 20s" می‌پذیرد\&. برای غیرفعال کردن منطق مهلت زمانی،
"0"
را بدهید\&. مقدار پیش‌فرض برابر با
\fIDefaultTimeoutStartSec=\fR
از فایل پیکربندی مدیر است (به
\fBsystemd-system.conf\fR(5)
مراجعه کنید)\&.
.RE
.PP
\fIService=\fR
.RS 4
نام واحد سرویسی را که باید با ترافیک ورودی فعال شود مشخص می‌کند\&. این تنظیم تنها برای سوکت‌هایی با
\fIAccept=no\fR
مجاز است\&. مقدار پیش‌فرض آن همان سرویسی است که نامی مشابه سوکت دارد (با پسوند جایگزین‌شده)\&. در بیشتر موارد، استفاده از این گزینه نباید ضروری باشد\&. توجه داشته باشید که تنظیم این پارامتر ممکن است منجر به اضافه شدن وابستگی‌های اضافی به واحد شود (به بالا مراجعه کنید)\&.
.RE
.PP
\fIRemoveOnStop=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. در صورت فعال بودن، هرگونه گره فایلی که توسط این واحد سوکت ایجاد شده است با متوقف شدن آن حذف می‌شود\&. این در مورد سوکت‌های
\fBAF_UNIX\fR
در سیستم فایل، صف‌های پیام POSIX، FIFOها، و همچنین هرگونه پیوند نمادین به آن‌ها که با
\fISymlinks=\fR
پیکربندی شده است اعمال می‌شود\&. معمولاً استفاده از این گزینه نباید ضروری باشد و توصیه نمی‌شود، زیرا سرویس‌ها ممکن است پس از خاتمه واحد سوکت همچنان به اجرا ادامه دهند و باید همچنان بتوان از طریق گره سیستم فایل با آن‌ها ارتباط برقرار کرد\&. مقدار پیش‌فرض off است\&.
.sp
در نسخه ۲۱۴ اضافه شد\&.
.RE
.PP
\fISymlinks=\fR
.RS 4
فهرستی از مسیرهای سیستم فایل را می‌پذیرد\&. مسیرهای مشخص‌شده به عنوان پیوندهای نمادین به مسیر سوکت
\fBAF_UNIX\fR
یا مسیر FIFO این واحد سوکت ایجاد خواهند شد\&. اگر این تنظیم استفاده شود، تنها یک سوکت
\fBAF_UNIX\fR
در سیستم فایل یا یک FIFO می‌تواند برای واحد سوکت پیکربندی شود\&. از این گزینه برای مدیریت یک یا چند نام مستعار پیوند نمادین برای یک سوکت، با متصل کردن چرخه عمر آن‌ها به یکدیگر استفاده کنید\&. توجه داشته باشید که اگر ایجاد یک پیوند نمادین با شکست مواجه شود، این امر برای واحد سوکت مهلک در نظر گرفته نمی‌شود و واحد سوکت ممکن است همچنان شروع شود\&. اگر یک رشته خالی اختصاص داده شود، فهرست مسیرها بازنشانی می‌شود\&. مقدار پیش‌فرض یک فهرست خالی است\&.
.sp
در نسخه ۲۱۴ اضافه شد\&.
.RE
.PP
\fIFileDescriptorName=\fR
.RS 4
نامی را به تمام توصیف‌کننده‌های فایلی که این واحد سوکت کپسوله‌سازی می‌کند اختصاص می‌دهد\&. این برای کمک به سرویس‌های فعال‌شده در شناسایی توصیف‌کننده‌های فایل خاص در صورتی که چندین توصیف‌کننده منتقل شوند مفید است\&. سرویس‌ها می‌توانند از فراخوانی
\fBsd_listen_fds_with_names\fR(3)
برای به دست آوردن نام‌های پیکربندی‌شده برای توصیف‌کننده‌های فایل دریافت‌شده استفاده کنند\&. نام‌ها ممکن است شامل هر نویسه ASCII باشند، اما باید نویسه‌های کنترلی و
":"
را حذف کنند، و باید حداکثر ۲۵۵ نویسه طول داشته باشند\&. اگر از این تنظیم استفاده نشود، نام توصیف‌کننده فایل در صورت
\fIAccept=no\fR
به‌طور پیش‌فرض همان نام واحد سوکت (شامل پسوند
\&.socket
آن) خواهد بود، و در غیر این صورت
"connection"
است\&.
.sp
در نسخه ۲۲۷ اضافه شد\&.
.RE
.PP
\fITriggerLimitIntervalSec=\fR, \fITriggerLimitBurst=\fR
.RS 4
محدودیتی را برای این که این واحد سوکت در یک بازه زمانی خاص چند بار می‌تواند فعال شود پیکربندی می‌کند\&. تنظیم
\fITriggerLimitIntervalSec=\fR
می‌تواند برای پیکربندی طول بازه زمانی با واحدهای زمانی معمول
"us"،
"ms"،
"s"،
"min"،
"h"
و \&... استفاده شود و مقدار پیش‌فرض آن 2s است (برای جزئیات درباره واحدهای زمانی مختلفِ قابل فهم به
\fBsystemd.time\fR(7)
مراجعه کنید)\&. تنظیم
\fITriggerLimitBurst=\fR
یک مقدار عدد صحیح مثبت می‌پذیرد و تعداد فعال‌سازی‌های مجاز در هر بازه زمانی را مشخص می‌کند، و مقدار پیش‌فرض آن برای سوکت‌های با
\fIAccept=yes\fR
برابر با 200 است (بنابراین به‌طور پیش‌فرض ۲۰۰ فعال‌سازی در هر ۲ ثانیه را مجاز می‌داند)، و در غیر این صورت 20 است (۲۰ فعال‌سازی در هر ۲ ثانیه)\&. هر کدام را روی 0 قرار دهید تا هرگونه محدودیت نرخ راه‌اندازی غیرفعال شود\&.
.sp
اگر این محدودیت پر شود، واحد سوکت در حالت شکست قرار می‌گیرد و تا زمانی که مجدداً راه‌اندازی نشود دیگر قابل اتصال نخواهد بود\&. توجه داشته باشید که این محدودیت قبل از اینکه فعال‌سازی سرویس در صف قرار گیرد اعمال می‌شود\&.
.sp
این را با
\fIPollLimitIntervalSec=\fR/\fIPollLimitBurst=\fR
که در زیر توضیح داده شده مقایسه کنید، که در صورتی که یک واحد سوکت با ترافیک ورودی سرریز شود، یک کندسازی موقت را پیاده‌سازی می‌کند، بر خلاف وضعیت خرابی دائمی که
\fITriggerLimitIntervalSec=\fR/\fITriggerLimitBurst=\fR
به بار می‌آورد\&.
.sp
در نسخه ۲۳۰ اضافه شد\&.
.RE
.PP
\fIPollLimitIntervalSec=\fR, \fIPollLimitBurst=\fR
.RS 4
محدودیتی را برای اینکه رویدادهای نظرسنجی روی توصیف‌کننده‌های فایل پشتیبان این واحد سوکت با چه تناوبی مورد بررسی قرار گیرند پیکربندی می‌کند\&. این جفت تنظیمات شبیه به
\fITriggerLimitIntervalSec=\fR/\fITriggerLimitBurst=\fR
هستند، اما به جای اعمال یک محدودیت (مهلک) بر بسامد فعال‌سازی، یک محدودیت (گذرا) بر بسامد نظرسنجی اعمال می‌کنند\&. نحو و دامنه پارامترهای مورد انتظار با گزینه‌های پیش‌گفته یکسان است و می‌توان آن را به همان شیوه غیرفعال کرد\&.
.sp
اگر محدودیت نظرسنجی پر شود، نظرسنجی روی آن تا زمانی که بازه زمانی مشخص‌شده سپری شود به‌طور موقت غیرفعال می‌گردد\&. بنابراین محدودیت نظرسنجی در صورت پر شدن تلاش‌های اتصال را کند می‌کند، اما بر خلاف محدودیت راه‌اندازی باعث شکست دائمی نخواهد شد\&. این سازوکار توصیه‌شده برای مقابله با تلاش‌های انکار خدمت از طریق طغیان بسته‌ها است\&.
.sp
محدودیت نظرسنجی به ازای هر توصیف‌کننده فایل برای گوش دادن اعمال می‌شود، بر خلاف محدودیت راه‌اندازی که برای کل واحد سوکت اعمال می‌گردد\&. این تمایز برای واحدهای سوکتی اهمیت دارد که روی چندین توصیف‌کننده فایل گوش می‌دهند (یعنی دارای چندین بند
\fIListenXYZ=\fR
هستند)\&.
.sp
این تنظیمات به‌طور پیش‌فرض برابر با 150 رویداد نظرسنجی در هر ۲ ثانیه (در حالت
\fIAccept=yes\fR)
و 15 رویداد (در غیر این صورت) است\&. این مقدار به‌طور قابل توجهی پایین‌تر از مقادیر پیش‌فرض برای محدودیت راه‌اندازی است (به بالا مراجعه کنید) و بدان معناست که محدودیت نظرسنجی معمولاً باید اطمینان حاصل کند که محدودیت راه‌اندازی هرگز پر نمی‌شود، مگر اینکه یکی از آن‌ها بازپیکربندی یا غیرفعال شود\&.
.sp
در نسخه ۲۵۵ اضافه شد\&.
.RE
.PP
\fIDeferTrigger=\fR
.RS 4
یک آرگومان بولی، یا
"patient"
را می‌پذیرد\&. فقط زمانی می‌تواند استفاده شود که
\fIAccept=no\fR
باشد\&. در صورت فعال بودن، حالت کار
"lenient"
به جای
"replace"
هنگام راه‌اندازی سرویس استفاده می‌شود، که بدان معناست واحدهای در حال فعال‌سازی/در حال اجرای فعلی که با این سرویس در تضاد هستند دچار اختلال/توقف نخواهند شد\&. علاوه بر این، اگر تضادی وجود داشته باشد، واحد سوکت منتظر می‌ماند تا صف کارهای فعلی کامل شود و احتمالاً فعال‌سازی را تا آن زمان به تعویق می‌اندازد\&. حد بالای کل زمان انتظار می‌تواند از طریق
\fIDeferTriggerMaxSec=\fR
پیکربندی شود\&. اگر روی
\fByes\fR
تنظیم شود، در صورتی که تمام کارها به پایان رسیده باشند یا مهلت زمانی به سر رسیده باشد اما تضاد همچنان باقی مانده باشد، واحد سوکت شکست خواهد خورد\&. اگر
\fBpatient\fR
باشد، همیشه تا سپری شدن
\fIDeferTriggerMaxSec=\fR
منتظر می‌ماند\&. مقدار پیش‌فرض no است\&.
.sp
این تنظیم به‌ویژه در صورتی مفید است که واحد سوکت باید در طول عملیات switch\-root/soft\-reboot در حالی که سرویس راه‌اندازی‌شده متوقف است فعال بماند\&.
.sp
در نسخه ۲۵۸ اضافه شد\&.
.RE
.PP
\fIDeferTriggerMaxSec=\fR
.RS 4
حداکثر زمان برای به تعویق انداختن راه‌اندازی را در هنگام فعال بودن
\fIDeferTrigger=\fR
پیکربندی می‌کند\&. اگر سرویس نتواند در مدت زمان مشخص‌شده فعال شود، سوکت ناموفق در نظر گرفته شده و خاتمه می‌یابد\&. مقداری بدون واحد به ثانیه، یا مقداری با بازه زمانی مانند "5min 20s" می‌پذیرد\&. برای غیرفعال کردن منطق مهلت زمانی (پیش‌فرض)،
"0"
یا
"infinity"
را بدهید\&.
.sp
در نسخه ۲۵۸ اضافه شد\&.
.RE
.PP
\fIPassFileDescriptorsToExec=\fR
.RS 4
یک آرگومان بولی می‌پذیرد\&. مقدار پیش‌فرض off است\&. در صورت فعال بودن، توصیف‌کننده‌های فایل ایجادشده توسط واحد سوکت به دستورات
\fIExecStartPost=\fR،
\fIExecStopPre=\fR
و
\fIExecStopPost=\fR
از واحد سوکت منتقل می‌شوند\&. توصیف‌کننده‌های فایل منتقل‌شده می‌توانند با
\fBsd_listen_fds\fR(3)
به گونه‌ای مورد دسترسی قرار گیرند که گویی دستورات از واحدهای سرویس مرتبط فراخوانی شده‌اند\&. توجه داشته باشید که دستور
\fIExecStartPre=\fR
نمی‌تواند به توصیف‌کننده‌های فایل سوکت دسترسی پیدا کند\&.
.sp
در نسخه ۲۵۶ اضافه شد\&.
.RE
.PP
برای تنظیمات بیشتر،
\fBsystemd.unit\fR(5)،
\fBsystemd.exec\fR(5)
و
\fBsystemd.kill\fR(5)
را بررسی کنید\&.
.SH "همچنین ببینید (SEE ALSO)"
.PP
\fBsystemd\fR(1), \fBsystemctl\fR(1), \fBsystemd-system.conf\fR(5), \fBsystemd.unit\fR(5), \fBsystemd.exec\fR(5), \fBsystemd.kill\fR(5), \fBsystemd.resource-control\fR(5), \fBsystemd.service\fR(5), \fBsystemd.directives\fR(7), \fBsd_listen_fds\fR(3), \fBsd_listen_fds_with_names\fR(3)
.PP
برای توضیحات جامع‌تر، مجموعه مقالات «systemd برای توسعه‌دهندگان» را ببینید:
\m[blue]\fBSocket Activation\fR\m[]\&\s-2\u[5]\d\s+2, \m[blue]\fBSocket Activation, part II\fR\m[]\&\s-2\u[6]\d\s+2, \m[blue]\fBConverting inetd Services\fR\m[]\&\s-2\u[7]\d\s+2, \m[blue]\fBSocket Activated Internet Services and OS Containers\fR\m[]\&\s-2\u[8]\d\s+2\&.
.SH "یادداشت‌ها (NOTES)"
.IP " 1." 4
USB FunctionFS
.RS 4
\%https://docs.kernel.org/usb/functionfs.html
.RE
.IP " 2." 4
RFC 3875
.RS 4
\%https://datatracker.ietf.org/doc/html/rfc3875
.RE
.IP " 3." 4
TCP Keepalive HOWTO
.RS 4
\%http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO
.RE
.IP " 4." 4
Smack
.RS 4
\%https://docs.kernel.org/admin-guide/LSM/Smack.html
.RE
.IP " 5." 4
Socket Activation
.RS 4
\%https://0pointer.de/blog/projects/socket-activation.html
.RE
.IP " 6." 4
Socket Activation, part II
.RS 4
\%https://0pointer.de/blog/projects/socket-activation2.html
.RE
.IP " 7." 4
Converting inetd Services
.RS 4
\%https://0pointer.de/blog/projects/inetd.html
.RE
.IP " 8." 4
Socket Activated Internet Services and OS Containers
.RS 4
\%https://0pointer.de/blog/projects/socket-activated-containers.html
.RE