table of contents
SYSTEMCTL(1) | systemctl | SYSTEMCTL(1) |
НАЗВА¶
systemctl — керування системою systemd та засіб керування службами
КОРОТКИЙ ОПИС¶
systemctl [ПАРАМЕТРИ...] КОМАНДА [МОДУЛЬ...]
ОПИС¶
systemctl можна використати для інтроспекції і керування станом «systemd» і засобом керування службами. Будь ласка, зверніться до systemd(1), щоб ознайомитися із вступом до базових понять та функціональними можливостями, якими керує цей інструмент.
КОМАНДИ¶
Передбачено обробку таких команд:
Команди модулів (інтроспекція і модифікація)¶
list-units [ВЗІРЕЦЬ...]
Зауважте, що ця команда не показує шаблонів модулів, але лише екземпляри шаблонів модулів. Шаблони модулів, які не матимуть екземплярів, не є придатними до запуску, отже, їх ніколи не буде показано у даних, які виведено цією командою. Це, зокрема, значить, що щось@.service ніколи не буде показано у цьому списку, якщо у нього не буде екземплярів, наприклад щось@десь.service. Скористайтеся командою list-unit-files (див. нижче), щоб отримати список встановлених файлів шаблонів модулів.
Виводити дані, подібні до таких:
UNIT LOAD ACTIVE SUB DESCRIPTION
sys-module-fuse.device loaded active plugged /sys/module/fuse
-.mount loaded active mounted Root Mount
boot-efi.mount loaded active mounted /boot/efi
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service ● user@1000.service loaded failed failed User Manager for UID 1000
...
systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories LOAD = Повідомляє, чи було успішно завантажено визначення модуля. ACTIVE = Стан активації модуля верхнього рівня, тобто узагальнення SUB. SUB = Стан активації модуля нижнього рівня, значення залежать від типу модуля. 123 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'.
Заголовок і останній модуль заданого типу буде підкреслено, якщо у терміналі передбачено підтримку цього. Поряд із пунктом служб, які було замасковано, які не було знайдено, та тих, які є помилковими з інших причин, буде показано кольорову крапку.
У стовпчику LOAD буде показано стан завантаження, одне із таких значень: loaded, not-found, bad-setting, error, masked. У стовпчиках ACTIVE буде показано загальний стан модуля, одне з таких значень: active, reloading, inactive, failed, activating, deactivating. У стовпчику SUB буде показано специфічний до типу модуля докладний стан модуля, можливі значення залежать від типу модуля. Список можливих станів LOAD, ACTIVE і SUB не є сталим. У нових випусках systemd може бути додано або вилучено значення.
systemctl --state=help
командою можна скористатися для показу поточного набору можливих значень.
Це типова команда.
list-automounts [ВЗІРЕЦЬ...]
WHAT WHERE MOUNTED IDLE TIMEOUT UNIT /dev/sdb1 /mnt/test no 120s mnt-test.automount binfmt_misc /proc/sys/fs/binfmt_misc yes 0 proc-sys-fs-binfmt_misc.automount 2 automounts listed.
Див. також --show-types, --all і --state=.
Додано у версії 252.
list-paths [ВЗІРЕЦЬ...]
PATH CONDITION UNIT ACTIVATES /run/systemd/ask-password DirectoryNotEmpty systemd-ask-password-plymouth.path systemd-ask-password-plymouth.service /run/systemd/ask-password DirectoryNotEmpty systemd-ask-password-wall.path systemd-ask-password-wall.service /var/cache/cups/org.cups.cupsd PathExists cups.path cups.service 3 paths listed.
Див. також --show-types, --all і --state=.
Додано у версії 254.
list-sockets [ВЗІРЕЦЬ...]
LISTEN UNIT ACTIVATES /dev/initctl systemd-initctl.socket systemd-initctl.service ... [::]:22 sshd.socket sshd.service kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service 5 sockets listed.
Зауваження: через те, що в адресах можуть міститися пробіли, виведені дані можуть бути незручними для програмної обробки.
Див. також --show-types, --all і --state=.
Додано у версії 202.
list-timers [ВЗІРЕЦЬ...]
NEXT LEFT LAST PASSED UNIT ACTIVATES - - Thu 2017-02-23 13:40:29 EST 3 days ago ureadahead-stop.timer ureadahead-stop.service Sun 2017-02-26 18:55:42 EST 1min 14s left Thu 2017-02-23 13:54:44 EST 3 days ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Sun 2017-02-26 20:37:16 EST 1h 42min left Sun 2017-02-26 11:56:36 EST 6h ago apt-daily.timer apt-daily.service Sun 2017-02-26 20:57:49 EST 2h 3min left Sun 2017-02-26 11:56:36 EST 6h ago snapd.refresh.timer snapd.refresh.service
NEXT показує час наступного запуску таймера.
LEFT показує, скільки лишилося до наступного запуску таймера.
LAST показує останній момент часу, коли було запущено таймер.
PASSED показує, скільки часу минуло з моменту останнього запуску таймера.
UNIT показує назву таймера
ACTIVATES показує назву служби, яку активує таймер, коли його запущено.
Див. також --all і --state=.
Додано у версії 209.
is-active ВЗІРЕЦЬ...
is-failed [ВЗІРЕЦЬ...]
Додано у версії 197.
status [ВЗІРЕЦЬ...|PID...]]
Цю функцію призначено для створення зручних для читання даних. Якщо вам потрібні дані, які просто обробляти на комп'ютері, скористайтеся замість неї show. Типово, ця функція виводить лише 10 рядків даних і обриває рядки багатокрапкою так, щоб вони вміщалися у вікно термінала. Змінити це можна за допомогою параметрів --lines і --full, див. вище. Крім того, journalctl --unit=НАЗВА або journalctl --user-unit=НАЗВА використовують подібне фільтрування для повідомлень, і можуть бути зручнішими.
Зауважте, що у результаті цієї дії буде показано лише динамічний стан, тобто дані щодо поточного виклику модуля (якщо його запущено) або найостаннішого виклику (якщо він уже не працює і його пам'ять не було звільнено). Відомості щодо попередніх викликів, викликів під час попередніх запусків системи або попередніх викликів, пам'ять яких вже було звільнено, можна отримати за допомогою команди journalctl --unit=.
За потреби, systemd завантажує модулі неявним чином, тому запуск status призведе до спроби завантажити файл. Тому ця команда не придатна для перевірки того, чи вже завантажено щось. Також можливий випадок, коли модулі буде швидко вивантажено одразу після завершення дії, якщо немає потреби тримати їх у пам'яті після неї.
Приклад 1. Приклад виведення systemctl status
$ systemctl status bluetooth ● bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago
Docs: man:bluetoothd(8)
Main PID: 930 (bluetoothd)
Status: "Running"
Tasks: 1
Memory: 648.0K
CPU: 435ms
CGroup: /system.slice/bluetooth.service
└─930 /usr/lib/bluetooth/bluetoothd Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service Jan 12 10:46:45 example.com bluetoothd[8900]: Current Time Service could not be registered Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5)
Для крапки («●») у терміналах із підтримкою кольорів буде використано колір для того, щоб стан модуля був помітним з першого погляду. Разом із кольором змінюватиметься форма, відповідно до стану: для станів «неактивний» та «супровід» буде показано біле коло («○»), для стану «активний» — зелену крапку («●»), для стану «деактивація» — білу крапку, для стану «помилка» — червоний хрестик («×»), а для стану «перезавантаження» — зелену кругову стрілку за годинниковою стрілкою («↻»).
У рядку «Loaded:» виведених даних буде показано «loaded», якщо модуль було завантажено до пам'яті. Іншими можливими значеннями для «Loaded:» є такі: «error», якщо виникла проблема під час завантаження; «not-found», якщо не було знайдено файл модуля; «bad-setting», якщо не вдалося обробити критичний параметр файла модуля, і «masked», якщо файл модуля було замасковано. Разом із показом шляху до файла модуля, у цьому рядку також буде показано стан вмикання. Увімкнені модулі буде включено до мережі залежностей між модулями, а тому буде запущено під час завантаження або за допомогою якихось інших форм активації. Із повною таблицею можливих станів вмикання, разом із визначенням терміна «masked», можна ознайомитися у документації з команди is-enabled.
У рядку «Active:» буде показано стан активності. Значенням, зазвичай, є «active» (активний) або «inactive» (неактивний). Активний стан може означати «запущено», «пов'язано», «увімкнено» тощо, залежно від типу модуля. Модуль може також перебувати у процесі зміни станів, повідомляючи про стан «activating» (активація) або «deactivating» (деактивація). Спеціальний стан «failed» буде показано, якщо робота служби завершилася якоюсь помилкою, зокрема аварійно, у результаті виходу з кодом помилки або перевищення часу очікування. Якщо модуль увійде до стану помилки, причину буде записано до журналу для подальшого вивчення.
show [ВЗІРЕЦЬ...|ЗАВДАННЯ...]
Багато властивостей, значення яких виводить systemctl show безпосередньо пов'язано із параметрами налаштувань системи та засобу керування службами та його файлами модулів. Зауважте, що властивості, які виведено цією командою, загалом, є нижчого рівня, нормалізованими версіями початкових параметрів налаштувань, і вказують на динамічний стан на додачу до налаштувань. Наприклад, властивості, які виведено для модулів служб, включають поточний ідентифікатор основного процесу служби як «MainPID» (динамічний стан), а параметри часу завжди виводяться як властивості із кінцевим суфіксом «...USec», навіть якщо відповідні параметри налаштувань мають назви, які закінчуються на «...Sec», оскільки мікросекунди є нормалізованою одиницею часу, яку на внутрішньому рівні використовує система на засіб керування службами.
Докладніший опис багатьох цих властивостей можна знайти у документації до базового компонента цих властивостей, інтерфейсу D-Bus, див. org.freedesktop.systemd1(5).
cat ВЗІРЕЦЬ...
Додано у версії 209.
help ВЗІРЕЦЬ...|PID...
Додано у версії 185.
list-dependencies [МОДУЛЬ...]
Показані модулі буде додатково фільтровано з використанням --type= та --state=, якщо вказано ці параметри. Зауважте, що ми не зможемо скористатися у цьому випадку ієрархічною структурою, отже неявним чином буде використано --plain.
Типово, буде рекурсивно розгорнуто лише модулі призначення. Якщо буде передано параметр --all, також буде рекурсивно розгорнуто усі інші модулі.
Змінити типи показаних залежностей можна за допомогою параметрів --reverse, --after, --before.
Зауважте, що ця команда виводить список лише тих модулів, які у поточний момент завантажено до пам'яті засобом керування службами. Зокрема, ця команда непридатна для отримання повного списку щодо усіх зворотних залежностей певного модуля, оскільки вона не виводить залежностей, які оголошено модулями і у поточний момент не завантажено.
Додано у версії 198.
start ВЗІРЕЦЬ...
Зауважте, що взірці назв модулів із символами-замінниками розгортаються до назв модулів, які зараз перебувають в оперативній пам'яті. Модулі, які є неактивними і не перебувають у стані помилки, зазвичай, не перебувають у пам'яті, отже, для них не буде встановлено відповідності жодному взірцю. Крім того, у випадку модулів із екземплярами systemd часто не знає назви екземпляра до запуску цього екземпляра. Отже, використання взірців із символами-замінниками у start не дуже-то й корисне. Крім того, вторинні назви-альтернативи модулів не буде взято до уваги.
Для роботи із неактивними модулями, на які посилаються інші завантажені модулі, можна також скористатися параметром --all. Зауважте, що це не те саме, що працювати із «усіма» можливими модулями, оскільки, як про це вже написано у попередньому абзаці, такий список є некоректним. Втім, systemctl start --all ВЗІРЕЦЬ може бути корисним, якщо усі модулі, які слід знайти за шаблоном, запускаються певною ціллю, про яку відомо, що її буде завантажено.
stop ВЗІРЕЦЬ...
Виконання цієї команди завершиться помилкою, якщо модуля не існує або якщо зупинення модуля заборонено (див. RefuseManualStop= у systemd.unit(5)). Виконання не завершиться помилкою, якщо виконання будь-якої з команд, які налаштовано для зупинення модуля (ExecStop= тощо), завершиться помилкою, оскільки засіб керування все одно примусово зупинить роботу модуля.
Якщо модуль, який зупиняється, може бути увімкнено іншими модулями, буде показано попередження зі списком назв відповідних модулів. Можна скористатися --no-warn для придушення попередження.
reload ВЗІРЕЦЬ...
Цю команду не слід плутати із командою daemon-reload.
restart ВЗІРЕЦЬ...
Зауважте, що перезапуск модуля за допомогою цієї команди не обов'язково скине усі ресурси модуля, перш ніж його буде знову запущено. Наприклад, сховище дескрипторів файлів окремої служби (див. FileDescriptorStoreMax= in systemd.service(5)) лишиться незмінним, доки завдання модуля перебуватиме у черзі обробки — його буде очищено, коли роботу модуля буде повністю зупинено, і у нього не лишиться завдань у черзі. Якщо треба скинути і сховище дескрипторів файлів, під час дії з перезапуску слід віддати явно команду systemctl stop, а потім команду systemctl start.
try-restart ВЗІРЕЦЬ...
reload-or-restart ВЗІРЕЦЬ...
try-reload-or-restart ВЗІРЕЦЬ...
Додано у версії 229.
isolate МОДУЛЬ
Ця команда є небезпечною, оскільки вона негайно припиняє роботу процесів, які не увімкнено у новій цілі, можливо, разом із графічним середовищем або терміналом, яким ви користуєтеся на момент виконання команди.
Зауважте, що ця дія є можливою лише для модулів, для яких увімкнено AllowIsolate=. Див. systemd.unit(5), щоб дізнатися більше.
kill ВЗІРЕЦЬ...
clean ВЗІРЕЦЬ...
Додано у версії 243.
freeze ВЗІРЕЦЬ...
Заморожування модуля спричинить призупинення усіх процесів, які місяться у cgroup, що відповідає модулю. Призупинення означає, що процеси модуля не буде заплановано для виконання на центральному процесорі, доки модуль не буде розморожено. Зауважте, що підтримку цієї команди передбачено лише на системах, які використовують уніфіковану ієрархію cgroup. Модуль буде автоматично розморожено одразу перед виконанням завдання щодо модуля, наприклад, перед тим, як модуль буде зупинено.
Додано у версії 246.
thaw ВЗІРЕЦЬ...
Це обернена дія до команди freeze, і вона відновлює виконання процесів для cgroup модуля.
Додано у версії 246.
set-property МОДУЛЬ ВЛАСТИВІСТЬ=ЗНАЧЕННЯ...
Приклад: systemctl set-property foobar.service CPUWeight=200
Якщо вказаний модуль виглядає неактивним, зміни буде збережено на лише диску, як це описано раніше, отже вони набудуть чинності, коли модуль буде запущено.
Зауважте, що за допомогою цієї команди можна змінити декілька властивостей одночасно. Це пріоритетніший спосіб за встановлення значень кожної властивості окремою командою.
Приклад: systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G IPAccounting=yes
Подібно параметрам налаштування у файлі модуля, встановлення порожнього значення скидає властивість до типового значення.
Приклад: systemctl set-property avahi-daemon.service IPAddressDeny=
Додано у версії 206.
bind МОДУЛЬ ШЛЯХ [ШЛЯХ]
Зауважте, що підтримку цього параметра у поточній версії передбачено лише для модулів, які запущено у просторі назв монтування (приклади: RootImage=, PrivateMounts= тощо). У цій команді передбачено підтримку монтування каталогів, звичайних файлів, вузлів пристроїв, вузлів сокетів AF_UNIX, а також FIFO з прив'язкою. Монтування з прив'язкою є недовговічним, його можна скасувати, щойно роботу поточного процесу модуля буде завершено. Зауважте, що згаданий тут простір назв, до якого буде додано монтування з прив'язкою, є простором назв, у якому працює основний процес служби. Інші процеси (ті, які виконуються ExecReload=, ExecStartPre= тощо) працюють в окремих просторах назв.
Якщо у ядрі передбачено відповідну підтримку, усі попередні монтування до вибраної цілі буде замінено новим монтуванням. Якщо такої підтримки не передбачено, усі попередні монтування буде змонтовано повторно, але монтування лишатиметься пришпиленим і недоступним.
Додано у версії 248.
mount-image МОДУЛЬ ОБРАЗ [ШЛЯХ [НАЗВА_РОЗДІЛУ:ПАРАМЕТРИ_МОНТУВАННЯ]]
Зауважте, що підтримку цього параметра у поточній версії передбачено лише для модулів, які запущено у просторі назв монтування (приклади: RootImage=, PrivateMounts= тощо). Зауважте, що згаданий тут простір назв, до якого буде додано монтування з прив'язкою, є простором назв, у якому працює основний процес служби. Інші процеси (ті, які виконуються ExecReload=, ExecStartPre= тощо) працюють в окремих просторах назв.
Якщо у ядрі передбачено відповідну підтримку, усі попередні монтування до вибраної цілі буде замінено новим монтуванням. Якщо такої підтримки не передбачено, усі попередні монтування буде змонтовано повторно, але монтування лишатиметься пришпиленим і недоступним.
Приклад:
systemctl mount-image foo.service /tmp/img.raw /var/lib/image root:ro,nosuid
systemctl mount-image --mkdir bar.service /tmp/img.raw /var/lib/baz/img
Додано у версії 248.
service-log-level СЛУЖБА [РІВЕНЬ]
Якщо вказано додатковий аргумент РІВЕНЬ, змінити поточний рівень журналювання служби на РІВЕНЬ. Рівнем журналювання має бути типовий рівень журналювання syslog, тобто значення у діапазоні 0...7 або один з таких рядків: emerg, alert, crit, err, warning, notice, info, debug; див. syslog(3), щоб дізнатися більше.
Служба повинна мати відповідну властивість BusName=призначення, а також реалізовувати загальний інтерфейс org.freedesktop.LogControl1(5). (systemctl скористається загальним протоколом D-Bus для доступу до інтерфейсу org.freedesktop.LogControl1.LogLevel для назви D-Bus призначення.)
Додано у версії 247.
service-log-target СЛУЖБА [ЦІЛЬ]
Якщо надано додатковий аргумент ЦІЛЬ, змінити поточну ціль журналювання служби на ЦІЛЬ. Ціллю журналювання має бути один з таких рядків: console (щоб записувати виведені дані до стандартного потоку помилок служби), kmsg (щоб записувати виведення журналу до буфера журналу ядра), journal (щоб записувати виведення журналу до systemd-journald.service(8) за допомогою власного протоколу журналу), syslog (щоб записувати виведення журналу до класичного сокета syslog /dev/log), null (щоб не записувати виведення журналу нікуди) або auto (щоб автоматично вибирати варіант, типово, еквівалент console, якщо службу викликано інтерактивно, і journal або syslog в інших випадках).
Для більшості служб має сенс використання лише незначної підмножини цілей журналювання. Зокрема, більшість «звичайних» служб мають реалізовувати лише console, journal і null. Усе інше стосується лише низькорівневих служб, які є активними на дуже ранніх етапах завантаження системи, до того, як буде встановлено належне журналювання.
Служба повинна мати відповідну властивість BusName=призначення, а також реалізовувати загальний інтерфейс org.freedesktop.LogControl1(5). (systemctl скористається загальним протоколом D-Bus для доступу до інтерфейсу org.freedesktop.LogControl1.LogLevel для назви D-Bus призначення.)
Додано у версії 247.
reset-failed [ВЗІРЕЦЬ...]
На додачу до скидання стану «failed» модуля команда також скидає різноманітні інші властивості для окремого модуля: обмежувальний лічильник запуску для модулів усіх типів буде скинуто до нуля, як і лічильник перезапуску модулів служб. Таким чином, якщо досягнуто обмеження на запуск модуля (як його налаштовано за допомогою StartLimitIntervalSec=/StartLimitBurst=), і модуль не вдається запустити знову, скористайтеся цією командою, щоб зробити модуль знову придатним до запуску.
whoami [PID...]
Додано у версії 254.
Команди файла модуля¶
list-unit-files [ВЗІРЕЦЬ...]
На відміну від list-units, ця команда виводить список шаблонів модулів, окрім модулів із явними екземплярами.
Додано у версії 233.
enable МОДУЛЬ..., enable ШЛЯХ...
Цій команді слід передавати або коректні назви модулів (у цьому випадку буде виконано пошук файлів модулів із відповідними назвами у різноманітних каталогах файлів модулів), або абсолютні шляхи до файлів модулів (у цьому випадку файли буде прочитано безпосередньо). Якщо вказаний файл модуля розташовано поза звичайними каталогами файлів модулів, буде створено додаткове символічне посилання, які пов'язуватиме його із каталогом налаштувань модулів, а отже, забезпечуватиме можливість знайти його у відповідь на запит команд, подібних до start. Файлова система, де зберігаються пов'язані файли модулів, має бути доступною на момент запуску systemd (наприклад, не можна зберігати такі файли у /home/ або /var/, якщо цих каталогів немає у кореневій файловій системі).
Ця команда виводить список виконаних із файловою системою дій. Виведення даних можна придушити за допомогою параметра --quiet.
Зауважте, що ця дія створює лише символічні посилання, які запропоновано у розділі [Install] файлів модулів. Хоча ця команда є рекомендованим способом керування каталогом налаштувань модулів, адміністратор може вносити додаткові зміни вручну, створюючи або вилучаючи символічні посилання у цьому каталозі. Такі дії можуть знадобитися для створення налаштувань, які відрізняються від пропонованих у типовому комплекті для встановлення. Якщо буде внесено такі зміни, адміністратор має, за потреби, викликати daemon-reload вручну, щоб забезпечити врахування внесених змін.
При використанні цієї дії над модулями без даних щодо встановлення, буде показано попередження щодо цього. Можна скористатися --no-warn для придушення попередження.
Вмикання модулів не слід плутати із запуском (активацією) модулів, який виконує команда start. Вмикання і запуск модулів є зовсім різними речима: модулі може бути увімкнено без запуску і запущено без вмикання. Вмикання лише вписує модуль у різноманітні відповідні місця (наприклад, робить так, щоб модуль автоматично запускався під час завантаження системи або з'єднання з комп'ютером певного типу обладнання). Запуск ініціалізує процес фонової служби (у випадку модулів служб) або пов'язує модуль із сокетом (у випадку модулів сокетів) тощо.
Залежно від того, чи вказано --system, --user, --runtime або --global, ця команда вмикає модуль для системи, лише для користувача, який її віддав, лише на одне завантаження системи або для усіх наступних входів до системи усіх користувачів. Зауважте, що в останньому випадку не буде перезавантажено налаштування фонових служб systemd.
Підтримки команди enable для замаскованих модулів не передбачено. Якщо віддати цю команду для замаскованого модуля, буде повідомлено про помилку.
disable МОДУЛЬ...
Цій команді можна передавати лише назви чинних модулів, вона не приймає шляхи до файлів модулів.
Окрім модулів, які буде вказано як аргументи, буде вимкнено усі модулі зі списку у параметрі Also= розділу [Install] усіх файлів модулів, з якими працюватиме програма.
Ця команда неявним чином перезавантажує налаштування засобу керування системою після завершення виконання дії. Зауважте, що ця команда не виконує неявного зупинення модулів, які було вимкнено. Якщо потрібно зупинити роботу таких модулів, або поєднайте цю команду із перемикачем --now, або потім викличте команду stop із відповідними аргументами.
Ця команда виводить відомості щодо виконаних із файловою системою дій (вилучення символічних посилань). Виведення даних можна придушити за допомогою параметра --quiet.
Якщо модуль вимикають, але модулі, які можуть його увімкнути лишатимуться активними, буде показано попередження зі списком назв відповідних модулів. Можна скористатися --no-warn для придушення попередження.
Цю команду використовують з --user. Модулі, з якими вона працює, може бути увімкнено у загальній області видимості, а отже, запущено автоматично навіть після успішного вимикання в області видимості користувача. У цьому випадку буде виведено попередження, яке можна придушити за допомогою --no-warn.
Ця команда враховує --system, --user, --runtime, --global та --no-warn у спосіб, подібний до enable.
Додано у версії 238.
reenable МОДУЛЬ...
Додано у версії 238.
preset МОДУЛЬ...
Скористайтеся параметром --preset-mode= для керування тим, має бути модулі увімкнено і вимкнено, лише вимкнено чи лише вимкнено.
Якщо у модулі не вказано даних щодо встановлення, його буде без попереджень проігноровано під час виконання цієї команди. Значенням аргументу МОДУЛЬ має бути дійсна назва модуля, усі альтернативні назви буде без попереджень проігноровано.
Щоб дізнатися більше про формат правил набору налаштувань, ознайомтеся зі сторінкою підручника щодо systemd.preset(5).
Додано у версії 238.
preset-all
Скористайтеся параметром --preset-mode= для керування тим, має бути модулі увімкнено і вимкнено, лише вимкнено чи лише вимкнено.
Додано у версії 215.
is-enabled МОДУЛЬ...
Таблиця 1.
Виведення
is-enabled
Назва | Опис | Код виходу |
"увімкнено" | Увімкнено за допомогою символічних посилань .wants/, .requires/ або Alias= (остаточно в /etc/systemd/system/ або тимчасово у /run/systemd/system/). | 0 |
"увімкнено-робота" | ||
"пов'язано" | Стає доступним через одне або декілька символічних посилань на файл модуля (остаточно в /etc/systemd/system/ або тимчасово у /run/systemd/system/), навіть якщо файл модуля може зберігатися поза шляхом пошуку файлів модулів. | > 0 |
"linked-runtime" | ||
"alias" | Назва альтернативи (символічного посилання на файл іншого модуля). | 0 |
"masked" | Повністю вимкнено так, що будь-яка дія із запуску завершиться помилкою (остаточно в /etc/systemd/system/ або тимчасово у /run/systemd/systemd/). | > 0 |
"masked-runtime" | ||
"static" | Файл модуля не увімкнено і немає умов для вмикання його у розділі [Install] файла модуля. | 0 |
"indirect" | Сам файл модуля не увімкнено, але він містить непорожній запис Also= у розділі [Install] файла модуля, де вказано список інших файлів модулів, які може бути увімкнено, або у нього є альтернатива на основі символічного посилання із іншою назвою, яку не вказано у Also=. Для файлів шаблонів модулів буде увімкнено екземпляр, відмінний від того, який вказано у DefaultInstance= is enabled. | 0 |
"disabled" | Файл модуля не увімкнено, але у ньому міститься розділ [Install] із настановами щодо встановлення. | > 0 |
"generated" | Файл модуля було створено динамічно за допомогою інструмента створення файлів. Див. systemd.generator(7). Створені файли модулів не може бути увімкнено, їх неявним чином вмикає їхній засіб породження. | 0 |
"transient" | Файл модуля було створено динамічно за допомогою програмного інтерфейсу середовища виконання. Тимчасові модулі не можна вмикати. | 0 |
"bad" | Файл модуля є некоректним або сталася якась інша помилка. Зауважте, що is-enabled насправді не повертатиме цього стану, а просто виведе повідомлення про помилку. Втім, його може бути виведено у списку файлів модулів, які програма виводить, якщо використано list-unit-files. | > 0 |
"not-found" | Файла модуля не існує. | 4 |
Додано у версії 238.
mask МОДУЛЬ...
Зауважте, що у результаті буде створено символічне посилання із назвою модуля у /etc/systemd/system/ (якщо не вказано --runtime) або /run/systemd/system/ (якщо вказано --runtime). Якщо відповідний файл модуля у цих каталогах вже існує, дія зазнає невдачі. Це означає, що дія, в основному, корисна для маскування модулів, які постачаються виробником обладнання (оскільки, вони зберігаються у /usr/lib/systemd/system/, а не у згаданих вище двох каталогах), але, типово, не працює для локально створених модулів (оскільки вони, типово, розміщуються у двох згаданих вище каталогах). Ті самі обмеження стосуються режиму --user, для якого, втім, відповідні каталоги розміщуються у домашньому каталозі користувача.
Якщо модуль, який має бути замасковано, може бути увімкнено іншими активними модулями, буде показано попередження зі списком назв відповідних модулів. Можна скористатися --no-warn для придушення попередження.
Додано у версії 238.
unmask МОДУЛЬ...
Додано у версії 238.
link ШЛЯХ...
Додано у версії 233.
revert МОДУЛЬ...
Насправді, цією командою можна скористатися для скасування усіх змін, які було внесено за допомогою команд systemctl edit, systemctl set-property і systemctl mask. Команда також повертає дію початкового файла модуля із його параметрами.
Додано у версії 230.
add-wants ЦІЛЬ МОДУЛЬ..., add-requires ЦІЛЬ МОДУЛЬ...
Ця команда враховує --system, --user, --runtime і --global у спосіб, подібний до enable.
Додано у версії 217.
edit МОДУЛЬ...
Залежно від того, вказано --system (типовий варіант), --user чи --global, ця команда створить вставний файл для кожного модуля для системи, лише для користувача, який її віддав, або для усіх наступних входів до системи усіх користувачів. Потім буде викликано редактор (див. розділ «Середовище» нижче) для тимчасових файлів, які буде записано до справжнього місця зберігання, якщо редактор успішно завершить роботу.
Якщо вказано --drop-in=, заданий файл вставлення буде використано замість типового override.conf.
Якщо вказано --full, буде скопійовано початкові модулі, а не створено фіктивні файли.
Якщо вказано --force, і якихось модулів ще не існує, для редагування буде відкрито нові файли модулів.
Якщо вказано --runtime, зміни буде внесено до /run/ тимчасово — їх буде втрачено під час перезавантаження системи.
Якщо тимчасовий файл буде порожнім на момент виходу, внесені до пов'язаного модуля зміни буде скасовано.
Після редагування модулів налаштування systemd буде перезавантажено (у спосіб, який є еквівалентним до команди daemon-reload).
Зауважте, що цю команду не можна використовувати для віддаленого редагування модулів, і ви не можете тимчасово редагувати модулі, які зберігаються в /etc/, оскільки вони мають вищий пріоритет над тими, які зберігаються у /run/.
Додано у версії 218.
get-default
Додано у версії 205.
set-default ЦІЛЬ
Додано у версії 205.
Команди машини¶
list-machines [ВЗІРЕЦЬ...]
Додано у версії 212.
Команди завдання¶
list-jobs [ВЗІРЕЦЬ...]
Якщо поєднано із --after або --before список буде розширено відомостями щодо того, на яке завдання очікує кожне завдання, і які завдання очікують на це завдання, див. вище.
Додано у версії 233.
cancel [ЗАВДАННЯ...]
Додано у версії 233.
Команди середовища¶
У systemd передбачено підтримку блоків середовища, яке буде передано процесам, породженим засобом керування. Назви змінних можуть містити літери ASCII, цифри та символи підкреслення. Назви змінних не можуть бути порожніми або починатися з цифри. У значеннях змінних можна використовувати більшість символів, але уся послідовність має бути коректним рядком UTF-8. (Зауважте, що символи керування, подібні до символу нового рядка (NL), табуляції (TAB) або символу скасування (ESC), є коректними символами ASCII, а отже, коректними символами UTF-8). Загальна довжина блоку середовища обмежена значенням _SC_ARG_MAX, яке визначено sysconf(3).
show-environment
Зауважте, що буде показано задіяний блок, тобто комбінацію змінних середовища, яку налаштовано за допомогою файлів налаштувань, засобів побудови середовища та IPC (тобто за допомогою set-environment, яку описано нижче). На момент відгалуження процесу модуля цей поєднаний блок середовища буде далі поєднано зі змінними середовища окремих модулів, які не буде показано цією командою.
set-environment ЗМІННА=ЗНАЧЕННЯ...
Зауважте, що це працює у блоці середовища, окремому від блоку середовища, налаштованого за допомогою налаштувань засобу керування службами і засобів створення середовища. Щоразу під час виклику процесу два блоки поєднуються (зі включенням усіх змінних середовища окремих служб) і передаються процесу. Команда show-environment покаже комбінацію цих блоків, див. вище.
Додано у версії 233.
unset-environment ЗМІННА...
Зауважте, що це працює у блоці середовища, окремому від блоку середовища, налаштованого за допомогою налаштувань засобу керування службами і засобів створення середовища. Щоразу під час виклику процесу два блоки поєднуються (зі включенням усіх змінних середовищ окремих служб) і передаються процесу. Команда show-environment покаже комбінацію блоків, див. вище. Зауважте, що це означає, що цю команду не можна використовувати для скасування визначення змінних середовища з файлів налаштувань засобу керування службами або із засобів створення середовища.
Додано у версії 233.
import-environment ЗМІННА...
Імпортування усього блоку середовища (виклик цієї команди без аргументів) вважається застарілим. Оболонка встановлює десятки змінних, які мають лише локальне значення, і які призначено лише для процесів, які є нащадками командної оболонки. Такі змінні у загальному блоці середовища є конфліктними щодо інших процесів.
Додано у версії 209.
Команди стану засобу керування¶
daemon-reload
Цю команду не слід плутати із командою reload.
daemon-reexec
log-level [РІВЕНЬ]
Додано у версії 244.
log-target [ЦІЛЬ]
Додано у версії 244.
service-watchdogs [yes|no]
Додано у версії 244.
Команди системи¶
is-system-running
Скористайтеся --wait, щоб наказати системі чекати, аж доки завершиться процес завантаження, перш ніж виводити поточний стан і повертати відповідний стан помилки. Якщо використано --wait, про стани initializing та starting повідомлено не буде. Замість цього команду буде заблоковано, аж до досягнення наступного стану (зокрема running або degraded).
Таблиця 2. Виведення
is-system-running
Назва | Опис | Код виходу |
initializing | Раннє завантаження, до досягнення basic.target або входу до стану maintenance. | > 0 |
starting | Пізнє завантаження, до того, як черга завдань стане бездіяльною уперше, або буде досягнуто одну з цілей порятунку системи. | > 0 |
running | Система є повноцінно функціональною. | 0 |
degraded | Система є функціональною, але один або декілька модулів є непрацездатними. | > 0 |
maintenance | Активною є ціль порятунку або критична ціль. | > 0 |
stopping | Засіб керування завершує роботу. | > 0 |
offline | Засіб керування не запущено. Зокрема, це стан роботи, якщо як засіб керування системою (PID 1) запущено несумісну програму. | > 0 |
unknown | Не вдалося визначити функціональний стан через брак ресурсів або з іншої причини. | > 0 |
Додано у версії 215.
default
rescue
emergency
halt
Якщо в поєднанні з --force, закриття всіх запущених служб пропускається, однак усі процеси припиняються, а всі файлові системи буде демонтовано або змонтовано лише для читання, одразу після чого відбувається зупинка системи. Якщо --force вказано двічі, операція виконується негайно без завершення будь-яких процесів або демонтування будь-яких файлових систем. Це може призвести до втрати даних. Зауважте, що коли --force вказано двічі, операцію зупинки виконує сама systemctl, без зв'язку із засобом керування системою. Це означає, що команда має бути успішною, навіть якщо засіб керування системою зазнав збою.
Якщо поєднати з --when=, вимикання буде заплановано після вказаної часової позначки. А --when=cancel скасує вимикання.
poweroff
Ця команда враховує --force і --when= у спосіб, подібний до halt.
reboot
Ця команда майже еквівалентна systemctl start reboot.target --job-mode=replace-irreversibly --no-block, але також друкує повідомлення на стіні для всіх користувачів. Ця команда є асинхронною; повернення відбувається після того, як операцію зупинки поставлено в чергу, не чекаючи її завершення.
Якщо вказано перемикач --reboot-argument=, його буде передано як додатковий аргумент системному виклику reboot(2).
Параметрами --boot-loader-entry=, --boot-loader-menu= і --firmware-setup можна скористатися для вибору дії, яку слід виконати після перезавантаження. Див. опис цих параметрів, щоб дізнатися більше.
Ця команда враховує --force і --when= у спосіб, подібний до halt.
Якщо за допомогою kexec --load завантажено нове ядро, замість перезавантаження буде виконано kexec, якщо не встановлено значення SYSTEMCTL_SKIP_AUTO_KEXEC=1. Якщо нову кореневу файлову систему було налаштовано у «/run/nextroot/», замість перезавантаження буде виконано soft-reboot, якщо не встановлено значення SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1.
Додано у версії 246.
kexec
Щоб завантажити ядро, буде виконано нумерацію за Специфікацією завантажувачів[1] і завантажено типовий запис завантаження. Для успішності цього кроку система має використовувати UEFI, і має бути належним чином налаштовано записи завантажувача. Для виведення списку записів завантаження можна скористатися bootctl list, див. bootctl(1).
Ця команда є асинхронною; повернення відбувається після того, як операцію зупинки поставлено в чергу, не чекаючи її завершення.
Ця команда враховує --force і --when= у спосіб, подібний до halt.
Якщо за допомогою kexec --load завантажено нове ядро, буде виконано kexec при виклику reboot, якщо не встановлено значення SYSTEMCTL_SKIP_AUTO_KEXEC=1.
soft-reboot
Ця команда враховує --force і --when= у спосіб, подібний до halt.
У результаті цієї дії буде перезавантажено лише простір користувача, а ядро лишиться працювати. Див. systemd-soft-reboot.service(8), щоб дізнатися більше.
Якщо у «/run/nextroot/» налаштовано нову кореневу файлову систему, буде виконано soft-reboot при виклику reboot, якщо не встановлено значення SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1.
Додано у версії 254.
exit [КОД_ВИХОДУ]
Засіб керування службами завершить роботу із вказаним кодом виходу, якщо передано КОД_ВИХОДУ.
Додано у версії 227.
switch-root [КОРІНЬ [ІНІЦІАЛІЗАЦІЯ]]
Додано у версії 209.
suspend
hibernate
hybrid-sleep
Додано у версії 196.
suspend-then-hibernate
Додано у версії 240.
Синтаксис параметрів¶
Команди із наведеного вище списку приймають або одну назву модуля (позначену як МОДУЛЬ), або декілька специфікацій модулів (позначених як ВЗІРЕЦЬ...). У першому випадку слід надати назву модуля з суфіксом або без нього. Якщо суфікс не вказано (назву модуля «скорочено»), systemctl допише відповідний суфікс: типово, «.service» або специфічний до типу суфікс у випадку команд, які працюють лише з певним типом модулів. Приклад:
# systemctl start sshd
і
# systemctl start sshd.service
є еквівалентними, як є еквівалентними
# systemctl isolate default
і
# systemctl isolate default.target
Зауважте, що (абсолютні) шляхи до вузлів пристроїв буде автоматично перетворено на назви модулів пристроїв, а інші (абсолютні) шляхи — на назви модулів монтування.
# systemctl status /dev/sda # systemctl status /home
є еквівалентом такого:
# systemctl status dev-sda.device # systemctl status home.mount
У другому випадку взірці із символами-замінниками у стилі командної оболонки буде зіставлено із основними назвами усіх модулів, які перебувають в оперативній пам'яті; буквально вказані назви модулів, із суфіксом чи без нього, буде оброблено за першим випадком. Це означає, що буквально вказані назви модулів завжди стосуються точно одного модуля, а взірці можуть відповідати нульовій кількості модулів, і це не вважатиметься помилкою.
Для взірців із символами-замінниками використано fnmatch(3), тому встановлення відповідності відбувається за звичайними правилами у стилі командної оболонки, і можна використовувати «*», «?», «[]». Див. glob(7), щоб дізнатися більше. Встановлення відповідності взірцям відбуватиметься для основних назв модулів, які перебувають у оперативній пам'яті, а взірці, відповідників яких не вдасться виявити, буде без повідомлень пропущено. Приклад:
# systemctl stop sshd@*.service
зупинить усі екземпляри sshd@.service. Зауважте, що альтернативні назви модулів і модулі, які не перебувають в оперативній пам'яті, не буде розглянуто під час розгортання взірця.
Для команд файлів модулів вказаний МОДУЛЬ має бути назвою файла модуля (можливо, скороченою, див. вище) або абсолютним шляхом до файла модуля:
# systemctl enable foo.service
або
# systemctl link /шлях/до/foo.service
ПАРАМЕТРИ¶
Передбачено обробку таких параметрів:
-t, --type=
В особливому випадку, якщо одним з аргументів є help, буде виведено список усіх дозволених значень, і програма завершить роботу.
--state=
В особливому випадку, якщо одним з аргументів є help, буде виведено список усіх дозволених значень, і програма завершить роботу.
Додано у версії 206.
-p, --property=
Для самого засобу керування systemctl show виведе усі доступні властивості, більшість з яких є похідними або дуже схожими на параметри, описані на сторінці підручника щодо systemd-system.conf(5).
Властивості модулів різних типів є доволі різними, тому виведення даних для будь-якого модуля (навіть такого, якого не існує) є способом ознайомитися зі списком властивостей відповідного типу. Так само, виведення списку властивостей для довільного завдання призведе до виведення властивостей, які є в усіх завдань. Властивості модулів задокументовано на сторінці підручника systemd.unit(5), а сторінками для окремих типів модулів є systemd.service(5), systemd.socket(5) тощо.
-P
Додано у версії 246.
-a, --all
Щоб отримати список усіх встановлених у файловій системі модулів, скористайтеся замість цієї команди командою list-unit-files.
При побудові списку модулів за допомогою list-dependencies вивести рекурсивні залежності усіх залежних модулів (типово, буде виведено лише залежності цільових модулів).
Якщо використано разом із status, показувати повідомлення журналу повністю, навіть якщо вони містять непридатні до друку символи або є дуже довгими. Типово, поля із непридатними до друку символами обрізаються як «бінарні дані». (Зауважте, що програма поділу даних на сторінки може виконати додаткове екранування непридатних до друку символів.)
-r, --recursive
Додано у версії 212.
--reverse
Додано у версії 203.
--after
Зауважте, що будь-яку залежність After= буде автоматично віддзеркалено для створення залежності Before=. Тимчасові залежності може бути вказано явним чином, але також буде створено неявним чином для модулів, які є цілями WantedBy= (див. systemd.target(5)), і як результат інших інструкцій (наприклад RequiresMountsFor=). Явні і неявні впроваджені залежності буде виведено у відповідь на команду list-dependencies.
Якщо передано команді list-jobs для кожного виведеного завдання вивести, які інші завдання очікують на нього. Можна поєднати з --before, щоб програма вивела і завдання, які очікують на якесь завдання, і усі завдання, на які очікує якесь завдання.
Додано у версії 203.
--before
Якщо передано команді list-jobs для кожного виведеного завдання вивести, які інші завдання очікують на нього Можна поєднати з --after, щоб програма вивела і завдання, які очікують на якесь завдання, і усі завдання, на які очікує якесь завдання.
Додано у версії 212.
--with-dependencies
Змінити типи показаних залежностей можна за допомогою параметрів --reverse, --after, --before.
Додано у версії 245.
-l, --full
Крім того, вивести цілі встановлення у даних, які виведено is-enabled.
--value
Додано у версії 230.
--show-types
Додано у версії 202.
--job-mode=
Якщо вказано «fail», і запитана дія конфліктує із завданням у черзі (специфічніше: спричиняє обернення у зупинене завдання і навпаки для завдання запуску, яке вже перебуває у черзі), спричиняє режим помилки для дії.
Якщо вказано «replace» (типовий варіант), будь-яке конфліктне завдання у черзі у разі потреби буде замінено.
Якщо вказано «replace-irreversibly», діяти, як для «replace», але також позначити нові завдання як непридатні до обернення. Це запобігає майбутнім конфліктним операціям з заміни цих завдань (або навіть додавання до черги таких операцій, доки непридатні до обернення завдання перебувають у черзі). Непридатні до обернення завдання, попри це, можна скасувати за допомогою команди cancel. Цим режимом завдання слід користуватися для будь-якої операції, яка включає shutdown.target.
«isolate» є чинним лише для дій із запуску і спричиняє зупинення усіх інших модулів при запуску вказаного модуля. Цей режим завжди використовує команда isolate.
«flush» спричиняє скасування усіх завдань з черги при додаванні нового завдання до черги.
Якщо вказано «ignore-dependencies», усі залежності модулів буде проігноровано для цього нового завдання, і дію буде виконано негайно. Якщо передано у команді, для переданого модуля не викликатимуться потрібні для нього модулі, а залежності упорядковування не буде взято до уваги. Здебільшого, цей параметр призначено для діагностики та порятунку для адміністратора. Не слід користуватися ним у програмах.
«ignore-requirements» є подібним до «ignore-dependencies», але спричиняє ігнорування лише вимог залежностей, залежності упорядковування буде взято до уваги.
«triggering» можна використовувати лише з systemctl stop. У цьому режимі вказаний модуль і усі активні модулі, які увімкнули його, буде зупинено. Див. обговорення Triggers= на сторінці підручника systemd.unit(5), щоб дізнатися більше про вмикання модулів.
«restart-dependencies» можна використовувати лише у поєднанні із systemctl start. У цьому режимі залежності вказаного модуля отримають поширення перезапуску, так, наче у чергу обробки було поставлено завдання з перезапуску модуля.
Додано у версії 209.
-T, --show-transaction
Додано у версії 242.
--fail
Якщо використано у поєднанні з командою kill, результатом дії буде помилка, якщо не завершено роботу жодного модуля.
Додано у версії 227.
--check-inhibitors=
Програми можуть встановлювати блокування уповільнення для уникнення переривання вимиканням системи або станом сну певних важливих дій (зокрема процедури записування компакт-диска чи подібних операцій). Створити ці блокування може будь-який користувач, а привілейовані користувачі можуть перевизначати ці блокування. Якщо визначено якесь блокування, запити щодо вимикання або присипляння, зазвичай, завершуватимуться помилкою (якщо користувач не є привілейованим). Втім, якщо вказано «no» або «auto» для неінтерактивних запитів, буде виконано спробу дії. Якщо існують блокування, дія може потребувати додаткових привілеїв.
Використання параметра --force є іншим способом перевизначити уповільнювачі.
Додано у версії 248.
-i
Додано у версії 198.
--dry-run
Додано у версії 236.
-q, --quiet
--no-warn
Додано у версії 253.
--no-block
--wait
Якщо використано з is-system-running, очікувати на завершення процедури завантаження, перш ніж повертати керування.
Додано у версії 232.
--user
--system
--failed
Додано у версії 233.
--no-wall
--global
--no-reload
--no-ask-password
--kill-whom=
Додано у версії 252.
--kill-value=INT
Якщо використано цей параметр, сигнал буде додано до черги лише для процесу керування або основного процесу модуля, ніколи для інших процесів, які належать модулю, тобто --kill-whom=all стосуватиметься лише основного і керівного процесів, але не інших процесів.
Додано у версії 254.
-s, --signal=
Використання особливого значення «help» призведе до виведення списку відомих значень і негайного виходу з програми, а особливого значення «list» — до списку відомих значень разом із числовими номерами сигналів і негайного виходу з програми.
--what=
Додано у версії 243.
-f, --force
Якщо використано разом із edit, створити усі вказані модулі, яких ще не існує.
Якщо використано разом із halt, poweroff, reboot або kexec, виконати вибрану дію без завершення роботи усіх модулів. Втім, усі процеси буде завершено у примусовому режимі, а усі файлові системи буде демонтовано або повторно змонтовано у режимі лише читання. Отже, це доволі сильнодійний, але відносно безпечний спосіб надсилання запиту щодо негайного перезавантаження. Якщо --force вказано двічі для цих дій (окрім kexec), їх буде виконано негайно, без переривання будь-яких процесів і демонтування будь-яких файлових систем. Попередження: подвійне вказування --force із будь-якою з цих дій може призвести до втрати даних. Зауважте, що якщо --force вказано двічі, вибрану дію буде виконано самою програмою systemctl, а обмін даними із загальносистемним засобом керування не встановлюватиметься. Це означає, що програма має завершити роботу успішно, навіть якщо загальносистемний засіб керування завершить роботу в аварійному режимі.
--message=
Додано у версії 225.
--now
Додано у версії 220.
--root=
--image=образ
Додано у версії 252.
--image-policy=правила
--runtime
Так само, при використанні разом із set-property, внести зміни лише тимчасово, так, щоб їх було скасовано під час наступного перезавантаження системи.
--preset-mode=
Додано у версії 215.
-n, --lines=
-o, --output=
--firmware-setup
Додано у версії 220.
--boot-loader-menu=час очікування
Додано у версії 242.
--boot-loader-entry=ідентифікатор
Додано у версії 242.
--reboot-argument=
Додано у версії 246.
--plain
Додано у версії 203.
--timestamp=
pretty (типовий варіант)
Додано у версії 248.
unix
Додано у версії 251.
us, μs
Додано у версії 248.
utc
Додано у версії 248.
us+utc, μs+utc
Додано у версії 248.
Додано у версії 247.
--mkdir
Додано у версії 248.
--marked
Якщо не використано --no-block, systemctl чекатиме на завершення завдань з черги.
Додано у версії 248.
--read-only
Додано у версії 248.
--drop-in=НАЗВА
Додано у версії 253.
--when=
Додано у версії 254.
-H, --host=
-M, --machine=
--no-pager
--legend=булеве значення
-h, --help
--version
СТАН ВИХОДУ¶
Якщо команду буде виконано успішно, буде повернуто 0; в інших випадках, буде повернуто ненульовий код помилки.
У systemctl використано коди повернення, які визначено LSB, зокрема у LSB 3.0.0[3].
Таблиця 3. Коди
повернення
LSB
Значення | Опис у LSB | Використання у systemd |
0 | "програма працює або служба працює нормально" | модуль є активним |
1 | "програма «вмерла» і файл pid у /var/run існує" | виконання модуля не завершилося помилкою (використовується is-failed) |
2 | "програма «вмерла», і існує файл блокування у /var/lock" | не використовується |
3 | "програму не запущено" | модуль не є активним |
4 | "стан програми або служби є невідомим" | Немає такого модуля |
Відповідність між станами служб у LSB та станами модулів systemd не є ідеальною, тому краще не покладатися на ці повернуті значення, а звернутися до станів певного модуля і підмодулів.
СЕРЕДОВИЩЕ¶
$SYSTEMD_EDITOR
Додано у версії 218.
$SYSTEMD_LOG_LEVEL
$SYSTEMD_LOG_COLOR
Цей параметр є корисним, лише якщо повідомлення буде записано безпосередньо до термінала, оскільки journalctl(1) та інші інструменти для показу журналу розфарбовуватимуть повідомлення на основі рівня журналювання власними засобами.
$SYSTEMD_LOG_TIME
Цей параметр є корисним, лише якщо повідомлення буде записано безпосередньо до термінала або файла, оскільки journalctl(1) та інші інструменти для показу журналу додаватимуть часові позначки на основі метаданих запису власними засобами.
$SYSTEMD_LOG_LOCATION
Зауважте, що часто до записів журналу все одно буде дописано розташування журналу. Тим не менше, включення його безпосередньо до тексту повідомлення може бути зручним для діагностичних програм.
$SYSTEMD_LOG_TARGET
$SYSTEMD_PAGER
Зауваження: якщо не встановлено значення $SYSTEMD_PAGERSECURE, буде без попередження проігноровано $SYSTEMD_PAGER (а також $PAGER).
$SYSTEMD_LESS
Користувачам, можливо, варто змінити два параметри:
K
Якщо значення $SYSTEMD_LESS не включає «K», і викликаним засобом поділу на сторінки є less, Ctrl+C буде проігноровано виконуваним файлом — його має обробляти сам засіб поділу на сторінки.
X
Зауважте, що встановлення звичайної змінної середовища $LESS не впливає на виклики less інструментами systemd.
Див. less(1), щоб дізнатися більше.
$SYSTEMD_LESSCHARSET
Зауважте, що встановлення звичайної змінної середовища $LESSCHARSET не впливає на виклики less інструментами systemd.
$SYSTEMD_PAGERSECURE
Зауваження: якщо команди викликають із підвищеними привілеями, наприклад, з використанням sudo(8) або pkexec(1), слід подбати про те, щоб небажані інтерактивні можливості не було увімкнено. «Безпечний» режим для засобу поділу на сторінки може бути автоматично увімкнуто, як це описано вище. Якщо встановлено значення SYSTEMD_PAGERSECURE=0 або якщо змінну не усунено з успадкованого середовища, користувач зможе викликати довільні команди. Зауважте, що якщо змінні $SYSTEMD_PAGER або $PAGER слід брати до уваги, то слід встановити і значення $SYSTEMD_PAGERSECURE. Втім, у такому випадку, можливо, варто взагалі вимкнути засіб поділу на сторінки за допомогою параметра --no-pager.
$SYSTEMD_COLORS
$SYSTEMD_URLIFY
ДИВ. ТАКОЖ¶
systemd(1), journalctl(1), loginctl(1), machinectl(1), systemd.unit(5), systemd.resource-control(5), systemd.special(7), wall(1), systemd.preset(5), systemd.generator(7), glob(7)
ПРИМІТКИ¶
- 1.
- Специфікація завантажувачів
- 2.
- Специфікація придатних до вивчення розділів
- 3.
- LSB 3.0.0
ПЕРЕКЛАД¶
Український переклад цієї сторінки посібника виконано Andriy Rysin <arysin@gmail.com>, Yuri Chornoivan <yurchor@ukr.net> і lxlalexlxl <lxlalexlxl@ukr.net>
Цей переклад є безкоштовною документацією; будь ласка, ознайомтеся з умовами GNU General Public License Version 3. НЕ НАДАЄТЬСЯ ЖОДНИХ ГАРАНТІЙ.
Якщо ви знайшли помилки у перекладі цієї сторінки підручника, будь ласка, надішліть електронний лист до списку листування перекладачів: trans-uk@lists.fedoraproject.org.
systemd 255 |