Systemd за администратор, част 3
3. Преобразувайте скрипта за стартиране на SysV в файл на услугата systemd
* Също така LSB заглавката казва, че тази услуга трябва да се изпълнява на ниво на изпълнение 3 (конзола за много потребители) и 5 (графично за много потребители).
* Изпълнимият двоичен файл на демон е /usr/sbin/abrtd.
* Това е цялата полезна информация. Всичко останало в 115-редовия скрипт е чист помощен код: синхронизиране и последователност на стартиращи операции (код, свързан със заключващи файлове), показване на информационни съобщения (ехо команди), анализиране на входни параметри (монструозен блок на буквите). Въз основа на информацията по-горе, можем да напишем следния сервизен файл:
[Unit] Description=Демон за откриване на сриващи се приложения After=syslog.target [Service] ExecStart=/usr/sbin/abrtd Type=forking [Install] WantedBy=multi-user.target
Нека да разгледаме по-отблизо този файл. Секцията [Единица] съдържа най-общата информация за услугата. Нека не забравяме, че systemd управлява не само услуги, но и много други обекти, по-специално устройства, точки на монтиране, таймери и т.н. Общото име за всички тези обекти е единица. Секцията на конфигурационния файл със същото име определя най-често срещаните свойства, които могат да бъдат присъщи на всяка единица. В нашия случай това е, първо, описателен низ и второ, индикация, че този модул се препоръчва да бъде активиран след стартиране на демона на системния журнал. Строго погледнато, тази зависимост не е необходимо да се посочва тук - на системи, където syslog демонът е активиран чрез сокет, тази зависимост е излишна. Съвременните реализации на syslog daemon (например rsyslog от версия 5) поддържат активиранечрез гнездо. В системи, използващи такива реализации, изричното указване на After=syslog.target би било излишно, тъй като съответната функционалност се поддържа автоматично. Въпреки това, този ред все още си струва да се уточни за съвместимост със системи, използващи наследени реализации на syslog daemon.
[Unit] Description=ABRT Automated Bug Reporting Tool After=syslog.target [Service] Type=dbus BusName=com.redhat.abrt ExecStart=/usr/sbin/abrtd -d -s [Install] WantedBy=multi-user.target
С какво новата версия се различава от предишната? Е, първо, изяснихме описанието на услугата. Ключовата промяна обаче е замяната на стойността на Type от разклонение на dbus и свързани промени: добавяне на име на услуга в D-Bus шината (директива BusName) и указване на допълнителни аргументи към abrtd "-d -s". Но защо изобщо е необходима тази промяна? Какъв е неговият практически смисъл? За да отговорим на този въпрос, се връщаме отново към демонизацията. По време на тази операция процесът се разклонява два пъти и се изключва от всички терминали. Това е много удобно, когато стартирате демон чрез скрипт, но когато използвате усъвършенствани системи за стартиране като systemd, това поведение не осигурява никаква полза, но причинява неоправдани забавяния. Дори ако оставим настрана въпроса за скоростта на изтегляне, ще има такъв важен аспект като наблюдението на състоянието на услугите. systemd решава и този проблем, като наблюдава работата на услугата и реагира на различни събития, ако е необходимо. Например, когато основният процес на услугата се срине неочаквано, systemd трябва да регистрира идентификатора на процеса и кода за изход и, в зависимост от настройките, може да опита да рестартира услугата или да активира някаква предварително дефинирана единица. Операциядемонизацията донякъде затруднява решаването на тези проблеми, тъй като обикновено е доста трудно да се намери връзката на демонизиран процес с оригиналния (всъщност смисълът на демонизацията е именно да разруши тази връзка) и съответно за systemd е по-трудно да определи кой от процесите, генерирани в дадена услуга, е основният. За да го улесним при решаването на този проблем, използвахме типа стартиране на dbus. Подходящо е за всички услуги, които регистрират името си в D-Bus12 в края на процеса на инициализация. ABRTd е един от тях. С новите настройки systemd ще стартира процеса abrtd, който вече няма да се разклонява (според превключвателите „-d -s“, които посочихме), и systemd ще счита момента, в който името com.redhat.abrt е регистрирано в D-Bus, като край на началния период за тази услуга. В този случай основният процес за тази услуга ще се счита за процес, директно създаден от systemd. По този начин systemd има удобен метод за определяне кога дадена услуга е приключила стартирането и може лесно да следи нейния статус. Всъщност това беше всичко, което трябваше да се направи. Получихме прост конфигурационен файл, 10 реда от който съдържат повече полезна информация от 115 реда на оригиналния начален скрипт. Добавяйки ред по ред към нашия файл, можем да използваме различни полезни системни функции, които биха изисквали значителни усилия за създаване на аналог в традиционен начален скрипт. Например, като добавим реда Restart=restart-always, казваме на systemd автоматично да рестартира услугата след всеки срив. Или, например, като добавим OOMScoreAdjust=-500, ще поискаме от ядрото да запази тази услуга, дори ако OOM Killer тръгне на бойната пътека. И ако добавим реда CPUSchedulingPolicy=idle, процесът abrtd ще работи само вонези моменти, когато системата не е заета с нищо друго, което ще ви позволи да не пречите на процесите, които активно използват процесора. За по-подробно описание на всички опции за конфигуриране можете да се обърнете към страниците с ръководство за systemd.unit, systemd.service, systemd.exec.
Разбира се, не всички init скриптове са толкова лесни за конвертиране в обслужващи файлове. Но, за щастие, няма толкова много "проблемни" скриптове.