Загалом, рекомендуємо користуватися, коли можна, Type=simple для служб, які працюють довго, оскільки це найпростіший і найшвидший варіант. Втім, використання цього типу служби заважає передаванню засобу керування службами помилок запуску служби і не дозволяє упорядковування інших модулів за результатами завершення ініціалізації служби (що, наприклад, є корисним, якщо клієнти потребують з'єднання із службою за допомогою певної форми IPC, а канал IPC буде встановлено самою службою, на відміну від виконання цього завдання наперед за допомогою сокета, активації каналу або подібної дії), його може бути недостатньо у багатьох випадках. Якщо це так, notify або dbus (останній лише у випадку, якщо служба надає інтерфейс D-Bus) є пріоритетнішими варіантами, оскільки вони уможливлюють для коду програм служб точне планування того, коли слід вважати запуск служби успішним, і коли слід слід продовжити обробку наступних модулів. Тип служби notify потребує явної підтримки у коді служби (оскільки службі доведеться у відповідний момент викликати sd_notify() або еквівалентний програмний інтерфейс) — якщо її підтримки не передбачено, альтернативою є forking: у цьому варіанті передбачено підтримку традиційного протоколу запуску служб UNIX. Нарешті, exec може бути прийнятним варіантом для випадків, коли достатньо переконатися, що викликано виконуваний файл служби, і коли сам виконуваний файл служби не виконує своєї ініціалізації або виконує мінімальну ініціалізацію (і помилка його ініціалізації є малоймовірною). Зауважте, що використання будь-якого типу, відмінного від simple, ймовірно, затримає процес завантаження системи, оскільки засобу керування системою доведеться чекати на завершення ініціалізації служби. Через це, рекомендуємо не використовувати без потреби жодного з типів, окрім simple. (Також зауважте, що, загалом, не рекомендовано користуватися idle або oneshot для служб, які працюватимуть довго.)

Загалом, рекомендовано використовувати ExitType=main, якщо служба має відому модель відгалуження і основний процес може бути надійно визначено. Варіант ExitType= cgroup призначено для програм, чия модель відгалуження є наперед невідомою і які можуть не мати певного основного процесу. Його добре пристосовано для тимчасових або автоматично створених служб, зокрема графічних програм у стільничному середовищі.

Зауважте, що у сучасних проєктах слід уникати файлів PID. Де це можливо, використовуйте Type=notify або Type=simple, типи, які не вимагають використання файлів PID для визначення основного процесу служби, і не потребують зайвого відгалуження.

Якщо для Type= не встановлено значення oneshot, має бути задано точно одну команду. Якщо використано Type=oneshot, може бути вказано нуль або більшу кількість команд. Команди можна вказати заданням декількох рядків команд у одній інструкції або, інакше, цей параметр можна вказати декілька разів з тими самими наслідками. Якщо цьому параметру надано порожнє значення, список команд, які слід запустити, буде скинуто, попередні надання значень цьому параметру втратять чинність. Якщо значення ExecStart= не вказано, служба повинна мати RemainAfterExit=yes і принаймні один встановлений рядок ExecStop=. (Служби, для яких не вказано обох, ExecStart= і ExecStop=, не є чинними.)

Для кожної з вказаних команд першим аргументом має бути або абсолютний шлях до виконуваного файла, або проста назва файла без будь-яких похилих рисок. Додатково, до цієї назви файла може бути дописано префікс із декількома спеціальними символами:

Таблиця 1. Особливі префікси виконуваних файлів

«@», «-», «:» і один із префіксів «+»/«!»/«!!» можна поєднати у будь-якому порядку. Втім, одночасно можна використовувати лише один з префіксів «+», «!», «!!». Зауважте, що підтримку цих префіксів передбачено для інших параметрів командного рядка, тобто ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop= і ExecStopPost=.

Якщо вказано декілька команд, команди буде викликано послідовно у тому порядку, у якому їх вказано у файлі модуля. Якщо виконання однієї з команд завершиться помилкою (і для неї не вказано префікса «-»), інші рядки не буде виконано, а модуль вважатиметься таким, виконання якого завершилося помилкою.

Якщо не встановлено Type=forking, процес, який запущено за допомогою цього рядка команди, буде вважатися основним процесом фонової служби.

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

Команди ExecStart= буде виконано лише після того, як виконання усіх команд ExecStartPre=, до яких не було додано префікса «-», буде успішно завершено.

Команди ExecStartPost= буде запущено лише після успішного виклику команд, які вказано в ExecStart=, якщо це визначено Type= (тобто запуску процесу для Type=simple, або успішного завершення останнього процесу ExecStart= для Type=oneshot, успішного завершення початкового процесу для Type=forking, надсилання «READY=1» для Type=notify, або отримання BusName= для Type=dbus).

Зауважте, що ExecStartPre= не можна використовувати для запуску довготривалих процесів. Усі процеси, які відгалужено процесами, які викликано за допомогою ExecStartPre=, буде завершено примусово до того, як буде запущено наступний процес служби.

Зауважте, що якщо будь-яка з цих команд, вказаних у ExecStartPre=, ExecStart= або ExecStartPost=, завершить роботу критичною помилкою (і для неї не буде вказано префікса «-», див. вище) або перевищить час очікування на дані до повного запуску служби, буде продовжено виконання команд, які вказано у ExecStopPost=. Команди в ExecStop= буде пропущено.

Зауважте, що виконання ExecStartPost= буде взято до уваги для упорядковувальних обмежень Before=/After=.

Поведінка буде подібною до ExecStartPre= і гібриду перевірки умов: якщо команда ExecCondition= завершить роботу із кодом виходу від 1 до 254 (включно), решту команд буде пропущено, а модуль не буде позначено як такий, виконання якого завершилося помилкою. Втім, якщо команда ExecCondition= завершить роботу зі станом виходу 255 або у критичному режимі (тобто через перевищення часу очікування, переривання сигналом тощо), модуль вважатиметься таким, виконання якого завершилося помилкою (і решту команд буде пропущено). Якщо кодом виходу буде 0 або код із SuccessExitStatus=, буде продовжено виконання наступних команд.

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

Буде встановлено одну додаткову спеціальну змінну середовища: буде встановлено $MAINPID у значення, якщо воно відоме, назви основного процесу фонової служби, і цією змінною можна буде скористатися у рядках команд, подібних до такого:

ExecReload=kill -HUP $MAINPID

Втім, зауважте, що перезавантаження фонової служби надсиланням сигналу (як і з прикладом рядка вище), зазвичай, не дуже вдалий вибір, оскільки це асинхронна дія, яка є непридатною для пов'язаного перезавантаження одразу декількох служб. Наполегливо рекомендуємо встановити для ExecReload= значення команди, яка не лише ініціює перезавантаження налаштувань фонової служби, але також синхронно очікує на його завершення. Наприклад, dbus-broker(1) використовує таке:

ExecReload=busctl call org.freedesktop.DBus \


        /org/freedesktop/DBus org.freedesktop.DBus \


        ReloadConfig

Зауважте, що, зазвичай, для цього параметра недостатньо вказати команду, якщо лише попросить службу припинити роботу (наприклад, надсиланням у певній формі сигналу щодо переривання), але не очікує на завершення припинення роботи. Оскільки роботу решти процесів служби буде припинено відповідно до KillMode= і KillSignal= або RestartKillSignal=, як це описано вище, негайно після завершення роботи команди, зупинення роботи може статися нештатно. Отже, вказана команда має бути синхронною, а не асинхронною дією.

Зауважте, що команди, вказані в ExecStop=, буде виконано, лише коли спочатку запущено службу. Їх не буде викликано, якщо службу не було взагалі запущено або якщо спроба запуску завершилася помилкою, наприклад, оскільки спроба виконання якоїсь із команд, які вказано в ExecStart=, ExecStartPre= або ExecStartPost=, завершилося помилкою (і до команди не було дописано префікс «-», див. вище) або було перевищено час очікування на дані. Скористайтеся ExecStopPost= для виклику команд, якщо служба не може запуститися належним чином і завершує роботу знову. Також зауважте, що дію з зупинення завжди буде виконано, якщо службу успішно запущено, навіть якщо процеси у службі перервано самим процесом або ззовні. Команди зупинення має бути приготовано для роботи у цьому випадку. Встановлення значення $MAINPID буде скасовано, якщо systemd стане відомо, що основний процес завершив роботу на момент виклику команд зупинення.

Запити щодо перезапуску служби реалізовано як дії з зупинення, за якими слідують дії із запуску. Це означає, що ExecStop= і ExecStopPost= буде виконано під час дії із перезапуску служби.

Рекомендуємо скористатися цим параметром для команд, які обмінюються даними зі службою, яка потребує штатного переривання роботи. Для кроків чищення після завершення роботи скористайтеся замість цього параметра параметром ExecStopPost=.

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

Зауважте, що усі команди, які налаштовано за допомогою цього параметра, буде викликано із кодом результату служби, а також кодом виходу і стану основного процесу, які встановлено у змінних середовища $SERVICE_RESULT, $EXIT_CODE і $EXIT_STATUS. Див. systemd.exec(5), щоб дізнатися більше.

Зауважте, що виконання ExecStopPost= буде взято до уваги для упорядковувальних обмежень Before=/After=.

Якщо служба із типом Type=notify надсилає «EXTEND_TIMEOUT_USEC=...», це може спричинити розширення часу запуску за межі TimeoutStartSec=. Перше отримання цього повідомлення має статися до перевищення TimeoutStartSec=, і щойно час запуску було розширено за межі TimeoutStartSec=, засіб керування службами дозволить продовження запуску служби, якщо служба повторює «EXTEND_TIMEOUT_USEC=...» протягом вказаного інтервалу, аж доки стан запуску служби буде завершено «READY=1». (див. sd_notify(3)).

Якщо служба із типом Type=notify надсилає «EXTEND_TIMEOUT_USEC=...», це може спричинити розширення часу зупинення за межі TimeoutStopSec=. Перше отримання цього повідомлення має статися до перевищення TimeoutStopSec=, і щойно час зупинення було розширено за межі TimeoutStopSec=, засіб керування службами дозволить продовження зупинення служби, якщо служба повторює «EXTEND_TIMEOUT_USEC=...» протягом вказаного інтервалу, або сама не припинить свою роботу (див. sd_notify(3)).

Приймає безрозмірне значення у секундах або значення проміжку часу, наприклад, «5min 20s». Передайте порожнє значення, щоб пропустити обробку часу очікування на переривання відповідним засобом нагляду і повернутися до TimeoutStopSec=. Передайте значення «infinity» для вимикання механізму граничного часу очікування. Типове значення DefaultTimeoutAbortSec= буде взято з файла налаштування засобу керування служб (див. systemd-system.conf(5)).

Якщо служба із типом Type=notify надсилає SIGABRT самостійно (замість того, щоб покластися на запис дампу ядра програми ядром системи), вона може надіслати «EXTEND_TIMEOUT_USEC=...», щоб продовжити час переривання за межі TimeoutAbortSec=. Перше отримання цього повідомлення має статися до перевищення TimeoutAbortSec=, і щойно час переривання було розширено за межі TimeoutAbortSec=, засіб керування службами дозволить продовження переривання служби, якщо служба повторює «EXTEND_TIMEOUT_USEC=...» протягом вказаного інтервалу, або сама не припинить свою роботу (див. sd_notify(3)).

Якщо встановлено значення terminate, службу буде штатно перервано надсиланням сигналу, який вказано за допомогою KillSignal= (типовим сигналом є SIGTERM, див. systemd.kill(5)). Якщо роботу служби не буде перервано, FinalKillSignal= буде надіслано після TimeoutStopSec=. Якщо встановлено значення abort, буде, натомість, надіслано WatchdogSignal=, а TimeoutAbortSec= буде застосовано до надсилання FinalKillSignal=. Цим параметром можна скористатися для аналізу служб, які періодично не вдається запустити або завершити. Якщо використано kill, роботу служби буде негайно перервано надсиланням FinalKillSignal= без будь-якого подальшого часу очікування. Цим параметром можна скористатися для спрощення вимикання служб, роботу яких було завершено помилками.

Якщо служба Type=notify надсилає «EXTEND_TIMEOUT_USEC=...», це може спричинити розширення часу виконання за RuntimeMaxSec=. Перше отримання цього повідомлення має статися до перевищення RuntimeMaxSec=, і щойно час виконання буде розширено за межі RuntimeMaxSec=, засіб керування службами дозволить службі продовжити роботу, якщо служба повторить «EXTEND_TIMEOUT_USEC=...» протягом проміжку часу, який вказано до досягнення завершення роботи служби шляхом «STOPPING=1» (або переривання роботи). (див. sd_notify(3)).

Приймає одне зі значень no, on-success, on-failure, on-abnormal, on-watchdog, on-abort або always. Якщо встановлено значення no (типове значення), службу не буде перезапущено. Якщо встановлено значення on-success, перезапуск буде виконано, лише якщо вихід з процедури служби буде виконано штатно. У цьому контексті штатний вихід означає будь-який з вказаних нижче варіантів:

Якщо встановлено значення on-failure, службу буде перезапущено, коли процес завершує роботу із ненульовим кодом виходу, буде перервано сигналом (включно із дампом ядра, але без згаданих вище чотирьох сигналів),коли буде перевищено час очікування на завершення дії (зокрема перезавантаження служби), і якщо буде активовано налаштований час очікування для засобу нагляду. Якщо встановлено значення on-abnormal, службу буде перезапущено, якщо процес буде перервано сигналом (включно із дампом ядра, але виключно для згаданих вище чотирьох сигналів), коли буде перевищено час очікування на завершення дії або коли буде активовано час очікування для засобу нагляду. Якщо встановлено значення on-abort, службу буде перезапущено, лише якщо процес служи завершить роботу через неперехоплений сигнал, який не вказано як стан штатного завершення роботи. Якщо встановлено значення on-watchdog, службу буде перезапущено, лише якщо буде перевищено час очікування на службу для засобу нагляду. Якщо встановлено значення always, службу буде перезапущено, незалежно від того, чи було її завершено штатно, перервано у нештатному режимі сигналом або завершено унаслідок перевищення часу очікування.

Таблиця 2. Причини виходу та результат дії параметрів Restart=

Як виключення наведеного вище параметра, службу буде перезапущено, якщо код виходу або сигнал буде вказано у RestartPreventExitStatus= (див. нижче) або службу буде зупинено за допомогою systemctl stop або еквівалентної дії. Також служби буде завжди перезапущено, якщо код виходу або сигнал буде вказано у RestartForceExitStatus= (див. нижче).

Зауважте, перезапуск служби підлягатиме обмеженню на частоту запуску модуля, яку налаштовано за допомогою StartLimitIntervalSec= і StartLimitBurst=, див. systemd.unit(5), щоб дізнатися більше. Перезапущена служба увійде до стану помилки лише після того, як буде досягнуто обмежень щодо запуску.

Встановлення для цього параметра значення on-failure є рекомендованим варіантом для довготривалих служб, призначеним для підвищення надійності роботи шляхом спроб автоматично відновлення після помилок. Для служб, які повинні мати можливість переривати свою роботу самостійно (і уникати негайного перезапуску) альтернативним варіантом є on-abnormal.

Зауважте, що цей параметр не змінює зв'язку між числовими станами виходу та їхніми назвами, тобто, незалежно від того, чи використано цей параметр, 0 все одно буде пов'язано із «SUCCESS» (а отже, типово показано як «0/SUCCESS» у виведенні інструментів) і 1 буде пов'язано із «FAILURE» (а отже, типово показаний як «1/FAILURE») тощо. Параметр керує лише тим, що трапиться у результаті отримання цих станів виходу, і як ці коди буде поширено до стану служби цілком.

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

Приклад 1. Служба із параметром SuccessExitStatus=

SuccessExitStatus=TEMPFAIL 250 SIGKILL

Стан виходу 75 (TEMPFAIL), 250 та сигнал переривання SIGKILL вважатимуться штатними перериваннями роботи служби.

Зауваження: для отримання списку станів виходу і трансляції між числовими значеннями стану та назвами можна скористатися systemd-analyze exit-status.

RestartPreventExitStatus=1 6 SIGABRT

призводить до того, що коди виходу 1 і 6 та сигнал переривання SIGABRT не призведуть до автоматичного перезавантаження служби. Цей параметр можна вказувати декілька разів — у цьому випадку списки станів запобігання перезапуску буде об'єднано. Якщо для цього параметра визначено порожній рядок, буде відновлено початкове значення списку, а усі попередні призначення для цього параметра буде відкинуто.

Зауважте, що цей параметр не впливає на процеси, які налаштовано за допомогою ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost= або ExecReload=, але лише для основного процесу служби, тобто процесу, який викликано за допомогою ExecStart= або (залежно від Type=, PIDFile=, ...) якимось іншим налаштованим основним процесом.

Зауважте, що сповіщення sd_notify() може бути належним чином пов'язано із модулями, лише якщо або процес, що їх надіслав, усе ще працює на момент, коли PID 1 обробляє повідомлення, або якщо за процесом, що їх надіслав, явним чином стежить у режимі виконання засіб керування службами. Другий випадок трапляється, якщо засіб керування службами спочатку відгалужує процес, тобто для усіх процесів, які відповідають main або exec. Навпаки, якщо допоміжний процес модуля надсилає повідомлення sd_notify() і негайно завершує роботу, засіб керування службами може не змогти належним чином пов'язати повідомлення із модулем, а отже, проігнорує його, навіть якщо для нього встановлено NotifyAccess=all.

Отже, щоб усунути конкурентність у пошуку модуля клієнта та належної прив'язки сповіщень до модулів, можна скористатися sd_notify_barrier(). Цей виклик працює як точка синхронізації і забезпечує надсилання усіх сповіщень до отримання результатів цього виклику засобом керування службами при успішному поверненні керування. Користуватися sd_notify_barrier() слід для клієнтів, які не викликано засобом керування службами, інакше цей механізм синхронізації стане непотрібним для прив'язування сповіщень до модуля.

Зауважте, що ті самі дескриптори файлів сокетів може бути передано одночасно декільком процесам. Також зауважте, що для вхідного обміну даними сокетом може бути активовано іншу службу, ніж та, для якої зрештою налаштовано успадкування дескрипторів файлів сокетів. Або, іншими словами, параметр Service= модулів .socket не повинен за значенням збігатися зі зворотним параметром Sockets= файла .service, на який він посилається.

Цей параметр може бути вказано декілька разів — список модулів сокетів буде об'єднано. Зауважте, що можливості очищення списку сокетів після встановлення (наприклад, встановленням для цього параметра порожнього значення) не передбачено.

У Linux, коли пам'яті стає замало, до стану, коли у ядра системи виникають проблеми із отриманням пам'яті для самого себе, система може завершити запущений процес з метою вивільнення пам'яті і усування проблем з її нестачею. Цей параметр приймає одне з таких значень: continue, stop або kill. Якщо встановлено значення continue, і процес служби буде завершено засобом запобігання OOM, дані про завершення роботи буде записано до журналу, але модуль продовжить роботу. Якщо встановлено значення stop, запис події буде додано до журналу, а роботу модуля буде штатно перервано засобом керування службами. Якщо встановлено значення kill, і один із процесів модуля буде завершено засобом припинення роботи OOM, ядру буде наказано припинити роботу решти процесів модуля встановленням атрибуту memory.oom.group у значення 1; див. також документацію до ядра системи[2].

Типовим для параметра є значення DefaultOOMPolicy= у systemd-system.conf(5), окрім модулів, для яких увімкнено Delegate=, де типовим значенням є continue.

Скористайтеся параметром OOMScoreAdjust= для налаштовування того, чи будуть процеси модуля пріоритетними кандидатами на переривання роботи механізмами завершення роботи у результаті OOM Linux. Див. systemd.exec(5), щоб дізнатися більше.

Цей параметр також стосується systemd-oomd; подібно до OOM-завершень, цей параметр визначає стан модуля після того, як systemd-oomd знищить cgroup, яку пов'язано із модулем.

Environment="ONE=one" 'TWO=two two'
ExecStart=echo $ONE $TWO ${TWO}

Environment=ONE='one' "TWO='two two' too" THREE=
ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
ExecStart=/bin/echo $ONE $TWO $THREE

ExecStart=sh -c 'dmesg | tac'

ExecStart=echo one ; echo "two two"

ExecStart=echo / >/dev/null & \; \
ls

[Unit]
Description=Foo
[Service]
ExecStart=/usr/sbin/foo-daemon
[Install]
WantedBy=multi-user.target

[Unit]
Description=Чищення якихось застарілих даних
[Service]
Type=oneshot
ExecStart=/usr/sbin/foo-cleanup
[Install]
WantedBy=multi-user.target

[Unit]
Description=Simple firewall
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/simple-firewall-start
ExecStop=/usr/local/sbin/simple-firewall-stop
[Install]
WantedBy=multi-user.target

[Unit]
Description=Якась проста фонова служба
[Service]
Type=forking
ExecStart=/usr/sbin/my-simple-daemon -d
[Install]
WantedBy=multi-user.target

[Unit]
Description=Проста служба DBus
[Service]
Type=dbus
BusName=org.example.simple-dbus-service
ExecStart=/usr/sbin/simple-dbus-service
[Install]
WantedBy=multi-user.target

[D-BUS Service]
Name=org.example.simple-dbus-service
Exec=/usr/sbin/simple-dbus-service
User=root
SystemdService=simple-dbus-service.service

[Unit]
Description=Проста служба сповіщення
[Service]
Type=notify
ExecStart=/usr/sbin/simple-notifying-service
[Install]
WantedBy=multi-user.target