Вход:  Пароль:  
FreeSource: ТЗ/initscripts ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

Сценарии запуска системы


Известно, что Linux-системы, использующие сценарии запуска SysV, запускаются достаточно долго. Это связано в первую очередь с тем, что сценарии запуска системы выполняются последовательно. Играют роль задержки при обращении к оборудованию. Также сильно замедляет загрузку обращение к многочисленным конфигурационным файлам. Это легко увидеть, посмотрев как «взлетает» система с флэш-диска. Существует несколько альтернативных реализаций сценариев запуска.


Теоретически может быть определено несколько направлений оптимизации:

Обзор вариантов


Проведя некоторое время в размышлениях по поводу запукса GNU/Linux систем в целом и ALT Linux в частности, спешу поделиться своим опытом.
Для начала замечу, что мое рассмотрение коснется только трех вариантов организации загрузки системы. Это


Для начала пробегусь в общих чертах на тему инициализации системы вообще.


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


Далее загрузщик так или иначе загружает в память ядро Linux и, обычно передает ему образ initrd (если не ошибають от Initial RAM Disk — начальный рамдиск). Это уже интереснее. Этот самый образ initrd является архивом, который содержит структуру файлов и каталогов, очень похожую на обычный корень файловой системы используемой традиционно в GNU/Linux. Только всего там по минимому. Ну это и понятно, поскольку этот образ разворачивается в память и там и работает.


Фактически, это первая мини-система запускаемая при старте компьютера. При этом Linux вполне может стартануть и без нее, но сейчас так делают разве что встраиваемые системы или системы собранные самостоятельно, да и то редко. Зачем же нужна такая мини-система? Вообще смысл ее очень прост: она должна примонтировать корень большой, настоящей системы и затем передать управление программе на нем. При этом иногда приходиться проделать совсем нетривиальные вещи, вроде автодетектирования оборудования и подгрузки необходимых для его работы модулей, подгрузки модулей файловой системы и т. п. вещи. Кроме того корень файловой системы может располагаться на другом компьютере и быть доступным по сети. Тогда initrd система получает сетевые настройки по протоколу dhcp и действует в соответствии с ними. Что бы там ни происходило, но итогом всех действий является смонтированый только для чтения (ну так обычно) корень файловой системы и запуск процесса /sbin/init уже с этого корня.


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



Каким образом это происходит сейчас в ALT Linux? Первый процесс в системе — это реализация SysVinit. Его файл настроек хранится в /etc/inittab и, если его рассмотреть, то видно, что сначала запускается файл /etc/rc.d/rc.sysinit, и ожидается его завершение, затем запускается файл /etc/rc.d/rc с параметром текущего уровня запуска (runlevel, понятие из SysVinit), завершения которого снова ожидают, а затем запускается некоторое количество процессов mingetty, которые инициализируют традиционные в Linux эмуляторы терминалов и выводят приглашения на вход пользователя.


Таким образом видно, что все интересное происходит в rc.sysinit и rc.


Так вот большую часть работы по базовой инициализации системы выполняет rc.sysinit. Это большой bash-скрипт, который устанавливает системный шрифт, проверяет файловые системы, монтирует их, запускает udev, и делает еще целую кучу всего интересного или нет (кому как :) ) и делает это, надо сказать весьма долго (у меня больше 20 секунд). Второй скрипт попроще, поскольку он просто идет в соответствующую папку (/etc/rc.d/rc<runlevel>.d) и запускает там все файлы (они все симлинки на файлы из /etc/init.d, но в принципе это по-барабану), начинающиеся с “K” с параметром stop, а затем все файлы, начинающиеся с “S” с параметром start. Соответственно все действия выполняют скрипты из /etc/init.d. Такой порядок заведен, для того, чтобы можно было менять состав и порядок выполнения скриптов из /etc/init.d для некоторого тюнинга процесса загрузки системы.


Теперь посмотрим, что же предлагают нам остальные системы инициализации.

InitNG


Начнем с initng. Эта система написана для того, чтобы решить некоторые недостатки SysVinit, о которых я напишу ниже. После запуска в качестве первого процесса initng смотрит на свои настройки в /etc/initng/. В этой папке хранятся иерархически организованные файлы конфигурации ifiles, в которых и описаны различные действия по инициализации системы (сервисы), а так же дополнительная информация.


У каждого сервиса описанного в соответствующем ifile имеются зависимости. Это другие сервисы без отработки которых сервис не может работать корректно (например, web-сервис apache не может работать до того как сеть будет инициализирована). Есть возможность задавать и «мягкие зависимости», это когда сервис может быть запущен без запуска некоторого, но если уж пользователь попросил запустить его, то он должен будет запуститься раньше (например, тот же apache может работать без mysql, но если мы запускаем и mysql, и apache, то лучше mysql перед apache). Так же сервисы могут предоставлять виртуальные сервисы, например и postfix, и qmail, и exim могут предоставлять сервис mta, тогда другие сервисы могут ставить себе в зависимость mta, не заботять о том, какой mta сейчас работает в действительности.


Так вот, обычно initng смотрит в файл runlevels/default.runlevel и смотрит, что же ему надо запустить. И просто запускает все указанные сервисы. При этом каждый сервис запускается строго после того, как будет запущены все его зависимости и при этом как можно раньше. Это то, что называется параллельным запуском скриптов инициализации и зачастую существенно уменьшает время загрузки.

Upstart


Следующая система — это upstart.


Это весьма экстравагантная система, которая сейчас усиленно развивается. Она является так называемой «системой, основанной на событиях» («events base system»). Неудивительно, что там есть понятие события. Событие в upstart описывается строкой. И ее скрипты могут активироваться по тем или иным событиям. Как предполагается использовать систему?



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

Некоторые выводы и соображения


Теперь я позволю себе сделать некоторые выводы и поделюсь своими соображениями.


Ну критики SysVinit предостаточно в интернет. В основном все сводиться к тому, что получаемая в результате система грузиться очень долго из-за того, что в единый момент времени запускается только один сервис, а он может долго ожидать реакции оборудования. Далее, очень тяжело управлять последовательностью запуска скриптов. Ведь разрабатывая скрипт запуска какого-либо демона мы совершенно не знаем, какими по счету будут запускаться остальные и каким надо запустить наш. Гораздо проще указать зависимости и забыть о последовательности запуска.


Про upstart могу сказать следующее. Вообще, в принципе я могу представить аккуратно написанные сильно ветвящиеся и параллельно запускаемые сервисы, но текущее положение дел в ubuntu ограничилось эмуляцией SysVinit. Да и зависимости эмулировать в такой системе очень сложно. Я, например, с трудом представляю, как в такой системе сделать человеческое управление зависимостями. Еще сложнее сделать управление зависимостями и придумать способ гибко настраивать, что будет запускаться, а что нет. Сложности проистекают, в основном тогда, когда сервис зависит от нескоьких других.

Предложения


Так или иначе, в случае необходимости модернизировать загрузку системы, придется начать с разбиения скрипта rc.sysinit на несколько поменьше. С возможностью запускать чатсть из них параллельно. Это первый этап в мигрировании.


Далее в случае миграции на init-ng я сумел найти такое вот простое решение организации совместимости старых скриптов и новой системы инициализации. Кроме того, init-ng позволяет писать плагины, в частности можно будет написать плагин, который будет парсить файлы, написанные с комментариями согласно LSB стандарта.

Существующие реализации



Страницы, ссылающиеся на данную: DmitrijMaslennikov


 
Файлов нет. [Показать файлы/форму]
Один комментарий. [Показать комментарии/форму]