Настройка и мониторинг запуска Linux-системы

Сравнение различных механизмов запуска Linux-систем

Уильям фон Хаген
Опубликовано 27.10.2014

Обзор процесса запуска Linux-системы

Процесс запуска Linux-системы — от включения питания до состояния полной работоспособности — можно разделить на две концептуально различные фазы:

1. Начальная загрузка с какого-либо устройства; загрузка и инициализация ядра Linux
2. Запуск приложений пространства пользователя (включая серверные процессы), монтирование дополнительных файловых систем, выполнение дополнительного конфигурирования и настройки ядра, предоставление доступа к дополнительным устройствам

Основные шаги первой фазы были описаны в ранее опубликованной на developerWorks статье Подробности процесса загрузки Linux (см. раздел Ресурсы). Эти шаги не сильно изменились за прошедшие годы, за исключением использования загрузчика GRUB 2 (GRand Unified Bootloader 2), различий в формате и в использовании начального RAM-диска, а также изменений в первом процессе, запускаемом в пространстве пользователя (традиционно это процесс init). На первой фазе повышение производительности происходит главным образом благодаря совершенствованию аппаратных средств (более быстрые загрузочные устройства, более быстрые механизмы доступа к устройствам, более быстрые и более мощные процессоры). Однако на второй фазе повышение производительности почти полностью определяется сферой программного обеспечения, и здесь применяется несколько разных подходов.

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

• Минимизация: запуск лишь наименьшего набора необходимых сервисов.
• Линейность: понимание потребностей каждого конкретного сервиса в других сервисах (т. н. анализ зависимостей) и учет этих потребностей в процессе запуска.
• Параллелизм: максимальное расширение возможностей для одновременного запуска независимых сервисов (или цепочек связанных сервисов).

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

Понимание и использование SysVinit

Традиционный механизм запуска и выключения системы, используемый в Linux-системах, носит название SysVinit. Как можно предположить по названию SysVinit, его концептуальные истоки лежат в версии UNIX® под названием Sys V (точнее, UNIX System V, Release 4 – SVR4), которая была выпущена в 1989 году. Инициализационная программа SysVinit читает файл /etc/inittab с целью идентификации набора сервисов, которые должны быть доступными в тот момент, когда система достигает своего состояния по умолчанию (уровень runlevel по умолчанию для системы) и команды, которую она должна выполнить для достижения этого состояния. В системах, использующих SysVinit, эта информация задается с помощью записей в файле /etc/inittab(см. листинг 1).

Листинг 1. Традиционные команды в файле /etc/inittab, связанные с запуском

si::sysinit:/etc/init.d/rcS
id:5:initdefault:
l5:5:wait:/etc/init.d/rc 5

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

При использовании механизма SysVinit каталог /etc/init.d содержит скрипты оболочки, которые запускают и останавливают все процессы системного уровня. Для каждого runlevel имеется собственный каталог, содержащий символьные ссылки на определенные скрипты оболочки в каталоге /etc/init.d, которые следует запускать или останавливать при входе в соответствующий уровень runlevel или выходе из него. Третья строка в листинге 1 дает механизму SysVinit указание выполнять скрипты из этого каталога, ассоциированные с runlevel 5. Обычно это скрипты /etc/rc5.d, /etc/init.d/rc5.d или /etc/rc.d/rc5.d — в зависимости от применяемого дистрибутива Linux.

Символьные ссылки в каталоге уровня runlevel начинаются с S или с K. S указывает, что данный скрипт должен исполняться с целью запуска ассоциированного с ним системного процесса при входе системы в указанный уровень runlevel; K указывает, что данный скрипт должен исполняться с целью завершения ассоциированного с ним системного процесса при выходе системы из этого уровня runlevel. Целочисленное значение, следующее за S или за K, определяет порядок, в котором эти скрипты следует исполнять при входе в соответствующий уровень runlevel или при выходе из него.

Если в каталог /etc/init.d добавляются новые скрипты, то специальным образом отформатированные комментарии в начале каждого скрипта идентифицируют все другие скрипты, от которых зависит данный скрипт, а также идентифицируют каждый уровень runlevel, с которым должен быть ассоциирован данный скрипт. Команды и другие сведения, которые должны присутствовать в этих скриптах, определяются спецификацией LSB (Linux Standard Base), которая представляет собой стандарт, разработанный несколькими создателями дистрибутивов Linux для гарантирования совместимости скриптов SysVinit в разных дистрибутивах Linux. В листинге 2, взятом из обсуждения LSB-комментариев в init скриптах, показан пример такого раздела.

Листинг 2. Раздел комментариев в традиционном скрипте SysVinit

### BEGIN INIT INFO
# Provides: lsb-ourdb
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop OurDB
# Description: OurDB is a very fast and reliable database
# engine used for illustrating init scripts
### END INIT INFO

В таблице 1 показана информация, которую представляет каждая из этих записей.

Таблица 1. Комментарии в секции INIT INFO скрипта SysVinit

Для запуска, остановки и перечисления скриптов SysVinit можно воспользоваться командой /sbin/service. Для перечисления или изменения уровней runlevel, с которыми ассоциированы эти скрипты, можно воспользоваться командой/sbin/chkconfig.

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

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

Более детальное описание механизма SysVinit в целом содержится в статье Boot Linux Faster (Ускорение загрузки Linux) на сайте developerWorks (см. раздел Ресурсы).

Понимание и использование механизмов запуска, управляемых событиями

Механизм SysVinit удобен в работе и легко настраивается благодаря использованию скриптов оболочки для запуска и остановки системных сервисов. Однако использование таких последовательных скриптов оболочки замедляет механизм SysVinit и не обеспечивает возможностей для параллельного запуска несвязанных сервисов. Другая проблема состоит в том, что скрипты, которые запускают и останавливают сервисы, выполняются только при запуске или выключении системы — другими словами, единственное событие, на которое они реагируют — это изменение уровней runlevel системы. За немногими исключениями (например, сервисы, запускаемые другими сервисами), это означает, что все сервисы, которые могут требоваться в системе, должны постоянно исполняться и ждать запросов, которые могут никогда не поступить.

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

Здесь на сцену выходят управляемые событиями механизмы запуска, которые срабатывают точно в определенный момент, выполняя заданные команды и запуская ассоциированные сервисы при наступлении соответствующих событий в системе. Демоны inetd и xinetd для различных сетевых сервисов представляют собой хорошую аналогию для управляемых событиями механизмов запуска, поскольку они просто ждут наступления определенных событий (запросы на сетевые соединения для управляемых этими демонами сервисов), а затем запускают соответствующий сервис по мере необходимости. Управляемые событиями механизмы запуска обеспечивают максимальную степень параллелизма во время запуска системы, позволяя нескольким командам исполняться одновременно в ответ на событие, и распространяют эту динамическую способность к реагированию на среду исполнения системы. Событие — это по существу строковое сообщение, которое процесс способен отослать в ответ на изменение в состоянии какого-либо "субъекта", мониторинг которого осуществляет этот процесс. Процесс отсылает сообщение о событии однократно.

Самым известным из управляемых событиями механизмов запуска является Upstart — это механизм запуска по умолчанию, используемый в таких дистрибутивах Linux, как Ubuntu 9.10 и выше, RHEL6 (связанные дистрибутивы: (CentOS, Oracle Linux, Scientific Linux), Fedora 9-14, а также во многих других дистрибутивах Linux. Upstart обладает обратной совместимостью с runlevel-моделью SysVinit.

Механизм Upstart использует т.н. файлы конфигурации заданий (conf-файлы), которые описывают его реакцию на различные события — запуск, выключение, переходы между уровнями runlevel и т. д. Обычно эти файлы находятся в каталоге /etc/init, хотя по причинам обратной совместимости некоторые из них находятся в каталоге /etc/event.d. Все создаваемые вами новые conf-файлы в масштабе всей системы должны размещаться в каталоге /etc/init. Как правило, conf-файлы имеют расширение conf. Это текстовые файлы, которые должны содержать как минимум следующую информацию.

• События (одно или несколько), в ответ на наступление которых этот conf-файл должен выполнить определенное действие. Например, запись start on startup говорит о том, что файл задания должен быть выполнен при получении информации о событии startup, а запись stop on runlevel говорит о том, что файл задания должен остановиться при получении какой-либо информации о событии runlevel, например, об изменении уровня runlevel системы.

• Раздел task или respawn, который содержит как минимум запись exec или раздел script с указанием команд, исполняемых в ответ на события, которыми инициируется этот conf-файл. Запись exec исполняет определенную команду, обычно двоичный файл, с определенным набором аргументов командной строки. Раздел script, известный как stanza-запись, содержит команды, исполняемые оболочкой, включая любые скрипты оболочки; она должны заканчиваться утверждением end script Механизм Upstart посредством ключевых слов task и respawn управляет двумя концептуальными классами заданий.

  • Задачи должны завершаться, т.е. должны переходить из остановленного состояния в запущенное, а затем, после завершения, должны возвращаться к остановленному состоянию.
  • Сервисы должны исполняться постоянно, поэтому они просто переходят из остановленного состояния в запущенное. Секция respawn указывает, как запускать и как перезапускать сервис.

В разделе task conf-файла Upstart также можно использовать другие ключевые слова для идентификации устройств вывода, скриптов для исполнения перед основным разделом exec или script, скриптов для исполнения после завершения основных разделов exec или script и т. д. Раздел pre-start script содержит команды, которые используются для инициализации среды, требуемой для команд script или exec, а раздел post-stop script содержит команды, которые используются для очистки или постобработки после завершения команды exec или stanza-записи script. В conf-файлах могут быть использованы и многие другие команды Upstart (см. раздел Ресурсы).

Например, в листинге 3 показан conf-файл Upstart с именем /etc/init/rcS.conf, эмулирующий механизм SysVinit. Для упрощения чтения этого файла я удалил из него комментарии.

Листинг 3. Conf-файл /etc/init/rcS.conf механизма Upstart.

start on runlevel [0123456]

stop on runlevel [!$RUNLEVEL]

task

export RUNLEVEL
console output
exec /etc/rc.d/rc $RUNLEVEL

Этот conf-файл определяет задачу, которая исполняет любые имеющиеся скрипты SysVinit из каталога, ассоциированным с текущим уровнем runlevel.

Задания Upstart можно запускать, останавливать и перечислять с помощью команды /sbin/initctl. Эта команда показывает задания механизма Upstart, которые исполняются в данный момент, а также их текущее состояние. Для добавления нового задания к последовательности инициализации системы достаточно просто создать соответствующий conf-файл для этого сервиса и поместить этот файл в каталог /etc/init. Upstart версии 1.3 и выше также поддерживает conf-файлы, привязанные к конкретному пользователю. Эти файлы размещаются в подкаталоге init личного каталога пользователя, однако эта опция используется нечасто.

Понимание и использование systemd

Точно так же, как механизм Upstart, казалось, был призван вытеснить механизм SysVinit из всех Linux-систем, со временем появился другой, еще более эффектный, более впечатляющий и более эффективный механизм запуска: systemd (system daemon), первым автором которого является Леонард Путтеринг (Leonard Poettering). Механизм запуска системы systemd значительно улучшает запуск параллелизированной системы благодаря пониманию обеспечивающих ресурсов, необходимых для различных сервисов. Кроме того, systemd облегчает отслеживание ресурсов для связанных процессов и управление ими за счет использования механизма cgroups (control groups), который поддерживается в ядре Linux начиная с поздних выпусков версии 2.6.

Большинство современных Linux-сервисов и ассоциированных с ними клиентов используют для взаимодействия между процессами сокеты UNIX, включая шину обмена сообщениями D-Bus, предназначенную для сообщений общего характера, связанных с аппаратными средствами, и для локальных сообщений между приложениями. Если необходимые сокеты существуют (или шина D-Bus была активирована), могут быть запущены любые использующие их сервисы, поэтому механизм systemd сначала создает все сокеты, ассоциированные с сервисами, которые вы хотите запустить на данной системе. Сервисы, которые используют эти ресурсы, обычно блокируются до тех пор, пока у них не возникает необходимость доставить или получить сообщение, поэтому они могут быть запущены либо параллельно, либо по требованию в соответствии с входящими запросами.

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

Механизм запуска systemd управляет т. н. элементами (unit). Чтобы удовлетворить различные типы потребностей в отношении инициализации и запуска, механизм systemd поддерживает различные типы элементов. Пояснения к наиболее распространенным из этих элементов приведены в таблице 2.

Таблица 2. Распространенные типы элементов для systemd

Конфигурационные файлы сервиса, ассоциированные с типами элементов, которые поддерживает механизм systemd, обычно находятся в подкаталогах /etc/systemd. В листинге 4 показан пример конфигурационного файла сервиса systemd.

Листинг 4. Пример конфигурационного файла сервиса systemd

[Unit]
Description=System Logging Service

[Service]
EnvironmentFile=-/etc/sysconfig/rsyslog
ExecStart=/sbin/rsyslogd -n $SYSLOGD_OPTIONS
Sockets=syslog.socket
StandardOutput=null

[Install]
WantedBy=multi-user.target
Alias=syslog.service

Этот файл представляет собой определение элемента для журнала syslog из rsyslog.service системы Fedora 17; он находится в каталоге /etc/systemd/system/multi-user.target.wants. Различные секции этого файла содержат описание элемента, с которым он ассоциирован, указывают, как запустить сервис и какие ресурсы он использует, а также указывают обстоятельства, при которых осуществляется вызов этого элемента — в данном случае вызов осуществляется, когда цель запуска системы имеет вид multi-user.target.

Механизм запуска systemd использует команду systemctl для запуска, остановки и проверки состояния элементов различных типов из командной строки. Команда systemadm предоставляет графический интерфейс, который предоставляет аналогичные возможности, однако он не устанавливается по умолчанию. Чтобы добавить его, необходимо установить пакет systemd-gtk.

Механизм запуска systemd может дать существенное повышение производительности, но может оказаться и более сложным в применении, если вам необходимо добавить команды в определенной, детерминированной точке последовательности запуска. Механизм systemd вполне заслуживает того, чтобы протестировать его на предмет возможного повышения производительности запуска в конкретной системе. Тем не менее далеко не все специалисты являются его поклонниками, поскольку systemd существенно отличается от предыдущих механизмов запуска Linux. В разделе Ресурсы приведена ссылка на альтернативное мнение относительно механизма systemd. Новые подходы интересны как таковые, однако они могут быстро терять блеск.

Мониторинг запуска системы и исполнения скрипта

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

• Какие команды или скрипты инициализации исполнялись в процессе запуска системы?
• В каком порядке исполнялись эти команды или скрипты?
• Сколько времени требуется каждой команде или каждому скрипту?

Если вы всего лишь добавляете один скрипт к процессу запуска системы, то на первом этапе вас интересует, исполняется ли этот скрипт на самом деле и если исполняется, то в какой точке. Простой способ получить эту информацию — вызвать команду /usr/bin/logger из вашего скрипта. Команда logger записывает сообщение в системный журнал с заданным приоритетом. Например, следующая команда записывает сообщение New script executed с числовым приоритетом, соответствующим сообщению типа alert, которое всегда необходимо журналировать.

/usr/bin/logger -p 1 "New script executed"

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

Первоначально утилита Bootchart была написана как скрипт оболочки, однако ее последняя версия, Bootchart 2, была переписана на языке C, чтобы повысить производительность и уменьшить воздействие самой утилиты на собираемые ею данные. Чтобы использовать последнюю версию Bootchart 2, загрузите исходный код для текущей версии, выполните сборку и установку приложения, а затем интегрируйте его в команды начального загрузчика (bootloader), который вы используете для загрузки своей системы. Для сборки и установки Bootchart 2 на вашей системе должны быть установлены следующие компоненты: система контроля исходного кода git, инструмент make для компиляции приложения и C-компилятор gcc. После этого вы сможете выполнять следующие действия.

1. Использовать команду git с целью клонирования репозитария исходного кода для Bootchart 2.

   git clone https://github.com/mmeeks/bootchart

2. Изменить каталог на каталог bootchart, который был создан на предыдущем шаге, и выполнить команду make для компиляции различных фрагментов Bootchart 2.
3. От имени пользователя root или с помощью команды sudo выполнить команду make install для установки различных приложений Bootchart 2 и их документации в местоположениях по умолчанию.

4. Добавить следующий фрагмент в конец записи для ядра в конфигурационном файле используемого вами начального загрузчика.

   initcall_debug printk.time=y quiet init=/sbin/bootchartd

   Если вы используете начальный загрузчик GRUB, то, вероятно, вы добавите предыдущий текстовый фрагмент к stanza-записи начальной загрузки в файле /boot/grub/menu.lst. Если вы используете GRUB2, то, вероятно, вы добавите предыдущий текстовый фрагмент к stanza-записи начальной загрузки в файле /boot/grub/grub.conf. Если конфигурационный файл GRUB в вашей системе был сгенерирован автоматически с помощью команд, подобных grub-mkconfig или grub2-mkconfig, вам следует добавить предыдущий текстовый фрагмент к опциям по умолчанию для начальной загрузки ядра, которые определены в файле /etc/default/grub, а затем заново сгенерировать конфигурационный файл своего фактического загрузчика.

При следующей перезагрузке вашей системы утилита Bootchart 2 соберет данные о каждой стадии процесса начальной загрузки и сгенерирует графическую сводку этих данных в формате PNG. Сводные данные сохраняются в файле /var/log/bootchart.tgz, а соответствующее им графическое представление сохраняется в файле /var/log/bootchart.png. На рис. 1 показан фрагмент графического изображения процесса начальной загрузки.

Рисунок 1. Фрагмент графического представления начальной загрузки, полученный с помощью утилиты Bootchart

Кликните, чтобы увидеть увеличенное изображение

Верхняя часть полученного с помощью Bootchart 2 графического представления процессов начальной загрузки представляет собой сводную информацию об исследуемой системе, включая общую продолжительность процесса запуска. Средняя часть — это графическое представление всех процессов запуска (рис. 1 является фрагментом этого представления). Два раздела в нижней части демонстрируют совокупное потребление процессами процессорных ресурсов и ресурсов ввода/вывода .

При каждой перезагрузке системы все предыдущие файлы с указанными именами перезаписываются. Если вы экспериментируете со способами изменения порядка исполнения различных скриптов в процессе запуска системы и/или пытаетесь оптимизировать содержимое этих скриптов, полезно будет сохранить сводные данные утилиты Bootchart 2 для нескольких начальных загрузок системы для упрощения сравнения результатов.

В конфигурационном файле Bootchart 2 (/etc/bootchartd.conf) имеется переменная CUSTOM_POST_CMD. Эта переменная позволяет указать полный маршрут к скрипту или к другому приложению, исполняемым после того, как утилита Bootchart 2 создаст свои данные и ассоциированные с ними графические файлы. Код в листинге 5 представляет собой пример скрипта, который можно использовать для переименования выходных файлов с присвоением им имен вида YYYY-MM-DD-HH-MM-HOSTNAME и сохранением этих файлов в каталоге /var/log/bootchart.

Листинг 5. Пример скрипта для присвоения новых уникальных имен выходным файлам Bootchart

#!/bin/bash

source /etc/bootchartd.conf

HOST=$(hostname -s)

if [ ! -d $(dirname $BOOTLOG_DEST)"/bootchart" ] ; then
    mkdir $(dirname $BOOTLOG_DEST)"/bootchart"
fi

DATE=$(date +%Y-%m-%d-%H-%M)

filebase="$DATE-$HOST"

mv $BOOTLOG_DEST $(dirname $BOOTLOG_DEST)"/bootchart/"${filebase}".tgz"

if [ "x$AUTO_RENDER" = "xyes" ] ; then
    mv ${AUTO_RENDER_DIR}/bootchart.${AUTO_RENDER_FORMAT} \
       $(dirname $BOOTLOG_DEST)"/bootchart/"${filebase}"."${AUTO_RENDER_FORMAT}
fi

Утилита Bootchart 2 работает со всеми механизмами запуска Linux-систем, описанными в этой статье, и предоставляет весьма полезную информацию о том, сколько времени, процессорных ресурсов и ресурсов ввода/вывода потребляется на каждом шаге последовательности запуска системы. Это помогает выявить в последовательности запуска фрагменты, которые имеет смысл оптимизировать для сокращения времени запуска системы.

Заключение

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

Ресурсы для скачивания

• этот контент в PDF

Похожие темы

• Оригинал статьи: Customizing and monitoring Linux system startup.
• Подробности процесса загрузки Linux, developerWorks, май 2006 г. Прекрасное введение в основные стадии загрузки Linux-системы.
• Boot Linux faster (Ускорение загрузки Linux), developerWorks, сентябрь 2003 г. Отличный обзор процесса запуска системы SysVinit, содержащий несколько хороших предложений по анализу и повышению производительности Linux-систем, использующих этот механизм запуска.
• LSB— это стандарт, разработанный несколькими создателями дистрибутивов Linux для гарантирования совместимости скриптов SysVinit в разных дистрибутивах Linux.
• Init Script Actions (Действия скрипта Init Script) — в этом документе описываются стандартные команды, которые должны быть доступны в скриптах SysVinit, совместимых со стандартом LSB версии 4.1 (действующая версия на момент написания этой статьи).
• Comment Conventions for Init Scripts (Соглашения по комментированию инициализационных скриптов) — в этом документе описываются комментарии, которые должны присутствовать в скриптах SysVinit, совместимых со стандартом LSB версии 4.1, с целью обозначения зависимостей и уровней runlevel, с которым должен быть ассоциирован совместимый скрипт инициализации.
• Parallelize applications for faster Linux booting (Параллелизация приложений с целью ускорения начальной загрузки Linux), developerWorks, март 2007 г. В этой статье рассматриваются механизмы запуска (initng и upstart), а также использование первоначальной версии Upstart для мониторинга и визуализации процесса запуска Linux.
• Upstart Intro, Cookbook and Best Practises— официальная документация Ubuntu по применению Upstart, в т. ч. по созданию conf-файлов Upstart.
• Rethinking Pid 1, апрель, 2010 г. Прекрасное введение в цели и реализацию механизма systemd, написанное его первоначальным разработчиком (Леннартом Путтерингом).
• Why systemd?, апрель, 2010 г. В этом документе сравниваются возможности SysVinit, Upstart и systemd. Читатели должны иметь в виду, что этот документ был написан первоначальным разработчиком systemd (Леннартом Путтерингом); соответственно, выбранные им для сравнения характеристики в более выгодном свете представляют возможности systemd.
• systemd for Administrators, Part 1, август 2010 г. Первая часть цикла учебных пособий по systemd для системных администраторов (автор — Леннартом Путтерингом).
• The systemd Fallacy— альтернативный — и весьма эмоциональный — взгляд на systemd.
• Bootchart 2 Project Summary— раздел на ресурсе Ohloh со сводной информацией по целям последней версии Bootchart и реализованным в ней изменениям.
• Свежую версию Bootchart 2 можно загрузить со страницы этого проекта в репозитарии GitHub.