Переосмысление PID 1. Часть 1

http://0pointer.de/blog/projects/systemd.html
  • Перевод
Если у Вас есть хорошие связи или вы хорошо читаете между строк, вы уже могли догадаться о чем этот блог-пост. Но тем не менее Вы можете найти эту историю интересной. Так что хватайте чашку кофе, садитесь поудобнее, и читайте, что грядет.

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

Здесь код. А вот здесь история:

Идентификатор процесса 1


В каждой Unix системе есть один процесс с специальным идентификатором 1. Он запускается ядром перед всеми последующими процессами, и он является также родительским процессом для всех последующих/остальных процессов кто не смог найти себе родителя. Вследствие, он может делать много того чего не могут позволить себе другие процессы. Также он несет ответственность за некоторые вещи за которые не отвечают другие процессы, например, за поднятие и поддержку юзерспейса во время загрузки системы.

Исторически в Linux, программное обеспечение действующее как PID 1 был многоуважаемый пакет sysvinit, думается он слишком долго оставался на этом поприще. Много раз предлагались замены, но только один из них был действительно принят: Upstart, который сейчас нашел свою дорогу в многие из главных дистрибутивов.

Как было упомянуто, главная ответственность системы загрузки поднятие юзерспейса (пользовательского окружения). И хорошая система загрузки должна делать это быстро. К сожалению, традиционная система загрузки SysV в действительности была не быстрой.

Для быстрой и эффективной загрузки важны две вещи:
  • Запускать как можно меньше
  • И запускать как можно больше параллельно

Что это значит? Запускать меньше означает запуск малого количества служб или откладывание запуска до того момента, когда они действительно будут необходимы. Есть несколько служб где мы знаем, что они действительно будут запрошены рано или поздно (syslog, D-Bus, system bus и т.д.), но для многих остальных это не важно. Например, bluetoothd не нужно запускать до тех пор, пока не будет воткнут блютуз донгл или какое-нибудь приложение не захочет общаться с ним по интерфейсу D-Bus. Тоже относится и к подсистеме печати: до тех пор пока машина физически не будет подключена к принтеру, или какое-нибудь приложение захочет напечатать что-то, нет необходимости запускать демон печати, такой как CUPS. Avahi: если машина не подключена к сети, нет необходимости запускать Avahi, или до тех пор, пока какое-нибудь приложение за захочет использовать его API. И даже возьмем SSH: до тех пор, пока никто не хочет подключиться к машине, нет необходимости запускать его, иначе можно запустить его (SSH) при первой попытке подключения к машине. (И заметьте, на большинстве машине где SSH может быть запущен, большинство подключается к ним только раз в несколько месяцев или еще реже.)

Запускать как можно больше параллельно означает, что, если мы запускаем что-то, мы не должны запускать это последовательно/друг за другом (как делает это sysvinit), но запускать все одновременно, так чтобы максимально использовать CPU и IO, и следовательно, общее время загрузки системы уменьшится.

Железо и софт развиваются очень динамично


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

Большинство текущих систем, которые пытаются распараллелить загрузку, продолжают синхронизировать запуск различных демонов вовлеченных в процесс: так как Avahi нуждается в D-Bus, то D-Bus стартует первым, и только тогда, когда D-Bus подаст сигнал о том, что он готов, Avahi начнет запуск. Аналогично для других служб: libvirtd и X11 нуждаются в HAL (такс, здесь я подразумеваю службы Fedora 13, не обращайте внимания на то, что HAL уже не поддерживается), следовательно, HAL стартует первым, перед libvirtd и X11. libvirtd в свою очередь, также нуждается в Avahi, следовательно он тоже будет ждать запуска Avahi. И все эти службы в свою очередь требуют syslog, и значит они все ждут пока Syslog не будет полностью инициализрован и запущен. И так далее…

Продолжение следует…
Метки:
Поделиться публикацией
Комментарии 6
  • +3

    Зачем вы перевели статью 2010(!) года? Вы серьёзно?


    Сообщество уже успело даже перейти в фазу принятия systemd (и он уже давно успел стать init'ом по умолчанию даже в вечностабильных Debian и RHEL).


    Все копья, которые могли сломать, уже были сломаны не по разу.


    А по делу: несмотря на всеобщую ненависть к systemd и его временами странные архитектурные решения (монополизация и монолитизация всей системы), начиная с Ubuntu 16.04 и RHEL 7 управление службами наконец-то перестало быть острой болью ниже спины.

    • –3
      Я думаю, статья фундаментальня и в ней обсуждаются общие концепции, которые не устареют с течением времени
      • 0
        Коллеги, я наверное использовал очень сильный термин, как фундаментальная статья, исправлюсь. В продолжении статьи, будут объяснены и пояснены ключевые моменты systemd в разрезе с аналогичным и старым системами загрузки.
    • +3
      Блин, я по заголовку уже приготовился читать, как Systemd хоронить готовятся… Еще подумал, только ж устаканилось.

      А тут оказывается перевод статьи семилетней давности.
      • +1
        Актуальный перевод всего цикла статей «СистемД для Системных администраторов» можно найти тут.
        • 0
          EvilMan это не перевод цикла статей СистемД для администраторов. Вы ошибаетесь!

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.