Scroll to navigation

SYSTEMD-NOTIFY(1) systemd-notify SYSTEMD-NOTIFY(1)

الاسم

systemd-notify - إعلام مدير الخدمة باكتمال بدء التشغيل وتغييرات حالة الخفي الأخرى

موجز

systemd-notify [خيارات...] [متغير=قيمة...]

systemd-notify --exec [خيارات...] [متغير=قيمة...] ; -- {سطر أوامر...}

systemd-notify --fork [خيارات...] -- {سطر أوامر...}

الوصف

قد يُستدعى systemd-notify بواسطة نصوص الخدمة لإعلام مدير الخدمة المستدعي بتغييرات الحالة. يمكن استخدامه لإرسال معلومات عشوائية، مشفرة في قائمة سلاسل تشبه كتلة البيئة. الأهم من ذلك، يمكن استخدامه لإعلام اكتمال بدء التشغيل.

هذا في الغالب مجرد غلاف حول sd_notify() ويجعل هذه الوظيفة متاحة لنصوص الصدفة. للتفاصيل انظر sd_notify(3).

قد يحمل سطر الأوامر قائمة من متغيرات البيئة لإرسالها كجزء من تحديث الحالة.

لاحظ أن systemd سيرفض استقبال تحديثات الحالة من هذا الأمر ما لم يتم تعيين NotifyAccess= بشكل مناسب لوحدة الخدمة التي يُستدعى منها هذا الأمر. انظر systemd.service(5) للتفاصيل.

لاحظ أن إشعارات sd_notify() قد تُنسب إلى الوحدات بشكل صحيح فقط إذا كانت العملية المرسلة لا تزال موجودة في الوقت الذي يعالج فيه مدير الخدمة الرسالة، أو إذا كانت العملية المرسلة مُتتبعة وقت التشغيل بشكل صريح من قبل مدير الخدمة. الحالة الأخيرة تكون إذا قام مدير الخدمة أصلاً بتفرع العملية، أي على جميع العمليات التي تطابق NotifyAccess=main أو NotifyAccess=exec. بالمقابل، إذا أرسلت عملية مساعدة للوحدة رسالة sd_notify() وخرجت فوراً، قد لا يتمكن مدير الخدمة من نسب الرسالة إلى الوحدة بشكل صحيح، وبالتالي سيتجاهلها، حتى لو تم تعيين NotifyAccess=all لها. لمعالجة هذا، سينتظر systemd-notify حتى تتم معالجة رسالة الإشعار من قبل مدير الخدمة. عند استخدام --no-block، يتم تعطيل هذا التزامن لاستقبال الإشعارات، وبالتالي قد يحدث السباق المذكور أعلاه إذا لم تكن العملية المستدعية هي مدير الخدمة أو مولدة من قبله.

سيحاول systemd-notify أولاً استدعاء sd_notify()() متظاهراً بأن لديه PID العملية الأم لـ systemd-notify (أي العملية المستدعية). سينجح هذا فقط عند الاستدعاء بصلاحيات كافية. عند الفشل، سيعود بعد ذلك إلى استدعائها تحت PID الخاص به. هذا السلوك مفيد بحيث عندما يتم استدعاء الأداة من نص صدفة، تظهر عملية الصدفة — وليس عملية systemd-notify — كمرسل للرسالة، وهذا بدوره مفيد إذا كانت عملية الصدفة هي العملية الرئيسية لخدمة، بسبب قيود NotifyAccess=all. استخدم المفتاح --pid= لضبط هذا السلوك.

الخيارات

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

--ready

أبلغ مدير الخدمة المستدعي باكتمال بدء تشغيل الخدمة أو إعادة تحميل التهيئة. هذا مكافئ لـ systemd-notify READY=1. للتفاصيل حول دلالات هذا الخيار انظر sd_notify(3).

--reloading

أبلغ مدير الخدمة المستدعي ببدء دورة إعادة تحميل التهيئة. هذا مكافئ لـ systemd-notify RELOADING=1 (لكنه يحدد أيضًا ضمنياً حقل MONOTONIC_USEC= كما هو مطلوب لخدمات Type=notify-reload، انظر systemd.service(5) للتفاصيل). للتفاصيل حول دلالات هذا الخيار انظر sd_notify(3).

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

--stopping

أبلغ مدير الخدمة المستدعي ببدء مرحلة إيقاف الخدمة. هذا مكافئ لـ systemd-notify STOPPING=1. للتفاصيل حول دلالات هذا الخيار انظر sd_notify(3).

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

--pid=

أبلغ مدير الخدمة عن PID الرئيسي للخدمة. يأخذ PID كوسيط. إذا تم تحديد الوسيط كـ "auto" أو تم حذفه، يُستخدم PID العملية التي استدعت systemd-notify، إلا إذا كان ذلك هو مدير الخدمة. إذا تم تحديد الوسيط كـ "self"، يُستخدم PID أمر systemd-notify نفسه، وإذا تم تحديد "parent" يُستخدم PID العملية المستدعية — حتى لو كان مدير الخدمة. --pid=auto مكافئ لـ systemd-notify --pid=$PID. للتفاصيل حول دلالات هذا الخيار انظر sd_notify(3).

سيحاول systemd-notify أولاً استدعاء sd_notify()() متظاهراً بأن لديه PID المحدد مع --pid=. سينجح هذا فقط عند الاستدعاء بصلاحيات كافية. عند الفشل، سيعود بعد ذلك إلى استدعائها تحت PID الخاص به. فعلياً، هذا يعني أن استدعاءً متميزاً لـ systemd-notify --pid= قد يتجاوز قيود NotifyAccess=main أو NotifyAccess=exec المفروضة لخدمة.

إذا تم استخدام هذا المفتاح في استدعاء غير متميز لـ systemd-notify من عملية ستصبح العملية الرئيسية الجديدة لخدمة — وهي ليست العملية المفرعة من قبل مدير الخدمة (أو العملية الرئيسية الحالية) —، فمن الضروري تعيين NotifyAccess=all في ملف وحدة الخدمة، وإلا سيتم تجاهل الإشعار لأسباب أمنية. انظر systemd.service(5) للتفاصيل.

--uid=مستخدم

عيّن معرف المستخدم لإرسال الإشعار منه. يأخذ اسم مستخدم UNIX أو UID رقمي. عند التحديد، سيتم إرسال رسالة الإشعار مع UID المحدد كمرسل، بدلاً من المستخدم الذي تم استدعاء الأمر باسمه. يتطلب هذا الخيار صلاحيات كافية لتتمكن من معالجة هوية المستخدم للعملية.

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

--status=

أرسل سلسلة حالة قابلة للقراءة البشرية حرة الشكل للخفي إلى مدير الخدمة. يأخذ هذا الخيار سلسلة الحالة كوسيط. هذا مكافئ لـ systemd-notify STATUS=.... للتفاصيل حول دلالات هذا الخيار انظر sd_notify(3). تُعرض هذه المعلومات في مخرج status لأمر systemctl(1)، من بين أماكن أخرى.

--booted

يُرجع 0 إذا تم إقلاع النظام مع systemd، غير صفرية بخلاف ذلك. إذا تم تمرير هذا الخيار، لا يتم إرسال أي رسالة. هذا الخيار بالتالي غير مرتبط بالخيارات الأخرى. للتفاصيل حول دلالات هذا الخيار، انظر sd_booted(3). طريقة بديلة للتحقق من هذه الحالة هي استدعاء systemctl(1) مع الأمر is-system-running. سيخرج "offline" إذا لم يتم إقلاع النظام مع systemd، على الرغم من أن قيمة الإرجاع لها معنى مختلف.

--no-block

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

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

--exec

إذا تم تحديده، سينفذ systemd-notify سطر أوامر آخر بعد إكمال عمليته، مستبدلاً عمليته الخاصة. إذا تم استخدامه، يجب أن تتبع قائمة التعيينات المراد تضمينها في الرسالة المرسلة بحرف ";" (كوسيط منفصل)، متبوعاً بسطر الأوامر المراد تنفيذه. هذا يسمح بـ "تسلسل

يرجى ملاحظة أن العديد من برامج الصدفة تفسر ”؛“ على أنه الفاصل الخاص بها في سطور الأوامر؛ ولذلك، عند استدعاء systemd-notify من برنامج صدفة، يجب عادةً تغيير رمز الفاصلة المنقوطة إلى ”\;“.

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

--fd=

إرسال واصف ملف مع رسالة الإشعار. وهذا مفيد عند الاستدعاء في الخدمات التي تم تمكين الإعداد FileDescriptorStoreMax= فيها، انظر systemd.service(5) للحصول على التفاصيل. يجب تمرير واصف الملف المحدد إلى systemd-notify عند الاستدعاء. يمكن استخدام هذا الخيار عدة مرات لتمرير عدة واصفات ملفات في رسالة إعلام واحدة.

لاستخدام هذه الوظيفة من محطة عمل bash(1)، استخدم تعبيرًا مثل التالي:

systemd-notify --fd=4 --fd=5 4</some/file 5</some/other/file

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

--fdname=

يضبط اسماً لتعيينه لموصّفات الملفات الممررة عبر --fd= (انظر أعلاه). يتحكم هذا في حقل "FDNAME=". لا يُحدد هذا الإعداد إلا مرة واحدة، وينطبق على جميع موصّفات الملفات الممررة. استدعِ هذه الأداة عدة مرات في حال وجب إرسال موصّفات ملفات متعددة بأسماء موصّفات ملفات مختلفة.

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

--fork

بدلاً من إرسال رسالة إشعار، يتفرع عن سطر أوامر وينتظر حتى استلام رسالة "READY=1" منه. بعبارة أخرى: يجعل هذا systemd-notify مستقبلاً لرسائل الإشعار بدلاً من المرسل، مبادلاً الأدوار. هذا مفيد للتفرع السريع عن عملية تنفذ بروتوكول sd_notify() من سكريبت شل. سيكون لسطر الأوامر المستدعى إدخال قياسي وإخراج قياسي متصلين بـ /dev/null، لكن الخطأ القياسي سيورث من العملية المستدعية. يُكتب معرف العملية الرقمي إلى الإخراج القياسي بواسطة systemd-notify (ما لم يُحدد --quiet)، والذي قد يُستخدم لإنهاء العملية المتفرعة عنها لاحقًا.

لاحظ أن العمليات المتفرعة عنها هكذا ستبقى على الأرجح قيد التشغيل بعد أن عاد systemd-notify بالفعل، مما سيؤدي بالتالي إلى إعادة تبعيتها لأقرب عملية حصادة عمليات، أي عادةً مدير الخدمات لكل مستخدم أو النظام.

لاحظ أن هذا الخيار لا ينبغي استخدامه لاستدعاء خدمات كاملة بشكل مؤقت، استخدم systemd-run لذلك.

لاحظ أيضًا أنه عند استدعائه بهذا المفتاح، سيخرج systemd-notify بنجاح في حالتين مميزتين:

1.استلم systemd-notify إشعار "READY=1" من العملية الابنة التي تفرع عنها للتو.

2.خرجت العملية الابنة بشكل نظيف (بحالة خروج صفرية) قبل إرسال "READY=1".

مثال استخدام:

# PID=$(systemd-notify --fork -- mycommand)
...
kill "$PID"
unset PID

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

--quiet،‏ -q

يُطفئ إخراج معرف العملية الرقمي عند استخدام --fork.

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

-h، --help

اطبع نص مساعدة قصير واخرج.

--version

اطبع سلسلة إصدار قصيرة واخرج.

حالة الخروج

عند النجاح، يُعاد الرقم 0، وإلا فيُعاد رمز فشل غير صفري.

مثال

مثال 1. إشعار بدء التشغيل وتحديثات الحالة

خفي شل بسيط يرسل إشعارات بدء التشغيل بعد إعداد قناة الاتصال الخاصة به. أثناء وقت التشغيل يرسل تحديثات حالة إضافية إلى نظام التهيئة:

#!/bin/sh
mkfifo /tmp/waldo
systemd-notify --ready --status="Waiting for data..."
while : ; do

read -r a < /tmp/waldo
systemd-notify --status="Processing $a"
# Do something with $a ...
systemd-notify --status="Waiting for data..." done

انظر أيضًا

systemd(1), systemctl(1), systemd.unit(5), systemd.service(5), sd_notify(3), sd_booted(3)

ترجمة

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

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

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

systemd 260.1