systemd forking vs simple?

Я пишу свій перший systemdфайл файлу.

Бо Typeє кілька варіантів:, forkingі simpleт. Д. Я прочитав Документацію Redhat на цю тему (табл. 9.9), але все ще не впевнений, коли мені слід скористатись якою опцією.

Будь-які вказівки?

Коли ви запускаєте службу вручну з командного рядка (не використовуючи команду nohupпрефікса чи &суфікс для запуску її у фоновому режимі, або іншими словами, просто запустіть команду, яку ви поставили б у ExecStart=рядку .serviceфайлу), що станеться?

a) Якщо послуга починається і працює, а запит не повертається, поки ви не натиснете клавішу Control-C або не припините послугу іншим способом: тоді Type = simpleце правильний вибір.

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

c) Якщо служба виконує свою роботу і повертається до підказки, не залишаючи нічого запущеним (тобто служба просто коригує деякі настройки ядра, надсилає команду на щось інше або робить щось подібне), то Type = oneshot, мабуть, це правильний вибір. У цьому випадку ExecStartсервісом може бути команда "встановити" щось, і це ExecStopбула б відповідна команда для "скасування". Зазвичай у цього виду є RemainAfterExit=true, тому systemd буде відслідковувати "стан" цієї служби відповідно до того, чи була річ нещодавно "встановлена" чи "не встановлена".

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

Для використання Type = notifyпроцес повинен мати можливість підключитися до сокета Unix, зазначеного в змінній середовища, $NOTIFY_SOCKETта повідомити про його стан, записуючи повідомлення до цього сокета, коли це необхідно. Також сервісний файл повинен визначати NotifyAccessопцію надання доступу до розетки сповіщень відповідно.

Існує утиліта командного рядка systemd-notifyта функція бібліотеки С, sd_notify(3)яку ви можете використовувати для надсилання цих повідомлень, але якщо жодне з них не відповідає вашим вимогам, ви можете просто реалізувати власного відправника повідомлень. Потрібні повідомлення дуже прості і виглядають як присвоєння змінної оболонки: наприклад, щоб повідомити, що служба успішно завершила запуск і готова подати будь-які вхідні запити, служба повинна надіслати рядок, еквівалентну виходу printf "READY=1\n"в сокет. Див man 3 sd_notifyдля більш докладної інформації про розпізнаних повідомленнях.

Примітка: багато службових додатків, розроблених для перенесення для багатьох систем у стилі Unix, можуть поводитись як b) за замовчуванням, але їх можна зробити так, як а), додавши параметр (як правило, описується як "не розщедритися", "продовжуйте працювати на передньому плані "," не демонструвати "або подібне). У такому випадку, якщо варіант не має інших побічних ефектів, то переважнішим буде додавання параметра та використання поведінки типу a) systemd.