systemd, init - مدیر
سیستم و
سرویسهای
لینوکس
/usr/lib/systemd/systemd [OPTIONS...]
init [OPTIONS...] {COMMAND}
systemd یک مدیر
سیستم و
سرویس برای
سیستمعاملهای
لینوکس است.
هنگامی که
به عنوان
اولین
فرآیند در
زمان
راهاندازی
سیستم (با
شناسه
فرآیند PID 1)
اجرا
میشود، به
عنوان
سیستم init عمل
میکند که
سرویسهای
فضای
کاربری (userspace)
را بالا
آورده و
نگهداری
مینماید.
نمونههای
جداگانهای
برای
کاربران
واردشده
اجرا
میشوند تا
سرویسهای
آنها را
آغاز کنند.
systemd
معمولاً
مستقیماً
توسط کاربر
فراخوانی
نمیشود،
بلکه به
عنوان
پیوند
نمادین /sbin/init
نصب شده و در
مراحل
اولیه
راهاندازی
سیستم آغاز
به کار
میکند.
نمونههای
مدیر کاربر
بهطور
خودکار از
طریق سرویس
user@.service(5)
راهاندازی
میشوند.
برای
سازگاری با
SysV، اگر این
فایل
اجرایی با
نام init
فراخوانی
شود و اولین
فرآیند روی
سیستم
نباشد (PID آن ۱
نباشد)، telinit
را اجرا
کرده و تمام
آرگومانهای
خط فرمان را
بدون تغییر
به آن ارسال
میکند. این
بدان
معناست که
init و telinit
هنگامی که
از
نشستهای
ورود
معمولی
فراخوانی
شوند
عمدتاً
معادل
هستند. برای
اطلاعات
بیشتر telinit(8) را
ببینید.
هنگامی که
به عنوان یک
نمونه
سیستمی
اجرا
میشود، systemd
فایل
پیکربندی system.conf
و فایلهای
موجود در
دایرکتوریهای
system.conf.d را تفسیر
میکند؛
هنگامی که
به عنوان
نمونه
کاربری
اجرا
میشود،
فایل
پیکربندی user.conf
و فایلهای
موجود در
دایرکتوریهای
user.conf.d را تفسیر
مینماید.
برای
اطلاعات
بیشتر systemd-system.conf(5)
را ببینید.
systemd شامل
پیادهسازیهای
بومی برای
وظایف
گوناگونی
است که باید
به عنوان
بخشی از
فرایند
راهاندازی
سیستم اجرا
شوند. به
عنوان
مثال، نام
میزبان (hostname) را
تنظیم
میکند یا
دستگاه
شبکه loopback را
پیکربندی
مینماید.
همچنین
فایلسیستمهای
API گوناگون
مانند /sys/، /proc/ و /dev/
را
راهاندازی
و سوار (mount)
میکند.
systemd همچنین
در صورتی که
به نظر برسد
ساعت سیستم
در اوایل
راهاندازی
نادرست
تنظیم شده
است، آن را
بازنشانی
میکند. بخش
«مبدأ ساعت
سیستم» در
زیر را
ببینید.
توجه
داشته
باشید که
برخی از
رابطهای
ارائهشده
توسط systemd (و نه
همه آنها)
تحت پوشش
تعهد
سازگاری و
پایداری
رابط[1] قرار
دارند.
واسط
برنامهنویسی
D-Bus مربوط به
systemd در org.freedesktop.systemd1(5) و
org.freedesktop.LogControl1(5) شرح
داده شده
است.
سیستمهایی
که systemd را در یک
محیط
کانتینر یا
initrd فراخوانی
میکنند
باید به
ترتیب
مشخصات
رابط
کانتینر[2]
یا رابط initrd[3]
را
پیادهسازی
نمایند.
systemd یک سیستم
وابستگی
بین
موجودیتهای
گوناگون به
نام
«واحدها» (units)
از ۱۱ نوع
مختلف
فراهم
میکند.
واحدها
اشیاء
گوناگونی
را که برای
راهاندازی
و نگهداری
سیستم
مرتبط
هستند
کپسولهسازی
مینمایند.
اکثریت
واحدها در
فایلهای
پیکربندی
واحد
پیکربندی
میشوند،
که نحو و
مجموعه
پایهای از
گزینههای
آنها در
systemd.unit(5) شرح
داده شده
است؛ با این
حال برخی
بهطور
خودکار از
سایر
فایلهای
پیکربندی،
بهصورت
پویا از
وضعیت
سیستم یا
بهطور
برنامهنویسیشده
در زمان
اجرا ایجاد
میشوند.
واحدها
ممکن است در
چندین
وضعیت
باشند که در
جدول زیر
شرح داده
شدهاند.
توجه داشته
باشید که
انواع
گوناگون
واحد ممکن
است چندین
زیروضعیت
اضافی
داشته
باشند که به
وضعیتهای
عمومی واحد
شرح داده
شده در
اینجا
نگاشت
میشوند.
جدول &1. &وضعیتهای
فعال (ACTIVE)
واحد
| وضعیت |
توضیحات |
| active |
شروعشده،
مقیدشده (bound)،
متصلشده (plugged
in)، ...، بسته به
نوع واحد. |
| inactive |
متوقفشده،
نامقید (unbound)،
جداشده (unplugged)،
...، بسته به
نوع واحد. |
| failed |
مشابه با
inactive، اما
واحد به
طریقی دچار
شکست شده
است (فرآیند
در زمان
خروج کد خطا
بازگردانده،
کرش کرده،
مهلت زمانی
یک عملیات
به پایان
رسیده، یا
پس از
راهاندازیهای
مجدد بیش از
حد). |
| activating |
در حال
تغییر از inactive
به active. |
| deactivating |
در حال
تغییر از active
به inactive. |
| maintenance |
واحد inactive
است و یک
عملیات
نگهداری در
حال انجام
میباشد. |
| reloading |
واحد active است
و در حال
بارگذاری
مجدد
پیکربندی
خود
میباشد. |
| refreshing |
واحد active است
و یک مانت
جدید در
فضای نام (namespace)
آن فعال
میشود. |
انواع
واحدهای
زیر در
دسترس
هستند:
1.واحدهای
سرویس (Service units)،
که دیمنها
و
فرآیندهایی
را که از
آنها
تشکیل
شدهاند
راهاندازی
و کنترل
میکنند.
برای
جزئیات،
ببینید
systemd.service(5).
2.واحدهای
سوکت (Socket units)، که
سوکتهای
شبکه یا IPC
محلی را در
سیستم
کپسولهسازی
میکنند و
برای
فعالسازی
مبتنی بر
سوکت مفید
هستند. برای
جزئیات
درباره
واحدهای
سوکت،
systemd.socket(5) و
برای
جزئیات در
مورد
فعالسازی
مبتنی بر
سوکت و سایر
اشکال
فعالسازی،
daemon(7) را
ببینید.
3.واحدهای
هدف (Target units)، که
برای
گروهبندی
واحدها یا
ارائه نقاط
همگامسازی
شناختهشده
در طول
راهاندازی
سیستم مفید
هستند؛
ببینید
systemd.target(5).
4.واحدهای
دستگاه (Device units)،
که
دستگاههای
هسته را در systemd
در معرض دید
قرار
میدهند و
ممکن است
برای
پیادهسازی
فعالسازی
مبتنی بر
دستگاه
استفاده
شوند. برای
جزئیات،
ببینید
systemd.device(5).
5.واحدهای
مانت (Mount units)، که
نقاط سوار
کردن را در
سیستم فایل
کنترل
میکنند؛
برای
جزئیات
ببینید
systemd.mount(5).
6.واحدهای
خودکار-مانت
(Automount units)، که
قابلیتهای
خودکار-سوارکردن
را برای
سوار کردن
برحسب
تقاضای
سیستمهای
فایل و
همچنین
راهاندازی
موازی
سیستم
فراهم
میکنند.
ببینید
systemd.automount(5).
7.واحدهای
زمانسنج (Timer
units)، که برای
راهاندازی
فعالسازی
سایر
واحدها بر
اساس
زمانسنجها
مفید هستند.
میتوانید
جزئیات را
در
systemd.timer(5)
بیابید.
8.واحدهای
سواپ (Swap units)، که
بسیار شبیه
به واحدهای
مانت هستند
و
پارتیشنها
یا
فایلهای
حافظه
مجازی (سواپ)
سیستمعامل
را
کپسولهسازی
میکنند.
آنها در
systemd.swap(5) شرح
داده
شدهاند.
9.واحدهای
مسیر (Path units)، که
ممکن است
برای
فعالسازی
سایر
سرویسها
در هنگام
تغییر یا
اصلاح
اشیاء
سیستم فایل
استفاده
شوند.
ببینید
systemd.path(5).
10.واحدهای
برش (Slice units)، که
میتوانند
برای
گروهبندی
واحدهایی
که
فرآیندهای
سیستم را
مدیریت
میکنند
(مانند
واحدهای service و
scope) در یک
ساختار
سلسلهمراتبی
درختی به
منظور
مدیریت
منابع به
کار روند.
ببینید
systemd.slice(5).
11.واحدهای
محدوده (Scope units)،
که شبیه به
واحدهای
سرویس
هستند، اما
به جای
راهاندازی
فرآیندهای
خارجی،
فرآیندهایی
را که از قبل
ایجاد
شدهاند
مدیریت
میکنند.
ببینید
systemd.scope(5).
واحدها بر
اساس
فایلهای
پیکربندی
خود
نامگذاری
میشوند.
برخی از
واحدها
دارای
معناشناسی
ویژه هستند.
فهرست
مفصلی از
آنها در
systemd.special(7) در
دسترس است.
systemd انواع
مختلفی از
وابستگیها
را
میشناسد،
از جمله
وابستگیهای
نیازمندی
مثبت و منفی
(یعنی Requires= و
Conflicts=) و همچنین
وابستگیهای
ترتیبی (After= و
Before=). نکته:
وابستگیهای
ترتیبی و
نیازمندی
متعامد
(مستقل از
یکدیگر)
هستند. اگر
تنها یک
وابستگی
نیازمندی
بین دو واحد
وجود داشته
باشد (به
عنوان مثال
foo.service به bar.service نیاز
داشته
باشد)، اما
هیچ
وابستگی
ترتیبی
وجود
نداشته
باشد (مثلاً
foo.service پس از bar.service
اجرا شود) و
درخواست
شروع هر دو
داده شود،
آنها به
صورت موازی
شروع
خواهند شد.
این یک
الگوی رایج
است که هر دو
وابستگی
نیازمندی و
ترتیبی بین
دو واحد
قرار گیرند.
همچنین
توجه داشته
باشید که
بیشتر
وابستگیها
به صورت
ضمنی توسط systemd
ایجاد و
نگهداری
میشوند. در
اکثر
موارد،
باید نیازی
به اعلام
دستی
وابستگیهای
اضافی
نباشد،
اگرچه
انجام این
کار ممکن
است.
برنامههای
کاربردی و
واحدها (از
طریق
وابستگیها)
ممکن است
تغییر
وضعیت
واحدها را
درخواست
کنند. در systemd،
این
درخواستها
به عنوان
«کارها» ('jobs')
کپسولهسازی
شده و در صف
کارها
نگهداری
میشوند.
کارها ممکن
است با
موفقیت
انجام شوند
یا شکست
بخورند؛
ترتیب
اجرای
آنها بر
اساس
وابستگیهای
ترتیبی
واحدهایی
است که برای
آنها
زمانبندی
شدهاند.
در هنگام
بوت، systemd واحد
هدف default.target را
فعال
میکند که
وظیفه آن
فعالسازی
سرویسها و
سایر
واحدهای
زمان بوت با
فراخوانی
آنها از
طریق
وابستگیها
است.
معمولاً
نام این
واحد صرفاً
یک نام
مستعار
(پیوند
نمادین)
برای یکی از
موارد graphical.target
(برای
بوتهای
کامل با
رابط
کاربری
گرافیکی) یا
multi-user.target (برای
بوتهای
محدود
کنسولی به
منظور
استفاده در
محیطهای
تعبیهشده
یا سرور، یا
موارد
مشابه؛
زیرمجموعهای
از graphical.target) است.
با این حال،
به
صلاحدید
مدیر سیستم
است که آن را
به عنوان یک
نام مستعار
برای هر
واحد هدف
دیگری
پیکربندی
کند. برای
جزئیات
مربوط به
این
واحدهای
هدف systemd.special(7) را
ببینید.
در نخستین
بوت، systemd
واحدها را
بر اساس
خطمشی
پیشتنظیم
(preset) فعال یا
غیرفعال
خواهد کرد.
ببینید systemd.preset(5)
و
«معناشناسی
اولین بوت»
در machine-id(5).
systemd تنها یک
مجموعه
حداقلی از
واحدها را
در حافظه
بارگذاریشده
نگه
میدارد.
بهطور
مشخص، تنها
واحدهایی
در حافظه
بارگذاریشده
نگه داشته
میشوند که
حداقل یکی
از شرایط
زیر برای
آنها صادق
باشد:
1.در
وضعیت active، activating،
deactivating یا failed باشد
(یعنی در هر
وضعیتی به
جز وضعیت
"inactive")
2.یک کار
در صف برای
آن وجود
داشته
باشد
3.یک
وابستگی
برای حداقل
یک واحد
دیگر باشد
که در حافظه
بارگذاری
شده است
4.نوعی
منبع هنوز
به آن تخصیص
داده شده
باشد (مثلاً
یک واحد
سرویس که
غیرفعال
است اما
فرآیندی
برای آن
هنوز باقی
مانده و
درخواست
خاتمه را
نادیده
گرفته است)
5.بهصورت
برنامهنویسیشده
از طریق
فراخوانی D-Bus
در حافظه
پین شده
باشد
systemd بهطور
خودکار و
ضمنی
واحدها را
از دیسک
بارگذاری
میکند —
اگر هنوز
بارگذاری
نشده باشند
— به محض
اینکه
عملیاتی
برای آنها
درخواست
شود.
بنابراین،
از بسیاری
جهات، این
واقعیت که
یک واحد
بارگذاری
شده است یا
خیر برای
کلاینتها
نامرئی است.
از systemctl list-units --all
برای فهرست
کردن جامع
تمام
واحدهایی
که در حال
حاضر
بارگذاری
شدهاند
استفاده
کنید. هر
واحدی که
هیچیک از
شرایط بالا
در مورد آن
صدق نکند،
بلافاصله
از حافظه
تخلیه
میشود.
توجه داشته
باشید که
وقتی یک
واحد از
حافظه
تخلیه
میشود،
دادههای
حسابداری
(accounting) آن نیز
پاک
میگردد. با
این حال،
این
دادهها
بهطور کلی
از دست
نمیروند،
زیرا هر
زمان که یک
واحد خاموش
میشود، یک
رکورد لاگ
ژورنال
تولید
میشود که
منابع
مصرفشده
را اعلام
مینماید.
فرآیندهایی
که systemd اجرا
میکند در
گروههای
کنترل
لینوکس (control groups)
مجزا قرار
میگیرند
که بر اساس
واحدی که به
آن تعلق
دارند در
سلسلهمراتب
خصوصی systemd
نامگذاری
شدهاند.
(برای
اطلاعات
بیشتر
درباره
گروههای
کنترل یا به
اختصار "cgroups"،
گروههای
کنترل نسخه
۲ (Control Groups v2)[4] را
ببینید). systemd از
این قابلیت
برای
ردگیری
مؤثر
فرآیندها
استفاده
میکند.
اطلاعات
گروه کنترل
در هسته
نگهداری
میشود و از
طریق
سلسلهمراتب
سیستم فایل
(در زیر /sys/fs/cgroup/) یا
در
ابزارهایی
مانند systemd-cgls(1)
یا ps(1) قابل
دسترسی است
(دستور ps xawf -eo
pid,user,cgroup,args به ویژه
برای فهرست
کردن تمام
فرآیندها و
واحدهای systemd
که به آنها
تعلق دارند
بسیار مفید
است).
systemd تا حد
زیادی با
سیستم SysV init
سازگار است:
اسکریپتهای
SysV init پشتیبانی
میشوند و
صرفاً به
عنوان یک
قالب فایل
پیکربندی
جایگزین
(هرچند
محدود)
خوانده
میشوند.
رابط SysV /dev/initctl
ارائه شده
است و
پیادهسازیهای
سازگاری از
ابزارهای
مختلف
کلاینت SysV در
دسترس
هستند.
علاوه بر
این،
عملکردهای
تثبیتشده
یونیکس
مانند /etc/fstab یا
پایگاه
داده utmp
پشتیبانی
میشوند.
systemd یک سیستم
تراکنش
حداقلی
دارد: اگر
درخواست
شروع یا
خاموش شدن
یک واحد
داده شود،
آن واحد و
تمام
وابستگیهایش
را به یک
تراکنش
موقت اضافه
میکند. سپس
بررسی
میکند که
آیا تراکنش
سازگار است
یا خیر (یعنی
آیا ترتیب
تمام
واحدها
بدون چرخه
است یا خیر).
اگر نباشد،
systemd تلاش
میکند آن
را اصلاح
کند و
کارهای
غیرضروری
را از
تراکنش که
ممکن است
چرخه را
برطرف کند
حذف
مینماید.
همچنین systemd
تلاش
میکند
کارهای
غیرضروری
را در
تراکنش که
باعث متوقف
شدن یک
سرویس در
حال اجرا
میشوند
متوقف سازد.
در نهایت
بررسی
میشود که
آیا کارهای
تراکنش با
کارهایی که
قبلاً در صف
قرار
گرفتهاند
در تضاد
هستند یا
خیر، و در
صورت لزوم
تراکنش در
آن زمان لغو
میشود. اگر
همه چیز
درست پیش
رفت و
تراکنش
سازگار و
اثرات
جانبی آن به
حداقل
رسید، با
تمام
کارهای
معوق قبلی
ادغام شده و
به صف اجرا
اضافه
میشود. در
عمل این
بدان
معناست که
قبل از
اجرای یک
عملیات
درخواستی،
systemd منطقی
بودن آن را
بررسی
میکند، در
صورت امکان
آن را اصلاح
مینماید و
تنها در
صورتی با
شکست مواجه
میشود که
واقعاً
نتواند کار
کند.
توجه
داشته
باشید که
تراکنشها
مستقل از
وضعیت یک
واحد در
زمان اجرا
تولید
میشوند؛
از این رو
برای مثال
اگر
درخواست یک
کار شروع
روی یک واحد
از قبل
شروعشده
داده شود،
باز هم یک
تراکنش
ایجاد
میکند و هر
وابستگی
غیرفعال را
بیدار
مینماید (و
طبق روابط
تعریفشده
باعث
انتشار
کارهای
دیگر
میشود). این
بدان دلیل
است که کار
قرارگرفته
در صف در
زمان اجرا
با وضعیت
واحد هدف
مقایسه
میشود و
هنگامی که
هر دو وضعیت
برقرار
باشند به
عنوان موفق
و کامل
علامتگذاری
میگردد. با
این حال،
این کار به
دلیل روابط
تعریفشده
وابستگیهای
دیگری را
نیز به
همراه
میآورد و
بدین ترتیب
در مثال ما
منجر به
قرار گرفتن
کارهای
شروع برای
هر یک از آن
واحدهای
غیرفعال در
صف نیز
میشود.
واحدها
ممکن است به
صورت پویا
در زمان
راهاندازی
سیستم و
بارگذاری
مجدد مدیر
سیستم
تولید
شوند، به
عنوان مثال
بر اساس
سایر
فایلهای
پیکربندی
یا
پارامترهای
ارسالشده
در خط فرمان
هسته. برای
جزئیات،
ببینید
systemd.generator(7).
دایرکتوریهای
واحد
سیستم
مدیر
سیستم systemd
پیکربندی
واحد را از
دایرکتوریهای
گوناگونی
میخواند.
بستههایی
که
میخواهند
فایلهای
واحد را نصب
کنند باید
آنها را در
دایرکتوری
بازگرداندهشده
توسط
pkg-config systemd
--variable=systemdsystemunitdir قرار
دهند.
دایرکتوریهای
دیگری که
بررسی
میشوند
عبارتند از
/usr/local/lib/systemd/system و /usr/lib/systemd/system.
پیکربندی
کاربر
همیشه
اولویت
دارد.
pkg-config systemd
--variable=systemdsystemconfdir مسیر
دایرکتوری
پیکربندی
سیستم را
برمیگرداند.
بستهها
باید
محتوای این
دایرکتوریها
را تنها با
دستورات
enable
و
disable از
ابزار
systemctl(1)
تغییر دهند.
فهرست کامل
دایرکتوریها
در
systemd.unit(5)
ارائه شده
است.
دایرکتوریهای
واحد
کاربر
قوانین
مشابهی
برای
دایرکتوریهای
واحد کاربر
اعمال
میشود. با
این حال، در
اینجا از
مشخصات
شاخه پایه XDG (XDG
Base Directory specification)[5] برای
یافتن
واحدها
پیروی
میشود.
برنامههای
کاربردی
باید
فایلهای
واحد خود را
در
دایرکتوری
بازگرداندهشده
توسط
pkg-config systemd
--variable=systemduserunitdir قرار
دهند.
پیکربندی
سراسری در
دایرکتوری
گزارششده
توسط
pkg-config systemd
--variable=systemduserconfdir انجام
میشود.
دستورات
enable
و
disable از
ابزار
systemctl(1)
میتوانند
فعال/غیرفعالسازی
سراسری
(یعنی برای
همه
کاربران) و
خصوصی (برای
یک کاربر)
واحدها را
مدیریت
کنند. فهرست
کامل
دایرکتوریها
در
systemd.unit(5)
ارائه شده
است.
دایرکتوری
اسکریپتهای
SysV init
مکان
دایرکتوری
اسکریپتهای
SysV init در بین
توزیعها
متفاوت است.
اگر systemd
نتواند یک
فایل واحد
بومی برای
یک سرویس
درخواستی
پیدا کند،
به دنبال یک
اسکریپت SysV init
با همان نام
(با حذف
پسوند .service)
میگردد.
دایرکتوری
پیوندهای
سطح اجرای SysV (link
farm)
مکان
دایرکتوری
پیوندهای
سطح اجرای SysV
بین
توزیعها
متفاوت است.
هنگام
تعیین
اینکه آیا
یک سرویس
باید فعال
شود یا خیر،
systemd این
پیوندها را
در نظر
میگیرد.
توجه داشته
باشید که یک
واحد سرویس
دارای فایل
پیکربندی
بومی را
نمیتوان
با فعال
کردن آن در
پیوندهای
سطح اجرای SysV
راهاندازی
کرد.
این سرویس
به
سیگنالهای
فرآیند
مختلف
یونیکس گوش
میدهد که
میتوانند
برای
درخواست
ناهمگام
اقدامات
گوناگون
استفاده
شوند.
مدیریت
سیگنال در
مراحل
بسیار
اولیه
راهاندازی،
پیش از
فراخوانی
هرگونه
فرآیند
دیگر فعال
میشود. با
این حال، یک
مدیر
کانتینر
ناظر یا
موارد
مشابه که
قصد دارند
این عملیات
را از طریق
این
سازوکار
درخواست
کنند، باید
توجه داشته
باشند که
این قابلیت
در مراحل
ابتدایی
مقداردهی
اولیه در
دسترس نیست.
یک پیام
اعلان sd_notify()
حاوی فیلد
X_SYSTEMD_SIGNALS_LEVEL=2 به محض
فعال شدن
گردانندههای
سیگنال
ارسال
میشود؛
زیر را
ببینید. این
پیام
میتواند
برای
زمانبندی
صحیح ارسال
این
سیگنالها
استفاده
شود.
SIGTERM
با
دریافت این
سیگنال،
مدیر سیستم
systemd وضعیت خود
را سریالی
کرده،
مجدداً خود
را اجرا
میکند و
وضعیت
ذخیرهشده
را دوباره
بازیابی
مینماید.
این عمل
عمدتاً
معادل
دستور
systemctl daemon-reexec
است.
مدیران
کاربر systemd
هنگام
دریافت این
سیگنال
واحد exit.target را
آغاز
میکنند.
این کار
عمدتاً
معادل
دستور systemctl --user start
exit.target --job-mode=replace-irreversibly
است.
SIGINT
با
دریافت این
سیگنال،
مدیر سیستم
systemd واحد ctrl-alt-del.target را
آغاز
میکند. این
کار عمدتاً
معادل
دستور
systemctl start
ctrl-alt-del.target --job-mode=replace-irreversibly
است. اگر این
سیگنال بیش
از ۷ بار در
مدت ۲ ثانیه
دریافت
شود، یک
راهاندازی
مجدد (reboot) فوری
صورت
میپذیرد.
توجه داشته
باشید که
فشردن Ctrl+Alt+Del روی
کنسول این
سیگنال را
ارسال
میکند.
بنابراین
اگر یک
راهاندازی
مجدد متوقف
شده و گیر
کرده باشد،
فشردن Ctrl+Alt+Del بیش
از ۷ بار در ۲
ثانیه روشی
نسبتاً
مطمئن برای
راهاندازی
مجدد فوری
سیستم است.
مدیران
کاربر systemd با
این سیگنال
همانند SIGTERM
رفتار
میکنند.
SIGWINCH
هنگامی
که این
سیگنال
دریافت
میشود،
مدیر سیستم
systemd واحد kbrequest.target را
آغاز
میکند. این
کار عمدتاً
معادل
دستور
systemctl start
kbrequest.target است.
این
سیگنال
توسط
مدیران
کاربر systemd
نادیده
گرفته
میشود.
SIGPWR
هنگامی
که این
سیگنال
دریافت
میشود،
مدیر systemd واحد
sigpwr.target را آغاز
میکند. این
کار عمدتاً
معادل
دستور systemctl start sigpwr.target
است.
SIGUSR1
هنگامی
که این
سیگنال
دریافت
میشود،
مدیر systemd تلاش
میکند تا
مجدداً به
گذرگاه D-Bus
متصل شود.
SIGUSR2
هنگامی
که این
سیگنال
دریافت
میشود،
مدیر systemd
وضعیت کامل
خود را در
قالب قابل
خواندن
برای انسان
لاگ میکند.
دادههای
لاگشده
مشابه
خروجی
دستور systemd-analyze dump
است.
SIGHUP
پیکربندی
کامل دیمن
را مجدداً
بارگذاری
میکند. این
کار عمدتاً
معادل
دستور systemctl daemon-reload
است.
SIGRTMIN+0
وارد
حالت
پیشفرض
میشود،
واحد default.target را
آغاز
میکند. این
کار عمدتاً
معادل
دستور systemctl isolate
default.target است.
SIGRTMIN+1
وارد
حالت نجات (rescue)
میشود،
واحد rescue.target را
آغاز
میکند. این
کار عمدتاً
معادل
دستور systemctl isolate
rescue.target است.
SIGRTMIN+2
وارد
حالت
اضطراری (emergency)
میشود،
واحد emergency.service را
آغاز
میکند. این
کار عمدتاً
معادل
دستور systemctl isolate
emergency.service است.
SIGRTMIN+3
دستگاه
را متوقف (halt)
میکند،
واحد halt.target را
آغاز
میکند. این
کار عمدتاً
معادل
دستور systemctl start halt.target
--job-mode=replace-irreversibly است.
SIGRTMIN+4
دستگاه
را خاموش (power off)
میکند،
واحد poweroff.target را
آغاز
میکند. این
کار عمدتاً
معادل
دستور systemctl start poweroff.target
--job-mode=replace-irreversibly است.
SIGRTMIN+5
دستگاه
را مجدداً
راهاندازی
(reboot) میکند،
واحد reboot.target را
آغاز
میکند. این
کار عمدتاً
معادل
دستور systemctl start reboot.target
--job-mode=replace-irreversibly است.
SIGRTMIN+6
دستگاه
را از طریق kexec
مجدداً
راهاندازی
میکند،
واحد kexec.target را
آغاز
میکند. این
کار عمدتاً
معادل
دستور systemctl start kexec.target
--job-mode=replace-irreversibly است.
SIGRTMIN+7
فضای
کاربری را
مجدداً
راهاندازی
میکند،
واحد soft-reboot.target را
آغاز
میکند. این
کار عمدتاً
معادل
دستور
systemctl start soft-reboot.target
--job-mode=replace-irreversibly است.
افزوده
شده در نسخه
254.
SIGRTMIN+13
دستگاه
را
بلافاصله
متوقف (halt)
میکند.
SIGRTMIN+14
دستگاه
را
بلافاصله
خاموش (power off)
میکند.
SIGRTMIN+15
دستگاه
را
بلافاصله
مجدداً
راهاندازی
(reboot) میکند.
SIGRTMIN+16
دستگاه
را
بلافاصله
با kexec مجدداً
راهاندازی
میکند.
SIGRTMIN+17
فضای
کاربری را
بلافاصله
مجدداً
راهاندازی
میکند.
افزوده
شده در نسخه
254.
SIGRTMIN+20
نمایش
پیامهای
وضعیت روی
کنسول را
فعال
میکند،
همانطور
که از طریق
systemd.show_status=1 در خط
فرمان هسته
کنترل
میشود.
ممکن است
بخواهید از
SetShowStatus() به جای
SIGRTMIN+20 استفاده
کنید تا از
شرایط
رقابتی (race conditions)
جلوگیری
شود. ببینید
org.freedesktop.systemd1(5).
SIGRTMIN+21
نمایش
پیامهای
وضعیت روی
کنسول را
غیرفعال
میکند،
همانطور
که از طریق
systemd.show_status=0 در خط
فرمان هسته
کنترل
میشود.
ممکن است
بخواهید از
SetShowStatus() به جای
SIGRTMIN+21 استفاده
کنید تا از
شرایط
رقابتی
جلوگیری
شود. ببینید
org.freedesktop.systemd1(5).
SIGRTMIN+22
سطح لاگ
مدیر سرویس
را روی "debug"
تنظیم
میکند، به
روشی معادل
systemd.log_level=debug در خط
فرمان
هسته.
SIGRTMIN+23
سطح لاگ
را به مقدار
پیکربندیشده
آن
بازمیگرداند.
مقدار
پیکربندیشده
– به ترتیب
اولویت – از
مقدار
مشخصشده
با
systemd.log-level= در خط
فرمان
هسته، یا
مقدار
مشخصشده
با
LogLevel= در
فایل
پیکربندی،
یا مقدار
پیشفرض
داخلی "info"
مشتق
میشود.
افزوده
شده در نسخه
239.
SIGRTMIN+24
بلافاصله
از مدیر
خارج
میشود
(تنها برای
نمونههای
--user در دسترس
است).
افزوده
شده در نسخه
195.
SIGRTMIN+25
با
دریافت این
سیگنال
مدیر systemd
مجدداً خود
را اجرا
میکند. این
عمل عمدتاً
معادل
دستور
systemctl daemon-reexec
است به جز
اینکه به
صورت
ناهمگام
انجام
خواهد شد.
مدیر
سیستم systemd با
این سیگنال
همانند SIGTERM
رفتار
میکند.
افزوده
شده در نسخه
250.
SIGRTMIN+26
مقصد لاگ
(log target) را به
مقدار
پیکربندیشده
آن
بازمیگرداند.
مقدار
پیکربندیشده
– به ترتیب
اولویت – از
مقدار
مشخصشده
با
systemd.log-target= در خط
فرمان
هسته، یا
مقدار
مشخصشده
با
LogTarget= در
فایل
پیکربندی،
یا مقدار
پیشفرض
داخلی مشتق
میشود.
افزوده
شده در نسخه
239.
SIGRTMIN+27, SIGRTMIN+28
مقصد لاگ
را روی "console" با
SIGRTMIN+27 (یا روی "kmsg"
با
SIGRTMIN+28) تنظیم
میکند، به
شیوهای
معادل
systemd.log_target=console
(یا
systemd.log_target=kmsg در
SIGRTMIN+28) در خط
فرمان هسته.
افزوده
شده در نسخه
239.
بلوک
محیطی برای
مدیر سیستم
در ابتدا
توسط هسته
تنظیم
میشود.
(بهویژه،
انتسابهای
"key=value" در خط
فرمان هسته
به
متغیرهای
محیطی برای
فرآیند PID 1
تبدیل
میشوند).
برای مدیر
کاربر،
مدیر سیستم
محیط را
همانطور
که در بخش
«متغیرهای
محیطی در
فرآیندهای
ایجادشده»
در systemd.exec(5) شرح
داده شده
تنظیم
میکند.
تنظیم DefaultEnvironment=
در مدیر
سیستم برای
همه
سرویسها
از جمله user@.service
اعمال
میشود.
ورودیهای
اضافی ممکن
است (مانند
هر سرویس
دیگری) از
طریق
تنظیمات Environment=
و EnvironmentFile= برای
user@.service
پیکربندی
شوند
(ببینید systemd.exec(5)).
همچنین
متغیرهای
محیطی
اضافی
میتوانند
از طریق
تنظیم ManagerEnvironment=
در systemd-system.conf(5) و
systemd-user.conf(5) تنظیم
گردند.
برخی از
متغیرهای
شناختهشده
توسط systemd:
$SYSTEMD_LOG_LEVEL
حداکثر
سطح لاگ
پیامهای
ارسالی
(پیامهای
با سطح لاگ
بالاتر،
یعنی
پیامهای
با اهمیت
کمتر،
متوقف
خواهند شد).
فهرستی از
مقادیر
جداشده با
کاما را
میپذیرد.
یک مقدار
میتواند
یکی از
موارد زیر
(به ترتیب
کاهش اهمیت)
باشد:
emerg،
alert،
crit،
err،
warning،
notice،
info،
debug یا
یک عدد صحیح
در محدوده 0...7.
برای
اطلاعات
بیشتر
syslog(3) را
ببینید. هر
مقدار
میتواند
به صورت
اختیاری با
یکی از
پیشوندهای
console،
syslog،
kmsg یا
journal به همراه
دونقطه
همراه شود
تا حداکثر
سطح لاگ را
برای آن
مقصد لاگ
خاص تنظیم
کند (برای
مثال
SYSTEMD_LOG_LEVEL=debug,console:info
مشخص
میکند که
لاگبرداری
در سطح debug
باشد، مگر
هنگام
لاگبرداری
در کنسول که
باید در سطح
info باشد). توجه
داشته
باشید که
حداکثر سطح
لاگ سراسری
بر هر سطح
لاگ
مشخصشده
برای مقصد
خاص اولویت
دارد.
این گزینه
میتواند
با --log-level=
بازنویسی
شود.
$SYSTEMD_LOG_COLOR
یک مقدار
بولی (boolean). اگر true
باشد،
پیامهای
نوشتهشده
در tty بر اساس
اولویت
رنگی
خواهند شد.
این گزینه
میتواند
با --log-color=
بازنویسی
شود.
$SYSTEMD_LOG_TIME
یک مقدار
بولی. اگر true
باشد،
پیامهای
لاگ کنسول
با یک برچسب
زمانی (timestamp)
پیشوندگذاری
خواهند شد.
این گزینه
میتواند
با --log-time=
بازنویسی
شود.
افزوده
شده در نسخه
246.
$SYSTEMD_LOG_LOCATION
یک مقدار
بولی. اگر true
باشد،
پیامها با
نام فایل و
شماره خط در
کد منبع که
پیام از
آنجا
سرچشمه
میگیرد
پیشوندگذاری
میشوند.
این گزینه
میتواند
با --log-location=
بازنویسی
شود.
$SYSTEMD_LOG_TID
یک مقدار
بولی. اگر true
باشد،
پیامها با
شناسه عددی
رشته جاری (TID)
پیشوندگذاری
میشوند.
افزوده
شده در نسخه
247.
$SYSTEMD_LOG_TARGET
مقصد
پیامهای
لاگ. یکی از
موارد زیر
است:
console (لاگ
در tty
متصلشده)،
console-prefixed (لاگ در tty
متصلشده
اما با
پیشوندهایی
که سطح لاگ و
"facility" را
کدگذاری
میکنند؛
ببینید
syslog(3))،
kmsg (لاگ در
بافر لاگ
حلقوی
هسته)،
journal
(لاگ در
ژورنال)،
journal-or-kmsg (لاگ در
ژورنال در
صورت موجود
بودن، و در
غیر این
صورت در kmsg)،
auto
(تعیین
خودکار
مقصد لاگ
مناسب،
حالت
پیشفرض)،
null
(غیرفعال
کردن خروجی
لاگ).
این گزینه
میتواند
با --log-target=
بازنویسی
شود.
$SYSTEMD_LOG_RATELIMIT_KMSG
اینکه
آیا
محدودیت
نرخ (ratelimit) برای kmsg
اعمال شود
یا خیر. یک
مقدار بولی
میپذیرد.
پیشفرض "true"
است. در صورت
غیرفعال
بودن، systemd
پیامهای
نوشتهشده
در kmsg را
محدود
نمیکند.
افزوده
شده در نسخه
254.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS,
$XDG_DATA_HOME, $XDG_DATA_DIRS
مدیر
کاربر systemd از
این
متغیرها
مطابق با
مشخصات
شاخه پایه XDG (XDG
Base Directory specification)[5] برای
یافتن
پیکربندی
خود
استفاده
میکند.
$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH,
$SYSTEMD_ENVIRONMENT_GENERATOR_PATH
مکانهایی
را که systemd در
آنها به
دنبال
فایلهای
واحد و
مولدها (generators)
میگردد
کنترل
میکند.
این
متغیرها
ممکن است
حاوی
فهرستی از
مسیرها
باشند که با
دونقطه (":")
از هم جدا
شدهاند. در
صورت
تنظیم، اگر
فهرست با یک
مؤلفه خالی
("...:") خاتمه
یابد، این
فهرست به
ابتدای
مجموعه
مسیرهای
معمول
اضافه
میشود. در
غیر این
صورت،
فهرست
مشخصشده
جایگزین
مجموعه
مسیرهای
معمول
میگردد.
$SYSTEMD_PAGER, $PAGER
صفحهبندیکننده
(pager) مورد
استفاده
هنگامی که
--no-pager داده
نشده باشد.
در صورت
تنظیم
$SYSTEMD_PAGER
از آن
استفاده
میشود؛ در
غیر این
صورت
$PAGER به
کار میرود.
اگر هیچیک
از
$SYSTEMD_PAGER و
$PAGER
تنظیم نشده
باشند،
مجموعهای
از
پیادهسازیهای
شناختهشده
صفحهبندیکننده
به نوبت
امتحان
میشوند،
از جمله
less(1) و
more(1)، تا
زمانی که
یکی پیدا
شود. اگر هیچ
پیادهسازی
صفحهبندیکنندهای
کشف نشود،
هیچ
صفحهبندیکنندهای
فراخوانی
نمیشود.
تنظیم این
متغیرهای
محیطی روی
یک رشته
خالی یا
مقدار "cat"
معادل
ارسال
گزینه
--no-pager
است.
توجه: اگر
$SYSTEMD_PAGERSECURE تنظیم
نشده باشد،
$SYSTEMD_PAGER و $PAGER
تنها
میتوانند
برای
غیرفعال
کردن
صفحهبندیکننده
(با "cat" یا "")
استفاده
شوند، و در
غیر این
صورت
نادیده
گرفته
میشوند.
$SYSTEMD_LESS
بازنویسی
گزینههای
ارسالشده
به
less (بهطور
پیشفرض "FRSXMK").
کاربران
ممکن است به
ویژه
بخواهند دو
گزینه را
تغییر
دهند:
K
این
گزینه به
صفحهبندیکننده
دستور
میدهد که
با فشردن Ctrl+C
بلافاصله
خارج شود.
برای اینکه
به
less اجازه
دهید خود
فشردن Ctrl+C را
مدیریت کند
تا به اعلان
دستور
صفحهبندیکننده
بازگردد،
این گزینه
را لغو کنید.
اگر مقدار
$SYSTEMD_LESS شامل "K"
نباشد و
صفحهبندیکننده
فراخوانیشده
less باشد،
فشردن Ctrl+C
توسط فایل
اجرایی
نادیده
گرفته
میشود و
باید توسط
صفحهبندیکننده
مدیریت
گردد.
X
این
گزینه به
صفحهبندیکننده
دستور
میدهد که
رشتههای
مقداردهی
اولیه و
پایان termcap را
به ترمینال
ارسال نکند.
این گزینه
بهطور
پیشفرض
تنظیم شده
است تا
اجازه دهد
خروجی
دستور حتی
پس از خروج
از
صفحهبندیکننده
در ترمینال
قابل
مشاهده
باقی بماند.
با این
وجود، این
امر مانع از
کارکرد
برخی از
قابلیتهای
صفحهبندیکننده
میشود،
بهویژه
خروجی
صفحهبندیشده
را
نمیتوان
با ماوس
پیمایش
کرد.
توجه
داشته
باشید که
تنظیم
متغیر
محیطی
معمولی $LESS
هیچ تاثیری
برای
فراخوانیهای
less توسط
ابزارهای systemd
ندارد.
برای
توضیحات
بیشتر less(1) را
ببینید.
$SYSTEMD_LESSCHARSET
بازنویسی
مجموعه
نویسه (charset)
ارسالشده
به
less (بهطور
پیشفرض
"utf-8"، اگر
ترمینال
فراخواننده
سازگار با UTF-8
تشخیص داده
شود).
توجه
داشته
باشید که
تنظیم
متغیر
محیطی
معمولی $LESSCHARSET
هیچ تاثیری
برای
فراخوانیهای
less توسط
ابزارهای systemd
ندارد.
$SYSTEMD_PAGERSECURE
دستورات
رایج
صفحهبندی
مانند
less(1)،
علاوه بر
«صفحهبندی»،
یعنی
پیمایش در
خروجی، از
باز کردن یا
نوشتن در
فایلهای
دیگر و
اجرای
دستورات
دلخواه شل
پشتیبانی
میکنند.
هنگامی که
دستورات با
امتیازات
بالا، برای
مثال تحت
sudo(8)
یا
pkexec(1)
فراخوانی
میشوند،
صفحهبندیکننده
به یک مرز
امنیتی
تبدیل
میشود.
باید
مراقبت شود
که تنها
برنامههای
با
قابلیتهای
کاملاً
محدود به
عنوان
صفحهبندیکننده
استفاده
شوند، و
ویژگیهای
تعاملی
ناخواسته
مانند باز
کردن یا
ایجاد
فایلهای
جدید یا
راهاندازی
فرآیندهای
فرعی مجاز
نباشد.
«حالت امن»
برای
صفحهبندیکننده
ممکن است
مطابق با
توضیحات
زیر فعال
شود،
اگر
صفحهبندیکننده
از آن
پشتیبانی
کند (بسیاری
از
صفحهبندیکنندهها
به گونهای
نوشته
نشدهاند
که این
موضوع را در
نظر بگیرند).
توصیه
میشود در
صورت اجازه
دادن به
کاربران
غیرقابل
اعتماد
برای اجرای
دستورات با
امتیازات
بالا، یا
«حالت امن»
را
بهصراحت
فعال کنید
یا با
استفاده از
--no-pager یا
PAGER=cat
صفحهبندیکننده
را کاملاً
غیرفعال
نمایید.
این گزینه
یک آرگومان
بولی
میپذیرد.
هنگامی که
روی true تنظیم
شود، «حالت
امن»
صفحهبندیکننده
فعال
میشود. در
«حالت
امن»، LESSSECURE=1
در هنگام
فراخوانی
صفحهبندیکننده
تنظیم
میشود، که
به
صفحهبندیکننده
دستور
میدهد
دستوراتی
را که
فایلهای
جدید باز
میکنند یا
میسازند
یا
فرآیندهای
فرعی جدید
راهاندازی
مینمایند
غیرفعال
کند. در حال
حاضر تنها
less(1) شناخته
شده است که
این متغیر
را درک کرده
و «حالت
امن» را
پیادهسازی
میکند.
هنگامی که
روی false تنظیم
شود، هیچ
محدودیتی
بر روی
صفحهبندیکننده
اعمال
نمیشود.
تنظیم SYSTEMD_PAGERSECURE=0
یا حذف
نکردن آن از
محیط به ارث
رسیده ممکن
است به
کاربر
اجازه دهد
دستورات
دلخواه را
فراخوانی
کند.
هنگامی که
$SYSTEMD_PAGERSECURE تنظیم
نشده باشد،
ابزارهای systemd
تلاش
میکنند تا
بهطور
خودکار
تشخیص دهند
که آیا
«حالت امن»
باید فعال
شود یا خیر و
آیا
صفحهبندیکننده
از آن
پشتیبانی
میکند یا
خیر. اگر
شناسه
کاربری
مؤثر (effective UID) با
مالک نشست
ورود یکسان
نباشد
(ببینید geteuid(2) و
sd_pid_get_owner_uid(3))، یا
هنگام اجرا
تحت sudo(8) یا
ابزارهای
مشابه ($SUDO_UID
تنظیم شده
باشد [6])،
«حالت امن»
فعال
میشود. در
این موارد،
SYSTEMD_PAGERSECURE=1 تنظیم
میشود و
صفحهبندیکنندههایی
که مشخص
نیست «حالت
امن» را
پیادهسازی
میکنند
اصلاً
استفاده
نخواهند شد.
توجه داشته
باشید که
این تشخیص
خودکار
تنها
رایجترین
سازوکارها
را برای
افزایش
امتیازات
پوشش
میدهد و
برای راحتی
در نظر
گرفته شده
است. توصیه
میشود
بهصراحت
$SYSTEMD_PAGERSECURE را
تنظیم کرده
یا
صفحهبندیکننده
را غیرفعال
کنید.
توجه
داشته
باشید که
اگر قرار
است
متغیرهای
$SYSTEMD_PAGER یا $PAGER
رعایت شوند
(به جز برای
غیرفعال
کردن
صفحهبندیکننده)،
$SYSTEMD_PAGERSECURE نیز
باید تنظیم
شده باشد.
$SYSTEMD_COLORS
یک
آرگومان
بولی
میپذیرد.
هنگامی که true
باشد، systemd و
ابزارهای
مربوطه از
رنگها در
خروجی خود
استفاده
میکنند،
در غیر این
صورت خروجی
تکرنگ (monochrome)
خواهد بود.
علاوه بر
این، این
متغیر
میتواند
یکی از
مقادیر
ویژه زیر را
بگیرد: "16"،
"256" تا
استفاده از
رنگها را
به ترتیب به
رنگهای
پایه ۱۶ یا
۲۵۶ رنگ ANSI
محدود کند.
این
میتواند
برای
بازنویسی
تصمیم
خودکار بر
اساس $TERM و
آنچه کنسول
به آن متصل
است، مشخص
شود.
$SYSTEMD_URLIFY
مقدار
باید بولی
باشد. کنترل
میکند که
آیا
پیوندهای
قابل کلیک
باید در
خروجی برای
شبیهسازهای
ترمینالی
که از این
قابلیت
پشتیبانی
میکنند
ایجاد شوند
یا خیر. این
میتواند
برای
بازنویسی
تصمیمی که
systemd بر اساس $TERM
و سایر
شرایط
میگیرد
مشخص شود.
$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
توسط systemd
برای
فرآیندهای
تحت نظارت
در طول
فعالسازی
مبتنی بر
سوکت تنظیم
میشوند.
برای
اطلاعات
بیشتر
sd_listen_fds(3)
را ببینید.
$NOTIFY_SOCKET
توسط
مدیر سرویس
برای
سرویسهایش
به منظور
اعلان
وضعیت و
آمادگی
تنظیم
میشود.
همچنین
توسط مدیر
سرویس برای
اطلاعرسانی
به مدیران
کانتینر
ناظر یا
مدیران
سرویس در
سطوح
بالاتر
درباره
پیشرفت خود
مصرف
میگردد.
برای
اطلاعات
بیشتر
sd_notify(3) و
بخش مربوطه
در زیر را
ببینید.
برای
متغیرهای
محیطی
بیشتر که
توسط systemd و
مؤلفههای
مختلف آن
شناخته
میشوند،
به
متغیرهای
محیطی
شناختهشده[7]
مراجعه
کنید.
هنگامی که
به عنوان
نمونه
سیستم اجرا
میشود، systemd
تعدادی از
گزینههای
فهرستشده
در زیر را
تجزیه
میکند.
آنها
میتوانند
به عنوان
آرگومانهای
خط فرمان
هسته مشخص
شوند که
بسته به
محیطی که systemd
در آن اجرا
میشود از
منابع
متعددی
تجزیه
میگردند.
اگر در داخل
کانتینر
لینوکس
اجرا شود،
این
گزینهها
از
آرگومانهای
خط فرمان
ارسالشده
به خود systemd در
کنار هر یک
از
گزینههای
خط فرمان
فهرستشده
در بخش
گزینهها
در بالا
تجزیه
میشوند.
اگر در خارج
از
کانتینرهای
لینوکس
اجرا شود،
این
آرگومانها
به جای آن از
/proc/cmdline و از
متغیر EFI با
نام "SystemdOptions"
(روی
سیستمهای
EFI) تجزیه
میشوند.
گزینههای
حاصل از /proc/cmdline
اولویت
بالاتری
دارند.
توجه:
استفاده از
"SystemdOptions" منسوخ
شده است.
متغیرهای
زیر شناخته
میشوند:
systemd.unit=, rd.systemd.unit=
واحدی را
که باید در
هنگام بوت
فعال شود
بازنویسی
میکند.
پیشفرض default.target
است. این
ممکن است
برای بوت
موقت به یک
واحد بوت
دیگر، برای
مثال rescue.target یا
emergency.service استفاده
شود. برای
جزئیات
درباره این
واحدها
systemd.special(7)
را ببینید.
گزینهای
که با
پیشوند "rd."
همراه است
تنها در initrd
رعایت
میشود، در
حالی که
گزینه بدون
پیشوند
تنها در
سیستم اصلی
معتبر است.
systemd.dump_core
یک
آرگومان
بولی
میپذیرد
یا در صورت
مشخص شدن
بدون
آرگومان
گزینه را
فعال
میکند. در
صورت فعال
بودن، مدیر
systemd (فرآیند PID 1)
در هنگام
کرش یک
تخلیه
حافظه (core dump)
ایجاد
میکند. در
غیر این
صورت هیچ
تخلیه
حافظهای
ایجاد
نمیشود.
پیشفرض
فعال است.
افزوده
شده در نسخه
233.
systemd.crash_chvt
یک عدد
صحیح مثبت
یا یک
آرگومان
بولی
میپذیرد.
همچنین
میتواند
بدون
آرگومان
مشخص شود که
اثری مشابه
مقدار بولی
مثبت دارد.
اگر یک عدد
صحیح مثبت
(در محدوده
۱–۶۳) مشخص
شود، مدیر
سیستم (PID 1)
ترمینال
مجازی
مشخصشده
را در هنگام
کرش فعال
میکند.
پیشفرض
غیرفعال
است، به این
معنی که هیچ
تلاشی برای
چنین
تغییری
انجام
نمیشود. در
صورت تنظیم
روی فعال،
به جای آن از
ترمینال
مجازی که
پیامهای
هسته در آن
نوشته
میشوند
استفاده
میگردد.
افزوده
شده در نسخه
233.
systemd.crash_shell
یک
آرگومان
بولی
میپذیرد
یا در صورت
مشخص شدن
بدون
آرگومان
گزینه را
فعال
میکند. در
صورت فعال
بودن، مدیر
سیستم (PID 1) در
هنگام کرش
یک پوسته (shell)
را
راهاندازی
مینماید.
در غیر این
صورت هیچ
پوستهای
ایجاد
نمیشود. به
دلایل
امنیتی
بهطور
پیشفرض
غیرفعال
است، زیرا
پوسته با
احراز هویت
گذرواژه
محافظت
نمیشود.
افزوده
شده در نسخه
233.
systemd.crash_action=
یکی از
مقادیر "freeze"،
"reboot" یا "poweroff" را
میپذیرد.
پیشفرض "freeze"
است. در صورت
تنظیم روی
"freeze"، سیستم
هنگام کرش
مدیر سیستم (PID
1) برای مدت
نامحدود
متوقف
میماند. در
صورت تنظیم
روی "reboot"،
مدیر سیستم (PID
1) پس از یک
تأخیر ۱۰
ثانیهای
دستگاه را
بهطور
خودکار
هنگام کرش
مجدداً
راهاندازی
میکند. در
صورت تنظیم
روی "poweroff"،
مدیر سیستم (PID
1) هنگام کرش
دستگاه را
بلافاصله
خاموش
مینماید.
اگر با
systemd.crash_shell
ترکیب شود،
اقدام کرش
پیکربندیشده
پس از خروج
از پوسته
اجرا
میشود.
افزوده
شده در نسخه
256.
systemd.confirm_spawn
یک
آرگومان
بولی یا یک
مسیر به
کنسول
مجازی که
پیامهای
تأیید باید
در آن ارسال
شوند
میپذیرد.
همچنین
میتواند
بدون
آرگومان
مشخص شود که
اثری مشابه
مقدار بولی
مثبت دارد.
در صورت
فعال بودن،
مدیر سیستم (PID
1) هنگام
ایجاد
فرآیندها
با استفاده
از
/dev/console
درخواست
تأیید
میکند. اگر
یک مسیر یا
نام کنسول
(مانند "ttyS0")
ارائه شود،
به جای آن از
کنسول
مجازی
اشارهشده
توسط این
مسیر یا
توصیفشده
توسط نام
دادهشده
استفاده
خواهد شد.
پیشفرض
غیرفعال
است.
افزوده
شده در نسخه
233.
systemd.service_watchdogs=
یک
آرگومان
بولی
میپذیرد.
در صورت
غیرفعال
بودن، تمام
زمانسنجهای
نگهبان
زمان اجرای
سرویس (
WatchdogSec=) و
اقدامات
اضطراری
(مانند
OnFailure= یا
StartLimitAction=) توسط
مدیر سیستم (PID
1) نادیده
گرفته
میشوند؛
ببینید
systemd.service(5).
پیشفرض
فعال است،
یعنی
نگهبانها
و اقدامات
مربوط به
شکست
بهطور
معمول
پردازش
میشوند.
نگهبان
سختافزاری
تحت تأثیر
این گزینه
قرار
نمیگیرد.
افزوده
شده در نسخه
237.
systemd.show_status
یک
آرگومان
بولی یا
مقادیر
ثابت
error و
auto
را
میپذیرد.
همچنین
میتواند
بدون
آرگومان
مشخص شود که
اثری مشابه
با یک مقدار
بولی مثبت
دارد. در
صورت فعال
بودن، مدیر
systemd (PID 1)
بهروزرسانیهای
خلاصه
وضعیت
سرویس را در
طول بوت روی
کنسول
نمایش
میدهد. با
مقدار
error،
تنها
پیامهای
مربوط به
خرابیها
نمایش داده
میشوند و
بوت در غیر
این صورت
بیصدا است.
مقدار
auto
مانند
false
رفتار
میکند تا
زمانی که
تأخیر قابل
توجهی در
بوت رخ دهد.
پیشفرض
فعال است،
مگر اینکه
quiet
به عنوان
گزینه خط
فرمان هسته
ارسال شده
باشد، که در
این صورت
پیشفرض
روی
error تنظیم
میشود. در
صورت مشخص
شدن، گزینه
فایل
پیکربندی
مدیر سیستم
با نام
ShowStatus= را
بازنویسی
میکند؛
ببینید
systemd-system.conf(5).
افزوده
شده در نسخه
233.
systemd.status_unit_format=
مقادیر
name،
description یا
combined
را به عنوان
مقدار
میپذیرد.
اگر
name باشد،
مدیر سیستم
از نامهای
واحد در
پیامهای
وضعیت
استفاده
میکند. اگر
combined باشد،
مدیر سیستم
از نامها و
توضیحات
واحد در
پیامهای
وضعیت
استفاده
مینماید.
در صورت
مشخص شدن،
گزینه فایل
پیکربندی
مدیر سیستم
با نام
StatusUnitFormat=
را
بازنویسی
میکند؛
ببینید
systemd-system.conf(5).
افزوده
شده در نسخه
243.
systemd.log_color, systemd.log_level=,
systemd.log_location, systemd.log_target=,
systemd.log_time, systemd.log_tid,
systemd.log_ratelimit_kmsg
خروجی
لاگ را با
همان
تأثیری که
متغیرهای
محیطی $SYSTEMD_LOG_COLOR،
$SYSTEMD_LOG_LEVEL، $SYSTEMD_LOG_LOCATION،
$SYSTEMD_LOG_TARGET، $SYSTEMD_LOG_TIME،
$SYSTEMD_LOG_TID و $SYSTEMD_LOG_RATELIMIT_KMSG
توضیح داده
شده در بالا
دارند،
کنترل
میکنند.
گزینههای
systemd.log_color، systemd.log_location،
systemd.log_time، systemd.log_tid و
systemd.log_ratelimit_kmsg
میتوانند
بدون
آرگومان
مشخص شوند
که اثری
مشابه با
مقدار بولی
مثبت دارد.
systemd.default_standard_output=,
systemd.default_standard_error=
خروجی
استاندارد
و خروجی
خطای
پیشفرض را
برای
سرویسها و
سوکتها
کنترل
میکند.
یعنی
پیشفرض را
برای
StandardOutput= و
StandardError= کنترل
مینماید
(برای
جزئیات
systemd.exec(5)
را ببینید).
یکی از
مقادیر
inherit،
null،
tty،
journal،
journal+console،
kmsg،
kmsg+console
را
میپذیرد.
اگر
آرگومان
حذف شود،
systemd.default-standard-output=
بهطور
پیشفرض
روی
journal و
systemd.default-standard-error= روی
inherit
تنظیم
میشود.
systemd.setenv=
یک
آرگومان
رشتهای به
شکل VARIABLE=VALUE
میپذیرد.
ممکن است
برای تنظیم
متغیرهای
محیطی
پیشفرض
جهت افزودن
به
فرآیندهای
فرزند
ایجادشده
استفاده
شود. ممکن
است بیش از
یک بار برای
تنظیم
چندین
متغیر
استفاده
شود.
systemd.machine_id=
یک مقدار
هگزادسیمال
۳۲
نویسهای
را برای
تنظیم machine-id
میپذیرد.
بیشتر برای
بوت شبکه که
در آن شناسه
یکسان برای
هر بار بوت
مد نظر است
در نظر
گرفته شده
است.
افزوده
شده در نسخه
229.
systemd.set_credential=,
systemd.set_credential_binary=
یک
اعتبارنامه
سیستم را
تنظیم
میکند که
سپس
میتواند
با استفاده
از تنظیم
ImportCredential= یا
LoadCredential=
به
سرویسهای
سیستم
ارسال شود؛
برای
جزئیات
systemd.exec(5)
را ببینید.
یک جفت از
نام و مقدار
اعتبارنامه
را که با دو
نقطه از هم
جدا
شدهاند
میپذیرد.
پارامتر
systemd.set_credential= مقدار
اعتبارنامه
را در قالب
متن ساده
انتظار
دارد، در
حالی که
پارامتر
systemd.set_credential_binary=
دادههای
دودویی
کدگذاریشده
در Base64 را
میپذیرد.
توجه داشته
باشید که خط
فرمان هسته
معمولاً
توسط
برنامههای
غیرممتاز
در /proc/cmdline قابل
دسترسی است.
بنابراین،
این
سازوکار
برای
انتقال
دادههای
حساس مناسب
نیست. از آن
تنها برای
دادههایی
که حساس
نیستند
(مانند
کلیدها/گواهیهای
عمومی به
جای
کلیدهای
خصوصی) یا در
محیطهای
آزمایش/اشکالزدایی
استفاده
کنید.
برای
اطلاعات
بیشتر
مستندات
اعتبارنامههای
سیستم و
سرویس[8] را
ببینید.
افزوده
شده در نسخه
251.
systemd.import_credentials=
یک
آرگومان
بولی
میپذیرد.
در صورت false
بودن، وارد
کردن
اعتبارنامهها
را از خط
فرمان
هسته، جدول
رشتههای
سازنده OEM
مربوط به DMI/SMBIOS،
زیرسیستم qemu_fw_cfg
یا استاب
هسته EFI
غیرفعال
میکند.
افزوده
شده در نسخه
251.
quiet
خروجی
وضعیت را در
هنگام بوت
خاموش
میکند،
همانند
اثری که
systemd.show_status=no دارد.
توجه داشته
باشید که
این گزینه
توسط خود
هسته نیز
خوانده
میشود و
خروجی لاگ
هسته را
غیرفعال
مینماید.
بنابراین
ارسال این
گزینه
خروجی
معمول از
مدیر سیستم
و هسته را
خاموش
میکند.
افزوده
شده در نسخه
186.
debug
خروجی
اشکالزدایی
را روشن
میکند. این
معادل
systemd.log_level=debug
است. توجه
داشته
باشید که
این گزینه
توسط خود
هسته نیز
خوانده
میشود و
خروجی
اشکالزدایی
هسته را
فعال
مینماید.
بنابراین
ارسال این
گزینه
خروجی
اشکالزدایی
را از مدیر
سیستم و
هسته روشن
میکند.
افزوده
شده در نسخه
205.
emergency, rd.emergency, -b
بوت در
حالت
اضطراری (emergency mode).
این به
ترتیب
معادل
systemd.unit=emergency.target
یا
rd.systemd.unit=emergency.target
است، و به
دلایل
سازگاری و
تایپ
آسانتر
ارائه شده
است.
افزوده
شده در نسخه
186.
rescue, rd.rescue, single, s,
S, 1
بوت در
حالت نجات (rescue
mode). این به
ترتیب
معادل
systemd.unit=rescue.target
یا
rd.systemd.unit=rescue.target
است، و به
دلایل
سازگاری و
تایپ
آسانتر
ارائه شده
است.
افزوده
شده در نسخه
186.
2, 3, 4, 5
بوت در
سطح اجرای
سنتی
مشخصشده SysV.
گزینههای
2،
3 و
4
معادل
systemd.unit=multi-user.target؛ و
گزینه
5
معادل
systemd.unit=graphical.target
هستند، و به
دلایل
سازگاری و
تایپ
آسانتر
ارائه
شدهاند.
افزوده
شده در نسخه
186.
locale.LANG=, locale.LANGUAGE=,
locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=,
locale.LC_COLLATE=, locale.LC_MONETARY=,
locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=,
locale.LC_ADDRESS=, locale.LC_TELEPHONE=,
locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=
تنظیم
محلیسازی
(locale) سیستم
برای
استفاده.
این
تنظیمات
پیکربندیهای
موجود در /etc/locale.conf
را
بازنویسی
میکند.
برای
اطلاعات
بیشتر
locale.conf(5) و
locale(7) را
ببینید.
افزوده
شده در نسخه
186.
برای سایر
پارامترهای
خط فرمان
هسته که
توسط
مؤلفههای
سیستمعامل
پایه درک
میشوند،
لطفاً به
kernel-command-line(7)
مراجعه
کنید.
در طول
مقداردهی
اولیه،
مدیر سرویس
اعتبارنامهها
را از منابع
گوناگون
وارد
مجموعه
اعتبارنامههای
سیستم
میکند، که
سپس
میتوانند
به
سرویسها
منتقل شده و
توسط
مولدها
مصرف شوند:
•هنگامی
که مدیر
سرویس برای
اولین بار
مقداردهی
اولیه
میشود،
اعتبارنامههای
سیستم را از
رشتههای
سازنده SMBIOS
نوع 11 با
نامهای
io.systemd.credential:name=value
و
io.systemd.credential.binary:name=value
میخواند.
•در همان
زمان
اعتبارنامهها
را از "fw_cfg"
مربوط به QEMU
وارد
میکند.
(توجه داشته
باشید که
سازوکار SMBIOS
معمولاً
ترجیح داده
میشود،
زیرا
سریعتر و
عمومی است).
•اعتبارنامهها
ممکن است از
طریق خط
فرمان هسته
با استفاده
از پارامتر
systemd.set-credential= ارسال
شوند؛ بالا
را ببینید.
•هنگامی
که مدیر
سرویس در
طول انتقال
initrd → host
فراخوانی
میشود،
تمام
فایلهای
موجود در
/run/credentials/@initrd/ را به
عنوان
اعتبارنامههای
سیستم وارد
میکند.
دستور systemd-creds(1)
را به صورت
زیر
فراخوانی
کنید تا
فهرست
اعتبارنامههای
ارسالی به
سیستم را
مشاهده
نمایید:
# systemd-creds --system list
برای
اطلاعات
بیشتر
مستندات
اعتبارنامههای
سیستم و
سرویس[8] را
ببینید.
مدیر
سرویس
هنگامی که
به عنوان PID 1
اجرا
میشود،
اعتبارنامههای
سیستم زیر
را مصرف
میکند:
vmm.notify_socket
شامل یک
نشانی
AF_VSOCK یا
AF_UNIX است که در
آن هنگام
تکمیل
راهاندازی
مدیر
سرویس، یک
پیام اعلان
READY=1 ارسال
میشود.
برای
اطلاعات
بیشتر
sd_notify(3) و
بخش بعدی را
ببینید.
توجه داشته
باشید در
صورتی که
هایپروایزر
از
SOCK_DGRAM روی
AF_VSOCK
پشتیبانی
نکند، به
جای آن
SOCK_SEQPACKET
امتحان
خواهد شد.
بار داده (payload)
اعتبارنامه
برای
AF_VSOCK
باید یک
رشته به شکل
"
vsock:CID:PORT" باشد.
مقادیر
"vsock-stream"، "vsock-dgram" و
"vsock-seqpacket"
میتوانند
به جای "vsock"
استفاده
شوند تا
استفاده از
نوع سوکت
متناظر را
تحمیل کنند.
این
قابلیت
برای
مدیران
ماشین یا
سایر
فرآیندهای
روی میزبان
مفید است تا
از طریق VSOCK
اعلانی
دریافت
کنند مبنی
بر اینکه
ماشین
مجازی
راهاندازی
خود را به
پایان
رسانده
است.
افزوده
شده در نسخه
254.
system.machine_id
یک شناسه
هگزادسیمال
۱۲۸ بیتی را
برای
مقداردهی
اولیه /etc/machine-id در
صورتی که
فایل هنوز
تنظیم نشده
باشد
میپذیرد.
برای
جزئیات
machine-id(5)
را ببینید.
افزوده
شده در نسخه
254.
برای
فهرستی از
اعتبارنامههای
سیستم که
مؤلفههای
گوناگون
دیگر systemd مصرف
میکنند،
به systemd.system-credentials(7)
مراجعه
کنید.
مدیر
سرویس یک
پروتکل
اعلان
آمادگی را
هم بین مدیر
و
سرویسهای
آن (یعنی در
جهت پایین
پشته) و هم
بین مدیر و
یک ناظر
احتمالی در
سطوح
بالاتر
پشته (که
دومی
میتواند
یک مدیر
ماشین یا
کانتینر،
یا در مورد
مدیر سرویس
به ازای هر
کاربر
نمونه مدیر
سرویس
سیستم باشد)
پیادهسازی
میکند.
پروتکل
پایه (و واسط
برنامهنویسی
پیشنهادی
برای آن) در
sd_notify(3) شرح
داده شده
است.
سوکت
اعلانی که
مدیر سرویس
(از جمله PID 1)
برای گزارش
آمادگی به
ناظر خود
استفاده
میکند از
طریق متغیر
محیطی
معمول $NOTIFY_SOCKET
تنظیم
میشود
(بالا را
ببینید). از
آنجا که این
متغیر
مستقیماً
تنها برای
مدیران
کانتینر و
برای نمونه
به ازای هر
کاربر از
مدیر سرویس
قابل تنظیم
است، یک
سازوکار
اضافی برای
پیکربندی
این مورد به
ویژه برای
استفاده در
محیطهای
ماشین
مجازی در
دسترس است:
اعتبارنامه
سیستم vmm.notify_socket
(بالا را
ببینید)
ممکن است
روی یک سوکت
مناسب
(معمولاً یک
سوکت AF_VSOCK) از
طریق
رشتههای
سازنده SMBIOS
نوع 11 تنظیم
شود. برای
جزئیات
بالا را
ببینید.
پروتکل
اعلان از
مدیر سرویس
به سمت بالا
در پشته به
سمت یک
ناظر، از
تعدادی
فیلد
افزونه
پشتیبانی
میکند که
به ناظر
اجازه
میدهد از
ویژگیهای
خاص سیستم
مطلع شده و
پیشرفت
راهاندازی
آن را
ردگیری کند.
بهطور
مشخص
فیلدهای
زیر ارسال
میشوند:
•یک پیام
X_SYSTEMD_HOSTNAME=... به محض
اینکه نام
اولیه
میزبان
برای سیستم
تعیین شود
ارسال
خواهد شد.
توجه داشته
باشید که در
طول اجرای
بعدی ممکن
است نام
میزبان
مجدداً به
صورت
برنامهنویسیشده
تغییر کند،
و (در حال
حاضر) در آن
حالت
اعلانهای
بیشتری
ارسال
نمیشود.
افزوده
شده در نسخه
256.
•یک پیام
X_SYSTEMD_MACHINE_ID=... به محض
تعیین
شناسه
ماشین
سیستم
ارسال
خواهد شد.
برای
جزئیات
machine-id(5)
را ببینید.
افزوده
شده در نسخه
256.
•یک پیام
X_SYSTEMD_SIGNALS_LEVEL=... به محض
اینکه مدیر
سرویس
گردانندههای
سیگنالهای
گوناگون
فرآیند
یونیکس را
که در بالا
شرح داده شد
نصب کند
ارسال
خواهد شد.
مقدار این
فیلد یک عدد
صحیح بدون
علامت در
قالب رشته
دهدهی است
و سطح ویژگی
سیگنالهای
فرآیند
یونیکس
پشتیبانیشده
توسط مدیر
سرویس را
نشان
میدهد. در
حال حاضر
تنها یک سطح
ویژگی
منفرد
تعریف شده
است:
•مقدار
X_SYSTEMD_SIGNALS_LEVEL=2
سیگنالهای
فرآیند
گوناگون
یونیکس
مستندشده
در بالا را
پوشش
میدهد – که
زیرمجموعه
گستردهتری
از
سیگنالهای
پشتیبانیشده
توسط سیستم
تاریخی SysV init
هستند.
سیگنالهای
ارسالشده
به PID 1 قبل از
ارسال این
پیام ممکن
است هنوز
بهدرستی
مدیریت
نشوند.
مصرفکننده
این
پیامها
باید مقدار
را به عنوان
یک عدد صحیح
بدون علامت
که
نشاندهنده
سطح
پشتیبانی
است تجزیه
کند. در حال
حاضر تنها
سطح 2 ذکرشده
تعریف شده
است، اما
بعداً ممکن
است سطوح
اضافی با
اعداد صحیح
بالاتر
تعریف شوند
که
رفتارهای
گستردهتری
از رفتار
تعریفشده
فعلی را
پیادهسازی
خواهند
کرد.
افزوده
شده در نسخه
256.
•پیامهای
X_SYSTEMD_UNIT_ACTIVE=... و
X_SYSTEMD_UNIT_INACTIVE=...
برای هر
واحد هدف با
فعال شدن یا
متوقف شدن
فعالیت آن
ارسال
خواهند شد.
این برای
ردگیری
پیشرفت و
قابلیتهای
راهاندازی
مفید است. به
عنوان
مثال، به
محض اینکه
گزارش شود
واحد ssh-access.target
شروع به کار
کرده است،
دسترسی SSH
معمولاً در
دسترس
خواهد بود؛
برای
جزئیات
systemd.special(7)
را ببینید.
افزوده
شده در نسخه
256.
•یک پیام
X_SYSTEMD_SHUTDOWN=... مدت
کوتاهی قبل
از خاموش
شدن سیستم
ارسال
خواهد شد.
مقدار آن
یکی از
رشتههای
"reboot"، "halt"، "poweroff"
یا "kexec" است و
نشان
میدهد که
چه نوع
خاموششدنی
در حال اجرا
است.
افزوده
شده در نسخه
256.
•یک پیام
X_SYSTEMD_REBOOT_PARAMETER=... نیز
مدت کوتاهی
قبل از
خاموش شدن
سیستم
ارسال
خواهد شد.
مقدار آن
آرگومان
راهاندازی
مجدد است که
با
systemctl --reboot-argument=...
پیکربندی
شده است.
افزوده
شده در نسخه
256.
توجه
داشته
باشید که
این
فیلدهای
افزونه
علاوه بر
اعلانهای
معمول "READY=1" و
"RELOADING=1" ارسال
میشوند.
systemd تنها به
ندرت
مستقیماً
فراخوانی
میشود،
زیرا در
اوایل
راهاندازی
سیستم شروع
به کار کرده
و در زمانی
که کاربران
ممکن است با
آن تعامل
داشته
باشند در
حال اجرا
است.
معمولاً از
ابزارهایی
مانند systemctl(1)
برای ارسال
دستورات به
مدیر
استفاده
میشود. از
آنجا که systemd
معمولاً
مستقیماً
فراخوانی
نمیشود،
گزینههای
فهرستشده
در زیر
بیشتر برای
اشکالزدایی
و مقاصد
ویژه مفید
هستند.
این
گزینهها
برای
آزمایش و
دروننگری
استفاده
میشوند، و
systemd ممکن است
در هر زمانی
با آنها
فراخوانی
شود:
--dump-configuration-items
تخلیه
موارد
پیکربندی
شناختهشده
واحد. این
گزینه یک
فهرست
مختصر اما
کامل از
موارد
پیکربندی
قابل فهم در
فایلهای
تعریف واحد
را خروجی
میدهد.
--dump-bus-properties
تخلیه
ویژگیهای
ارائهشده
روی گذرگاه.
این گزینه
یک فهرست
مختصر اما
کامل از
ویژگیهای
ارائهشده
روی D-Bus را
خروجی
میدهد.
افزوده
شده در نسخه
239.
--test
تعیین
تراکنش
راهاندازی
اولیه (یعنی
فهرست
کارهای در
صف
قرارگرفته
در زمان
راهاندازی)،
تخلیه آن و
خروج — بدون
اجرای
واقعی
هیچیک از
کارهای
تعیینشده.
این گزینه
تنها برای
اشکالزدایی
مفید است.
توجه داشته
باشید که در
طول
راهاندازی
عادی مدیر
سرویس ممکن
است
واحدهای
اضافی که
توسط این
عملیات
نمایش داده
نشدهاند
شروع شوند،
زیرا
فعالسازیهای
سختافزاری،
سوکت،
گذرگاه یا
سایر انواع
ممکن است با
اجرای
تراکنش
کارهای
اضافی
اضافه کنند.
از --system برای
درخواست
تراکنش
اولیه مدیر
سرویس
سیستم
استفاده
کنید (این
حالت
پیشفرض
ضمنی نیز
هست)، و با --user
ترکیب کنید
تا به جای آن
تراکنش
اولیه مدیر
سرویس به
ازای هر
کاربر
درخواست
شود.
--system, --user
هنگامی
که همراه با
--test استفاده
شود،
انتخاب
میکند که
تراکنش
اولیه برای
نمونه
سیستم
محاسبه شود
یا برای
نمونه به
ازای هر
کاربر. این
گزینهها
در صورت
فراخوانی
بدون --test هیچ
تاثیری
ندارند،
زیرا در طول
فراخوانیهای
معمولی
(یعنی غیر از
--test) مدیر
سرویس با
بررسی
اینکه آیا PID
اجرایی آن ۱
است یا خیر،
بهطور
خودکار
تشخیص
میدهد که
باید در
حالت سیستم
کار کند یا
کاربر. توجه
داشته
باشید که
راهاندازی
و نگهداری
سیستمی که
مدیر سرویس
در حالت --system
اما با PID غیر
از ۱ اجرا
شود
پشتیبانی
نمیشود.
-h, --help
یک متن
راهنمای
کوتاه چاپ
کرده و خارج
میشود.
--version
یک رشته
نسخه کوتاه
چاپ کرده و
خارج
میشود.
این
گزینهها
مستقیماً
با
گزینههای
فهرستشده
در بالا در
بخش «خط
فرمان
هسته»
مطابقت
دارند. هر دو
فرم ممکن
است بهطور
معادل برای
مدیر سیستم
استفاده
شوند، اما
توصیه
میشود در
این زمینه
از فرمهای
فهرستشده
در بالا
استفاده
شود، زیرا
آنها
بهدرستی
دارای فضای
نام (namespaced)
هستند.
هنگامی که
یک گزینه هم
در خط فرمان
هسته و هم به
عنوان یک
آرگومان خط
فرمان
معمولی
مشخص شود،
دومی
اولویت
بالاتری
دارد.
هنگامی که
systemd به عنوان
مدیر کاربر
استفاده
میشود، خط
فرمان هسته
نادیده
گرفته شده و
تنها
گزینههای
شرحدادهشده
در زیر درک
میشوند. با
این وجود،
systemd معمولاً
در این حالت
از طریق
سرویس user@.service(5)
آغاز
میشود که
بین همه
کاربران
مشترک است.
ممکن است
استفاده از
فایلهای
پیکربندی
برای اصلاح
تنظیمات
(ببینید
systemd-user.conf(5))، یا
متغیرهای
محیطی
راحتتر
باشد. برای
بررسی نحوه
تنظیم بلوک
محیط، بخش
«متغیرهای
محیطی» در
بالا را
ببینید.
--unit=
واحد
پیشفرض را
برای
فعالسازی
در زمان
راهاندازی
تنظیم
میکند. در
صورت عدم
تعیین،
پیشفرض
روی default.target قرار
میگیرد.
گزینه systemd.unit= در
بالا را
ببینید.
--dump-core
تخلیه
حافظه (core dump) را
هنگام کرش
فعال
میکند. این
سوییچ در
هنگام اجرا
به عنوان
نمونه
کاربر هیچ
تأثیری
ندارد.
مشابه با
systemd.dump_core= در بالا
است.
--crash-vt=VT
هنگام
کرش به یک
کنسول
مجازی (VT) مشخص
تغییر
وضعیت
میدهد. این
سوییچ
هنگام اجرا
به عنوان
نمونه
کاربر هیچ
تأثیری
ندارد.
مشابه با
systemd.crash_chvt= در بالا
است (اما به
املای
متفاوت آن
توجه کنید!).
افزوده
شده در نسخه
227.
--crash-shell
در هنگام
کرش یک
پوسته را
اجرا
میکند. این
سوییچ
هنگام اجرا
به عنوان
نمونه
کاربر هیچ
تأثیری
ندارد.
گزینه systemd.crash_shell=
در بالا را
ببینید.
--crash-action=
مشخص
میکند که
هنگام کرش
مدیر سیستم (PID
1) چه اقدامی
انجام شود.
این سوییچ
هنگامی که
systemd به عنوان
نمونه
کاربر اجرا
میشود هیچ
تأثیری
ندارد.
گزینه
systemd.crash_action=
در بالا را
ببینید.
افزوده
شده در نسخه
256.
--confirm-spawn
هنگام
ایجاد
فرآیندها
درخواست
تأیید
میکند. این
سوییچ
هنگام اجرا
به عنوان
نمونه
کاربر هیچ
تأثیری
ندارد.
گزینه systemd.confirm_spawn
در بالا را
ببینید.
--show-status
اطلاعات
خلاصه
وضعیت واحد
را در طول
راهاندازی
و خاموش شدن
روی کنسول
نمایش
میدهد.
گزینه
systemd.show_status
در بالا را
ببینید.
افزوده
شده در نسخه
244.
--log-color
پیامهای
لاگ مهم را
برجسته
میکند.
گزینه
systemd.log_color
در بالا را
ببینید.
افزوده
شده در نسخه
244.
--log-level=
سطح لاگ
را تنظیم
میکند.
گزینه systemd.log_level
در بالا را
ببینید.
--log-location
مکان کد
را در
پیامهای
لاگ لحاظ
میکند.
گزینه
systemd.log_location
در بالا را
ببینید.
افزوده
شده در نسخه
244.
--log-target=
مقصد لاگ
را تنظیم
میکند.
گزینه systemd.log_target
در بالا را
ببینید.
--log-time=
پیامهای
کنسول را با
برچسب
زمانی
پیشوندگذاری
میکند.
گزینه
systemd.log_time
در بالا را
ببینید.
افزوده
شده در نسخه
246.
--machine-id=
شناسه
یکتای machine-id
تنظیمشده
روی هارد
دیسک را
بازنویسی
میکند.
گزینه
systemd.machine_id=
در بالا را
ببینید.
افزوده
شده در نسخه
229.
--service-watchdogs
تمام
مهلتهای
زمانی
زمانسنج
نگهبان
سرویس و
اقدامات
اضطراری را
بهطور
سراسری
فعال/غیرفعال
میکند.
گزینه
systemd.service_watchdogs
در بالا را
ببینید.
افزوده
شده در نسخه
237.
--default-standard-output=,
--default-standard-error=
خروجی
پیشفرض یا
خروجی خطای
پیشفرض را
به ترتیب
برای همه
سرویسها و
سوکتها
تنظیم
میکند.
گزینههای
systemd.default_standard_output= و
systemd.default_standard_error= در
بالا را
ببینید.
هنگامی که
systemd شروع به
کار کرده یا
مجدداً
راهاندازی
میشود،
ممکن است
ساعت سیستم
را روی
«مبدأ» (epoch)
تنظیم کند.
این
سازوکار
برای
اطمینان از
این است که
ساعت سیستم
تا حدودی
بهطور
منطقی
مقداردهی
اولیه شده و
در طول
راهاندازیهای
مجدد
تقریباً
یکنواخت (monotonic)
باقی
بماند، در
صورتی که
ساعت
بلادرنگ (RTC)
محلی مجهز
به باتری در
دسترس
نباشد یا
بهدرستی
کار نکند.
مبدأ
کمترین
تاریخی است
که فرض
میشود
زمان ساعت
سیستم
بالاتر از
آن
بهدرستی
تنظیم شده
است. هنگام
مقداردهی
اولیه، اگر
ساعت محلی
روی مقدار
کمتری
تنظیم شده
باشد، به
مبدأ جلو
برده
میشود. به
عنوان یک
حالت خاص،
اگر ساعت
محلی به
اندازه
کافی در
آینده باشد
(بهطور
پیشفرض ۱۵
سال، اما
این مقدار
را میتوان
در زمان
ساخت
پیکربندی
کرد)، ساعت
سختافزاری
خراب فرض
میشود و
ساعت سیستم
به مبدأ به
عقب
بازگردانده
میشود.
مبدأ روی
بالاترین
مورد از
میان این
موارد
تنظیم
میشود:
زمان ساخت
systemd، زمان
تغییر ("mtime")
فایل /usr/lib/clock-epoch و
زمان تغییر
فایل /var/lib/systemd/timesync/clock.
/run/systemd/notify
سوکت
اعلان
وضعیت دیمن.
این یک سوکت
دیتاگرام
AF_UNIX است و
برای
پیادهسازی
منطق اعلان
دیمن
همانطور
که توسط
sd_notify(3)
پیادهسازی
شده
استفاده
میشود.
/run/systemd/private
به عنوان
کانال
ارتباطی
داخلی بین
systemctl(1) و فرآیند
systemd استفاده
میشود. این
یک سوکت
جریانی (stream)
AF_UNIX
است. این
رابط خصوصی
systemd است و
نباید در
پروژههای
خارجی
استفاده
شود.
/dev/initctl
پشتیبانی
سازگاری
محدود برای
رابط
کلاینت SysV،
همانطور
که توسط
واحد systemd-initctl.service
پیادهسازی
شده است. این
یک لوله
نامگذاریشده
(named pipe) در سیستم
فایل است.
این رابط
منسوخ شده
است و نباید
در
برنامههای
جدید
استفاده
شود.
/usr/lib/clock-epoch
زمان
تغییر ("mtime")
این فایل
برای مبدأ
زمانی (epoch)
استفاده
میشود؛
بخش قبلی را
ببینید.
افزوده
شده در نسخه
247.
/var/lib/systemd/timesync/clock
زمان
تغییر ("mtime")
این فایل
توسط
systemd-timesyncd.service(8)
بهروزرسانی
میشود. در
صورت وجود،
زمان تغییر
این فایل
برای مبدأ
استفاده
میشود؛
بخش قبلی را
ببینید.
افزوده
شده در نسخه
257.
systemd 252
آرگومانهای
خط فرمان
هسته
systemd.unified_cgroup_hierarchy
و
systemd.legacy_systemd_cgroup_controller
منسوخ شدند.
لطفاً به
سلسلهمراتب
یکپارچه cgroup
سوئیچ کنید.
افزوده
شده در نسخه
252.
- 1.
- تعهد
سازگاری و
پایداری
رابط (Interface Portability and Stability
Promise)
- 2.
- رابط
کانتینر (Container
Interface)
- 3.
- رابط initrd (initrd Interface)
- 4.
- گروههای
کنترل نسخه
۲ (Control Groups v2)
- 5.
- مشخصات
شاخه پایه XDG (XDG
Base Directory specification)
- 6.
- توصیه
میشود که
سایر
ابزارها $SUDO_UID
را در صورت
لزوم تنظیم
و بررسی
کنند، و با
آن به عنوان
یک رابط
مشترک
رفتار
نمایند.
- 7.
- متغیرهای
محیطی
شناختهشده
(Known Environment Variables)
- 8.
- اعتبارنامههای
سیستم و
سرویس (System and Service
Credentials)
- 9.
- صفحه اصلی
systemd
- 10.
- سند طراحی
اصلی (Original Design Document)
