Услуга за премахване на Systemctl. Изпълнение на собствени скриптове systemd. Проверка на състоянието на услугите

Systemd Unit е скрипт, който изпълнява различни действия (каквото и да напишете в него). Обикновено пиша такива скриптове за стартиране на различни услуги, които компилирам на ръка или когато използвам готов софтуер.

Какво ще ви дадат единиците Systemd?

Единиците са обекти, които могат да се управляват от системата (по принцип стандартизирано представяне на системни ресурси, които могат да се управляват от набор от демони).

Единиците в известен смисъл могат да се наричат ​​услуги или задачи, но единицата има много по-широка дефиниция, тъй като може да се използва за абстрактни услуги, мрежови ресурси, устройства, монтирания на файлова система и изолирани пулове от ресурси.

Някои функции, които са лесни за изпълнение:

• Активиране на базата на сокет: Сокетите, свързани с услуга, е най-добре да се изтръгнат от самия демон, за да се обработват отделно. Това има няколко предимства, като забавяне на стартирането на услуга, докато не е наличен подходящият сокет. Той също така позволява на системата да създаде всички сокети, преди процесът да започне, което позволява свързаните услуги да се зареждат паралелно.
• Активиране на базата на автобус: Устройствата могат да се активират и на шинния интерфейс, предоставен от D-Bus. Устройството може да се стартира, когато съответната шина е налична.
• Активиране въз основа на пътя:Устройството може да бъде стартирано въз основа на активност или наличието на определени пътеки на файловата система. Той използва inotify.
• Активиране на базата на устройство: Устройствата могат също да бъдат стартирани, когато свързаният хардуер е достъпен за първи път (свързан) чрез използване на udev събития.
• Картографиране на имплицитна зависимост:Голяма част от структурата на зависимостта за единици може да бъде изградена от самата система. Все още можете да добавите информация за зависимост, но по-голямата част от тежката работа ще бъде свършена вместо вас.
• Екземпляри и шаблони:Шаблонните блокови файлове могат да се използват за създаване на множество екземпляри на едно и също общо устройство. Това ви позволява да създавате малки вариации или единични единици, които осигуряват същата обща функция.
• Просто опростяване на сигурността:Единиците могат да реализират някои доста добри функции за сигурност чрез добавяне на прости директиви. Например, можете да посочите какъв достъп може да се използва (четене, запис), когато работите с файловата система, да ограничите възможностите на ядрото, да зададете частна папка /tmp и мрежов достъп.
• Вмъквания и фрагменти: Единиците могат лесно да бъдат разширени чрез предоставяне на фрагменти, които ще заменят части от системния файл. Това улеснява превключването между ванилия и персонализирани реализации.

Има много други предимства, които системните единици имат пред работните елементи на други системи, но това трябва да ви даде представа за мощността, която може да се използва с вашите собствени директиви за конфигурация.

Как мога да намеря / Къде са Systemd единиците в Unix/Linux?

Файловете, които определят как systemd ще обработва модула, могат да бъдат намерени на различни места, всяко с различни приоритети и значения.

Всички копия на системните файлове на системата (имам предвид всички модули) могат да бъдат намерени в директорията /lib/systemd/system. Съхранените тук файлове могат да се стартират и спират при поискване, но по време на сесията. Това ще бъде универсален файл с единица, който често се пише от разработчици на проекти на трети страни, които трябва да работят на всяка система, която внедрява systemd в стандартната си реализация. Не трябва да редактирате файлове в тази директория. Вместо това трябва да замените файла (ако е необходимо) с друго файлово местоположение, което ще замени файла на това местоположение.

Ако искате да промените как работи определено устройство, тогава трябва да отидете в директорията /etc/systemd/system, защото - файловете, намерени в тази директория, имат предимство пред всички други места във файловата система.

Ако искате да отмените само определени директиви от файлове на системни единици, можете действително да предоставите фрагменти от файлови единици в поддиректория. Те ще добавят или променят директиви към копия на системата, което ви позволява да посочите само опциите, които искате да промените.

Правилният начин да направите това е да създадете директория, наречена след файла с ".d", добавен към края. По този начин трябва да се създаде поддиректория my_test.service.d за модула, наречен my_test.service. В тази директория файл, завършващ на .conf, може да се използва за замяна или разширяване на атрибутите на единичния файл.

Има също място за дефиниране на единици за изпълнение в /run/systemd/system. Файловете, намерени в тази директория, имат предимство пред /etc/systemd/system и /lib/systemd/system.

На файловете в това местоположение се дава по-нисък приоритет от предишното местоположение, но с по-висок приоритет от последното. Самият процес systemd използва това местоположение за динамично генерирани модулни файлове, създадени по време на изпълнение. Тази директория може да се използва за промяна на поведението на устройството на системата по време на цялата сесия. Всички промени, направени в тази директория, ще бъдат загубени, когато сървърът бъде рестартиран.

Типове файлове на единица Systemd

Най-лесният начин да определите типа на устройството е да погледнете неговия суфикс, който се добавя в края на името на ресурса (единицата). Следният списък описва типовете единици, достъпни за systemd:

• .обслужване: Тази част описва как да управлявате услуга или приложение на сървър. Той ще включва стартиране или спиране на услугата, при какви обстоятелства тя трябва да стартира автоматично, както и информация за зависимостите за съответния софтуер.
• .гнездо: Файлът на устройството за сокет описва мрежата, IPC сокета или FIFO буфера, който systemd използва за активиране на сокета. Те винаги имат свързан .service файл, който ще бъде стартиран при активността на сокета, която дефинира този блок.
• .устройство: Единица, която описва устройство, което е посочено като необходимо за управление на systemd с udev или файловата система sysfs. Не всички устройства имат .device файлове. Някои скриптове, които може да изискват devices.device, са за монтиране и достъп до устройства.
• .монтиране: Този блок дефинира точка на монтиране в системата, която се управлява от systemd. Те са кръстени на пътя на монтиране, като "/" е променен на тире. Записите в /etc/fstab може да имат автоматично създадени блокове.
• .автоматично монтиране: Модулът .automount задава точка на монтиране, която ще бъде зададена автоматично и трябва да бъде дефинирана след точката на монтиране, към която се отнасят, и трябва да има съответен модул .mount, за да дефинира конкретни монтирания.
• .размяна: Тази единица описва SWAP (swap space) в системата. Името на тези блокове трябва да отразява пътя до устройството или файла.
• .цел: Това устройство се използва за осигуряване на точки за синхронизация за други устройства при зареждане или промяна на състоянията. Те могат да се използват и за привеждане на системата в ново състояние.
• .път: Този модул дефинира път, който може да се използва за активиране на базата на път. По подразбиране модулът ще бъде стартиран със същото базово име. Това използва inotify за проследяване на промените в пътя.
• .таймер: Това устройство дефинира таймер, който ще се управлява от systemd (подобно на cron задание) за отложено или планирано активиране. Когато таймерът бъде достигнат, ще се стартира съответният блок.
• .моментална снимка: Този модул се създава автоматично от командата snapshot systemctl. Тя ви позволява да възстановите текущото състояние на системата след извършване на промени. Моментните снимки не се запазват в сесиите и се използват за връщане назад на преходни състояния.
• .филийка: Свързва се с възли на контролна група на Linux, което ви позволява да ограничавате ресурсите или да ги присвоявате на всички процеси, свързани със slice. Името отразява нейната йерархична позиция в дървото на групата. Единиците се поставят в определени срезове по подразбиране в зависимост от техния тип.
• .обхват: Те се създават автоматично от systemd от информацията, която получава от неговия шинен интерфейс. Те се използват за управление на набори от системни процеси, създадени външно.

Както можете да видите, има много различни единици, с които системата взаимодейства. Много от тях работят заедно, за да добавят функционалност. Предимно .service се използва поради тяхната полезност.

Структура на файловете на системния модул

Вътрешната структура на файловете е организирана с помощта на секции. Секциите се обозначават с две квадратни скоби "[" и "]" с името на секцията, оградено вътре. Всеки раздел продължава до началото на следващия раздел или до края на файла.

Имената на секциите са добре дефинирани и чувствителни към главни и малки букви. По този начин разделът няма да бъде интерпретиран правилно, ако е написан като . Ако трябва да добавите нестандартни дялове за анализиране (различни от systemd), можете да добавите префикс X към името на дяла.

В тези раздели поведението на устройството и метаданните се дефинират с помощта на прости директиви, използващи формат ключ-стойност със знак за равенство, например:

Директива1=стойност Директива2=стойност .......

В случай на предефиниране на файл (например, съдържащ се в директорията unit.type.d), директивите могат да бъдат нулирани чрез присвояване на празен низ. Например, копие на един системен файл може да съдържа директива, дефинирана по следния начин:

Директива1=стойност_по подразбиране

Стойността по подразбиране може да бъде пропусната във файла за заместване чрез указване на Директива1 (без стойност), като това:

Директива1=

Сега нека разгледаме всяка от единиците поотделно.

Първият раздел, открит в повечето модулни файлове, е . Обикновено се използва за дефиниране на метаданни на устройството и за настройка на връзката на устройството с други устройства.

Въпреки че редът на секциите няма значение за systemd при анализиране на файл, тази секция често се поставя отгоре, защото предоставя преглед на устройството. Някои общи указания ще намерите в раздела:

• Описание=: Тази директива може да се използва за описание на името и основната функционалност на устройството. Връща се от различни инструменти на systemd, така че е добре да зададете нещо кратко, конкретно и информативно.
• документация=: Тази директива предоставя местоположения за документация. Те могат да бъдат налични вътрешни помощни страници или налични в Интернет (URL). Командата "status system your_service" ще покаже тази информация.
• Изисква=: Тази директива изброява всички единици, от които зависи тази единица (услуга или устройство). Ако текущият блок е активиран, единиците, изброени тук, също трябва да се активират успешно, в противен случай ще се провали. Тези блокове работят паралелно с текущото устройство по подразбиране.
• Иска =: Тази директива е подобна на Requires=, но по-малко ограничаваща. Systemd ще се опита да стартира някое от изброените тук устройства, когато това устройство е активирано. Ако тези устройства не бъдат открити или стартирани, текущият блок ще продължи да функционира. Това е препоръчителният начин за конфигуриране на повечето зависимости. Отново, това предполага паралелно активиране, освен ако не е променено от други директиви.
• BindsTo=: Тази директива е подобна на Requires=, но също така кара текущото устройство да спре, когато съответният възел приключи.
• преди=: Устройствата, изброени в тази директива, няма да бъдат стартирани, докато текущият блок не бъде маркиран като работещ, ако са активирани едновременно.
• След=: Устройствата, изброени в тази директива, ще бъдат стартирани преди стартирането на текущото устройство (устройство).
• Конфликти=: Това устройство може да се използва за показване на устройства, които не могат да се изпълняват едновременно с текущото устройство. Стартирането на устройство с тази връзка ще доведе до спиране на други устройства.
• Състояние…=: Има редица директиви, които започват с условие, което позволява на администратора да тества определени условия, преди да стартира устройството. Това може да се използва за предоставяне на файл с общ елемент, който ще работи само на отговарящи на условията системи. Ако условието не е изпълнено, единицата се пропуска.
• Твърди...=: Подобно на директивата по-горе (Условие…=), но зададените директиви проверяват различни аспекти на работната среда, за да решат дали устройството трябва да бъде активирано. Въпреки това, за разлика от директивите Condition…=, отрицателен резултат причинява повреда в тази директива.

Използвайки тези директиви и няколко други, можете да зададете обща информация за устройството и връзката му с операционната система.

В самия край на файла, разположен - раздел. Този раздел не е задължителен и се използва за определяне на поведението или единицата, ако е разрешено или деактивирано. Включването на устройството означава, че то автоматично стартира при зареждане. По принцип това се постига чрез фиксиране на въпросното устройство към друг блок, който е някъде в линията от единици, които трябва да бъдат стартирани при зареждане.

Поради това само единици, които могат да бъдат активирани, ще имат този раздел. Директивите вътре казват какво трябва да се случи, когато устройството се включи:

• WantedBy=: Тази директива е най-често срещаният начин за определяне на това как трябва да бъде включено дадено устройство. Тази директива ви позволява да посочите зависимост (подобно на директивата Wants= в раздела). Разликата е, че тази директива е включена в спомагателна единица, което позволява на основния блок да остане относително чист. Когато дадено устройство е посочено с тази директива, в системата ще бъде създадена папка в /etc/systemd/ с име на посоченото устройство, но с „.wants“ в самия край. В този случай ще бъде създадена символична връзка към текущия блок, който създава зависимостта. Например, ако текущият блок има WantedBy = multi-user.target, ще бъде създадена директория с име multi-user.target.wants в /etc/systemd/system (ако вече не е налична) и символна връзка към текущия блок ще бъдат поставени вътре. Деактивирането на това устройство премахва асоциацията и премахва зависимостта.
• RequiredBy=: Тази директива е много подобна на директивата WantedBy=, но вместо това указва необходима зависимост, която ще доведе до неуспешно активиране, ако не бъде изпълнена. Когато е разрешено, модул с тази директива ще създаде директория, завършваща на .requires.
• Псевдоним=: Тази директива ви позволява да активирате устройството под различно име. Наред с други приложения, това позволява да бъдат налични функции за множество доставчици, така че съответните отдели да могат да търсят всеки доставчик с общ псевдоним.
• също=: Тази директива ви позволява да активирате или деактивирате блокове като набор. Тук можете да посочите поддържащи устройства, които винаги трябва да са налични, когато това устройство е активно. Те ще се управляват като група за инсталационни задачи.
• Екземпляр по подразбиране=: За шаблонни единици (по-късно), които могат да инстанцират блокове с непредвидими имена, това може да се използва като резервен вариант за името, ако не е предоставено подходящо име.

Разделът се използва за предоставяне на конфигурация, която е приложима само за услуги. Едно от основните неща, които трябва да бъдат посочени в раздела, е услугата Type=. Той категоризира услугите според техния процес и демонизиращо поведение. Това е важно, защото казва на systemd как правилно да управлява услугата и да знае нейния статус.

Директивата Type= може да бъде едно от следните:

• просто: Основният процес на услугата е посочен в началния ред. Това е стойността по подразбиране, ако директивите Type= и Busname= не са зададени, но е зададен ExecStart=. Всяко съобщение трябва да бъде обработено извън устройството чрез втори блок от съответния тип (например чрез блок .socket, ако тази услуга трябва да комуникира чрез сокети).
• раздвояване: Този тип услуга се използва, когато услугата разклонява дъщерни процеси, когато родителският процес излезе моментално. Това казва на systemd, че процесът все още работи, въпреки че родителят е прекратил сесията. Много подходящ, например, за стартиране на php-fpm, nginx, tomcat.
• един изстрел: Този тип показва, че процесът ще бъде краткотраен и системата трябва да изчака процеса да завърши, преди да продължи с други устройства. Стойността по подразбиране за Type= и ExecStart= не е зададена. Използва се за еднократни задачи.
• dbus: Това означава, че устройството ще използва името от D-Bus шината. Когато това се случи, systemd ще продължи да обработва следващия блок.
• уведомявам: Това показва, че услугата ще изпрати известие, когато завърши стартирането. Процесът systemd ще изчака това да се случи, преди да премине към други устройства.
• празен: Това означава, че услугата няма да започне, докато не бъдат изпратени всички задачи.

Когато използвате определени видове услуги, може да са необходими някои допълнителни директиви. Например:

• RemainAfterExit=: Тази директива обикновено се използва с типа onehot. Това означава, че услугата трябва да се счита за активна дори след като процесът излезе.
• PIDFile=: Ако типът на услугата е маркиран като "forking", тази директива се използва за задаване на пътя на файла, който трябва да съдържа идентификационния номер на процеса на основното "дете", което ще се наблюдава.
• BusName=: Тази директива трябва да бъде зададена на името на D-Bus, което услугата ще се опита да получи, когато използва типа услуга "dbus".
• NotifyAccess=: Тази директива определя достъпа до сокета, който трябва да се използва за слушане на известия, когато е избрано "notify". Може да бъде "няма", "основен" или "всички". По подразбиране "няма" игнорира всички съобщения за състояние. Опцията „main“ ще слуша съобщения от главния процес, докато опцията „all“ ще накара всички членове на контролната група на услугата да бъдат обработени.

Досега обсъдихме някаква основна информация, но всъщност не казахме как да управляваме нашите услуги. За това са налични следните директиви:

• ExecStart=: Трябва да посочите пълния път и аргументите на командата, която трябва да бъде изпълнена, за да стартира процеса. Това може да бъде посочено само веднъж (с изключение на услугите "onehot"). Ако пътя на командата е предшестван от тире "-", ненулевите състояния на изход ще бъдат приети, без да се маркира активирането на устройството като неуспешно.
• ExecStartPre=: Трябва да посочите пълния път и аргументите на командата, които трябва да бъдат изпълнени преди стартирането на главния процес. Това може да се използва многократно.
• ExecStartPost=: Това има същите качества като ExecStartPre = с изключение на това, че тази директива определя командите, които да се изпълняват след стартиране на главния процес.
• ExecReload=: Тази незадължителна директива указва командата, необходима за презареждане на конфигурацията на услугата, ако е налична.
• ExecStop=: Това показва командата, необходима за спиране на услугата. Ако това не е посочено, процесът ще бъде убит незабавно, когато услугата бъде спряна.
• ExecStopPost=: Това може да се използва за указване на команди, които да бъдат изпълнени след спиране на командата.
• RestartSec=: Ако автоматичното рестартиране на услугата е активирано, това определя времето за изчакване, преди да се опитате да рестартирате услугата.
• рестартиране=: Това показва обстоятелствата, при които systemd ще се опита автоматично да рестартира услугата. Може да се настрои на „винаги“, „при успех“, „при неуспех“, „при ненормално“, „при прекъсване“ или „куче-пазач“. Това ще се рестартира според начина, по който услугата е била спряна.
• TimeoutSec=: Това задава времето, през което системата ще изчака дадена услуга да спре, преди да я маркира като неуспешна или принудително убита. Можете да зададете индивидуални изчаквания с TimeoutStartSec= и TimeoutStopSec=.

Сокетите са много често срещани в конфигурациите на systemd, тъй като много услуги прилагат базирано на сокет активиране, за да осигурят по-добра едновременност и гъвкавост. Всеки блок на сокет трябва да има съответен сервизен модул, който ще се активира, когато сокетът получи активност.

Чрез прекъсване на управлението на сокет извън самата услуга, сокетите могат да бъдат инициализирани рано и свързаните услуги често могат да работят паралелно. По подразбиране името на сокета ще се опита да стартира услуга със същото име след получаване на връзка. Когато услугата се инициализира, към нея ще бъде предаден сокет, който ще й позволи да започне да обработва всички буферирани заявки.

За да укажете действителния сокет, тези директиви са общи:

• ListenStream=: Това определя адрес за поток от сокет, който поддържа последователна, надеждна комуникация. Услугите, използващи TCP, трябва да използват този тип сокет.
• ListenDatagram=: Това определя адрес за сокет за дейтаграма, който поддържа бързи, ненадеждни комуникационни пакети. Услугите, използващи UDP, трябва да зададат този тип сокет.
• ListenSequentialPacket=: Това определя адрес за последователни, надеждни комуникации с максимален брой дейтаграми, които запазват границите на съобщенията. Това е най-често при Unix сокети.
• Слушайте FIFO: Заедно с други видове слушане, можете също да посочите FIFO буфер вместо сокет.

Има повече видове директиви за свързване, но тези по-горе са най-често срещаните.

Други характеристики на гнездата могат да се контролират с допълнителни директиви:

• Приемам=: Това определя дали допълнително копие на услугата ще бъде стартирано за всяка връзка. Ако е зададено на false (по подразбиране), един екземпляр ще обработва всички връзки.
• SocketUser=: Задава собственика на Unix сокет. Ако не е указан, потребителят ще бъде root.
• SocketGroup=: Собственикът на групата се задава с помощта на Unix сокет. Това ще бъде основната група, ако нито една от тях не е посочена. Ако е зададен само SocketUser=, systemd ще се опита да намери подходяща група.
• SocketMode=: За Unix сокети или FIFO буфери, това задава разрешенията за създадения обект.
• Услуга=: Ако името на услугата не съвпада с името на услугата .гнездо, тази услуга може да бъде определена с помощта на тази директива.

Модулите за монтиране ви позволяват да контролирате точката на монтиране от systemd. Точките на монтиране се наименуват според директорията, която управляват, като се използва алгоритъм за превод.

Например, водещата наклонена черта (наклонена черта или "/") се премахва, всички други наклонени черти се преобразуват в тире "-", а всички тирета и непечатаеми знаци се заменят с кодове за избягване в стил C. Резултатът от този превод се използва като името на хоста за монтиране. Единиците за монтиране ще имат косвена зависимост от други монтирания над тях в йерархията.

Единиците за монтиране често се превеждат директно от файла /etc/fstab по време на процеса на зареждане. За автоматично генерирани дефиниции на единици и тези, които искате да дефинирате в един файл:

• Какво=: Абсолютният път до ресурса, който ще бъде монтиран.
• Къде=: Абсолютният път на точката на монтиране, където трябва да се монтира ресурсът. Това трябва да е същото като името на файла на устройството, с изключение на използването на стандартната нотация на файловата система.
• тип=: Тип файлова система за монтиране.
• Опции=: Всички опции за монтиране, които искате да приложите. Това е списък, разделен със запетая.
• SloppyOptions=: Булева стойност (0 или 1), която указва дали монтирането ще се провали, ако има неразпозната опция за монтиране.
• DirectoryMode=: Ако трябва да се създадат родителски директории за точката на монтиране, това определя режима на разрешение за тези папки.
• TimeoutSec=: Задава времето, през което системата ще изчака, докато операцията за монтиране бъде маркирана като неуспешна.

Този модул ви позволява автоматично да инсталирате свързания .mount модул при зареждане. Както при модула .mount, тези единици трябва да бъдат именувани след пътя на преведената точка на монтиране.

Секцията е доста проста, разрешени са само следните две опции:

• Къде=: Абсолютният път на автоматично монтиране във файловата система. Това ще съответства на името на файла, с изключение на това, че конвенцията за пътя се използва вместо превод.
• DirectoryMode=: Ако трябва да се създаде автоматично монтиране или някакви родителски директории, това ще определи настройките за разрешение за тези компоненти на пътя.

Суап модулите се използват за конфигуриране на суап (суап) в системата. Единиците трябва да бъдат наименувани според името на суап файла или устройството, като се използва същия трансфер на файлова система, както беше обсъдено по-горе.

Подобно на опциите за монтиране, суап блоковете могат да бъдат създадени автоматично от /etc/fstab или могат да бъдат конфигурирани чрез специален файл на единица.

Разделът може да съдържа следните директиви за конфигурация:

• Какво=: Абсолютен път до мястото за размяна (било то файл или устройство).
• Приоритет=: Тази опция приема цяло число, което определя приоритета за настройката за размяна.
• Опции=: Всички опции, които обикновено са зададени във файла /etc/fstab, могат да бъдат зададени с помощта на тази директива. Използва се списък, разделен със запетая.
• TimeoutSec=: Тази опция задава времето, което системата чака за активиране на суапа, преди да маркира операцията като неуспешна.

Блокът път дефинира пътя на файловата система, който systmed може да следи за промени. Трябва да има друг блок, който ще се активира, когато бъде открита определена дейност в местоположението на пътя. Активността на пътя се определя от факта, че той не влияе на събитията.

Разделът може да съдържа следните директиви:

• Пътят съществува=: Тази директива се използва за проверка дали пътят съществува. Ако пътят съществува, съответният блок се активира.
• PathExistsGlob=: Тази опция е същата като по-горе, но поддържа глобални изрази за определяне дали съществува път.
• PathChanged=: Тази опция се използва за проследяване на промените в местоположението на пътя. Свързаният блок се активира, ако бъде открита промяна (проверява се, когато файлът е затворен).
• PathModified=: Тази опция е същата като по-горе, но се активира при писане на файлове, а също и когато файлът е затворен.
• DirectoryNotEmpty=: Тази директива позволява на systemd да активира свързания блок, когато директорията вече не е празна.
• единица=: Това показва, че устройството е активирано, когато условията на пътя по-горе са изпълнени. Ако това е пропуснато, systemd ще търси .service файл, който има същото име на базова единица като този блок.
• MakeDirectory=: Тази директива определя дали systemd ще създаде структура на директория преди сърфиране.
• DirectoryMode=: Ако горната директива е активирана, тогава тази опция ще зададе режима на разрешение за всички компоненти на пътя, които ще бъдат създадени.

Таймер, използван за планиране на изпълнение на задачи в определено време или след определено забавяне. Този тип устройство замества или допълва някои функции cron и daemon. Трябва да се осигури подходящ блок, който ще се активира при достигане на таймера.

Разделът може да съдържа някои от следните директиви:

• OnActiveSec=: Тази директива позволява активирането на съответния блок по отношение на активирането на модула .timer.
• OnBootSec=: Тази директива задава времето, когато съответното устройство ще бъде активирано след зареждане на системата.
• OnStartupSec=: Тази директива е подобна на таймера по-горе, но указва кога процесът systemd ще се събуди след зареждане на системата.
• OnUnitActiveSec=: Това настройва таймера в зависимост от това кога последният е бил активиран.
• OnUnitInactiveSec=: Това задава таймер за времето, когато устройството е било неактивно.
• OnCalendar=: Това ви позволява да активирате съответния блок, като посочите абсолютно (вместо относително).
• AccuracySec=: Това устройство се използва за задаване на нивото на точност с таймера, който трябва да бъде залепен. По подразбиране блокът, свързан с него, ще бъде активиран в рамките на една минута.
• единица=: Тази директива се използва за указване на това какво трябва да се активира, когато таймерът изтече. Ако не е зададено, Systemd ще търси блок с име .service.
• Устойчив =: Ако това е зададено, Systemd ще изпълни съответния тригер за блокиране.
• WakeSystem=: Настройката на тази директива позволява на системата да бъде "събудена" от режим на готовност, ако таймерът бъде достигнат.

Разделът всъщност няма специфична конфигурация за .slice. Вместо това може да съдържа някои от директивите за управление на ресурсите, изброени по-горе.

Стига теория, да преминем към практиката.

Писане на systemd Unit файл

Първото нещо, което трябва да направите, е да проверите инициализацията:

# ps -s1| awk "(печат $4)"| grep -Ev "CMD"

PS: Ето кратка статия:

Файловете с шаблони на блокове могат да бъдат дефинирани, защото съдържат символа @ след името на основния блок и преди суфикса на типа блок. Името на блоковия файл с шаблона може да изглежда така:

[имейл защитен]

От създадения блок (който е по-горе), можете да създадете екземпляр на друг блок, който изглежда така:

[имейл защитен]

Силата на шаблонните модулни файлове се дължи главно на способността за динамично вмъкване на подходяща информация в дефиницията на устройството според средата (ENV). Това се прави чрез задаване на директиви във файла на шаблона, както обикновено, но заместване на определени стойности или части от стойности със спецификатори на променливи.

По-долу са някои от най-често срещаните спецификатори, които ще бъдат заменени, когато инстанционна единица бъде интерпретирана с подходящата информация:

• %н: Където и да се използва това, ще бъде добавено пълното име на елемента.
• %Н: Това е същото като по-горе, но всяко екраниране като тези, присъстващи в шаблоните на пътеката на файла, ще бъде пропуснато.
• %p: Това указва префикса на името на единицата. Това е частта от името на единицата, която предхожда символа @.
• %P: Това е същото като по-горе, но с малко отклонение.
• %i: Това се отнася до името на екземпляра, което е идентификаторът след @ в екземпляра. Той е един от най-често използваните спецификатори, защото е динамичен. Използването на този идентификатор насърчава използването на значими конфигурационни идентификатори. Например, портът, на който ще се изпълнява услугата, може да се използва като идентификатор на екземпляр, а шаблонът може да използва този спецификатор, за да персонализира спецификацията на порта.
• %I: Този спецификатор е същият като по-горе, но с някаква дерогация.
• %f: Това ще бъде заменено с неекранирано име на единица или префиксно име, добавено към "/".
• %° С: Това ще посочи контролната група на устройството със стандартната родителска йерархия /sys/fs/cgroup/ssytemd.
• %u: Потребителското име, конфигурирано за стартиране на устройството.
• %U: Същото като по-горе, UID вместо име.
• %H: Име на хост на системата, на която работи устройството.
• %% : Използва се за вмъкване на буквен знак за процент.

Използвайки горните идентификатори във файловия шаблон, Systemd ще попълни правилните стойности, когато интерпретира шаблона, за да създаде екземпляр на единица.

Примери за файлови единици на Systemd

Помислете за следния пример - това е писане на системен скрипт за стартиране на tomcat. За да направите това, отворете файла:

# vim /etc/systemd/system/tomcat9.service

И напишете следния код в него:

Описание=Tomcat9 After=syslog.target network.target Type=forking User=tomcat Group=tomcat Environment=CATALINA_PID=/usr/local/tomcat9/tomcat9.pid Environment=TOMCAT_JAVA_HOME=/usr/bin/java Environment=CATALINA_HOME=/usr /local/tomcat9 Environment=CATALINA_BASE=/usr/local/tomcat9 Environment=CATALINA_OPTS= #Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC" Environment="JAVA_OPTS=-Dfile.encoding=UTF-8 - Dnet.sf.ehcache.skipUpdateCheck=true -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseParNewGC -XX:MaxPermSize=128m -Xms512m -Xmx512m" ExecStart=/usr/local/tomcat9/bin/startup.sh ExecStop =/bin/kill -15 $MAINPID WantedBy=multi-user.target

Нека рестартираме услугата:

# systemctl демон-презареждане

Добавете Tomcat към стартиране на ОС:

# systemctl активира tomcat9

Рестартирайте tomcat:

# systemctl рестартирайте tomcat9

За да проверите състоянието, изпълнете:

# systemctl status tomcat9 ● tomcat9.service - Tomcat9 Зареден: зареден (/etc/systemd/system/tomcat9.service; активиран) Активен: активен (работи) от вторник 2017-05-09 22:04:58 EEST; Преди 6 секунди Процес: 28528 ExecStop=/bin/kill -15 $MAINPID (код=излязъл, статус=0/УСПЕХ) Процес: 28531 ExecStart=/usr/local/tomcat9/bin/startup.sh (код=излязъл, статус= 0/УСПЕХ) Основен PID: 28541 (java) CGroup: /system.slice/tomcat9.service └─28541 /usr/bin/java -Djava.util.logging.config.file=/usr/local/tomcat9/conf/ logging.properties -Djava.ut... 09 май 22:04:58 debian systemd: Стартиране на Tomcat9... 09 май 22:04:58 debian startup.sh: Tomcat стартира. 09 май 22:04:58 debian systemd: Стартира Tomcat9.

Както можете да видите, всичко работи добре. В това отношение имам всичко! Ще последват още примери. Ще ги добавя при нужда. Но основно използвам шаблона по-горе (просто го модифицирайте малко).

Статията „Записване на системен файл с единица“ е завършена.

Системните демони са една от ключовите подсистеми на UNIX. От това колко добре и правилно са написани зависят не само възможностите на операционната система, но и параметри като лекота на използване и дори скорост на работа. В тази статия ще разгледаме четири примера за правилно внедряване на демони, които могат да направят работата в системата по-удобна, ефективна и по-бърза.

systemd: по-бързо от светлината

Схемата за стартиране на типична дистрибуция на Linux изглежда по следния начин: ядрото инициализира хардуера и стартира процеса /sbin/init, който от своя страна изпълнява скриптовете за инициализация. Скриптовете монтират файлови системи, настройват мрежата, различни устройства и стартират последователно стартиране на демони: syslogd, cron, cups и други, които са изброени в конфигурационните файлове. В самия край init стартира мениджъра за влизане: getty или xdm (kdm, gdm). Просто и логично, нали? Такава схема обаче е доста примитивна и в сравнение с Windows и Mac OS X като цяло е архаична. Техните системи за инициализация изпълняват задачи паралелно, без да чакат една да завърши, преди да предадат контрола на следващата. Ако единият от тях спре на I/O, другият незабавно поема контрола, така че общото време за зареждане се намалява толкова много, че традиционната система изостава.

В света на Linux само Ubuntu се държи по този начин и дори тогава само през последните две години. Всички останали продължават да зареждат системата по старомодния начин или използват самостоятелно сглобени патерици, които паралелизират процеса на зареждане неумело и често погрешно (Gentoo и Arch, здравейте!). Все още не е намерено наистина универсално решение, така че много програмисти работят върху идеята за паралелна система за инициализация.

Ленарт Потъринг от Red Hat и автор на PulseAudio е един от тях. Последното му постижение е демонът systemd, друг претендент за титлата /sbin/init killer, който можеше лесно да бъде подминат, ако идеята, залегнала в него, не се оказа толкова интересна и правилна.

Systemd е различна от всяка друга система за стартиране по това, че умишлено прави сложните неща прости. 99% от всички други системи за едновременна инициализация се провалиха просто защото, в сравнение с простите и разбираеми дори за дивака /sbin/init, те изглеждаха като тежки чудовища. За да можете да работите паралелно, без да въвеждате операционната система в непоследователно състояние (което може да възникне, например, ако се опитате да конфигурирате мрежата, преди да заредите мрежовите драйвери или стартирате демоните, без да монтирате правилния FS), различни синхронизации използвани са методи. По принцип това бяха един вид „маркери на зависимост“, които не позволяваха на следващата стъпка на инициализация да работи, ако стъпката, описана в нейните зависимости, не беше завършена.
Например, cron зависи от syslog, защото трябва да поддържа регистрационни файлове; syslog зависи от настройката на мрежата, защото може да получава регистрационни файлове от отдалечени машини и т.н. Поради това скриптовете за инициализация се превърнаха в объркващ низ от блокове и компилирането им стана много по-сложно. Systemd е много по-опростен, не следи зависимостите, просто изпълнява всичко едновременно.

Не се шегувам. Systemd използва механизми за контрол на зависимостта само в много ранните етапи на инициализацията, което по някакъв начин трябва да се случи последователно (монтиране на основната файлова система, монтиране на swap, зареждане на модули и т.н.). Когато става въпрос за демони, които отнемат 90% от времето за инициализация на ОС, за да се стартират, systemd забравя за зависимостите и ги стартира всички наведнъж, показвайки просто невероятна скорост.

Това работи, защото systemd е наясно как работят демоните и как комуникират помежду си.

Наистина, всъщност демоните изобщо не се нуждаят от други демони, а само от „комуникационни канали“, които осигуряват обмен на данни: cron не зависи от syslog, той се нуждае от /dev/log сокет, в който може да записва своите журнали, същото е вярно за всеки друг демон. Всички те комуникират през сокети и единствената причина, поради която демон A трябва да бъде стартиран преди демони B, C и D, е защото демон A трябва да създаде сокета, от който се нуждае. Systemd взема това предвид, така че механизмът му за паралелно стартиране разчита на сокети, които създава за всеки демон предварително и след това стартира демоните едновременно. В същото време отговорността за синхронизацията и „проследяването на зависимостите“ вече е прехвърлена на ядрото, в което е внедрен механизмът на сокетите.

Ако например cron получи контрол преди syslog, нищо лошо няма да се случи - cron ще намери любимия си /dev/log и дори ще може да му пише съобщения (ако иска, разбира се), което, не, няма да бъде изхвърлен, но буфериран в сокета, но само докато cron поиска да напише съобщение до сокета, което може да го препълни. В този случай ядрото ще блокира процеса cron и ще прехвърли контрола на следващия процес в опашката за изпълнение (следващия демон). Скоро (или може би веднага) редът ще достигне системния журнал, който ще започне, ще прочете съобщенията, натрупани в / dev / log, ще ги обработи и ще се блокира върху нещо (или ще прекара времето, определено за него) и контролът ще премине към следващият демон. Типичен мултитаскинг без допълнителни патерици.

Освен това, благодарение на тази схема, повечето демони могат да бъдат стартирани само когато наистина са необходими. Така, например, CUPS не трябва да се стартира по време на инициализация на ОС, когато натоварването на системата вече е високо. По-логично е да го стартирате, когато първият документ бъде изпратен за печат. Systemd ви позволява да правите това, като следите активността на сокета и възприема подобен подход към монтирането на файлови системи, като ги прикачва само към точки на монтиране, когато се опитвате да получите достъп до файлове (демоните също могат да бъдат стартирани, когато конкретен файл на устройство се появи в системата) .

Честно казано, струва си да се каже, че такова гениално решение на проблема със зависимостта е измислено и внедрено в Mac OS X от самото начало на съществуването му, но по някаква причина никой не му обърна внимание преди автора на systemd.

Между другото, самият systemd има друга характеристика, която е очевидно уникална за Linux: той може да групира процеси, използвайки cgroups с различни ограничения за време на изпълнение за цялата група (ограничения на ресурсите, работни и основни директории, umask, настройки за убиване на OOM, добър параметър, приоритет на операцията I/O, приоритети за използване на процесора и други). Това означава, че демоните вече могат да бъдат поставени във виртуални среди без използването на допълнителен софтуер, просто като напишете няколко реда в системния конфигурационен файл.

Systemd вече е достъпен за изтегляне и може да бъде включен в бъдеща версия на Fedora като алтернативна система за стартиране. Инструкции за инсталиране на други дистрибуции можете да намерите на официалната страница: freedesktop.org/wiki/Software/systemd.

Можете да инсталирате Systemd на Ubuntu, като изпълните следните команди:

$ sudo add-apt-repository ppa:andrew-edmunds/ppa
$ sudo apt-get актуализация
$ sudo apt-get install systemd

След това редактирайте /boot/grub/grub.cfg, като добавите реда init=/sbin/systemd към параметрите на ядрото. След рестартиране дистрибуцията ще работи с новата система за стартиране, което може да се провери с командата:

$ sudo systemctl списък с единици

Аргументите за състояние, стартиране, спиране и разрешаване се използват за проверка на състоянието, стартиране, спиране и разрешаване на услугите.

Ulatencyd: незабавна реакция

Кой според вас е най-важният параметър на десктоп операционна система? Добър GUI? Брой налични приложения? Лесна употреба?

Да, всичко това има значение, но днес, когато дори сървърните операционни системи могат лесно да бъдат надарени с тези свойства, напълно различни фактори стават решаващи, най-важният от които е отзивчивостта на системата.

Една добра настолна операционна система трябва да пожертва всичко в името на високата бързина на реакция. Без значение каква скорост показва при запис на файлове на диск, колко десктоп ефекти предлага на потребителя, дали реагира правилно на внезапното изваждане на флашка, всичко това няма да има значение, ако ОС кара потребителя да чака.

За разработчиците на операционни системи това е обща истина, така че през цялото време те са се стремили да направят своите операционни системи по-интерактивни. За някои се получи добре (здравей BeOS), за други не работи добре (къде без MS), но имаше и такива, които изобщо не успяха. Дълго време разработчиците на Linux бяха напълно незаинтересовани от темата за отзивчивостта на Linux на настолни компютри. Кон Коливас им посочваше проблеми много пъти, говореше за мудността и бавността на Linux, пишеше кръпки, кодираше нови планировчици на задачи през нощта и се опитваше да ги включи в ядрото. Всичко напразно, отново и отново кръпките бяха отхвърлени, а самият автор беше грубо отстранен от бизнеса.

С течение на времето обаче работата на Кон Коливас се изплати. Инго Молнар прочете източниците си и написа планировчика CFS (Completely Fair Scheduler), а Linux веднага го включи в ядрото 2.6.23. Оттогава нещата се подобриха много при настолните компютри и Linux стана много по-бърз (въпреки че внедряването на Kohn продължава да показва по-впечатляващи резултати).

Вторият основен крайъгълен камък по пътя на Linux към десктопа беше включването на известната корекция от 200 страници в ядрото 2.6.38, както и появата на неговия аналог в езика bash. Така Linux се научи да отделя интерактивните процеси от всички други демони, сървъри и bash скриптове и да им дава по-високи приоритети. Това събитие допълнително подобри ситуацията и я направи почти идеална: сега Linux не се забави дори когато ядрото беше преустроено в няколко нишки във фонов режим.
И накрая, третата важна стъпка за десктоп Linux (и тук стигам до най-важната) беше появата на демона ulatencyd, който може динамично да регулира отзивчивостта на системата, приспособявайки я към променящите се обстоятелства.

Подобно на корекцията на ядрото, ulatencyd използва механизма cgroups за групиране на интерактивни процеси и промяна на техните приоритети, но работата му не свършва дотук. Демонът използва евристика за откриване на „най-интерактивните“ процеси, както и очевидни системни саботьори като форк бомби и програми с големи изтичания на памет. В същото време първите получават още по-голям приоритет, докато вторите са силно ограничени във възможностите си (получават нисък приоритет, ограничения върху наличната памет), изолирани или унищожени. Но най-важното е, че по всяко време демонът може да бъде обучен на нови правила за избор на процес, така че сега да можем да присвоим най-високите (дори в реално време) приоритети на нашите любими игри, видео плейъри и браузъри.

Демонът поддържа плъгини, така че неговата функционалност може да бъде разширена до фантастични възможности. Например, вече е наличен (и то стандартен) плъгин, който следи работата на потребителя в X и присвоява най-висок приоритет на новоотваряните приложения и процеси, чиито прозорци са на преден план.

За да инсталирате ulatencyd, трябва да изтеглите изходния му код от страницата и да го изградите с помощта на стандартния cmake и make:

$cmake
$make
$ sudo make install

$ sudo /usr/local/sbin/ulatencyd -v 2

И вижте как той групира процесите по приоритет:

$ ps xaf -eo pid,сесия,аргументи,cgroup

Не е необходимо да се правят настройки. По подразбиране демонът предпочита мултимедията и най-използваните интерактивни приложения, оставяйки фоновите задачи да работят тихо, без да се намесват в основната система.

щафета: на три фронта

Каква е връзката между мониторинга на мрежовия хост, балансирането на натоварването и прокси сървъра? Това всички функции на една машина ли са? Да, напълно възможно е. Но какво ще стане, ако кажа, че и трите функции са тясно свързани и трябва да бъдат реализирани в едно универсално приложение? Рейв? Въобще не.

Вземете например една доста често срещана сървърна функция в тесни кръгове, наречена „балансиране на натоварването между няколко DNS сървъра“. Какво е необходимо за решаването му? Първо, възможността за пренасочване на DNS трафик към друг хост (от балансиращия към един от истинските DNS сървъри).

Това може да стане чрез защитна стена или специално конфигуриран BIND (донякъде тежък). Второ, възможността да изберете най-подходящия кандидат за обработка на заявка от списък с DNS сървъри. Това вече е по-сложно и тук може да се нуждаете от специализиран софтуер или отново защитна стена (но много добра). Трето, възможността да проверявате DNS сървърите за наличност и да премахвате тези, които са паднали от списъка. Имате нужда от скрипт, който пингва хостове и управлява списъци, или специални възможности за защитна стена (има ли такова нещо?). Като цяло, дълго досадно изграждане на велосипед или закупуване на специализирано решение за конкретна задача на нереалистични цени. Но какво ще стане, ако утре изведнъж трябва да направите нещо подобно за SMTP?

Редактиране или повторно отваряне на портфейла? Не си струва, по-добре е да запазите съдържанието на портфейла и да оставите патериците с велосипеди на спортистите. Релейният демон, въведен в OpenBSD 4.3, ви позволява да разрешите тази и огромен брой други задачи, подобни и не толкова, само за няколко минути.

Той включва възможностите на балансьор на натоварването за протоколи от слой 3, 4 и 7, прокси от слой 7 (релета) и услуга за проверка на наличността на мрежови възли (от които произлиза).

Можете да създадете голямо разнообразие от конфигурации, базирани на relayd, вариращи от прости прокси сървъри или SSL ускорители до сложни решения като прозрачни уеб проксита с филтриране на заявки и балансиране на натоварването между няколко уеб сървъра. И всичко това с помощта на прост конфигурационен файл, чиято дължина дори и в най-сложните конфигурации рядко надхвърля 50 реда.

Да, разбира се, без пример, всичко това са само думи. Ето една работеща конфигурация, която напълно отговаря на изискванията, посочени в началото на раздела:

#vi /etc/relayd.conf

Променливи и макроси

Адрес и порт на нашето реле

relayd_addr="127.0.0.1"
relayd_port="8053"

Адреси на три DNS сървъра, които ще обработват

заявки

маса { 192.168.1.1, 192.168.1.2, 192.168.1.3 }

Основни настройки

Интервал между проверките на хоста за наличност

(10 секунди)

Време за изчакване за проверка на хостове за наличност чрез метода TCP

(ако хостът не отговаря повече от 200 ms - той не работи)

Ние разделяме сървъра на 5 процеса за по-голяма ефективност

обработка на заявка

Регистрирайте резултатите от проверката на хостове за наличност

Настройки на DNS протокола

Опции за оптимизиране на връзката

dns протокол "dnsfilter" (tcp (nodelay, sack, socket buffer 1024, backlog 1000))

Настройки на релето

реле dnsproxy(

Адрес и порт на слушане

слушане на $relayd_addr порт $relayd_port

Работим с описания по-рано протокол

протокол "dnsfilter"

Изпращаме DNS пакети до един от изброените в таблицата

DNS сървъри, след проверка за наличност

препраща порт 53
режим проверка на баланса на натоварването tcp
}

Най-важните части от тази конфигурация са в тялото на протокола dns и директивите за реле. Първият е вид шаблон, който се използва, за да се избегне повтарянето на същите настройки на протокола в други части на конфигурационния файл (relayd поддържа три протокола: HTTP, DNS и TCP). Втората е настройката на релето, която определя порта за слушане, прокси протокола, неговите настройки и информация за това как и към кой хост трябва да бъдат пренасочени пакетите. В нашия случай проксито трябва да изпрати DNS заявка до един от трите сървъра с предварителна проверка за достъпност (това използва TCP ръкостискане, но relayd поддържа много други методи, вариращи от ping до опит за установяване на SSL връзка). В същото време, ако един от DNS сървърите не работи, relayd автоматично ще го изключи от списъка, докато планираната проверка за наличност (интервалът между проверките е посочен в опцията за интервал) покаже неговата работоспособност.

Можете да използвате следния формуляр за стартиране на реле, за да тествате вашата конфигурация:

# relayd -d -vv -f /etc/relayd.conf

Така демонът няма да отиде на заден план и ще поддържа подробен списък на всичките си действия. След отстраняване на грешки в конфигурацията можете да конфигурирате демона да стартира по време на зареждане на системата. За да направите това, просто поставете реда relayd_flags="" във файла /etc/rc.conf.local.

FreeBSD fscd: красотата на минимализма

Този раздел не трябваше да присъства в статията. Демонът fscd е толкова прост инструмент, че изглеждаше излишно да се пише за него отделно. От друга страна е невъзможно да не се пише за него, защото това е един от най-ярките примери за правилното решение на проблем в UNIX стил. И задачата на разработчиците на FreeBSD беше следната.
Различни системни и не толкова демони могат да се сринат от време на време (или да започнат да се държат като идиоти, което е още по-лошо). На домашна машина това не е страшно, можете да рестартирате паднала машина с ръцете си или да изпратите компютъра да се рестартира. Но какво да правите на сървър, където администраторът е рядък?

Услугите трябва да се наблюдават и да се рестартират при необходимост. Как да го направя? Естествено, за да вградите тази функционалност в системата за инициализация (в края на краищата тя е тази, която стартира демоните). И например Solaris направи точно това, толкова екстравагантно, че самият Линус Торвалдс щеше да си счупи крака, докато измисляше как да го конфигурира. Разработчиците на FreeBSD се отнесоха лесно. Те са написали отделен демон, който може да стартира инициализиращите скриптове на FreeBSD, като същевременно остава напълно независима система. Въпросът е, че fscd е толкова прост, че можете да го използвате, без да четете man страници или да се притеснявате, че ще се срине. Преценете сами, за да направите fscd монитор, например sshd, трябва да въведете само една команда:

# fscadm активира sshd /var/run/sshd.pid

Това е всичко, fscd ще запомни този избор и автоматично ще активира наблюдението, след като машината се рестартира. Единственото условие е контролираният демон да има инициализиращ файл в директорията /etc/rc.d (или /usr/local/etc/rc.d) и запис във файла /etc/rc.conf, който го включва (това е очевидно).

Демонът fscd ще бъде достъпен само във FreeBSD 9.0, но е напълно възможно да го изтеглите от официалната страница (people.freebsd.org/~trhodes/fsc) и да го компилирате за 8.0.

заключения

Всеки ден се появява нещо ново в света на UNIX, но много рядко това ново се оказва нещо, което заслужава нашето внимание. В тази статия говорих за четири системни компонента на UNIX, които не само заслужават специално внимание, но и са от реална употреба. Кой знае, може би в бъдеще те ще бъдат неразделна част от UNIX като командата grep или syslog daemon.

Връзки

• дом на systemd под крилото: freedesktop.org/wiki/Software/systemd ; freedesktop.org
• източници на systemd: cgit.freedesktop.org/systemd ;
• ulatencyd код: github.com/poelzi/ulatencyd ;
• fscd източници: people.freebsd.org/~trhodes/fsc.

инфо

• В дългосрочен план авторът възнамерява да превърне systemd в пълноценен мениджър на сесии, който може да замени gnomesession и kdeinit.
• Освен всичко друго, systemd има функции за наблюдение на демон, така че възможностите на fscd са вградени в него от раждането.
• Неизползването на скриптове е един от начините за ускоряване на процеса на изтегляне. Много задачи за инициализация могат да бъдат изпълнени от systemd чрез директно извикване на необходимите команди, без използването на скриптове.
• Предишното име на relayd - hosted (от думите host state, "host state"), беше променено на сегашното във връзка с разширяването на функционалността.

systemd е нов демон за инициализация на системата Linux, който в крайна сметка трябва да замени класическия демон SysV initd. Основните задачи, които е проектиран да решава, са, първо, ускоряване на зареждането на системата чрез максимизиране на броя на услугите, работещи паралелно, второ, подобряване на управляемостта на системата чрез използването на специфични функции, предоставени от ядрото на Linux, и трето, обединяване на цялата система настройки и максимално обобщаване на кода за стартиране на различни услуги. Поне така се почувствах, след като прочетох документацията.

Искам да благодаря на Сергей Пташник за отличния превод на документацията на systemd: systemd за администратора от автора на самата система, Lennart Potering. Искам да благодаря и за многото бележки към документацията, които винаги се оказват на място. Тази и следващите ми бележки по същество се основават на тази документация или по-скоро на нейната PDF версия.

1. Инсталирайте systemd

Инсталирането на systemd е доста лесно. Нека първо инсталираме пакета:
# apt-get install systemd И запишете използването на systemd в настройките на ядрото на Linux. За да направите това, отворете файла с настройките за зареждане на GRUB 2:
# vi /etc/default/grub И добавете допълнителна опция init=/lib/systemd/systemd към настройката GRUB_CMDLINE_LINUX_DEFAULT. След редактиране тази опция изглежда така:
GRUB_CMDLINE_LINUX="video=VGA-1:640x480 video=TV-1:640x480 rootfstype=ext4 init=/lib/systemd/systemd" Сега приложете промените, като генерирате нов конфигурационен файл на буутлоудъра:
# update-grub Сега можете да рестартирате системата, за да започнете да използвате systemd:
# изключване -r сега 2. Разрешаване на проблеми

2.1. Локализация на текстовата конзола

Първият проблем, с който се сблъсках, беше грешка при стартиране на конзолния скрипт на кирилица. Този скрипт трябва да се изпълнява с активна текстова конзола и systemd изпълнява всички init скриптове асинхронно, карайки този скрипт да се изпълнява, когато X сървърът вече работи. В резултат на това вместо руски букви в конзолата се показват квадрати, не можете да превключите оформлението и да се върнете към графичната сесия.

Console-cyrillic е остарял пакет, останал в моята система от момента, в който го инсталирах (което беше по времето на Etch). Този пакет присъства в по-новите версии на Debian и все още се поддържа, но пакетите за настройка на конзолата и конфигурацията на клавиатурата са по-общи алтернативи. Статията Показване на руски в конзолата Ubuntu 11.04 Natty описва необходимите стъпки за настройката им.

Инсталирайте необходимите пакети:
# apt-get install console-setup keyboard-configuration Ако по някаква причина конфигураторът на пакети не е стартиран при инсталиране на пакети, можете да принудите конфигурацията на пакета:
# dpkg-reconfigure console-setup # dpkg-reconfigure keyboard-configuration По принцип systemd предоставя нови конфигурационни файлове за настройка на текстова конзола, но тези настройки не работят на моята система.

2.2. Запазване на системното време в хардуерния часовник на BIOS

Когато променяте настройките за време, по някаква причина времето не се записва в часовника на BIOS. Можете да запишете текущото системно време в хардуерния часовник с командата:
# hwclock -w Действителното време, което ще бъде съхранено в часовника на BIOS, зависи от третия ред на /etc/adjtime. В случай на UTC низ ще бъде запазено средното време по Гринуич, в случай на LOCAL низ ще бъде запазено времето на текущата часова зона.

Трябва да се отбележи, че след Wheezy UTC настройката е премахната от /etc/default/rcS файла и настройката от /etc/adjtime: release-notes: utc/local timezone вече не е в /etc/default/rcS вместо това се използва файл.

Коренът на проблема се крие във факта, че използвам openntpd, а не ntpd. В случай на работещ ntpd в ядрото на системата е включено запазване на текущото системно време в хардуерен таймер на всеки 11 минути. Разработчиците на systemd смятат, че това е достатъчно. Ако не се използва ntpd, тогава е невъзможно да се определи кой от часовниците е по-точен - хардуерен или системен, така че няма смисъл да се предпочита един часовник пред друг. Ако е необходимо, потребителят трябва ръчно да настрои часовника според нуждите.

За да разреша този проблем, реших да напиша собствен сервизен файл за демона openntpd. Съдържанието на сервизния файл /etc/systemd/system/openntpd.service:
Описание=openntpd След=network.target Тип=прост ExecStart=/usr/sbin/ntpd -dsf /etc/openntpd/ntpd.conf ExecStartPost=/bin/chown ntpd /var/lib/openntpd/ntpd.drift ExecStop=/sbin /hwclock -w WantedBy=multi-user.target Сега трябва да спрем вече работещия екземпляр на openntpd, да кажем на systemd, че конфигурацията му е променена:
# systemctl stop openntpd.service # systemctl daemon-reload Автоматично зареждане на новосъздадения сервизен файл и стартиране на openntpd:
# systemctl активира openntpd.service # systemctl стартира openntpd.service 3. Управление на услугата

Systemd, за разлика от inetd, може независимо да наблюдава всички процеси, генерирани от услугата. За това се използват така наречените контролни групи от процеси - cgroups. Всяка услуга започва със собствен идентификатор на група. Всички допълнителни процеси, създадени в рамките на услугата, също получават този идентификатор. Това елиминира необходимостта от използване на PID файлове за управление на услугата. Също така, благодарение на cgroups, процесите, породени от услуга, никога не се губят. Например, CGI процесът ще бъде спрян заедно с уеб сървъра, дори ако уеб сървърът не се погрижи да го спре и да постави идентификатора на процеса в PID файла. Потребителските процеси също са поставени в отделна контролна група и се наблюдават от подсистемата за влизане, която замени ConsoleKit.

Втората важна характеристика на systemd е, че има собствена система за журналиране, наречена journald. Тази система събира информация от различни източници и я свързва с услуги. Събира съобщения на ядрото, съобщения на процеси, изпратени чрез syslog, съобщения, изпратени чрез собствения API на journald, и съобщения, изпратени от процес към стандартен изход (STDOUT) и към стандартния поток за диагностични съобщения (STDERR) на едно място, свързано с услуга. Systemd също следи кодовете за изход на процеса. Благодарение на това цялата диагностична информация на услугата може да се види на едно място и е удобно да се диагностицират проблеми.

systemctl- преглед на статусите на услугите. Ако изходът на командата не се пренасочва някъде, а стига до конзолата, тогава автоматично се стартира програма за пейджър, за да видите състоянието на услугите, обикновено е по-малко,
системно състояние openntpd.service - подробен преглед на състоянието на посочената услуга (openntpd),
systemctl status --follow openntpd.service - преглед на състоянието на посочената услуга (openntpd) с показване на съобщения от услугата в процеса на тяхното получаване. Тази опция има по-кратък аналог - -f, който по някаква причина не работи на моята система. Може би фактът е, че опцията -f има и второ значение - --force и systemctl не може да определи коя от опциите има предвид,
systemctl състояние -n10 openntpd.service - преглед на състоянието на посочената услуга (openntpd) с изхода на последните 10 съобщения на услугата,
неуспешно нулиране на systemctl- нулиране на всички състояния на прекратяване, показани от командата за преглед на състоянието на услугата,
systemd-cgls- преглед на йерархията на групите за контрол на процеси (нещо подобно може да се получи с помощта на командата ps xawf -eo pid,user,cgroups,args),
systemctl демон-презареждане- презаредете конфигурацията на systemd,
systemctl стартиране openntpd.service - стартирайте посочената услуга (openntpd), подобно на update-rc.d openntpdстартирайте за SysV initd,
systemctl спиране openntpd.service - спиране на посочената услуга (openntpd), подобно на update-rc.d openntpdспиране за SysV initd,
systemctl рестартиране openntpd.service - рестартирайте посочената услуга (openntpd),
systemctl активиране openntpd.service - разрешаване на стартиране на посочената услуга (openntpd) при зареждане на системата, подобно на update-rc.d openntpdактивирайте за SysV initd,
systemctl деактивиране openntpd.service - забранете стартирането на посочената услуга (openntpd) при зареждане на системата, подобно на update-rc.d openntpdдеактивиране за SysV initd,
systemctl маска openntpd.service - забрана за стартиране на посочената услуга (openntpd), дори ще бъде невъзможно да се стартира ръчно,
systemctl демаскиране openntpd.service - разрешение за стартиране на посочената услуга (openntpd), тя може да бъде стартирана ръчно, също така ще бъде разрешено да стартира при зареждане на системата, ако е конфигурирана,
systemctl убиване openntpd.service - изпраща сигнал (по подразбиране се изпраща сигнал SIGTERM) до всички процеси в контролната група на услугата (openntpd),
systemctl kill -s SIGKILL openntpd.service - изпраща сигнал SIGKILL до всички процеси в контролната група на услугата (openntpd). Можете да използвате и съкратеното име на сигнала - KILL,
systemctl kill -s HUP --kill-who=main crond услуга - Изпращане на сигнал SIGHUP към основния процес на групата за управление на услугата (crond). Този пример ще принуди crond да прочете отново конфигурационния файл, докато заданията, стартирани от crond, няма да получат този сигнал и ще продължат да работят нормално,
помощ за systemctl openntpd.service - преглед на сервизната документация (не работи в Debian Wheezy),
systemd-analyze вина- показване на списък с услуги, подредени в низходящ ред на времето, изразходвано за стартирането им. Командата може да бъде полезна за намиране на тесни места по време на инициализация на системата,
systemd-analyze plot > plot.svg- извеждане на времева диаграма във формат SVG, илюстрираща последователността (и паралелизма) на стартиране на услугите.

4. Нови системни конфигурационни файлове

Systemd въвежда редица нови конфигурационни файлове за системни настройки. Очаква се тези файлове в крайна сметка да станат стандартни и да заменят системните конфигурационни файлове, които са специфични за различни дистрибуции. Докато това се случи, systemd ще използва конфигурационните файлове на дистрибуцията, ако няма нови файлове.

Също така, тъй като всички услуги сега ще бъдат стартирани с помощта на сервизни файлове, няма нужда да използвате файлове, включени в скриптове на обвивката. Това са файлове, разположени в /etc/default (семейство Debian) и /etc/sysconfig (семейство RedHat). Тъй като е много по-лесно да навигирате в сервизните файлове, отколкото в шел скриптовете, няма нужда да премествате сервизните настройки в отделни файлове - всички необходими настройки могат да бъдат въведени директно в сервизния файл.

Ето новите конфигурационни файлове, въведени от systemd:

/etc/име на хост- мрежово име на системата,
/etc/vconsole.conf- настройки на шрифта на системната конзола и клавиатурната подредба,
/etc/locale.conf- системни езикови настройки,
/etc/modules-load.d/*.conf- директория за изброяване на модули на ядрото, които да бъдат принудени да се заредят при зареждане на системата,
/etc/sysctl.d/*.conf- директория за настройки на параметрите на ядрото, допълва класическия файл /etc/sysctl.conf,
/etc/tmpfiles.d/*.conf- директория за управление на настройките на временните файлове,
/etc/binfmt.d/*.conf- директория за регистриране на изпълними файлови формати, като Java, Mono, WINE формати,
/etc/os-release- файл с идентификатора на разпространението и неговата версия,
/etc/machie-id- файл с постоянен уникален системен идентификатор,
/etc/machie-info- файл с описателно мрежово име за системата. Системната икона, която ще се показва в графични черупки, също е конфигурирана тук. Файлът се обслужва от демона systemd-hostnamed.

5. подсистема за регистриране на журнала

Както вече споменахме, systemd въвежда нова система за регистриране, която събира информация от различни източници (съобщения на ядрото, съобщения, изпратени до syslog, STDOUT и STDERR) на едно място. Тази система не ви принуждава да изоставите стандартния демон за регистриране на syslog - можете да използвате и двете системи за регистриране паралелно.

Journald използва две директории за съхраняване на информация от журнала:
/run/log/journal- директория с пръстен буфер на последните съобщения,
/var/log/journal- директория с постоянно съхранение на всички съобщения.

По подразбиране се използва само първата директория и за да се даде възможност за постоянно съхранение на всички съобщения, втората директория трябва да бъде създадена ръчно (в Debian Wheezy тази директория се създава автоматично, когато е инсталиран systemd, а първата директория не се използва):
# mkdir -p /var/log/journald След това можете, но не е необходимо, да премахнете демона за журналиране по подразбиране rsyslog или ng-syslog.

Настройките на journald daemon на Debian Wheezy се съхраняват във файл /etc/systemd/systemd-journald.conf. По-специално, там можете да зададете настройки за компресия за регистрационния файл, да зададете ограничение за размера на регистрационните файлове, да конфигурирате дублиране на съобщения към системната конзола или към syslog daemon.

Потребителят root и потребителите в групата adm имат достъп до всички съобщения в дневника, докато нормалните потребители имат достъп само до съобщенията, генерирани от техните процеси.

За да прегледате съобщенията в журнала в Debian Wheezy, можете да използвате командата systemd-journalctl (ръководството посочва командата journalctl):
systemd-journalctl- преглед на всички съобщения. Както в случая на systemctl, ако изходът на командата не се пренасочва никъде, а стига до конзолата, автоматично се стартира програма за пейджър за по-удобно гледане на съобщения, обикновено по-малко,
systemd-journalctl -f- преглед на съобщения в процеса на тяхното получаване,
systemd-journalctl -n10- преглед на последните 10 съобщения,
systemd-journalctl -b- преглед на съобщенията, генерирани след зареждане на системата (не работи на Debian Wheezy),
systemd-journalctl -b -p грешка- преглед на съобщенията, генерирани след зареждане на системата и имащи грешка с приоритет или по-висок (не работи в Debian Wheezy),
systemd-journalctl --since=вчера- преглед на всички съобщения, генерирани от вчера (не работи в Debian Wheezy),
systemd-journalctl --since=2012-10-15 --until="2012-10-16 23:59:59"- вижте всички съобщения, генерирани на 15 и 16 октомври 2012 г. (не работи на Debian Wheezy),
systemd-journalctl -u httpd --от=00:00 --до=09:30- преглед на всички съобщения, генерирани от httpd потребител днес от полунощ до девет и половина (не работи на Debian Wheezy),
systemd-journalctl /dev/sdc- вижте всички съобщения, в които се споменава sdc устройството (не работи на Debian Wheezy),
systemd-journalctl /usr/sbin/vpnc- преглед на всички съобщения от /usr/sbin/vpnc процеси (не работи в Debian Wheezy),
systemd-journalctl /usr/sbin/vpnc /usr/sbin/dhclient- преглед на всички съобщения от процесите /usr/sbin/vpnc и /usr/sbin/dhclient, комбинирани и сортирани по време (не работи в Debian Wheezy),

В допълнение към простото разглеждане на текстови съобщения е възможно да видите метаданните, които journald добавя към всеки запис в дневника. За да видите тези полета, просто използвайте следната опция, която превключва формата на изходните данни:
systemd-journalctl -o подробен- Показва всички метаданни, придружаващи съобщението, в удобна за четене форма заедно със съобщението от дневника. Други налични формати: експортиране - същият многословен формат, но без отстъпи, json - извеждане във формат JSON, cat - извеждане само на текст на съобщение без допълнителни данни.

Имената на полетата, започващи с долна черта, могат да се използват за филтриране на съобщения. Списанието е индексирано във всички полета, така че търсенето е бързо. Примери за филтриране на съобщения по метаданни:
systemd-journalctl _UID=70- показва всички съобщения от потребителски процеси с ID 70,
systemd-journalctl _UID=70 _UID=71- извеждане на всички съобщения от потребителски процеси с идентификатори 70 и 71. Посочването на полета със същото име автоматично предполага логическа операция ИЛИ,
systemd-journalctl _HOSTNAME=epsilon _COMM=avahi-daemon- извежда всички съобщения от процеси с име avahi-daemon, работещи на компютър с име epsilon. В този случай са посочени различни полета, така че се подразбира логическа операция И,
systemd-journalctl _HOSTNAME=theta _UID=70 + _HOSTNAME=epsilon _COMM=avahi-daemon- показване на съобщения, които отговарят на някой от двата филтъра, комбинирани със знак +. Знакът + показва изрична логическа операция ИЛИ, която има по-нисък приоритет от И,
systemd-journalctl -F _SYSTEMD_UNIT- извеждане на всички стойности на полето _SYSTEMD_UNIT, налични в дневника. Получените стойности могат да се използват за филтриране на интересни записи (не работи на Debian Wheezy).

Онзи ден ми отне да напиша прост bash скрипт, който постоянно да следи директорията за наличие на *.pdf файлове в нея, с последващото им конвертиране в txt формат. Скриптът трябваше да работи във фонов режим и да се стартира автоматично при рестартиране.

За да реализирам работа във фонов режим, първо написах Linux - демон в C, но след това реших, че това е твърде много за моята задача, и го внедрих с помощта на Systemd.

Първо трябва да се уверите, че вашата дистрибуция работи със Systemd, с командата:

връзка за четене /proc/1/exe
ако изходът е /sbin/init- тогава използвате SysV и трябва или да надстроите дистрибуцията, както в моя случай, надстроих Debian 7 Wheezy до Debian 8 Jessie, или да приложите фонова работа по друг начин.

Ако изходът е:
/lib/systemd/systemd- тогава всичко е наред, имате Systemd.

Systemd върши своята работа с това, което е известно като systemd единици.
Unit е конфигурационен файл, разположен в една от директориите:

/run/systemd/system/- Единици, създадени по време на изпълнение. Тази директория има приоритет пред директорията с инсталирани модули от пакети.
/etc/systemd/system/- единици, създадени и управлявани от системния администратор. Тази директория има предимство пред директорията с модули, създадени по време на изпълнение. В тази директория ще създадем нашата единица.

Отиваме в директорията /etc/systemd/system/ и я създаваме или копираме съществуващ файл, например sshd.service, и пишем в него:

[Мерна единица]

Описание=MyBashScript

След=syslog.target

1. [Обслужване]

2. ExecStart=/bin/bash "/home/user/scripts/script.sh"

   Тип=разклонение

3. [Инсталирай]

   WantedBy=multi-user.target

   Псевдоним=bash.service

Повече за всеки раздел:
Раздел:
Съдържа обща информация за услугата, нейното описание и това, че тя трябва да стартира след стартиране на демона на Syslog.

Раздел
Директна информация за нашата услуга.
Параметърът ExecStart сочи към изпълнимия файл на нашата услуга. Трябва да посочите абсолютни пътища, в случай на bash скрипт, ние вземаме пътя до скрипта в единични кавички.
Type=forking означава, че изпълняваният скрипт ще работи в режим на демон. Ако искаме скриптът да се изпълни веднъж, тогава задаваме Type=simple.

Раздел
Последният раздел съдържа информация за целта, в която услугата трябва да започне. В този случай искаме услугата да се стартира, когато multi-user.target е активиран (това е еквивалентът на init 3 в SysV).
Alias=bash.service - за удобство нека създадем псевдоним, за да улесним управлението на нашата услуга чрез systemctl.

Това е работещ служебен файл Systemd, с малко функционалност. Запазете файла и изпълнете командата systemctl демон-презарежданетака че Systemd да знае за нашата услуга и можете да я стартирате с командата systemctl стартира bash.service.
При мен не проработи първия път, защото първоначално посочих неабсолютен път в параметъра ExecStart на секцията. След корекцията Systemd все още се оплакваше от същата грешка, рестартирането помогна.

За да видите състоянието, стартиране, спиране, рестартиране, активиране или деактивиране на системни услуги, използвайте командата systemctl. По-ранните версии на Systemd използваха командите service и chkconfig и те все още са включени в системата, главно за обратна съвместимост.

По-долу са основните команди systemctl:

systemctl начално име.услуга- стартиране на услугата.
systemctl стоп name.service- сервизно спиране
systemctl рестартирайте name.service- рестартиране на услугата
systemctl опитайте-рестартирайте name.service- рестартирайте услугата само ако работи
systemctl презареди name.service- презареждане на конфигурацията на услугата
systemctl status name.service- проверете дали услугата работи с подробен изход за състоянието на услугата
systemctl е активно име.услуга- проверете дали услугата работи с прост отговор: активен или неактивен
systemctl list-units --type услуга --all– показване на състоянието на всички услуги
systemctl активира name.service– активира услугата (позволява да стартира по време на стартиране на системата)
systemctl деактивира name.service- деактивирайте услугата
systemctl активира отново name.service– деактивира услугата и веднага я активира
systemctl е разрешен name.service- проверява дали услугата е активирана
systemctl list-unit-files --type услуга– показва всички услуги и проверява кои са активирани
systemctl mask name.service- замества сервизния файл със символна връзка към /dev/null, което прави устройството недостъпно за systemd
systemctl демаскирайте name.service- връща сервизен файл, което прави устройството достъпно за systemd

Systemd е система за стартиране и системен мениджър, който се превръща в новия стандарт за Linux машини. Дебатът относно производителността на systemd в сравнение с традиционните системи за стартиране на SysV все още продължава, но повечето дистрибуции планират да внедрят тази система и много вече са го направили.

Научаването и работата с инструментите и демоните на systemd ще ви помогне да оцените по-добре мощността, гъвкавостта и други характеристики на системата или поне да се справите с минимални проблеми.

Този урок ще ви научи как да работите с командата systemctl, основният инструмент за управление на системата systemd init. Ще научите как да управлявате услуги, да проверявате състоянието и да работите с конфигурационни файлове.

Управление на услугата

Основната цел на системата за стартиране е да инициализира компонентите, които трябва да бъдат стартирани след зареждане на ядрото на Linux (традиционно наричани "персонализирани" компоненти). Системата за стартиране се използва и за управление на сървърни услуги и демони. Имайки предвид това, нека започнем нашето въведение в systemd с прости операции за управление на услугата.

В systemd целта на повечето действия са единици, които са ресурси, които systemd може да управлява. Единиците се категоризират според видовете ресурси, които представляват. Единиците се дефинират в така наречените единици файлове. Типът на всяка единица може да се определи от суфикса в края на файла.

Файловете с единици със суфикс .service са предназначени за задачи за управление на услуги. Въпреки това, в повечето случаи суфиксът .service може да бъде пропуснат, тъй като systemd е достатъчно умен, за да разбере какво да прави, когато използва команди за управление на услугата без суфикса.

Стартиране и спиране на услугата

За да стартирате systemd услуга, използвайте командата start. Ако не сте в root сесия, трябва да използвате sudo, тъй като тази команда ще повлияе на състоянието на операционната система:

sudo systemctl стартиране на application.service

Както бе споменато по-рано, systemd знае да търси *.service файлове за команди за управление на услугата, така че тази команда може да бъде въведена по следния начин:

sudo systemctl стартира приложение

Горният формат може да се използва в ежедневната работа, но в ръководството за яснота ще използваме суфикса .service.

За да спрете услугата, просто въведете командата за спиране:

sudo systemctl спира application.service

Рестартирайте и рестартирайте

За да рестартирате услугата, използвайте рестартиране:

sudo systemctl рестартирайте application.service

Ако посоченото приложение може да презареди конфигурационните си файлове (без рестартиране), може да се използва презареждане:

sudo systemctl презареди application.service

Ако не знаете дали дадена услуга може да презареди своите файлове, използвайте командата reload-or-restart. Той ще рестартира услугата и ако това не е възможно, ще я рестартира.

sudo systemctl презареждане или рестартиране на application.service

Активиране и деактивиране на услуги

Горните команди са необходими при работа с услугата в текущата сесия. За да добавите услуга към systemd autoload, трябва да я активирате.

Има команда за активиране за това:

sudo systemctl активира application.service

Това ще създаде символна връзка към копие на сервизния файл (обикновено /lib/systemd/system или /etc/systemd/system) в точката на диска, където systemd търси файлове за автоматично стартиране (обикновено /etc/systemd/system/ some_target.target.want, повече за това по-късно в ръководството).

За да премахнете услугата от стартиране, трябва да въведете:

sudo systemctl деактивира application.service

Имайте предвид, че активирането на услуга не я стартира в текущата сесия. Ако искате да стартирате услугата и да я включите в стартирането, трябва да изпълните командите за стартиране и активиране.

Проверка на статуса на услуга

За да проверите състоянието на услуга, въведете:

systemctl status application.service

Тази команда ще изведе състоянието на услугата, йерархията на групата и първите няколко реда от дневника.

Например, когато проверявате състоянието на сървъра на Nginx, може да видите резултат като този:

nginx.service - Високопроизводителен уеб сървър и обратен прокси сървър
Заредено: заредено (/usr/lib/systemd/system/nginx.service; активирано; предварително зададено от доставчика: деактивирано)
Активен: активен (работи) от вторник 2015-01-27 19:41:23 EST; преди 22 часа
Основен PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: главен процес /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: работен процес
27 януари 19:41:23 desktop systemd: Стартиране на високопроизводителен уеб сървър и обратен прокси сървър...
27 януари 19:41:23 desktop systemd: Стартира Уеб сървър с висока производителност и обратен прокси сървър.

Това предоставя преглед на текущото състояние на приложението, уведомява ви за всички проблеми и всяко действие, което може да се наложи в бъдеще.

Има и методи за проверка на конкретни състояния. Например, за да проверите дали даден модул е ​​активен (работи), можете да използвате командата is-active:

systemctl е активно приложение.услуга

Това ще покаже текущото състояние на устройството, обикновено активно или неактивно. Изходният код ще бъде "0", ако единицата е активна, което опростява процеса на анализ.

За да разберете дали дадено устройство е активирано, можете да използвате командата is-enabled:

systemctl е разрешено application.service

Тази команда ще отчете дали услугата е активирана и ще върне кода за изход на "0" или "1" в зависимост от резултата.

Третата команда ви позволява да определите дали устройството е в неизправно състояние. Това показва, че е имало проблем със стартирането на въпросния модул:

systemctl е неуспешно application.service

Командата ще се върне активна, ако модулът работи правилно, и неуспешна, ако е възникнала грешка. Ако модулът е спрян нарочно, командата може да върне неизвестна или неактивна. Код за изход "0" означава, че е възникнала грешка, докато "1" показва всяко друго състояние.

Преглед на състоянието на системата

По-рано разгледахме командите, необходими за управление на отделни услуги, но те не са много полезни за изследване на текущото състояние на системата. Има няколко команди systemctl, които предоставят тази информация.

Преглед на списък с текущи единици

За да поискате списък с текущи единици systemd, използвайте командата list-units:

systemctl списъчни единици

Тази команда ще изброи всички единици, които в момента съществуват в системата systemd. Резултатът ще изглежда така:

ЕДИНИЧНО ЗАРЕЖДАНЕ АКТИВНО ПОДОПИСАНИЕ
atd.service зареди активен работещ ATD демон
avahi-daemon.service зареди активен работещ Avahi mDNS/DNS-SD стек
dbus.service зареди активна работеща D-Bus системна шина за съобщения
dcron.service зареди активен работещ планировчик на периодични команди
dkms.service зареди активен излез от системата за динамични модули на ядрото
[имейл защитен]зареден активно работещ Getty на tty1
. . .

Резултатът има следните колони:

• UNIT е името на systemd единицата.
• LOAD Показва дали конфигурацията на устройството е била обработена от systemd. Конфигурацията на заредените единици се съхранява в паметта.
• АКТИВЕН - обобщено състояние на блока. Това обикновено ви позволява бързо да определите дали текущият модул е ​​стартиран успешно.
• SUB: Състояние на подниво, което предоставя подробна информация за устройството. Това често зависи от вида на модула, състоянието и действителния метод, в който работи модулът.
• ОПИСАНИЕ - кратко описание на функциите на устройството.

Тъй като командата list-units показва само активни единици по подразбиране, всички от горните записи ще се покажат заредени в колоната LOAD и активни в колоната ACTIVE. Този формат е поведението по подразбиране на systemctl, когато се извиква без допълнителни команди, така че ще видите същото нещо, ако извикате systemctl без аргументи:

С systemctl можете да правите заявки за различна информация чрез добавяне на флагове. Например, за да видите всички единици, които systemd е заредил (или се е опитал да зареди), независимо дали са активни в момента или не, можете да използвате флага -all:

systemctl list-units --all

Тази команда ще докладва единиците, които systemd е заредил или се е опитал да зареди, независимо от текущото им състояние. След стартиране някои единици стават неактивни и единиците, които systemd се опита да зареди, не бяха намерени на диска.

Можете да използвате други флагове, за да филтрирате резултатите. Например, флагът --state= може да се използва за указване на състояния LOAD, ACTIVE или SUB. Флагът --all трябва да бъде оставен, за да може системата да показва неактивни единици:

systemctl list-units --all --state=inactive

Друг популярен филтър е --type=. Позволява ви да филтрирате единици по тип. Например, за да поискате само активни единици, можете да въведете:

systemctl list-units --type=service

Списък на единиците файлове

Командата list-units изброява само единиците, които systemd се е опитал да обработи и зареди в паметта. Тъй като systemd избирателно чете само единиците файлове, които смята, че са му необходими, списъкът няма да включва всички налични единици файлове. За да изброите всички налични модулни файлове (включително тези, които systemd не се опита да зареди), използвайте командата list-unit-files.

systemctl списък-единични файлове

Единиците са представяния на ресурси, за които systemd знае. Тъй като systemd не чете непременно всички дефиниции на единици, той представя само информация за самите файлове. Резултатът се състои от две колони: UNIT FILE и STATE.

СЪСТОЯНИЕ НА ЕДИНИЧНИЯ ФАЙЛ
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount static
var-lib-nfs-rpc_pipefs.mount static
org.cups.cupsd.path е активиран
. . .

Обикновено колоната STATE съдържа стойностите активирани, деактивирани, статични или маскирани. В този контекст статичен означава, че няма раздел за инсталиране във файла на модула, който се използва за активиране на модула. Следователно тези единици не могат да бъдат активирани. Това обикновено означава, че модулът извършва еднократно действие или се използва само като зависимост от друг модул и не трябва да се стартира сам.

Управление на единици

Вече знаете как да работите с услуги и да показвате информация за единици и файлове на единици, за които systemd знае. Можете да получите по-конкретна информация за единиците, като използвате някои допълнителни команди.

Показване на файл на единица

За да покажете файла с единица, който systemd е заредил, можете да използвате командата cat (добавена в systemd версия 209). Например, за да видите файла на демона за планиране atd, можете да въведете:

systemctl cat atd.service
Описание=ATD демон
Тип=разклонение
ExecStart=/usr/bin/atd
WantedBy=multi-user.target

На екрана ще видите единичен файл, който е известен на текущия процес systemd. Това може да е важно, ако наскоро сте променили вашите модулни файлове или ако предефинирате някои опции във фрагмент от единичен файл (повече за това по-късно).

Картографиране на зависимости

За да видите дървото на зависимостта на единица, използвайте командата:

systemctl списък-зависимости sshd.service

Той ще покаже йерархия от зависимости, с които системата трябва да се справи, за да стартира това устройство. Зависимости в този контекст са тези единици, които са необходими за работата на други единици, които са по-високо в йерархията.

sshd.service
├─system.slice
└─основна цел
├─microcode.service
├─rhel-autorelabel-mark.service
├─rhel-autorelabel.service
├─rhel-configure.service
├─rhel-dmesg.service
├─rhel-loadmodules.service
├─paths.target
├─резени.цел
. . .

Рекурсивните зависимости се показват само за .target единици, които показват системни състояния. За рекурсивно изброяване на всички зависимости, добавете флага --all.

За да покажете обратни зависимости (единици, които зависят от определен елемент), можете да добавите флага --reverse към командата. Флаговете --before и --after също са полезни, те показват единици, които зависят от определената единица и се изпълняват преди или след нея.

Проверка на свойствата на единицата

За да видите свойствата на ниско ниво на единица, можете да използвате командата show. Това ще покаже списък със свойства за определената единица във формат ключ=стойност.

systemctl показва sshd.service
Id=sshd.service
Имена=sshd.service
Изисква=basic.target
Wants=system.slice
WantedBy=multi-user.target
Конфликти=shutdown.target
Преди=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Описание=OpenSSH сървър демон
. . .

За да покажете едно от свойствата, подайте флага -p и посочете името на свойството. Например, за да видите конфликти в единицата sshd.service, трябва да въведете:

systemctl шоу sshd.service -p Конфликти
Конфликти=shutdown.target

Маскировка на единица

Systemd може да заключи единица (автоматично или ръчно) чрез създаване на символна връзка към /dev/null. Това се нарича маскиране на единици и се извършва с командата mask:

sudo systemctl маска nginx.service

Сега услугата Nginx няма да стартира автоматично или ръчно, докато маскирането е активирано.

Ако проверите list-unit-files, ще видите, че услугата е маркирана като маскирана:

systemctl списък-единични файлове
. . .
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service маскиран
quotaon.service static
rc-local.service static
rdisc.service е деактивиран
статика на спасителната служба
. . .

Ако се опитате да стартирате услугата, ще получите това съобщение:

sudo systemctl стартира nginx.service
Неуспешно стартиране на nginx.service: Модулът nginx.service е маскиран.

За да демаскирате единица и да я направите достъпна, използвайте unmask:

sudo systemctl демаскирайте nginx.service

Това ще върне услугата в предишното й състояние.

Редактиране на модулни файлове

Въпреки че конкретният формат на модулните файлове не се обсъжда в това ръководство, systemctl предоставя вградени механизми за редактиране и модифициране на модулни файлове. Тази функционалност беше добавена в systemd версия 218.

Командата за редактиране отваря фрагмента на единичния файл по подразбиране:

sudo systemctl редактиране на nginx.service

Това ще бъде празен файл, който може да се използва за отмяна или добавяне на директиви към дефиницията на единицата. Ще бъде създадена директория в директорията /etc/systemd/system, която съдържа името на устройството със суфикса .d. Например за nginx.service ще бъде създадена директорията nginx.service.d.

В тази директория ще бъде създаден фрагмент с име override.conf. Когато единицата е заредена, systemd ще обедини фрагмента за замяна в паметта с останалата част от файла на единицата. Директивите за фрагменти ще имат предимство пред тези, посочени във файла на изходния елемент.

Ако искате да редактирате целия файл с единица, вместо да създавате фрагмент, можете да подадете флага --full:

sudo systemctl edit --full nginx.service

Това ще зареди текущия файл на модула в редактора, където може да бъде модифициран. Когато редакторът се затвори, модифицираният файл ще бъде записан в /etc/systemd/system и ще има предимство пред дефиницията на системния модул (обикновено се намира някъде в /lib/systemd/system).

За да премахнете всички добавки, които сте направили, премахнете директорията config.d или модифицирания сервизен файл от /etc/systemd/system. Например, за да премахнете фрагмент, можете да въведете:

sudo rm -r /etc/systemd/system/nginx.service.d

За да изтриете целия редактиран файл, въведете:

sudo rm /etc/systemd/system/nginx.service

След изтриване на файл или директория, процесът systemd трябва да се презареди, така че системата повече да не се опитва да препраща към тези файлове и да се върне към използване на системни копия. За да направите това, въведете:

sudo systemctl демон-презареждане

Промяна на нивата на изпълнение

Целите са специални модулни файлове, които описват системни нива или точки за синхронизация. Подобно на други единици, целевите файлове могат да бъдат идентифицирани чрез суфикс. В този случай се използва суфиксът .target. Целите сами по себе си не правят нищо, вместо това се използват за групиране на други единици.

Целите могат да се използват за привеждане на системата в определено състояние. По подобен начин други системи за стартиране използват нива на изпълнение. Те се използват като референции, когато са налични определени функции, което ви позволява да посочите желаното състояние, вместо да конфигурирате отделните единици, необходими за създаване на това състояние.

Например, има swap.target, който се използва, за да покаже, че swap е готов за използване. Единиците, които са част от този процес, могат да бъдат синхронизирани за тази цел с помощта на директиви WantedBy= или RequiredBy=. Единиците, които се нуждаят от размяна, могат да уточнят това условие чрез Wants=, Requires= или After= спецификации.

Проверка и задаване на цели по подразбиране

Процесът systemd има цел по подразбиране, която използва при зареждане на системата. Осигуряването на набор от зависимости към тази единствена цел привежда системата в желаното състояние. За да намерите целта по подразбиране, въведете:

systemctl get-default
multi-user.target

Ако искате да зададете различна цел по подразбиране, можете да използвате set-default. Например, ако имате инсталиран графичен работен плот и искате системата да го зарежда по подразбиране, можете да промените целта съответно:

sudo systemctl set-default graphical.target

Списък на наличните цели

Можете да видите списъка с налични цели с командата:

systemctl list-unit-files --type=target

За разлика от нивата на изпълнение, множество цели могат да бъдат активирани едновременно. Активна цел показва, че systemd ще се опита да стартира всички единици, свързани с тази цел, и няма да се опита да ги деактивира. За да видите всички активни цели, въведете:

systemctl list-units --type=target

Целева изолация

Възможно е да стартирате всички единици, свързани с целта, и да спрете всички единици, които не са част от дървото на зависимостите. За това се използва командата isolate. Подобно е на промяната на нивото на изпълнение в други системи за стартиране.

Например, ако работите в графична среда, където целта graphical.target е активна, можете да деактивирате графичната система и да поставите системата в състояние на многопотребителски команден ред, като изолирате multi-user.target. Тъй като graphical.target зависи от multi-user.target, но не и обратното, всички графични единици ще бъдат спрени.

Можете да разгледате зависимостите на изолираната цел, преди да извършите тази процедура, за да сте сигурни, че няма да спрете жизненоважни услуги:

systemctl списък-зависимости multi-user.target

Ако всичко ви подхожда, можете да изолирате целта:

sudo systemctl изолира multi-user.target

Съкращения

Има определени цели за важни събития като изключване или рестартиране. systemctl предлага и няколко преки пътища за бърз достъп.

Например, за да поставите системата в режим на отстраняване на грешки, можете просто да въведете rescue вместо isolate rescue.target:

sudo systemctl спасяване

Това ще осигури допълнителна функционалност - ще уведоми всички потребители на системата за събитието.

За да спрете системата, можете да използвате командата halt:

sudo systemctl спиране

За да инициирате пълно изключване, можете да използвате командата poweroff:

sudo systemctl poweroff

Рестартирането може да бъде стартирано с командата за рестартиране:

sudo systemctl рестартиране

Тези команди ще уведомяват потребителите на системата за събития, които стандартната команда няма да направи. Имайте предвид, че повечето машини използват по-кратки команди за тези операции, за да работят правилно със systemd.

Например, за да рестартирате системата, можете просто да въведете:

Заключение

Вече сте запознати с основните механизми на systemctl и знаете как да управлявате init системата с този инструмент.

Въпреки че systemctl работи предимно с процеса systemd, има други компоненти в системата systemd, които се контролират от други помощни програми. Например, отделни демони и помощни програми се използват за управление на регистриране и потребителски сесии (съответно journald/journalctl и logind/loginctl).