| SYSTEMD-NOTIFY(1) | systemd-notify | SYSTEMD-NOTIFY(1) |
نام (NAME)
systemd-notify - اطلاعرسانی به مدیر سرویس درباره تکمیل راهاندازی و سایر تغییرات وضعیت دیمن
خلاصه دستور (SYNOPSIS)
systemd-notify [OPTIONS...] [VARIABLE=VALUE...]
systemd-notify --exec [OPTIONS...] [VARIABLE=VALUE...] ; -- {CMDLINE...}
systemd-notify --fork [OPTIONS...] -- {CMDLINE...}
توضیحات (DESCRIPTION)
systemd-notify میتواند توسط اسکریپتهای سرویس فراخوانی شود تا تغییرات وضعیت را به مدیر سرویس فراخواننده اطلاع دهد. این ابزار میتواند برای ارسال اطلاعات دلخواه، کدگذاریشده در قالبی شبیه به فهرست رشتههای بلوک متغیرهای محیطی، استفاده شود. مهمتر از همه، میتوان از آن برای اعلان تکمیل راهاندازی استفاده کرد.
این ابزار در واقع عمدتاً یک پوسته (wrapper) پیرامون sd_notify() است و این قابلیت را در دسترس اسکریپتهای پوسته قرار میدهد. برای جزئیات sd_notify(3) را ببینید.
خط فرمان ممکن است حاوی فهرستی از متغیرهای محیطی باشد تا به عنوان بخشی از بهروزرسانی وضعیت ارسال شوند.
توجه داشته باشید که سیستمدی از پذیرش بهروزرسانیهای وضعیت از این دستور خودداری خواهد کرد مگر اینکه NotifyAccess= بهطور مناسب برای واحد سرویسی که این دستور از آن فراخوانی میشود تنظیم شده باشد. برای جزئیات systemd.service(5) را ببینید.
توجه داشته باشید که اعلانهای sd_notify() تنها در صورتی میتوانند به درستی به واحدها منتسب شوند که فرآیند ارسالکننده در زمان پردازش پیام توسط مدیر سرویس هنوز فعال باشد، یا اینکه فرآیند ارسالکننده صراحتاً در زمان اجرا توسط مدیر سرویس ردیابی شود. حالت دوم زمانی رخ میدهد که مدیر سرویس در ابتدا فرآیند را منشعب (fork) کرده باشد، یعنی در تمام فرآیندهایی که با NotifyAccess=main یا NotifyAccess=exec مطابقت دارند. برعکس، اگر یک فرآیند کمکیِ واحد پیامی از طریق sd_notify() ارسال کند و بلافاصله خارج شود، مدیر سرویس ممکن است نتواند پیام را به درستی به آن واحد منتسب کند و بنابراین آن را نادیده خواهد گرفت، حتی اگر NotifyAccess=all برای آن تنظیم شده باشد. برای رفع این مشکل، systemd-notify تا زمانی که پیام اعلان توسط مدیر سرویس پردازش شود منتظر خواهد ماند. هنگامی که --no-block استفاده شود، این همگامسازی برای دریافت اعلانها غیرفعال میگردد و از این رو ممکن است شرایط رقابتی (race condition) یادشده رخ دهد، در صورتی که فرآیند فراخواننده، خودِ مدیر سرویس نبوده یا توسط مدیر سرویس ایجاد نشده باشد.
systemd-notify ابتدا تلاش خواهد کرد تا با وانمود کردن به داشتن PID فرآیند والدِ systemd-notify (یعنی فرآیند فراخواننده)، sd_notify() را فراخوانی کند. این کار تنها زمانی موفقیتآمیز خواهد بود که با دسترسیها و اختیارات کافی فراخوانی شده باشد. در صورت عدم موفقیت، سپس به فراخوانی آن با PID خود بازمیگردد. این رفتار از این جهت مفید است که وقتی این ابزار از یک اسکریپت پوسته فراخوانی میشود، فرآیند پوسته — و نه فرآیند systemd-notify — به عنوان فرستنده پیام ظاهر میشود؛ که این به نوبه خود، به دلیل محدودیتهای NotifyAccess=all، در صورتی که فرآیند پوسته فرآیند اصلی یک سرویس باشد، مفید خواهد بود. از سوییچ --pid= برای دستکاری این رفتار استفاده کنید.
گزینهها (OPTIONS)
گزینههای زیر پشتیبانی میشوند:
--ready
--reloading
افزوده شده در نسخه 253.
--stopping
افزوده شده در نسخه 253.
--pid=
systemd-notify ابتدا تلاش خواهد کرد تا با وانمود کردن به داشتن PID مشخصشده با --pid=، sd_notify() را فراخوانی کند. این کار تنها در صورتی موفقیتآمیز خواهد بود که با اختیارات کافی فراخوانی شده باشد. در صورت عدم موفقیت، سپس به فراخوانی آن با PID خود بازمیگردد. در عمل، این بدان معناست که یک فراخوانی ممتاز از systemd-notify --pid= ممکن است محدودیتهای اعمالشده NotifyAccess=main یا NotifyAccess=exec برای یک سرویس را دور بزند.
اگر این سوییچ در یک فراخوانی بدون اختیارات ممتاز از systemd-notify توسط فرآیندی استفاده شود که قرار است فرآیند اصلی جدید یک سرویس باشد — و آن فرآیند توسط مدیر سرویس منشعب نشده باشد (یا فرآیند اصلی فعلی نباشد) —، در این صورت ضروری است که NotifyAccess=all در فایل واحد سرویس تنظیم شود، در غیر این صورت به دلایل امنیتی اعلان نادیده گرفته خواهد شد. برای جزئیات systemd.service(5) را ببینید.
--uid=USER
افزوده شده در نسخه 237.
--status=
--booted
--no-block
افزوده شده در نسخه 246.
--exec
توجه داشته باشید که بسیاری از پوستهها ";" را به عنوان جداکننده خط فرمان خود تفسیر میکنند، بنابراین زمانی که systemd-notify از یک پوسته فراخوانی میشود، نقطه ویرگول معمولاً باید به صورت "\;" گریز داده شود (escaped).
افزوده شده در نسخه 254.
--fd=
برای استفاده از این قابلیت از یک پوسته bash(1)، از عبارتی مانند زیر استفاده کنید:
systemd-notify --fd=4 --fd=5 4</some/file 5</some/other/file
افزوده شده در نسخه 254.
--fdname=
افزوده شده در نسخه 254.
--fork
توجه داشته باشید فرآیندهایی که بدین شکل منشعب میشوند احتمالاً پس از آنکه systemd-notify قبلاً بازگشته است همچنان در حال اجرا باقی خواهند ماند، که در نتیجه منجر به این میشود که والد جدید آنها نزدیکترین فرآیند دروگر (process reaper)، یعنی معمولاً مدیر سرویس به ازای هر کاربر یا مدیر سرویس سراسری سیستم شود.
توجه داشته باشید که این گزینه نباید برای فراخوانی موقت سرویسهای کامل استفاده شود، برای این کار از systemd-run استفاده کنید.
همچنین توجه داشته باشید که در صورت فراخوانی با این سوییچ، systemd-notify تحت دو شرایط متمایز با موفقیت خارج خواهد شد:
نمونه استفاده:
# PID=$(systemd-notify --fork -- mycommand) ... kill "$PID" unset PID
افزوده شده در نسخه 258.
--quiet, -q
افزوده شده در نسخه 258.
-h, --help
--version
کدهای خروج (EXIT STATUS)
در صورت موفقیت، 0 برگردانده میشود؛ در غیر این صورت یک کد خطای غیر صفر برگردانده خواهد شد.
مثالها (EXAMPLES)
مثال 1. اعلان راهاندازی و بهروزرسانیهای وضعیت
یک دیمن ساده پوسته که پس از آمادهسازی کانال ارتباطی خود، اعلانهای راهاندازی را ارسال میکند. در طول زمان اجرا بهروزرسانیهای وضعیت بیشتری را به سیستم init ارسال میکند:
#!/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
همچنین ببینید (SEE ALSO)
systemd(1), systemctl(1), systemd.unit(5), systemd.service(5), sd_notify(3), sd_booted(3)
| systemd 261.2 |