Библиотека сайта rus-linux.net
Проходим еще раз, еще один Linux Init: введение в systemd
Оригинал: Here We Go Again, Another Linux Init: Intro to systemdАвтор: Carla Schroder
Дата публикации: 13 December 2011
Перевод: Н.Ромоданов
Дата перевода: декабрь 2014 г.
Раньше у нас был демон инициализации типа System V (SysV), который управлял начальной загрузкой системы Linux, и это было хорошо. Он конфигурировался с помощью простых текстовых файлов, которые легко понять простым смертным, и это был дружественный островок стабильности среди окружающего моря изменений. Затем пришел systemd, и снова мы, пользователи Linux, были брошены на произвол судьбы в омут неизведанных вод. Зачем все эти изменения? Не может ли Linux побыть стабильным еще минуту?
Изменения
В течение очень многих лет в системе Linux для управления запуском системы хватало механизма sysvinit (инициализация System V). Исключение составляли такие дистрибутивы, как Slackware, в которых используется init в стиле BSD. SysV и BSD init достаточно схожи, так что можно было без проблем пользоваться любым вариантом.
Затем появились две новых системы инициализации Linux: Ubuntu's Upstart, впервые выпущенная в 2006 году, и systemd, появившаяся в 2009 году. Код systemd был первоначально написан Леонардом Поттерингом (Leonard Poettering). Upstart был по умолчанию была в Ubuntu начиная с версии 6.10 Edgy Eft и доступна в большинстве дистрибутивов. systemd используется как механизм инициализации по умолчанию в Fedora 15 и в более поздних версиях. Причем для тех, кто хочет опробовать этот вариант на своей любимой системе Linux, эта система инициализации присутствует в репозитариях большинства дистрибутивов.
Изменение ключевых основных подсистем пугает пользователей, поскольку это означает, что нужно осваивать новые способы администрирования наших систем и изменять наш рабочий процесс. Не вызывает восторга от таких решений также то, что из-за болезни роста страдают основные сервисы, надежность которых снижается. Так как же обстоят дела с этой новой штуковиной systemd, и какие преимущества она даст нам, простым пользователям Linux?
Более быстрый запуск
Основная задача sysvinit состоит в запуске пользовательского пространства userspace. При загрузке ядро запускает процесс PID 1; это самый первый процесс, который запускается при старте. Выполните команду pstree для того, чтобы в «художественном» стиле ASCII посмотреть схему дерева ваших процессов. Раньше считалось, что в затягивании времени загрузки на минуту или более в равной степени виноваты BIOS и sysvinit. Их скорость работы повысили, но механизм sysvinit всегда будет медленным, поскольку он запускает процессы по одному, в каждом из них выполняет проверку зависимостей, а также для того, чтобы запустить некоторые демоны, ждет запуска других демонов.
Так почему бы не запускать процессы параллельно? Есть способ сделать это без какой-либо сложности, и это - воспользоваться тем, как работают демоны в стиле Unix. Клиентам демонов Unix не нужно знать, зависят ли демоны от чего-то, что работает; все, что им нужно, это чтобы были доступными сокеты домена Unix. Что это такое сокеты? Они являются сокетами межпроцессного взаимодействия (inter-process communication sockets - IPC), и они, как процессы на локальной системе, общаются друг с другом. Вы можете увидеть это с помощью команды netstat:
$ netstat -a --protocol=unix Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 4836 /var/run/dbus/system_bus_socket unix 9 [ ] DGRAM 4584 /dev/log unix 3 [ ] STREAM CONNECTED 489456 /tmp/orbit-carla/linc- aaa-0-476044c676da9 unix 3 [ ] STREAM CONNECTED 489455 unix 3 [ ] STREAM CONNECTED 489452 /tmp/orbit-carla/ linc-8ba-0-45fe9270a46b2 [...]
Видно, что у сокетов, в соответствие с традицией "все в Unix является файлом", есть иноды (inodes). Так что вы можете с помощью стандартных файловых утилит Linux выполнять над ними различные операции, что может быть интересной темой для другой статьи.
Таким образом, все сокеты для всех демонов могут создаваться в одном шаге, а затем, на втором шаге, - все демоны. Любые запросы клиентов для тех демонов, которые еще не запущены, будут кэшироваться в буфере сокета, а затем отправляться демону после того, как он будет запущен и заработает. Если вы не знаете всех тонкостей работы ядра, вы, возможно, окажетесь под впечатлением того, как оказывается гениально и эффективно использовать что-то, что окружало нас в течение десятилетий, а не пытаться придумать что-то совершенно новое.
Горячее подключение и сервисы по требованию
В sysvinit есть статическая конфигурация и sysvinit запускает процессы по одному, по порядку. Когда мы конфигурируем sysvinit, мы всегда должны иметь в виду правильный порядок их запуска, например, помнить, что запуск сети должен происходить перед запуском сетевых сервисов. И мы должны иметь в виду, что все, что нам, возможно, потребуется, нужно запускать при запуске системы, либо нам это придется запускать вручную, поскольку sysvinit после запуска засыпает и ничего больше не делает.
Такой подход может быть достаточен для простых серверов, но не для настольных и мобильных систем. Пользователи переходят от одних сетей к другим, всевозможным образом подключают и отключают такие устройства, как клавиатуры и наушники, аудиоустройства, смотрят фильмы и слушают музыку - благодаря Bluetooth и USB у нас, наконец, есть универсальные порты для подключения устройств, и подключение устройств к работающей системе является обычным делом, а не экзотическим приключением. Помните, как, еще в прошлом, нас предупреждали, чтобы мы никогда не подключали клавиатуру PS/2, мышь или диски IDE при работающей системе из-за риска их повреждения? Даже если ничего экстраординарного не происходило, они могли идентифицироваться только при загрузке.
Автоматическое обнаружение и автоматическое монтирование съемных устройств прошли в Linux через много стадий. Помните, как в старые добрые времена, диски и флешки USB подключались и отключались вручную? И перебежчики с Windows и Mac гадали почему эти устройства вели себя странно и не работали? Да, это было странно и непонятно. Но Linux тогда еще развивался, поэтому и возникали такие ситуации.
Затем есть сетевые сервисы, к которым обращение происходит по требованию, например, общие файлы, принтеры, виртуальные приватные сети, доступ по SSH и так далее. Суть в том, в нашем современном мире большинство таких обращений происходит уже после запуска систем, так что вместо того, чтобы пытаться предвидеть все, что вам, возможно, потребуется, и поместить все это в багажник, почему бы не создать систему, которая запускает и останавливает процессы по требованию? В повседневной практике это, кажется, решение одной из моих повседневных проблем, связанной с тем, что во многих дистрибутивах при старте запускаются демоны Avahi и Bluetooth. Я не пользуюсь ни одним из них, поэтому я их всегда отключаю. Вопрос лишь в том, что надо об этом заранее знать. А т.к. я решаю конкретные задачи, я знаю какого вида работу будет выполнять компьютер.
На уровне подсистем было много попыток реализовать динамическое управление аппаратным и программным обеспечением: HAL (Hardware Abstraction Layer - слой аппаратных абстракций), autofs, devfs и все те виды динамического управления, о которых я уже забыла. Теперь для улучшенного межпроцессного обмена данными и управления, например, для управлением жизненным циклом процессов, у нас есть шина D-Bus. В D-Bus в качестве транспортного механизма используются сокеты домена Unix, и кажется, что на этом можно было бы остановиться (например, KDE и Gnome работают на D-Bus). Таким образом, можно было бы расширить дополнительные функциональные возможности, имеющиеся в D-Bus, и на systemd, который, как PID 1, функционирует как постоянный наблюдатель за процессом Linux, и обеспечить эффективность за счет распараллеливания и динамического управления ресурсами в работающей системе, а не просто запускать систему, а затем спать до следующей перезагрузки системы.
Это небольшое вступление к изучению тонкостей механизма systemd и управления процессами в Linux. Для дальнейшего изучения хорошей отправной точкой может быть домашняя страница systemd. В следующей статье будет рассказано как в ваших системах отлаживать и управлять systemd.