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