نام (NAME)

systemd-run - اجرای برنامه‌ها در واحدهای موقت scope، واحدهای service، یا واحدهای service راه‌اندازی‌شده با path، socket یا timer

خلاصه دستور (SYNOPSIS)

systemd-run [OPTIONS...] COMMAND [ARGS...]

systemd-run [OPTIONS...] [PATH OPTIONS...] {COMMAND [ARGS...]}

systemd-run [OPTIONS...] [SOCKET OPTIONS...] {COMMAND [ARGS...]}

systemd-run [OPTIONS...] [TIMER OPTIONS...] {COMMAND [ARGS...]}

توضیحات (DESCRIPTION)

systemd-run می‌تواند برای ایجاد و راه‌اندازی یک واحد موقت .service یا .scope و اجرای COMMAND مشخص‌شده در آن استفاده شود. همچنین می‌تواند برای ایجاد و راه‌اندازی یک واحد موقت .path، .socket یا .timer استفاده شود که هنگام سپری شدن زمان یا وقوع رویداد، یک واحد .service را فعال می‌کند.

اگر دستوری به عنوان واحد سرویس موقت اجرا شود، مانند هر سرویس دیگری توسط مدیر سرویس راه‌اندازی و مدیریت خواهد شد و بنابراین مانند هر واحد دیگری در خروجی systemctl list-units نمایش داده می‌شود. این دستور در یک محیط اجرایی تمیز و تفکیک‌شده، با مدیر سرویس به عنوان فرآیند والد خود اجرا خواهد شد. در این حالت، systemd-run سرویس را به صورت ناهمگام در پس‌زمینه راه‌اندازی می‌کند و پس از اینکه دستور اجرای خود را آغاز کرد بازمی‌گردد (مگر اینکه --no-block، --wait، --pipe یا --pty مشخص شده باشند، زیر را ببینید).

اگر دستوری به عنوان واحد scope موقت اجرا شود، توسط خود systemd-run به عنوان فرآیند والد اجرا خواهد شد و بنابراین محیط اجرایی فراخواننده را به ارث می‌برد. با این حال، فرآیندهای دستور مانند سرویس‌های عادی توسط مدیر سرویس مدیریت می‌شوند و در خروجی systemctl list-units نمایش داده خواهند شد. اجرا در این حالت همگام است و تنها زمانی بازمی‌گردد که دستور به پایان برسد. این حالت از طریق سوئیچ --scope فعال می‌شود (زیر را ببینید).

اگر دستوری با گزینه‌های path، socket یا timer مانند --on-calendar= (زیر را ببینید) اجرا شود، یک واحد موقت path، socket یا timer در کنار واحد سرویس برای دستور مشخص‌شده ایجاد می‌شود. تنها واحد موقت path، socket یا timer بلافاصله راه‌اندازی می‌شود و واحد سرویس موقت توسط واحد path، socket یا timer برانگیخته (trigger) خواهد شد. اگر گزینه --unit= مشخص شده باشد، COMMAND می‌تواند حذف شود. در این حالت، systemd-run تنها یک واحد .path، .socket یا .timer ایجاد می‌کند که واحد مشخص‌شده را برمی‌انگیزد.

به طور پیش‌فرض، سرویس‌های ایجادشده با systemd-run دارای نوع پیش‌فرض simple هستند، برای جزئیات به توضیحات Type= در systemd.service(5) مراجعه کنید. توجه داشته باشید که در صورت استفاده از این نوع، مدیر سرویس (و بنابراین دستور systemd-run) راه‌اندازی سرویس را به محض موفقیت‌آمیز بودن fork() برای فرآیند اصلی سرویس، یعنی پیش از فراخوانی execve()، موفقیت‌آمیز تلقی می‌کند و در نتیجه حتی در صورتی که دستور مشخص‌شده نتواند راه‌اندازی شود نیز چنین در نظر می‌گیرد. استفاده از نوع سرویس exec (یعنی --property=Type=exec) را در نظر داشته باشید تا اطمینان حاصل شود که systemd-run تنها در صورتی با موفقیت بازمی‌گردد که خط فرمان مشخص‌شده با موفقیت راه‌اندازی شده باشد.

پس از اینکه systemd-run دستور را به مدیر سرویس تحویل می‌دهد، مدیر گسترش متغیرها (variable expansion) را انجام می‌دهد. این بدان معناست که نویسه‌های دلار ("$") که نباید گسترش یابند باید به صورت "$$" گریز (escape) داده شوند. گسترش را می‌توان با استفاده از --expand-environment=no نیز غیرفعال کرد.

گزینه‌ها (OPTIONS)

گزینه‌های زیر پشتیبانی می‌شوند:

--scope

--unit=, -u

--property=, -p

--description=

--slice=

--slice-inherit

--expand-environment=BOOL

-r, --remain-after-exit

--send-sighup

--service-type=

--uid=, --gid=

--nice=

--working-directory=

--same-dir, -d

--root-directory=

--same-root-dir, -R

-E NAME[=VALUE], --setenv=NAME[=VALUE]

--pty, -t

--pty-late, -T

--pipe, -P

--shell, -S

--quiet, -q

-v, --verbose

--output=

--on-active=, --on-boot=, --on-startup=, --on-unit-active=, --on-unit-inactive=

--on-calendar=

--on-clock-change, --on-timezone-change

--path-property=, --socket-property=, --timer-property=

--no-block

--wait

-G, --collect

--job-mode=MODE

--ignore-failure

--background=COLOR

--user

--system

-H, --host=

-M, --machine=

-C, --capsule=

--no-ask-password

-h, --help

--version

--json=MODE

--no-pager

--json= نباید با --scope، --pty، --pty-late، --pipe، --verbose، یا گزینه‌های path، socket یا timer ترکیب شود.

تمام آرگومان‌های خط فرمان پس از نخستین آرگومان غیرگزینه‌ای، بخشی از خط فرمان فرآیند راه‌اندازی‌شده می‌شوند.

کدهای خروج (EXIT STATUS)

در صورت موفقیت، 0 بازگردانده می‌شود. اگر systemd-run در راه‌اندازی سرویس ناموفق باشد، یک مقدار بازگشتی غیرصفر برگردانده خواهد شد. اگر systemd-run منتظر خاتمه سرویس بماند، مقدار بازگشتی از سرویس منتقل خواهد شد. در صورت موفقیت 0 بازگردانده می‌شود، از جمله در تمامی مواردی که سیستم‌دی خروج سرویس را تمیز در نظر می‌گیرد؛ بررسی SuccessExitStatus= در systemd.service(5) را ببینید.

مثال‌ها (EXAMPLES)

مثال ۱. لاگ کردن متغیرهای محیطی ارائه‌شده توسط systemd به سرویس‌ها

# systemd-run env
Running as unit: run-19945.service
# journalctl -u run-19945.service
Sep 08 07:37:21 bupkis systemd[1]: Starting /usr/bin/env...
Sep 08 07:37:21 bupkis systemd[1]: Started /usr/bin/env.
Sep 08 07:37:21 bupkis env[19948]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
Sep 08 07:37:21 bupkis env[19948]: LANG=en_US.UTF-8
Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.x86_64

مثال ۲. محدود کردن منابع در دسترس یک دستور

# systemd-run -p IOWeight=10 updatedb

این دستور ابزار updatedb(8) را فراخوانی می‌کند، اما وزن I/O بلوکی را برای آن به 10 کاهش می‌دهد. برای اطلاعات بیشتر درباره ویژگی IOWeight= به systemd.resource-control(5) مراجعه کنید.

مثال ۳. اجرای دستورات در زمانی مشخص

دستور زیر یک فایل را پس از ۳۰ ثانیه لمس (touch) می‌کند.

# date; systemd-run --on-active=30 --timer-property=AccuracySec=100ms /bin/touch /tmp/foo
Mon Dec  8 20:44:24 KST 2014
Running as unit: run-71.timer
Will run service as unit: run-71.service
# journalctl -b -u run-71.timer
-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. --
Dec 08 20:44:38 container systemd[1]: Starting /bin/touch /tmp/foo.
Dec 08 20:44:38 container systemd[1]: Started /bin/touch /tmp/foo.
# journalctl -b -u run-71.service
-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. --
Dec 08 20:44:48 container systemd[1]: Starting /bin/touch /tmp/foo...
Dec 08 20:44:48 container systemd[1]: Started /bin/touch /tmp/foo.

مثال ۴. اجازه دسترسی به tty

دستور زیر bash(1) را به عنوان یک سرویس فراخوانی می‌کند و ورودی، خروجی و خطای استاندارد آن را به TTY فراخواننده منتقل می‌نماید.

# systemd-run -t --send-sighup bash

مثال ۵. راه‌اندازی screen به عنوان یک سرویس کاربری

$ systemd-run --scope --user screen
Running scope as unit run-r14b0047ab6df45bfb45e7786cc839e76.scope.
$ screen -ls
There is a screen on:
        492..laptop     (Detached)
1 Socket in /var/run/screen/S-fatima.

این دستور فرآیند screen را به عنوان فرزندی از فرآیند systemd --user که توسط user@.service راه‌اندازی شده است، در یک واحد scope شروع می‌کند. یک واحد systemd.scope(5) به جای واحد systemd.service(5) استفاده می‌شود، زیرا screen هنگام جدا شدن از ترمینال خارج می‌شود و یک واحد سرویس در این صورت خاتمه می‌یافت. اجرای screen به عنوان یک واحد کاربری این مزیت را دارد که بخشی از اسکوپ نشست (session scope) نیست. اگر KillUserProcesses=yes در logind.conf(5) پیکربندی شده باشد (پیش‌فرض "no" است)، با خروج کاربر از آن نشست، اسکوپ نشست خاتمه خواهد یافت.

واحد user@.service هنگامی که کاربر برای نخستین بار وارد سیستم می‌شود به طور خودکار راه‌اندازی می‌شود، و تا زمانی که دست‌کم یک نشست ورود باز باشد فعال می‌ماند. پس از خروج کاربر از آخرین نشست، user@.service و تمامی سرویس‌های زیرمجموعه آن خاتمه می‌یابند. این رفتار در صورتی که «ماندگاری» (lingering) برای آن کاربر فعال نشده باشد پیش‌فرض است. فعال کردن ماندگاری به این معنی است که user@.service در حین بوت به طور خودکار راه‌اندازی می‌شود، حتی اگر کاربر وارد سیستم نشده باشد، و با خروج کاربر از سیستم، سرویس خاتمه نمی‌یابد.

فعال کردن ماندگاری به کاربر اجازه می‌دهد فرآیندها را بدون وارد شدن به سیستم اجرا کند، برای مثال به منظور اجازه دادن به screen برای تداوم پس از خروج کاربر از سیستم، حتی اگر اسکوپ نشست خاتمه یابد. در پیکربندی پیش‌فرض، کاربران می‌توانند ماندگاری را برای خود فعال کنند:

$ loginctl enable-linger

مثال ۶. گسترش متغیرها توسط مدیر

$ systemd-run -t echo "<${INVOCATION_ID}>" '<${INVOCATION_ID}>'
      <> <5d0149bfa2c34b79bccb13074001eb20>

آرگومان نخست توسط پوسته گسترش می‌یابد (نقل‌قول‌های دوتایی)، اما آرگومان دوم توسط پوسته گسترش نمی‌یابد (نقل‌قول‌های تکی). echo(1) با آرایه آرگومان ["/usr/bin/echo", "<>", "<${INVOCATION_ID}>"] فراخوانی می‌شود، و سپس systemd(1) متغیر ${INVOCATION_ID} را تولید کرده و آن را در خط فرمان جایگزین می‌کند. این جایگزینی نمی‌توانست در سمت کلاینت انجام شود، زیرا شناسه هدفی که برای سرویس تنظیم خواهد شد پیش از برقراری تماس مشخص نیست.

مثال ۷. گسترش متغیرها و تغییر مسیر خروجی با استفاده از یک پوسته

گسترش متغیرها توسط systemd(1) می‌تواند با --expand-environment=no غیرفعال شود.

غیرفعال کردن گسترش متغیرها می‌تواند زمانی مفید باشد که دستور مورد نظر برای اجرا حاوی نویسه‌های دلار است و گریز (escape) دادن آن‌ها نامناسب یا دشوار باشد. به عنوان مثال، هنگامی که از یک پوسته استفاده می‌شود:

$ systemd-run --expand-environment=no -t bash \
      -c 'echo $SHELL $$ >/dev/stdout'
/bin/bash 12345

آرگومان آخر عیناً به پوسته bash(1) که توسط واحد سرویس راه‌اندازی شده است منتقل می‌شود. پوسته "$SHELL" را به مسیر پوسته، و "$$" را به شماره فرآیند خود گسترش می‌دهد، و سپس آن رشته‌ها به دستور توکار echo منتقل شده و در خروجی استاندارد چاپ می‌شوند (که در این مورد، به ترمینال فراخواننده متصل است).

مثال ۸. مقدار بازگشتی

$ systemd-run --user --wait true
$ systemd-run --user --wait -p SuccessExitStatus=11 bash -c 'exit 11'
$ systemd-run --user --wait -p SuccessExitStatus=SIGUSR1 --expand-environment=no \
      bash -c 'kill -SIGUSR1 $$'

هر سه فراخوانی بالا با موفقیت انجام خواهند شد، یعنی با کد خروج 0 خاتمه می‌یابند.

همچنین ببینید (SEE ALSO)

systemd(1), systemctl(1), systemd.unit(5), systemd.service(5), systemd.scope(5), systemd.slice(5), systemd.exec(5), systemd.resource-control(5), systemd.timer(5), systemd-mount(1), machinectl(1), run0(1)

نکات (NOTES)

1.

کدهای فرار ANSI (ویکی‌پدیا)