systemd، init - مدير النظام والخدمات الخاص بـ systemd
ملخص
/usr/lib/systemd/systemd [الخيارات...]
init [الخيارات...]
الوصف
systemd هو مدير للنظام والخدمات لأنظمة Linux. عند تشغيله كعملية أولى عند بدء التشغيل (باعتباره PID 1)، فإنه يعمل كنظام تهيئة يقوم بتشغيل وصيانة الخدمات في مساحة المستخدم. يتم بدء مثيلات منفصلة للمستخدمين الذين قاموا بتسجيل الدخول لبدء خدماتهم.
عادةً ما لا يتم استدعاء systemd مباشرةً من قبل المستخدم، ولكنه يتم تثبيته كرمز ارتباط /sbin/init ويتم تشغيله أثناء بدء التشغيل المبكر. يتم بدء مثيلات مدير المستخدم تلقائيًا من خلال خدمة [email protected](5).
عند تشغيله كمثيل للنظام، يقوم systemd بتفسير ملف التكوين system.conf والملفات الموجودة في أدلة system.conf.d؛ عند تشغيله كمثيل للمستخدم، يقوم systemd بتفسير ملف التكوين user.conf والملفات الموجودة في أدلة user.conf.d. راجع systemd-system.conf(5) لمزيد من المعلومات.
يحتوي systemd على تطبيقات أصلية لمختلف المهام التي يجب تنفيذها كجزء من عملية بدء التشغيل. على سبيل المثال، يقوم بتعيين اسم المضيف أو تكوين جهاز الشبكة الحلقية.
يقوم systemd أيضًا بإعداد وتركيب العديد من أنظمة ملفات واجهة برمجة التطبيقات، مثل /sys/ و /proc/ و /dev/.
سيقوم systemd أيضًا بإعادة ضبط ساعة النظام أثناء بدء التشغيل المبكر إذا بدا أنها مضبوطة بشكل غير صحيح. انظر قسم "عصر ساعة النظام" أدناه.
لاحظ أنه ليست كل الواجهات التي يوفرها systemd مغطاة بـ "وعد قابلية النقل واستقرار الواجهة"[1].
وصف واجهة برمجة التطبيقات D-Bus الخاصة بـ systemd في org.freedesktop.systemd1(5) و org.freedesktop.LogControl1(5).
يجب على الأنظمة التي تستدعي systemd في بيئة حاوية أو initrd تنفيذ مواصفات "واجهة الحاوية"[2] أو "واجهة initrd"[3] على التوالي.
الوحدات
يوفر systemd نظام اعتماد بين الكيانات المختلفة التي تسمى "الوحدات" ذات 11 نوعًا مختلفًا. تجسد الوحدات الكائنات المختلفة ذات الصلة ببدء تشغيل النظام وصيانته. يتم تكوين غالبية الوحدات في ملفات تكوين الوحدة، والتي يصف بناء جملتها ومجموعة الخيارات الأساسية الخاصة بها systemd.unit(5)، ومع ذلك يتم إنشاؤها تلقائيًا من ملفات تكوين أخرى، أو ديناميكيًا من حالة النظام أو برمجيًا في وقت التشغيل. يمكن أن تكون الوحدات في عدد من الحالات، كما هو موضح في الجدول التالي. لاحظ أن أنواع الوحدات المختلفة قد يكون لها عدد من الحالات الفرعية الإضافية، والتي يتم تعيينها إلى الحالات العامة للوحدة الموصوفة هنا.
الجدول 1. حالات ACTIVE للوحدة
┌──────────────┬─────────────────────────────────────┐
│ الحالة │ الوصف │
├──────────────┼─────────────────────────────────────┤
│ active │ بدأت، تم ربطها، تم توصيلها، ...، │
│ │ اعتمادًا على نوع الوحدة. │
├──────────────┼─────────────────────────────────────┤
│ inactive │ توقفت، تم إلغاء ربطها، تم فصلها، ...، │
│ │ اعتمادًا على نوع الوحدة. │
├──────────────┼─────────────────────────────────────┤
│ failed │ مشابه لـ inactive، ولكن الوحدة فشلت │
│ │ بطريقة ما (أرجعت العملية رمز خطأ عند │
│ │ الخروج، أو تعطلت، أو انتهت العملية بعد │
│ │ عدد كبير جدًا من عمليات إعادة التشغيل). │
├──────────────┼─────────────────────────────────────┤
│ activating │ تتغير من inactive إلى active. │
├──────────────┼─────────────────────────────────────┤
│ deactivating │ تتغير من active إلى inactive. │
├──────────────┼─────────────────────────────────────┤
│ maintenance │ الوحدة غير نشطة وتجري عملية صيانة. │
├──────────────┼─────────────────────────────────────┤
│ reloading │ الوحدة نشطة ويتم إعادة تحميل │
│ │ تكوينها. │
├──────────────┼─────────────────────────────────────┤
│ refreshing │ الوحدة نشطة ويتم تنشيط تثبيت جديد في │
│ │ مساحة الاسم الخاصة بها. │
└──────────────┴─────────────────────────────────────┘
تتوفر أنواع الوحدات التالية:
وحدات الخدمة، والتي تبدأ وتتحكم في العمليات الخلفية والعمليات التي تتكون منها. للحصول على التفاصيل، راجع systemd.service(5).
وحدات المقبس، والتي تغلف المقابس المحلية للاتصال بين العمليات أو مقابس الشبكة في النظام، وهي مفيدة للتنشيط المستند إلى المقبس. للحصول على تفاصيل حول وحدات المقبس، راجع systemd.socket(5)، وللحصول على تفاصيل حول التنشيط المستند إلى المقبس وأشكال التنشيط الأخرى، راجع daemon(7).
وحدات الهدف مفيدة لتجميع الوحدات أو توفير نقاط مزامنة معروفة أثناء الإقلاع، انظر systemd.target(5).
تعرض وحدات الجهاز أجهزة kernel في systemd ويمكن استخدامها لتنفيذ التنشيط القائم على الجهاز. للحصول على التفاصيل، انظر systemd.device(5).
تتحكم وحدات التركيب في نقاط التركيب في نظام الملفات، لمزيد من التفاصيل انظر systemd.mount(5).
توفر وحدات التركيب التلقائي إمكانات التركيب التلقائي، للتركيب حسب الطلب لأنظمة الملفات بالإضافة إلى الإقلاع المتوازي. انظر systemd.automount(5).
وحدات المؤقت مفيدة لتشغيل تنشيط وحدات أخرى بناءً على المؤقتات. يمكنك العثور على التفاصيل في systemd.timer(5).
تتشابه وحدات التبديل بشكل كبير مع وحدات التركيب وتغلف أقسام ذاكرة التبديل أو ملفات نظام التشغيل. يتم وصفها في systemd.swap(5).
يمكن استخدام وحدات المسار لتنشيط خدمات أخرى عند تغيير كائنات نظام الملفات أو تعديلها. انظر systemd.path(5).
يمكن استخدام وحدات الشريحة لتجميع الوحدات التي تدير عمليات النظام (مثل وحدات الخدمة والنطاق) في شجرة هرمية لأغراض إدارة الموارد. انظر systemd.slice(5).
تتشابه وحدات النطاق مع وحدات الخدمة، ولكنها تدير العمليات الخارجية بدلاً من تشغيلها. انظر systemd.scope(5).
يتم تسمية الوحدات باسم ملفات التكوين الخاصة بها. بعض الوحدات لها دلالات خاصة. تتوفر قائمة مفصلة في systemd.special(7).
تعرف systemd أنواعًا مختلفة من التبعيات، بما في ذلك تبعيات المتطلبات الإيجابية والسلبية (أي Requires= و Conflicts=) بالإضافة إلى تبعيات الترتيب (After= و Before=). ملاحظة: تبعيات الترتيب والمتطلبات متعامدة. إذا كانت هناك تبعية متطلبات فقط بين وحدتين (على سبيل المثال، foo.service تتطلب bar.service)، ولكن لا توجد تبعية ترتيب (على سبيل المثال، foo.service بعد bar.service) وكلاهما طلب بدء التشغيل، فسيتم تشغيلهما بالتوازي. من الشائع أن يتم وضع كل من تبعيات المتطلبات والترتيب بين وحدتين. لاحظ أيضًا أن غالبية التبعيات يتم إنشاؤها والحفاظ عليها ضمنيًا بواسطة systemd. في معظم الحالات، يجب ألا يكون من الضروري الإعلان عن تبعيات إضافية يدويًا، ومع ذلك، من الممكن القيام بذلك.
يمكن للبرامج والتطبيقات (عبر التبعيات) طلب تغييرات الحالة للوحدات. في systemd، يتم تغليف هذه الطلبات كـ "مهام" ويتم الاحتفاظ بها في قائمة انتظار المهام. يمكن أن تنجح المهام أو تفشل، ويتم ترتيب تنفيذها بناءً على تبعيات الترتيب للوحدات التي تم جدولتها.
عند الإقلاع، يقوم systemd بتنشيط وحدة الهدف الافتراضية default.target، والتي تهدف إلى تنشيط الخدمات عند الإقلاع ووحدات أخرى عند الإقلاع عن طريق سحبها عبر التبعيات. عادةً ما تكون اسم الوحدة مجرد اسم مستعار (رابط رمزي) إما لـ graphical.target (للإقلاع الكامل الميزات إلى واجهة المستخدم) أو multi-user.target (للإقلاع ذي وحدة تحكم محدودة فقط للاستخدام في البيئات المضمنة أو الخادم، أو ما شابه ذلك؛ وهي مجموعة فرعية من graphical.target). ومع ذلك، الأمر متروك للمسؤول لتكوينه كاسم مستعار لوحدة هدف أخرى. انظر systemd.special(7) للحصول على تفاصيل حول وحدات الهدف هذه.
عند التشغيل الأول، سيقوم systemd بتمكين أو تعطيل الوحدات وفقًا للسياسة المحددة مسبقًا. راجع systemd.preset(5) و "دلالات التشغيل الأول" في machine-id(5).
يحتفظ systemd بمجموعة صغيرة فقط من الوحدات المحملة في الذاكرة. على وجه التحديد، الوحدات التي يتم الاحتفاظ بها في الذاكرة هي تلك التي ينطبق عليها واحد على الأقل من الشروط التالية:
تكون في حالة نشطة أو قيد التنشيط أو إيقاف التنشيط أو فشل (أي في أي حالة وحدة باستثناء
"غير نشطة")
يوجد لديها مهمة معلقة
هي تبعية لوحدة أخرى واحدة على الأقل موجودة في الذاكرة
يوجد لديها نوع من الموارد لا يزال مخصصًا (مثل وحدة الخدمة التي تكون غير نشطة ولكن لا يزال لديها عملية معلقة تجاهلت الطلب بالإنهاء)
تم تثبيتها في الذاكرة برمجيًا عن طريق مكالمة D-Bus
سيقوم systemd تلقائيًا وبشكل ضمني بتحميل الوحدات من القرص - إذا لم يتم تحميلها بعد - بمجرد طلب العمليات عليها. وبالتالي، في كثير من النواحي، فإن حقيقة ما إذا كانت الوحدة محملة أم لا تكون غير مرئية للعملاء. استخدم systemctl list-units --all لسرد جميع الوحدات المحملة حاليًا. أي وحدة لا ينطبق عليها أي من الشروط المذكورة أعلاه يتم تفريغها على الفور من الذاكرة. لاحظ أنه عند تفريغ وحدة من الذاكرة، يتم أيضًا مسح بيانات المحاسبة الخاصة بها. ومع ذلك، لا يتم فقدان هذه البيانات بشكل عام، حيث يتم إنشاء سجل سجل يعلن عن الموارد المستهلكة في كل مرة يتم فيها إيقاف وحدة.
تتم وضع العمليات التي يطلقها systemd في مجموعات تحكم Linux فردية، والتي تحمل اسم الوحدة التي تنتمي إليها، في التسلسل الهرمي الخاص بـ systemd. (راجع Control Groups v2[4] لمزيد من المعلومات حول مجموعات التحكم، أو "cgroups" باختصار). يستخدم systemd هذا لتتبع العمليات بشكل فعال. يتم الاحتفاظ بمعلومات مجموعة التحكم في النواة، ويمكن الوصول إليها عبر التسلسل الهرمي لنظام الملفات (أسفل /sys/fs/cgroup/)، أو في أدوات مثل systemd-cgls(1) أو [ps]({filename}../../ps)(1) (ps xawf -eo pid,user,cgroup,args مفيد بشكل خاص لسرد جميع العمليات ووحدات systemd التي تنتمي إليها).
يتوافق systemd مع وظائف Unix المختلفة، مثل /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]({filename}../../systemctl)(1). توجد القائمة الكاملة من الدلائل في systemd.unit(5).
دليل وحدات المستخدم
تنطبق قواعد مماثلة على أدلة وحدات المستخدم. ومع ذلك، هنا يتم اتباع مواصفات XDG Base Directory[5] للعثور على الوحدات. يجب على التطبيقات وضع ملفات وحدتها في الدليل الذي يتم إرجاعه بواسطة pkg-config systemd --variable=systemduserunitdir. يتم إجراء التكوين العام في الدليل الذي يتم الإبلاغ عنه بواسطة pkg-config systemd --variable=systemduserconfdir. يمكن لأوامري enable وdisable الخاصة بأداة [systemctl]({filename}../../systemctl)(1) معالجة كل من التمكين/التعطيل العام (أي لجميع المستخدمين) والخاص (لمستخدم واحد) للوحدات. توجد القائمة الكاملة من الدلائل في systemd.unit(5).
الإشارات
تستمع الخدمة إلى إشارات عمليات UNIX المختلفة التي يمكن استخدامها لطلب إجراءات مختلفة بشكل غير متزامن. يتم تمكين معالجة الإشارات في وقت مبكر جدًا أثناء بدء التشغيل، قبل استدعاء أي عمليات أخرى. ومع ذلك، يجب على مدير الحاويات المشرف أو ما شابه ذلك الذي يهدف إلى طلب هذه العمليات عبر هذه الآلية أن يأخذ في الاعتبار أن هذه الوظيفة غير متاحة أثناء المرحلة الأولية من التهيئة. يتم إرسال رسالة إشعار 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. إذا تم استقبال هذه الإشارة أكثر من 7 مرات في غضون ثانيتين، فسيتم تشغيل إعادة تشغيل فورية. لاحظ أن الضغط على Ctrl+Alt+Del على وحدة التحكم سيؤدي إلى إرسال هذه الإشارة. لذلك، إذا كان هناك تعليق في عملية إعادة التشغيل، فإن الضغط على Ctrl+Alt+Del أكثر من 7 مرات في غضون ثانيتين هو طريقة آمنة نسبيًا لتشغيل إعادة تشغيل فورية.
يعامل مدراء المستخدم 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.target. هذا يكافئ إلى حد كبير الأمر systemctl isolate rescue.target.
SIGRTMIN+2
يدخل في وضع الطوارئ، ويبدأ وحدة emergency.service. هذا يكافئ إلى حد كبير الأمر systemctl isolate emergency.service.
SIGRTMIN+3
يقوم بإيقاف تشغيل الجهاز، ويبدأ وحدة halt.target. هذا يكافئ إلى حد كبير الأمر systemctl start halt.target --job-mode=replace-irreversibly.
SIGRTMIN+4
يقوم بإيقاف تشغيل الجهاز، ويبدأ وحدة poweroff.target. هذا يكافئ إلى حد كبير الأمر systemctl start poweroff.target --job-mode=replace-irreversibly.
SIGRTMIN+5
يقوم بإعادة تشغيل الجهاز، ويبدأ وحدة 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
يوقف الجهاز فورًا.
SIGRTMIN+14
يقوم بإيقاف تشغيل الجهاز فورًا.
SIGRTMIN+15
يعيد تشغيل الجهاز فورًا.
SIGRTMIN+16
يعيد تشغيل الجهاز فورًا باستخدام `kexec`.
SIGRTMIN+17
يعيد تشغيل مساحة المستخدم فورًا.
تمت إضافته في الإصدار 254.
SIGRTMIN+20
يمكّن عرض رسائل الحالة على وحدة التحكم، كما هو محدد عبر `systemd.show_status=1` في سطر أوامر النواة.
قد ترغب في استخدام `SetShowStatus()` بدلاً من `SIGRTMIN+20` لتجنب حدوث حالات سباق. انظر إلى `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
يستعيد هدف التسجيل إلى قيمته المكوّنة. يتم اشتقاق القيمة المكوّنة من - بالترتيب - القيمة المحددة باستخدام `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=` في مدير النظام على جميع الخدمات بما في ذلك `[email protected]`. يمكن تكوين إدخالات إضافية (كما هو الحال مع أي خدمة أخرى) من خلال إعدادات `Environment=` و `EnvironmentFile=` لـ `[email protected]` (انظر `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
قيمة منطقية. إذا كانت صحيحة، فسيتم تلوين الرسائل المكتوبة إلى الطرفية (tty) وفقًا للأولوية.
يمكن تجاوز هذا باستخدام --log-color=.
$SYSTEMD_LOG_TIME
قيمة منطقية. إذا كانت صحيحة، فسيتم إضافة طابع زمني كبادئة لرسائل التسجيل في وحدة التحكم.
تمت إضافته في الإصدار 246.
$SYSTEMD_LOG_LOCATION
قيمة منطقية. إذا كانت صحيحة، فسيتم إضافة اسم الملف ورقم السطر في التعليمات البرمجية حيث تنشأ الرسالة كبادئة للرسائل.
يمكن تجاوز هذا باستخدام --log-location=.
$SYSTEMD_LOG_TID
قيمة منطقية. إذا كانت صحيحة، فسيتم إضافة معرف الخيط (TID) العددي الحالي كبادئة للرسائل.
تمت إضافته في الإصدار 247.
$SYSTEMD_LOG_TARGET
الوجهة لرسائل التسجيل. أحد الخيارات: console (تسجيل إلى الطرفية المتصلة)، console-prefixed (تسجيل إلى الطرفية المتصلة ولكن مع بادئات ترميز مستوى التسجيل و "facility"، راجع syslog(3))، kmsg (تسجيل إلى المخزن المؤقت لسجلات النواة)، journal (تسجيل إلى السجل)، journal-or-kmsg (تسجيل إلى السجل إذا كان متاحًا، وإلى kmsg بخلاف ذلك)، auto (تحديد هدف التسجيل المناسب تلقائيًا، وهو الإعداد الافتراضي)، null (تعطيل إخراج التسجيل).
يمكن تجاوز هذا باستخدام --log-target=.
$SYSTEMD_LOG_RATELIMIT_KMSG
ما إذا كان سيتم تقييد معدل kmsg أم لا. يأخذ قيمة منطقية. الإعداد الافتراضي هو "true". إذا تم تعطيله، فلن يقوم systemd بتقييد الرسائل المكتوبة إلى kmsg.
تمت إضافته في الإصدار 254.
$XDG_CONFIG_HOME، $XDG_CONFIG_DIRS، $XDG_DATA_HOME، $XDG_DATA_DIRS
يستخدم مدير مستخدم systemd هذه المتغيرات وفقًا لمواصفات دليل قاعدة XDG[5] للعثور على تكوينه.
$SYSTEMD_UNIT_PATH، $SYSTEMD_GENERATOR_PATH، $SYSTEMD_ENVIRONMENT_GENERATOR_PATH
يتحكم في الأماكن التي يبحث فيها systemd عن ملفات الوحدات والمولدات.
يمكن أن تحتوي هذه المتغيرات على قائمة من المسارات، مفصولة بنقطتين (":"). عند تعيينها، إذا انتهت القائمة بمكون فارغ ("...:")، فسيتم إضافة هذه القائمة إلى مجموعة المسارات المعتادة. وإلا، فستستبدل القائمة المحددة مجموعة المسارات المعتادة.
`$SYSTEMD_PAGER`، `$PAGER`
برنامج عرض الصفحات الذي سيتم استخدامه عندما لا يتم تحديد الخيار `--no-pager`. يتم استخدام `$SYSTEMD_PAGER` إذا تم تعيينه؛ وإلا يتم استخدام `$PAGER`. إذا لم يتم تعيين أي من `$SYSTEMD_PAGER` أو `$PAGER`، فسيتم تجربة مجموعة من برامج عرض الصفحات المعروفة بالتتابع، بما في ذلك [less]({filename}../../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]({filename}../../less)(1) لمزيد من المناقشة.
`$SYSTEMD_LESSCHARSET`
تجاوز مجموعة الأحرف التي يتم تمريرها إلى less (افتراضيًا "utf-8"، إذا تم تحديد أن الوحدة الطرفية المستدعاة متوافقة مع UTF-8).
لاحظ أن تعيين متغير البيئة العادي `$LESSCHARSET` ليس له أي تأثير على عمليات استدعاء less بواسطة أدوات systemd.
`$SYSTEMD_PAGERSECURE`
تسمح أوامر برنامج عرض الصفحات الشائعة مثل [less]({filename}../../less)(1)، بالإضافة إلى "عرض الصفحات"، أي التمرير خلال الناتج، بفتح أو كتابة ملفات أخرى وتشغيل أوامر shell عشوائية.
عند استدعاء الأوامر بامتيازات مرتفعة، على سبيل المثال تحت [sudo]({filename}../../sudo)(8) أو pkexec(1)، يصبح برنامج عرض الصفحات بمثابة حدود أمان. يجب توخي الحذر بحيث يتم استخدام البرامج ذات الوظائف المحدودة فقط كبرامج عرض صفحات، ويجب عدم السماح بالميزات التفاعلية غير المقصودة مثل فتح أو إنشاء ملفات جديدة أو بدء العمليات الفرعية. يمكن تمكين "الوضع الآمن" لبرنامج عرض الصفحات كما هو موضح أدناه، إذا كان برنامج عرض الصفحات يدعم ذلك (معظم برامج عرض الصفحات ليست مكتوبة بطريقة تأخذ ذلك في الاعتبار). يوصى إما بتمكين "الوضع الآمن" بشكل صريح أو بتعطيل برنامج عرض الصفحات تمامًا باستخدام `--no-pager` أو `PAGER=cat` عند السماح للمستخدمين غير الموثوق بهم بتنفيذ أوامر بامتيازات مرتفعة.
يأخذ هذا الخيار وسيطًا منطقيًا. عند تعيينه على true، يتم تمكين "الوضع الآمن" للبرنامج لعرض النصوص. في "الوضع الآمن"، سيتم تعيين LESSSECURE=1 عند استدعاء البرنامج لعرض النصوص، مما يوجه البرنامج لتعطيل الأوامر التي تفتح أو تنشئ ملفات جديدة أو تبدأ عمليات فرعية جديدة. حاليًا، يُعرف فقط less(1) بأنه يفهم هذا المتغير وينفذ "الوضع الآمن".
عند تعيينه على false، لا يتم فرض أي قيود على برنامج عرض النصوص. قد يؤدي تعيين SYSTEMD_PAGERSECURE=0 أو عدم إزالته من البيئة الموروثة إلى السماح للمستخدم بتنفيذ أوامر عشوائية.
عندما لا يتم تعيين $SYSTEMD_PAGERSECURE، تحاول أدوات systemd تحديد ما إذا كان يجب تمكين "الوضع الآمن" وما إذا كان برنامج عرض النصوص يدعمه تلقائيًا. يتم تمكين "الوضع الآمن" إذا لم يكن معرف المستخدم الفعال هو نفسه معرف مالك جلسة تسجيل الدخول، راجع geteuid(2) و sd_pid_get_owner_uid(3)، أو عند التشغيل تحت [sudo]({filename}../../sudo)(8) أو أدوات مماثلة (تم تعيين $SUDO_UID [6]). في هذه الحالات، سيتم تعيين SYSTEMD_PAGERSECURE=1 ولن يتم استخدام برامج عرض النصوص التي لا يُعرف أنها تنفذ "الوضع الآمن". لاحظ أن هذا الاكتشاف التلقائي يغطي الآليات الأكثر شيوعًا لرفع الامتيازات وهو مخصص للراحة. يوصى بتعيين $SYSTEMD_PAGERSECURE بشكل صريح أو تعطيل برنامج عرض النصوص.
لاحظ أنه إذا كان من المفترض احترام المتغيرين $SYSTEMD_PAGER أو $PAGER، بخلاف تعطيل برنامج عرض النصوص، فيجب أيضًا تعيين $SYSTEMD_PAGERSECURE.
$SYSTEMD_COLORS
يأخذ هذا المتغير وسيطًا منطقيًا. عند تعيينه على true، ستستخدم systemd والأدوات ذات الصلة الألوان في إخراجها، وإلا فسيكون الإخراج أحادي اللون. بالإضافة إلى ذلك، يمكن أن يأخذ المتغير إحدى القيم الخاصة التالية: "16" أو "256" لتقييد استخدام الألوان إلى مجموعة الألوان الأساسية 16 أو 256 من ANSI، على التوالي. يمكن تحديد ذلك لإلغاء القرار التلقائي بناءً على $TERM وما إذا كانت وحدة التحكم متصلة.
$SYSTEMD_URLIFY
يجب أن تكون القيمة منطقية. يتحكم فيما إذا كان سيتم إنشاء روابط قابلة للنقر في الإخراج لوحدات محاكاة الطرفية التي تدعم ذلك. يمكن تحديد ذلك لإلغاء القرار الذي تتخذه systemd بناءً على $TERM وشروط أخرى.
$LISTEN_PID، $LISTEN_PIDFDID، $LISTEN_FDS، $LISTEN_FDNAMES
يتم تعيينها بواسطة systemd للعمليات الخاضعة للإشراف أثناء تفعيل المقبس. راجع sd_listen_fds(3) للحصول على مزيد من المعلومات.
$NOTIFY_SOCKET
يتم تعيينها بواسطة مدير الخدمة لخدماته لإشعارات الحالة والاستعداد. كما يتم استهلاكها بواسطة مدير الخدمة لإخطار مديري الحاويات أو مديري الخدمات المشرفين في الأعلى بتقدمه. راجع sd_notify(3) والقسم ذي الصلة أدناه للحصول على مزيد من المعلومات.
لمزيد من المتغيرات البيئية التي تفهمها systemd ومكوناتها المختلفة، راجع المتغيرات البيئية المعروفة [7].
سطر أوامر النواة
عند تشغيله كحالة النظام، يقوم systemd بتحليل عدد من الخيارات المذكورة أدناه. يمكن تحديدها كـوسائط سطر أوامر النواة التي يتم تحليلها من مصادر مختلفة اعتمادًا على البيئة التي يتم فيها تنفيذ systemd. إذا تم تشغيله داخل حاوية Linux، يتم تحليل هذه الخيارات من وسائط سطر الأوامر التي يتم تمريرها إلى systemd نفسه، بالإضافة إلى أي من خيارات سطر الأوامر المدرجة في قسم الخيارات أعلاه. إذا تم تشغيله خارج حاويات Linux، يتم تحليل هذه الوسائط من /proc/cmdline بدلاً من ذلك.
المتغيرات التالية مفهومة:
systemd.unit=، rd.systemd.unit=
يقوم بتجاوز الوحدة المراد تنشيطها عند بدء التشغيل. بشكل افتراضي، يكون `default.target`. يمكن استخدامه لتشغيل وحدة مختلفة مؤقتًا عند بدء التشغيل، على سبيل المثال `rescue.target` أو `emergency.service`. راجع `systemd.special(7)` للحصول على تفاصيل حول هذه الوحدات. الخيار الذي يبدأ بـ "rd." يُحتَرم فقط في `initrd`، بينما الخيار الذي لا يبدأ به يُحتَرم فقط في النظام الرئيسي.
systemd.dump_core
يأخذ وسيطة منطقية أو يمكّن الخيار إذا تم تحديده بدون وسيطة. إذا تم تمكينه، فإن مدير `systemd` (PID 1) يقوم بتفريغ الذاكرة الأساسية عند التعطل. وإلا، فلن يتم إنشاء أي تفريغ للذاكرة الأساسية. بشكل افتراضي، يكون ممكّنًا.
تمت إضافته في الإصدار 233.
systemd.crash_chvt
يأخذ عددًا صحيحًا موجبًا، أو وسيطة منطقية. يمكن تحديده أيضًا بدون وسيطة، بنفس تأثير الوسيطة المنطقية الموجبة. إذا تم تحديد عدد صحيح موجب (في النطاق 1-63)، فسيقوم مدير النظام (PID 1) بتنشيط الجهاز الطرفي الافتراضي المحدد عند التعطل. بشكل افتراضي، يكون معطلاً، مما يعني أنه لن يتم إجراء أي تبديل. إذا تم تعيينه على "مُمكّن"، فسيتم استخدام الجهاز الطرفي الافتراضي الذي تتم كتابة رسائل النواة إليه بدلاً من ذلك.
تمت إضافته في الإصدار 233.
systemd.crash_shell
يأخذ وسيطة منطقية أو يمكّن الخيار إذا تم تحديده بدون وسيطة. إذا تم تمكينه، فإن مدير `systemd` (PID 1) يطلق عملية shell عند التعطل. وإلا، فلن يتم إطلاق أي عملية shell. بشكل افتراضي، يكون معطلاً، لأسباب تتعلق بالأمان، حيث أن عملية shell ليست محمية بواسطة مصادقة كلمة المرور.
تمت إضافته في الإصدار 233.
systemd.crash_action=
يأخذ إحدى القيم: "freeze" أو "reboot" أو "poweroff". بشكل افتراضي، يكون "freeze". إذا تم تعيينه على "freeze"، فسيتوقف النظام إلى أجل غير مسمى عند تعطل مدير النظام (PID 1). إذا تم تعيينه على "reboot"، فسيقوم مدير النظام (PID 1) بإعادة تشغيل الجهاز تلقائيًا عند التعطل، بعد تأخير 10 ثوانٍ. إذا تم تعيينه على "poweroff"، فسيقوم مدير النظام (PID 1) بإيقاف تشغيل الجهاز على الفور عند التعطل. إذا تم دمجه مع `systemd.crash_shell`، فسيتم تنفيذ إجراء التعطل المُكوَّن بعد خروج عملية shell.
تمت إضافته في الإصدار 256.
systemd.confirm_spawn
يأخذ وسيطة منطقية أو مسارًا إلى الجهاز الطرفي الافتراضي الذي يجب إخراج رسائل التأكيد إليه. يمكن تحديده أيضًا بدون وسيطة، بنفس تأثير الوسيطة المنطقية الموجبة. إذا تم تمكينه، يطلب مدير `systemd` (PID 1) التأكيد عند إطلاق العمليات باستخدام `/dev/console`. إذا تم توفير مسار أو اسم جهاز طرفي (مثل "ttyS0")، فسيتم استخدام الجهاز الطرفي المشار إليه بواسطة هذا المسار أو الموصوف بالاسم المقدم بدلاً من ذلك. بشكل افتراضي، يكون معطلاً.
أُضيفت في الإصدار 233.
systemd.service_watchdogs=
يأخذ وسيطًا منطقيًا. إذا تم تعطيله، سيتم تجاهل جميع أجهزة المراقبة الخاصة بالخدمات (WatchdogSec=) والإجراءات الطارئة (مثل OnFailure= أو StartLimitAction=) بواسطة مدير النظام (معرّف العملية 1)؛ راجع systemd.service(5). القيمة الافتراضية هي تمكينها، أي تتم معالجة أجهزة المراقبة وإجراءات الفشل بشكل طبيعي. لا يتأثر جهاز المراقبة للأجهزة بهذا الخيار.
أُضيفت في الإصدار 237.
systemd.show_status
يأخذ وسيطًا منطقيًا أو الثوابت error و auto. يمكن أيضًا تحديده بدون وسيط، ويكون له نفس تأثير الوسيط المنطقي الموجب. إذا تم تمكينه، يعرض مدير systemd (معرّف العملية 1) تحديثات حالة الخدمة الموجزة على وحدة التحكم أثناء بدء التشغيل. مع "error"، يتم عرض الرسائل المتعلقة بالإخفاقات فقط، ولكن يكون بدء التشغيل هادئًا بخلاف ذلك. يتصرف "auto" كما لو كان "false" حتى يحدث تأخير كبير في بدء التشغيل. القيمة الافتراضية هي تمكينها، إلا إذا تم تمرير "quiet" كخيار في سطر أوامر النواة، وفي هذه الحالة تكون القيمة الافتراضية هي "error". إذا تم تحديده، فإنه يOverride خيار ملف تكوين مدير النظام ShowStatus=، راجع systemd-system.conf(5).
أُضيفت في الإصدار 233.
systemd.status_unit_format=
يأخذ القيم name أو description أو combined. إذا كانت "name"، فسيستخدم مدير النظام أسماء الوحدات في رسائل الحالة. إذا كانت "combined"، فسيستخدم مدير النظام أسماء الوحدات وأوصافها في رسائل الحالة. عند تحديده، فإنه يOverride خيار ملف تكوين مدير النظام 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=
يأخذ قيمة سداسية عشرية مكونة من 32 حرفًا لاستخدامها في تعيين معرّف الجهاز. المقصود منه في الغالب التمهيد عبر الشبكة حيث يتم الرغبة في استخدام نفس معرّف الجهاز لكل عملية تمهيد.
أُضيفت في الإصدار 229.
systemd.set_credential=، systemd.set_credential_binary=
يُعيّن بيانات اعتماد النظام، والتي يمكن بعد ذلك تمريرها إلى خدمات النظام باستخدام
الإعداد ImportCredential= أو LoadCredential=، راجع systemd.exec(5) للحصول على التفاصيل. يأخذ زوجًا
من اسم البيانات و قيمتها، مفصولين بنقطتين. يتوقع المعامل systemd.set_credential= قيمة البيانات في شكل نصي حرفي، بينما يأخذ المعامل systemd.set_credential_binary= بيانات ثنائية مشفرة بتنسيق Base64. لاحظ أن سطر أوامر النواة يكون عادةً متاحًا للبرامج غير المميزة في /proc/cmdline. وبالتالي، فإن هذه الآلية غير مناسبة لنقل البيانات الحساسة. استخدمها فقط للبيانات غير الحساسة (مثل المفاتيح العامة/الشهادات، بدلاً من المفاتيح الخاصة)، أو في بيئات الاختبار/التصحيح.
لمزيد من المعلومات، راجع وثائق System and Service Credentials[8].
أُضيفت في الإصدار 251.
systemd.import_credentials=
يأخذ وسيطًا منطقيًا. إذا كانت القيمة خاطئة، فسيتم تعطيل استيراد البيانات من سطر أوامر النواة، أو جدول سلسلة OEM الخاص بـ DMI/SMBIOS، أو نظام qemu_fw_cfg الفرعي، أو برنامج تشغيل النواة EFI.
أُضيفت في الإصدار 251.
quiet
أوقف تشغيل إخراج الحالة أثناء الإقلاع، على غرار ما يفعله الخيار systemd.show_status=no. لاحظ أن هذا الخيار يقرأه أيضًا النواة نفسها ويعطل إخراج سجل النواة. وبالتالي، فإن تمرير هذا الخيار يعطل الإخراج المعتاد من كل من مدير النظام والنواة.
أُضيفت في الإصدار 186.
debug
شغّل إخراج التصحيح. هذا يعادل systemd.log_level=debug. لاحظ أن هذا الخيار يقرأه أيضًا النواة نفسها ويقوم بتمكين إخراج تصحيح النواة. وبالتالي، فإن تمرير هذا الخيار يشغّل إخراج التصحيح من كل من مدير النظام والنواة.
أُضيفت في الإصدار 205.
emergency، rd.emergency، -b
الإقلاع في وضع الطوارئ. هذا يعادل systemd.unit=emergency.target أو
rd.systemd.unit=emergency.target، على التوالي، ومُقدَّم لأسباب التوافق ولتسهيل الكتابة.
أُضيفت في الإصدار 186.
rescue، rd.rescue، single، s، S، 1
الإقلاع في وضع الاستعادة. هذا يعادل 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=
اضبط إعدادات اللغة المحلية للنظام لاستخدامها. هذا يلغي الإعدادات الموجودة في /etc/locale.conf. لمزيد من المعلومات، راجع locale.conf(5) و locale(7).
أُضيفت في الإصدار 186.
للحصول على معلمات سطر أوامر النواة الأخرى التي تفهمها مكونات نظام التشغيل الأساسي، يرجى الرجوع إلى kernel-command-line(7).
بيانات الاعتماد الخاصة بالنظام
أثناء التهيئة، يقوم مدير الخدمة باستيراد بيانات الاعتماد من مصادر مختلفة إلى مجموعة بيانات الاعتماد الخاصة بالنظام، والتي يمكن بعد ذلك نشرها في الخدمات واستهلاكها بواسطة المولدات:
عندما يقوم مدير الخدمة بتهيئة نفسه لأول مرة، فإنه يقرأ بيانات الاعتماد الخاصة بالنظام من سلاسل SMBIOS Type 11، على النحو التالي: io.systemd.credential:name=value، و io.systemd.credential.binary:name=value.
في الوقت نفسه، سيقوم باستيراد بيانات الاعتماد من QEMU "fw_cfg". (لاحظ أن آلية SMBIOS هي الأفضل بشكل عام، لأنها أسرع وأكثر عمومية.)
يمكن تمرير بيانات الاعتماد عبر سطر أوامر النواة، باستخدام المعلمة systemd.set-credential=، كما هو مذكور أعلاه.
يمكن تمرير بيانات الاعتماد من بيئة UEFI عبر systemd-stub(7).
عندما يتم استدعاء مدير الخدمة أثناء الانتقال من initrd إلى النظام المضيف، فإنه سيستورد جميع الملفات الموجودة في /run/credentials/@initrd/ كبيانات اعتماد للنظام.
استخدم الأمر systemd-creds(1) على النحو التالي لعرض قائمة ببيانات الاعتماد التي تم تمريرها إلى النظام:
# systemd-creds --system list
لمزيد من المعلومات، راجع وثائق System and Service Credentials[8].
يستهلك مدير الخدمة، عند تشغيله كـ PID 1، بيانات الاعتماد التالية للنظام:
vmm.notify_socket
يحتوي على عنوان AF_VSOCK أو AF_UNIX لإرسال رسالة إشعار READY=1 عندما يكمل مدير الخدمة عملية الإقلاع. راجع sd_notify(3) والقسم التالي لمزيد من المعلومات. لاحظ أنه في حالة عدم دعم برنامج التشغيل الافتراضي لـ SOCK_DGRAM عبر AF_VSOCK، سيتم تجربة SOCK_SEQPACKET بدلاً من ذلك. يجب أن يكون حمولة بيانات الاعتماد لـ AF_VSOCK عبارة عن سلسلة بالصيغة "vsock:CID:PORT". يمكن استخدام "vsock-stream" و "vsock-dgram" و "vsock-seqpacket" بدلاً من "vsock" لفرض استخدام نوع المقبس المقابل.
تعتبر هذه الميزة مفيدة لمديري الأجهزة أو العمليات الأخرى الموجودة على المضيف لتلقي إشعار عبر VSOCK عندما تنتهي آلة افتراضية من الإقلاع.
تمت إضافتها في الإصدار 254.
system.machine_id
يأخذ معرفًا سداسيًا عشريًا مكونًا من 128 بت لتهيئة /etc/machine-id، في حالة عدم إعداده بالفعل. راجع machine-id(5) للحصول على التفاصيل.
تمت إضافتها في الإصدار 254.
للحصول على قائمة ببيانات الاعتماد الخاصة بالنظام التي تستهلكها مكونات systemd المختلفة، راجع systemd.systemcredentials(7).
بروتوكول الاستعداد
يقوم مدير الخدمة بتنفيذ بروتوكول إشعار الاستعداد بين المدير وخدماته (أي إلى الأسفل في التسلسل الهرمي)، وبين المدير ومراقب محتمل في المستوى الأعلى (قد يكون مدير جهاز أو حاوية، أو في حالة مدير خدمة لكل مستخدم، يكون مثيل مدير الخدمة للنظام). يتم وصف البروتوكول الأساسي (والواجهة البرمجية المقترحة له) في sd_notify(3).
يتم تحديد مقبس الإشعار الذي يستخدمه مدير الخدمة (بما في ذلك PID 1) لإرسال إشعارات الاستعداد إلى المشرف الخاص به عبر متغير البيئة $NOTIFY_SOCKET (كما هو مذكور أعلاه). نظرًا لأنه يمكن تعيين هذا مباشرةً فقط لمديري الحاويات ولـ مثيل مدير الخدمة لكل مستخدم، فهناك آلية إضافية لتكوين هذا، وهي مخصصة بشكل خاص للاستخدام في بيئات الأجهزة الافتراضية: يمكن تعيين بيانات الاعتماد الخاصة بالنظام vmm.notify_socket إلى مقبس مناسب (عادةً ما يكون AF_VSOCK) عبر سلاسل SMBIOS Type 11. للحصول على التفاصيل، راجع ما ورد أعلاه.
يدعم بروتوكول الإشعارات من مدير الخدمة إلى الأعلى نحو المشرف عددًا من حقول الإضافة التي تسمح للمشرف بمعرفة خصائص معينة للنظام وتتبع تقدم الإقلاع. على وجه التحديد، يتم إرسال الحقول التالية:
سيتم إرسال رسالة X_SYSTEMD_HOSTNAME=... بمجرد تحديد اسم المضيف الأولي للنظام. لاحظ أنه خلال وقت التشغيل اللاحق، قد يتم تغيير اسم المضيف مرة أخرى برمجيًا، و (حاليًا) لا يتم إرسال أي إشعارات إضافية في هذه الحالة.
تمت إضافته في الإصدار 256.
سيتم إرسال رسالة X_SYSTEMD_MACHINE_ID=... بمجرد تحديد معرف الجهاز الخاص بالنظام. راجع machine-id(5) للحصول على التفاصيل.
تمت إضافته في الإصدار 256.
سيتم إرسال رسالة X_SYSTEMD_SIGNALS_LEVEL=... بمجرد تثبيت مدير الخدمة لمعالجات إشارات عمليات UNIX المختلفة الموصوفة أعلاه. قيمة الحقل هي عدد صحيح غير سالب بتنسيق سلسلة عشرية، وتشير إلى مستوى ميزة إشارة العملية UNIX المدعومة لمدير الخدمة. حاليًا، يتم تحديد مستوى ميزة واحد فقط:
^ _SYSTEMD_SIGNALS_LEVEL=2 يغطي إشارات عمليات UNIX المختلفة الموثقة أعلاه - وهي مجموعة فرعية من تلك المدعومة بواسطة نظام 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) الذي يتم تشغيله به هو 1 أم لا. لاحظ أنه لا يتم دعم تشغيل النظام والحفاظ عليه مع تشغيل مدير الخدمة في وضع --system ولكن بمعرف عملية (PID) مختلف عن 1.
-h، `--help`
اطبع نص مساعدة موجزًا واخرج.
`--version`
اطبع سلسلة إصدار موجزة واخرج.
خيارات تكرر إعدادات سطر أوامر النواة
تتوافق هذه الخيارات مباشرةً مع الخيارات المدرجة أعلاه في "سطر أوامر النواة". يمكن استخدام كلا الشكلين بشكل متساوٍ لمدير النظام، ولكن يوصى باستخدام الأشكال المدرجة أعلاه في هذا السياق، لأنها مسماة بشكل صحيح. عند تحديد خيار في كل من سطر أوامر النواة وكوسيطة سطر أوامر عادية، يكون للخيار الأخير الأسبقية.
عند استخدام systemd كمدير مستخدم، يتم تجاهل سطر أوامر النواة ولا يتم فهم سوى الخيارات الموضحة أدناه. ومع ذلك، يتم عادةً بدء تشغيل systemd في هذا الوضع من خلال خدمة [email protected](5)، والتي تتم مشاركتها بين جميع المستخدمين. قد يكون من الأسهل استخدام ملفات التكوين لتعديل الإعدادات (انظر systemd-user.conf(5))، أو متغيرات البيئة. راجع قسم "البيئة" أعلاه لمناقشة كيفية تعيين كتلة البيئة.
--unit=
اضبط الوحدة الافتراضية لتفعيلها عند بدء التشغيل. إذا لم يتم تحديده، فسيتم افتراضيًا إلى default.target. راجع systemd.unit= أعلاه.
--dump-core
فعّل تفريغ النواة عند التعطّل. لا يكون لهذا الخيار أي تأثير عند تشغيله كمثيل مستخدم. وهو نفس خيار systemd.dump_core= أعلاه.
--crash-vt=VT
قم بالتبديل إلى وحدة تحكم افتراضية (VT) محددة عند التعطّل. لا يكون لهذا الخيار أي تأثير عند تشغيله كمثيل مستخدم. وهو نفس خيار systemd.crash_chvt= أعلاه (ولكن مع اختلاف التهجئة!).
تمت إضافته في الإصدار 227.
--crash-shell
شغّل 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
فعّل أو عطّل عالميًا جميع مهلات مراقبة الخدمة (service watchdog) والإجراءات الطارئة. راجع systemd.service_watchdogs أعلاه.
تمت إضافته في الإصدار 237.
--default-standard-output=، --default-standard-error=
يضبط الإخراج الافتراضي أو إخراج الخطأ لجميع الخدمات والمنافذ (sockets)، على التوالي. راجع systemd.default_standard_output= و systemd.default_standard_error= أعلاه.
حقبة الساعة النظام (SYSTEM CLOCK EPOCH)
عند بدء تشغيل systemd أو إعادة تشغيله، قد يقوم بضبط ساعة النظام إلى "الحقبة". تُستخدم هذه الآلية لضمان بقاء ساعة النظام مهيأة بشكل معقول ومستقر تقريبًا عبر عمليات إعادة التشغيل، في حالة عدم وجود RTC (ساعة حقيقية مدعومة بالبطارية) أو إذا لم تكن تعمل بشكل صحيح.
الحقبة هي أدنى تاريخ يُفترض أن يكون وقت ساعة النظام مضبوطًا عليه بشكل صحيح. عند التهيئة، يتم تعديل الساعة المحلية إلى الحقبة إذا كانت مضبوطة على قيمة أقل. كحالة خاصة، إذا كانت الساعة المحلية متأخرة بشكل كبير (افتراضيًا 15 عامًا، ولكن يمكن تكوين ذلك في وقت الإنشاء)، فسيتم افتراض أن الساعة المادية معطلة، ويتم إعادة ضبط ساعة النظام إلى الحقبة.
يتم تعيين الحقبة إلى الأعلى من: وقت إنشاء systemd، ووقت التعديل ("mtime") لـ /usr/lib/clock-epoch، ووقت التعديل لـ /var/lib/systemd/timesync/clock.
الملفات
/run/systemd/notify
مقبس إشعار حالة برنامج التشغيل. هذا عبارة عن مقبس بيانات AF_UNIX ويستخدم لتنفيذ منطق إشعار برنامج التشغيل كما هو مُنفَّذ بواسطة sd_notify(3).
/run/systemd/private
يستخدم داخليًا كقناة اتصال بين [systemctl]({filename}../../systemctl)(1) وعملية systemd. هذا عبارة عن مقبس دفق AF_UNIX. هذه الواجهة خاصة بـ systemd ولا ينبغي استخدامها في المشاريع الخارجية.
/usr/lib/clock-epoch
يتم استخدام وقت التعديل ("mtime") لهذا الملف لوقت الحقبة، راجع القسم السابق.
تمت إضافته في الإصدار 247.
/var/lib/systemd/timesync/clock
يتم تحديث وقت التعديل ("mtime") لهذا الملف بواسطة systemd-timesyncd.service(8). إذا كان موجودًا، يتم استخدام وقت تعديل الملف للحصول على الحقبة، راجع القسم السابق.
تمت إضافته في الإصدار 257.
التاريخ
systemd 252
تم إهمال وسيطات سطر أوامر النواة systemd.unified_cgroup_hierarchy و systemd.legacy_systemd_cgroup_controller. يرجى التبديل إلى التسلسل الهرمي الموحد لمجموعة التحكم.
انظر أيضًا
الصفحة الرئيسية لـ systemd[9]، systemd-system.conf(5)، locale.conf(5)، [systemctl]({filename}../../systemctl)(1)، [journalctl]({filename}../../journalctl)(1)، systemd-notify(1)، daemon(7)، sd-daemon(3)، org.freedesktop.systemd1(5)، systemd.unit(5)، systemd.special(7)، pkg-config(1)، kernel-command-line(7)، bootup(7)، systemd.directives(7)، org.freedesktop.systemd1(5)
لمزيد من المعلومات حول المفاهيم والأفكار التي تقوم عليها systemd، يرجى الرجوع إلى وثيقة التصميم الأصلية[10].
ملاحظات
واجهة قابلية النقل والاستقرار
https://systemd.io/PORTABILITY_AND_STABILITY/
واجهة الحاوية
https://systemd.io/CONTAINER_INTERFACE
واجهة initrd
https://systemd.io/INITRD_INTERFACE/
مجموعات التحكم v2
https://docs.kernel.org/admin-guide/cgroup-v2.html
مواصفات دليل XDG الأساسي
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
يوصى بأن تقوم الأدوات الأخرى بتعيين والتحقق من $SUDO_UID حسب الاقتضاء، مع معاملتها كواجهة شائعة.
متغيرات البيئة المعروفة
https://systemd.io/ENVIRONMENT
بيانات اعتماد النظام والخدمة
https://systemd.io/CREDENTIALS
الصفحة الرئيسية لـ systemd
https://systemd.io/
وثيقة التصميم الأصلية
https://0pointer.de/blog/projects/systemd.html