Як убити демона?

Як убити демона?
Вбити системного демона неважко, правда?

Або. все не так просто? Якщо ваш демон функціонує як один процес, все дійсно дуже просто. Ви командуєте, і демон системного логу зупиняється. Втім, цей метод не цілком коректний, так як він діє не тільки на самого демона, але і на інші процеси з тим же ім’ям.

Іноді подібна поведінка може призвести до неприємних наслідків. Більш правильним буде використання pid-файлу: kill $ (cat / var / run / syslogd. Pid). Ось, начебто, і все, що вам потрібно. Або ми упускаємо ще щось? Дійсно, ми забуваємо одну просту річ: існують служби, такі, як Apache, crond, atd, які за родом службової діяльності повинні запускати дочірні процеси.

Це можуть бути абсолютно сторонні, зазначені користувачем програми (наприклад, завдання cron / at, CGI-скрипти) або повноцінні серверні процеси (наприклад, Apache workers). Коли ви вбиваєте основний процес, він може зупинити всі дочірні процеси. А може і не зупинити. Справді, якщо служба функціонує в штатному режимі, її зазвичай зупиняють командою. До прямого викликом адміністратор, як правило, вдається тільки в аварійній ситуації, коли служба працює неправильно і може не зреагувати на стандартну команду зупинки.

Таким чином, убивши, наприклад, основний сервер Apache, ви можете отримати від нього у спадок працюють CGI-скрипти, причому їх батьком автоматично стане ID 1 (init), так що встановити їх походження буде не так-то просто. поспішає до нас на допомогу. Команда дозволить відправити сигнал всім процесам, породженим в рамках даної служби.

Наприклад: # systemctl kill crond. service Ви можете бути впевнені, що всім процесам служби cron буде відправлений сигнал SIGTERM. Зрозуміло, можна відправити і будь-який інший сигнал. Скажімо, якщо ваші справи зовсім вже погані, ви можете скористатися і # systemctl kill-s SIGKILL crond. service Після введення цієї команди, служба cron буде жорстоко вбита разом з усіма її дочірніми процесами, незалежно від того, скільки разів вона Форкан, і як би вона не намагалася втекти з-під нашого контролю за допомогою подвійного форка або.

У деякий случах виникає необхідність відправити сигнал саме основного процесу служби. Наприклад, використовуючи, ми можемо змусити демона перечитати файли конфігурації. Зрозуміло, передавати HU допоміжним процесам в цьому випадку абсолютно необов’язково. Для вирішення такого завдання непогано підійде і класичний метод з pid-файлом, проте у systemd і на цей випадок є просте рішення, яка рятує вас від необхідності шукати потрібний файл: # systemctl kill-s HU-kill-who = main crond. service Отже, що ж принципово нове привносить systemd в рутинний процес вбивства демона?

Насамперед: вперше в історії Linux представлений спосіб примусової зупинки служби, що не залежить від того, наскільки сумлінно основний процес служби виконує свої зобов’язання щодо зупинки дочірніх процесів. Як вже згадувалося вище, необхідність відправити процесу зазвичай виникає саме в нештатної ситуації, коли ви вже не можете бути впевнені, що демон коректно виконає всі свої обов’язки. Відмінність полягає в тому, що просто відправляє сигнал заданому процесу, в той час як діє по офіційно визначеного методу, викликаючи команду, визначену в параметрі ExecStop конфігурації служби. Зазвичай команди буває цілком достатньо для зупинки служби, і до доводиться вдаватися тільки в крайніх випадках, наприклад, коли служба зависла і не реагує на команди.

До речі кажучи, при використанні параметра, ви можете вказувати назви сигналів як з префіксом SIG, так і без нього обидва варіанти будуть працювати. На завершення варто сказати, що для нас дуже цікавим і несподіваним виявився той факт, що до появи systemd в Linux просто не існувало інструментів, що дозволяють коректно відправити сигнал службі в цілому, а не окремому процесу. 1. Прим. перев. : Варто особливо відзначити, що використання контрольних груп не тільки спрощує процес знищення форк-бомб, а й значно зменшує шкоду від працюючої форк-бомби. Так як systemd автоматично поміщає кожну службу і кожен користувальницький сеанс в свою контрольну групу по ресурсу процесорного часу, запуск форк-бомби одним користувачем або службою не створить значних проблем з чуйністю системи у інших користувачів і служб. Таким чином, в якості основної загрози форк-бомбардування залишаються лише можливість вичерпання пам’яті і ідентифікаторів процесів (ID).

Вихідна стаття:, автор Lennart Poettering.

Як убити демона?

Сподобалася стаття? Поділися нею з друзями!




Добавить комментарий