نام (NAME)

systemd.unit - پیکربندی عمومی و تنظیمات مشترک واحدهای systemd

خلاصه دستور (SYNOPSIS)

service.service, socket.socket, device.device, mount.mount, automount.automount, swap.swap, target.target, path.path, timer.timer, slice.slice, scope.scope

توضیحات (DESCRIPTION)

یک فایل واحد، یک فایل متنی ساده به سبک ini است که اطلاعات مربوط به یک سرویس، سوکت، دستگاه، نقطه اتصال (mount point)، نقطه اتصال خودکار (automount point)، فایل یا پارتیشن swap، هدف راه‌اندازی (target)، مسیر فایل‌سیستم تحت نظارت، تایمر کنترل و نظارت‌شده توسط systemd(1)، یک برش مدیریت منابع (slice) یا گروهی از فرآیندهای ایجادشده به صورت خارجی را کدگذاری می‌کند. برای توضیحات کلی درباره نحو، systemd.syntax(7) را ببینید.

این صفحه راهنما، گزینه‌های پیکربندی مشترک تمام انواع واحد را فهرست می‌کند. این گزینه‌ها باید در بخش‌های [Unit] یا [Install] فایل‌های واحد پیکربندی شوند.

علاوه بر بخش‌های عمومی [Unit] و [Install] که در اینجا توضیح داده شده‌اند، هر واحد ممکن است دارای یک بخش ویژه نوع خود باشد، مانند [Service] برای یک واحد سرویس. برای اطلاعات بیشتر صفحات راهنمای مربوطه را ببینید: systemd.service(5)، systemd.socket(5)، systemd.device(5)، systemd.mount(5)، systemd.automount(5)، systemd.swap(5)، systemd.target(5)، systemd.path(5)، systemd.timer(5)، systemd.slice(5)، systemd.scope(5).

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

نام‌های معتبر واحد از یک «پیشوند نام واحد» و یک پسوند که نوع واحد را مشخص می‌کند و با یک نقطه شروع می‌شود، تشکیل شده‌اند. «پیشوند نام واحد» باید از یک یا چند نویسه معتبر (حروف اسکی، ارقام، ":"، "-"، "_"، "." و "\") تشکیل شود. طول کل نام واحد شامل پسوند نباید از ۲۵۵ نویسه تجاوز کند. پسوند نوع واحد باید یکی از موارد زیر باشد: ".service"، ".socket"، ".device"، ".mount"، ".automount"، ".swap"، ".target"، ".path"، ".timer"، ".slice" یا ".scope".

نام‌های واحد را می‌توان با یک آرگومان واحد به نام «نام نمونه» (instance name) پارامتری کرد. سپس واحد بر اساس یک «فایل الگو» (template file) ساخته می‌شود که به عنوان تعریف چندین سرویس یا واحدهای دیگر عمل می‌کند. یک واحد الگو باید یک علامت "@" منفرد در انتهای پیشوند نام واحد (دقیقاً قبل از پسوند نوع) داشته باشد. نام واحد کامل با درج نام نمونه بین "@" و پسوند نوع واحد تشکیل می‌شود. در خود فایل واحد، می‌توان با استفاده از "%i" و سایر مشخص‌کننده‌ها به پارامتر نمونه ارجاع داد، به زیر مراجعه کنید.

فایل‌های واحد ممکن است شامل گزینه‌های اضافی علاوه بر مواردی که در اینجا فهرست شده‌اند باشند. اگر systemd با یک گزینه ناشناخته مواجه شود، یک پیام هشدار در گزارش ثبت می‌کند اما به بارگذاری واحد ادامه می‌دهد. اگر نام یک گزینه یا بخش با پیشوند X- آغاز شود، توسط systemd کاملاً نادیده گرفته می‌شود. گزینه‌های درون یک بخش نادیده‌گرفته‌شده نیازی به پیشوند ندارند. برنامه‌ها ممکن است از این قابلیت برای گنجاندن اطلاعات اضافی در فایل‌های واحد استفاده کنند. برای دسترسی به این گزینه‌ها، برنامه‌ها باید فایل‌های واحد را خودشان تجزیه کنند.

واحدها را می‌توان با ایجاد یک پیوند نمادین (symlink) از نام جدید به نام موجود در یکی از مسیرهای جستجوی واحد، نام مستعار داد (یک نام جایگزین برای آن‌ها تعیین کرد). به عنوان مثال، systemd-networkd.service نام مستعار dbus-org.freedesktop.network1.service را دارد که در طول نصب به عنوان یک پیوند نمادین ایجاد شده است، بنابراین هنگامی که از systemd از طریق D-Bus خواسته می‌شود که dbus-org.freedesktop.network1.service را بارگذاری کند، systemd-networkd.service را بارگذاری خواهد کرد. به عنوان مثالی دیگر، default.target — هدف پیش‌فرض سیستم که هنگام راه‌اندازی اجرا می‌شود — معمولاً به multi-user.target یا graphical.target پیوند نمادین داده می‌شود تا مشخص کند چه چیزی به طور پیش‌فرض راه‌اندازی شود. نام‌های مستعار را می‌توان در دستوراتی مانند disable، start، stop، status و موارد مشابه، و در تمام دستورالعمل‌های وابستگی واحد، از جمله Wants=، Requires=، Before=، After= استفاده کرد. نام‌های مستعار را نمی‌توان با دستور preset استفاده کرد.

نام‌های مستعار از محدودیت‌های زیر پیروی می‌کنند: یک واحد از نوع خاص (".service"، ".socket"، ...) فقط می‌تواند با نامی دارای همان پسوند نوع نام مستعار داده شود. یک واحد ساده (غیر الگو یا نمونه)، فقط با یک نام ساده می‌تواند نام مستعار بگیرد. یک نمونه الگو فقط می‌تواند با یک نمونه الگوی دیگر نام مستعار داده شود و بخش نمونه باید یکسان باشد. یک الگو ممکن است توسط یک الگوی دیگر نام مستعار بگیرد (در این حالت نام مستعار برای همه نمونه‌های الگو اعمال می‌شود). به عنوان یک حالت خاص، یک نمونه الگو (مانند "alias@inst.service") ممکن است یک پیوند نمادین به الگوی متفاوتی (مانند "template@inst.service") باشد. در این حالت، فقط همین نمونه خاص دارای نام مستعار می‌شود، در حالی که سایر نمونه‌های الگو (مانند "alias@foo.service"، "alias@bar.service") نام مستعار نخواهند داشت. این قوانین این الزام را حفظ می‌کنند که نمونه (در صورت وجود) همیشه برای یک واحد معین و تمام نام‌های مستعار آن به طور منحصر به فرد تعریف شده باشد. مقصد پیوند نمادین نام مستعار باید به یک مکان معتبر فایل واحد اشاره کند، یعنی نام مقصد پیوند نمادین باید همان‌طور که توضیح داده شد با نام منبع پیوند نمادین مطابقت داشته باشد، و مسیر مقصد باید در یکی از مسیرهای جستجوی واحد باشد، برای جزئیات بیشتر به بخش مسیر بارگذاری فایل واحد در زیر مراجعه کنید. توجه داشته باشید که فایل مقصد ممکن است وجود نداشته باشد، یعنی پیوند نمادین ممکن است معلق (dangling) باشد.

فایل‌های واحد ممکن است نام‌های مستعار را از طریق دستورالعمل Alias= در بخش [Install] مشخص کنند. هنگامی که واحد فعال (enable) می‌شود، پیوندهای نمادین برای آن نام‌ها ایجاد می‌شوند و هنگام غیرفعال (disable) شدن واحد حذف می‌گردند. به عنوان مثال، reboot.target دستورالعمل Alias=ctrl-alt-del.target را مشخص می‌کند، بنابراین در صورت فعال بودن، پیوند نمادین /etc/systemd/system/ctrl-alt-del.target که به فایل reboot.target اشاره می‌کند ایجاد خواهد شد، و هنگامی که Ctrl+Alt+Del فشرده شود، systemd به دنبال ctrl-alt-del.target می‌گردد، پیوند نمادین را تا reboot.target دنبال می‌کند و reboot.service را به عنوان بخشی از آن هدف اجرا می‌نماید. systemd در طول عملکرد عادی اصلاً به بخش [Install] نگاه نمی‌کند، بنابراین هر دستورالعملی در آن بخش فقط از طریق پیوندهای نمادین ایجادشده در زمان فعال‌سازی تأثیر می‌گذارد.

در کنار یک فایل واحد foo.service، دایرکتوری foo.service.wants/ ممکن است وجود داشته باشد. تمام فایل‌های واحدی که از چنین دایرکتوری پیوند نمادین شده‌اند، به طور ضمنی به عنوان وابستگی‌هایی از نوع Wants= به واحد اضافه می‌شوند. قابلیت مشابهی برای وابستگی‌های نوع Requires= نیز وجود دارد که در این حالت پسوند دایرکتوری .requires/ است. این قابلیت برای قلاب کردن واحدها به فرآیند راه‌اندازی سایر واحدها بدون نیاز به تغییر فایل‌های واحد آن‌ها مفید است. برای جزئیات بیشتر درباره معنای Wants= و Requires=، به زیر مراجعه کنید. روش ترجیحی برای ایجاد پیوندهای نمادین در دایرکتوری‌های .wants/ یا .requires/ مشخص کردن وابستگی در بخش [Install] واحد مقصد و ایجاد پیوند نمادین در سیستم فایل با دستورات enable یا preset از systemctl(1) است. مقصد می‌تواند یک واحد معمولی باشد (چه ساده یا یک نمونه خاص از یک واحد الگو). در حالتی که واحد مبدأ یک الگو باشد، مقصد نیز می‌تواند یک الگو باشد که در این حالت نمونه به واحد مقصد «منتشر» می‌شود تا یک نمونه واحد معتبر تشکیل دهد. مقصد پیوندهای نمادین در .wants/ یا .requires/ باید به یک مکان معتبر فایل واحد اشاره کند، یعنی نام مقصد پیوند نمادین باید شرایط توصیف‌شده را برآورده سازد و مسیر مقصد باید در یکی از مسیرهای جستجوی واحد باشد، برای جزئیات بیشتر به بخش مسیر بارگذاری فایل واحد در زیر مراجعه کنید. توجه داشته باشید که فایل مقصد ممکن است وجود نداشته باشد، یعنی پیوند نمادین ممکن است معلق باشد.

در کنار یک فایل واحد foo.service، یک دایرکتوری بازنویسی قطعه‌ای (drop-in) به نام foo.service.d/ ممکن است وجود داشته باشد. تمام فایل‌های دارای پسوند ".conf" از این دایرکتوری به ترتیب الفبایی-عددی ادغام شده و پس از تجزیه خود فایل اصلی واحد، تجزیه و اعمال می‌شوند. این قابلیت برای تغییر یا افزودن تنظیمات پیکربندی برای یک واحد، بدون نیاز به ویرایش فایل اصلی واحد مفید است. هر فایل drop-in باید سرآیندهای بخش مناسب را داشته باشد. برای واحدهای نمونه‌سازی‌شده، این منطق ابتدا به دنبال زیردایرکتوری ".d/" نمونه (مانند "foo@bar.service.d/") می‌گردد و فایل‌های ".conf" آن را می‌خواند، و سپس زیردایرکتوری ".d/" الگو (مانند "foo@.service.d/") و فایل‌های ".conf" موجود در آن را بررسی می‌کند. علاوه بر این، برای نام‌های واحد حاوی خط تیره ("-")، مجموعه دایرکتوری‌های تولیدشده از کوتاه‌سازی مکرر نام واحد پس از خط تیره‌ها نیز جستجو می‌شود. به طور خاص، برای نام واحد foo-bar-baz.service نه تنها دایرکتوری drop-in معمولی foo-bar-baz.service.d/ جستجو می‌شود، بلکه هر دو دایرکتوری foo-bar-.service.d/ و foo-.service.d/ نیز جستجو می‌شوند. این برای تعریف فایل‌های قطعه‌ای مشترک برای مجموعه‌ای از واحدهای مرتبط که نام آن‌ها با یک پیشوند مشترک آغاز می‌شود مفید است. این طرح به ویژه برای واحدهای mount، automount و slice که ساختار نام‌گذاری سیستماتیک آن‌ها بر اساس خط تیره به عنوان جداکننده اجزا ساخته شده، بسیار کارآمد است. توجه داشته باشید که فایل‌های drop-in با نام‌های یکسان در رده‌های پایین‌تر سلسله‌مراتب پیشوند، مواردی را که بالاتر قرار دارند لغو و بازنویسی می‌کنند؛ یعنی foo-bar-.service.d/10-override.conf بر فایل foo-.service.d/10-override.conf اولویت دارد و آن را بازنویسی می‌کند.

در موارد نام‌های مستعار واحد (توضیح داده شده در بالا)، قطعه‌های drop-in برای نام مستعار و تمام نام‌های مستعار دیگر بارگذاری می‌شوند. در مثال default.target که نام مستعار graphical.target است، دایرکتوری‌های default.target.d/، default.target.wants/، default.target.requires/، graphical.target.d/، graphical.target.wants/، graphical.target.requires/ همگی خوانده می‌شوند. برای الگوها، فایل‌های drop-in برای الگو، هرگونه نام مستعار الگو، نمونه الگو و تمام نمونه‌های نام مستعار خوانده می‌شوند. هنگامی که فقط یک نمونه الگوی خاص نام مستعار دارد، فایل‌های drop-in برای الگوی مقصد، نمونه الگوی مقصد و نمونه الگوی نام مستعار خوانده می‌شوند.

علاوه بر /etc/systemd/system، دایرکتوری‌های قطعه‌ای ".d/" برای سرویس‌های سیستمی را می‌توان در دایرکتوری‌های /usr/lib/systemd/system یا /run/systemd/system نیز قرار داد. فایل‌های drop-in در /etc/ بر فایل‌های موجود در /run/ اولویت دارند که آن‌ها نیز به نوبه خود بر فایل‌های موجود در /usr/lib/ اولویت دارند. فایل‌های drop-in در هر یک از این دایرکتوری‌ها بر فایل‌های واحد در هر کجا که قرار داشته باشند اولویت دارند. چندین فایل drop-in با نام‌های مختلف بدون توجه به اینکه در کدام دایرکتوری قرار دارند، به ترتیب لغت‌نگاری اعمال می‌شوند.

واحدها همچنین از یک دایرکتوری قطعه‌ای سطح بالا با عنوان type.d/ پشتیبانی می‌کنند، که در آن type می‌تواند مثلاً "service" یا "socket" باشد، که امکان تغییر یا افزودن به تنظیمات تمام فایل‌های واحد متناظر در سیستم را فراهم می‌سازد. قالب‌بندی و اولویت اعمال پیکربندی‌های drop-in از آنچه در بالا تعریف شد پیروی می‌کند. فایل‌های موجود در type.d/ نسبت به فایل‌های موجود در دایرکتوری‌های بازنویسی اختصاصی نام، اولویت کمتری دارند. قوانین معمول اعمال می‌شوند: چندین فایل drop-in با نام‌های مختلف بدون توجه به اینکه در کدام دایرکتوری قرار دارند، به ترتیب لغت‌نگاری اعمال می‌شوند، بنابراین یک فایل در type.d/ تنها در صورتی برای یک واحد اعمال می‌شود که هیچ drop-in یا پوششی (mask) با آن نام در دایرکتوری‌های دارای اولویت بالاتر وجود نداشته باشد. بخش مثال‌ها را ببینید.

توجه داشته باشید که اگرچه systemd یک سیستم وابستگی انعطاف‌پذیر بین واحدها ارائه می‌دهد، توصیه می‌شود از این قابلیت صرفاً به صورت محدود استفاده کنید و در عوض به تکنیک‌هایی مانند فعال‌سازی مبتنی بر گذرگاه (bus) یا سوکت تکیه نمایید که وابستگی‌ها را ضمنی کرده و منجر به سیستمی ساده‌تر و انعطاف‌پذیرتر می‌شوند.

همان‌طور که در بالا ذکر شد، یک واحد ممکن است از یک فایل الگو نمونه‌سازی شود. این امر امکان ایجاد چندین واحد از یک فایل پیکربندی واحد را فراهم می‌آورد. اگر systemd به دنبال یک فایل پیکربندی واحد بگردد، ابتدا نام دقیق واحد را در سیستم فایل جستجو می‌کند. اگر موفقیتی حاصل نشد و نام واحد حاوی نویسه "@" باشد، systemd به دنبال یک الگوی واحد خواهد گشت که نام مشابهی دارد اما رشته نمونه (یعنی بخش بین نویسه "@" و پسوند) از آن حذف شده است. مثال: اگر سرویس getty@tty3.service درخواست شود و فایلی با آن نام یافت نشود، systemd به دنبال getty@.service می‌گردد و در صورت یافت شدن، یک سرویس را از آن فایل پیکربندی نمونه‌سازی می‌کند.

برای ارجاع به رشته نمونه از درون فایل پیکربندی می‌توانید از مشخص‌کننده ویژه "%i" در بسیاری از گزینه‌های پیکربندی استفاده کنید. برای جزئیات به زیر مراجعه نمایید.

اگر یک فایل واحد خالی باشد (یعنی اندازه فایل ۰ باشد) یا به /dev/null پیوند نمادین شده باشد، پیکربندی آن بارگذاری نخواهد شد و با وضعیت بارگذاری "masked" (ماسک‌شده) ظاهر می‌شود و نمی‌توان آن را فعال کرد. از این ویژگی به عنوان روشی مؤثر برای غیرفعال‌سازی کامل یک واحد استفاده کنید که شروع آن را حتی به صورت دستی غیرممکن می‌سازد.

قالب فایل واحد تحت پوشش تعهد پایداری و قابلیت حمل رابط (Interface Portability and Stability Promise)[1] قرار دارد.

گریز رشته برای گنجاندن در نام واحدها (STRING ESCAPING FOR INCLUSION IN UNIT NAMES)

گاهی اوقات تبدیل رشته‌های دلخواه به نام‌های واحد مفید است. برای تسهیل این امر، روشی برای گریز رشته‌ها (string escaping) استفاده می‌شود تا رشته‌های حاوی مقادیر بایتی دلخواه (به جز NUL) به نام‌های واحد معتبر با مجموعه نویسه‌های محدود آن‌ها نگاشت شوند. یک حالت خاص رایج، نام‌های واحدی هستند که مسیرهای اشیاء در سلسله‌مراتب سیستم فایل را بازتاب می‌دهند. مثال: یک واحد دستگاه dev-sda.device به دستگاهی با گره دستگاه /dev/sda در سیستم فایل اشاره دارد.

الگوریتم گریز به صورت زیر عمل می‌کند: با داشتن یک رشته، هر نویسه "/" با "-" جایگزین می‌شود، و سایر نویسه‌هایی که الفبایی-عددی اسکی، ":"، "_" یا "." نیستند با کدهای گریز به سبک C مانند "\x2d" جایگزین می‌شوند. علاوه بر این، "." زمانی که به عنوان اولین نویسه در رشته فراریافته ظاهر شود، با چنین کد گریز به سبک C جایگزین می‌گردد.

هنگامی که ورودی به عنوان یک مسیر مطلق سیستم فایل واجد شرایط باشد، این الگوریتم کمی گسترش می‌یابد: مسیر دایرکتوری ریشه "/" به صورت یک خط تیره منفرد "-" کدگذاری می‌شود. علاوه بر این، هرگونه نویسه "/" ابتدایی، انتهایی یا تکراری قبل از تبدیل از رشته حذف می‌شود. مثال: /foo//bar/baz/ تبدیل می‌شود به "foo-bar-baz".

این فرآیند گریز کاملاً برگشت‌پذیر است، به شرطی که مشخص باشد آیا رشته فراریافته یک مسیر بوده است یا خیر (نتایج بازگردانی گریز برای مسیرها و رشته‌های غیرمسیر متفاوت است). از دستور systemd-escape(1) می‌توان برای اعمال و بازگردانی گریز روی رشته‌های دلخواه استفاده کرد. از systemd-escape --path برای گریز دادن رشته‌های مسیر، و از systemd-escape بدون --path در سایر موارد استفاده کنید.

وابستگی‌های خودکار (AUTOMATIC DEPENDENCIES)

مسیر بارگذاری فایل واحد (UNIT FILE LOAD PATH)

فایل‌های واحد از مجموعه‌ای از مسیرها که در زمان کامپایل تعیین شده‌اند بارگذاری می‌شوند که در دو جدول زیر توضیح داده شده است. فایل‌های واحدی که در دایرکتوری‌های ابتدای فهرست یافت می‌شوند، فایل‌های هم‌نام در دایرکتوری‌های پایین‌تر فهرست را لغو و بازنویسی می‌کنند [2].

هنگامی که متغیر محیطی $SYSTEMD_UNIT_PATH تنظیم شده باشد، محتوای این متغیر مسیر بارگذاری واحد را بازنویسی می‌کند. اگر $SYSTEMD_UNIT_PATH با یک مؤلفه خالی (":") پایان یابد، مسیر معمول بارگذاری واحد به انتهای محتوای این متغیر افزوده خواهد شد.

جدول ۱.  مسیر بارگذاری هنگام اجرا در حالت سیستمی (--system).

جدول ۲.  مسیر بارگذاری هنگام اجرا در حالت کاربری (--user).

مجموعه مسیرهای بارگذاری برای نمونه مدیر کاربری را می‌توان با استفاده از متغیرهای محیطی مختلف گسترش داد یا تغییر داد. و متغیرهای محیطی نیز به نوبه خود می‌توانند با استفاده از مولدهای محیط (environment generators) تنظیم شوند،
systemd.environment-generator(7) را ببینید. به ویژه، $XDG_DATA_HOME و $XDG_DATA_DIRS را می‌توان به راحتی با استفاده از systemd-environment-d-generator(8) تنظیم کرد. بنابراین، دایرکتوری‌های فهرست‌شده در اینجا صرفاً مقادیر پیش‌فرض هستند. برای مشاهده فهرست واقعی که بر اساس گزینه‌های کامپایل و محیط فعلی استفاده می‌شود، از دستور زیر استفاده کنید:

systemd-analyze --user unit-paths

علاوه بر این، واحدهای اضافی ممکن است با ایجاد یک پیوند نمادین اشاره‌کننده به یک فایل واحد در دایرکتوری‌ها، از دایرکتوری‌هایی خارج از مسیر بارگذاری واحد به systemd بارگذاری شوند. برای این منظور می‌توانید از systemctl link استفاده کنید؛ systemctl(1) را ببینید. سیستم فایلی که فایل‌های واحد پیوندشده در آن قرار دارند باید هنگام شروع systemd قابل دسترسی باشد (به عنوان مثال هر چیزی در زیر /home/ یا /var/ مجاز نیست، مگر اینکه آن دایرکتوری‌ها در سیستم فایل ریشه قرار داشته باشند).

بسیار مهم است که بین «فایل‌های واحد پیوندشده» (linked unit files) و «نام‌های مستعار فایل واحد» (unit file aliases) تمایز قائل شویم: هر پیوند نمادینی که در آن مقصد (target) پیوند نمادین درون مسیر بارگذاری واحد باشد به یک نام مستعار تبدیل می‌شود: نام منبع و نام فایل مقصد باید محدودیت‌های خاص فهرست‌شده در بحث نام‌های مستعار در بالا را برآورده سازند، اما فایل مقصد پیوند نمادین لزوماً نباید وجود داشته باشد و در واقع مسیر مقصد پیوند نمادین استفاده نمی‌شود، مگر برای بررسی اینکه آیا مقصد درون مسیر بارگذاری واحد است یا خیر. در مقابل، یک پیوند نمادین که به خارج از مسیر بارگذاری واحد می‌رود نشان‌دهنده یک فایل واحد پیوندشده است. هنگام بارگذاری فایل، پیوند نمادین دنبال می‌شود، اما نام مقصد در غیر این صورت استفاده نمی‌شود (و حتی ممکن است یک نام فایل واحد معتبر نباشد). به عنوان مثال، پیوندهای نمادین /etc/systemd/system/alias1.service → service1.service، /etc/systemd/system/alias2.service → /usr/lib/systemd/service1.service، /etc/systemd/system/alias3.service → /etc/systemd/system/service1.service همگی نام‌های مستعار معتبر هستند و service1.service دارای چهار نام خواهد بود، حتی اگر فایل واحد در /run/systemd/system/service1.service قرار داشته باشد. در مقابل، یک پیوند نمادین /etc/systemd/system/link1.service → ../link1_service_file بدین معناست که link1.service یک «واحد پیوندشده» است و محتوای /etc/systemd/link1_service_file پیکربندی آن را فراهم می‌کند.

جمع‌آوری زباله واحدها (UNIT GARBAGE COLLECTION)

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

منطق جمع‌آوری زباله را می‌توان با گزینه CollectMode= تغییر داد، که امکان پیکربندی مجاز بودن تخلیه خودکار واحدهایی را که در وضعیت failed هستند فراهم می‌کند، به زیر مراجعه کنید.

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

از systemctl daemon-reload یا یک دستور معادل برای بارگذاری مجدد پیکربندی واحد در حالی که واحد از قبل بارگذاری شده است استفاده کنید. در این حالت، تمام تنظیمات پیکربندی پاک شده و با پیکربندی جدید جایگزین می‌شوند (که البته ممکن است بلافاصله اعمال نشود)، اما تمام وضعیت‌های زمان اجرا ذخیره/بازیابی می‌شوند.

گزینه‌های بخش [UNIT] ([UNIT] SECTION OPTIONS)

فایل واحد ممکن است شامل یک بخش [Unit] باشد که اطلاعات عمومی در مورد واحد را حمل می‌کند که وابسته به نوع واحد نیست:

Description=

Documentation=

Wants=

Requires=

Requisite=

BindsTo=

PartOf=

Upholds=

Conflicts=

Before=, After=

OnFailure=

OnSuccess=

PropagatesReloadTo=, ReloadPropagatedFrom=

PropagatesStopTo=, StopPropagatedFrom=

JoinsNamespaceOf=

RequiresMountsFor=

WantsMountsFor=

OnSuccessJobMode=, OnFailureJobMode=

IgnoreOnIsolate=

StopWhenUnneeded=

RefuseManualStart=, RefuseManualStop=

AllowIsolate=

DefaultDependencies=

SurviveFinalKillSignal=

CollectMode=

FailureAction=, SuccessAction=

FailureActionExitStatus=, SuccessActionExitStatus=

JobTimeoutSec=, JobRunningTimeoutSec=

JobTimeoutAction=, JobTimeoutRebootArgument=

StartLimitIntervalSec=interval, StartLimitBurst=burst

StartLimitAction=

RebootArgument=

SourcePath=

نگاشت ویژگی‌های واحد به معکوس آن‌ها (MAPPING OF UNIT PROPERTIES TO THEIR INVERSES)

تنظیمات واحد که با یک واحد دوم رابطه ایجاد می‌کنند معمولاً در ویژگی‌های هر دو واحد نشان داده می‌شوند، به عنوان مثال در خروجی systemctl show. در برخی موارد نام ویژگی با نام تنظیمات پیکربندی یکسان است، اما نه همیشه. این جدول ویژگی‌هایی را که روی دو واحد متصل به یکدیگر از طریق نوعی وابستگی نشان داده می‌شوند فهرست می‌کند، و نشان می‌دهد که کدام ویژگی در واحد «مبدأ» با کدام ویژگی در واحد «مقصد» مطابقت دارد.

جدول ۴.  ویژگی‌های «مستقیم» و «معکوس» واحد

Note:
WantedBy=, RequiredBy=, and UpheldBy= are used in the بخش [Install] to create symlinks in .wants/, .requires/, and .upholds/ directories. They cannot be used directly as a unit configuration setting.

Note: ConsistsOf=, BoundBy=, RequisiteOf=, ConflictedBy= are created implicitly along with their reverses and cannot be specified directly.

Note: Triggers= is created implicitly between a socket, path unit, or an automount unit, and the unit they activate. By default, a unit with the same name is triggered, but this can be overridden using Sockets=, Service=, and Unit= settings. See systemd.service(5), systemd.socket(5), systemd.path(5), and systemd.automount(5) for details. TriggeredBy= is created implicitly on the triggered unit.

Note: Following= is used to group device aliases and points to the "primary" device unit that systemd is using to track device state, usually corresponding to a sysfs path. It does not show up in the "target" unit.

[INSTALL] SECTION OPTIONS

Unit files may include an بخش [Install], which carries installation information for the unit. This section is not interpreted by systemd(1) during runtime; it is used by the enable and disable commands of the systemctl(1) tool during installation of a unit.

Alias=

WantedBy=, RequiredBy=, UpheldBy=

Also=

DefaultInstance= allbox tab(:); lB lB lB s. T{ "Forward" property T}:T{ "Reverse" property T}:T{ Where used T} l l l s 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 s l l l s l l ^ ^ l l l s l l ^ ^ l l l l. T{ Before= T}:T{ After= T}:T{ [Unit] section T} T{ After= T}:T{ Before= T}:: T{ Requires= T}:T{ RequiredBy= T}:T{ [Unit] section T}:T{ [Install] section T} T{ Wants= T}:T{ WantedBy= T}:T{ [Unit] section T}:T{ [Install] section T} T{ Upholds= T}:T{ UpheldBy= T}:T{ [Unit] section T}:T{ [Install] section T} T{ PartOf= T}:T{ ConsistsOf= T}:T{ [Unit] section T}:T{ an automatic property T} T{ BindsTo= T}:T{ BoundBy= T}:T{ [Unit] section T}:T{ an automatic property T} T{ Requisite= T}:T{ RequisiteOf= T}:T{ [Unit] section T}:T{ an automatic property T} T{ Conflicts= T}:T{ ConflictedBy= T}:T{ [Unit] section T}:T{ an automatic property T} T{ Triggers= T}:T{ TriggeredBy= T}:T{ Automatic properties, see notes below T} T{ PropagatesReloadTo= T}:T{ ReloadPropagatedFrom= T}:T{ [Unit] section T} T{ ReloadPropagatedFrom= T}:T{ PropagatesReloadTo= T}:: T{ PropagatesStopTo= T}:T{ StopPropagatedFrom= T}:T{ [Unit] section T} T{ StopPropagatedFrom= T}:T{ PropagatesStopTo= T}:: T{ Following= T}:T{ n/a T}:T{ An automatic property T}:T{   T}

Note: WantedBy=, RequiredBy=, and UpheldBy= are used in the [Install] section to create symlinks in .wants/, .requires/, and .upholds/ directories. They cannot be used directly as a unit configuration setting.

Note: ConsistsOf=, BoundBy=, RequisiteOf=, ConflictedBy= are created implicitly along with their reverses and cannot be specified directly.

Note: Triggers= is created implicitly between a socket, path unit, or an automount unit, and the unit they activate. By default, a unit with the same name is triggered, but this can be overridden using Sockets=, Service=, and Unit= settings. See systemd.service(5), systemd.socket(5), systemd.path(5), and systemd.automount(5) for details. TriggeredBy= is created implicitly on the triggered unit.

Note: Following= is used to group device aliases and points to the "primary" device unit that systemd is using to track device state, usually corresponding to a sysfs path. It does not show up in the "target" unit.

[INSTALL] SECTION OPTIONS

Unit files may include an [Install] section, which carries installation information for the unit. This section is not interpreted by systemd(1) during runtime; it is used by the enable and disable commands of the systemctl(1) tool during installation of a unit.

Alias=

WantedBy=, RequiredBy=, UpheldBy=

Also=

DefaultInstance=

یادداشت: WantedBy=، RequiredBy=، و UpheldBy= در بخش [Install] برای ایجاد پیوندهای نمادین در دایرکتوری‌های .wants/، .requires/، و .upholds/ استفاده می‌شوند. آن‌ها را نمی‌توان مستقیماً به عنوان یک تنظیم پیکربندی واحد استفاده کرد.

یادداشت: ConsistsOf=، BoundBy=، RequisiteOf=، ConflictedBy= به طور ضمنی همراه با معکوس‌های خود ایجاد می‌شوند و نمی‌توان آن‌ها را مستقیماً مشخص کرد.

یادداشت: Triggers= به طور ضمنی بین یک سوکت، واحد path یا یک واحد automount و واحدی که فعال می‌کنند ایجاد می‌شود. به طور پیش‌فرض، واحدی با همان نام فعال می‌شود، اما این را می‌توان با استفاده از تنظیمات Sockets=، Service=، و Unit= بازنویسی کرد. برای جزئیات، systemd.service(5)، systemd.socket(5)، systemd.path(5)، و systemd.automount(5) را ببینید. TriggeredBy= به طور ضمنی روی واحد تحریک‌شده ایجاد می‌شود.

یادداشت: Following= برای گروه‌بندی نام‌های مستعار دستگاه استفاده می‌شود و به واحد دستگاه «اصلی» اشاره می‌کند که systemd برای ردیابی وضعیت دستگاه از آن استفاده می‌نماید، که معمولاً با یک مسیر sysfs مطابقت دارد. این ویژگی در واحد «مقصد» نشان داده نمی‌شود.

گزینه‌های بخش [INSTALL] ([INSTALL] SECTION OPTIONS)

فایل‌های واحد ممکن است شامل یک بخش [Install] باشند که اطلاعات نصب را برای واحد حمل می‌کند. این بخش توسط systemd(1) در زمان اجرا تفسیر نمی‌شود؛ بلکه توسط دستورات enable و disable از ابزار systemctl(1) در طول نصب یک واحد استفاده می‌شود.

Alias=

WantedBy=, RequiredBy=, UpheldBy=

Also=

DefaultInstance=

مشخص‌کننده‌های زیر در بخش Install تفسیر می‌شوند: %a, %b, %B, %g, %G, %H, %i, %j, %l, %m, %n, %N, %o, %p, %u, %U, %v, %w, %W, %%. برای معنای آن‌ها به بخش بعدی مراجعه کنید.

مشخص‌کننده‌ها (SPECIFIERS)

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

جدول ۵. مشخص‌کننده‌های موجود در فایل‌های واحد

مثال‌ها (EXAMPLES)

مثال ۱. مجاز کردن فعال‌سازی واحدها

قطعه کد زیر (برجسته‌شده) به یک واحد (مثلاً foo.service) اجازه می‌دهد تا از طریق systemctl enable فعال شود:

[Unit]
Description=Foo
[Service]
ExecStart=/usr/sbin/foo-daemon
[Install]
WantedBy=multi-user.target

پس از اجرای systemctl enable، یک پیوند نمادین /etc/systemd/system/multi-user.target.wants/foo.service که به واحد واقعی پیوند دارد ایجاد خواهد شد. این به systemd می‌گوید که هنگام راه‌اندازی multi-user.target واحد را فراخوانی کند. دستور معکوس systemctl disable آن پیوند نمادین را دوباره حذف خواهد کرد.

مثال ۲. بازنویسی تنظیمات ارائه‌دهنده

دو روش برای بازنویسی تنظیمات ارائه‌دهنده در فایل‌های واحد وجود دارد: کپی کردن فایل واحد از /usr/lib/systemd/system به /etc/systemd/system و تغییر تنظیمات انتخاب‌شده. روش جایگزین، ایجاد یک دایرکتوری به نام unit.d/ درون /etc/systemd/system و قرار دادن یک فایل قطعه‌ای name.conf در آنجا است که تنها تنظیمات خاصی را که کاربر به آن‌ها علاقه‌مند است تغییر می‌دهد. توجه داشته باشید که در صورت وجود چندین فایل قطعه‌ای از این دست، به ترتیب لغت‌نگاری نام فایل آن‌ها پردازش می‌شوند.

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

مزیت روش دوم این است که کاربر فقط تنظیماتی را که مشخصاً می‌خواهد بازنویسی می‌کند، در حالی که به‌روزرسانی‌های واحد توسط ارائه‌دهنده به طور خودکار اعمال می‌شوند. این روش این عیب را دارد که برخی از به‌روزرسانی‌های آینده توسط ارائه‌دهنده ممکن است با تغییرات محلی ناسازگار باشند.

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

فرض کنید یک واحد ارائه‌شده توسط توزیع به آدرس /usr/lib/systemd/system/httpd.service با محتویات زیر وجود دارد:

[Unit]
Description=Some HTTP server
After=remote-fs.target sqldb.service
Requires=sqldb.service
AssertPathExists=/srv/webserver
[Service]
Type=notify
ExecStart=/usr/sbin/some-fancy-httpd-server
Nice=5
[Install]
WantedBy=multi-user.target

اکنون مدیر سیستم می‌خواهد برخی از تنظیمات را تغییر دهد: اولاً، در راه‌اندازی محلی، /srv/webserver ممکن است وجود نداشته باشد، زیرا وب‌سرور HTTP طوری پیکربندی شده است که از /srv/www به جای آن استفاده کند. ثانیاً، پیکربندی محلی باعث می‌شود که وب‌سرور HTTP به یک سرویس حافظه موقت (cache)، یعنی memcached.service نیز وابسته باشد که باید فراخوانی شود (Requires=) و همچنین به درستی ترتیب‌بندی گردد (After=). ثالثاً، به منظور ایمن‌سازی بیشتر سرویس، مدیر سیستم مایل است تنظیم PrivateTmp= را فعال کند (برای جزئیات systemd.exec(5) را ببینید). و در نهایت، مدیر سیستم می‌خواهد میزان اولویت نایس (niceness) سرویس را به مقدار پیش‌فرض ۰ بازنشانی کند.

اولین امکان، کپی کردن فایل واحد در /etc/systemd/system/httpd.service و تغییر تنظیمات انتخاب‌شده است:

[Unit]
Description=Some HTTP server
After=remote-fs.target sqldb.service memcached.service
Requires=sqldb.service memcached.service
AssertPathExists=/srv/www
[Service]
Type=notify
ExecStart=/usr/sbin/some-fancy-httpd-server
Nice=0
PrivateTmp=yes
[Install]
WantedBy=multi-user.target

از طرف دیگر، مدیر سیستم می‌تواند یک فایل قطعه‌ای /etc/systemd/system/httpd.service.d/local.conf با محتویات زیر ایجاد کند:

[Unit]
After=memcached.service
Requires=memcached.service
# بازنشانی تمام ارزیابی‌ها و سپس افزودن مجدد شرط مورد نظر
AssertPathExists=
AssertPathExists=/srv/www
[Service]
Nice=0
PrivateTmp=yes

توجه داشته باشید که برای فایل‌های drop-in، اگر بخواهید ورودی‌ها را از تنظیمی که به عنوان فهرست تجزیه می‌شود (و وابستگی نیست) حذف کنید، مانند AssertPathExists= (یا مثلاً ExecStart= در واحدهای سرویس)، ابتدا باید فهرست را قبل از افزودن مجدد تمام ورودی‌ها به جز موردی که قرار است حذف شود، پاک کنید. وابستگی‌ها (After= و غیره) را نمی‌توان به یک فهرست خالی بازنشانی کرد، بنابراین وابستگی‌ها را فقط می‌توان در drop-inها اضافه کرد. اگر می‌خواهید وابستگی‌ها را حذف کنید، باید کل واحد را بازنویسی کنید.

مثال ۳. فایل‌های قطعه‌ای سطح بالا با واحدهای الگو

فایل‌های قطعه‌ای سطح بالا به ازای هر نوع را می‌توان برای تغییر جنبه‌ای از تمام واحدهای یک نوع خاص استفاده کرد. برای مثال، با ایجاد دایرکتوری /etc/systemd/system/service.d/ با یک فایل قطعه‌ای، محتویات فایل قطعه‌ای را می‌توان برای تمام واحدهای سرویس اعمال کرد. می‌توانیم با ایجاد نمونه‌ای از یک واحد کمکی ثانویه توسط قطعه سطح بالا، این کار را فراتر ببریم. برای مثال، مجموعه واحدها و فایل‌های قطعه‌ای زیر را در نظر بگیرید که در آن یک وابستگی OnFailure= برای تمام واحدهای سرویس نصب می‌کنیم.

/etc/systemd/system/failure-handler@.service:

[Unit]
Description=My failure handler for %i
[Service]
Type=oneshot
# انجام یک اقدام خاص برای زمانی که %i به طور غیرمنتظره خارج می‌شود.
ExecStart=/usr/sbin/myfailurehandler %i

سپس می‌توانیم یک نمونه از failure-handler@.service را به عنوان یک وابستگی OnFailure= برای تمام واحدهای سرویس اضافه کنیم.

/etc/systemd/system/service.d/10-all.conf:

[Unit]
OnFailure=failure-handler@%N.service

اکنون پس از اجرای systemctl daemon-reload تمام سرویس‌ها یک وابستگی OnFailure= به failure-handler@%N.service کسب خواهند کرد. واحدهای نمونه الگو نیز این وابستگی را به دست خواهند آورد که منجر به ایجاد یک زنجیره وابستگی بازگشتی می‌شود. systemd سعی خواهد کرد این زنجیره‌های وابستگی بازگشتی را که در آن یک واحد الگو مستقیماً و به طور بازگشتی به خودش وابسته است شناسایی کند و در صورت یافتن، چنین وابستگی‌هایی را به طور خودکار حذف خواهد کرد. اگر systemd زنجیره وابستگی بازگشتی را شناسایی نکند، ما می‌توانیم با غیرفعال کردن drop-in برای واحدهای نمونه الگو از طریق یک پیوند نمادین به /dev/null خودمان زنجیره را بشکنیم:

mkdir /etc/systemd/system/failure-handler@.service.d/
ln -s /dev/null /etc/systemd/system/failure-handler@.service.d/10-all.conf
systemctl daemon-reload

این تضمین می‌کند که اگر یک نمونه failure-handler@.service ناموفق شود، نمونه‌ای به نام failure-handler@failure-handler.service را فعال نخواهد کرد.

همچنین ببینید (SEE ALSO)

systemd(1), systemctl(1), systemd-system.conf(5), systemd.special(7), systemd.service(5), systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5), systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.scope(5), systemd.slice(5), systemd.time(7), systemd-analyze(1), capabilities(7), systemd.directives(7), uname(1)

نکات (NOTES)

1.

تعهد پایداری و قابلیت حمل رابط (Interface Portability and Stability Promise)

2.

💣💥🧨💥💥💣 لطفاً توجه داشته باشید که این فایل‌های پیکربندی باید همیشه در دسترس باشند. اگر /usr/local/ یک پارتیشن جداگانه باشد، ممکن است در طول راه‌اندازی اولیه در دسترس نباشد و نباید برای پیکربندی استفاده شود.

3.

systemd و دیمن‌های ذخیره‌سازی برای سیستم فایل ریشه

4.

اعتبارات سیستم و سرویس

5.

PSI (اطلاعات توقف تحت فشار)