SYSTEMD(1)

systemd

SYSTEMD(1)

الاسم¶

systemd، init - مدير النظام والخدمة systemd

موجز¶

/usr/lib/systemd/systemd [الخيارات...]

init [الخيارات...]

الوصف¶

إن systemd هو مدير نظام وخدمة لأنظمة تشغيل لينكس. عند تشغيله كأول عملية عند الإقلاع (بمعرف العملية PID 1)، فإنه يعمل كنظام init الذي يُنشئ خدمات فضاء المستخدم ويصونها. تُبدأ مثيلات منفصلة للمستخدمين المسجلين لبدء خدماتهم.

عادةً لا يُستدعى systemd مباشرة بواسطة المستخدم، بل يُثبت كوصلة رمزية في /sbin/init ويُبدأ خلال الإقلاع المبكر. تُبدأ مثيلات مدير المستخدم آليًا من خلال خدمة user@.service(5).

عند تشغيله كمثيلة نظام، يفسر systemd ملف الإعداد system.conf والملفات في أدلة system.conf.d؛ وعند تشغيله كمثيلة مستخدم، يفسر systemd ملف الإعداد user.conf والملفات في أدلة user.conf.d. انظر systemd-system.conf(5) لمزيد من المعلومات.

يحتوي systemd على تنفيذات أصيلة لمهام متنوعة يجب تنفيذها كجزء من عملية الإقلاع. على سبيل المثال، يضبط اسم المضيف أو يضبط جهاز شبكة الالتفاف المحلي (loopback). كما يُعد ويصل أنظمة ملفات واجهة برمجة التطبيقات المختلفة، مثل /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. حالات الوحدة النشطة

الحالة	الوصف
نشط	بدأت، ارتبطت، وُصلت، ...، اعتماداً على نوع الوحدة.
inactive	توقفت، فُك ارتباطها، فُصلت، ...، اعتماداً على نوع الوحدة.
failed	مشابه لـ inactive (غير نشط)، ولكن الوحدة فشلت بطريقة ما (أعادت العملية رمز خطأ عند الخروج، أو انهارت، أو انتهت مهلة عملية ما، أو بعد عدد كبير جداً من إعادات التشغيل).
جارٍ التنشيط	التغيير من inactive إلى active.
deactivating	التغيير من active إلى inactive.
maintenance	الوحدة غير نشطة وتجري عملية صيانة حاليًا.
reloading	الوحدة نشطة وهي تعيد تحميل تهيئتها.
refreshing	الوحدة نشطة ويجري تنشيط وصل جديد في مساحة الأسماء الخاصة بها.

تتوفر أنواع الوحدات التالية:

1.وحدات الخدمة (Service units)، والتي تبدأ وتتحكم في العفاريت (daemons) والعمليات التي تتكون منها. للحصول على التفاصيل، انظر 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) لتجميع الوحدات التي تدير عمليات النظام (مثل وحدات الخدمة والمدى) في شجرة هرمية لأغراض إدارة الموارد. انظر 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 بتمكين أو تعطيل الوحدات وفقًا لسياسة مسبقة الضبط. انظر systemd.preset(5) و "دلالات الإقلاع الأول" في machine-id(5).

يحتفظ systemd فقط بمجموعة دنيا من الوحدات المحملة في الذاكرة. وتحديدًا، الوحدات الوحيدة التي تبقى محملة في الذاكرة هي تلك التي يتحقق فيها شرط واحد على الأقل من الشروط التالية:

1.أن تكون في حالة نشطة (active)، أو قيد التنشيط (activating)، أو قيد التعطيل (deactivating)، أو فاشلة (failed) (أي في أي حالة وحدة باستثناء "inactive")

2.أن يكون لها وظيفة منتظرة في الطابور

3.أن تكون اعتمادية لوحدة أخرى واحدة على الأقل محملة في الذاكرة

4.أن يكون لها شكل من أشكال الموارد التي لا تزال مخصصة (على سبيل المثال وحدة خدمة غير نشطة ولكن لا تزال هناك عملية تابعة لها باقية وتجاهلت طلب الإنهاء)

5.أن تُثبّت في الذاكرة برمجياً بواسطة استدعاء D-Bus

سيقوم systemd آليًا وضمنيًا بتحميل الوحدات من القرص — إذا لم تكن محملة بعد — بمجرد طلب عمليات لها. وبالتالي، في نواحٍ كثيرة، تكون حقيقة ما إذا كانت الوحدة محملة أم لا غير مرئية للعملاء. استخدم systemctl list-units --all لسرد جميع الوحدات المحملة حاليًا بشكل شامل. تُفرغ أي وحدة لا ينطبق عليها أي من الشروط المذكورة أعلاه فوراً. لاحظ أنه عند إفراغ وحدة من الذاكرة، تُفرغ بيانات المحاسبة الخاصة بها أيضًا. ومع ذلك، لا تُفقد هذه البيانات عمومًا، حيث يُنشأ سجل في اليومية (journal) يعلن عن الموارد المستهلكة كلما توقفت وحدة ما.

توضع العمليات التي يطلقها systemd في مجموعات تحكم لينكس (control groups) فردية تسمى باسم الوحدة التي تنتمي إليها في التسلسل الهرمي الخاص لـ systemd. (انظر مجموعات التحكم الإصدار 2[4] لمزيد من المعلومات حول مجموعات التحكم، أو اختصارًا "cgroups"). يستخدم systemd هذا لتتبع العمليات بشكل فعال. تُصان معلومات مجموعة التحكم في النواة، ويمكن الوصول إليها عبر التسلسل الهرمي لنظام الملفات (تحت /sys/fs/cgroup/)، أو في أدوات مثل systemd-cgls(1) أو ps(1) (يعد ps xawf -eo pid,user,cgroup,args مفيدًا بشكل خاص لسرد جميع العمليات ووحدات systemd التي تنتمي إليها.).

يتوافق systemd مع وظائف يونكس الراسخة المختلفة مثل /etc/fstab أو قاعدة بيانات utmp.

يحتوي systemd على نظام معاملات (transaction system) أدنى: إذا طُلب بدء تشغيل وحدة أو إيقاف تشغيلها، فسيضيفها وجميع اعتمادياتها إلى معاملة مؤقتة. بعد ذلك، سيتحقق مما إذا كانت المعاملة متسقة (أي ما إذا كان ترتيب جميع الوحدات خاليًا من الحلقات التكرارية). إذا لم تكن كذلك، فسيحاول 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 الأساسي[5] للعثور على الوحدات. يجب أن تضع التطبيقات ملفات وحداتها في الدليل الذي ترجعه القيمة pkg-config systemd --variable=systemduserunitdir. يتم الإعداد العام في الدليل الذي يبلغ عنه pkg-config systemd --variable=systemduserconfdir. يمكن للأمرين enable و disable من أداة systemctl(1) التعامل مع كل من تمكين/تعطيل الوحدات العام (أي لجميع المستخدمين) والخاص (لمستخدم واحد). تتوفر قائمة كاملة بالأدلة في systemd.unit(5).

إشارات¶

تستمع الخدمة إلى إشارات عملية يونكس المختلفة التي يمكن استخدامها لطلب إجراءات متنوعة بشكل غير متزامن. تم تمكين معالجة الإشارات في وقت مبكر جدًا أثناء الإقلاع، قبل استدعاء أي عمليات أخرى. ومع ذلك، يجب على مدير حاوية مشرف أو ما شابه ذلك والذي ينوي طلب هذه العمليات عبر هذه الآلية أن يأخذ في الاعتبار أن هذه الوظيفة غير متوفرة خلال مرحلة التهيئة المبكرة. يتم إصدار رسالة إشعار 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 لتجنب حالات التسابق (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

يستعيد هدف السجل إلى قيمته المضبوطة. تُشتق القيمة المضبوطة من – حسب ترتيب الأولوية – القيمة المحددة بـ 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

قيمة منطقية. إذا كانت صحيحة، فستُلون الرسائل المكتوبة في الـ tty حسب الأولوية.

يمكن تجاوز هذا باستخدام --log-color=.

$SYSTEMD_LOG_TIME

قيمة منطقية. إذا كانت صحيحة، فستُسبق رسائل سجل الطرفية بختم زمني.

يمكن تجاوز هذا باستخدام --log-time=.

أُضيف في الإصدار 246.

$SYSTEMD_LOG_LOCATION

قيمة منطقية. إذا كانت صحيحة، فستُسبق الرسائل باسم الملف ورقم السطر في الشيفرة المصدرية حيث نشأت الرسالة.

يمكن تجاوز هذا باستخدام --log-location=.

$SYSTEMD_LOG_TID

قيمة منطقية. إذا كانت صحيحة، فستُسبق الرسائل بمعرّف الخيط الرقمي الحالي (TID).

أُضيف في الإصدار 247.

$SYSTEMD_LOG_TARGET

وجهة رسائل السجل. أحد الخيارات: console (التسجيل في الطرفية المرفقة)، أو console-prefixed (التسجيل في الطرفية المرفقة ولكن مع بادئات ترميز مستوى السجل و"المرفق"، راجع 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(1) و more(1)، حتى يُعثر على أحدها. إذا لم يُكتشف أي تطبيق لمستعرض الصفحات، فلا يُستدعى أي مستعرض. ضبط متغيرات البيئة هذه على سلسلة فارغة أو القيمة "cat" يعادل تمرير الخيار --no-pager.

ملاحظة: إذا لم يُضبط $SYSTEMD_PAGERSECURE، فلا يمكن استخدام $SYSTEMD_PAGER و $PAGER إلا لتعطيل مستعرض الصفحات (باستخدام "cat" أو "")، ويتم تجاهلهما فيما عدا ذلك.

$SYSTEMD_LESS

تجاوز الخيارات الممررة إلى less (مبدئيًا "FRSXMK").

قد يرغب المستخدمون في تغيير خيارين على وجه الخصوص:

يوجه هذا الخيار مستعرض الصفحات بالخروج فورًا عند الضغط على Ctrl+C. للسماح لـ less بالتعامل مع Ctrl+C بنفسه للعودة إلى محث أوامر المستعرض، قم بإلغاء ضبط هذا الخيار.

إذا لم تتضمن قيمة $SYSTEMD_LESS الحرف "K"، وكان المستعرض المستدعى هو less، فسيُتجاهل Ctrl+C من قبل الملف التنفيذي، ويجب معالجته من قبل المستعرض.

يوجه هذا الخيار مستعرض الصفحات بعدم إرسال سلاسل تهيئة وإنهاء termcap إلى الطرفية. يُضبط مبدئيًا للسماح لمخرجات الأوامر بالبقاء مرئية في الطرفية حتى بعد خروج المستعرض. ومع ذلك، فإن هذا يمنع بعض وظائف المستعرض من العمل، لا سيما أن المخرجات المفصولة بصفحات لا يمكن تمريرها باستخدام الفأرة.

لاحظ أن ضبط متغير البيئة العادي $LESS ليس له أي تأثير عند استدعاء less بواسطة أدوات systemd.

راجع less(1) لمزيد من النقاش.

$SYSTEMD_LESSCHARSET

يتجاوز طقم المحارف الممرر إلى less (مبدئيًا "utf-8"، إذا حُدّد أن الطرفية المستدعية متوافقة مع UTF-8).

لاحظ أن ضبط متغير البيئة العادي $LESSCHARSET ليس له أي تأثير عند استدعاء less بواسطة أدوات systemd.

$SYSTEMD_PAGERSECURE

تدعم أوامر المستعرض (pager) الشائعة مثل less(1)، بالإضافة إلى "التصفح"، أي التمرير عبر المخرجات، فتح ملفات أخرى أو الكتابة إليها وتشغيل أوامر صدفة عشوائية. عند استدعاء الأوامر بامتيازات مرفوعة، على سبيل المثال تحت sudo(8) أو pkexec(1)، يصبح المستعرض حدًا أمنيًا. يجب الحرص على استخدام البرامج ذات الوظائف المحدودة للغاية فقط كمستعرضات، وعدم السماح بالميزات التفاعلية غير المقصودة مثل فتح ملفات جديدة أو إنشائها أو بدء عمليات فرعية. يمكن تمكين "الوضع الآمن" للمستعرض كما هو موضح أدناه، إذا كان المستعرض يدعم ذلك (معظم المستعرضات لم تُكتب بطريقة تأخذ هذا في الاعتبار). يوصى إما بتمكين "الوضع الآمن" صراحةً أو تعطيل المستعرض تمامًا باستخدام --no-pager أو PAGER=cat عند السماح للمستخدمين غير الموثوق بهم بتنفيذ أوامر بامتيازات مرفوعة.

يأخذ هذا الخيار وسيطًا منطقيًا. عند ضبطه على صحيح (true)، يتم تمكين "الوضع الآمن" لمستعرض الصفحات. في "الوضع الآمن"، سيُضبط LESSSECURE=1 عند استدعاء المستعرض، مما يوجه المستعرض لتعطيل الأوامر التي تفتح أو تنشئ ملفات جديدة أو تبدأ عمليات فرعية جديدة. حاليًا، يُعرف فقط less(1) بقدرته على فهم هذا المتغير وتطبيق "الوضع الآمن".

عند الضبط إلى false، لا توضع قيود على أداة التصفح (pager). إن ضبط SYSTEMD_PAGERSECURE=0 أو عدم إزالته من البيئة الموروثة قد يسمح للمستخدم باستدعاء أوامر اعتباطية.

عندما لا يكون $SYSTEMD_PAGERSECURE مضبوطًا، تحاول أدوات systemd آليًا معرفة ما إذا كان ينبغي تفعيل "النمط الآمن" وما إذا كان المستعرض يدعمه. يُفعل "النمط الآمن" إذا كان معرف المستخدم الفعلي ليس هو نفسه مالك جلسة الولوج، انظر 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

يأخذ وسيطًا منطقيًا (boolean)، أو قيمة خاصة. مبدئيًا (عند عدم الضبط)، سيستخدم systemd والأدوات المرتبطة به الألوان في مخرجاتها إذا أمكن ذلك. إذا ضُبط $COLORTERM على "truecolor" أو "24bit"، فسيتم تمكين ألوان 24 بت، وإلا فستُستخدم 256 لونًا، ما لم يشر $NO_COLOR أو $TERM إلى تعطيل الألوان.

true

نفس حالة عدم الضبط، باستثناء تجاهل $NO_COLOR.

false

سيكون المخرج أحادي اللون.

"16"، "256"، "24bit"

استخدم دائمًا ألوان ANSI الـ 16 الأساسية، أو 256 لونًا، أو لون 24 بت، على التوالي.

"auto-16"، "auto-256"، "auto-24bit"

استخدم كمية الألوان المعطاة، بشرط $TERM، وما هو متصل بالطرفية.

$SYSTEMD_URLIFY

يجب أن تكون القيمة منطقية. تتحكم فيما إذا كان يجب توليد روابط قابلة للنقر في المخرج لمحاكيات الطرفية التي تدعم ذلك. يمكن تحديد هذا لتجاوز القرار الذي يتخذه systemd بناءً على $TERM وشروط أخرى.

$LISTEN_PID، و $LISTEN_PIDFDID، و $LISTEN_FDS، و $LISTEN_FDNAMES

يضبطه systemd للعمليات المراقبة أثناء التفعيل المستند إلى المقابس (socket-based activation). انظر sd_listen_fds(3) لمزيد من المعلومات.

$NOTIFY_SOCKET

يضبطه مدير الخدمة لخدماته من أجل إشعارات الحالة والجاهزية. ويستهلكه أيضاً مدير الخدمة لإخطار مديري الحاويات المشرفين أو مديري الخدمات في أعلى المكدس بتقدمه الخاص. راجع sd_notify(3) والقسم ذو الصلة أدناه لمزيد من المعلومات.

لمزيد من متغيرات البيئة التي يفهمها systemd ومكوناته المختلفة، راجع متغيرات البيئة المعروفة[7].

سطر أوامر النواة¶

عند تشغيله كنسخة للنظام، يحلل systemd عدداً من الخيارات المدرجة أدناه. يمكن تحديدها كمعطيات لسطر أوامر النواة والتي تُحلل من عدة مصادر اعتماداً على البيئة التي يُنفذ فيها systemd. إذا شُغل داخل حاوية لينكس، تُحلل هذه الخيارات من معطيات سطر الأوامر الممررة إلى systemd نفسه، إلى جانب أي من خيارات سطر الأوامر المدرجة في قسم «الخيارات» أعلاه. أما إذا شُغل خارج حاويات لينكس، فتُحلل هذه المعطيات من الملف /proc/cmdline بدلاً من ذلك.

المتغيرات التالية مفهومة:

systemd.unit=، rd.systemd.unit=

يتخطى الوحدة المراد تنشيطها عند الإقلاع. القيمة المبدئية هي default.target. قد يُستخدم هذا للإقلاع مؤقتاً في وحدة إقلاع مختلفة، على سبيل المثال rescue.target أو emergency.service. راجع systemd.special(7) للحصول على تفاصيل حول هذه الوحدات. الخيار المسبوق بـ "rd." يُحترم فقط في قرص الذاكرة المبدئي (initrd)، بينما الخيار غير المسبوق يُحترم فقط في نظام التشغيل الرئيس.

systemd.dump_core

يأخذ معطى منطقياً أو يُفعل الخيار إذا حُدد بدون معطى. في حال تفعيله، يقوم مدير systemd (ذي المعرف PID 1) بتفريغ الذاكرة (dump core) عندما ينهار. خلاف ذلك، لا يُنشأ أي تفريغ للذاكرة. المبدئي هو مفعل.

أُضيف في الإصدار 233.

systemd.crash_chvt

يأخذ عدداً صحيحاً موجباً، أو معطى منطقياً. يمكن أيضاً تحديده بدون معطى، بنفس تأثير القيمة المنطقية الموجبة. إذا حُدد عدد صحيح موجب (في النطاق 1-63)، فسيقوم مدير النظام (PID 1) بتنشيط الطرفية الافتراضية المحددة عندما ينهار. المبدئي هو معطل، مما يعني عدم محاولة إجراء مثل هذا التبديل. إذا ضُبط على مفعل، تُستخدم الطرفية الافتراضية التي تُكتب عليها رسائل النواة عوضاً عن ذلك.

أُضيف في الإصدار 233.

systemd.crash_shell

يأخذ معطى منطقياً أو يُفعل الخيار إذا حُدد بدون معطى. في حال تفعيله، يطلق مدير النظام (PID 1) صدفة (shell) عندما ينهار. خلاف ذلك، لا تُطلق أي صدفة. المبدئي هو معطل، لأسباب أمنية، حيث إن الصدفة ليست محمية بالاستيثاق بكلمة سر.

أُضيف في الإصدار 233.

systemd.crash_action=

يأخذ إحدى القيم "freeze" أو "reboot" أو "poweroff". المبدئي هو "freeze". إذا ضُبط على "freeze"، فسيتوقف النظام عن الاستجابة لأجل غير مسمى عندما ينهار مدير النظام (PID 1). إذا ضُبط على "reboot"، فسيعيد مدير النظام (PID 1) تشغيل الحاسوب آلياً عندما ينهار، بعد تأخير لمدة 10 ثوانٍ. إذا ضُبط على "poweroff"، فسيقوم مدير النظام (PID 1) بإطفاء الحاسوب فوراً عندما ينهار. إذا دُمج مع systemd.crash_shell، يُنفذ إجراء الانهيار المضبوط بعد خروج الصدفة.

أُضيف في الإصدار 256.

systemd.confirm_spawn

يأخذ معطى منطقياً أو مساراً إلى الوحدة الطرفية الافتراضية حيث يجب إرسال رسائل التأكيد. يمكن أيضاً تحديده بدون معطى، بنفس تأثير القيمة المنطقية الموجبة. في حال تفعيله، يطلب مدير النظام (PID 1) التأكيد عند إطلاق العمليات باستخدام /dev/console. إذا قُدم مسار أو اسم وحدة طرفية (مثل "ttyS0")، فستُستخدم الوحدة الطرفية الافتراضية التي يشير إليها هذا المسار أو الموصوفة بالاسم المعطى بدلاً من ذلك. المبدئي هو معطل.

أُضيف في الإصدار 233.

systemd.service_watchdogs=

يأخذ معطى منطقياً. إذا عُطل، فسيتم تجاهل جميع كلاب حراسة (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=

يأخذ قيمة ست عشرية بطول 32 محرفاً لتُستخدم في ضبط معرف الآلة (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)، يعطل استيراد الاعتمادات من سطر أوامر النواة، أو جدول سلاسل DMI/SMBIOS OEM، أو نظام 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=

ضبط محلية (locale) النظام المراد استخدامها. هذا يتخطى الإعدادات في /etc/locale.conf. لمزيد من المعلومات، راجع locale.conf(5) و locale(7).

أُضيف في الإصدارة 186.

لمعاملات سطر أوامر النواة الأخرى التي تفهمها مكونات نظام التشغيل الأساسية، يرجى الرجوع إلى kernel-command-line(7).

اعتمادات النظام¶

أثناء التهيئة، سيقوم مدير الخدمة باستيراد الاعتمادات من مصادر مختلفة إلى مجموعة اعتمادات النظام، والتي يمكن بعد ذلك نشرها في الخدمات واستهلاكها من قبل المولدات:

•عندما يتهيأ مدير الخدمة لأول مرة، فإنه سيقرأ اعتمادات النظام من سلاسل الموردين من نوع SMBIOS Type 11 io.systemd.credential:الاسم=القيمة، و io.systemd.credential.binary:الاسم=القيمة.

•في الوقت نفسه سيقوم باستيراد الاعتمادات من QEMU "fw_cfg". (لاحظ أن آلية SMBIOS مفضلة عموماً، لأنها أسرع وعامة.)

•يمكن تمرير الاعتمادات عبر سطر أوامر النواة، باستخدام المعامل systemd.set-credential=، راجع أعلاه.

•يمكن تمرير الاعتمادات من بيئة UEFI عبر systemd-stub(7).

•عند استدعاء مدير الخدمة أثناء الانتقال من initrd إلى المضيف، فإنه سيستورد جميع الملفات في /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) والقسم التالي لمزيد من المعلومات. لاحظ أنه في حال كان برنامج الإدارة الفائقة (hypervisor) لا يدعم 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.system-credentials(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 المدعوم لمدير الخدمة. حالياً، عُرف مستوى ميزة واحد فقط:

•يغطي X_SYSTEMD_SIGNALS_LEVEL=2 إشارات عمليات UNIX المختلفة الموثقة أعلاه — والتي هي مجموعة مفرطة من تلك التي يدعمها نظام التمهيد SysV التاريخي.

قد لا تُعالج الإشارات المرسلة إلى 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 عادةً في هذا النمط من خلال خدمة user@.service(5)، المشتركة بين جميع المستخدمين. قد يكون من الأنسب استخدام ملفات الضبط لتعديل الإعدادات (راجع systemd-user.conf(5))، أو متغيرات البيئة. راجع قسم «البيئة» أعلاه لمناقشة كيفية ضبط كتلة البيئة.

--unit=

يضبط الوحدة المبدئية لتنشيطها عند بدء التشغيل. إذا لم تُحدد، ستكون القيمة المبدئية هي default.target. انظر systemd.unit= أعلاه.

--dump-core

يُفعل تفريغ الذاكرة (core dumping) عند الانهيار. ليس لهذا المفتاح تأثير عند التشغيل كجلسة مستخدم. وهو مماثل لـ 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

يفعل/يعطل مهل مراقبي الخدمة (watchdog) وإجراءات الطوارئ بشكل عام. انظر systemd.service_watchdogs أعلاه.

أُضيف في الإصدارة 237.

--default-standard-output=, --default-standard-error=

يضبط المخرجات المبدئية أو مخرجات الخطأ المبدئية لكل الخدمات والمقابس على التوالي. انظر systemd.default_standard_output= و systemd.default_standard_error= أعلاه.

عصر ساعة النظام¶

عند بدء تشغيل systemd أو إعادة تشغيله، قد يضبط ساعة النظام على "العصر" (epoch). تُستخدم هذه الآلية لضمان بقاء ساعة النظام مهيئة بشكل معقول ومتزايدة بانتظام (monotonic) تقريباً عبر عمليات إعادة التشغيل، في حال عدم توفر ساعة وقت حقيقي (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(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 أصبحت مهجورة. يرجى الانتقال إلى التسلسل الهرمي الموحد لـ cgroup.

انظر أيضًا¶

الصفحة الرئيسية لـ systemd[9]، systemd-system.conf(5)، locale.conf(5)، systemctl(1)، 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].

ملاحظات¶

1.: وعد استقرار وقابلية نقل الواجهة

https://systemd.io/PORTABILITY_AND_STABILITY/

2.: واجهة الحاويات

https://systemd.io/CONTAINER_INTERFACE

3.: واجهة initrd

https://systemd.io/INITRD_INTERFACE/

4.: مجموعات التحكم النسخة 2

https://docs.kernel.org/admin-guide/cgroup-v2.html

5.: مواصفة دليل XDG الأساسي

https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

6.: يوصى للأدوات الأخرى بضبط والتحقق من $SUDO_UID حسب الاقتضاء، ومعاملته كواجهة مشتركة.
7.: متغيرات البيئة المعروفة

https://systemd.io/ENVIRONMENT

8.: بيانات اعتماد النظام والخدمة

https://systemd.io/CREDENTIALS

9.: الصفحة الرئيسية لـ systemd

https://systemd.io/

10.: وثيقة التصميم الأصلية

https://0pointer.de/blog/projects/systemd.html

ترجمة¶

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.

systemd 260.1

Source file:	systemd.1.ar.gz (from man-pages-ar 4.30.2-1.1)
Source last updated:	2026-05-15T16:18:45Z
Converted to HTML:	2026-05-17T00:59:57Z