SYSTEMCTL(1)

НАЗВА
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 буде показано загальний стан модуля, одне з таких значень:

    Таблиця 1. Стани ACTIVE модуля
    Стан | Опис
    active | Запущено, прив'язано, з'єднано, ..., залежно від типу модуля.
    inactive | Зупинено, відв'язано, від'єднано, ..., залежно від типу модуля.
    failed | Подібний до inactive, але роботу модуля перервано якоюсь помилкою (процес повернув код помилки при виході, завершив роботу аварійно, перевищено час очікування на завершення дії або кількість перезапусків стала критичною).
    activating | Змінюється з inactive на active.
    deactivating | Змінюється з active на inactive.
    maintenance | Модуль перебуває у стані inactive і виконується дія із супроводу його роботи.
    reloading | Модуль перебуває у стані active і перезавантажує власні налаштування.
    оновлення | Модуль є активним, і нове монтування активується у його просторі назв.

    У стовпчику 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
        kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
        /dev/rfkill      systemd-rfkill.socket       systemd-rfkill.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 ВЗІРЕЦЬ...
    Зупинити і потім знову запустити один або декілька модулів, які вказано у рядку команди, якщо модулі запущено. Якщо модулі не запущено, ніяких дій щодо них не виконуватиметься.

enqueue-marked
    Поставити у чергу завдання запуску/зупинки/перезапуску/перезавантаження для всіх модулів, для яких встановленовідповідні позначки "needs-*". Якщо для модуля, який позначено для перезавантаження, не передбачено підтримки перезавантаження, до черги буде поставлено перезапуск. Встановити відповідні властивості модулів можна за допомогою set-property Markers=....

    Якщо не використано --no-block, systemctl чекатиме на завершення завдань з черги.

    Додано у версії 260.

reload-or-restart ВЗІРЕЦЬ...
    Перезавантажити один або декілька модулів, якщо у них передбачено підтримку таких дій. Якщо підтримки перезавантаження не передбачено, зупинити і потім знову запустити ці модулі. Якщо модулі ще не запущено, їх буде запущено.

    Якщо використано у поєднанні із --marked, є застарілою альтернативою до enqueue-marked.

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=, буде вилучено одразу дані з кешу і динамічні дані, а також очищено дані сховища дескрипторів файлів (оскільки ці три типи ресурсів є зайвими і відтворюються під час наступного виклику цього модуля). Декілька значень можна відокремити комами. Зауважте, що вказані модулі має бути зупинено, щоб можна було викликати цю дію.

    Таблиця 2. Можливі значення --what=
    Значення | Налаштовування модуля
    "runtime" | RuntimeDirectory=
    "state" | StateDirectory=
    "cache" | CacheDirectory=
    "logs" | LogsDirectory=
    "configuration" | ConfigurationDirectory=
    "fdstore" | FileDescriptorStorePreserve=
    "all" | Усе з наведеного вище
    "help" | Показати список підтримуваних значень і вийти

    Додано у версії 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]. Цій команді можна передавати лише назву модуля, вона не приймає шляхів до файла модуля.

    Ця команда неявним чином перезавантажує налаштування засобу керування системою після завершення виконання дії. Зауважте, що ця команда не виконує неявного перезапуску модулів, які було вимкнено. Якщо потрібно зупинити роботу таких модулів, або поєднайте цю команду із перемикачем --now, або потім викличте команду try-restart із відповідними аргументами.

    Додано у версії 238.

preset МОДУЛЬ...
    Скинути стан вмикання-вимикання одного або декількох файлів модулів, які вказано у рядку команди, до типових значень, які зазначено у файлах наборів правил модулів. Результат буде той самий, що і у команд disable або enable, залежно від того, що вказано для модуля у файлах наборів налаштувань.

    Скористайтеся параметром --preset-mode= для керування тим, має бути модулі увімкнено і вимкнено, лише вимкнено чи лише вимкнено.

    Якщо у модулі не вказано даних щодо встановлення, його буде без попереджень проігноровано під час виконання цієї команди. Значенням аргументу МОДУЛЬ має бути дійсна назва модуля, усі альтернативні назви буде без попереджень проігноровано.

    Щоб дізнатися більше про формат правил набору налаштувань, ознайомтеся зі сторінкою підручника щодо systemd.preset(5).

    Додано у версії 238.

preset-all
    Скидає усі встановлені файли модулів до типових параметрів, які налаштовано у файлі правил набору налаштувань (див. вище).

    Скористайтеся параметром --preset-mode= для керування тим, має бути модулі увімкнено і вимкнено, лише вимкнено чи лише вимкнено.

    Додано у версії 215.

is-enabled МОДУЛЬ...
    Перевіряє, чи увімкнено якийсь із вказаних файлів модулів (як за допомогою команди enable). Повертає стан виходу 0, якщо увімкнено принаймні один модуль, і ненульовий стан, якщо це не так. Виводить поточний стан вмикання (див. таблицю). Щоб придушити виведення даних, скористайтеся параметром --quiet. Щоб було виведено цілі встановлення, скористайтеся параметром --full.

    Таблиця 3. Виведення is-enabled
    Назва | Опис | Код виходу
    "увімкнено" | Увімкнено за допомогою символічних посилань .wants/, .requires/ або Alias= (остаточно в /etc/systemd/system/ або тимчасово у /run/systemd/system/). | 0
    "увімкнено-робота" |  |
    "пов'язано" | Стає доступним через одне або декілька символічних посилань на файл модуля (остаточно в /etc/systemd/system/ або тимчасово у /run/systemd/system/), навіть якщо файл модуля може зберігатися поза шляхом пошуку файлів модулів. | > 0
    "linked-runtime" |  |
    "alias" | Назва альтернативи (символічного посилання на файл іншого модуля). | 0
    "masked" | Повністю вимкнено так, що будь-яка дія із запуску завершиться помилкою (остаточно в /etc/systemd/system/ або тимчасово у /run/systemd/systemd/). | > 0
    "masked-runtime" |  |
    "static" | Файл модуля не увімкнено і немає умов для вмикання його у розділі [Install] файла модуля. | 0
    "indirect" | Сам файл модуля не увімкнено, але він містить непорожній запис Also= у розділі [Install] файла модуля, де вказано список інших файлів модулів, які може бути увімкнено, або у нього є альтернатива на основі символічного посилання із іншою назвою, яку не вказано у Also=. Для файлів шаблонів модулів буде увімкнено екземпляр, відмінний від того, який вказано у DefaultInstance= is enabled. | 0
    "disabled" | Файл модуля не увімкнено, але у ньому міститься розділ [Install] із настановами щодо встановлення. | > 0
    "generated" | Файл модуля було створено динамічно за допомогою інструмента створення файлів. Див. systemd.generator(7). Створені файли модулів не може бути увімкнено, їх неявним чином вмикає їхній засіб породження. | 0
    "transient" | Файл модуля було створено динамічно за допомогою програмного інтерфейсу середовища виконання. Тимчасові модулі не можна вмикати. | 0
    "bad" | Файл модуля є некоректним або сталася якась інша помилка. Зауважте, що is-enabled насправді не повертатиме цього стану, а просто виведе повідомлення про помилку. Втім, його може бути виведено у списку файлів модулів, які програма виводить, якщо використано list-unit-files. | > 0
    "not-found" | Файла модуля не існує. | 4

    Додано у версії 238.

mask МОДУЛЬ...
    Замаскувати один або декілька модулів, як вказано у рядку команди. Це пов'яже файли модулів із /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, на яких програма очікує дані від імені користувача.

    Коли альтернатива модуля впроваджується під час перезавантаження (наприклад, перетворення b.service на символічне посилання, що вказує на a.service), стан роботи канонічного модуля (a.service) зберігається. Старий серіалізований стан тепер перетвореного на альтернативу модуля відкидається, щоб запобігти пошкодженню канонічного модуля застарілими данимитивний стан Aqs. Залежності, що посилаються на назву альтернативи, буде автоматично пов'язано із канонічним модулем, а граф залежностей перебудовується з файлів модулів, що забезпечує узгодженість. Якщо перетворений на альтернативу модуль мав запущені процеси, їх буде покинуто — засіб керування службами вже не стежитиме за ними.

    Цю команду не слід плутати із командою 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).

    Таблиця 4. Виведення is-system-running
    Назва | Опис | Код виходу
    initializing | Раннє завантаження, до досягнення basic.target або входу до стану maintenance. | > 0
    starting | Пізнє завантаження, до того, як черга завдань стане бездіяльною уперше, або буде досягнуто одну з цілей порятунку системи. | > 0
    running | Система є повноцінно функціональною. | 0
    degraded | Система є функціональною, але один або декілька модулів є непрацездатними. | > 0
    maintenance | Активною є ціль порятунку або критична ціль. | > 0
    stopping | Засіб керування завершує роботу. | > 0
    offline | Засіб керування не запущено. Зокрема, це стан роботи, якщо як засіб керування системою (PID 1) запущено несумісну програму. | > 0
    unknown | Не вдалося визначити функціональний стан через брак ресурсів або з іншої причини. | > 0

    Додано у версії 215.

default
    Увійти в типовий режим. Це еквівалентно 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.

    Щоб завантажити ядро, буде виконано нумерацію за UAPI.1 Специфікацією завантажувачів[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», «lenient», «replace», «replace-irreversibly», «isolate», «ignore-dependencies», «ignore-requirements», «flush», «triggering» або «restart-dependencies». Типовим є «replace», якщо не використано команду isolate, яка неявним чином встановлює режим завдання «isolate».

    Якщо вказано «fail», і запитана дія над слабкими залежностями конфліктує із завданням у черзі (специфічніше: спричиняє обернення у зупинене завдання і навпаки для завдання запуску, яке вже перебуває у черзі), спричиняє режим помилки для дії.

    Якщо вказано «lenient», і запитана дія конфліктує із будь-яким активним або активованим модулем, спричиняє режим помилки для дії.

    Якщо вказано «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», що означає, що logind виконає перевірку і врахує активні блокування заборони, але systemctl виконає лише перевірку інтерактивних викликів на боці клієнта (тобто з TTY), отже користувачам буде повернуто зручніше і інформативніше повідомлення про помилку. «no» вимикає перевірки systemctl і logind.

    Програми можуть встановлювати блокування уповільнення для уникнення переривання вимиканням системи або станом сну певних важливих дій (зокрема процедури записування компакт-диска чи подібних операцій). Створити ці блокування може будь-який користувач, а привілейовані користувачі можуть перевизначати ці блокування. Якщо визначено якесь блокування, запити щодо вимикання або присипляння, зазвичай, завершуватимуться помилкою (якщо не буде явно перевизначено за допомогою "no").

    Використання параметра --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). Повідомлення про помилки виводяться завжди.

-v, --verbose
    Показати дані з виведення до журналу модуля під час виконання дій модуля.

    Додано у версії 258.

--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, не перезавантажувати неявним чином налаштування фонових служб після внесення змін.

--kill-whom=
    Якщо використано разом із kill, визначає, яким процесам слід надіслати сигнал UNIX. Має бути одним з таких значень: main, control, cgroup або all — для вибору того, слід припинити роботу основного процесу, процесу керування, усіх процесів у групі керування модуля або усіх процесів модуля.Основним процесом модуля є процес, який визначає його термін роботи. Процесом керування модуля є процес, який було викликано засобом керування для виконання змін стану модуля. Наприклад, усі процеси, які запущено через використання параметрів ExecStartPre=, ExecStop= або ExecReload= модулів служб, є процесами керування. Зауважте, що одночасно у кожного модуля може бути лише один процес керування, оскільки одночасно можна виконувати лише одну зміну стану. Для служб типу Type=forking, процесом керування є початковий процес, який запущено засобом керування для ExecStart=, а повністю відгалужений від нього процес вже буде розглядатися як основний процес модуля (якщо його можна визначити). У цьому відмінність від модулів служб інших типів, де відгалужений засобом керування процес для ExecStart= є завжди самим по собі основним процесом. Модуль служби складається з нуля або одного основного процесу, нуля або одного процесу керування і будь-якої кількості додаткових процесів частини групи керування модуля. Втім, процесами цих типів керують не усі типи модулів. Наприклад, для модулів монтування визначено процеси керування (ними є виклики /usr/bin/mount і /usr/bin/umount), але основного процесу не визначено. Якщо не вказано, типовим варіантом є all, окрім випадку використання --kill-subgroup=, у якому типовим варіантом є cgroup.

    Додано у версії 252.

--kill-value=INT
    Якщо використано з командою kill, додає до черги сигнал разом із вказаним цілочисельним параметром для вказаних процесів. Цією дією можна скористатися, лише для сигналів реального часу POSIX (тобто --signal=SIGRTMIN+... або --signal=SIGRTMAX-...); вона забезпечує створення сигналів за допомогою системного виклику sigqueue(3), а не kill(3). Вказане значення має бути 32-бітовим цілим числом зі знаком; його можна вказати у десятковій, шістнадцятковій (якщо додано префікс «0x»), вісімковій (якщо додано префікс «0o») або двійковій (якщо додано префікс «0b») системі числення

    Якщо використано цей параметр, сигнал буде додано до черги лише для процесу керування або основного процесу модуля, ніколи для інших процесів, які належать модулю, тобто --kill-whom=all стосуватиметься лише основного і керівного процесів, але не інших процесів.

    Додано у версії 254.

--kill-subgroup=ШЛЯХ
    Приймає підшлях групи керування для надсилання сигналів; для використання з командою kill. Типово, вибраний сигнал буде надіслано усім процесам cgroup модуля (а також основним процесам та процесам керування (якщо зовні) — є об'єктом --kill-whom=). Але з цим параметром можна вибрати підгрупу. Ця функціональна можливість доступна, лише якщо «cgroup» або «cgroup-fail» використовуються з --kill-whom=, і насправді перший варіант є типовим, якщо використано --kill-subgroup=.

    Вказаний шлях може, але не обов'язково, мати префікс — символ похилої риски, — його відсутність або наявність ні на що не впливає, за будь-яких умов шлях буде визначено відносно шляху до основної групи керування модуля.

    Цією функціональною можливістю можна скористатися лише для модулів, у яких увімкнено делегування керування групою (див. Delegate= у systemd.resource-control(5)).

    Додано у версії 258.

-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, or reenable, також розпочати/зупинити/спробувати перезапустити модулі після успішного виконання дій у вказаному файлі модуля.

    Додано у версії 220.

--root=
    Якщо використано разом із enable/disable/is-enabled (і пов'язаними командами), використати вказаний шлях до кореневої теки при пошуку файлів модулів. Якщо вказано цей параметр, systemctl працюватиме із файловою системою безпосередньо, замість обміну даними з фоновою службою systemd для внесення змін.

--image=образ
    Приймає шлях до файла образу диска або вузла блокового пристрою Якщо вказано, усі дії буде застосовано до файлової системи у вказаному образі диска. Цей параметр подібний до --root=, але працює з файловою системою, що зберігається в образах диска або блокових пристроїв. Образ диска або має містити файлову систему, або бути набором файлових систем у таблиці розділів GPT, за якою має зберігатися UAPI.2 специфікація придатних до вивчення розділів[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.

--read-only
    Якщо використано разом із bind, створює придатне лише для читання монтування прив'язки.

    Додано у версії 248.

--drop-in=НАЗВА
    Якщо використано з edit, використати вказану назву файла вставляння замість override.conf.

    Додано у версії 253.

--when=
    Якщо використано разом із halt, poweroff, reboot або kexec, запланувати виконання дії на вказану часову позначку, яку слід вказати за допомогою синтаксичної конструкції, документацію щодо якої наведено у підручнику systemd.time(7), розділ «PARSING TIMESTAMPS». Зокрема, якщо вказано «show», буде показано поточну заплановану дію, яку можна скасувати передаванням порожнього рядка або рядка «cancel». Якщо вказано "auto", дію буде заплановано відповідно до вікна супроводу або на одну хвилину від поточного моменту.

    Додано у версії 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-ask-password
    Не надсилати користувачеві запит щодо розпізнавання для привілейованих дій.

--no-pager
    Не передавати виведені дані до засобу поділу на сторінки.

--legend=булеве значення
    Увімкнути або вимкнути виведення умовних позначень, тобто стовпчика заголовків та нижнього колонтитула із підказками. Типово, умовні позначення буде виведено, якщо їх не вимкнено за допомогою --quiet або подібного параметра.

-h, --help
    Вивести короткий текст довідки і завершити роботу.

--version
    Вивести короткі дані щодо версії і завершити роботу.

СТАН ВИХОДУ

Якщо команду буде виконано успішно, буде повернуто 0; в інших випадках, буде повернуто ненульовий код помилки.

У systemctl використано коди повернення, які визначено LSB, зокрема у LSB 3.0.0[3].

Таблиця 5. Коди повернення 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, $PAGER
    Засіб показу сторінок, яким слід скористатися, якщо не вказано --no-pager. Буде використано $SYSTEMD_PAGER, якщо значення цієї змінної встановлено; якщо значення не встановлено ні для $SYSTEMD_PAGER, ні для $PAGER, буде виконано спробу скористатися відомими реалізаціями послідовно, включно з less(1) і more(1), аж доки не буде щось знайдено. Якщо не буде виявлено реалізації засобу показу сторінок, засіб показу сторінок викликано не буде. Встановлення для значення цих змінних середовища порожнього рядка або значення «cat» є еквівалентом передавання параметра --no-pager.

    Зауваження: якщо не встановлено значення $SYSTEMD_PAGERSECURE, для вимикання пейджера можна буде скористатися лише $SYSTEMD_PAGER і $PAGER (зі значенням "cat" або ""), і цю змінну буде проігноровано.

$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
    У звичайних програмах-пейджерах, зокрема less(1), окрім «пейджингу», тобто гортання виведених даних, передбачено підтримку відкриття файлів або запису даних до файлів та виконання довільних команд оболонки. Коли команди викликаються з розширеними привілеями, наприклад, під sudo(8) або pkexec(1), пейджер стає джерелом небезпеки. Слід бути обережним, і використовувати як пейджери лише програми зі суворо обмеженими можливостями, а непередбачувані інтерактивні функції, такі як відкриття або створення нових файлів чи запуск підпроцесів, слід виключити. «Безпечний режим» для пейджера можна увімкнути, як описано нижче, якщо у пейджері передбачено його підтримку (більшість пейджерів не враховують цього міркування). Рекомендується або явно увімкнути «безпечний режим», або повністю вимикати пейджер за допомогою --no-pager або PAGER=cat, якщо ви дозволяєте ненадійним користувачам виконувати команди з підвищеними привілеями.

    Цей параметр приймає булевий аргумент. Якщо встановлено значення true, увімкнено «безпечний режим» пейджера. У «безпечному режимі» під час виклику пейджера буде встановлено LESSSECURE=1, що вказує пейджеру вимкнути команди, які відкривають або створюють нові файли або запускають нові підпроцеси. Наразі відомо, що лише less(1) розуміє цю змінну та реалізує «безпечний режим».

    Якщо встановлено значення false, на пейджер не накладаються жодні обмеження. Встановлення SYSTEMD_PAGERSECURE=0 або невилучення його з успадкованого середовища може дозволити користувачеві викликати довільні команди.

    Якщо значення $SYSTEMD_PAGERSECURE не встановлено, інструменти systemd намагаються автоматично визначити, чи слід увімкнути «безпечний режим» і чи передбачено його підтримку у пейджері. «Безпечний режим» вмикається, якщо ефективний UID не збігається з власником сеансу входу, див. geteuid(2) та sd_pid_get_owner_uid(3), або під час роботи під керуванням sudo(8) або подібних інструментів ($SUDO_UID встановлено [4]). У цих випадках буде встановлено значення SYSTEMD_PAGERSECURE=1, а пейджери, у яких, як відомо, не реалізовано «безпечний режим», взагалі не використовуватимуться. Зауважте, що це автоматичне визначення охоплює лише найпоширеніші механізми розширення привілеїв і призначене для зручності. Рекомендується явно встановити $SYSTEMD_PAGERSECURE або вимкнути пейджер.

    Зверніть увагу, що якщо ви хочете врахування змінних $SYSTEMD_PAGER і $PAGER, окрім вимкнення пейджера, також слід встановити значення для $SYSTEMD_PAGERSECURE.

$SYSTEMD_COLORS
    Приймає логічний аргумент або спеціальне значення.Типово (не встановлено), systemd та пов'язані допоміжні засоби використовуватимуть розфарбовування у виведених даних, якщо це можливо. Якщо для $COLORTERM встановлено "truecolor" або "24bit", буде увімкнено 24-бітові кольори, інакше - 256 кольорів, якщо $NO_COLOR або $TERM не вказують, що розфарбовування вимкнено.

    true
        Те саме, що і «не встановлено», але $NO_COLOR буде проігноровано.

    false
        Виведені дані будуть чорно-білими.

    "16", "256", "24bit"
        Завжди використовувати базові 16 кольорів ANSI, 256 кольорів або 24-бітові кольори, відповідно.

    "auto-16", "auto-256", "auto-24bit"
        Використовувати вказану кількість кольорів стосовно $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.  UAPI.1 Специфікація завантажувачів
    https://uapi-group.org/specifications/specs/boot_loader_specification

2.  UAPI.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

4.  Рекомендуємо, щоб інші інструменти встановлювали та перевіряли значення $SUDO_UID належним чином, розглядаючи це як типовий інтерфейс.

ПЕРЕКЛАД
Український переклад цієї сторінки посібника виконано 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.