Scroll to navigation

SYSTEMD.GENERATOR(7) systemd.generator SYSTEMD.GENERATOR(7)

الاسم

systemd.generator - مولّدات وحدات systemd

موجز

/path/to/generator normal-dir [early-dir] [late-dir]

/run/systemd/system-generators/*
/etc/systemd/system-generators/*
/usr/local/lib/systemd/system-generators/*
/usr/lib/systemd/system-generators/*

/run/systemd/user-generators/*
/etc/systemd/user-generators/*
/usr/local/lib/systemd/user-generators/*
/usr/lib/systemd/user-generators/*

الوصف

المولّدات هي برامج تنفيذية صغيرة موضوعة في /usr/lib/systemd/system-generators/ وأدلة أخرى مذكورة أعلاه. systemd(1) ينفّذ هذه البرامج الثنائية مبكرًا جدًا عند الإقلاع وعند إعادة تحميل الإعدادات — قبل تحميل ملفات الوحدات. غرضها الرئيس هو تحويل معاملات الإعدادات وسياق التنفيذ غير الأصلية لمدير الخدمة إلى ملفات وحدات مولّدة ديناميكيًا، أو روابط رمزية، أو إضافات ملفات وحدات، بحيث يمكنها توسيع تسلسل ملفات الوحدات الذي يقوم مدير الخدمة بتحميله والعمل عليه لاحقًا.

systemd يستدعي كل مولّد مع ثلاثة مسارات أدلة تُستخدم لمخرجات المولّد. في هذه الأدلة الثلاثة، يمكن للمولّدات أن تولّد ديناميكيًا ملفات وحدات (عادية، ونماذج، بالإضافة إلى قوالب)، وإضافات .d/ لملفات الوحدات، وإنشاء روابط رمزية لملفات الوحدات لإضافة تبعيات إضافية، أو إنشاء أسماء مستعارة، أو إنشاء مثيلات من القوالب الموجودة. هذه الأدلة مضمنة في مسار تحميل الوحدات، مما يسمح للإعدادات المولّدة بتوسيع التعريفات الموجودة أو تجاوزها. للاختبارات، قد يُستدعى المولّد بحجة واحدة فقط؛ يجب على المولّد افتراض أن جميع المسارات الثلاثة متطابقة في هذه الحالة.

المولّدات المنفّذة من قبل مدير النظام تُستدعى في صندوق حماية مع دليل /tmp/ خاص قابل للكتابة وحيث معظم نظام الملفات للقراءة فقط باستثناء أدلة مخرجات المولّد.

مسارات الأدلة لمخرجات المولّد تختلف حسب الأولوية: .../generator.early له أولوية أعلى من إعدادات المسؤول في /etc/، بينما .../generator له أولوية أقل من /etc/ لكن أعلى من إعدادات البائع في /usr/، و .../generator.late له أولوية أقل من جميع الإعدادات الأخرى. انظر القسم التالي ونقاش مسارات تحميل الوحدات وتجاوز الوحدات في systemd.unit(5).

المولّدات تُحمّل من مجموعة مسارات محدّدة أثناء التجميع، كما هو مذكور أعلاه. مولّدات النظام والمستخدم تُحمّل من أدلة بأسماء تنتهي بـ system-generators/ و user-generators/، على التوالي. المولّدات الموجودة في الأدلة المذكورة سابقًا تتجاوز تلك التي تحمل نفس الاسم في الأدلة الأدنى في القائمة [1]. رابط رمزي إلى /dev/null أو ملف فارغ يمكن استخدامه لإخفاء مولّد، وبالتالي منعه من التشغيل. يُرجى ملاحظة أن ترتيب الدليلين ذوي الأولوية الأعلى معكوس بالنسبة لمسار تحميل الوحدات، والمولّدات في /run/ تستبدل تلك الموجودة في /etc/.

بعد تثبيت مولّدات جديدة أو تحديث الإعدادات، يمكن تنفيذ systemctl daemon-reload. هذا يحذف الإعدادات السابقة التي أنشأتها المولّدات، ويعيد تشغيل جميع المولّدات، ويجعل systemd يعيد تحميل الوحدات من القرص. انظر systemctl(1) لمزيد من المعلومات.

أدلة المخرجات

المولّدات تُستدعى مع ثلاث وسائط: مسارات إلى أدلة حيث يمكن للمولّدات وضع ملفات الوحدات المولّدة أو الروابط الرمزية. افتراضيًا، هذه المسارات هي أدلة وقت تشغيل مضمنة في مسار البحث لـ systemd، لكن قد يُستدعى المولّد بمسارات مختلفة لأغراض التصحيح. إذا تم توفير وسيطة واحدة فقط، يجب على المولّد استخدام نفس الدليل كمسارات المخرجات الثلاثة.

1.normal-dir

في الاستخدام العادي هذا هو /run/systemd/generator في حالة مولّدات النظام و $XDG_RUNTIME_DIR/systemd/generator في حالة مولّدات المستخدم. ملفات الوحدات الموضوعة في هذا الدليل لها أولوية على إعدادات وحدات البائع لكن ليس على إعدادات وحدات المستخدم/المسؤول الأصلية.

2.early-dir

في الاستخدام العادي هذا هو /run/systemd/generator.early في حالة مولّدات النظام و $XDG_RUNTIME_DIR/systemd/generator.early في حالة مولّدات المستخدم. ملفات الوحدات الموضوعة في هذا الدليل تتجاوز ملفات الوحدات في /usr/ و /run/ و /etc/. هذا يعني أن ملفات الوحدات الموضوعة في هذا الدليل لها أولوية على جميع الإعدادات العادية، سواء البائع أو المستخدم/المسؤول.

3.late-dir

في الاستخدام العادي هذا هو /run/systemd/generator.late في حالة مولّدات النظام و $XDG_RUNTIME_DIR/systemd/generator.late في حالة مولّدات المستخدم. هذا الدليل يمكن استخدامه لتوسيع شجرة ملفات الوحدات دون تجاوز أي ملفات وحدات أخرى. أي ملفات إعدادات أصلية مقدمة من البائع أو المستخدم/المسؤول لها أولوية.

ملاحظة: يجب ألا تكتب المولدات إلى مواقع أخرى أو تُجري تغييرات أخرى على حالة النظام. من المفترض أن يستمر ناتج المولد فقط حتى إعادة تحميل الخفي daemon-reload أو إعادة تنفيذ الخفي daemon-reexec التالية؛ إذا تم استبدال المولد أو إخفاؤه، يجب أن تختفي تأثيراته.

البيئة

يُعيّن مدير الخدمة عددًا من متغيرات البيئة عند استدعاء ملفات المولدات القابلة للتنفيذ. تحمل هذه المتغيرات معلومات حول سياق تنفيذ المولد، وذلك لتبسيط تكييف المولدات مع بيئات محددة. تُعيّن متغيرات البيئة التالية:

$SYSTEMD_SCOPE

إذا تم استدعاء المولد من مدير خدمات النظام، يُعيّن هذا المتغير إلى "system"؛ إذا تم استدعاؤه من مدير خدمات لكل مستخدم، يُعيّن إلى "user".

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

$SYSTEMD_IN_INITRD

إذا تم تشغيل المولد كجزء من initrd، يُعيّن هذا إلى "1". إذا تم تشغيله من المضيف العادي (أي بعد الانتقال من initrd إلى المضيف)، يُعيّن إلى "0". يُعيّن متغير البيئة هذا فقط لمولدات النظام.

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

$SYSTEMD_SOFT_REBOOTS_COUNT

إذا تم إعادة تشغيل النظام بشكل ناعم، يُعيّن هذا المتغير إلى عدد عمليات إعادة التشغيل الناعمة. يُعيّن متغير البيئة هذا فقط لمولدات النظام.

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

$SYSTEMD_FIRST_BOOT

إذا كانت دورة الإقلاع هذه تُعتبر "إقلاعًا أول"، يُعيّن هذا إلى "1"؛ إذا كانت إقلاعًا لاحقًا عاديًا، يُعيّن إلى "0". للتفاصيل، انظر توثيق ConditionFirstBoot= في systemd.unit(5). يُعيّن متغير البيئة هذا فقط لمولدات النظام.

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

$SYSTEMD_VIRTUALIZATION

إذا تم تشغيل مدير الخدمة في بيئة افتراضية، يُعيّن $SYSTEMD_VIRTUALIZATION إلى زوج من السلاسل، مفصولة بنقطتين. السلسلة الأولى إما "vm" أو "container"، تُصنف نوع الافتراضية. السلسلة الثانية تُحدد تطبيق تقنية الافتراضية. إذا لم يتم اكتشاف أي افتراضية، لن يُعيّن هذا المتغير. هذه البيانات مطابقة لما يكتشفه ويُبلغ عنه systemd-detect-virt(1)، وتستخدم نفس مفردات معرفات تطبيق الافتراضية.

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

$SYSTEMD_ARCHITECTURE

يُعيّن هذا المتغير إلى معرف قصير للهندسة المعمارية المُبلغ عنها للنظام. للتفاصيل حول القيم المُحددة، انظر توثيق ConditionArchitecture= في systemd.unit(5).

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

$CREDENTIALS_DIRECTORY، $ENCRYPTED_CREDENTIALS_DIRECTORY

إذا تم تعيينه، يُشير إلى الدليل الذي وُضعت فيه بيانات اعتماد النظام. ستُوضع بيانات الاعتماد المُمررة إلى النظام في شكل نص عادي في $CREDENTIALS_DIRECTORY، وتلك المُمررة في شكل مشفر ستُوضع في $ENCRYPTED_CREDENTIALS_DIRECTORY. استخدم الأمر systemd-creds(1) لفك تشفير/الاستيثاق آليًا لبيانات الاعتماد المُمررة، إذا لزم الأمر. تحديدًا، استخدم الأمر systemd-creds --system cat.

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

$SYSTEMD_CONFIDENTIAL_VIRTUALIZATION

إذا تم تشغيل مدير الخدمة في بيئة افتراضية سرية، يُعيّن $SYSTEMD_CONFIDENTIAL_VIRTUALIZATION إلى سلسلة تُحدد تقنية عتاد الافتراضية السرية. إذا لم يتم اكتشاف أي افتراضية سرية، لن يُعيّن هذا المتغير. هذه البيانات مطابقة لما يكتشفه ويُبلغ عنه systemd-detect-virt(1)، وتستخدم نفس مفردات معرفات تقنية الافتراضية السرية.

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

ملاحظات حول كتابة المولدات

•تُنفذ جميع المولدات بالتوازي. هذا يعني أن جميع الملفات القابلة للتنفيذ تُبدأ في نفس الوقت تمامًا وتحتاج إلى القدرة على التعامل مع هذا التوازي.

•تُشغل المولدات في وقت مبكر جدًا عند الإقلاع ولا يمكنها الاعتماد على أي خدمات خارجية. لا يجوز لها التحدث إلى أي عملية أخرى. يشمل ذلك أشياء بسيطة مثل التسجيل في syslog(3)، أو systemd نفسه (هذا يعني: لا systemctl(1))! تُوصل أنظمة الملفات غير الأساسية مثل /var/ و /home/ بعد تشغيل المولدات. ومع ذلك، يمكن للمولدات الاعتماد على توفر وظائف النواة الأساسية، بالإضافة إلى أنظمة الملفات المُوصلة /sys/ و /proc/ و /dev/ و /usr/ و /run/.

•تُزال الوحدات التي كتبتها المولدات عند إعادة تحميل التهيئة. هذا يعني أن عمر الوحدات المُولدة مرتبط ارتباطًا وثيقًا بدورات إعادة تحميل systemd نفسه.

•يجب استخدام المولدات فقط لتوليد ملفات الوحدات، وإضافات .d/*.conf لها، وروابط رمزية إليها، وليس أي نوع آخر من التهيئة غير المرتبطة بالوحدات. بسبب منطق دورة الحياة المذكور أعلاه، ليست المولدات مناسبة لتوليد تهيئة ديناميكية للخدمات الأخرى. إذا كنت بحاجة إلى توليد تهيئة ديناميكية لخدمات أخرى، فافعل ذلك في خدمات عادية تُرتّبها قبل الخدمة المعنية.

لاحظ أنه باستخدام إعدادات StandardInputData=/StandardInputText= لملفات وحدات الخدمة (انظر systemd.exec(5))، من الممكن جعل بيانات إدخال عشوائية (بما في ذلك تهيئة خاصة بالخفي) جزءًا من تعريفات الوحدة، والتي قد تكون غالبًا كافية لتضمين بيانات أو تهيئة لبرامج أخرى في ملفات الوحدة بطريقة أصلية.

•نظرًا لأن syslog(3) غير متوفر (انظر أعلاه)، يجب كتابة رسائل السجل إلى /dev/kmsg بدلاً من ذلك.

•يجب أن يتضمن المولد دائمًا اسمه الخاص في تعليق في أعلى الملف المُولد، حتى يتمكن المستخدم من معرفة المكون الذي أنشأ أو عدّل وحدة معينة بسهولة.

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

•قد تكتب المولدات ملفات وحدات ديناميكية أو فقط تربط ملفات الوحدات بوحدات أخرى باستخدام الروابط الرمزية المعتادة .wants/ أو .requires/. غالبًا، من الأجمل ببساطة إنشاء مثيل لملف وحدة قالب من /usr/ باستخدام مولد بدلاً من كتابة ملفات وحدات ديناميكية بالكامل. بالطبع، يعمل هذا فقط إذا كان سيتم استخدام معامل واحد.

•إذا كنت حريصًا، يمكنك تنفيذ المولدات في نصوص شل. ومع ذلك، نوصي باستخدام كود C، نظرًا لأن المولدات تُنفذ بشكل متزامن وبالتالي تُؤخر الإقلاع بأكمله إذا كانت بطيئة.

•بخصوص دلالات التجاوز: هناك قاعدتان نحاول اتباعهما عند التفكير في دلالات التجاوز:

1.يجب أن تتجاوز تهيئة المستخدم تهيئة البائع. هذا (في الغالب) يعني أن الأشياء من /etc/ يجب أن تتجاوز الأشياء من /usr/.

2.يجب أن تتجاوز التهيئة الأصلية التهيئة غير الأصلية. هذا (في الغالب) يعني أن الأشياء التي تُولدها يجب ألا تتجاوز أبدًا ملفات الوحدات الأصلية لنفس الغرض.

من بين هاتين القاعدتين، القاعدة الأولى هي الأكثر أهمية على الأرجح، وتنتهك القاعدة الثانية أحيانًا. لذلك، عند تحديد ما إذا كنت ستستخدم argv[1] أو argv[2] أو argv[3]، فاختيارك المبدئي ينبغي أن يكون argv[1].

•بدلاً من الانطلاق الآن وكتابة جميع أنواع المولدات لتنسيقات ملفات الإعداد القديمة، يُرجى التفكير مليًا! غالبًا ما تكون فكرة أفضل أن تُهمل الأشياء القديمة بدلاً من إبقائها حية بشكل مصطنع.

أمثلة

مثال 1. systemd-fstab-generator

systemd-fstab-generator(8) يحول /etc/fstab إلى وحدات وصل أصلية. يستخدم argv[1] كموقع لوضع ملفات الوحدات المُنشأة للسماح للمستخدم بتجاوز /etc/fstab بملفات الوحدات الأصلية الخاصة به، ولكن أيضًا لضمان تجاوز /etc/fstab لأي إعداد مبدئي من البائع من /usr/.

بعد تحرير /etc/fstab، ينبغي على المستخدم استدعاء systemctl daemon-reload. هذا يُعيد تشغيل جميع المولدات ويُجبر systemd على إعادة تحميل الوحدات من القرص. لوصل الدلائل الجديدة المُضافة إلى fstab فعليًا، يمكن استخدام systemctl start /path/to/mountpoint أو systemctl start local-fs.target.

مثال 2. systemd-system-update-generator

systemd-system-update-generator(8) يُعيد توجيه default.target مؤقتًا إلى system-update.target، إذا كان تحديث النظام مُجدولاً. نظرًا لأن هذا يحتاج إلى تجاوز إعداد المستخدم المبدئي لـ default.target، فإنه يستخدم argv[2]. للتفاصيل حول هذا المنطق، انظر systemd.offline-updates(7).

المثال 3. تنقيح مولد

dir=$(mktemp -d)
SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/system-generators/systemd-fstab-generator \


        "$dir" "$dir" "$dir"
find $dir

انظر أيضًا

systemd(1), systemd-cryptsetup-generator(8), systemd-debug-generator(8), systemd-fstab-generator(8), fstab(5), systemd-getty-generator(8), systemd-gpt-auto-generator(8), systemd-hibernate-resume-generator(8), systemd-system-update-generator(8), systemd-xdg-autostart-generator(8), systemd.unit(5), systemctl(1), systemd.environment-generator(7)

ملاحظات

1.
💣💥🧨💥💥💣 يرجى ملاحظة أن ملفات الضبط تلك يجب أن تكون متوفرة في جميع الأوقات. إذا كان /usr/local/ قسماً منفصلاً، فقد لا يكون متوفراً أثناء بدء التشغيل المبكر، ويجب عدم استخدامه للضبط.

ترجمة

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

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

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

systemd 261~rc3