Система инициализации artix. linux статьи

История

Поттеринг и Кей Сиверс , что разработчики программного обеспечения , работающие на Red Hat , которые изначально разработанные Systemd, начали проект для разработки Systemd в 2010 году они стремились превзойти эффективность инициализации демона несколько способов. Они хотели улучшить структуру программного обеспечения для выражения зависимостей, чтобы больше обработки должна быть сделана одновременно или параллельно во время системной загрузки и уменьшить вычислительную нагрузку от оболочки .

В мае 2011 года Fedora стала первым крупным дистрибутивом Linux, в котором по умолчанию включен systemd. В период с октября 2013 г. по февраль 2014 г. в списке рассылки Debian прошли длительные дебаты между Техническим комитетом Debian , в ходе которых обсуждалась система инициализации, которую следует использовать по умолчанию в Debian 8 «jessie», и завершились решением в пользу systemd. Дебаты получили широкую огласку, и после принятия решения они продолжаются в списке рассылки Debian. В феврале 2014 года, после принятия решения Debian, Марк Шаттлворт объявил в своем блоге, что Ubuntu последует за внедрением systemd.

В ноябре 2014 года разработчик Debian Джои Хесс, члены Технического комитета Debian Расс Олбери и Ян Джексон , а также сопровождающий пакетов systemd Толлеф Фог Хин покинули свои должности. Все четверо обосновали свое решение в общедоступном списке рассылки Debian и в личных блогах тем, что подвергались чрезвычайному стрессу, связанному с продолжающимися спорами об интеграции systemd в сообществе Debian и FOSS, что делало регулярное обслуживание практически невозможным.

В августе 2015 года systemd начала предоставлять оболочку входа в систему, вызываемую через оболочку machinectl .

Пишем systemd Unit файл

Первое что стоит сделать — так это проверить инициализацию:

# ps -s1| awk '{print $4}'| grep -Ev "CMD"

PS: Вот небольшая статья:

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

[email protected]

Из созданного блока ( что выше) можно создать экземпляр др блока, который выглядит следующим образом:

[email protected]

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

Ниже приведены некоторые из наиболее распространенных спецификаторов, которые будут заменены, когда юнит-экземпляра интерпретируется с соответствующей информацией:

%n: В любом месте, где это используется, будет добавлено полное имя элемента.
%N: Это то же самое, что и выше, но любое экранирование, такое как те, что присутствуют в шаблонах пути файла, будет отменено.
%p: Это указывает префикс имени юнита. Это часть названия юнита, которая предшествует символу @.
%P: Это то же самое что и выше, но с любым отступлением.
%i: Это ссылается на имя экземпляра, которое является идентификатором, следующим за @ в экземпляре. Это один из наиболее часто используемых спецификаторов, поскольку он динамичный. Использование этого идентификатора поощряет использование значимых идентификаторов конфигурации. Например, порт, в котором будет выполняться служба, может использоваться как идентификатор экземпляра, и шаблон может использовать этот спецификатор для настройки спецификации порта.
%I: Этот спецификатор такой же, как и выше, но с любым отступлением.
%f: Это будет заменено на имя неэкранированного юнита или имя префикса, добавленное к «/».
%c: Это будет указывать на управляющую группу устройства со стандартной родительской иерархией /sys/fs/cgroup/ssytemd.
%u: Имя пользователя, настроенного для запуска юнита.
%U: То же, что и выше, UID вместо имени.
%H: Имя хоста системы, на котором выполняется юнит.
%%: Это используется для вставки буквенного знака процента.

Используя приведенные выше идентификаторы в шаблоне файла, Systemd заполнит правильные значения при интерпретации шаблона для создания юнит-экземпляра.

Системы инициализации Linux

За время развития операционных систем были созданы различные системы инициализации Linux. В разных дистрибутивах использовались разные системы. В этой статье мы рассмотрим лучшие системы инициализации, которые вы можете сейчас использовать. Мы начнем с более старых систем с меньшим функционалом, чтобы понять с чего все начиналось, затем подойдем к более новым, созданным в последнее время.

1. System V Init

System V или SysV — это довольно старая, но до сих пор ещё популярная система инициализации Linux и Unix подобных операционных систем. Она была основой для создания многих других систем инициализации, а также первой коммерческой системой инициализации разработанной для Unix в AT&T. Она была разработана еще в 1983 году.

Почти все дистрибутивы Linux изначально использовали SysV. Исключением была только Gentoo, в которой использовалась собственная система инициализации и Slackware, с инициализацией в стиле BSD.

Основные возможности SysV:

Написание файлов запуска служб на bash;
Последовательный запуск служб;
Сортировка порядка запуска с помощью номеров в именах файлов;
Команды для запуска, остановки и проверки состояния служб.

Никакой параллельной загрузки, системы зависимостей, запуска по требованию и автоматического запуска здесь не было и в помине.

С момента ее разработки прошло много лет и из-за некоторых недостатков были разработаны другие системы для ее замены, они хоть и имели новые функции и были более эффективны, но они были по-прежнему совместимы с SysV.

Юниты systemd.

Прежде всего, нужно разобраться что такое юнит, что означают его статус, и как их фильтровать. Unit — это описание сервиса в текстовом виде, где указаны операции, которые должны быть выполнены до и после запуска службы. Юнит — это описание параметров системы инициализации.

root@dedicated:~ /etc/init.d/nginx status

Общая команда будет иметь следующий вид:

root@dedicated:~ sudo service nginx status

…или выполнить тоже самое с помощью systemd:

root@dedicated:~ systemctl status nginx.service

Посмотреть список всех запущенных юнитов можно командой:

root@dedicated:~ systemctl

Мы увидим список всех запущенных юнитов, а так же их статус.

UNIT — имя юнита

LOAD — информирует нас о успешной загрузке конфигурации.

ACTIVE — Активный ли юнит.

SUB — более детальная системная информация о юните.

DESCRIPTION — краткое описание.

На скриншотах выше, в колонке UNIT, после префикса, указан тип юнита. Например *.service указывает, что юнит указывает на службу (nginx, apache и т.д.). Существует несколько возможных видов юнитов (socket, device, mount, swap, automount, target, snapshot, timer и другие)

На данный момент многие из них нам не пригодятся, потому рассмотрим базовый *.service, на которые стоит обратить внимание. Задача на данный момент — указать путь, а не запутать читателя

Ссылка на руководство по углубленному изучению будет предоставлена в конце статьи.

Отфильтруем только службы:

root@dedicated:~ systemctl list-units --type=service

Отфильтруем неактивные юниты:

root@dedicated:~ systemctl list-units --all --state=inactive

Существуют следующие статусы: active, inactive, running, exited, dead, loaded, not-found, plugged, mounted, waiting, listening.

Посмотреть самую полную информацию, включая юниты, которые система по какой-то причине не загрузила:

root@dedicated:~ systemctl list-units --all

Отобразить список зависимостей определенного юнита

root@dedicated:~ systemctl list-dependencies nginx.service

Используя флаги, одной только командой systemctl вы можете получить представление о системе для анализа ее работы. Так же опытный администратор может отключить необязательные службы с автозагрузки, тем самым выполнив оптимизацию загрузки сервера.

Загрузка и инициализация

Процесс загрузки вашего компьютера начинается с исполнения программного обеспечения BIOS (Basic Input / Output System — «базовая система ввода-вывода») его материнской платы. После завершения инициализации и проверок аппаратного обеспечения BIOS инициирует исполнение системного загрузчика (GRUB в дистрибутиве Fedora). Системный загрузчик осуществляет доступ к основной загрузочной записи (MBR — Master Boot Record) на вашем устройстве хранения данных, которым обычно является жесткий диск. Он использует находящиеся в ней данные для обнаружения и загрузки ядра Linux.

Процесс системы инициализации является первым процессом, который запускается в дистрибутиве Fedora после загрузки ядра. Фактически, процесс системы инициализации всегда всегда получает идентификатор процесса (PID — Process Identifier) 1 в рамках системы. Запуск этого процесса всегда осуществляется ядром Linux после завершения ранних этапов загрузки системы с участием BIOS и системного загрузчика (GRUB).

Редактирование юнитов

Напрямую юниты не редактируются. Для редактирования существует команда edit:

root@dedicated:~ systemctl edit --full nginx.service

Выше мы говорили про автоматический перезапуск служб. Давайте рассмотрим этот пример. Добавим в секции два параметра

Restart=on-failure
RestartSec=60s

Чтобы изменения вступили в силу, перезапустим конфигурацию:

root@dedicated:~ systemctl daemon-reload

Проверим, что у нас получилось. Узнаем PID процесса:

root@dedicated:~ systemctl status nginx.service | grep PID
Main PID: 12567 (nginx)

Завершим его:

root@dedicated:~ kill -9  12567

Известной уже командой проверим его статус

root@dedicated:~ systemctl status nginx.service

…ждем 60 секунд. И проверяем снова:

Изменение файлов юнитов

Если требуется изменить файл юнита, это можно сделать непосредственно командой systemctl, чтобы не искать его на диске.

Для создания сниппета файла юнита (блок, который может использоваться для дополнения или замены параметров файла юнита по умолчанию) нужно воспользоваться опцией edit:

sudo systemctl edit nginx.service

Если нужно изменить все содержимое файла, а не создавать сниппет, воспользуйтесь флагом —full:

sudo systemctl edit --full nginx.service

После изменения файла юнита нужно перезагрузить сам процесс systemd для принятия изменений:

sudo systemctl daemon-reload

Решение проблем

По-видимому, процессы с кратким сроком жизни не оставляют записей в логах

Если команда journalctl -u foounit не показывает вывода для службы с коротким сроком жизни, вместо нее обратитесь к PID. Например, если загрузка службы systemd-modules-load.service завершилась неудачно и команда systemctl status systemd-modules-load показывает, что она была запущена с PID 123, то вы сможете посмотреть вывод процесса в журнале под данным PID, то есть командой journalctl -b _PID=123. Такие поля метаданных для журнала, как _SYSTEMD_UNIT и _COMM, собираются асинхронно и зависят от директории /proc в случае с действующими процессами. Исправление этой ситуации требует внесения исправлений в ядро для обеспечения предоставления этих данных через сокет, наподобие SCM_CREDENTIALS.

Отключение журналирования аварийных дампов памяти приложений

Добавьте в файл /etc/systemd/coredump.conf такую строку:

Storage=none

и выполните:

# systemctl daemon-reload

чтобы перезагрузить конфигурацию.

Время загрузки системы увеличивается с течением времени

После использования systemd-analyze некоторое количество пользователей заметило, что их время загрузки значительно увеличилось по сравнению с тем, к чему они привыкли. После использования systemd-analyze blame NetworkManager тратил необычно большое количество времени на запуск.

Проблема некоторых пользователей была связана с тем, что /var/log/journal становился слишком большим. При этом также может уменьшаться скорость работы других команд, например, systemctl status или journalctl. Для решения проблемы можно удалить все файлы из каталога журнала (в идеале — сделав где-нибудь резервные копии, хотя бы временно) и затем установить предел размера файла журнала, как описано в разделе Ограничение размера журнала.

systemd-tmpfiles-setup.service не удается запустить при загрузке

Начиная с версии Systemd 219, /usr/lib/tmpfiles.d/systemd.conf определяет атрибуты для каталогов ACL, в /var/log/journal и, следовательно, требует чтобы поддержка ACL была включена для файловой системы, где находится журнал.

systemctl не удается включить символические ссылки в /etc/systemd/system

Если в /etc/systemd/system/foo.service symlink и systemctl enable foo.service включены, они не будут выполнены и будет показана вот такая ошибка:

Failed to issue method call: No such file or directory

# systemctl enable /absolute/path/foo.service

Просмотр логов

Компонент systemd под названием journald собирает и управляет общесистемными записями в журнале – то есть данными логов приложений и ядра.

Чтобы просмотреть все записи, начиная с самой старой записи, введите:

По умолчанию эта команда выведет записи текущей и предыдущих загрузок (если инструмент journald настроен для сохранения записей от предыдущих загрузок). Некоторые дистрибутивы включают это поведение по умолчанию, а некоторые – нет. Чтобы включить сохранение записей от предыдущих загрузок, можно:

Отредактировать файл /etc/systemd/journald.conf. Измените значение параметра Storage=, указав persistent.
Создать постоянный каталог при помощи команды:

Чтобы просмотреть только записи текущей загрузки, введите:

Записи ядра (которые, как правило, представлены как dmesg) можно просмотреть при помощи команды:

Если совместить флаги -k и –b, можно получить записи ядра только для текущей загрузки.

Структура юнита systemd

Давайте рассмотрим файл юнита Nginx, и из чего он состоит. На первый взгляд, эта информация может показаться запутанной, но она вполне логична и обязательна для понимания.

root@dedicated:~ systemctl cat nginx.service

— Обычно здесь описаны метаданные службы и её взаимодействие с другими службами.

Description — краткое описание демона

Documentation — страница man, где описана работа со службой, в данном случае Nginx

After — Дословно означает «После». Поле указывает, после каких демонов или событий данный юнит будет запущен. На нашем примере, юнит Nginx будет запущен после того, как поднимутся сетевые интерфейсы.

— Описывает конфигурацию. Применяется только для юнитов служб.

Type — Важный параметр. Описывает, каким образом демон будет запущен. В нашем варианте это forking, но вы можете столкнуться и с другими:

forking — после запуска демон ответвляется (fork), завершая родительский процесс;

simple — при запуске, демон переходит в режим ожидания, в своем первоначальном виде;

one-shot — одноразовое выполнение. Данный тип используется для скриптов, которые должны запуститься, и завершиться после выполнения.

PIDFile — указывает на основной процесс, который отслеживает systemd

ExecStartPre — основной путь и аргументы, с которыми будет запущена команда ДО запуска основного процесса

ExecStart — основной путь и аргументы, с которым будет запущен Nginx

ExecReload — указывает команду для перезапуска службы

ExecStop — команда для остановки службы

TimeoutStopSec — Указывает, что система будет ждать 5 секунд остановки службы, прежде чем остановить её принудительно

— описывает поведение юнита.

WantedBy — описывает как именно устройство будет включено. multi-user.target означает, что при запуске, в каталоге /etc/systemd/system будет создан каталог multi-user.target.wants, в котором будет создана символическая ссылка на службу. Это параметр зависимости с текущим блоком, когда вы остановите службу, эта ссылка будет удалена.

С доступным перечнем параметров вы можете ознакомится обратившись к руководству:

root@dedicated:~ man systemd.unit

Сравнение SysV и systemd

Функции	SysV	systemd
Зависимость D-Bus	Нет	Да
Управление устройствами с помощью udev	Нет	Да
Активация по таймеру	cron/at	Проприетарная
Управление квотами	Нет	Да
Автоматическая обработка зависимостей служб	Нет	Да
Завершение процессов пользователей при выходе из системы	Нет	Да
Управление пространством подкачки	Нет	Да
Интеграция SELinux	Нет	Да
Поддержка шифрованных HDD	Нет	Да
Загрузка статических модулей ядра	Нет	Да
Графический интерфейс пользователя (GUI)	Нет	Да
Перечисление всех дочерних процессов	Нет	Да
Совместимость с SysV	Да	Да
Интерактивная загрузка	Нет	Да
Переносимость на отличную от x86 архитектуру процессора	Да	Нет
Параллельный запуск служб	Нет	Да
Ограничение ресурсов для каждой службы	Нет	Да
Легко расширяемый скрипт автозагрузки	Да	Нет
Раздельные код и файл конфигурации	Да	Нет
Автоматический расчет зависимостей	Нет	Да
Подробный вывод отладочной информации	Да	Нет
Количество файлов	75 файлов	900 файлов + Glib + D-Bus

Интерфейс для systemd (опционально)

Chkservice — удобная утилита для управления юнитами systemd. В Debian 10 она доступна прямо из репозитория:

root@dedicated:~ apt install chkservice

Если в репозиториях вашего дистрибутива она отсутствует, установку можно выполнить с доступного PPA разработчиков:

root@dedicated:~ add-apt-repository ppa:linuxenko/chkservice
root@dedicated:~ apt-get update
root@dedicated:~ apt-get install chkservice

Запустить интерфейс:

root@dedicated:~ chkservice

Управление выполняется следующим образом, стрелками «вверх» и «вниз». Запустить юнит — клавиша «r», остановить — клавиша «s». Будьте осторожны, после нажатия клавиши, сигнал немедленно отправляет команду на выполнения без предупреждений.

Заключение

К этому моменту вы должны уже ознакомиться с некоторыми базовыми возможностями команды , которая позволяет взаимодействовать и контролировать экземпляр . Утилита будет главной точкой взаимодействия для управления службами и состоянием системы.

Хотя работает главным образом с основным процессом , в экосистеме есть другие компоненты, которые контролируются другими утилитами. Другие возможности, такие как управление журналами и сеансы пользователя, обрабатываются отдельными демонами и утилитами управления (/ и / соответственно). Знакомство с этими другими инструментами и демонами упростит задачу управления.