Приветствую вас, Уважаемые Читатели!
Мне показалось интересным разобраться в устройстве любимой нами операционной системы немного более подробно чем открыть файловый браузер и найти там глубоко запрятанную папку с любимыми фильмами. И решил, что если уж начинать такое исследование, то наверное лучше начать с базовых понятий. Как раз таким понятием является система инициализации и управления сервисами, службами и процессами известная как SYSTEMD. Эта система на данный момент является стандартом системы управления пользовательскими процессами. И на основе это системы построено подавляющее большинство известных дистрибутивов.
Конечно подобный цикл статей следовало бы начать с изучения процесса загрузки операционной системы. Но в данном случае лично мне было интересно создать собственный юнит SYSTEMD, именно поэтому и была написана эта статья.
Теперь очень коротко и в общих чертах вспомним процесс загрузки Linux.
Мы нажимаем кнопку "Пуск" (или используем иной способ ), которая даёт команду всему устройству начать работу.
Устройство запускает процессор, который первым делом начинает выполнять прошитый в материнской плате код, который обычно называется UEFI (или ранее BIOS).
UEFI тем или иным способом ищет программу-загрузчик на диске, которую ему указана в настройках (или ранее BIOS передавал управление программам прошитым в определённых секторах диска).
Программа-загрузчик (обычно это GRUB2) находит в своих конфигурационных файлах где найти ядро ОС (в нашем случае Linux) и с какими параметрами это ядро запустить, и собственно это ядро ОС запускает.
Ядро ОС запускается, инициализирует и настраивает доступное ему оборудование, догружает необходимый программный код и данные, выполняет какие-то другие не очевидные нам действия.
И вот когда ядро полностью себя загрузило и настроило, приходит время запускать процессы, для которых собственно и был включен компьютер - т.е. пользовательские сервисы.
И именно с этого момента начинается повествование данной статьи.
Первый процесс который запускает ядро это процесс INIT. Как известно каждый процесс в системе имеет свой номер PID, и у процесса INIT этот номер PID=1.
Процесс INIT запускает все остальные пользовательские процессы, и соответственно становится их родительским процессом. Кроме того если у какого-то процесса пропадает родительский процесс, то процесс INIT становится родительским для этого процесса.
Вот вывод команды выполненный на моём рабочем ноуте в графической консоли
ps -e -o ppid,pid,command --sort=ppid
На скрине виден процесс с PID=1, запущенный командной /sbin/init, это как раз тот процесс который нам нужен.
Ещё мы можем видеть процесс с PID=2 kthreadd, этот процесс запускает служебные процессы ядра, также становясь для них родительским. Но это всё сложные системные процессы и мы их пока рассматривать не будем.
Теперь повнимательнее рассмотрим что это собственно за процесс такой INIT. И обнаружим, что он представляет собой ссылку на основной рабочий процесс systemd, который собственно и обсуждается в этой статье.
Именно этот процесс и является основным рабочим процессом SYSTEMD. Теперь посмотрим, что ещё можно найти в этой директории помимо systemd, и обнаружим множество других исполняемых файлов с говорящими названиями, которые видимо также выполняют какие-то свои задачи.
Теперь пришло время обратиться к одному из основных понятий SYSTEMD, которое является базовым для управления этой системой. Любой процесс, который управляется SYSTEMD, оформляется в системе в виде ЮНИТА. Юнит это организационная единица SYSTEMD, которая описывает необходимые свойства управляемого процесса и все его взаимодействия с другими процессами. Юнит описывается файлом описания юнита. Такие файлы располагаются в трёх основных директория, жёстко прошитых в SYSTEMD. Есть ещё много таких директорий, но мы пока сосредоточимся на этих трёх путях. Подробную инфу смотрите в man. В различных дистрибутивах возможны вариации этих путей. Пути представлены в порядке просмотра директорий системой:
/etc/systemd/system/ — юниты, созданные администратором;
/run/systemd/system/ — юниты, созданные во время работы системы;
/lib/systemd/system/ — юниты, поставляемые с пакетами.
Система использует тот файл описания юнита, который встретит первым, т.е. если файла описания юнита будет 3 штуки с разными данными, то подключен будет тот, который находится в первой директории в списке приведённом выше.
Посмотрим, что можно увидеть в папке /lib/systemd/system. Здесь мы найдём множество файлов описания юнитов, которые поставляются вместе с дистрибутивом.
Заглянем внутрь такого файлика, и увидим как описан данный юнит. Судя по названию этот юнит как-то связан с командой выключения системы.
Как можно заметить файл описания имеет вполне понятную структуру. И знание структуры и синтаксиса таких файлов позволяет пользователю самостоятельно создавать свои собственные сервисы, управляемые из-под SYSTEMD, для своих целей.
Встроенная справочная система man (man systemd) содержит вполне подробную информацию о типах юнитов, синтаксисе файлов описания юнитов и пр. Там правда всё на английском и не очень структурировано. Но если кому-то покажется интересным пишите комментарии - попробую извлечь необходимую информацию из справочной системы.
Теперь попробуем самостоятельно написать свой собственный сервис для SYSTEMD. Существует несколько типов юнитов, мы используем простейший и основной: "service".
Для начала напишем такой файлик юнита.
И небольшой скриптик, который запущенный с параметром start пишет вывод команды date в файлик вывода каждую секунду. Дописывать текущее время скрипт будет до тех пор, пока не появится триггерный файл. В свою очередь триггерный файл создаётся тем же скриптом, запущенным с параметром stop. Такая структура удобна для того, чтобы можно было задать общие имена файла вывода и триггерного файла.
Эти все файлы созданы в домашней директории.
Теперь скопируем файл описания юнита в директорию /etc/systemd/system/ , выставим этому файлику разрешения на запуск всеми, потом проверим, что там всё правильно написано (это всё мы делаем через команду sudo). И убедившись что всё правильно, попробуем установить юнит в систему командой systemctl enable s71.service, при этом при выполнении команды потребуется аутентификация. Если всё в порядке, то система создаст необходимые ссылки.
И если всё в порядке можно запустить наш сервис, проверить его статус, и заодно проверить его работу.
И опять если всё в порядке остановим наш сервис стандартной командой, и опять проверим его статус.
На скрине выше показан удачный вариант установки сервиса. Статус сервиса активный и рабочий, в файл вывода стабильно пишутся записи, что видно по команде tail -f. Сразу признаюсь, что это был конечный результат попыток установки и запуска сервиса. И далеко не все из этих попыток были удачными. Основная задача заключалась в методичном и правильном написании файла описания юнита.
Т.е. получается, что мы создали свой собственный сервис, и можем управлять им стандартными командами SYSTEMD. Это хороший результат.
Относительно SYSTEMD есть ещё пара интересных моментов.
Во-первых система помимо управления пользовательскими процессами ведёт системный лог. Для этого существует специальный фоновый процесс, в составе системы SYSTEMD. Но надо заметить это не единственный источник логов в операционной системе, хотя пожалуй самый удобный для использования. Просматривать такие логи можно командой journalctl (ключ -e прокручивает лог на самую свежую запись). Управление таким логированием сложная и большая тема, которая заслуживает отдельной статьи.
Во-вторых система организует управляемые ею процессы в древовидную структуру, которую отображает в виртуальной файловой системе в моём случае по пути /sys/fs/cgroup
Управление процессами с помощью cgroup, также отдельная и сложная тема, которая заслуживает отдельной статьи.
На этом думаю возможным закончить такой достаточно общий обзор SYSTEMD. И на этом считаю возможным закончить данную статью.
Если кого-то из Уважаемых Читателей заинтересует развитие тем, затронутых в статье, то большая просьба написать в комментариях.
Благодарю всех Уважаемых Читателей, дочитавших до этого места.
Желаю всем удачи в начинаниях и продолжениях, до новых встреч!!!)
PS
Статья не является учебным пособием, и представляет личный опыт автора.
Статья может содержать ошибки и не точности.
Приведённые данные необходимо проверять самостоятельно.
Текст написан автором лично при информационной поддержке ГигаЧат.
Картинка для превью статьи сгенерирована сетью Шедеврум, возможно с небольшими правками автора.
Канал MAX для всего того, что не поместилось на канал ДЗЕН.