Для чего нужна служба init linux

Обновлено: 04.07.2024

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

Во-первых, загрузчик размещает в памяти образ ядра, который вы указали в файле его конфигурации. После этого ядро запускается. Когда ядро загружено и запущено, оно инициализирует относящиеся к ядру структуры и задания, и запускает процесс init .

Этот процесс удостоверяется, что все файловые системы (определенные в /etc/fstab ) смонтированы и готовы к использованию. Затем он выполняет несколько сценариев, находящихся в каталоге /etc/init.d , которые запускают службы, необходимые для нормального запуска системы.

И, наконец, когда все сценарии выполнены, init подключает терминалы (чаще всего просто виртуальные консоли, которые видны при нажатии ALT+F1 , ALT+F2 и т.д.), прикрепляя к каждой консоли специальный процесс под названием agetty . Этот процесс впоследствии обеспечивает возможность входа в систему с помощью login .

Сценарии инициализации¶

Сейчас процесс init запускает сценарии из каталога /etc/init.d не в случайном порядке. Более того, запускаются не все сценарии из /etc/init.d , а только те, которые предписано исполнять. Решение о запуске сценария принимается в результате просмотра каталога /etc/runlevels .

Во-первых, init запускает все сценарии из /etc/init.d , на которые есть символьные ссылки из /etc/runlevels/boot. Обычно сценарии запускаются в алфавитном порядке, но в некоторых сценариях имеется информация о зависимостях от других сценариев, указывающая системе на необходимость их предварительного запуска.

Когда все сценарии, указанные в /etc/runlevels/boot , будут выполнены, init переходит к запуску сценариев, на которые есть символьные ссылки из /etc/runlevels/default . И снова запуск происходит в алфавитном порядке, пока в сценарии не встретится информация о зависимостях; тогда порядок изменяется для обеспечения правильного порядка запуска.

Как работает init¶

Конечно, init не принимает решений сам по себе. Ему необходим конфигурационный файл, где описаны необходимые действия. Этот файл — /etc/inittab .

Если вы запомнили последовательность загрузки, описанную чуть ранее, вы вспомните, что первое действие init — это монтирование всех файловых систем. Это определяется в строке /etc/inittab , приведенной ниже:

Этой строкой процессу init предписывается выполнить /sbin/rc sysinit для инициализации системы. Самой инициализацией занимается сценарий /sbin/rc , так что можно сказать, что init делает не слишком много — он просто делегирует задачу по инициализации системы другому процессу.

Во-вторых, init выполняет все сценарии, на которые есть символьные ссылки из /etc/runlevels/boot . Это определяется следующей строкой:

И снова все необходимые действия выполняются сценарием rc . Заметьте, что параметр, переданный rc (boot), совпадает с названием используемого подкаталога в /etc/runlevels .

Теперь init проверяет свой конфигурационный файл, чтобы определить, какой уровень запуска использовать. Для этого из /etc/inittab считывается строка:

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

В строке, определяющей уровень 3, для запуска служб снова используется сценарий rc (на этот раз с аргументом default). Опять-таки, обратите внимание, что аргумент, передаваемый сценарию rc , совпадает с названием подкаталога из /etc/runlevels .

По окончании работы rc , init принимает решение о том, какие виртуальные консоли включить и какие команды выполнить в каждой из них. Пример определения виртуальных консолей:

Что такое уровень запуска?¶

Как вы заметили, init применяет нумерацию для определения уровня запуска, который надо использовать. Уровень запуска — это то состояние, в котором запускается ваша система; он содержит набор сценариев (сценариев уровня запуска или сценариев инициализации [initscript]), которые следует выполнять при входе и выходе из определенного уровня запуска.

В Calculate определено семь уровней запуска: три служебных и четыре определяемых пользователем. Служебные называются sysinit, shutdown и reboot. Действия, совершаемые ими, в точности соответствуют их названиям: инициализация системы, выключение системы и ее перезагрузка.

Определяемые пользователем уровни — это те, которым соответствуют подкаталоги в /etc/runlevels : boot , default , nonetwork и single . Уровень boot запускает все службы, необходимые системе и используемые всеми остальными уровнями. Остальные уровни отличаются друг от друга запускаемыми службами: default используется для повседневной работы, nonetwork — для тех случаев, когда не требуется сеть, а single — при необходимости восстановления системы.

Работа со сценариями инициализации¶

Сценарии, запускаемые процессом rc , называются сценариями инициализации. Каждый сценарий из /etc/init.d может запускаться с аргументами start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme и broken.

Для запуска, остановки или перезапуска службы (и всех, зависящих от нее) следует использовать start , stop и restart . Пример запуска postfix:

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

Если вы хотите остановить службу, но оставить зависимые от нее работающими, можно использовать аргумент pause . Пример:

Чтобы узнать текущее состояние службы (запущена, остановлена, приостановлена и т.д.), можно использовать аргумент status . Пример:

Если указано, что служба работает, но вы знаете, что это не так, можно сбросить состояние на stopped (остановлена), используя аргумент zap . Пример сброса информации о состоянии postfix:

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

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

Использование rc-update¶

Что такое rc-update?¶

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

Используя rc-update , можно включать и исключать сценарии инициализации из уровней запуска. Из rc-update автоматически запускается сценарий depscan.sh , который перестраивает дерево зависимостей.

Добавление и удаление служб¶

В процессе установки Calculate вы могли добавлять сценарии инициализации в уровень запуска "default". В тот момент вы, возможно, не имели понятия, что такое "default" и зачем он нужен, но теперь вы это знаете. Сценарию rc-update требуется второй аргумент, определяющий действие: add (добавить), del (удалить) или show (показать).

Для того, чтобы добавить или удалить сценарий, просто введите rc-update с аргументом add или del , затем название сценария и уровня запуска. Пример удаления Postfix из уровня запуска default:

По команде rc-update show выводится список всех доступных сценариев с указанием соответствующих уровней запуска. Пример получения информации о сценариях инициализации:

Настройка служб¶

Почему нужна дополнительная настройка?¶

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

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

Каталог /etc/conf.d¶

В Calculate предусмотрен очень простой способ настройки служб: для каждого сценария, предполагающего настройку, в каталоге /etc/conf.d есть конфигурационный файл. Например, у сценария, запускающего apache2 (под названием /etc/init.d/apache2 ), есть конфигурационный файл /etc/conf.d/apache2 , где могут храниться нужные вам параметры, передаваемые серверу Apache 2 при запуске. Пример переменной, определенной в /etc/conf.d/apache2 :

Такие файлы настроек содержат одни переменные (наподобие /etc/make.conf), облегчая настройку служб. Это также позволяет нам давать больше информации о переменных (в комментариях).

Написание сценариев инициализации¶

Мне тоже придется. ¶

Нет, написание сценариев инициализации обычно не требуется, т.к. Calculate содержит готовые сценарии для всех поддерживаемых служб. Однако, вы можете установить какую-либо службу, не используя систему Portage; в таком случае, вероятно, вам придется создавать сценарий инициализации самостоятельно.

Структура¶

Основная структура сценария инициализации показана ниже.

В любом сценарии должна быть определена функция start() . Все остальные разделы необязательны.

Зависимости¶

Можно определять два типа зависимостей: use (использую) и need (нуждаюсь). Как упоминалось ранее, need -зависимость более строга, чем use -зависимость. Вслед за типом зависимости указывается название службы, от которой существует зависимость, или ссылка на виртуальную (virtual) зависимость.

Виртуальная зависимость — это зависимость от функций, предоставляемых службой, но не какой-то единственной службой. Сценарий может зависеть от службы системного журнала, но таких достаточно много (metalogd, syslog-ng, sysklogd и т.п.). Поскольку нельзя нуждаться в каждой из них (ни в одной корректно работающей системе они не запущены все сразу), мы обеспечили предоставление виртуальной зависимости всеми этими службами.

Давайте взглянем на информацию о зависимостях postfix:

Как можно увидеть, postfix:

требует сеть (net): виртуальная зависимость, удовлетворяемая, например, /etc/init.d/net.eth0
использует журнал (logger): виртуальная зависимость, удовлетворяемая, например, /etc/init.d/syslog-ng
использует службу имен (dns): виртуальная зависимость, удовлетворяемая, например, /etc/init.d/named
предоставляет почтовый агент (mta): виртуальная зависимость, общая для всех программ — почтовых серверов

Порядок запуска¶

Иногда вам нужна не сама служба, а запуск вашей службы до (или после) другой службы, если та присутствует в системе (обратите внимание на условие: это уже не зависимость) и запускается на том же уровне запуска (отметьте условие: это относится только к службам из одинакового уровня запуска). Такую очередность можно указать, используя значения before (до) или after (после).

Например, рассмотрим значения для службы Portmap. Пример функции depend() службы Portmap:

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

Стандартные функции¶

Если вам нужны дополнительные примеры функции start() , пожалуйста, прочитайте исходные коды сценариев инициализации, находящихся в каталоге /etc/init.d . Что касается команды start-stop-daemon , то на случай, если вам нужны дополнительные сведения, есть превосходная страница справки. Пример вызова страницы справки по start-stop-daemon:

Другими функциями, которые можно определить — stop() и restart() . От вас не требуется определение этих функций! Система инициализации, применяемая нами, достаточно развита и в состоянии самостоятельно заполнить эти функции, если вы используете start-stop-daemon .

Синтаксис сценариев инициализации, применяемых в Calculate, основан на оболочке Борна (Bourne Again Shell — bash), поэтому вы можете свободно использовать внутри своих сценариев bash-совместимые конструкции.

Добавление дополнительных параметров¶

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

Переменные для настройки служб¶

Для поддержки конфигурационного файла в каталоге /etc/conf.d ничего дополнительно делать не нужно: при запуске вашего сценария инициализации автоматически включаются следующие файлы (т.е., переменные из них становятся доступны):

/etc/conf.d/<ваш сценарий инициализации>
/etc/conf.d/basic
/etc/rc.conf

Если ваш инициализационный сценарий предоставляет виртуальную зависимость (например, net ), то также включается файл, соответствующий этой зависимости (например, /etc/conf.d/net ).

4.e. Изменение поведения уровней запуска

Кто от этого выиграет?¶

Большинству пользователей ноутбуков знакома ситуация: дома вам нужен запуск net.eth0 , а в дороге, наоборот, запуск net.eth0 не нужен (так как сеть недоступна). В Calculate можно изменять поведение уровней запуска по своему усмотрению.

Например вы можете создать второй загружаемый уровень запуска «по умолчанию», в котором будут другие сценарии. Затем при загрузке вы сможете выбрать, какой из уровней по умолчанию следует использовать.

Использование программного уровня (softlevel)¶

Прежде всего, создайте каталог для своего второго уровня запуска «по умолчанию». Например, создадим уровень запуска offline . Пример создания каталога уровня запуска:

Добавьте необходимые сценарии инициализации в только что созданный уровень запуска. Например, чтобы получить точную копию уровня default , за исключением net.eth0 :

Теперь необходимо отредактировать конфигурацию загрузчика, добавив запись об уровне offline . Например, в файле /boot/grub/grub.conf . Пример:

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

Использование загрузочного уровня (bootlevel)¶

Использование загрузочного уровня полностью аналогично использованию программного уровня. Единственная разница состоит в том, что вы определяете второй уровень "boot" вместо "default".

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

Я предлагаю вам познакомиться со следующими уровнями типичной загрузки Linux:

1. BIOS

BIOS отвечает за базовый ввод/вывод данных с устройств/на устройства.
Делает некоторые проверки целостности устройств. К тому же, за тестирование работоспособности электроники отвечает POST (Power-on self-test, он же «тест на адекватность себя самого», выполняющийся как этап пре-загрузки), который управляется BIOS
Ищет, загружает и выполняет программу-загрузчик ОС
Берет загрузчик из флопика, сидюка или жесткого диска. Во время загрузки BIOS'а вы можете нажать на кнопку (обычно это F12 или F2 или Del, зависит от платформы), если вам требуется внести некоторые изменения касательно настройки железа.
Как только загрузчик был обнаружен и загружен в память, BIOS передает управление ему.
Короче говоря, BIOS загружает и выполняет загрузочную запись (MBR).

2. MBR

MBR — это главная загрузочная запись, хранящаяся на жестком диске
Она размещена в 1-м секторе загрузочного диска, например /dev/hda или /dev/sda
MBR занимает меньше, чем 512 байтов. Она состоит из трех компонентов: 1) главная загрузочная информация, «живущая» в первых 446 байтах; 2) информация о таблице разделов — в следующих 64 байтах; 3) и последние 2 байта нужны для проверки корректности mbr.
Она содержит информацию о GRUB'е (или LILO).
Простыми словами — MBR загружает и выполняет загрузчик GRUB.

3. GRUB

GRUB — Grand Unified Bootloader.
Если в вашей системе установлено более, чем одно ядро, у вас есть возможность выбирать, которое из них должен выполняться
GRUB отображает ~~красивую анимацию plymouth~~ заставку, и, подождав несколько секунд интерактивного воздействия пользователя, если он не нажал ни одной клавиши, он загружает ядро, установленное по умолчанию в файле конфигурации grub.
GRUB понимает, что такое файловая система (древние загрузчики Linux'а, например, LILO этого не понимают).
Конфигурационный файл Grub обычно лежит по пути /boot/grub/grub.conf (так же /etc/grub.conf может быть символьной ссылкой на него). Вот пример файла конфигурации для CentOS:

4. Ядро или Kernel

Ядро монтирует файловую систему в соответствии с настройкой «root=» в фале grub.conf
Выполняет программу /sbin/init
Поскольку init — это первый процесс, запущенный ядром Linux, поэтому она имеет идентификатор процесса (PID) №1. Можете выполнить «ps -ef | grep init» и убедиться в этом.
initrd — это Initial RAM Disk, он же временный диск в оперативной памяти
initrd используется самим ядром в качестве временной корневой файловой системы, пока kernel не загрузится в реальную примонтированную файловую систему. Этот временный диск также содержит необходимые для загрузки драйверы, позволяющие получить доступ к разделам дисков и другому оборудованию

5. Init

Смотрит в файл /etc/inittab для того, чтобы определить уровень выполнения (run level).
Есть следующие уровни выполнения:
- 0 – прервать выполнение
- 1 – Однопользовательский режим, так называемый «Single user mode», или иными словами, консоль восстановления
- 2 – Многопользовательский режим без поддержки NFS
- 3 – Полноценный многопользовательский режим
- 4 – не используется
- 5 – X11
- 6 – перезагрузка
6. Уровень выполнения программ (Runlevel)

Вот и все. Возможно, некоторым из вас это не ново и особого интереса не было при чтении статью, поскольку она более ориентирована на начально-средний уровень знакомства з Линуксом.
В таком случае могу лишь сказать, что «повторение — мать учения» (с).

Дополнения, исправления, уточнения
В операционной системе Linux и других системах семейства Unix после завершения загрузки ядра начинается инициализация Linux системы, сервисов и других компонентов. За это отвечает процесс инициализации, он запускается ядром сразу после завершения загрузки, имеет PID 1, и будет выполняться пока будет работать система.

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

Системы инициализации Linux

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

1. System V Init

System V или SysV - это довольно старая, но до сих пор ещё популярная система инициализации Linux и Unix подобных операционных систем. Она была основой для создания многих других систем инициализации, а также первой коммерческой системой инициализации разработанной для Unix в AT&T. Она была разработана еще в 1983 году.

Почти все дистрибутивы Linux изначально использовали SysV. Исключением была только Gentoo, в которой использовалась собственная система инициализации и Slackware, с инициализацией в стиле BSD.

Основные возможности SysV:
- Написание файлов запуска служб на bash;
- Последовательный запуск служб;
- Сортировка порядка запуска с помощью номеров в именах файлов;
- Команды для запуска, остановки и проверки состояния служб.
Никакой параллельной загрузки, системы зависимостей, запуска по требованию и автоматического запуска здесь не было и в помине.

С момента ее разработки прошло много лет и из-за некоторых недостатков были разработаны другие системы для ее замены, они хоть и имели новые функции и были более эффективны, но они были по-прежнему совместимы с SysV.

2. OpenRC

OpenRC - это система инициализации Linux и Unix подобных операционных систем совместимая с Sys V Init и поддерживающая систему зависимостей во время запуска. Она приносит некоторые улучшения в SysV, и как и другие системы инициализации Linux, совместима с ней, но вы должны иметь в виду, что OpenRC не заменяет полностью файл /sbin/init. Эта система инициализации используется в Gentoo и дистрибутивах BSD.

Кроме стандартных возможностей SysV, здесь поддерживается также:
- Поддержка зависимостей служб;
- Поддержка параллельного запуска служб;
- Поддерживает настройку в одном отдельном файле;
- Работает как демон;
По сравнению с SysV тут появилось много новых возможностей, но все еще не все те, что нужны для оптимальной работы системы.

3. Systemd

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

Systemd очень сильно отличается от всех существующих систем инициализации, тем как она работает с сервисами, и даже конфигурационными файлами сервисов. Совместимости со скриптами SysV нет, их нужно преобразовать в linux systemd unit файлы.

Вот ее основные особенности:
- Понятный, простой и эффективный дизайн;
- Параллельная загрузка служб на основе зависимостей;
- Поддерживается завершение дополнительных процессов;
- Поддерживается собственный журнал с помощью journald;
- Поддерживается планирование заданий с помощью таймеров Systemd;
- Поддерживается управление сетью с помощью networkd;
- Для управления DNS используется systemd-resolved;
- Хранение журналов в бинарных файлах;
- Сохранение состояния сервисов linux systemd для возможного восстановления;
- Улучшенная интеграция с Gnome;
- Запуск сервисов по требованию;
4. Runinit

Runinit - это кроссплатформенная система инициализации, которая может работать в GNU Linux, Solaris, BSD и MacOS. Это отличная альтернатива для SysV с поддержкой мониторинга состояния служб.

Здесь есть некоторые интересные особенности, которых нет в других системах инициализации:
- Полный контроль сервисов, каждый сервис привязывается к своему каталогу;
- Надежное средство журналирования и ротации логов;
- Быстрая система загрузки и выключения;
- Портативность;
- Легкое создание файлов конфигурации служб;
- Небольшое количество кода системы инициализации.
5. Upstart

Upstart - это система инициализации на основе событий, разработанная в Canonical и призванная заменять SysV. Она может запускать системные службы, выполнять над ними различные задачи, инспектировать их во время выполнения, а также выполнять нужные действия в ответ на события в системе.

Это гибридная система инициализации, она использует как SysV скрипты запуска, так и файлы служб Systemd. Вот ее самые заметные особенности:
- Изначально разработанная для Ubuntu, но может использоваться и в других дистрибутивах;
- Запуск и остановка служб на основе событий;
- Генерация событий во время запуска и остановки служб;
- События могут быть отправлены обычными процессами;
- Связь с процессом инициализации через DBus;
- Пользователи могут запускать и останавливать свои процессы;
- Перезапуск служб, которые неожиданно завершились;
- Параллельная загрузка сервисов;
- Автоматический перезапуск служб;
Большинство ее возможностей работают благодаря интеграции с системой инициализации Systemd. В последнее время всё меньше используются скрипты SysV init и всё больше применяются юнит файлы Systemd. Рано или поздно Systemd вытеснит и полностью заменит Upstart в Ubuntu.

Выводы

Как я уже говорил, система инициализации запускает и управляет всеми другими процессами в системе Linux. SysV до недавнего времени была основной системой инициализации в большинстве дистрибутивов Linux, но из-за некоторых своих недостатков для нее было разработано несколько замен, в том числе Systemd.

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

Я создаю дистрибутив Linux, и теперь мне нужна программа init. Я очень хорошо умею кодировать на c и знаю немного о linux (не так много, но я использую arch linux для разработки в течение 4 лет), поэтому я подумал, что должен попробовать написать свой базовый скрипт инициализации на C. просто интересно, какие задачи выполняет init для настройки системы на простую оболочку? (Когда я спрашиваю «что делает init?», Я знаю, что такое init и для чего он. Я просто не знаю, для каких задач он выполняет.)

Мне не нужен код , и я , возможно , даже не нужны базовые команды , но я действительно нужен порядок , что они работают в.
Вы можете использовать любой интерпретатор для сценариев инициализации в стиле SysV, включая Perl, awk, bash, (t) csh, собственные двоичные файлы . Обычно используется Bash, потому что он практически гарантированно доступен в системе, где такие сценарии развернут в соответствующей точке процесса загрузки, а не потому, что существует некоторая связь между SysVinit и bash. SysVinit определяет контракт, и каждый скрипт может реализовать этот контракт любым способом, который его разработчик сочтет нужным.
Есть какая-то близорукость, которая влияет на мир Linux. Люди думают, что они используют то, что называется «Система 5 init », и это то, что является традиционным, и лучшее место для старта. На самом деле это не так.

На самом деле, традиция не совсем такая, как говорят такие люди. Система 5 init и Система 5 rc относятся к AT & T UNIX System 5, которая была почти такой же далекой после первой UNIX, как мы сейчас (скажем) после первой версии Linux-Mandrake.

Только первое издание UNIX имело init . Не было rc . Язык ассемблера 1-го издания init ( чей код был восстановлен и доступен Уорреном Туми и др. ) Непосредственно породил 12 getty процессов, смонтировал 3 встроенные файловые системы из встроенной таблицы и непосредственно запустил программу из домашнего каталога пользователь по имени mel . getty Стол был также непосредственно в образе программы.

Еще одно десятилетие после UNIX System 5 появилась так называемая «традиционная» система инициализации Linux. В 1992 году Микель ван Смуренбург (пере) написал Linux init + rc и связанные с ним инструменты, которые люди теперь называют «Системой 5 init », хотя на самом деле это не программное обеспечение UNIX System 5 (и не только init ).

Система 5 init / rc - не лучшее место для старта, и даже если добавить знания о systemd, которые не покрывают половину того, что нужно знать. В области проектирования систем инициализации (для Linux и BSD) было проделано много работы только за последние два десятилетия. Все виды инженерных решений были обсуждены, приняты, спроектированы, реализованы и реализованы на практике. Коммерческие Unices тоже многое сделали.

Вот неполный список некоторых основных систем инициализации, отличных от этих двух, и один или два из их (нескольких) существенных моментов:
- Конструкция nosh включает вытеснение всего управления службами (включая даже getty порождение и зомби) в отдельный диспетчер служб и просто обработку специфичных для операционной системы устройств / символических ссылок / каталогов / каталогов и системных событий. это очень простой инициат. Он выполняет /bin/rc.init чью работу - запускать программы, монтировать файловую систему и т. Д. Для этого вы можете использовать что-то вроде minirc .
Более того, около 10 лет назад среди пользователей daemontools и других пользователей обсуждалась возможность использования в svscan качестве процесса № 1, что привело к таким проектам, как svscan Пола Жарка в качестве исследования процесса 1 , идеи Геррита Папе и svscan Лорана Берко в качестве процесса 1 .

Что подводит нас к тому, что делают программы №1.

Представления о том, что процесс «1» должен делать, по своей природе субъективны. Значимым объективным критерием разработки является то, что должен делать процесс № 1 как минимум . Ядро предъявляет к нему несколько требований. И всегда есть некоторые специфические для операционной системы вещи разных видов, которые она должна делать. Когда дело доходит до того, что процесс № 1 традиционно выполнял, то мы не достигли такого минимума и никогда не были на самом деле.

Есть несколько вещей, которые различные ядра операционной системы и другие программы требуют от процесса № 1, от которого просто невозможно уйти.
- программа IBM AIX srcmstr , контроллер системных ресурсов
- Геррит Папе runsvdir из Рунита
- Даниэль Дж. Бернштейн svscan из Daemontools, Адам Сэмпсон svscan из Freedt , Брюс Гюнтер из Daemontools-Encoresvscan и Лоран Берко s6-svscan из S6
- Уэйн Маршалл perpd из Перп
- Средство управления сервисом в Solaris 10
- service-manager от Nosh
Существуют также разовые задачи инициализации и финализации, от которых невозможно уйти или которые они сильно пострадают, например, монтирование файловых систем «API» или очистка кеша файловой системы.

Основы работы с файловыми системами «API» мало чем отличаются от работы с init 1-й редакцией UNIX: у каждого есть список информации, встроенной в программу, а у одного просто mount() все записи в списке. Вы найдете этот механизм в таких разнообразных системах, как BSD (sic!) init , Через nosh system-manager , для systemd.

Чтобы увидеть, что у человека на самом деле нет другого выбора, кроме как выполнять программы процесса № 1, и, таким образом, выбрать правильный курс для достижения заявленной цели проектирования, лучше всего посмотреть на совпадения в работе рунита Геррита Папе, Феликса фон Минит Лейтнера и system-manager программа из пакета nosh. Первые два показывают две попытки быть минималистскими, но все же работают с вещами, которых невозможно избежать.

Процесс INIT — это движущая сила, которая обеспечивает работу компьютера под управлением Linux, но она может и убить систему. Эта статья расскажет о том, что такое процесс Init, а также поможет узнать, как подчинить поведение этого процесса себе. (Да, Init — это сила, но администратор системы может управлять этой силой).
Вообще-то в UNIX слово "init" не обозначает конкретную программу, скорее всего целый класс программ. Название "init" используется для вызова первого процесса после загрузки системы, первого и единственного процесса. Когда кернел завершает проверку и настройку аппаратного обеспечения компьютера, он вызывает "init" и передает ему контроль над компьютером. С этого момента кернел обрабатывает только системные вызовы ( system calls), не заботясь более о поведении операционной системы. После того как кернел монтирует корневую файловую систему, все контролируется процессом "init".

Как Вы уже догадываетесь, простейший путь для получения прав доступа супервизора системы и его администратора на компьютере с ОС Linux — это напечатать строку "init=/bin/sh" в ответ на приглашение загрузчика LILO. Учтите, что это не является "прорехой" в безопасности системы, потому что настоящей угрозой безопасности системы является физический доступ к компьютеру и его системной консоли. Если Вы опасаетесь возможности ввода параметров "init=" в процессе загрузки, то сам загрузчик LILO может предотвратить возможность подобного несанкционированного управления при помощи защиты своим собственным паролем.
Задача процесса Init
Мы уже знаем, что имя "Init" не собственное, а, скорее, нарицательное, и его может использовать почти любая программа. Вопрос лишь в том, чем в самом деле должен заниматься "Init"? Будучи первым (и единственным) процессом, выполняемым кернелом, "Init" должен заботиться о запуске всех остальных процессов в системе, включая различные программы-демоны, используемые операционной системой, а также обеспечивать сеансы связи с текстовыми консолями. "Init" также должен перезапускать некоторые из своих порожденных процессов после завершения их работы. Обычно это касается всех сеансов связи через консоли. Как только Вы отключаетесь от системы, она должна вновь запустить программу getty, чтобы предоставить возможность следующего соединения. Кроме этого, "Init" заботится о мертвых процессах и отделывается от них. В соответствии с понятием процессов в UNIX, процесс не может быть удален из системной таблицы процессов, пока о его смерти не будет сообщено процессу, породившему данный процесс (или другому процессу-предку, в случае, если процесс-родитель больше не существует). В случае, если процесс прекращает работу после системного вызова exit, он остается в состоянии зомби-процесса, пока кто-нибудь не позаботится о нем. "Init", будучи предком любого другого процесса, должен собирать информацию о состоянии завершения каждого усыновленного зомби-процесса. Следует отметить, что грамотно написанная программа должна сама заботиться о всех порожденных собой процессах, зомби появляются только как следствие некорректного поведения программ. Если бы "Init" не собирал все зомби-процессы, то ленивые программисты легко и быстро исчерпали бы все системные ресурсы и компьютер с переполненной системной таблицей процессов просто завис бы.

Как говорилось выше, шелл может использоваться в качестве программы "Init". Использование "голого"шелла (init=/bin/sh) просто открывает сеанс связи системного администратора на абсолютно несконфигурированном компьютере. Эта глава описывает, как скрипт шелла может выполнить все задачи, необходимые для работы системы в минимальной конфигурации. Этот вид упрощенной программы "Init" может использоваться в изолированных системах либо в случаях ограничения системных ресурсов, когда нужно экономить каждый бит памяти. Самым радикальным решением для изолированных систем является прямое использование конкретного приложения в качестве процесса "Init", в результате мы получим закрытую систему (без возможности взаимодействия с ее администратором, что, несомненно, вызовет проблемы), но иногда такая конфигурация удовлетворяет конкретным технологическим требованиям. Типичным примером системы Linux без реальной программы "Init" служит установочный диск с дистрибутивом операционной системы, в ней /sbin/init — это символьная ссылка на программу установки.

Когда Вы загружаете систему в режиме init=/bin/sh, Вы должны по крайней мере перемонтировать корневую файловую систему перед тем, как делать что-либо еще, не забудьте также выполнить команду:
umount -a
перед нажатием ctrl-alt-del, потому что шелл не перехватывает эту комбинацию из трех клавиш.
Программа simpleinit
Модуль util-linux содержит исходники программы Init на языке С. У этой программы гораздо больше возможностей, чем у простого скрипта, и она может хорошо работать с большинством персональных компьютеров, хотя она не обладает такими широкими возможностями изменения своей конфигурации, как модуль SysVinit, поставляемый со многими дистрибутивами Linux.
Роль программы simpleinit (которая должна называться init для нормальной работы) очень похожа на роль скрипта, приведенного выше, с добавлением возможностей управления однопользовательским режимом и интерактивным вызовом сеансов связи через консоли. Также она корректно выполняет процедуру отключения системы. На программу simpleinit интересно посмотреть, она хорошо документирована, Вам, несомненно, понравится знакомство с прилагаемой документацией. Я советую обратиться к дистрибутиву модуля util-linux для получения более свежей информации. Средства программы simpleinit предельно просты, как и обещает ее название. Программа вызывает скрипт ( /etc/rc) и запрашивает файл конфигурации, чтобы определить, какой процесс должен быть перезапущен. Файл конфигурации называется /etc/inittab, аналогично файлам конфигурации других программ "init", хотя его формат и отличается от них. Если Вы планируете установить simpleinit на свой компьютер (который, скорее всего, уже содержит SysVinit), вы должны делать это очень осторожно и быть готовым к загрузке системы с аргументом кернела "init=/bin/sh" для исправления ошибок.

Продолжение следует
Алессандро РубиниLinux Journal, issue 55, November 1998, перевод Игоря Греня

Компьютерная газета. Статья была опубликована в номере 49 за 1998 год в рубрике soft :: unix

Читайте также: