Provided by: manpages-uk_4.24.0-2_all 
НАЗВА
systemctl — керування системою systemd та засіб керування службами
КОРОТКИЙ ОПИС
systemctl [ПАРАМЕТРИ...] КОМАНДА [МОДУЛЬ...]
ОПИС
systemctl можна використати для інтроспекції і керування станом «systemd» і засобом
керування службами. Будь ласка, зверніться до systemd(1), щоб ознайомитися із вступом до
базових понять та функціональними можливостями, якими керує цей інструмент.
КОМАНДИ
Передбачено обробку таких команд:
Команди модулів (інтроспекція і модифікація)
list-units [ВЗІРЕЦЬ...]
Виводить список модулів, які systemd у поточний момент тримає у пам'яті. До списку
буде включено модулів, на які є безпосередні посилання або посилання за залежністю,
модулі, які пришпилено програмами на рівні коду, або модулів, які були активними, але
виконання яких завершилося помилкою. Типово, буде показано лише модулі, які є
активними, мають заплановані завдання, або виконання яких завершилося помилкою;
змінити це можна за допомогою параметра --all. Якщо вказано один або декілька ВЗІРЦІВ,
буде показано лише модулі, які відповідають хоч одному з них. Подальше фільтрування
можливе за допомогою параметрів --type= і --state=, якщо такі вказано.
Зауважте, що ця команда не показує шаблонів модулів, але лише екземпляри шаблонів
модулів. Шаблони модулів, які не матимуть екземплярів, не є придатними до запуску,
отже, їх ніколи не буде показано у даних, які виведено цією командою. Це, зокрема,
значить, що щось@.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 ВЗІРЕЦЬ...
Перевірити, чи є активним (тобто запущеним) якийсь із вказаних модулів. Повертає код
виходу 0, якщо принаймні один модуль є активним, або ненульове значення в інших
випадках. Якщо не вказано --quiet, також виведе стан поточного модуля до стандартного
виведення.
is-failed [ВЗІРЕЦЬ...]
Перевірити, чи перебуває у стані «failed». Якщо модуль не вказано, буде виконано пошук
модулів, виконання яких завершилося помилкою, що відповідає стану «degraded»
повернутому is-system-running. Повертає код виходу 0, якщо принаймні один модуль
перебуває у стані помилки, або ненульове значення в інших випадках Якщо не вказано
--quiet, також виведе стан поточного модуля або системи до стандартного виведення
Додано у версії 197.
status [ВЗІРЕЦЬ...|PID...]]
Показати відомості щодо поточного стану для усієї системи або одного чи декількох
модулів із наступним виведенням найсвіжіших даних з журналу. Якщо не вказано
позиційних аргументів і фільтра модулів за допомогою --type=, --state= або --failed,
показує стан усієї системи. Якщо поєднано із --all, буде виведено стан усіх модулів.
Якщо вказано позиційні аргументи, кожен з позиційних аргументів буде оброблено як
назву модуля, для якого слід показати дані, або як загальний взірець для показу даних
відповідних до взірця модулів, або як PID для показу даних модуля, що містить цей PID.
Якщо використано --type=, --state= або --failed, буде виконано додаткове фільтрування
списку модулів за станом TYPE та ACTIVE.
Цю функцію призначено для створення зручних для читання даних. Якщо вам потрібні дані,
які просто обробляти на комп'ютері, скористайтеся замість неї 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 [ВЗІРЕЦЬ...|ЗАВДАННЯ...]
Вивести властивості одного або декількох модулів, завдань або самого засобу керування.
Якщо аргумент не вказано, буде виведено властивості засобу керування. Якщо вказано
назву модуля, буде виведено властивості модуля, а якщо вказано ідентифікатор завдання,
буде виведено властивості завдання. Типово, властивості із порожніми значеннями
виведено не буде.. Скористайтеся параметром --all, щоб програма вивела і ці
властивості. Щоб вибрати для показу якісь властивості, скористайтеся параметром
--property=. Цю команду призначено для використання у випадку потреби у обробці
виведених даних комп'ютером. Якщо вам потрібні форматовані зручні для читання виведені
дані, скористайтеся командою status.
Багато властивостей, значення яких виводить systemctl show безпосередньо пов'язано із
параметрами налаштувань системи та засобу керування службами та його файлами модулів.
Зауважте, що властивості, які виведено цією командою, загалом, є нижчого рівня,
нормалізованими версіями початкових параметрів налаштувань, і вказують на динамічний
стан на додачу до налаштувань. Наприклад, властивості, які виведено для модулів служб,
включають поточний ідентифікатор основного процесу служби як «MainPID» (динамічний
стан), а параметри часу завжди виводяться як властивості із кінцевим суфіксом
«...USec», навіть якщо відповідні параметри налаштувань мають назви, які закінчуються
на «...Sec», оскільки мікросекунди є нормалізованою одиницею часу, яку на внутрішньому
рівні використовує система на засіб керування службами.
Докладніший опис багатьох цих властивостей можна знайти у документації до базового
компонента цих властивостей, інтерфейсу D-Bus, див. org.freedesktop.systemd1(5).
cat ВЗІРЕЦЬ...
Вивести базові файли одного або декількох модулів. Виводить «fragment» і «drop-ins»
(початкові файли) модулів. Перед пунктом кожного файла буде виведено коментар із
назвою файла. Зауважте, що буде виведено вміст базових файлів на диску, який може
відрізнятися від даних засобу керування службами для цих модулів, якщо файли модулів
було оновлено на диску, і з того часу не було віддано команду daemon-reload.
Додано у версії 209.
help ВЗІРЕЦЬ...|PID...
Вивести сторінки підручника для одного або декількох модулів, якщо такі доступні. Якщо
задано PID, буде показано сторінки підручника для модуля, якому належить процес.
Додано у версії 185.
list-dependencies [МОДУЛЬ...]
Виводить модулі, які потрібні і бажані для вказаних модулів. Виводить рекурсивний
список модулів із наступними залежностями Requires=, Requisite=, Wants=, ConsistsOf=,
BindsTo= і Upholds=. Якщо модулів не вказано, буде неявно використано default.target.
Показані модулі буде додатково фільтровано з використанням --type= та --state=, якщо
вказано ці параметри. Зауважте, що ми не зможемо скористатися у цьому випадку
ієрархічною структурою, отже неявним чином буде використано --plain.
Типово, буде рекурсивно розгорнуто лише модулі призначення. Якщо буде передано
параметр --all, також буде рекурсивно розгорнуто усі інші модулі.
Змінити типи показаних залежностей можна за допомогою параметрів --reverse, --after,
--before.
Зауважте, що ця команда виводить список лише тих модулів, які у поточний момент
завантажено до пам'яті засобом керування службами. Зокрема, ця команда непридатна для
отримання повного списку щодо усіх зворотних залежностей певного модуля, оскільки вона
не виводить залежностей, які оголошено модулями і у поточний момент не завантажено.
Додано у версії 198.
start ВЗІРЕЦЬ...
Запустити (активувати) один або декілька модулів, які вказано у рядку команди.
Зауважте, що взірці назв модулів із символами-замінниками розгортаються до назв
модулів, які зараз перебувають в оперативній пам'яті. Модулі, які є неактивними і не
перебувають у стані помилки, зазвичай, не перебувають у пам'яті, отже, для них не буде
встановлено відповідності жодному взірцю. Крім того, у випадку модулів із екземплярами
systemd часто не знає назви екземпляра до запуску цього екземпляра. Отже, використання
взірців із символами-замінниками у start не дуже-то й корисне. Крім того, вторинні
назви-альтернативи модулів не буде взято до уваги.
Для роботи із неактивними модулями, на які посилаються інші завантажені модулі, можна
також скористатися параметром --all. Зауважте, що це не те саме, що працювати із
«усіма» можливими модулями, оскільки, як про це вже написано у попередньому абзаці,
такий список є некоректним. Втім, systemctl start --all ВЗІРЕЦЬ може бути корисним,
якщо усі модулі, які слід знайти за шаблоном, запускаються певною ціллю, про яку
відомо, що її буде завантажено.
stop ВЗІРЕЦЬ...
Зупинити (деактивувати) один або декілька модулів, які вказано у рядку команди.
Виконання цієї команди завершиться помилкою, якщо модуля не існує або якщо зупинення
модуля заборонено (див. RefuseManualStop= у systemd.unit(5)). Виконання не завершиться
помилкою, якщо виконання будь-якої з команд, які налаштовано для зупинення модуля
(ExecStop= тощо), завершиться помилкою, оскільки засіб керування все одно примусово
зупинить роботу модуля.
Якщо модуль, який зупиняється, може бути увімкнено іншими модулями, буде показано
попередження зі списком назв відповідних модулів. Можна скористатися --no-warn для
придушення попередження.
reload ВЗІРЕЦЬ...
Наказує усім модулям зі списку у рядку команди перезавантажити налаштування. Зауважте,
що у результаті буде перезавантажено специфічні для служби налаштування, а не файл
налаштувань модуля systemd. Якщо вам потрібно, щоб програма systemd перезавантажила
файл налаштувань модуля, скористайтеся командою daemon-reload. Іншими словами, у
випадку, наприклад, Apache, у результаті буде перезавантажено httpd.conf у вебсервері
Apache, але не файл модуля systemd apache.service.
Цю команду не слід плутати із командою daemon-reload.
restart ВЗІРЕЦЬ...
Зупинити і потім знову запустити один або декілька модулів, які вказано у рядку
команди. Якщо модулі ще не запущено, їх буде запущено.
Зауважте, що перезапуск модуля за допомогою цієї команди не обов'язково скине усі
ресурси модуля, перш ніж його буде знову запущено. Наприклад, сховище дескрипторів
файлів окремої служби (див. FileDescriptorStoreMax= in systemd.service(5)) лишиться
незмінним, доки завдання модуля перебуватиме у черзі обробки — його буде очищено, коли
роботу модуля буде повністю зупинено, і у нього не лишиться завдань у черзі. Якщо
треба скинути і сховище дескрипторів файлів, під час дії з перезапуску слід віддати
явно команду systemctl stop, а потім команду systemctl start.
try-restart ВЗІРЕЦЬ...
Зупинити і потім знову запустити один або декілька модулів, які вказано у рядку
команди, якщо модулі запущено. Якщо модулі не запущено, ніяких дій щодо них не
виконуватиметься.
reload-or-restart ВЗІРЕЦЬ...
Перезавантажити один або декілька модулів, якщо у них передбачено підтримку таких дій.
Якщо підтримки перезавантаження не передбачено, зупинити і потім знову запустити ці
модулі. Якщо модулі ще не запущено, їх буде запущено.
try-reload-or-restart ВЗІРЕЦЬ...
Перезавантажити один або декілька модулів, якщо у них передбачено підтримку таких дій.
Якщо підтримки перезавантаження не передбачено, зупинити і потім знову запустити ці
модулі. Якщо модулі не запущено, ніяких дій виконано не буде.
Додано у версії 229.
isolate МОДУЛЬ
Запустити модуль, який вказано у рядку команди, і усі його залежності, і зупинити усі
інші, якщо для них не вказано IgnoreOnIsolate=yes (див. systemd.unit(5)). Якщо вказано
назву модуля без суфікса, програма припускатиме, що суфіксом є «.target».
Ця команда є небезпечною, оскільки вона негайно припиняє роботу процесів, які не
увімкнено у новій цілі, можливо, разом із графічним середовищем або терміналом, яким
ви користуєтеся на момент виконання команди.
Зауважте, що ця дія є можливою лише для модулів, для яких увімкнено AllowIsolate=.
Див. systemd.unit(5), щоб дізнатися більше.
kill ВЗІРЕЦЬ...
Надіслати сигнал процесу UNIX одному або декільком процесам модуля. Скористайтеся
--kill-whom=, щоб вибрати, якому процесу слід надіслати сигнал. Скористайтеся
--signal=, щоб вибрати сигнал, який слід надіслати. Поєднайте з --kill-value=, щоб
додати до черги сигнал реального часу POSIX із пов'язаним значенням.
clean ВЗІРЕЦЬ...
Вилучити налаштування, стан, кеш, журнал та динамічні дані вказаних модулів.
Скористайтеся --what=, щоб вибрати тип ресурсу для вилучення. Для модулів служб цією
командою можна скористатися для вилучення каталогів, які налаштовано за допомогою
ConfigurationDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory= та
RuntimeDirectory=, див. systemd.exec(5), щоб дізнатися більше. Нею також можна
скористатися для очищення сховища дескрипторів файлів з вмиканням за допомогою
FileDescriptorStoreMax=, див. systemd.service(5), щоб дізнатися більше. Для модулів
таймера цією командою можна скористатися для вилучення сталих даних часових позначок,
якщо використано Persistent= і вибрано --what=state, див. systemd.timer(5). Ця команда
застосовується лише до модулів, у яких використовуються якісь з цих параметрів. Якщо
не вказано --what=, буде вилучено одразу дані з кешу і динамічні дані, а також очищено
дані сховища дескрипторів файлів (оскільки ці три типи ресурсів є зайвими і
відтворюються під час наступного виклику цього модуля). Зауважте, що вказані модулі
має бути зупинено, щоб можна було викликати цю дію.
Таблиця 1. Можливі значення --what=
┌────────────────┬──────────────────────────────┐
│Значення │ Налаштовування модуля │
├────────────────┼──────────────────────────────┤
│"runtime" │ RuntimeDirectory= │
├────────────────┼──────────────────────────────┤
│"state" │ StateDirectory= │
├────────────────┼──────────────────────────────┤
│"cache" │ CacheDirectory= │
├────────────────┼──────────────────────────────┤
│"logs" │ LogsDirectory= │
├────────────────┼──────────────────────────────┤
│"configuration" │ ConfigurationDirectory= │
├────────────────┼──────────────────────────────┤
│"fdstore" │ FileDescriptorStorePreserve= │
├────────────────┼──────────────────────────────┤
│"all" │ Усе з наведеного вище │
└────────────────┴──────────────────────────────┘
Додано у версії 243.
freeze ВЗІРЕЦЬ...
Заморозити один або декілька модулів, які вказано у командному рядку за допомогою
засобу замороження cgroup
Заморожування модуля спричинить призупинення усіх процесів, які місяться у cgroup, що
відповідає модулю. Призупинення означає, що процеси модуля не буде заплановано для
виконання на центральному процесорі, доки модуль не буде розморожено. Зауважте, що
підтримку цієї команди передбачено лише на системах, які використовують уніфіковану
ієрархію cgroup. Модуль буде автоматично розморожено одразу перед виконанням завдання
щодо модуля, наприклад, перед тим, як модуль буде зупинено.
Додано у версії 246.
thaw ВЗІРЕЦЬ...
Розтопити (розморозити) один або декілька модулів, які вказано у рядку команди.
Це обернена дія до команди freeze, і вона відновлює виконання процесів для cgroup
модуля.
Додано у версії 246.
set-property МОДУЛЬ ВЛАСТИВІСТЬ=ЗНАЧЕННЯ...
Встановити вказані властивості модуля у середовищі виконання, де передбачено
відповідну підтримку. Ця команда уможливлює зміну властивостей параметра налаштувань,
зокрема параметрів керування ресурсами у середовищі виконання. Не усі властивості може
бути динамічно змінено, але багато з параметрів керування ресурсами (в основному,
властивостей у systemd.resource-control(5)) можна. Зміни буде застосовано негайно і
збережено на диск для майбутніх завантажень, якщо не буде передано параметр --runtime,
бо у цьому випадку параметри буде застосовано лише під час наступного перезавантаження
системи. Синтаксис надання властивостям значень близько наслідує синтаксис надання
значень у файлах модулів.
Приклад: 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 МОДУЛЬ ШЛЯХ [ШЛЯХ]
Монтує з прив'язкою файл або каталог з основної системи до вказаного простору
монтування модуля. Першим аргументом шляху є початковий файл або каталог в основній
системі, другим аргументом шляху є файл або каталог призначення у просторі назв
модуля. Якщо останній пропущено, шлях призначення у просторі назв модуля є тим самим,
що і початковий шлях в основній системі. Якщо поєднано із перемикачем --read-only,
буде створено монтування з прив'язкою лише для читання. Якщо поєднано із перемикачем
--mkdir, шлях призначення буде створено ще до застосування монтування.
Зауважте, що підтримку цього параметра у поточній версії передбачено лише для модулів,
які запущено у просторі назв монтування (приклади: RootImage=, PrivateMounts= тощо). У
цій команді передбачено підтримку монтування каталогів, звичайних файлів, вузлів
пристроїв, вузлів сокетів AF_UNIX, а також FIFO з прив'язкою. Монтування з прив'язкою
є недовговічним, його можна скасувати, щойно роботу поточного процесу модуля буде
завершено. Зауважте, що згаданий тут простір назв, до якого буде додано монтування з
прив'язкою, є простором назв, у якому працює основний процес служби. Інші процеси (ті,
які виконуються ExecReload=, ExecStartPre= тощо) працюють в окремих просторах назв.
Якщо у ядрі передбачено відповідну підтримку, усі попередні монтування до вибраної
цілі буде замінено новим монтуванням. Якщо такої підтримки не передбачено, усі
попередні монтування буде змонтовано повторно, але монтування лишатиметься пришпиленим
і недоступним.
Додано у версії 248.
mount-image МОДУЛЬ ОБРАЗ [ШЛЯХ [НАЗВА_РОЗДІЛУ:ПАРАМЕТРИ_МОНТУВАННЯ]]
Монтує образ з основної системи до простору назв вказаного модуля. Перший аргумент
шляху є образ джерела в основній системи, другий аргумент шляху є каталогом
призначення у просторі назв монтування модуля (тобто у RootImage=/RootDirectory=).
Наступний аргумент, якщо його вказано, буде оброблено як відокремлений двокрапкою
кортеж назви розділу і списку відокремлених комами параметрів монтування для цього
розділу. Формат є тим самим, як для параметра служби MountImages=. Якщо поєднано із
перемикачем --read-only, буде створено монтування лише для читання. Якщо поєднано із
перемикачем --mkdir, шлях призначення буде створено ще до застосування монтування.
Зауважте, що підтримку цього параметра у поточній версії передбачено лише для модулів,
які запущено у просторі назв монтування (приклади: 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» («помилка») вказаних модулів або, якщо не вказано назв модулів,
скинути стан для усіх модулів. Якщо робота модуля якимось чином завершується помилкою
(тобто процес завершує роботу із ненульовим кодом помилки, нештатно перериває роботу
або перевищує час очікування на дані), його автоматично буде переведено у стан
«failed», а його код виходу та стан буде записано для вивчення адміністратором, аж
доки службу не буде зупинено і повторно запущено або скинуто за допомогою цієї
команди.
На додачу до скидання стану «failed» модуля команда також скидає різноманітні інші
властивості для окремого модуля: обмежувальний лічильник запуску для модулів усіх
типів буде скинуто до нуля, як і лічильник перезапуску модулів служб. Таким чином,
якщо досягнуто обмеження на запуск модуля (як його налаштовано за допомогою
StartLimitIntervalSec=/StartLimitBurst=), і модуль не вдається запустити знову,
скористайтеся цією командою, щоб зробити модуль знову придатним до запуску.
whoami [PID...]
Повертає список модулів, яким належать процеси, вказані за PID (по одному на рядок).
Якщо PID не вказано, повертає модуль, з якого викликано команду systemctl.
Додано у версії 254.
Команди файла модуля
list-unit-files [ВЗІРЕЦЬ...]
Вивести список файлів, які встановлено у системі, у поєднанні із даними щодо їхньої
увімкненості (як про це повідомляє команда is-enabled). Якщо вказано один або декілька
ВЗІРЦІВ, буде показано лише файли модулів, які відповідають одному з взірців
(підтримки встановлення відповідності за шляхами у файловій системі взірцям не
передбачено).
На відміну від list-units, ця команда виводить список шаблонів модулів, окрім модулів
із явними екземплярами.
Додано у версії 233.
enable МОДУЛЬ..., enable ШЛЯХ...
Увімкнути один або декілька модулів або екземплярів модулів. У результаті буде
створено набір символічних посилань у кодуванні розділів [Install] вказаних файлів
модулів. Після створення символічних посилань налаштування засобу керування системою
буде перезавантажено (у еквівалентний до daemon-reload спосіб) з метою забезпечення
негайного врахування змін. Зауважте, що це не означатиме запуску будь-яких модулів,
які вмикаються. Якщо слід запустити якісь модулі, поєднайте цю команду із перемикачем
--now або потім віддайте команду start із відповідними аргументами. Зауважте, що у
випадку вмикання екземплярів модулів (тобто вмикання модулів у формі
щось@десь.service) буде створено символічні посилання із назвами, які збігаються зі
назвами екземплярів, у каталозі налаштувань модулів, втім, ці посилання вказуватимуть
на єдиний файл шаблонів модуля, з якого було створено екземпляр.
Цій команді слід передавати або коректні назви модулів (у цьому випадку буде виконано
пошук файлів модулів із відповідними назвами у різноманітних каталогах файлів
модулів), або абсолютні шляхи до файлів модулів (у цьому випадку файли буде прочитано
безпосередньо). Якщо вказаний файл модуля розташовано поза звичайними каталогами
файлів модулів, буде створено додаткове символічне посилання, які пов'язуватиме його
із каталогом налаштувань модулів, а отже, забезпечуватиме можливість знайти його у
відповідь на запит команд, подібних до start. Файлова система, де зберігаються
пов'язані файли модулів, має бути доступною на момент запуску systemd (наприклад, не
можна зберігати такі файли у /home/ або /var/, якщо цих каталогів немає у кореневій
файловій системі).
Ця команда виводить список виконаних із файловою системою дій. Виведення даних можна
придушити за допомогою параметра --quiet.
Зауважте, що ця дія створює лише символічні посилання, які запропоновано у розділі
[Install] файлів модулів. Хоча ця команда є рекомендованим способом керування
каталогом налаштувань модулів, адміністратор може вносити додаткові зміни вручну,
створюючи або вилучаючи символічні посилання у цьому каталозі. Такі дії можуть
знадобитися для створення налаштувань, які відрізняються від пропонованих у типовому
комплекті для встановлення. Якщо буде внесено такі зміни, адміністратор має, за
потреби, викликати daemon-reload вручну, щоб забезпечити врахування внесених змін.
При використанні цієї дії над модулями без даних щодо встановлення, буде показано
попередження щодо цього. Можна скористатися --no-warn для придушення попередження.
Вмикання модулів не слід плутати із запуском (активацією) модулів, який виконує
команда start. Вмикання і запуск модулів є зовсім різними речима: модулі може бути
увімкнено без запуску і запущено без вмикання. Вмикання лише вписує модуль у
різноманітні відповідні місця (наприклад, робить так, щоб модуль автоматично
запускався під час завантаження системи або з'єднання з комп'ютером певного типу
обладнання). Запуск ініціалізує процес фонової служби (у випадку модулів служб) або
пов'язує модуль із сокетом (у випадку модулів сокетів) тощо.
Залежно від того, чи вказано --system, --user, --runtime або --global, ця команда
вмикає модуль для системи, лише для користувача, який її віддав, лише на одне
завантаження системи або для усіх наступних входів до системи усіх користувачів.
Зауважте, що в останньому випадку не буде перезавантажено налаштування фонових служб
systemd.
Підтримки команди enable для замаскованих модулів не передбачено. Якщо віддати цю
команду для замаскованого модуля, буде повідомлено про помилку.
disable МОДУЛЬ...
Вимикає один або декілька модулів. У результаті з каталогу налаштувань модулів буде
вилучено усі символічні посилання на файли модулів, які є основою вказаних модулів, а
отже, буде скасовано усі зміни, які було внесено командою enable або link. Зауважте,
що це призведе до вилучення усіх символічних посилань на відповідні файли модулів,
зокрема створених вручну посилань, а не лише створених за допомогою enable чи link.
Зауважте, що хоча disable скасовує результати роботи enable, ці дві команди не є
симетричними, оскільки disable може вилучити більше символічних посилань, ніж було
створено попередньою командою enable.
Цій команді можна передавати лише назви чинних модулів, вона не приймає шляхи до
файлів модулів.
Окрім модулів, які буде вказано як аргументи, буде вимкнено усі модулі зі списку у
параметрі Also= розділу [Install] усіх файлів модулів, з якими працюватиме програма.
Ця команда неявним чином перезавантажує налаштування засобу керування системою після
завершення виконання дії. Зауважте, що ця команда не виконує неявного зупинення
модулів, які було вимкнено. Якщо потрібно зупинити роботу таких модулів, або поєднайте
цю команду із перемикачем --now, або потім викличте команду stop із відповідними
аргументами.
Ця команда виводить відомості щодо виконаних із файловою системою дій (вилучення
символічних посилань). Виведення даних можна придушити за допомогою параметра --quiet.
Якщо модуль вимикають, але модулі, які можуть його увімкнути лишатимуться активними,
буде показано попередження зі списком назв відповідних модулів. Можна скористатися
--no-warn для придушення попередження.
Цю команду використовують з --user. Модулі, з якими вона працює, може бути увімкнено у
загальній області видимості, а отже, запущено автоматично навіть після успішного
вимикання в області видимості користувача. У цьому випадку буде виведено попередження,
яке можна придушити за допомогою --no-warn.
Ця команда враховує --system, --user, --runtime, --global та --no-warn у спосіб,
подібний до enable.
Додано у версії 238.
reenable МОДУЛЬ...
Повторно увімкнути один або декілька модулів, як вказано у рядку команди. Це поєднання
послідовних disable і enable. Корисне для скидання символічних посилань на момент
вмикання файла модуля до типових налаштувань, які вказано у розділі [Install]. Цій
команді можна передавати лише назву модуля, вона не приймає шляхів до файла модуля.
Додано у версії 238.
preset МОДУЛЬ...
Скинути стан вмикання-вимикання одного або декількох файлів модулів, які вказано у
рядку команди, до типових значень, які зазначено у файлах наборів правил модулів.
Результат буде той самий, що і у команд disable або enable, залежно від того, що
вказано для модуля у файлах наборів налаштувань.
Скористайтеся параметром --preset-mode= для керування тим, має бути модулі увімкнено і
вимкнено, лише вимкнено чи лише вимкнено.
Якщо у модулі не вказано даних щодо встановлення, його буде без попереджень
проігноровано під час виконання цієї команди. Значенням аргументу МОДУЛЬ має бути
дійсна назва модуля, усі альтернативні назви буде без попереджень проігноровано.
Щоб дізнатися більше про формат правил набору налаштувань, ознайомтеся зі сторінкою
підручника щодо systemd.preset(5).
Додано у версії 238.
preset-all
Скидає усі встановлені файли модулів до типових параметрів, які налаштовано у файлі
правил набору налаштувань (див. вище).
Скористайтеся параметром --preset-mode= для керування тим, має бути модулі увімкнено і
вимкнено, лише вимкнено чи лише вимкнено.
Додано у версії 215.
is-enabled МОДУЛЬ...
Перевіряє, чи увімкнено якийсь із вказаних файлів модулів (як за допомогою команди
enable). Повертає стан виходу 0, якщо увімкнено принаймні один модуль, і ненульовий
стан, якщо це не так. Виводить поточний стан вмикання (див. таблицю). Щоб придушити
виведення даних, скористайтеся параметром --quiet. Щоб було виведено цілі
встановлення, скористайтеся параметром --full.
Таблиця 2. Виведення is-enabled
┌───────────────────┬──────────────────────────┬────────────┐
│Назва │ Опис │ Код виходу │
├───────────────────┼──────────────────────────┼────────────┤
│"увімкнено" │ Увімкнено за допомогою │ │
├───────────────────┤ символічних посилань │ │
│"увімкнено-робота" │ .wants/, .requires/ або │ │
│ │ Alias= (остаточно в │ 0 │
│ │ /etc/systemd/system/ або │ │
│ │ тимчасово у │ │
│ │ /run/systemd/system/). │ │
├───────────────────┼──────────────────────────┼────────────┤
│"пов'язано" │ Стає доступним через │ │
├───────────────────┤ одне або декілька │ │
│"linked-runtime" │ символічних посилань на │ │
│ │ файл модуля (остаточно в │ │
│ │ /etc/systemd/system/ або │ │
│ │ тимчасово у │ > 0 │
│ │ /run/systemd/system/), │ │
│ │ навіть якщо файл модуля │ │
│ │ може зберігатися поза │ │
│ │ шляхом пошуку файлів │ │
│ │ модулів. │ │
├───────────────────┼──────────────────────────┼────────────┤
│"alias" │ Назва альтернативи │ 0 │
│ │ (символічного посилання │ │
│ │ на файл іншого модуля). │ │
├───────────────────┼──────────────────────────┼────────────┤
│"masked" │ Повністю вимкнено так, │ │
├───────────────────┤ що будь-яка дія із │ │
│"masked-runtime" │ запуску завершиться │ │
│ │ помилкою (остаточно в │ > 0 │
│ │ /etc/systemd/system/ або │ │
│ │ тимчасово у │ │
│ │ /run/systemd/systemd/). │ │
├───────────────────┼──────────────────────────┼────────────┤
│"static" │ Файл модуля не увімкнено │ 0 │
│ │ і немає умов для │ │
│ │ вмикання його у розділі │ │
│ │ [Install] файла модуля. │ │
├───────────────────┼──────────────────────────┼────────────┤
│"indirect" │ Сам файл модуля не │ 0 │
│ │ увімкнено, але він │ │
│ │ містить непорожній запис │ │
│ │ Also= у розділі │ │
│ │ [Install] файла модуля, │ │
│ │ де вказано список інших │ │
│ │ файлів модулів, які може │ │
│ │ бути увімкнено, або у │ │
│ │ нього є альтернатива на │ │
│ │ основі символічного │ │
│ │ посилання із іншою │ │
│ │ назвою, яку не вказано у │ │
│ │ Also=. Для файлів │ │
│ │ шаблонів модулів буде │ │
│ │ увімкнено екземпляр, │ │
│ │ відмінний від того, який │ │
│ │ вказано у │ │
│ │ DefaultInstance= is │ │
│ │ enabled. │ │
├───────────────────┼──────────────────────────┼────────────┤
│"disabled" │ Файл модуля не │ > 0 │
│ │ увімкнено, але у ньому │ │
│ │ міститься розділ │ │
│ │ [Install] із настановами │ │
│ │ щодо встановлення. │ │
├───────────────────┼──────────────────────────┼────────────┤
│"generated" │ Файл модуля було │ 0 │
│ │ створено динамічно за │ │
│ │ допомогою інструмента │ │
│ │ створення файлів. Див. │ │
│ │ systemd.generator(7). │ │
│ │ Створені файли модулів │ │
│ │ не може бути увімкнено, │ │
│ │ їх неявним чином вмикає │ │
│ │ їхній засіб породження. │ │
├───────────────────┼──────────────────────────┼────────────┤
│"transient" │ Файл модуля було │ 0 │
│ │ створено динамічно за │ │
│ │ допомогою програмного │ │
│ │ інтерфейсу середовища │ │
│ │ виконання. Тимчасові │ │
│ │ модулі не можна вмикати. │ │
├───────────────────┼──────────────────────────┼────────────┤
│"bad" │ Файл модуля є │ > 0 │
│ │ некоректним або сталася │ │
│ │ якась інша помилка. │ │
│ │ Зауважте, що is-enabled │ │
│ │ насправді не повертатиме │ │
│ │ цього стану, а просто │ │
│ │ виведе повідомлення про │ │
│ │ помилку. Втім, його може │ │
│ │ бути виведено у списку │ │
│ │ файлів модулів, які │ │
│ │ програма виводить, якщо │ │
│ │ використано │ │
│ │ list-unit-files. │ │
├───────────────────┼──────────────────────────┼────────────┤
│"not-found" │ Файла модуля не існує. │ 4 │
└───────────────────┴──────────────────────────┴────────────┘
Додано у версії 238.
mask МОДУЛЬ...
Замаскувати один або декілька модулів, як вказано у рядку команди. Це пов'яже файли
модулів із /dev/null, унеможлививши їх запуск. Це потужніша версія disable, оскільки
вона забороняє будь-який тип активації модуля, включно із вмиканням та активацією
вручну. Будьте обережні із цим параметром. При цьому враховується параметр --runtime
для тимчасового маскування, аж до наступного перезавантаження системи. Можна
скористатися параметром --now для забезпечення паралельної зупинки модулів. Цій
команді можна передавати лише назви модулів, вона не приймає шляхів до файлів модулів.
Зауважте, що у результаті буде створено символічне посилання із назвою модуля у
/etc/systemd/system/ (якщо не вказано --runtime) або /run/systemd/system/ (якщо
вказано --runtime). Якщо відповідний файл модуля у цих каталогах вже існує, дія зазнає
невдачі. Це означає, що дія, в основному, корисна для маскування модулів, які
постачаються виробником обладнання (оскільки, вони зберігаються у
/usr/lib/systemd/system/, а не у згаданих вище двох каталогах), але, типово, не працює
для локально створених модулів (оскільки вони, типово, розміщуються у двох згаданих
вище каталогах). Ті самі обмеження стосуються режиму --user, для якого, втім,
відповідні каталоги розміщуються у домашньому каталозі користувача.
Якщо модуль, який має бути замасковано, може бути увімкнено іншими активними модулями,
буде показано попередження зі списком назв відповідних модулів. Можна скористатися
--no-warn для придушення попередження.
Додано у версії 238.
unmask МОДУЛЬ...
Скасувати маскування одного або декількох файлів модулів, як їх вказано у рядку
команди. Скасовує результат застосування mask. Цій команді можна передавати лише назви
модулів, вона не приймає шляхів до файлів модулів.
Додано у версії 238.
link ШЛЯХ...
Створити посилання на файл модуля, який зберігається поза шляхом пошуку файлів
модулів, до шляху пошуку файлів модулів. Цій команді має бути передано абсолютний шлях
до файла модуля. Результат виконання команди можна скасувати за допомогою disable.
Результатом виконання команди є те, що файл модуля стане доступним для команд,
подібних до as start, хоча сам файл не встановлено безпосередньо до шляху пошуку
модулів. Файлова система, де зберігаються пов'язані файли модулів, має бути доступною
на момент запуску systemd (наприклад, не можна зберігати такі файли у /home/ або
/var/, якщо цих каталогів немає у кореневій файловій системі).
Додано у версії 233.
revert МОДУЛЬ...
Повернути один або декілька файлів модулів до версії їхнього постачальника. Ця команда
вилучає створені файли налаштувань, які вносять зміни до вказаних модулів, а також
будь-які налаштовані користувачами файли модулів, які перевизначають відповідний файл
модуля від постачальника. Зокрема, для модуля «щось.service» буде вилучено відповідні
каталоги «щось.service.d/» із файлами, які у них містяться, у каталогах сталих та
динамічних налаштувань (тобто в /etc/systemd/system і /run/systemd/system); якщо у
файла є версія від постачальника (тобто файл модуля, який зберігається у /usr/), усі
відповідні сталі або динамічні файли, які перевизначають типові, буде також вилучено.
Зауважте, що якщо у файла модуля немає версії від постачальника (тобто його визначено
лише у /etc/systemd/system або /run/systemd/system, але немає файла модуля, який
зберігається у /usr/), файл не буде вилучено. Крім того, якщо модуль замасковано, його
маскування буде знято.
Насправді, цією командою можна скористатися для скасування усіх змін, які було внесено
за допомогою команд systemctl edit, systemctl set-property і systemctl mask. Команда
також повертає дію початкового файла модуля із його параметрами.
Додано у версії 230.
add-wants ЦІЛЬ МОДУЛЬ..., add-requires ЦІЛЬ МОДУЛЬ...
Додає залежності «Wants=» або «Requires=», відповідно, для вказаної ЦІЛІ для одного
або декількох модулів.
Ця команда враховує --system, --user, --runtime і --global у спосіб, подібний до
enable.
Додано у версії 217.
edit МОДУЛЬ...
Редагувати або замінити вставний фрагмент або основний файл модуля для розширення або
перевизначення вказаного модуля.
Залежно від того, вказано --system (типовий варіант), --user чи --global, ця команда
працюватиме із файлами загальносистемних модулів, файлами модулів користувача, який її
віддав, або файлами модулів, які є спільними для усіх користувачів.
Буде викликано редактор (див. розділ «Середовище» нижче) для тимчасових файлів, які
будуть записані у справжнє розташування, якщо редактор завершить роботу успішно. Після
завершення редагування конфігурацію буде перезавантажено, еквівалентно до systemctl
daemon-reload --system або systemctl daemon-reload --user. Для edit --global
перезавантаження не буде виконано, і зміни набудуть чинності лише для наступних входів
до системи (або після запиту щодо перезавантаження іншим способом).
Якщо вказано --full, буде створено або редаговано замінник основного файла модуля. У
протилежному випадку, буде створено або редаговано вставний файл.
Якщо вказано --drop-in=, заданий файл вставлення буде використано замість типового
override.conf.
Модуль має існувати, тобто має існувати його головний файл. Якщо вказано --force, цю
вимогу буде проігноровано, і може бути створено новий модуль (з --full) або може бути
створено вставлення для модуля, якого не існує.
Якщо вказано --runtime, зміни буде внесено до /run/ тимчасово — їх буде втрачено під
час перезавантаження системи.
Якщо вказано --stdin, новий вміст буде прочитано зі стандартного джерела вхідних
даних. У цьому режимі попередній вміст файла буде втрачено.
Якщо тимчасовий файл буде порожнім на момент виходу, внесені до пов'язаного модуля
зміни буде скасовано.
Зауважте, що цю команду не можна використовувати для віддаленого редагування модулів,
і ви не можете тимчасово редагувати модулі, які зберігаються в /etc/, оскільки вони
мають вищий пріоритет над тими, які зберігаються у /run/.
Додано у версії 218.
get-default
Повертає типову ціль завантаження системи. У результаті буде повернуто назву модуля, з
яким пов'язано (символічним посиланням) default.target.
Додано у версії 205.
set-default ЦІЛЬ
Встановити типову ціль завантаження системи. У результаті буде встановлено (за
допомогою символічних посилань) альтернативу для default.target так, щоб вона
вказувала на заданий цільовий модуль.
Додано у версії 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
Створити дамп блоку середовища засобу керування systemd. Це блок середовища, який буде
передано усім процесам, які породжено засобом керування системою. Дамп блоку
середовища буде створено у прямій формі, яка пасує для передавання у більшість
командних оболонок. Якщо у значеннях змінних немає спеціальних символів або пробілів,
екранування не виконуватиметься, а встановлення значень відбувається у формі
«ЗМІННА=значення». Якщо у значеннях містяться пробіли або символи, які мають
спеціальне значення у командній оболонці, використовують екранування символом долара і
одинарних лапок, а встановлення значень відбувається у формі «ЗМІННА=$'значення'».
Відомо, що підтримку таких синтаксичних конструкцій передбачено у bash(1), zsh(1),
ksh(1), та ash(1) з busybox(1), але не у dash(1) або fish(1).
Зауважте, що буде показано задіяний блок, тобто комбінацію змінних середовища, яку
налаштовано за допомогою файлів налаштувань, засобів побудови середовища та IPC (тобто
за допомогою set-environment, яку описано нижче). На момент відгалуження процесу
модуля цей поєднаний блок середовища буде далі поєднано зі змінними середовища окремих
модулів, які не буде показано цією командою.
set-environment ЗМІННА=ЗНАЧЕННЯ...
Встановити одну або декілька змінних середовища засобу керування службами, як вказано
у рядку команди. Виконання цієї команди завершиться помилкою, якщо назви і значення
змінних не відповідають вказаним вище правилам.
Зауважте, що це працює у блоці середовища, окремому від блоку середовища,
налаштованого за допомогою налаштувань засобу керування службами і засобів створення
середовища. Щоразу під час виклику процесу два блоки поєднуються (зі включенням усіх
змінних середовища окремих служб) і передаються процесу. Команда show-environment
покаже комбінацію цих блоків, див. вище.
Додано у версії 233.
unset-environment ЗМІННА...
Скасувати встановлення однієї або декількох змінних середовища засобу керування
systemd. Якщо вказано лише назву змінної, її буде вилучено незалежно від значення.
Якщо вказано змінну і значення, змінну буде вилучено, лише якщо вона має вказане
значення.
Зауважте, що це працює у блоці середовища, окремому від блоку середовища,
налаштованого за допомогою налаштувань засобу керування службами і засобів створення
середовища. Щоразу під час виклику процесу два блоки поєднуються (зі включенням усіх
змінних середовищ окремих служб) і передаються процесу. Команда show-environment
покаже комбінацію блоків, див. вище. Зауважте, що це означає, що цю команду не можна
використовувати для скасування визначення змінних середовища з файлів налаштувань
засобу керування службами або із засобів створення середовища.
Додано у версії 233.
import-environment ЗМІННА...
Імпортувати усі, одну або декілька змінних середовища, які встановлено на клієнті, до
блоку середовища засобу керування systemd. Якщо передано список назв змінних
середовища, значення на боці клієнта буде імпортовано до блоку середовища засобу
керування. Якщо якісь назви не є коректними назвами змінних середовища або мають
некоректні значення за правилами, які описано вище, буде повідомлено про помилку. Якщо
не буде передано аргументів, буде імпортовано увесь блок середовища, який успадковано
systemctl. У цьому режимі усі успадковані некоректні змінні середовища буде без
повідомлень проігноровано.
Імпортування усього блоку середовища (виклик цієї команди без аргументів) вважається
застарілим. Оболонка встановлює десятки змінних, які мають лише локальне значення, і
які призначено лише для процесів, які є нащадками командної оболонки. Такі змінні у
загальному блоці середовища є конфліктними щодо інших процесів.
Додано у версії 209.
Команди стану засобу керування
daemon-reload
Перезавантажити налаштування засобу керування systemd. У результаті буде перезапущено
усі засоби породження (див. systemd.generator(7)), перезавантажено усі файли модулів і
повторно створено усе дерево залежностей. Під час перезавантаження фонової служби
лишатимуться доступними усі сокети systemd, на яких програма очікує дані від імені
користувача.
Цю команду не слід плутати із командою reload.
daemon-reexec
Повторно виконати засіб керування systemd. У результаті стан засобу керування буде
переведено у послідовну форму, процес буде повторно виконано, а потім стан буде знову
переведено у попередню форму. Ця команда малокорисна, якщо ви не переймаєтеся
діагностикою або оновленням пакунків. Іноді, у ній може бути користь, як у потужному
варіанті daemon-reload. Під час повторного виконання фонової служби лишатимуться
доступними усі сокети systemd, на яких програма очікує дані від імені користувача.
log-level [РІВЕНЬ]
Якщо не вказано аргументу, буде виведено поточний рівень журналювання засобу
керування. Якщо вказано необов'язковий аргумент РІВЕНЬ, команда змінить поточний
рівень журналювання засобу керування на РІВЕНЬ (приймаються ті самі значення, що і для
параметра --log-level=, який описано у systemd(1)).
Додано у версії 244.
log-target [ЦІЛЬ]
Якщо не вказано аргументу, буде виведено поточну ціль журналювання засобу керування.
Якщо вказано необов'язковий аргумент ЦІЛЬ, команда змінить поточну ціль журналювання
засобу керування на ЦІЛЬ (приймаються ті самі значення, що і для параметра
--log-target=, який описано у systemd(1)).
Додано у версії 244.
service-watchdogs [yes|no]
Якщо не вказано аргументу, вивести поточний стан динамічних засобів спостереження за
службами засобу керування системою. Якщо вказано необов'язковий булевий аргумент,
увімкнути або вимкнути динамічні засоби спостереження за службами (WatchdogSec=) та
термінові дії (наприклад, OnFailure= або StartLimitAction=); див. systemd.service(5).
Цей параметр не впливає на апаратний засіб спостереження.
Додано у версії 244.
Команди системи
is-system-running
Перевіряє, чи є система працездатною. Повертає «успіх» (код виходу 0), якщо система є
повністю працездатною, а саме, не перебуває у режимі запуску, вимикання або супроводу
і не має служб у стані помилки. В інших випадках буде повернуто стан помилки
(ненульовий код виходу). Крім того, до стандартного виведення буде виведено короткий
рядок поточного стану, див. наведену нижче таблицю. Скористайтеся --quiet, щоб
придушити виведення цих даних.
Скористайтеся --wait, щоб наказати системі чекати, аж доки завершиться процес
завантаження, перш ніж виводити поточний стан і повертати відповідний стан помилки.
Якщо використано --wait, про стани initializing та starting повідомлено не буде.
Замість цього команду буде заблоковано, аж до досягнення наступного стану (зокрема
running або degraded).
Таблиця 3. Виведення is-system-running
┌─────────────┬──────────────────────────┬────────────┐
│Назва │ Опис │ Код виходу │
├─────────────┼──────────────────────────┼────────────┤
│initializing │ Раннє завантаження, до │ > 0 │
│ │ досягнення basic.target │ │
│ │ або входу до стану │ │
│ │ maintenance. │ │
├─────────────┼──────────────────────────┼────────────┤
│starting │ Пізнє завантаження, до │ > 0 │
│ │ того, як черга завдань │ │
│ │ стане бездіяльною │ │
│ │ уперше, або буде │ │
│ │ досягнуто одну з цілей │ │
│ │ порятунку системи. │ │
├─────────────┼──────────────────────────┼────────────┤
│running │ Система є повноцінно │ 0 │
│ │ функціональною. │ │
├─────────────┼──────────────────────────┼────────────┤
│degraded │ Система є │ > 0 │
│ │ функціональною, але один │ │
│ │ або декілька модулів є │ │
│ │ непрацездатними. │ │
├─────────────┼──────────────────────────┼────────────┤
│maintenance │ Активною є ціль │ > 0 │
│ │ порятунку або критична │ │
│ │ ціль. │ │
├─────────────┼──────────────────────────┼────────────┤
│stopping │ Засіб керування завершує │ > 0 │
│ │ роботу. │ │
├─────────────┼──────────────────────────┼────────────┤
│offline │ Засіб керування не │ > 0 │
│ │ запущено. Зокрема, це │ │
│ │ стан роботи, якщо як │ │
│ │ засіб керування системою │ │
│ │ (PID 1) запущено │ │
│ │ несумісну програму. │ │
├─────────────┼──────────────────────────┼────────────┤
│unknown │ Не вдалося визначити │ > 0 │
│ │ функціональний стан │ │
│ │ через брак ресурсів або │ │
│ │ з іншої причини. │ │
└─────────────┴──────────────────────────┴────────────┘
Додано у версії 215.
default
Увійти в типовий режим. Це еквівалентно systemctl isolate default.target. Цю операцію
типово заблоковано, для запиту асинхронної поведінки скористайтесь --no-block.
rescue
Увійти в режим порятунку. Це еквівалентно systemctl isolate rescue.target. Цю операцію
типово заблоковано, для запиту асинхронної поведінки скористайтесь --no-block.
emergency
Увійти в аварійний режим. Це еквівалентно systemctl isolate emergency.target. Цю
операцію типово заблоковано, для запиту асинхронної поведінки скористайтесь
--no-block.
halt
Вимкнути і зупинити систему. Це майже еквівалентно systemctl start halt.target
--job-mode=replace-irreversibly --no-block, але також виводить повідомлення на стіні
для всіх користувачів. Ця команда є асинхронною; повернення відбувається після того,
як дію зупинки поставлено в чергу, не чекаючи її завершення. Зауважте, що ця операція
просто зупинить ядро ОС після закінчення роботи, залишивши апаратні засоби
увімкненими. Для вимкнення системи скористайтесь systemctl poweroff (див. нижче).
Якщо в поєднанні з --force, закриття всіх запущених служб пропускається, однак усі
процеси припиняються, а всі файлові системи буде демонтовано або змонтовано лише для
читання, одразу після чого відбувається зупинка системи. Якщо --force вказано двічі,
операція виконується негайно без завершення будь-яких процесів або демонтування
будь-яких файлових систем. Це може призвести до втрати даних. Зауважте, що коли
--force вказано двічі, операцію зупинки виконує сама systemctl, без зв'язку із засобом
керування системою. Це означає, що команда має бути успішною, навіть якщо засіб
керування системою зазнав збою.
Якщо поєднати з --when=, вимикання буде заплановано після вказаної часової позначки. А
--when=cancel скасує вимикання.
poweroff
Закрити і вимкнути систему. Це здебільшого еквівалентно systemctl start
poweroff.target --job-mode=replace-irreversibly --no-block, але також друкує
повідомлення на стіні для всіх користувачів. Ця команда є асинхронною; повернення
відбувається після того, як операцію вимкнення поставлено в чергу, не чекаючи її
завершення.
Ця команда враховує --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
Вимкнути і перезавантажити систему за допомогою kexec. Ця команда завантажить ядро
kexec, якщо його ще не завантажено або його робота завершилася помилкою. Ядро можна
завантажити раніше окремим кроком; це іноді корисно, якщо бажаними є нетиповий initrd
або додаткові параметри командного рядка ядра. Можна скористатися --force для
продовження роботи без ядра kexec тобто для виконання звичайного перезавантаження.
Останній крок перезавантаження є рівноцінним systemctl start kexec.target
--job-mode=replace-irreversibly --no-block.
Щоб завантажити ядро, буде виконано нумерацію за Специфікацією завантажувачів[1] і
завантажено типовий запис завантаження. Для успішності цього кроку система має
використовувати UEFI, і має бути належним чином налаштовано записи завантажувача. Для
виведення списку записів завантаження можна скористатися bootctl list, див.
bootctl(1).
Ця команда є асинхронною; повернення відбувається після того, як операцію зупинки
поставлено в чергу, не чекаючи її завершення.
Ця команда враховує --force і --when= у спосіб, подібний до halt.
Якщо за допомогою kexec --load завантажено нове ядро, буде виконано kexec при виклику
reboot, якщо не встановлено значення SYSTEMCTL_SKIP_AUTO_KEXEC=1.
soft-reboot
Закрити і перезавантажити простір користувача. Це еквівалентно systemctl start
soft-reboot.target --job-mode=replace-irreversibly --no-block. Ця команда є
асинхронною; повернення відбувається після того, як операцію зупинки поставлено в
чергу, не чекаючи її завершення.
Ця команда враховує --force і --when= у спосіб, подібний до halt.
У результаті цієї дії буде перезавантажено лише простір користувача, а ядро лишиться
працювати. Див. systemd-soft-reboot.service(8), щоб дізнатися більше.
Якщо у «/run/nextroot/» налаштовано нову кореневу файлову систему, буде виконано
soft-reboot при виклику reboot, якщо не встановлено значення
SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1.
Додано у версії 254.
exit [КОД_ВИХОДУ]
Попросити засіб керування службами завершити свою роботу. Підтримку передбачено лише
для засобів керування службами користувача (тобто у поєднанні із параметром --user)
або у контейнерах. В усіх інших аспектах, є еквівалентом poweroff. Ця команда є
асинхронною; вона повертає керування після додавання до черги дії з виходу, без
очікування на завершення дії.
Засіб керування службами завершить роботу із вказаним кодом виходу, якщо передано
КОД_ВИХОДУ.
Додано у версії 227.
switch-root [КОРІНЬ [ІНІЦІАЛІЗАЦІЯ]]
Перемикає на інший кореневий каталог і виконує новий процес засобу керування системою
у ньому. Цю команду призначено для використання в initrd і переходу з процесу засобу
керування системою initrd (тобто процесу «init», PID 1) до основного процесу засобу
керування системою, який завантажується з самих кореневих файлів основної системи. Цей
виклик приймає два аргументи: каталог, який має стати новим кореневим каталогом, і
шлях до виконуваного файла нового засобу керування системою, який слід виконувати як
PID 1. Якщо пропущено обидва або перший є порожнім рядком, типово буде використано
/sysroot/.Якщо останній не буде вказано або буде вказано порожній рядок, буде виконано
автоматичний пошук виконуваного файла systemd, який і буде використано як засіб
керування службами. Якщо не вказано шляху до засобу керування системою, цей шлях є
порожнім рядком або він збігається зі шляхом до виконуваного файла systemd, основному
засобу керування системою буде передано стан процесу засобу керування системою initrd,
що надасть змогу пізніше виконати інтроспекцію стану служб, які було включено до фази
завантаження initrd.
Додано у версії 209.
sleep
Перевести систему у режим сну за допомогою suspend, hibernate, hybrid-sleep або
suspend-then-hibernate. Варіант присипляння буде автоматично вибрано
systemd-logind.service(8). Типово буде використано suspend-then-hibernate із резервним
варіантом suspend, а потім hibernate, якщо підтримки таких режимів не передбачено.
Зверніться до опису параметра SleepOperation= у logind.conf(5) для отримання
додаткової інформації. Ця команда є асинхронною, вона повертає керування після того,
як операцію присипляння буде успішно поставлено до черги. Вона не чекатиме на
завершення циклу сну/відновлення.
Додано у версії 256.
suspend
Призупинити роботу системи. Ця команда увімкне активацію модуля спеціальної цілі
suspend.target. Ця команда є асинхронною. Вона поверне керування після успішного
додавання до черги дії із призупинення. Команда не чекатиме на завершення циклу
призупинення-відновлення роботи.
Якщо вказано --force, а systemd-logind повернула помилку для операції, помилку буде
проігноровано, а операцію спробують виконати повторно безпосередньо через запуск
цільового модуля.
hibernate
Приспати систему. Ця команда увімкне активацію модуля спеціальної цілі
hibernate.target. Ця команда є асинхронною. Вона поверне керування після успішного
додавання до черги дії із присипляння. Команда не чекатиме на завершення циклу
присипляння-розморожування.
Ця команда враховує --force у той самий спосіб, у який це робить suspend.
hybrid-sleep
Приспати і призупинити роботу системи. Ця команда увімкне активацію модуля спеціальної
цілі hybrid-sleep.target. Ця команда є асинхронною. Вона поверне керування після
успішного додавання до черги дії із гібридного присипляння. Команда не чекатиме на
завершення циклу присипляння-пробудження.
Ця команда враховує --force у той самий спосіб, у який це робить suspend.
Додано у версії 196.
suspend-then-hibernate
Призупинити роботу системи і приспати її, коли заряд акумулятора буде вичерпано, або
із затримкою, визначеною у systemd-sleep.conf. Ця команда увімкне активацію модуля
спеціальної цілі suspend-then-hibernate.target. Ця команда є асинхронною. Вона поверне
керування після успішного додавання до черги дії із гібридного присипляння. Команда не
чекатиме на завершення циклу присипляння-пробудження або призупинення-розморожування.
Ця команда враховує --force у той самий спосіб, у який це робить suspend.
Додано у версії 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=
Аргументом є список відокремлених комами типів модулів, зокрема service і socket. Якщо
модулі виведено у списку list-units, list-dependencies, show або status, буде показано
лише модулі вказаних типів. Типово буде показано модулі усіх типів.
В особливому випадку, якщо одним з аргументів є help, буде виведено список усіх
дозволених значень, і програма завершить роботу.
--state=
Аргументом має бути список відокремлених комами станів LOAD, SUB або ACTIVE модуля.
При побудові списку за допомогою list-units, list-dependencies, show або status
вивести лише ті модулі, які перебувають у вказаних станах. Скористайтеся
--state=failed або --failed, щоб отримати список лише модулів із помилками.
В особливому випадку, якщо одним з аргументів є help, буде виведено список усіх
дозволених значень, і програма завершить роботу.
Додано у версії 206.
-p, --property=
При виведенні властивостей модуля, завдання чи засобу керування за допомогою команди
show обмежитися виведенням властивостей, які вказано в аргументі. Аргументом має бути
список відокремлених комами назв властивостей, наприклад «MainPID». Якщо властивостей
не вказано, буде виведено усі властивості. Якщо параметр вказано декілька разів, буде
виведено усі властивості із вказаними назвами. Для назв властивостей буде реалізовано
можливість доповнення у командній оболонці.
Для самого засобу керування systemctl show виведе усі доступні властивості, більшість
з яких є похідними або дуже схожими на параметри, описані на сторінці підручника щодо
systemd-system.conf(5).
Властивості модулів різних типів є доволі різними, тому виведення даних для будь-якого
модуля (навіть такого, якого не існує) є способом ознайомитися зі списком властивостей
відповідного типу. Так само, виведення списку властивостей для довільного завдання
призведе до виведення властивостей, які є в усіх завдань. Властивості модулів
задокументовано на сторінці підручника systemd.unit(5), а сторінками для окремих типів
модулів є systemd.service(5), systemd.socket(5) тощо.
-P
Еквівалент --value --property=, тобто виводить значення властивості без назви
властивості або «=». Зауважте, що навіть одноразове використання -P стoсуватиметься
усіх властивостей зі списку, який отримано за допомогою -p/--property=.
Додано у версії 246.
-a, --all
При побудові списку модулів з використанням list-units, також вивести дані неактивних
модулів та модулів, які є похідними від інших модулів. При показі властивостей модуля,
завдання або засобу керування вивести усі властивості, незалежно від того, було
встановлено для них значення чи ні.
Щоб отримати список усіх встановлених у файловій системі модулів, скористайтеся
замість цієї команди командою list-unit-files.
При побудові списку модулів за допомогою list-dependencies вивести рекурсивні
залежності усіх залежних модулів (типово, буде виведено лише залежності цільових
модулів).
Якщо використано разом із status, показувати повідомлення журналу повністю, навіть
якщо вони містять непридатні до друку символи або є дуже довгими. Типово, поля із
непридатними до друку символами обрізаються як «бінарні дані». (Зауважте, що програма
поділу даних на сторінки може виконати додаткове екранування непридатних до друку
символів.)
-r, --recursive
При побудові списку модулів також вивести дані модулів локальних контейнерів. Записи
модулів локальних контейнерів матимуть префікс — назву контейнера, відокремлений від
назви одинарною двокрапкою («:»).
Додано у версії 212.
--reverse
Вивести зворотні залежності між модулями з використанням list-dependencies, тобто
слідувати залежностям типу WantedBy=, RequiredBy=, UpheldBy=, PartOf=, BoundBy=,
замість Wants= і подібних.
Додано у версії 203.
--after
Із list-dependencies вивести дані модулів, які перебувають у порядку перед вказаним
модулем. Іншими словами, вивести рекурсивний список модулів із залежністю After=.
Зауважте, що будь-яку залежність After= буде автоматично віддзеркалено для створення
залежності Before=. Тимчасові залежності може бути вказано явним чином, але також буде
створено неявним чином для модулів, які є цілями WantedBy= (див. systemd.target(5)), і
як результат інших інструкцій (наприклад RequiresMountsFor=). Явні і неявні
впроваджені залежності буде виведено у відповідь на команду list-dependencies.
Якщо передано команді list-jobs для кожного виведеного завдання вивести, які інші
завдання очікують на нього. Можна поєднати з --before, щоб програма вивела і завдання,
які очікують на якесь завдання, і усі завдання, на які очікує якесь завдання.
Додано у версії 203.
--before
Із list-dependencies вивести дані модулів, які перебувають у порядку після вказаного
модуля. Іншими словами, вивести рекурсивний список модулів із залежністю Before=.
Якщо передано команді list-jobs для кожного виведеного завдання вивести, які інші
завдання очікують на нього Можна поєднати з --after, щоб програма вивела і завдання,
які очікують на якесь завдання, і усі завдання, на які очікує якесь завдання.
Додано у версії 212.
--with-dependencies
Якщо їх використано разом із status, cat, list-units і list-unit-files, ці команди
виводять дані усіх вказаних модулів і залежності для цих модулів.
Змінити типи показаних залежностей можна за допомогою параметрів --reverse, --after,
--before.
Додано у версії 245.
-l, --full
Не обривати багатокрапкою надто довгі назви модулів, записи ієрархії процесів,
виведені повідомлення журналу, і не обрізати описи модулів у виведених даних status,
list-units, list-jobs і list-timers.
Крім того, вивести цілі встановлення у даних, які виведено is-enabled.
--value
При виведенні властивостей за допомогою show вивести лише значення без назви
властивості і символу «=». Див. також параметр -P вище.
Додано у версії 230.
--show-types
При показі сокетів вивести тип сокета.
Додано у версії 202.
--job-mode=
При додаванні нового завдання до черги цей параметр керує тим, як працювати з
завданнями, які вже перебувають у черзі. Приймає одне зі значень, «fail», «replace»,
«replace-irreversibly», «isolate», «ignore-dependencies», «ignore-requirements»,
«flush», «triggering» або «restart-dependencies». Типовим є «replace», якщо не
використано команду isolate, яка неявним чином встановлює режим завдання «isolate».
Якщо вказано «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
При додавання завдання модуля до черги обробки (наприклад, у результаті виклику
systemctl start або подібної команди) вивести короткі відомості щодо усіх завдань з
черги, що стосуються одразу запитаного завдання та усіх завдань, які додано через
залежності модуля. Зауважте, що до виведених даних буде включено лише завдання, які є
безпосередньою частиною запитаної операції. Може так статися, що виконання програмного
коду запуску служби у результаті виконання завдань з черги може потребувати подальшого
запуску завдань. Це означає, що завершення виконання завдань зі списку може
потребувати ширшого кола завдань, ніж буде виведено у списку.
Додано у версії 242.
--fail
Скорочення для --job-mode=fail.
Якщо використано у поєднанні з командою kill, результатом дії буде помилка, якщо не
завершено роботу жодного модуля.
Додано у версії 227.
--check-inhibitors=
Якщо надіслано запит щодо вимикання або присипляння системи, цей параметр керує тим,
як працювати із блокуваннями уповільнення. Приймає одне з таких значень: «auto», «yes»
або «no». Типовим варіантом є «auto». Цей варіант працює як «yes» для інтерактивних
викликів (тобто викликів з інтерактивного термінала) і «no» для неінтерактивних
викликів. «yes» дозволить запиту брати до уваги блокування уповільнення. «no»
дозволить запиту ігнорувати блокування уповільнення.
Програми можуть встановлювати блокування уповільнення для уникнення переривання
вимиканням системи або станом сну певних важливих дій (зокрема процедури записування
компакт-диска чи подібних операцій). Створити ці блокування може будь-який користувач,
а привілейовані користувачі можуть перевизначати ці блокування. Якщо визначено якесь
блокування, запити щодо вимикання або присипляння, зазвичай, завершуватимуться
помилкою (якщо користувач не є привілейованим). Втім, якщо вказано «no» або «auto» для
неінтерактивних запитів, буде виконано спробу дії. Якщо існують блокування, дія може
потребувати додаткових привілеїв.
Використання параметра --force є іншим способом перевизначити уповільнювачі.
Додано у версії 248.
-i
Скорочення для --check-inhibitors=no.
Додано у версії 198.
--dry-run
Просто вивести список дій. У поточній версії передбачено підтримку у командах halt,
poweroff, reboot, kexec, suspend, hibernate, hybrid-sleep, suspend-then-hibernate,
default, rescue, emergency і exit.
Додано у версії 236.
-q, --quiet
Придушити виведення результатів різноманітних команд, а також підказок щодо обрізаних
рядків журналу. Це не може придушити виведення команд, для яких єдиним результатом
роботи є виведення даних (подібних до show). Повідомлення про помилки виводяться
завжди.
--no-warn
Не створювати попередження, які буде типово показано у таких випадках:
• якщо systemctl викликано без змонтованої procfs у /proc/,
• якщо використано enable або disable для модулів без даних щодо встановлення (тобто
тих, у яких розділ [Install] є порожнім),
• якщо використано disable у поєднанні із --user для модулів, які увімкнено у
загальній області видимості,
• якщо зупинено (stop), вимкнено (disable) або замасковано (mask), модуль все одно
має активні модулі перемикання,
• якщо файл модуля змінено і потрібна операція daemon-reload.
Додано у версії 253.
--no-block
Не очікувати синхронно на завершення запитаної дії. Якщо цього не вказано, завдання
буде перевірено, додано до черги, а systemctl очікуватиме, аж доки буде завершено
запуск модуля. Якщо передано цей аргумент, завдання буде лише перевірено і додано до
черги обробки. Цей параметр не можна поєднувати із --wait.
--wait
Якщо використано із start або restart, синхронно чекати на переривання запущених
модулів знову. Цей параметр не можна поєднувати з --no-block. Зауважте, що очікування
буде необмеженим, якщо вказаний модуль не перерве роботи (самостійно або його не буде
зупинено явним чином); подібний випадок може трапитися зі службами, у яких використано
«RemainAfterExit=yes».
Якщо використано з is-system-running, очікувати на завершення процедури завантаження,
перш ніж повертати керування.
Якщо використано разом із kill, зачекати, доки буде перервано роботу модулів, яким
надіслано сигнал. Зауважте, що програма не перериватиме чекання, якщо будь-який
заданий модуль не завершить роботу.
Додано у версії 232.
--user
Обмінюватися даними із засобом керування службами користувача, який викликав команду,
а не з засобом керування службами системи.
--system
Обмінюватися даними із загальносистемним засобом керування службами. Це неявний
типовий варіант.
--failed
Вивести список усіх модулів у стані помилки. Є еквівалентом --state=failed.
Додано у версії 233.
--no-wall
Не надсилати повідомлень на стіну перед перериванням, вимиканням і перезавантаженням.
--global
Якщо використано разом із enable або disable, працювати із загальним каталогом
налаштувань користувачів, таким чином, вмикати або вимикати файл модуля на загальному
рівні для усіх майбутніх входів до системи усіх користувачів.
--no-reload
Якщо використано разом із enable, disable, preset, mask або unmask, не
перезавантажувати неявним чином налаштування фонових служб після внесення змін.
--no-ask-password
Якщо використано разом із start та пов'язаними командами, вимикає запити щодо паролів.
Базові служби можуть потребувати введення пароля або рядка ключа, наприклад, Для
розблоковування дисків системи або сертифікатів шифрування. Якщо цей параметр не
вказано, і команду викликано з термінала, systemctl проситиме користувача ввести
потрібні реєстраційні дані у терміналі. Скористайтеся цим параметром, щоб вимкнути цю
поведінку. Якщо параметр вказано, пароль має бути надано у якийсь інший спосіб
(наприклад, за допомогою графічних агентів введення пароля), інакше служба може
завершити роботу із повідомленням про помилку. Крім того, цей параметр вимикає запити
щодо розпізнавання користувача для виконання привілейованих дій.
--kill-whom=
Якщо використано разом із kill, визначає, яким процесам слід надіслати сигнал UNIX.
Має бути одним з таких значень: main, control або all — для вибору того, слід
припинити роботу основного процесу, процесу керування або усіх процесів
модуля.Основним процесом модуля є процес, який визначає його термін роботи. Процесом
керування модуля є процес, який було викликано засобом керування для виконання змін
стану модуля. Наприклад, усі процеси, які запущено через використання параметрів
ExecStartPre=, ExecStop= або ExecReload= модулів служб, є процесами керування.
Зауважте, що одночасно у кожного модуля може бути лише один процес керування, оскільки
одночасно можна виконувати лише одну зміну стану. Для служб типу Type=forking,
процесом керування є початковий процес, який запущено засобом керування для
ExecStart=, а повністю відгалужений від нього процес вже буде розглядатися як основний
процес модуля (якщо його можна визначити). У цьому відмінність від модулів служб інших
типів, де відгалужений засобом керування процес для ExecStart= є завжди самим по собі
основним процесом. Модуль служби складається з нуля або одного основного процесу, нуля
або одного процесу керування і будь-якої кількості додаткових процесів. Втім,
процесами цих типів керують не усі типи модулів. Наприклад, для модулів монтування
визначено процеси керування (ними є виклики /usr/bin/mount і /usr/bin/umount), але
основного процесу не визначено. Якщо не вказано, типовим варіантом є all.
Додано у версії 252.
--kill-value=INT
Якщо використано з командою kill, додає до черги сигнал разом із вказаним
цілочисельним параметром для вказаних процесів. Цією дією можна скористатися, лише для
сигналів реального часу POSIX (тобто --signal=SIGRTMIN+... або --signal=SIGRTMAX-...);
вона забезпечує створення сигналів за допомогою системного виклику sigqueue(3), а не
kill(3). Вказане значення має бути 32-бітовим цілим числом зі знаком; його можна
вказати у десятковій, шістнадцятковій (якщо додано префікс «0x»), вісімковій (якщо
додано префікс «0o») або двійковій (якщо додано префікс «0b») системі числення
Якщо використано цей параметр, сигнал буде додано до черги лише для процесу керування
або основного процесу модуля, ніколи для інших процесів, які належать модулю, тобто
--kill-whom=all стосуватиметься лише основного і керівного процесів, але не інших
процесів.
Додано у версії 254.
-s, --signal=
Якщо використано разом із kill, вибрати, який сигнал буде надіслано до вибраних
процесів. Має бути один із відомих специфікаторів сигналів, зокрема SIGTERM, SIGINT
або SIGSTOP. Якщо не вказано, типовим є сигнал SIGTERM.
Використання особливого значення «help» призведе до виведення списку відомих значень і
негайного виходу з програми, а особливого значення «list» — до списку відомих значень
разом із числовими номерами сигналів і негайного виходу з програми.
--what=
Вибрати тип ресурсів окремих модулів, які слід вилучити при виклику команди clean,
див. вище. Приймає одне з таких значень: configuration, state, cache, logs, runtime,
fdstore, — для вибору типу ресурсу. Цей параметр можна вказувати декілька разів — буде
вилучено ресурси усіх вказаних типів. Також приймає особливе значення all, як
скорочення для визначення ресурсів усіх шести типів. Якщо цей параметр не вказано,
типовою є комбінації cache, runtime і fdstore, тобто двох типів ресурсів, які,
загалом, вважаються зайвими і можуть бути відтворені під час наступного виклику.
Зауважте, що явне вилучення типу ресурсу fdstore є корисним, лише якщо увімкнено
параметр FileDescriptorStorePreserve=, оскільки інакше сховище дескрипторів файлів
буде автоматично очищено при завершенні роботи модуля.
Додано у версії 243.
-f, --force
Якщо використано у поєднанні із enable, перезаписати усі наявні конфліктні символічні
посилання.
Якщо використано разом із edit, створити усі вказані модулі, яких ще не існує.
Якщо використано із suspend, hibernate, hybrid-sleep або suspend-then-hibernate,
помилку, яку повертає systemd-logind, буде проігноровано, а операцію буде виконано
безпосередньо через запуск відповідних модулів.
Якщо використано разом із halt, poweroff, reboot або kexec, виконати вибрану дію без
завершення роботи усіх модулів. Втім, усі процеси буде завершено у примусовому режимі,
а усі файлові системи буде демонтовано або повторно змонтовано у режимі лише читання.
Отже, це доволі сильнодійний, але відносно безпечний спосіб надсилання запиту щодо
негайного перезавантаження. Якщо --force вказано двічі для цих дій (окрім kexec), їх
буде виконано негайно, без переривання будь-яких процесів і демонтування будь-яких
файлових систем.
Попередження
Визначення --force двічі із будь-якою з цих операцій може призвести до втрати
даних. Зауважте, що коли --force вказано двічі, вибрану операцію виконує сама
systemctl, без зв'язку із засобом керування системою. Це означає, що команда має
бути успішною, навіть якщо засіб керування системою зазнав збою.
--message=
Якщо використано разом із halt, poweroff or reboot, встановити коротке повідомлення,
яке пояснюватиме причину дії. Повідомлення буде записано до журналу разом із типовим
повідомленням про завершення роботи.
Додано у версії 225.
--now
Якщо використано разом з enable, модулі також буде запущено. Якщо використано разом із
disable або mask, модулі також буде зупинено. Дії із запуску або зупинення будбе
виконано, лише якщо відповідні дії вмикання або вимикання були успішними.
Додано у версії 220.
--root=
Якщо використано разом із enable/disable/is-enabled (і пов'язаними командами),
використати вказаний шлях до кореневої теки при пошуку файлів модулів. Якщо вказано
цей параметр, systemctl працюватиме із файловою системою безпосередньо, замість обміну
даними з фоновою службою systemd для внесення змін.
--image=образ
Приймає шлях до файла образу диска або вузла блокового пристрою Якщо вказано, усі дії
буде застосовано до файлової системи у вказаному образі диска. Цей параметр подібний
до --root=, але працює з файловою системою, що зберігається в образах диска або
блокових пристроїв. Образ диска або має містити файлову систему, або бути набором
файлових систем у таблиці розділів GPT, за якою має зберігатися специфікація придатних
до вивчення розділів[2]. Докладніший опис підтримуваних образів дисків наведено на
сторінці підручника systemd-nspawn(1) щодо перемикача з такою самою назвою.
Додано у версії 252.
--image-policy=правила
Приймає рядок правил поводження з образами як аргумент, як у systemd.image-policy(7).
Правила буде примусово застосовано при роботі з образами дисків, які вказано за
допомогою --image=, див. вище. Якщо не вказано, типовим значенням будуть правила «*»,
тобто буде використано усі розпізнані файлові системи образу.
--runtime
Якщо використано разом із enable, disable, edit (і пов'язаними командами), вносити
зміни лише тимчасово, щоб їх було скасовано під час наступного перезавантаження
системи. Це стосуватиметься тих змін, які не було внесено до підкаталогів /etc/, а
лише до /run/, втім, із ідентичними результатами, оскільки останні буде втрачено під
час перезавантаження системи, а отже, буде втрачено і зміни.
Так само, при використанні разом із set-property, внести зміни лише тимчасово, так,
щоб їх було скасовано під час наступного перезавантаження системи.
--preset-mode=
Приймає одне з таких значень: «full» (типовий варіант), «enable-only» (лише
увімкнути), «disable-only» (лише вимкнути). Якщо використано разом із командами preset
та preset-all, керує тим, чи модулі має бути вимкнено і увімкнено відповідно до правил
набору параметрів, чи має бути лише увімкнено, чи має бути лише вимкнено.
Додано у версії 215.
-n, --lines=
Якщо використано разом із status, керує кількістю виведених рядків журналу, із
відліком від найсвіжіших. Приймає додатний цілий аргумент або 0 для вимикання
виведення з журналу. Типовим є значення 10.
-o, --output=
Якщо використано разом із status, керує форматуванням виведених записів журналу.
Доступні варіанти описано на сторінці підручника щодо journalctl(1). Типовим є варіант
«short».
--firmware-setup
Якщо використано разом із командою reboot, poweroff або halt, вказати мікропрограмі
системи, що перезавантаження слід виконати до інтерфейсу налаштовування мікропрограми
під час наступного завантаження. Зауважте, що скористатися цією можливістю можна не в
усіх системах.
Додано у версії 220.
--boot-loader-menu=час очікування
Якщо використано разом із командою reboot, poweroff або halt, вказати засобу
завантаження системи, що під час наступного завантаження слід показати меню
завантаження. Приймає значення часу як параметр, який вказує час очікування меню на
реакцію користувача. Передайте нульове значення, щоб вимкнути час очікування меню.
Зауважте, що підтримку цієї можливості передбачено не в усіх засобах завантаження
системи.
Додано у версії 242.
--boot-loader-entry=ідентифікатор
Якщо використано разом із командою reboot, poweroff або halt, вказує, що під час
наступного завантаження системи засіб завантаження має завантажити вказаний запис
завантаження. Приймає ідентифікатор запису засобу завантаження як аргумент або «help»,
якщо потрібно вивести список доступних записів. Зауважте, що підтримку цієї можливості
передбачено не в усіх засобах завантаження системи.
Додано у версії 242.
--reboot-argument=
Цей перемикач використовують разом із reboot. Значенням залежить від архітектури і
мікропрограми. Наприклад, можна скористатися «recovery» для ініціювання відновлення
системи, і «fota» для ініціювання оновлення мікропрограми «повітрям».
Додано у версії 246.
--plain
Якщо використано разом із list-dependencies, list-units or list-machines, виведені
дані буде показано як список, а не як ієрархію, а крапки для пунктів буде прибрано.
Додано у версії 203.
--timestamp=
Змінити формат виведених часових позначок. Можна використовувати такі значення:
pretty (типовий варіант)
"День РРРР-ММ-ДД ГГ:ХХ:СС ЧП"
Додано у версії 248.
unix
"@seconds-since-the-epoch"
Додано у версії 251.
us, μs
"День РРРР-ММ-ДД ГГ:ХХ:СС.ДДДДДДД ЧП"
Додано у версії 248.
utc
"День РРРР-ММ-ДД ГГ:ХХ:СС UTC"
Додано у версії 248.
us+utc, μs+utc
"День РРРР-ММ-ДД ГГ:ХХ:СС.ДДДДДД UTC"
Додано у версії 248.
Додано у версії 247.
--mkdir
Якщо використано разом із bind, створює файл або каталог призначення до застосування
монтування із прив'язкою. Зауважте, що хоча за назвою цього параметра можна
припустити, що він застосовний лише до каталогів, у результаті використання цього
параметра також буде створено вузол файла призначення для монтування, якщо об'єктом
монтування є не каталог, а звичайний файл, вузол пристрою, сокет або FIFO.
Додано у версії 248.
--marked
Можна використовувати лише разом із reload-or-restart. Ставить у чергу усі завдання з
перезапуску для усіх модулів, які позначено як «needs-restart», і перезавантажує
завдання для модулів, які позначено як «needs-reload». Якщо для модуля, який позначено
для перезавантаження, не передбачено підтримки перезавантаження, до черги буде
поставлено перезапуск. Встановити відповідні властивості модулів можна за допомогою
set-property Markers=....
Якщо не використано --no-block, systemctl чекатиме на завершення завдань з черги.
Додано у версії 248.
--read-only
Якщо використано разом із bind, створює придатне лише для читання монтування
прив'язки.
Додано у версії 248.
--drop-in=НАЗВА
Якщо використано з edit, використати вказану назву файла вставляння замість
override.conf.
Додано у версії 253.
--when=
Якщо використано разом із halt, poweroff, reboot або kexec, запланувати виконання дії
на вказану часову позначку, яку слід вказати за допомогою синтаксичної конструкції,
документацію щодо якої наведено у підручнику systemd.time(7), розділ «PARSING
TIMESTAMPS». Зокрема, якщо вказано «show», буде показано поточну заплановану дію, яку
можна скасувати передаванням порожнього рядка або рядка «cancel».
Додано у версії 254.
--stdin
Якщо використано разом із edit, вміст файла буде прочитано зі стандартного джерела
вхідних даних, а редактор не запускатиметься. У цьому режимі старий вміст файла буде
повністю замінено. Це корисно для «редагування» файлів модулів зі скриптів:
$ systemctl edit --drop-in=limits.conf --stdin some-service.service <<EOF
[Unit]
AllowedCPUs=7,11
EOF
У цьому режимі можна «редагувати» декілька вставлень одночасно; до усіх вставлень буде
записано однакові дані.
Додано у версії 256.
-H, --host=
Виконати дію віддалено. Вкажіть назву вузла або відокремлені символом «@» ім'я
користувача і назву вузла, з якими слід встановити з'єднання. До назви вузла можна
дописати суфікс порту, на якому очікуватиме на з'єднання ssh. Суфікс має бути
відокремлено двокрапкою. Далі, можна вказати назву контейнера, відокремлену «/», яка
вказуватиме що з'єднання слід встановити безпосередньо із вказаним контейнером на
вказаному вузлі. Для обміну даними із екземпляром засобу керування на віддаленому
комп'ютері буде використано SSH. Назви контейнерів можна нумерувати за допомогою
machinectl -H ВУЗОЛ. Адреси IPv6 слід брати у квадратні дужки.
-M, --machine=
Виконати дію у локальному контейнері. Вкажіть назву контейнера, з якими слід
встановити з'єднання, із необов'язковим префіксом імені користувача, який слід
відокремити від назви контейнера символом «@». Якщо замість контейнера використати
особливий рядок «.host», буде встановлено з'єднання із локальною системою (це корисно
для встановлення з'єднання із каналом даних певного користувача: «--user
--machine=lennart@.host»). Якщо не буде використано синтаксичної конструкції із «@»,
буде встановлено з'єднання від імені користувача root. Якщо використано «@», ліву чи
праву частину синтаксичного виразу навколо нього може бути пропущено (але не обидві
частини). У цьому випадку неявно буде використано ім'я локального користувача і
«.host», відповідно.
-C, --capsule=
Виконати дію над капсулою. Вкажіть назву капсули для з'єднання. Див.
capsule@.service(5), щоб дізнатися більше про капсули.
Додано у версії 256.
--no-pager
Не передавати виведені дані до засобу поділу на сторінки.
--legend=булеве значення
Увімкнути або вимкнути виведення умовних позначень, тобто стовпчика заголовків та
нижнього колонтитула із підказками. Типово, умовні позначення буде виведено, якщо їх
не вимкнено за допомогою --quiet або подібного параметра.
-h, --help
Вивести короткий текст довідки і завершити роботу.
--version
Вивести короткі дані щодо версії і завершити роботу.
СТАН ВИХОДУ
Якщо команду буде виконано успішно, буде повернуто 0; в інших випадках, буде повернуто
ненульовий код помилки.
У systemctl використано коди повернення, які визначено LSB, зокрема у LSB 3.0.0[3].
Таблиця 4. Коди повернення LSB
┌─────────┬──────────────────────────┬────────────────────────┐
│Значення │ Опис у LSB │ Використання у systemd │
├─────────┼──────────────────────────┼────────────────────────┤
│0 │ "програма працює або │ модуль є активним │
│ │ служба працює нормально" │ │
├─────────┼──────────────────────────┼────────────────────────┤
│1 │ "програма «вмерла» і │ виконання модуля не │
│ │ файл pid у /var/run │ завершилося помилкою │
│ │ існує" │ (використовується │
│ │ │ is-failed) │
├─────────┼──────────────────────────┼────────────────────────┤
│2 │ "програма «вмерла», і │ не використовується │
│ │ існує файл блокування у │ │
│ │ /var/lock" │ │
├─────────┼──────────────────────────┼────────────────────────┤
│3 │ "програму не запущено" │ модуль не є активним │
├─────────┼──────────────────────────┼────────────────────────┤
│4 │ "стан програми або │ Немає такого модуля │
│ │ служби є невідомим" │ │
└─────────┴──────────────────────────┴────────────────────────┘
Відповідність між станами служб у LSB та станами модулів systemd не є ідеальною, тому
краще не покладатися на ці повернуті значення, а звернутися до станів певного модуля і
підмодулів.
СЕРЕДОВИЩЕ
$SYSTEMD_EDITOR
Редактор, яким слід скористатися для редагування модулів; має пріоритет над $EDITOR і
$VISUAL. Якщо не вказано жодного зі значень $SYSTEMD_EDITOR, $EDITOR або $VISUAL, або
якщо вказано порожні значення або не вдається запустити жоден із вказаних редакторів,
systemctl спробує запустити відомі редактори у такому порядку: editor(1), nano(1),
vim(1), vi(1).
Додано у версії 218.
$SYSTEMD_LOG_LEVEL
Максимальний рівень журналювання виданих повідомлень (повідомлення з вищим рівнем
журналювання, тобто менш важливі, будуть придушені). Приймає список відокремлених
комами значень. Значення може бути одним із (у порядку зменшення важливості) emerg,
alert, crit, err, warning, notice, info, debug або ціле число в діапазоні 0...7.
Перегляньте syslog(3) для отримання додаткової інформації. Перед кожним значенням може
бути необов'язковий префікс console, syslog, kmsg або journal, після якого йде
двокрапка, щоб установити максимальний рівень журналювання для певної цілі журналу
(наприклад, SYSTEMD_LOG_LEVEL=debug,console:info вказує на реєстрацію на рівні
діагностики, за винятком випадків входу в консоль, яка має бути на рівніinfo).
Зауважте, що глобальний максимальний рівень журналювання має пріоритет над будь-якими
максимальними рівнями журналювання для кожної цілі.
$SYSTEMD_LOG_COLOR
Булеве значення. Якщо істинне, повідомлення, які записано до термінал, буде
розфарбовано за пріоритетністю.
Цей параметр є корисним, лише якщо повідомлення буде записано безпосередньо до
термінала, оскільки journalctl(1) та інші інструменти для показу журналу
розфарбовуватимуть повідомлення на основі рівня журналювання власними засобами.
$SYSTEMD_LOG_TIME
Булеве значення. Якщо істинне, до повідомлень журналу у консолі буде додано префікс із
часової позначки.
Цей параметр є корисним, лише якщо повідомлення буде записано безпосередньо до
термінала або файла, оскільки journalctl(1) та інші інструменти для показу журналу
додаватимуть часові позначки на основі метаданих запису власними засобами.
$SYSTEMD_LOG_LOCATION
Булеве значення Якщо істинне, до повідомлень журналу буде додано префікс із назви
файла і номера рядка у початковому коді, звідки походить повідомлення.
Зауважте, що часто до записів журналу все одно буде дописано розташування журналу. Тим
не менше, включення його безпосередньо до тексту повідомлення може бути зручним для
діагностичних програм.
$SYSTEMD_LOG_TARGET
Призначення для повідомлень журналу. Одне з таких значень: console (виводити
повідомлення до долученого термінала), console-prefixed (виводити повідомлення до
долученого термінала, але із префіксом, де закодовано рівень журналювання і «процес»,
див. syslog(3), kmsg (виводити повідомлення до циклічного буфера журналу ядра),
journal (виводити повідомлення до журналу), journal-or-kmsg (виводити повідомлення до
журналу, якщо він доступний, і до kmsg, якщо недоступний), auto (визначити відповідне
призначення повідомлень журналу автоматично, типовий варіант), null (вимкнути
виведення повідомлень).
$SYSTEMD_PAGER
Засіб показу сторінок, яким слід скористатися, якщо не вказано --no-pager;
перевизначає $PAGER. Якщо не встановлено ні $SYSTEMD_PAGER, ні $PAGER, буде виконано
спробу скористатися відомими реалізаціями послідовно, включно з less(1) і more(1), аж
доки не буде щось знайдено. Якщо не буде виявлено реалізації засобу показу сторінок,
засіб показу сторінок викликано не буде. Встановлення для значення цієї змінної
середовища порожнього рядка або значення «cat» є еквівалентом передавання параметра
--no-pager.
Зауваження: якщо не встановлено значення $SYSTEMD_PAGERSECURE, буде без попередження
проігноровано $SYSTEMD_PAGER (а також $PAGER).
$SYSTEMD_LESS
Перевизначає параметри, які буде передано less (типово, «FRSXMK»).
Користувачам, можливо, варто змінити два параметри:
K
Цей параметр наказує засобу поділу на сторінки негайно завершити роботу, якщо
натиснуто Ctrl+C. Щоб дозволити less обробляти Ctrl+C самостійно для перемикання
назад на запит команди засобу, скасуйте встановлення цього параметра.
Якщо значення $SYSTEMD_LESS не включає «K», і викликаним засобом поділу на
сторінки є less, Ctrl+C буде проігноровано виконуваним файлом — його має обробляти
сам засіб поділу на сторінки.
X
Цей параметр наказує засобу поділу на сторінки не надсилати рядки ініціалізації та
деініціалізації termcap на термінал. Його типово встановлено, щоб лишити видимим
виведення команди у терміналі, навіть після завершення роботи засобу поділу на
сторінки. Тим не менше, це заважає роботі деяких можливостей засобу поділу на
сторінки, зокрема виведені дані не можна буде гортати за допомогою миші.
Зауважте, що встановлення звичайної змінної середовища $LESS не впливає на виклики
less інструментами systemd.
Див. less(1), щоб дізнатися більше.
$SYSTEMD_LESSCHARSET
Перевизначити набір символів, який передано less (типовим набором є «utf-8», якщо
викликаний термінал є сумісним із UTF-8).
Зауважте, що встановлення звичайної змінної середовища $LESSCHARSET не впливає на
виклики less інструментами systemd.
$SYSTEMD_PAGERSECURE
Приймає булевий аргумент. Якщо істина, буде увімкнено «безпечний» режим програми для
поділу на сторінки; якщо хибність, режим буде вимкнено. Якщо значення
$SYSTEMD_PAGERSECURE не встановлено взагалі, безпечний режим буде увімкнено, якщо
ефективний UID не збігається із ідентифікатором власника сеансу входу до системи, див.
geteuid(2) і sd_pid_get_owner_uid(3). У безпечному режимі LESSSECURE=1 буде
встановлено при виклику засобу поділу на сторінки, і засіб вимкне команди, які
відкривають або створюють файли або запускають нові підпроцеси. Якщо значення
$SYSTEMD_PAGERSECURE взагалі не встановлено, засоби поділу на сторінки, про реалізацію
безпечного режиму у яких нічого не відомо, не буде використано. (У поточній версії
безпечний режим реалізовано лише у less(1).)
Зауваження: якщо команди викликають із підвищеними привілеями, наприклад, з
використанням sudo(8) або pkexec(1), слід подбати про те, щоб небажані інтерактивні
можливості не було увімкнено. «Безпечний» режим для засобу поділу на сторінки може
бути автоматично увімкнуто, як це описано вище. Якщо встановлено значення
SYSTEMD_PAGERSECURE=0 або якщо змінну не усунено з успадкованого середовища,
користувач зможе викликати довільні команди. Зауважте, що якщо змінні $SYSTEMD_PAGER
або $PAGER слід брати до уваги, то слід встановити і значення $SYSTEMD_PAGERSECURE.
Втім, у такому випадку, можливо, варто взагалі вимкнути засіб поділу на сторінки за
допомогою параметра --no-pager.
$SYSTEMD_COLORS
Приймає булевий аргумент. Якщо істина, systemd і пов'язані інструменти
використовуватимуть кольори у виведених даних. Якщо хибність, виведення буде
монохроматичним. Крім того, змінна може приймати одне з таких особливих значень: «16»,
«256», щоб обмежити використання кольорів базовими 16 або 256 кольорами ANSI,
відповідно. Це значення можна встановити для перевизначення автоматичного значення на
основі $TERM та того, з чим з'єднано консоль.
$SYSTEMD_URLIFY
Значення має бути булевим. Визначає, чи має бути створено придатні до натискання
посилання у виведенні до емуляторів терміналів, у яких передбачено відповідну
підтримку. Це значення можна встановити для перевизначення значення, яке встановлено
systemd на основі $TERM та інших умов.
ДИВ. ТАКОЖ
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. Специфікація завантажувачів
https://uapi-group.org/specifications/specs/boot_loader_specification
2. Специфікація придатних до вивчення розділів
https://uapi-group.org/specifications/specs/discoverable_partitions_specification
3. LSB 3.0.0
http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html
ПЕРЕКЛАД
Український переклад цієї сторінки посібника виконано Andriy Rysin <arysin@gmail.com>,
Yuri Chornoivan <yurchor@ukr.net> і lxlalexlxl <lxlalexlxl@ukr.net>
Цей переклад є безкоштовною документацією; будь ласка, ознайомтеся з умовами GNU General
Public License Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩. НЕ НАДАЄТЬСЯ ЖОДНИХ
ГАРАНТІЙ.
Якщо ви знайшли помилки у перекладі цієї сторінки підручника, будь ласка, надішліть
електронний лист до списку листування перекладачів: ⟨trans-uk@lists.fedoraproject.org⟩.